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
find . \( -name "*.cpp" -or -name "*.h" -or -name "*.c" -or -name "*.cc" \) -exec clang-format -i {} \;
If you reached this file doing a git blame, please see README.clang-format (added 2 commits in the future of this one)
The problem was that the JS checker for the field format was using the
willCommit property of event and we don't define it so the JS
interpreter was going "ok nope, out of here" and the field didn't get edited.
I've read the willCommit definition in js_api_reference.pdf for almost
30 minutes, and even it's just 3 lines i don't think i understand it,
but i think that returning true is "safer", i.e. says that this event is
going to actually change the field, which as far as i can see it's what
we always do
BUGS: 421508
Summary:
This adds a new data object "Event" that can be used
to carry information in and out of JavaScript execution
contexts. The Event Object is defined in the Adobe JavaScript
scripting reference.
The implementation now adds handling for the FieldCalculate
Event. It should be extensible enough so that in the future
more events could be supported.
Reviewers: #okular
Subscribers: aacid
Tags: #okular
Maniphest Tasks: T7805
Differential Revision: https://phabricator.kde.org/D10073
Nicolas Fella
Volker Krause
Nicolas Fella
Alexander Lohnau
Albert Astals Cid
João Netto
Andre Heinecke