Ok, I will blog about that because now I am in working time :( but for short:
if possible, and only if possible - and I have no time now for checking the side-effect in the current code: include a new constructor in the PdfStamper, that receives a java.io.Writer instead of an output stream. Just that, and of course, the underneath code should be adapted to use it instead of the stream. In case of receiving an output stream, the stamper creates an internal Writer, using the default machine encoding. The old constructor would be deprecated or at least an alert about encoding problems can be included in the javadoc :) Or not, I really don't know the effort required to change it and also if it make sense in the iText project. Meanwhile, I will publish a blog remembering the java community about the encoding traps, and giving an easy solution for legacy code that don't give the proper encoding support. It is not a critic, really, I guess iText a fantastic library and I am planning to publish a lot about its powerful features, but after 15 years of software engineering, some old topics just jump in my eyes :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
