Sorry for the length of this note.
This note is to prepare people for an upcoming commit. I have modified the way the text bridge works to improve the performance of text. I can provide the patch for current CVS to anyone who is interested.
I will hold off on committing this until I get some feed back from others but it's a fairly important improvement over the current architecture.
Batik still passes all of it's regression tests. However FOP's PDF transcoder will have issues because it accesses the Attributed string properties in it's replacement TextBridge (see below). This brings me to my question. How would people feel about moving the PDFTranscoder and associated special purpose bridges to Batik?
I think this would help a lot of the ongoing issues we have had keeping FOP/Batik in sync. The major interface between FOP/Batik should generally be at a higher level. The real problem is that there will be a circular dependency that needs breaking. Batik uses FOP's PDF Graphics for PDF output (and that uses at the very least FOP Font stuff), and FOP FO uses Batik to render SVG. I don't know how to resolve this right now but it seems like the right thing to do eventually.
Anyway onto the gritty details:
In the past the Batik Text Bridge would annotate the text element with individual properties for fill (FOREGROUND), stroke (STROKE_PAINT), stroke-width, underline/overline, etc (around 12 in total). This required relaying out the text when ever any of these properties changed because there was no way to propagate the changes through the complexities of BIDI etc. This patch replaces all those text attributes with one (PAINT_INFO) that references a TextPaintInfo object that contains all the various paint/stroke/underline etc values.
The advantage of this approach is that Batik can now swap the paint/stroke objects that the TextPaintInfo object references to change these paint attributes. This allows us to update all these paint attributes without doing any text layout just a repaint. This also allows us to avoid the current double layout when we create text elements. We currently layout once to get geometry bounds then again so we can associate the various paints (which may depend on the text bounds, like gradients).
The changes should be fairly minor in FOP (it actually generally cleans up the code a bit).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
