>>>>> "KL" == Keiron Liddle <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
