Keiron, Keiron Liddle wrote: > > Hi all, > > The main issue for me in this situation is not the actual change of > interface but the problem of the getWidth (and some others) method which is > no longer implemented. >
OK: thanks for telling us what your top priority is. I think Thierry was planning to get back to you on how to deal with getWidth() as I beleive he thinks you could get things done another way, but I'll let him speak for himself. Could you give us a list of the other method which are temporarily not implemented? This would let us prioritize which methods we should tackle first when Stephane comes back. > Ideally I want to change to batik1.1 when it is available and update the > interface at the same time. Updating the interface is most likely (I hope) > a simple task. It should be. > In this case I don't think there is any need for a backward compatible > interface. The thing that I really want is the getWidth method to be > useable when batik1.1 is released. This is a runtime compatibility issue > that I was aware of soon after the change, I just haven't got around to > raising the issue, preoccupied with some other areas. I suppose it could be > useful for this sort of problem to also be made publicly known in a similar > way that the interface changes are known. > OK. > As a side note: > It would be good if the TextPainter system was easily extended so that for > simple text that can be represented in pdf we put the text directly into > the pdf and for more complicated text (effects, overline, underline etc.) > the stroking text painter could handle it. Rather than the current > situation where the stroking text painter can handle everything but makes > large pdf files, the pdf text painter only handles simple text. > I am not sure what you have in mind? An AbstractTextPainter of some sort wich template methods for simple text? Vincent. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]