1
votes

According to some q&a I understand that iText text extraction tool is not capable to recognize underline and strikethrough font attributes due to the PDF specification not supporting it. To allow recognition I did update PdfContentStreamProcessor.java by adding shape subpath recognition. I did also add ShapeRenderInfo.java to contain graphics info.

For instance recognizing underline means start from a TextRenderInfo object and scan all ShapeRenderInfo to try to match (rectangle contains/intersect ... etc)) the By reading q&a I did understand that iText text extraction tool is not supporting underline (strike-through, over-strike, ...) font attributes recognitions due to PDF specification allowing underline only by drawing shapes under text. To achieve underline recognition I did update PdfContentStreamProcessor.java by adding shape sub-path management, I did also add ShapeRenderInfo.java to contain graphics rendering parameters.

My idea is to have underline recognized by getting Rectangles2D from both TextRenderInfo and ShapeRenderInfo and by checking for containment/intersection between them.

What I'm doing implies a noticeable change in how currently iText delivers events to RenderListener, because they are currently propagated as encountered in the pdf streams, on the contrary I need that XxxxxRenderObjects are collected first, then delivered at page end, thus allowing searching through rectangles.

In brief: isUnderline() method on TextRenderInfo, will start scanning into collected shapes trying to match graphic objects rectangles against text rectangles.

Beside the need to update RenderListener.java to allow ShapeRender events propagation, I did identified the following possible solutions to implement the logic change:

1) update PdfContentStreamProcessor implementing the new event delivery policy

2) shield PdfContentStreamProcessor and RenderListener(s) by inserting a new layer (a new listener) capable to handle the logic

My question to the iText team is: What is the best choice? Have you any further suggestion?

Thank you beforehand

JQ.

1
I'm not part of some iText team, but my 2ยข anyway: I would propose putting all the stuff collecting the events for a single page or analyzing them in a separate layer. There is hardly anything to gain by putting these functionalities together, so different programming units should be used. - mkl
This is an interesting question, but it is too difficult to answer it in the context of a StackOverflow question. This is something that should be discussed with the iText development team. We are working on similar projects. See for instance: youtube.com/watch?v=lZnbhnU4m3Y You really want to avoid a situation where we work on this functionality in the official release and you work on the functionality by creating a fork that is not compatible with the official version. - Bruno Lowagie
Bruno I agree, this is why I'm asking this question, if my code could be of some use for iText I'll be happy to share. - JQJ

1 Answers

0
votes

Since iText does not provide all required events I did modify PdfContentStreamProcessor by adding necessary PDF commands handling (see PDF reference chapter 8) then I did write a new handler RenderListenerExtended to add shape processing capabilities. Then new logic (required for underline, overline etc...) has been implemented following point 2. Testing is ongoing. JQ