xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Re: svg font clipping
Date Tue, 18 Jun 2002 11:40:13 GMT
>>>>> "KL" == Keiron Liddle <keiron@aftexsw.com> writes:

KL> On Tue, 2002-06-18 at 08:28, Vincent Hardy wrote:
>> > No, it's not a trivial change (I've played with removing methods
>> > enough to be fairly sure I know what the dependencies are).  My
>> > preference is actually to rationalize the TextPainter interface but
>> > FOP probably wouldn't like that.... :)
>> If we do what you have done for the method name change (implement
>> old and new methods for 1 release and then remove the old methods,
>> all that after sending a warning to the list) and make sure that
>> Keiron sees the warning message :-), then it seems ok to me to go
>> that route, but let's see what Keiron think, this may cause more
>> pain in FOP than I realize.

KL> Sooner is better than later :)

KL> Those methods are not implemented properly anyway. It relies on
KL> the StrokingTextPainter to sort these those values out.  I am
KL> hoping to improve the text painter use anyway, so that it properly
KL> selects to stroke or not depending on the text element. Currently
KL> it does a rather poor job, I noticed the bug while I was making a
KL> test example of various types of text elements.

    What is the current state of FOP + Batik?

    So, if cvs FOP will not currently work with cvs Batik, and given
your statements above I would feel that I have a fairly free hand to
muck with the TextPainter interface (and not do the duplicate methods
thing - which would be ugly since I would ideally want to 'repurpose'
existing method names to be consistent with the rest of GVT).

    However, if cvs FOP will currently work with cvs Batik.  Then I
would not want to break what is currently working (so I would
duplicate methods for at least a release).

    As for sooner, I don't think it would make it for 1.5B3 but
probably shortly there after.

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

View raw message