At 6:22 PM -0400 9/29/01, David Mundie wrote: >Among the reasons I eagerly awaited OS X 10.1 was the hope that the >Batik streaking problem under 10.0 would be gone. Sure enough, it is >fixed - but now I have two even worse problems. > >(a) Text doesn't work - characters come out as rectangles and I get gobs of > >kCGErrorFailure : CGGStackRestore: gstack underflow. > >errors. > >(b) The images are truncated on the left and the top. It looks like >about a quarter of the image is missing on those two edges. > >Any observations or recommendations? I have placed samples of my >converted images at > >http://www.anthus.com/Work/moonPhases.png > >and > >http://www.anthus.com/Work/textRotate.png > >Any help would be appreciated - I've been waiting a long time to get >batik working under OS X.
[NOTE: I cc-ed Apple's Java Dev list here in case anyone there can possibly shed some light for Batik developers] Following up on my plans to debug this more in OS X within JBuilder I have noted the following: [NOTE: some of this might only be useful to either Batik or Apple Java implementors as it delves quite a bit into the org.apache and com.apple classes] Running the org.apache.batik.apps.svgbrowser.Main within JBuilder under MacOS X 10.1 I see the following when I open the sample barChart.svg: - Upon parsing and rendering of barChart.svg I get the following low-level errors in the console: ... Load started... Load completed in 7753 ms Build started... Build completed in 2283 ms Rendering preparation... kCGErrorFailure : can't find name id 4 for font id 8424 kCGErrorFailure : can't find name id 1 for font id 8424 kCGErrorFailure : can't find name id 2 for font id 8424 kCGErrorFailure : can't find name id 6 for font id 8424 ... However, stepping through the GraphicsEnvironment and StrokingTextPainter when they attempt to resolve fonts shows they are successfully creating gvtFonts for Arial and Helvetica in this case... The interesting part happens when outlines are finally requested for the glyph text runs that exist... Stepping through this area, specifically down to the call to Shape glyphOutline = awtGlyphVector.getGlyphOutline(glyphIndex); in getGlyphOutline() line 316 in org.apache.batik.gvt.font.AWTGVTGlyphVector leads to the following chain of calls: getGlyphOutline() line 386 in sun.awt.font.StandardGlyphVector getGlyphOutline() line 1354 in sun.awt.font.NativeFontWrapper ... And as far as I can tell looking at the point coords and operators that come back. This is returning the same (i believe rectangle drawing) coords independent of the glyph being requested. So as far as I can tell the failure to display text in the SVGs is sourcing from a fundamental failure to get the glyph outlines from the native Font code within sun.awt.font.NativeFontWrapper Someone else debugging might be able to correct me if I am wrong about this but it seems to be a native impl problem. I guess a simple test app requesting font glyph outlines might help lead us to determine whether this is a general failure case or perhaps in how the calls are being made in batik Even checking the latest release notes for this Java 1.3.1 VM for 10.1 http://developer.apple.com/techpubs/macosx/ReleaseNotes/JavaGMWebReleaseNotes.html does not show any hints to get this to succeed, trying the various com.apple property settings also did not improve anything... Is there anyone with more knowledge of the font impl within the 10.1 JVM who can elaborate more on the bug or a possible workaround? Thanks Jeff -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
