Am Mit, 2003-08-20 um 01.31 schrieb [EMAIL PROTECTED]: > Transcoding is a no-brainer, if that is a problem a simple one-liner can > convert to whatever you want.
I'm talking about the XSLT processors; sure a small perl/python/bash script will recode all generated HTML files in a directory, but as this does not seem necessary at the moment, I don't see a good reason to insert another step in the chain. > > unfortunately quite a few browsers cannot properly display the former. > That's highly interesting. Even the venerable netscape-4 can properly > display documents in utf-8, even utf-7. The IEs had troubles until somewhen (haven't checked for quite some time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser. And I'm not sure about lynx and w3c either. Usually one doesn't notice because ASCII is directly representable in the lower 7 bits UTF-8 and what more does a good American citizen need? :) > (and in any case, just convert to latin1 and you have universal support). Guess what we're using right now... :) I know UTF-8 is highly useful, but since it's just the flip of a switch and we don't really need it at the moment, it's causing more troubles than benefits. So I'd rather hold off with generating UTF-8 output for now. Input is a completely different matter, but I think right now the technical barrier to writing documentation is already high enough to require the writers to have a UTF-8 compatible environment. Since the charset is choosable on a file-by-file base anyways I don't see any problem using this feature for languages that need it. :) -- Servus, Daniel
Description: Dies ist ein digital signierter Nachrichtenteil