Hi,
Both options are related to transparency groups. These are an extension
of XObject forms. I thought about ignoring them, i.e. treat them like
ordinary forms.
So I looked at PDXobject.createXObject(); this one is called by
PDResources.getXObject(), which is called by DrawObject.process(). That
one class can officially be replaced if you extend PageDrawer and call
"addOperator(new DrawObject());" in the constructor; that class should
have a slightly modified code that does NOT call
showTransparencyGroup(), but only showForm() (there are 3 DrawObject
classes, copy the one in
org.apache.pdfbox.contentstream.operator.graphics). You can extend
PageDrawer, but you'll have to extend PDFRenderer as well, see class
comment of PageDrawer.
(I haven't tested this myself)
Tilman
Am 30.03.2022 um 16:40 schrieb Tres Finocchiaro:
Quoting:
[...] "PostScript is the grandaddy of PDF, and if you're reading about
printing you've already heard of it. It can represent text, vector graphics
and images, so if your PDF contains a vector shape it's going to be
reproduced almost exactly in PostScript. Other graphics operations (like
transparency) can't be done in PostScript, and the Java print layer handles
this by rasterizing the page to a bitmap and including that bitmap in the
spool file." - © 2012 Jonathan Cookson, bfo.com
Unfortunately this rasterization has some quality (and performance) impacts
on users, in some case very noticeable, but are often out of their control,
identified in part here:
- *PDF will only print rasterized*
https://issues.apache.org/jira/browse/PDFBOX-4123
- *PDF will only print rasterized on Windows*
https://issues.apache.org/jira/browse/PDFBOX-4380
These above issues plague users because they often have to go down a
"rabbit hole" to find out how to escalate the quality or performance
issues related to this behavior.
1. The emails start with them reaching out to the software provider
2. The software provider asks them to reach out to the PDF supplier
3. They reach out to their IT department to escalate with the PDF
supplier
4. The PDF supplier quotes something about quality in Adobe being just
fine
5. We link them to one of the above bug reports and they eventually fix
this on the PDF end.
Understanding that we can't necessarily change the "granddaddy of PDF",
please understand that in a twist of irony, these users are *nearly all
using low-dpi, black and white printers* (e.g. labels, receipts), printing
content that would *never benefit from transparency*.
That said, is there a possibility PDFBOX would be willing to add a
togglable feature to ignore the transparency? I can see two options (not
knowing how this would impact the contents of the document of course):
1. Option 1: Remove transparent objects entirely
Useful for commonly invisible components that weren't meant to be there,
or would otherwise cover content.
-- OR --
2. Option 2: Change transparent objects to opaque
Useful for components which were intended to be transparent, but would
otherwise remove information from the document if removed.
If this could be altered programmatically, the users could be given a
workaround while they await feedback from their PDF provider.
-Tres
- tres.finocchi...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
