Hi,
Am 09.01.2016 um 13:27 schrieb Tilman Hausherr:
It really depends on what java printing and the printer driver do... our code is
the same.
Hmmm, not really, see your comment bellow about creating an image first when
choosing a dpi instead of using 0
If I'd have a choice, I'd always use dpi=0 which will take the native printer
resolution. This can be higher than 600dpi.
I agree, especially as we can't blow up the dpi of the given print graphics,
e.g. the default dpi of CupsPDF printer driver on linux is 300 dpi
Yes, using a specific dpi means that the print job will get bigger and bigger.
Doing that means that an image is created first, and that one is rendered.
That are two possible issues with that approach (create an image first and print
that to the printer graphics device as a whole)
First of all the printer graphics may by at a lower resolution as the image
itself (300dpi vs. 600 dpi), so that some may be some quality loss when
downsizing the image to the lower resolution.
More important is a possible second effect. If dpi = 0 is used all painting is
done directly to the printer graphics device which produces a vectorized pdf (at
least in my case using the CupsPDF printer driver and I guess it's the same with
the XPS driver). Such a vectorized pdf can be scaled easily to any resolution.
If dpi > 0 is used an intermediate image with the given dpi is created and
printed as whole to the printer graphics device which produces a pdf consisting
of one single image which can't be scaled without quality loss.
Saying that, to choose another dpi resolution than the default IMHO makes sense
only if rendering to an image for further usage other than printing.
I tried printing from PDFDebugger which uses default settings (dpi = 0) and can
confirm that the color parts look blurry in XPS. (Btw these are NOT images, the
only image is the printer symbol) However I did it with CIB PDF brewer (i.e. I
printed to a PDF file) and it looks fine. I also tried to print the XPS file
with CIB but then I got a null pointer error, so I can't test that one (this is
a bug in XPS or in CIB). I wanted to do that to find out whether the contents of
the XPS file are bad, or just the display. Please try this yourself. A software
similar to CIB is e.g. PDF Creator.
And maybe the XPS driver is a third reason for an issue in the given use case.
Tilman
Am 08.01.2016 um 16:46 schrieb Tres Finocchiaro:
Correction....
To be able to represent this visually, I've taken the following picture of
a rendering done using each approach and sent to the XPS Document writer:
** *http://i.imgur.com/nBaaJoP.png *(i had incorrectly marked each
rendering)*
- [email protected]
On Fri, Jan 8, 2016 at 10:44 AM, Tres Finocchiaro <
[email protected]> wrote:
Hi,
I'm trying to determine the best way to achieve high resolution PDF
printing with PDFBOX 2.0.
Our programmer recently wrote some logic to use PDFPrintable but I noticed
the fonts were rasterized, so I started converting the code to use
PDFPageable instead (since we had upgraded from a system which used
silentPrint()). However, I'm having mixed results.
What I've found is:
- When DPI (such as 600dpi) is provided as a parameter to PDFPageable,
the images render much nicer, but the fonts get rasterized.
- Rasterizing the fonts seems to make the print job much, much
larger.
- Rasterizing the fonts is observable at a high zoom factor (not
observable to the naked eye).
- When the default DPI is provided (AFAIK, Zero, or simply omitted),
the images render quite grainy, but the fonts appear vector.
To be able to represent this visually, I've taken the following picture of
a rendering done using each approach and sent to the XPS Document writer:
http://i.imgur.com/JlTpGht.png
The PDF we're using is available for preview and download here:
https://github.com/qzind/qz-print/blob/2.0/assets/pdf_sample.pdf
So the question is, why does a higher DPI have a negative effect on
rendering? Are we not using this improperly? Thanks in advance!
-Tres
- [email protected]
BR
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
