Hi Manuel,

Manuel Mall <[EMAIL PROTECTED]> wrote on 11/01/2005 04:24:05 AM:

> On Tue, 1 Nov 2005 01:33 am, [EMAIL PROTECTED] wrote:
> >         Just an FYI, Batik also currently has an implementation of
> > the Unicode TR14 word breaking alg.
> > (org.apache.batik.gvt.flow.TextLineBreak).

> Thomas, thanks for the pointer (Note to myself - need to become more 
> aware of what's in the Batik code base. Feeble excuse - Joerg didn't 
> seem to know either).

    It's a fairly recent addition, to support proposals for flowing 
text in SVG 1.2.

> Had a look at the Batik code: Same algorithm as Joerg wrote (not 
> surprising as UAX#14 actually contains real C code) very similar data 
> structures internally. Data structures are hard coded and not generated 
> from the Unicode text files. 

   I would not think it would be worth the while to parse the Unicode
files on startup every time (they aren't small).  Passing in the table
mapping chars to types might be a useful extension (but in honesty
I doubt .5% of users would ever provide their own, unless the code
only included say Western Language by default).

> The API is different, especially it relies 
> on Batik specific types being passed across not just plain Strings (but 
> this could probably be handled by a wrapper).

   AttributedString (the type passed across the interface) is a
JDK class: java.text.AttributedString.  We do define now attributes
(keys) to hang the word break info off of.

> This probably strengthens the argument of making all of this part of 
> XMLGraphics Common....grumble...grumble...

   Yes, this is mostly why I mentioned it.  On the other hand the
code is not that large or really overly complex.

> My main reason for hesitation with the XMLGraphics Common approach is 
> simple man power. We need to setup the infrastructure (subversion, 
> mailing lists, web site, etc.). We need to maintain this. 

   Sure, some of this will happen anyway because of the current 
problems we have with the PDFTranscoder (Batik depends on FOP which
depends on Batik :( ).  Those dependencies need to be straightened

> We would basically would publish APIs currently internal to Batik 
> and FOP with all the resultant support headaches. For example, 
> I would not like to see my time diluted in the moment by having 
> to discuss API needs outside of FOP/Batik. 

   Yes, this is the big issue, as soon as an API becomes public
it is a lot more work to maintain it. 

> Actually I am reluctant to even dive into the Batik code base 
> in the moment. FOP is complicated enough to digest.

   The hope is that by exposing some of these API's we will 
attract some people as contributors that would otherwise be 
'scared off' by the size and complexity of the FOP and
Batik code bases.

Reply via email to