Hi all, I've been working on a strange issue recently, this seems to affect all recent version of OpenJDK as well as Oracle JDK.
The issue appears to be related to this change: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/fbe9320339ea The issue as I could find by debugging OpenJDK is a mix of a couple of things. This change was addressing postscript size explosion, where missing font descriptor in version prior to this fix were causing characters to be rendered as paths. The new code creates an actual descriptor array, so fonts can be rendered directly by postscript. However, it seems that the postscript code assumes ISO_8859_1 encoding, so if I pass some characters with, say, umlaut, like 'ä', instead of creating a patch the character is encoded as <c3a4> (which is correct ihmo) but then mapped to ISOLatin1Encoding. This is a snippet of the generated postscript file, the file is generated using a modified verion of the PrintSE.java test in OpenJDK: http://cr.openjdk.java.net/~neugens/psDieresisBug/PrintSEUmlauts.java /ISOF { dup findfont dup length 1 add dict begin { 1 index /FID eq {pop pop} {D} ifelse } forall /Encoding ISOLatin1Encoding D currentdict end definefont } BD /NZ {dup 1 lt {pop 1} if} BD /S { moveto 1 index stringwidth pop NZ sub 1 index length 1 sub NZ div 0 3 2 roll ashow newpath} BD 12.0 12 F <c3a4> 7.44 100.0 100.0 S pgSave restore I'm not really confident with Postscript at this level, so I would like some hints of where to look for an actual fix. I have a workaround that seems to work, something like: GlyphVector gv = font.createGlyphVector(frc, "ä"); g2d.drawGlyphVector(gv, 250, 220); which basically forces the glyph path again. And of course I could revert the original change, but in either case it doesn't seem correct. My guess is that we should either somehow force ISO_8859_1 when calling CharsetString[] makeMultiCharsetString from PSPrinterJob, or have a proper fix for the Postscript file. Any idea of hint is very much appreciated. Cheers, Mario
