[
https://issues.apache.org/jira/browse/PDFBOX-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864837#action_12864837
]
Andreas Lehmkühler commented on PDFBOX-678:
-------------------------------------------
Puh, I've just realized that my last hint wasn't that good. The whole
clipping-stuff isn't that easy. I'm sorry for that.
Now, I've take some time to dig deeper into it and here is the result:
PDF-Reference 1.7., Section 5.2.5 says:
"The behavior of the clipping modes requires further explanation. Glyph
outlines begin accumulating if a BT operator is executed while the text
rendering mode is set to a clipping mode or if it is set to a clipping mode
within a text object. Glyphs accumulate until the text object is ended by an ET
operator; the text rendering mode must not be changed back to a nonclipping
mode before that point.
...
At the end of the text object, the accumulated glyph outlines, if any, are
combined into a single path, treating the individual outlines as subpaths of
that path and applying the nonzero winding number rule (see "Nonzero Winding
Number Rule" on page 232). The current clipping path in the graphics state is
set to the intersection of this path with the previous clipping path. As is the
case for path objects, this clipping occurs after all filling and stroking
operations for the text object have occurred. It remains in effect until some
previous clipping path is restored by an invocation of the Q operator."
AFAIU the reference the following processing order could work, without any hack:
1. create the shape from the TextLayout
2. add the shape to the current linepath
3. repeat 1.+2. until the end of the textobject (ET operator -> EndText)
4. clone the current linepath
5. fill the path by calling fillPath()
6. clone the current linepath
7. stroke the path by calling fillPath()
8. add the cloned linepath to the current linepath
9. intersect the linepath with the current clipping path by calling
setClippingPath
4.+5. are only necessary for filing and 6.+7. for stroking
WDYT?
P.S.: PDF-Reference 1.7., Section 5.2.5 has also a note about Type3-Fonts: "The
text rendering mode has no effect on text displayed in a Type 3 font" :-))
> 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.
