Snapshot available at
https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox-app/3.0.4-SNAPSHOT/
it does not yet have an updated javadoc, nor a constant (not sure if
needed), just pass -1, please test it and confirm that it does what you
want. If you set logging level to debug then it will output the dpi for
every page.
Tilman
On 28.11.2024 19:52, Tilman Hausherr wrote:
Hi,
I've created https://issues.apache.org/jira/browse/PDFBOX-5911 and
I'll work on it tomorrow or on the weekend and will tell here when
there's a snapshot version so you can test it.
Tilman
On 28.11.2024 17:18, Kevin Day wrote:
PS Tilman - I think we are on the same page about the auto-rasterize, I
just suggest -1 instead of max integer. Either would be fine. (and I
agree,
changing the API footprint should be avoided)
PPS you wouldn't believe how many trees I have killed trying to
figure this
out... My office looks like 1985 with paper all over my desk.
On Thu, Nov 28, 2024, 9:01 AM Kevin Day <ke...@trumpetinc.com> wrote:
Thanks for responding.
I know my initial email was long, sorry. Let me summarize:
If we print the entire sample document non-rasterized to *some* (but
not
all) printers, page 4 only partially prints. If we print to other
printers,
it prints fine. If we print just page 4, it prints fine.
My guess is this is something weird deep in the Java print stack.
What I am proposing is a small additional functionality related to
the dpi
parameter:
If dpi is set to 0, then use current behavior (non rasterized).
If dpi is set to > 0 create raster using that explicit dpi - current
behavior.
If dpi is set to -1 (introduce a constant RASTERIZE_AUTO), compute the
raster dpi dynamically from the affine transform sent by the printer.
This should be a *very* surgical enhancement (probably less than 5
lines
of code), and preserves all existing behavior. I'm happy to provide a
patch that does this, if you will accept it.
The reason this is needed is that it is almost impossible to
determine the
dpi of a printer from Java. If someone has a way to do this, I will
gladly
do that - but I've spent hours digging through the JRE source, and
there
isn't a way to get at the print job resolution values without doing
unsafe
operations.
(And yes, please ignore my suggestions about optimization by caching
- I
agree it is not worth introducing risk).
Thanks again,
K
On Thu, Nov 28, 2024, 7:12 AM PDF Developer <pdf...@yahoo.com.invalid>
wrote:
My mistake - apologies.
It printed from my Linux machine with PDFDebugger v3.03.
- Linux MintBook 5.15.0-125-generic-
/usr/lib/jvm/jdk-22-oracle-x64/bin/java java version "22.0.1"
2024-04-16
On Thursday, November 28, 2024 at 12:34 PM GMT, Tilman Hausherr <
thaush...@t-online.de> wrote:
On 28.11.2024 13:04, PDF Developer wrote:
I concur. Printed fine from Acrobat (Windows 10) using the default
printer driver.
That was never a problem, the problem is with printing from PDFBox.
This
can be tested with the PDFDebugger / debug or with PrintPDF / print
commands.
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: users-h...@pdfbox.apache.org
