Jeremias Maerki wrote:
<snip/>
>> - it seems to me that a bit more of the internal state of
>> a PDFTextUtil object could be controlled by the object itself,
>> especially in the following piece of code (PDFTextPainter, l.220):
>> Font f = textUtil.selectFontForChar(ch);
>> if (f != textUtil.getCurrentFont()) {
>> textUtil.writeTJ();
>> textUtil.setCurrentFont(f);
>> textUtil.writeTf(f);
>> textUtil.writeTextMatrix(localTransform);
>> }
>> A signalFontUsed(f) method might make sense. Basically doing the
>> same test as above, but inside PDFTextUtil. The code would be better
>> encapsulated, so more maintainable. WDYT?
>
> Again, feel free to change and improve.
Ok. It’s just that I’m reluctant to modify code I’m not familiar with,
and from which I may have missed the logic.
>> - in PDFTextPainter: now that the code is working, you probably want to
>> remove the DEBUG variable and all the statements displaying stuff to
>> System.out; or replace them with proper log.debug statements ;-)
>
> No, I don't. The debug code is most probably optimized away by the
> compiler so it doesn't bother us at runtime. If any bugs arise, it's
Except if the DEBUG variable is left to true...
> convenient to switch on. Most importantly, though, the Batik guys have
> indicated that they don't want to work with a logging framework. Since
> this code is destined to go to Batik I try not to introduce more Commons
> Logging in this area.
Vincent
