Hi Thomas. Cameron McCormack: > > ▪ flowBidi, which generates a StackOverflowException in some > > java.awt.font and sun.font methods
Thomas DeWeese: > Since the other flow tests work, can you sort out what > method is causing the problem? It looks to be a bug in the 1.6 beta JRE. The call from Batik’s code is BidiAttributedCharacterIterator:121, where it creates a java.awt.font.TextLayout object. The AttributedString that’s passed to it is "Some (embedded bidi) of text.", where the text run in the parentheses has a BIDI_EMBEDDING attributed on it. I’ve filed a bug on Apple’s JRE. > > ▪ batik70 (sample problem) > > I think the stroking problem on the 'i' is just > a flaw in the Mac OS X stroker. I can't think of > anything we can do. I checked to make sure that > we add a 'close_path' in this case. > > For the background pattern I would try two things > to try and sort things out. First remove the > innerShadow filter on the ellipses. See if the > color of the pattern goes back to normal. > > Second remove the use of the pattern and try > putting a few copies of the pattern directly > over the circles (to avoid rendering to a pattern > buffer that is then composited). Ok so it seems to be something to do with the going to a buffer for the pattern. Here’s a reduced test case: <svg xmlns="http://www.w3.org/2000/svg"; width="400" height="200"> <rect width="400" height="200" fill="rgb(13, 97, 160)"/> <g fill="rgb(110, 200, 255)"> <rect x="50" y="50" width="50" height="50"/> <rect x="100" y="50" width="50" height="50" fill-opacity="0.8"/> <rect x="100" y="100" width="50" height="50" fill-opacity="0.6"/> <rect x="50" y="100" width="50" height="50" fill-opacity="0.4"/> </g> <pattern id="p" patternUnits="userSpaceOnUse" width="200" height="200" fill="rgb(110, 200, 255)"> <rect x="50" y="50" width="50" height="50"/> <rect x="100" y="50" width="50" height="50" fill-opacity="0.8"/> <rect x="100" y="100" width="50" height="50" fill-opacity="0.6"/> <rect x="50" y="100" width="50" height="50" fill-opacity="0.4"/> </pattern> <rect x="200" width="200" height="200" fill="url(#p)"/> </svg> This is how it renders: http://mcc.id.au/temp/2007/composite.png I tried to trace through the code to determine what ColorModel/WritableRaster/SampleModel are used so I could reproduce the rendering in a small test case. In the end I couldn’t, though. Do you have a Mac to test with? > > ▪ masking-mask-BE-0[56] (same problem) > > ▪ histogramNormalization (same problem) > > ▪ feConvolveMatrix (same problem) > > So there is something funny going on with > alpha handling. I wonder if we aren't falling > into our optimized code for MultiplyAlphaRed. > The other possibility is that we might be > getting the alpha pre-multipled state wrong > (or the mac jvm doesn't handle one of the > pre-multiplied states correctly). I found the main BufferedImage that the whole document is rendered to is TYPE_INT_ARGB_PRE, and the pattern BufferedImage is TYPE_INT_ARGB. In my standalone test I tried painting a semi-opaque TYPE_INT_ARGB BufferedImage to a TYPE_INT_ARGB_PRE one, but it worked properly. > > The text ones all give correct rendering with a small rotation. > > I suppose it would be an option to add a small rotation to > 'complex' texts (anything that adjusts individual glyph positions), > on Mac OS X. However since this is fixed in Java 6 I'd rather just > recommend people upgrade the JVM... Maybe we could set the rendering hint that corresponds to text-rendering="geometricPrecision" when rendering certain (or all) text. The 1.6 JRE isn’t released yet for OS X though, it’s just a beta (which can only be downloaded by signing up for Apple’s Developer Centre thingo). > > > > http://mcc.id.au/temp/t/show?mac,linearGradientRepeat > > > > > > This looks to me like it's rendering the gradient at > > > lower resolution than the reference. > > > > > > > http://mcc.id.au/temp/t/show?mac,gradientLimit > > > > Top right gradient wrong. > > > > > > Once again I wonder if it's rendering at lower resolution... > > > > Anything that could be done about these? > > I don't know, someone must be scaling the buffer we give > them for display. I don't know where that would be happening. Is it enough of a corner case to ignore? > > > > http://mcc.id.au/temp/t/show?mac,gradientPoint > > > > Gradients wrong. Got this ouptut on the console, so it may be a > VM > > > > bug: > > > > > > It looks that way, perhaps it's requesting a _huge_ gradient > > > bitmap (I noticed Mac OS X requests the entire gradient block at > > > once instead of in small tiles). > > > > > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-05 > > > > http://mcc.id.au/temp/t/show?mac,masking-mask-BE-06 > > > > Mask gradient wrong. > > > > > > Hmm, looks like the gradient opacity is being interpreted > > > 'backwards'. > > > > Strange that it?s got opacity 1 on the top scan line. > > Well it's not uncommon to have a special case for opacity==1 > since you don't need to do compositing just copy. But that > would indicate that there was something a little wonky inside > their own code. But I'm actually leaning towards the problem > being when the alpha is or isn't premultiplied (although I > must admit that I'm having a hard time understanding how > you get the result we see from that). Could be part of the same compositing problem I guess. I’m not really sure where to look though for this and the other alpha related problems. -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
