Find feature produces some wrong highlightments

[calixteman]

Attach (recommended) or Link to PDF file here:
cd.pdf

Configuration:

• Web browser and its version: Firefox nightly
• Operating system and its version: Windows 11

Steps to reproduce the problem:

1. Search for e and Highlight all

Something is wrong around the B(cb, cs).
From the find_controler:
...of the blend function B (c b , cs ) shall be the so...

and from devtools:

The problem is the space between c and b: it's either an extra space in the searched string or a missing one in the html.

[calixteman]

In both cases, we call getTextContent but in the TextLayer case we pass includeMarkedContent = true when in the search case we pass a false.
Hence, in the TextLayer case we hit these path:

pdf.js/src/core/evaluator.js

Line 3302 in b5fea8f

flushTextContentItem();

pdf.js/src/core/evaluator.js

Line 3318 in b5fea8f

flushTextContentItem();

then

pdf.js/src/core/evaluator.js

Line 2921 in b5fea8f

textContentItem.initialized = false;

but not in the search case.
And finally it makes a difference here:
https://github.com/mozilla/pdf.js/blob/master/src/core/evaluator.js#L2471 which is called with the operator OPS.setTextMatrix.

[calixteman]

So in the TextLayer case we have a forced flush between the c and the b.
In the other one, we compare the positions of the two glyphs but with different font size and since the b is a bit smaller then a white space is guessed.
Having a space between c and b isn't a big deal, the real problem is that we've different behaviors which lead to something really wrong.
So fixing the extra space is another problem, but I think that in the search case we must flush the text chunk exactly at the same time as in the TextLayer case, just to have something consistent.

@Snuffleupagus, do you have any thoughts here ?

[Snuffleupagus]

but I think that in the search case we must flush the text chunk exactly at the same time as in the TextLayer case, just to have something consistent.

That sounds reasonable, since we obviously must return consistent textContent-data regardless of the includeMarkedContent value used.

Looking at the surrounding code, I can't help wondering why we don't also "flush" in the following case?

pdf.js/src/core/evaluator.js

Lines 3292 to 3299 in cd35b9b

	case OPS.beginMarkedContent:
	if (includeMarkedContent) {
	textContent.items.push({
	type: "beginMarkedContent",
	tag: args[0] instanceof Name ? args[0].name : null,
	});
	}
	break;