Menu
▾
▴
#570 PNG export locale dependence
In http://trac.sagemath.org/ticket/17940 I found that JMol sometimes creates broken PNG files. More precisely it does so in March in Germany, due to the fact that the Creation Date contains the string "Mär" which causes an incorrect chunk length.
Looking at the sources, I see indeed that PngEncoder.writeText does write the result of String.length() (i.e. UTF-16 code unit count) as the hunk size. This is not equal to the number of bytes in non-ASCII locales.
Looking at the underlying CRCEncoder.writeString I see that this is using String.getBytes(), with no arguments, i.e. it uses system locale for string encoding. Which might be anything. The PNG specification requires UTF-8 for iTXt chunks.
But the chunk is not really formatted as iTXt even apart from this encoding issue. It lacks several null bytes used as separators or flags in the corresponding section of the PNG standard. So perhaps you meant that chunk to be tEXt instead? In that case, the chunk type would have to be tEXt and the string encoding would have to be latin1.
If you want to avoid performing a byte count or worrying about locales which don't map to latin1, then you might consider formatting the creation date in a locale-independent manner.
Good catch. Indeed, this was not supposed to be iTXt. Fixed by changing to tEXt and also date format ISO 8601 http://en.wikipedia.org/wiki/ISO_8601, which is a simple string. 2015-03-11T13:23:51