On 12.03.2010 01:11, Martin Rex wrote:
Jorge Amodio wrote:
I'd potentially agree if the format we actually use wouldn't have useless
page breaks that leave 25% of the pages unused. At least over here. I'd also
agree if that format would actually be usable on small devices like ebook
readers (where it's essential that you can reflow the text).
Agree, lot of white space.
Actually, the page breaks _are_ useful. Like when referencing specific
parts/paragraph in a document with an URL in a long section, e.g.
http://tools.ietf.org/html/rfc5246#page-36
which contains the message flow of a full TLS handshake.
And that message flow is just perfect in ASCII arts.
That URL points to an HTML document, not a TXT document. There is
(unfortunately) no fragment identifier syntax for text/plain (at least
not one that UAs actually support)
And guess what: if we go directly to HTML, we'd have anchors as well,
but not only for section numbers, but also figures, tables, or even
individual paragraphs.
Discussing parts of documents that are not ASCII text is extremely
difficult on IETF mailing lists and wastes huge amounts of network
bandwith if put in graphics attachments.
That's a argument about image formats, which is orthogonal. Just because
other formats would *allow* more complex graphics formats doesn't imply
we would have to use them.
Unicode characters are also a Royal PITA in specs, because they're
non-discussable. There are extremely few people who can recognize
"non-discussable"?
all unicode codepoints from their glyphs (and a number of them
can not be distinguished by their glyphs), and even worse, most
machines/environments do not even have fonts to display glyphs
for most of the unicode codepoints.
That is an argument for not allowing *all* Unicode characters.
Having stuff that can only be copy&pasted for a large part of
the internet population, but neither typed nor displayed is
nothing that we need in our specs.
Using HTML or PDF for RFCs is about the same as moving from
English language RFCs to mandarin language RFCs. There is
a huge number of people who can read it, but there is a
also a large number of current RFC and I-D consumers and
producers which can not and does not want to use mandarin.
Sorry? Are you implying anybody is unable to display HTML?
I do not doubt that there are tools available for heavy graphical
user interfaces and specific platforms that can deal with mandarin
just fine. But I do not understand mandarin, my tools can not cope
with it and a lot of my platforms and my environments can not cope
with it. HTML and pdf are only marginally better than mandarin.
Sorry? With all due respect, but this statement is really ridiculous; at
least in the context of HTML.
Btw. printing out I-Ds and RFCs on paper (even 2-up and double sided)
has always been working just fine for me with tools like a2ps.
Sounds great if you have a Postscript printer.
However, what typically happens is: open in browser, print, fail. Ask
for advice, and if you're lucky get pointed to a program that
understands form feeds in text/plain, such as Wordpad. Retry. Get a
printout with large parts of the page being empty (depending on local).
Printing out HTML is a royal pain and waste of paper. I don't know
what it is, but in 80% of the time when I print out Web content,
content is cut off at the right side (for both MSIE and Firefox
on Windows).
Yes, there are bugs. And yes, there is complex HTML out there that is
tricky to print.
Use something simple, such as the HTML produced by rfc2html or
rfc2629.xslt, and there shouldn't be a problem.
Printing PDF works, but reading PDF on screen is a royal PITA.
Yes.
Even with a 1600x1200 screen, displaying a single page is
The concept of a "page" is part of the problem - for the current format
as well. "Pages" are good when the primary output format is paper, and
the paper size is known in advance. Today, that's the edge case.
difficult to achieve -- and hardly legible with many PDFs that
I've come accross--and if you choose a legible size, then the page
doesn't fit and you have to page down to see the bottom of the page.
Getting 62 lines of pure ascii text with a legible font displayed
on a 1024x768 screen is much easier and much more legible.
And doing a 2-up of an RFC or I-D has a predictable legibility.
...
How is that different for (a properly selected subset of) HTML?
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf