This bug would cause out-of-memory errors when zoomed in.
There's an equivalent (and therefore redundant) check for if the
normalizedRect is null, so it looks like the normalizedArea != 0 check
was an oversight, if anything.
QTime is quite inefficient and getFreeMemory sometimes gets called quite
frequently. I found that upwards of 10% of CPU time was being spent
inside of QTime in some cases. Besides being the recommended thing for
this use case, QDeadlineTimer is a lot more efficient.
This represents the newly entered data for each keystroke. This is often a single added character, but for cases like pasting text it can be more complex.
The PDF API reference doesn't specify any algorithm to use.
The algorithm used here works by iterating through both strings from the start until the first different character is encountered. Then the rest of the new text is considered the difference.
This doesn't produce the theoretically optimal/minimal diff, but seems to work well enough for practical application.
When text is removed the diff is empty
QLinkedList is deprecated in later Qt5 and gone in Qt6
The 1:1 port is std::list but in this cases all we ever do
is create the lists, push back to them, and pass then around
to be read, for that a QList is more than enough
Make it more similar to how we handle the format event.
We pass the new value to processKeystrokeAction, that calls the script
and sets the new value for the form object according to the result. If
needed the widget is refreshed to reflect the new text
I'm going to need to break binary compatibility to add a new feature
so may as well cleanup all the TODOs regarding that
Changes:
* Moving a few destructors to the header
* Removing a few unnecessary & in params
* Adding a few necessary & in params
* Making print return an enum instead of a bool and then having another
function that returns the enum
* Make Generator::requestFontData be a virtual
* Remove unused enum
* Remove a few filePrinter unneeded functions
* Remove unused TextDocumentGenerator::addMetaData signal
The PixmapRequest constructor expected width and height in logical
pixels, and scaled them to device pixels. However, not knowing what
screen the request is for, it had to use qApp->devicePixelRatio()
for the scaling. That value may not be correct if not all screens
use the same scaling.
Fix this by introducing a new constructor that takes the device
pixel ratio as an additional argument, and deprecating the old
constructor.
