Currently when adding a signature the user is prompted to specify a
rectangle, then chose a certificate. The problem here is that the
user doesn't know what size is appropriate, so it takes some trial and
error to get something good.
To address this change the flow a bit. First ask which certificate and
other parameters should be used. With that information we create a
signature annotation object and add that to the page. The user can
then move and resize it like any annotation util the size and placement
is right.
Once the user is happy with the placement they click on a Finish Signing
button that then prompts for where to save the signed document and signs
it.
This makes the warning about a too small signature rect redundant since
the user sees that the signature won't fit. It was only an approximation
anyway.
CCBUG: 443403
Also did some refactoring on the keystroke, format, validate methods.
Created new methods that can accept any generalized form field to allow
for the operations on FormFieldChoice as well.
Fixes two things:
1. Cursor positions are being incorrectly calculated in scenarios where keystroke actions reject some input text.
2. Undo/redo operations were buggy and the commands would not merge often leading to single character undo/redo most of the times.
Currently event.change evaluates from first point of difference to end of the string. This MR modifies it to evaluate to whole incoming text. Now we evaluate whatever change is coming in, even if that change contains some common substring with original string (not considering only from the first point of difference).
The current definition makes it difficult to evaluate the final value from event.value and event.change within Javascript. This change is also better from compatibility POV as other readers such as Adobe and PDF.js make similar calculations.
It complicates stuff further down the line and we don't gain much for
it, so work with the rest of the stack rather than work around it.
One of the complications is that if bindir contains both plugins and executable, we will have okular and okular/ in the same folder and that doesn't really work.
We now definitely has std::as_const available and Qt has started nagging
about converting to std::as_const.
Implementation is the same for both functions, and qAsConst was a
stop-gap measure until std::as_const was sufficiently available.
In order to be able to also do this with Qt6 we can't currently rely on
'random distro' to be able to give us an environment sufficient for
running clang and clazy, so use the CI system setup instead
A side effect is that we get a newer clazy and clang-tidy and thus is a
few more issues to either ignore or fix.
Also, ask ninja to continue as long as possible rather than stop at
first error to be able to get succes in as few runs as possible
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
