[
https://issues.apache.org/jira/browse/PDFBOX-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868094#action_12868094
]
Maruan Sahyoun commented on PDFBOX-678:
---------------------------------------
Sorry for answering so late.
I've partially implemented it extending processTextPosition() within PageDrawer
thus being dependent on the correct behavior for BT/ET processing from the
current implementation.
Creating the shapes from there works fine as well as fill and stroke. As
fillPath and strokePath reset the clipping after every drawing operation I set
the clipping path again.
For landscape orientation everything is fine. I need to implement page rotation
(Outlines behave a little different than drawString()).
While implementing the outlines I found a possible bug for the stroke width
which is taken from the graphics object "next" to the text for clipping modes
which results in a too thick stroke for the samples I have. I'll open another
incident if further investigation shows that this is really a bug.
> 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
> Attachments: Java Printing.pdf
>
>
> 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.
