Enrico Forestieri wrote: > On Fri, Sep 15, 2006 at 11:21:39AM +0200, Georg Baum wrote: >> Enrico Forestieri wrote: >> >> > The attached patch fixes the problem reported by Uwe. I am afraid but >> > with mingw/cygwin the setlocale() thing doesn't really work, so I >> > always assume iso-8859-1 (latin1). >> >> dt2dv/dv2dt should not be aware of any locale. They simply should process >> the raw data without interpretation. >> IMO the isprint test is wrong and should be dropped completely. At least >> for our usage we know that everything we put in the dtl file is OK. > > Sorry Georg, I didn't really study the dtl sources. If the author felt > necessary testing if a character was a printable one, I have to trust him > that this is the correct thing to do.
No, you don't ned to trust him, since in our case the input data is generated by dv2dt. We know for sure that it will not output anything that was not in the original DVI file. Testing for non-printable chars makes sense if the input comes from an untrusted source, but that is not the case here. >> Could you prepare & commit a patch that does this, including a comment >> why we do so? > > Hmm, without a full understanding of what could go wrong if a control > character is let in, I will not do that. Notice that the occurrence of > a non-ascii character in the body of a document has never been a problem. > The problem reported by Uwe was due to the use of non-ascii characters as > arguments of the \pdfauthor and \pdfsubject macros. The full understanding statement applies to your fix as well IMO. How do you know that dt2dv can cope with non-ascii chars at all? Georg
