@bberenz the PDF crash bug is causing clients to use DPI work-arounds.
Although this works great, they don't always know the DPI of the printer they're printing to.
I think we need a new param rasterize: true for Pixel printing which -- in the case of a PDF -- will auto-sense the DPI of the printer and use that when the rasterize: true parameter is provided. Setting a dpi would naturally force this parameter to true as well.
This will have the benefit of auto-scaling to the desired paper using the rendering of the PDF without knowing the DPI, thus completely circumventing the PDF printing bug for the 2.0 release.
Should be safe to always default to true for other Pixel jobs, since HTML and Images are already rasterized anyway.
Then for those non-Mac shops that want PDF vector printing (or HTML if JavaFX ever adds it down the road), they can set rasterize: false and allow the data to be sent in a more native/preferable flavor.
@bberenz the PDF crash bug is causing clients to use DPI work-arounds.
Although this works great, they don't always know the DPI of the printer they're printing to.
I think we need a new param
rasterize: true
for Pixel printing which -- in the case of a PDF -- will auto-sense the DPI of the printer and use that when therasterize: true
parameter is provided. Setting a dpi would naturally force this parameter to true as well.This will have the benefit of auto-scaling to the desired paper using the rendering of the PDF without knowing the DPI, thus completely circumventing the PDF printing bug for the 2.0 release.
Should be safe to always default to
true
for other Pixel jobs, since HTML and Images are already rasterized anyway.Then for those non-Mac shops that want PDF vector printing (or HTML if JavaFX ever adds it down the road), they can set
rasterize: false
and allow the data to be sent in a more native/preferable flavor.-Tres