[rfc-i] Data point [Re: Fwd:I-D ACTION:draft-hoffman-utf8-rfcs-03.txt]
touch at ISI.EDU
Tue Oct 7 12:29:56 PDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Julian Reschke wrote:
> Joe Touch wrote:
>> Right - the one tool I had that understood ASCII, CRs, and FFs was
>> Wordpad. It worked for reading RFCs on the screen and for printing them
>> (to printers I've used, e.g., inkjets, lasers, save as PDF, PS, etc.)
>> That tool will display UTF-8 correctly on the screen, but will not print
>> the special characters properly.
>> So I can have EITHER UTF-8 special characters or FFs, but not both.
>> That's not a path forward, IMO.
> Again; use a web browser and navigate to the HTML version on
> tools.ietf.org. It will print properly.
Please explain. HTML doesn't preserve page boundaries on printout.
How do I take draft-hoffman-utf8-rfcs-03.txt and print it out preserving
page boundaries AND UTF-8 characters in Vista?
>>> At this point I'm really not sure what your point is.
>>> - LF as a line separator is a problem in Windows? Agreed.
>> Nope - it works fine in Wordpad.
>>> - It's hard to enter formfeed characters in Windows editors? Agreed.
>> Well, a fairly definitive site on how to enter FFs in UTF-8 apparently
>> gets it incorrect. I don't recall similar issues with ASCII tables being
> Formfeeds in UTF-8 are the same thing as in ASCII. I think I said so
> already, didn't I?
> So if you use the information from that very side to get info about how
> to include a form feed into ASCII, you will face the *identical* problem.
> What does that tell us? Editor support for embedding form feeds is a
> problem. That has *nothing* to do with UTF-8.
It's not editor support. It's a site that tells you how to insert FFs
that is incorrect.
The point here isn't whether the editor can do it, the point is that at
least one large reference site has incorrect information on how to do
it. That says "confusion in the community" to me.
>>> (These problems go away as soon as the author chooses one of the tools
>>> we have for the job)
>> They go away only if we chose to generate RFCs using xml2rfc, for which
>> I have yet to see a WYSIWYG editor.
> Many generate RFCs using xml2rfc without that kind of editor and can
> live with it, or even consider it a feature (less distraction).
Sure. People also create lithographs using a chisel. That's fine, but I
don't see why a 'step forward' in supporting character sets has to push
us a step backward in how we write docs. (for those of us using Word,
xml2rfc is a step backwards - about 20 years back, into nroff and scribe
>> For reading the docs, we can use Wordpad.
>> As to printing the docs, there's NO path forward yet that preserves both
>> UTF-8 and FFs.
> That is incorrect. Again: run the document through a filter to HTML, and
> print from a browser. That is one way that is known that it *will* work.
> There may be more.
No it doesn't. My browser does not understand or honor FFs.
> For instance, import it into Word and print from there.
I tried this, and it works.
So now I need commercial software to view and print RFCs in ways that
preserve page boundaries?
You're considering this a viable path?
>> At this point, I'm wondering why I'm involved in proving that UTF-8
>> can't be done on Vista. IMO, a viable proposal needs to include a test
>> coordinate by the author that involves a set of currently used common
>> platforms - i.e., the onus of proof is on them.
> I think it's agreed that *displaying* the RFC is simple (just use a web
Not preserving page breaks. Open your browser, and do a print preview to
> but that printing isn't. That's the same for both ASCII and
> UTF-8. I personally don't care at all. I don't print things anymore.
No it's not the same for ASCII. I can view and print and preserve page
boundaries in both in Wordpad, which is free on Windows.
> For ASCII, you seem to have found a solution that works for you on
> Windows. It's definitely not obvious for people who don't know already.
There are only two editors that come with Windows - Notepad and Wordpad.
If one doesn't work, and you try the other, that's not exactly obscure.
> I have told you about another one that will work both for ASCII and
> UTF-8. How many ways do we need?
You've shown me a way that works only if I use commercial software.
Again, that's a step forward? That makes RFCs more useful to the public,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the rfc-interest