You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Werner Guttmann <we...@indoqa.com> on 2012/05/15 10:40:37 UTC
SVG to PNG transcoding and phaysical image sizes
Hi,
in one of our projects, we are currently using the PNGTranscoder to
produce a PNG from an SVG, and everything works just fine (in terms of
expected output, content, ...). As part of some recent testing, we came
to realize that the PNGs produced are of differing physical byte sizes
on different machines.
E.g. a PNG image of dimension 1620x1118 px one one box has a size of
10,836 bytes, whereas a second server produces 10,864 bytes worth of PNG
from the very same SVG (using the very same binary and thus process). Is
this something we should be expecting, and if so, why is this the case ?
Just some more contextual information:
- We tried this with Java 6u27, 6u31 and 6u323, and it looks like
switching between Java version on any given host does not make any
difference.
- The servers in question run a variety of OS, incl. Windows 8, Linux
Mint, Linux Ubuntu.
Any idea what might cause these effects ?
Kind regards
Werner Guttmann
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Werner Guttmann <we...@indoqa.com>.
Not really what I hoped to hear, but the answer (and its clarity) is
appreciated.
Thanks
Werner
On 15.05.2012 10:52, Dieter wrote:
> The JRE makes a lot of native calls using JNI. This functionality is
> platform-dependent and means that threading, image-encoding,
> rendering/antialiasing, etc. is slightly different for each OS.
>
> On Tue, May 15, 2012 at 10:40 AM, Werner Guttmann
> <we...@indoqa.com> wrote:
>> Hi,
>>
>> in one of our projects, we are currently using the PNGTranscoder to produce
>> a PNG from an SVG, and everything works just fine (in terms of expected
>> output, content, ...). As part of some recent testing, we came to realize
>> that the PNGs produced are of differing physical byte sizes on different
>> machines.
>>
>> E.g. a PNG image of dimension 1620x1118 px one one box has a size of 10,836
>> bytes, whereas a second server produces 10,864 bytes worth of PNG from the
>> very same SVG (using the very same binary and thus process). Is this
>> something we should be expecting, and if so, why is this the case ?
>>
>> Just some more contextual information:
>>
>> - We tried this with Java 6u27, 6u31 and 6u323, and it looks like switching
>> between Java version on any given host does not make any difference.
>> - The servers in question run a variety of OS, incl. Windows 8, Linux Mint,
>> Linux Ubuntu.
>>
>> Any idea what might cause these effects ?
>>
>> Kind regards
>> Werner Guttmann
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Dieter <di...@googlemail.com>.
The JRE makes a lot of native calls using JNI. This functionality is
platform-dependent and means that threading, image-encoding,
rendering/antialiasing, etc. is slightly different for each OS.
On Tue, May 15, 2012 at 10:40 AM, Werner Guttmann
<we...@indoqa.com> wrote:
> Hi,
>
> in one of our projects, we are currently using the PNGTranscoder to produce
> a PNG from an SVG, and everything works just fine (in terms of expected
> output, content, ...). As part of some recent testing, we came to realize
> that the PNGs produced are of differing physical byte sizes on different
> machines.
>
> E.g. a PNG image of dimension 1620x1118 px one one box has a size of 10,836
> bytes, whereas a second server produces 10,864 bytes worth of PNG from the
> very same SVG (using the very same binary and thus process). Is this
> something we should be expecting, and if so, why is this the case ?
>
> Just some more contextual information:
>
> - We tried this with Java 6u27, 6u31 and 6u323, and it looks like switching
> between Java version on any given host does not make any difference.
> - The servers in question run a variety of OS, incl. Windows 8, Linux Mint,
> Linux Ubuntu.
>
> Any idea what might cause these effects ?
>
> Kind regards
> Werner Guttmann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Dieter <di...@googlemail.com>.
Hi Werner, Thomas,
we are actually using our own solution for text-layout (incl. kerning)
and text-rendering. It should be pixel-identical on every platform
although I haven't tested it. Maybe you want to build something
similar to work around your problems.
Cheers,
Dieter
On Wed, May 16, 2012 at 9:17 PM, Thomas DeWeese
<th...@gmail.com> wrote:
> Hi Werner,
> Yes, text renders differently on different platforms, and yes this is
> very annoying, and no I don't know of anyway to work around it.
> It causes all sorts of headaches with the Batik automated testing system (it
> more or less means that you need a set of reference images for
> every platform).
>
> Thomas
>
>
> On Wed, May 16, 2012 at 2:27 AM, Werner Guttmann
> <we...@indoqa.com> wrote:
>>
>> No, I haven't yet (and will), but it looks like the problem seems to be
>> with some SVG text elements and their rendering on various platforms.
>>
>> Thanks
>> Werner
>>
>>
>> On 15.05.2012 19:05, Joel Uckelman wrote:
>>>
>>> Thus spake Werner Guttmann:
>>>>
>>>> Hi,
>>>>
>>>> in one of our projects, we are currently using the PNGTranscoder to
>>>> produce a PNG from an SVG, and everything works just fine (in terms of
>>>> expected output, content, ...). As part of some recent testing, we came
>>>> to realize that the PNGs produced are of differing physical byte sizes
>>>> on different machines.
>>>>
>>>> E.g. a PNG image of dimension 1620x1118 px one one box has a size of
>>>> 10,836 bytes, whereas a second server produces 10,864 bytes worth of PNG
>>>> from the very same SVG (using the very same binary and thus process). Is
>>>> this something we should be expecting, and if so, why is this the case ?
>>>
>>>
>>> That's not many bytes difference. Have you compared the PNGs in a hex
>>> editor? It could be that one of the metadata fields has some system-
>>> specific information in it.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Thomas DeWeese <th...@gmail.com>.
Hi Werner,
Yes, text renders differently on different platforms, and yes this is
very annoying, and no I don't know of anyway to work around it.
It causes all sorts of headaches with the Batik automated testing system
(it more or less means that you need a set of reference images for
every platform).
Thomas
On Wed, May 16, 2012 at 2:27 AM, Werner Guttmann <werner.guttmann@indoqa.com
> wrote:
> No, I haven't yet (and will), but it looks like the problem seems to be
> with some SVG text elements and their rendering on various platforms.
>
> Thanks
> Werner
>
>
> On 15.05.2012 19:05, Joel Uckelman wrote:
>
>> Thus spake Werner Guttmann:
>>
>>> Hi,
>>>
>>> in one of our projects, we are currently using the PNGTranscoder to
>>> produce a PNG from an SVG, and everything works just fine (in terms of
>>> expected output, content, ...). As part of some recent testing, we came
>>> to realize that the PNGs produced are of differing physical byte sizes
>>> on different machines.
>>>
>>> E.g. a PNG image of dimension 1620x1118 px one one box has a size of
>>> 10,836 bytes, whereas a second server produces 10,864 bytes worth of PNG
>>> from the very same SVG (using the very same binary and thus process). Is
>>> this something we should be expecting, and if so, why is this the case ?
>>>
>>
>> That's not many bytes difference. Have you compared the PNGs in a hex
>> editor? It could be that one of the metadata fields has some system-
>> specific information in it.
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: batik-users-unsubscribe@**xmlgraphics.apache.org<ba...@xmlgraphics.apache.org>
> For additional commands, e-mail: batik-users-help@xmlgraphics.**apache.org<ba...@xmlgraphics.apache.org>
>
>
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Werner Guttmann <we...@indoqa.com>.
No, I haven't yet (and will), but it looks like the problem seems to be
with some SVG text elements and their rendering on various platforms.
Thanks
Werner
On 15.05.2012 19:05, Joel Uckelman wrote:
> Thus spake Werner Guttmann:
>> Hi,
>>
>> in one of our projects, we are currently using the PNGTranscoder to
>> produce a PNG from an SVG, and everything works just fine (in terms of
>> expected output, content, ...). As part of some recent testing, we came
>> to realize that the PNGs produced are of differing physical byte sizes
>> on different machines.
>>
>> E.g. a PNG image of dimension 1620x1118 px one one box has a size of
>> 10,836 bytes, whereas a second server produces 10,864 bytes worth of PNG
>> from the very same SVG (using the very same binary and thus process). Is
>> this something we should be expecting, and if so, why is this the case ?
>
> That's not many bytes difference. Have you compared the PNGs in a hex
> editor? It could be that one of the metadata fields has some system-
> specific information in it.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVG to PNG transcoding and phaysical image sizes
Posted by Joel Uckelman <uc...@nomic.net>.
Thus spake Werner Guttmann:
> Hi,
>
> in one of our projects, we are currently using the PNGTranscoder to
> produce a PNG from an SVG, and everything works just fine (in terms of
> expected output, content, ...). As part of some recent testing, we came
> to realize that the PNGs produced are of differing physical byte sizes
> on different machines.
>
> E.g. a PNG image of dimension 1620x1118 px one one box has a size of
> 10,836 bytes, whereas a second server produces 10,864 bytes worth of PNG
> from the very same SVG (using the very same binary and thus process). Is
> this something we should be expecting, and if so, why is this the case ?
That's not many bytes difference. Have you compared the PNGs in a hex
editor? It could be that one of the metadata fields has some system-
specific information in it.
--
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org