Jeremias Maerki wrote:
>>   - 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.


Reply via email to