xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Re: Batik Under OS X 10.1
Date Mon, 01 Oct 2001 13:12:13 GMT
>>>>> "JA" == Jeff Adams <jeffa@coursewave.com> writes:

JA> 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. 

   Similarly, I'm still trying to get my hands on a copy of Mac OS X.

>> Sure enough, it is fixed - but now I have two even worse problems.
>> (a) Text doesn't work - characters come out as rectangles [...]

   Hmm, this is a new one.

>> (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.

   This is probably some of the continuing Raster issues, hard to tell
if it has gotten better or worse, or stayed about the same.

>> Any help would be appreciated - I've been waiting a long time to
>> get batik working under OS X.


JA> [NOTE: I cc-ed Apple's Java Dev list here in case anyone there can
JA> possibly shed some light for Batik developers]

JA> Following up on my plans to debug this more in OS X within
JA> JBuilder I have noted the following:

    Thanks for taking the time to do this tracking...

JA> - Upon parsing and rendering of barChart.svg I get the following
JA> low-level errors in the console:

JA> ...  Load started...  Load completed in 7753 ms Build started...
JA> Build completed in 2283 ms Rendering preparation...
JA> kCGErrorFailure : can't find name id 4 for font id 8424
JA> kCGErrorFailure : can't find name id 1 for font id 8424
JA> kCGErrorFailure : can't find name id 2 for font id 8424
JA> kCGErrorFailure : can't find name id 6 for font id 8424 ...

JA> However, stepping through the GraphicsEnvironment and
JA> StrokingTextPainter when they attempt to resolve fonts shows they
JA> are successfully creating gvtFonts for Arial and Helvetica in this
JA> case...

    Hmm, if I had to guess the problem is that it finds the font but
for some reason it can't match our requests for glyphs with the glyphs
in the font, so it prints the above diagnositc and uses the 'missing
glyph' outline (the box), so our GlyphVector gets filled with missing
glyphs, this would be correct behaviour if we were asking for nonsense
glyphs, which I suppose is possible, if for example there is supposed
to be a translation step you go through but for Solaris, Linux, and
Win32 it's the identity function, but isn't for MacOS.

    Have you tried some of the SVGFont tests to see if they work
properly?  They are the samples/tests/font*.svg tests.

    I'm guessing they will work fine since it doesn't use the JDK font
stuff for very much, but if they fail as well it might be very

JA> So as far as I can tell the failure to display text in the SVGs is
JA> sourcing from a fundamental failure to get the glyph outlines from
JA> the native Font code within sun.awt.font.NativeFontWrapper

JA> Someone else debugging might be able to correct me if I am wrong
JA> about this but it seems to be a native impl problem.

JA> I guess a simple test app requesting font glyph outlines might
JA> help lead us to determine whether this is a general failure case
JA> or perhaps in how the calls are being made in batik

    Wish I could get my hands on a 10.1 Upgrade CD to provide some
test cases for these things, anyone know when the second wave is
supposed to arrive?

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

View raw message