xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davis-5 <t...@robertjdavis.co.uk>
Subject Re: SOLVED Re: PNG pixel dimensions of given dpi don't correspond to original SVG mm dimensions
Date Wed, 14 May 2008 14:21:29 GMT

thomas.deweese wrote:
>    There is no way to exactly encode 300dpi with PNG.

Fair enough.

thomas.deweese wrote:
>    What it writes is a pelletized image, it picks the best two (for 1bit) 
> _colors_ it can find.  There is no guarantee that they will be black
> and white (in fact in many cases they are distinctly not black and white).
>    If you really only want black and white I would suggest replacing the
> current Batik code as it will do a _lot_ of work to give you a wrong 
> (although often close) answer.

The reason for these requests is to minimise the variation of the image when
it is sent to a printer.

For example, if the dpi is different from the printer dpi then the printer
may perform some sort of dithering where graphical elements lie on pixel
boundaries. I want to avoid this. However I am satisfied with your answer; I
don't think that 299.99... dpi will be an issue.

And if the pallette is not pure black 00,00,00 and pure white FF,FF,FF then
the printer may use dithering to approximate to this. This is something that
does concern me still but I will only know once I try it out. Again perhaps
it is not an issue.

View this message in context: http://www.nabble.com/PNG-pixel-dimensions-of-given-dpi-don%27t-correspond-to-original-SVG-mm-dimensions-tp17212289p17232271.html
Sent from the Batik - Users mailing list archive at Nabble.com.

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message