GitLab

On the backend side, add adding 5 new parameters to TextPage::findText(),
4 to return coords for the part of the match that falls on the next line,
and 1 to specify whether hyphen was ignored at end of the first line.

For the glib binding, this extends the public PopplerRectangle struct
by new members to hold additional information about whether the rectangle
belongs to a group of rectangles for the same match, and whether a hyphen
was ignored at the end of the line. Since PopplerRectangle is public
ABI, this is done by making the public PopplerRectangle API return the
enlarged struct, and internally casting to the new struct when required;
the new members are accessible only via accessor functions.

For Qt5 binding, this commit only implements the new flag
Poppler::Page::AcrossLines (but no new function and no new
return data type) and if this flag is passed, the returned
list of rectangles will also include rectangles for the
second part of across-line matches.

This minimum qt5 binding still allows for the creation of
tests for this feature (using the qt5 test framework) which
this commit *do includes*. But a more complete binding (with
a new return type that includes 'next_line' and 'after_hyphen'
boolean fields) is left to do for qt5 binding maintainers
if they want to use this feature (in eg. Okular).

So, as mentioned, this commit incorporates tests for the
implemented across-line matching feature, and the tests do
also check for two included aspects of this feature, which are:

 - Ignoring hyphen character while matching when 1) it's the
   last character of the line and 2) its corresponding matching
   character in the search term is not an hyphen too.

 - Any whitespace characters in the search term will be allowed
   to match on the logic position where the lines split (i.e. what
   would normally be the newline character in a text file, but
   PDF text does not include newline characters between lines).

Regarding the enhancement to findText() function which implements
matching across lines, just two more notes:

 - It won't match on text spanning more than two lines, i.e. it
   only matches text spanning from end of one line to start of
   next line.

 - It does not supports finding backwards, if findText() receives
   both <backward> and <matchAcrossLines> parameters as true, it
   will ignore the <matchAcrossLines> parameter. Implementing
   <matchAcrossLines> with backwards direction is possible, but
   it will make an already complex function like findText() to be
   even more complex, for little gain as eg. Evince does not even
   use the <backward> parameter of findText().

Fixes poppler issues #744 and #755
Related Evince issue https://gitlab.gnome.org/GNOME/evince/issues/333

Don't make Ascii7Map be static, otherwise it will cache the unicode map
between globlParams and end up with a bad pointer

If we find the constant searching of the unicode in globalparams is a
speed problem we need to apply a similar solution to the one we did for
UTF8

And make the cache just be "infinite", it's not like we support
that many maps or that there's so many used in a given session,
and if they are, well it's good we cached them

All the unicode maps we support use about 2MB of memory, but PSOutputDev
is the only one that loads "random" unicodeMaps so to load them all
you'd had to print lots of different documents with fonts with lots of
different font encodings, so it seems like a not very likely situation
and the code gets simplified a bit

Move the initer of the cpp frontend into the core to able to reuse it for the qt5 and glib frontends.

Remove LinkAction::setNextActions as this setter should not be used outside of the ::parseAction method.

The convertLinkActionToLink method deep-copies every poppler LinkAction
object into a Link object as used by the Qt5 frontend.  With one
exception: LinkOCGState objects are not deep-copied, but pointers to
them are stored instead.  This makes for a memory management that is
inconsistent, difficult to understand, and prone to memory errors.
The present patch introduces deep-copying for LinkOCGState objects
as well.

... rather than a pointer.  This makes it clearer that the
result is borrowed, and should not be shallow-copied.

Rather than a pointer to a std::vector.  This removes one
layer of indirection when accessing the vector.

Makes the code a bit simpler

GlobalParams::getUnicodeMap was just calling
GlobalParams::getUnicodeMap2 so move the code of this one to the other
one and save ourselves having one function that just calls the other

To make it clear that it is an owning pointer.

oss-fuzz/19630

Noone uses it so it's a bit faster not to do it

Because it is already copy-constructible, and having one without
the other is weird.

A Ref is really just two ints.  Let's not call malloc separately
for each of them.