[rfc-i] Data point [Re: Fwd:I-D ACTION:draft-hoffman-utf8-rfcs-03.txt]
julian.reschke at gmx.de
Tue Oct 7 11:54:24 PDT 2008
Joe Touch wrote:
> Julian Reschke wrote:
>> You're the expect on Word (here). Are you saying that you can use it to
>> generate ASCII, but not UTF-8?
> Correct. The issue is the print driver.
I figured that out myself in the meantime as well.
> I have a path for ASCII that I use regularly. Printing is native
> (Wordpad). Viewing is native (Wordpad). Editing is a 3-step process
> (edit in Word, print via generic/text-only, filter output to generate
> FFs), and editing is WYSIWYG. Page boundaries in Word are output as a
> token that a script converts to FFs; FFs are interpreted correctly by
> I have no similar path for UTF-8, at least not yet - the tools I use
> today that preserve page boundaries (only Wordpad) fails on UTF-8 - it
> renders them fine on the screen, but when I print them, they are
> corrupted (they print as if the content is ASCII).
So, the inability of your preferred tool chain to produce UTF-8 is a
reason not to *allow* it?
Keep in mind that nobody is *requiring* use of UTF-8 (that would be
silly anyway because any given ASCII text/plain document *is* a UTF-8
text/plain document by definition).
I think it's totally acceptable to allow an extension that helps with
I18N, even if one of the tools in use to produce RFCs doesn't support it.
More information about the rfc-interest