[
https://issues.apache.org/jira/browse/PDFBOX-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977909#comment-14977909
]
Andreas Lehmkühler commented on PDFBOX-3063:
--------------------------------------------
Sorry, but I don't agree. I guess most of the people don't need that color
stuff so that we shouldn't add those operators by default. As Tilman already
pointed out, people need some expert knowledge on how to handle those color
values (take the text rendering mode into account, PDColor doesn't always
provide simple RGB values, etc.), so that we may expect a lot
missunderstandings and questions on the mailing list. I would prefer to start
with an example on how to use colors by overriding/ectending PDFTextStripper
including the "missing" operators.
> Appears that getStrokingColor/getNonStrokingColor are broken
> ------------------------------------------------------------
>
> Key: PDFBOX-3063
> URL: https://issues.apache.org/jira/browse/PDFBOX-3063
> Project: PDFBox
> Issue Type: Bug
> Components: Text extraction
> Reporter: Joel Hirsh
> Attachments: whiteonwhitetext.pdf, whitetext.pdf
>
>
> I am using PDFTextStripper and overriding processTextPosition so that I can
> test for white on white text.
> In version 1.8 I called getGraphicsState().getStrokingColor() and
> getGraphicsState().getNonStrokingColor() to get the colors and then could
> test for white on white text.
> In version 2.0 I am making the same calls on the same file, but the PDColor
> returned for both methods never changes from PDColor{components=[0.0],
> patternName=null}
> In the attached file, there is some white text '661.37' just above and to the
> left of the 2.00. Can find it in Acrobat by searching or careful selecting
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
