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, email: [EMAIL PROTECTED]



Reply via email to