Added handler to make text div building more flexible

[AsterAI]

No description provided.

[timvandermeij]

I'm not entirely sure what the purpose of this patch is. Could you elaborate a bit on what problem this solves?

[Snuffleupagus]

I'm not entirely sure what the purpose of this patch is. Could you elaborate a bit on what problem this solves?

Furthermore, even with the necessary details explaining the purpose of the patch, there's the additional problem of this basically being dead code; #8413 (comment) seems very much relevant here as well.

[AsterAI]

@timvandermeij
Hi Tim, this patch allow pdf.js delegate some responsibility during it builds text divs.
Now EVERYTHING are controlled by pdf.js. This patch allow to change div creation logic by side "clients" of pdf.js lib

Example:
apply some classes to divs, that depends on low level transform matrix .e.t.c
Now, to change logic i have to patch appendText function in my private forks.

P.S. in the future I see pdf.js architecture that fully match to Open/Close principle.
To do this we have to review pds.js architecture to plugin / component / module oriented architectures.

[yurydelendik]

handler-based is somewhat a new pattern to the PDF.js. We can add e.g. onProgress event to the task returned by readerTextLayer (to match what we do with loading task) and not perform handler presents check for every item, but for block of items e.g. at _processItems level. If consumer wants to perform additional actions, they can monitor onProgress event on the task.

We did factory based approach so we don't need to change anything in web/ for custom solutions. I'm think, you will not need that with onProgress callback, or just inherit existing TextLayerBuilder to specify additional onProgress monitoring thing for a rendering task.

[AsterAI]

Ok, i will try to implement new event onGlyphProcess event