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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
