[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt

Thomas Clausen ietf at thomasclausen.org
Fri Jun 27 09:38:11 PDT 2014


On Jun 27, 2014, at 18:18, Julian Reschke <julian.reschke at gmx.de> wrote:

> On 2014-06-27 17:58, Thomas Clausen wrote:
>> 
>> On Jun 27, 2014, at 13:31, Julian Reschke <julian.reschke at gmx.de> wrote:
>> 
>>> On 2014-06-27 12:29, Dearlove, Christopher (UK) wrote:
>>>> Now that's just deliberately insulting.
>>>> 
>>>> No one has suggested not being able to put things on an iPad.
>>>> 
>>>> However it also remains useful to put things reliably, and formatted at least to the point of not splitting things cross pages, on paper. Fanfold is just an transparent attempt to make an opinion not your own look archaic.
>>>> 
>>>> And this got raised because you may not want paper, but some of us do, and you at least now appear to be ready to steamroller those who disagree with you.
>>>> 
>>>> At the moment what appears to be on offer is
>>>> - Text, but freeflowing and not suitable (tables and figures will break).
>>>> - HTML, where some (but definitely not all) browsers might offer what you want, but at the least not guaranteed.
>>>> ...
>>> 
>>> ...it would be awesome if we could have a discussion involving "might", but based on facts.
>>> 
>>> Please try to print <http://greenbytes.de/tech/webdav/rfc7230.html> from your favorite browser and report back what you think is missing.
>> 
>> OK, I did just that, from my “favorite browser"
>> 
>> First up missing is “page numbers in the table of content”.
>> 
>> Say what you want, but telling someone to “look at page 42” is a lot easier than saying “look at section 19.3.4.12 paragraph 9”.
>> 
>> This, since page numbers (in your print-out) are nicely in the bottom right (i.e. in a fixed place) and so easy to flip to.
>> 
>> Trying to find "section 19.3.4.12 paragraph 9” means that (on paper) I’d have to scan the entire pages to see where that “anchor point” might be, since they can be everywhere — and possibly flip back and forth. A lot less ergonomic, a lot less user-friendly.
>> 
>> Now, given that I often annotate documents on a tablet….PDF readers on a tablet do often have easy-to-access “go to page” functions, whereas the “find text” is either less well supported, or is less easily accessible — for example, I can “scroll” with my finger and have the tablet flip from page-to-page, whereas I am not quite sure that I have seen a way of doing “scrolling not pages but section numbers” which would require the reader actually parsing the text and determining what is a section number…..I guess that you’d suggest that “PDF readers should, then, be updated to be better at that” — that’s a little like saying “everybody should really start using IPv6”…..20 years hence….
>> 
>> So there’s that….
>> 
>> Then, the last thing on page 12…apologies, on the thing that is on the next line….sorry, "the next sequence of characters" after the last paragraph of section 2.6 (which, incidentally, appears two pages before what I want to point to), is a section heading, which stands alone with the section text coming on the next page. That’s poor pagination.
>> 
>> It’s also - in your “war against page numbers” poor document structure, to have a section spanning multiple pages — and a good example why sections are  not granular enough to be useful as references.
>> 
>> Same thing on page 13 — I am sorry, I mean….hang on, need to count….4th paragraph (if you do not count the artwork as a paragraph — 5th if you do) in section 2.7.1 actually splits a sentence across two pages. It’d have been a lot more reader-friendly had the pagbreak been made 3 lines above, before that paragraph.
>> 
>> This sort of split-a-sentence-across-multiple-pages happens quite frequently in this document, so I am not going to point them all out. I would have, if I could have said “sentence split over multiple pages on page 3, 4, 15, 29 and 33”, though, since that would have been easy. Searching for section numbers and counting paragraphs is not. See argument above, that it is easy to identify page numbers (they are on a fixed place) and it’s easy to reference them.
>> 
>> Ah, getting to page 47, I am sorry, section 8.4.2, there’s a table. For some reason, that table does not have a table number, so fortunately there’s only one table in that section — least it’d be ambiguous. Well, in the printout, the table row “ X-gzip | Deprecated (alias for …) “ came out on top of a page, with the rest of that same table on the preceding page. Poor splitting in the output format.
> 
> Whether or not something has a table number depends on the author who wrote the XML. I usually don't want a number because I almost never refer to a specific table, but the section it appears in.

I do not want to pick particularly on you, Julian, because I *know* that what I am saying in the below is not your intent…..I am picking you *precisely* because I know it isn’t your intent — please forgive me for using you as an example here:

When making an argument such as the above, it seems that your preferences and workflow overrides mine: not adding table numbers deprives me of the ability to use them as anchors for references — my adding table numbers doesn’t force you to use them, you can *still* reference the enclosing section.

Page numbers is the same: your *not* liking them, and *not* using them is fine, nobody forces you to — but removing them does force everybody else into your workflow and your preferences.

I’m not saying that that’s your intent, I am just noting that the argument “We need to do XXX, because XXX is my preference and those who disagree are (in Ted’s words) silly” probably isn’t the best to use.

Back to the issue at hand, what I tried to illustrate is that if page numbers are removed, then *every* other entity does need a number: tables, figures, artwork, paragraphs, …, since otherwise it becomes too tedious to figure out how to point to that which I want to point to. I think that what 

> 
>> The table in section 8.6.2 (which also ain’t got no number), in my printout I get the “header” on the bottom of the page, and the only table row on top of the next. Poor splitting in the output format.
> 
> That is true. I'd like to investigate, so if you can tell me which UA it is, and what your paper size is, I might be able to find out what's going on.

I can do better than that, I will send you the pdf  (off-list) that is generated (same thing happens if I send to printer and to pdf). Otherwise, A4 paper and Safari on a mac (it’s one of those rare days I’m at a real desk with a non-tablet device).


>> So this document is a good illustration of:
>> 
>> 	o	why the war-on-pagenumbers is unfortunate — in formats where you do not just have CTRL-F to find-and-scroll-to
>> 		what you want, anchors in fixed positons (like page-numbers) are a huge help
>> 
>> 	o	why section numbers is an insufficient granularity
>> 
>> 	o	why tables, figures, artwork, etc, at least need numbers also so as to be able to point
>> 		precisely to what one is talking about
>> 
>> 	o	that when outputting html to a paginated format, there is a risk of stuff that splits across
>> 		pages that really shouldn’t do that.
> 
> Yes, there's that risk. In some cases it's because of missing CSS support in browsers, sometimes it's really hard to do, sometimes it might be a shortcoming in the HTML/CSS that was produced. That's why I am asking for feedback.

I know - and that’s why you’ve got it ;)

Thomas

> None of these problems IMHO are problems serious enough to make printing impossible. The requirements on the aesthetics of a single one-off printout IMHO are different from those for a printed book.
> 
>> You asked for “report back” — that was mine.
>> 
>> Thomas
> 
> Best regards, Julian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140627/a6111d2e/attachment-0001.html>


More information about the rfc-interest mailing list