[jira] Commented: (PDFBOX-678) Support missing Text Rendering Modes when rendering a PDF

["Maruan Sahyoun (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863280#action_12863280 ] 

Maruan Sahyoun commented on PDFBOX-678:
---------------------------------------

After reviewing the changes which have to be made in order to implement the different text rendering modes I would like to get feedback on how to move forward:

a) for drawing the outlines of the font (stroke text) these are generated by creating a TextLayout object and getting a Shape from that. For that to work we need a AWT font object where Daniel already implement a getawtFont() method for PDSimpleFont. For Type3 fonts there is no such approach so enhanced text rendering modes won't be available for that

b) text rendering modes which involve clipping need some more changes as with the current approach of page rendering the text and the graphics are being written independently from each other i.e. when the text is rendered is has no 'knowledge' about the graphics. This would need to be changed in order to set the clipping path for drawing together with a Composite to do the overlay.

c) currently when text is drawn it's drawn as a string. For the outlines modes a Shape is drawn. For the display this doesn't really matter but when it comes to applications such as text selection this would mean that ouline modes wouldn't allow for the text to be selected. This could be overcome by either drawing the filled part (STROKE_AND_FILL_TEXT) as a string or by adding a transparent filled text drawn as string for stroke only modes

a) and b) are needed for PDFReader and PDFPrinter type applications where c) is needed if PDFReader should become more than a viewing application.

Questions from these topics

a) how important is Type3 support?
b) did I understand the current rendering process correctly in that text and graphics is being written independently?
c) how important is the implementation of CLIPPING text rendering modes?

 

> Support missing Text Rendering Modes when rendering a PDF
> ---------------------------------------------------------
>
>                 Key: PDFBOX-678
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-678
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: PDFReader
>            Reporter: Maruan Sahyoun
>
> Of the 7 different Text Rendering Modes only mode 0 (Fill Text) is correctly implemented. Mode 1 (Stroke Text) falls back to Mode 0 and the others are not implemented. I'm looking to implement the missing modes (at least some of them).
> Before doing so I'm proposing a structural change to when rendering really occurs. Currently it's done within the PDxxxFont classes. I'd rather implement the (AWT) text output in PageDrawer (or helper classes within the same package) and use the font classes to return an AWT font by adding a getAwtFont method. Doing so we get a better separation between the PDF related stuff (PDxxx) and applications like PageDrawer. The current rendering specific code within the PDxxxFont classes can be retained for compatibility and marked deprecated at a later stage.
> WDYT?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.