On Fri, Sep 15, 2006 at 03:54:12PM +0200, Georg Baum wrote: > 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.
Maybe. > >> 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? Because isprint would not fail in a locale aware environment when the locale is iso-8859-1 and its argument is 246 (รถ). However, I found that not all non-ascii chars cause problems and I can't understand why. -- Enrico
