[rfc-i] Data point [Re: Fwd:I-D ACTION:draft-hoffman-utf8-rfcs-03.txt]

Julian Reschke julian.reschke at gmx.de
Tue Oct 7 12:42:22 PDT 2008

Joe Touch wrote:
>> 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.

You need a script that finds the boundaries, and inserts the right kind 
off CSS-for-print styling.

tools.ietf.org has been doing this for a long time now (again: see 

> How do I take draft-hoffman-utf8-rfcs-03.txt and print it out preserving
> page boundaries AND UTF-8 characters in Vista?

Run it through the same script 
(<http://tools.ietf.org/tools/rfcmarkup/>), and open the HTML in a browser.

>> 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.

So if I find 10 sites that claim that Microsoft Word sucks, would that 
stop you from using it?

> 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.

So we really need to stop using text/plain, as inserting form feeds is 

>> 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
> time).

It's a matter of taste. You won't convince me that Word is superior. I 
won't convince you that XML is superior.

>>> 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?

No, I just mentioned another path, as you seem to like Word.

>> I think it's agreed that *displaying* the RFC is simple (just use a web
>> browser),
> Not preserving page breaks. Open your browser, and do a print preview to
> see why.

Try It.

>> 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.

I just tried and it doesn't work. What steps do I need to follow to get 

>> 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 just tried it and it didn't work for me. Maybe my printing defaults 
are different -- the default layout I get is to narrow (lines break that 
shouldn't) and not long enough (footers appear on the next side).

>> 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.


Why can't we just rely on a format and software that's the base of the 
WWW. It *does* work.

> ...

BR, Julian

More information about the rfc-interest mailing list