gmane.ietf.rfc.interest

Re: Pagination requirements

Brian E Carpenter — 2012-05-23T06:38:56

...

Not true. I regularly print I-Ds and occasionally RFCs in
"booklet" format on all kinds of printers (as long as they
support that format of course, but it seems to be widespread
on duplex printers).

If they didn't have a standardised pagination and form feeds
it would be much harder.

    Brian

Re: Pagination requirements

Tim Bray — 2012-05-23T04:15:06

To his credit, Martin has been admirably clear. The existing format
meets his needs well and the problems that are troubling the rest of
us are for one reason or another not disturbing him; rather than
changing things, we should complain to those at fault, the vendors of
the technologies we use that do not perform well with the line-printer
format.

Noted.  Yes, let’s move on.

 -Tim

On Tue, May 22, 2012 at 8:12 PM, Peter Saint-Andre <stpeter< at >stpeter.im> wrote:

Re: Pagination requirements

Peter Saint-Andre — 2012-05-23T03:12:11

<snip/>

Folks, this thread has gone on for so long that I forget its original
purpose. Can we give it a break for a while? If someone has novel input
to provide or, even better, true requirements for the RFC format going
forward, perhaps they could write that in succinct text?

Peter

Re: Pagination requirements

Martin Rex — 2012-05-23T03:09:16

MSIE, FF and Chrome correctly navigate to Page 87.



Neither. It is printed at the bottom of the _same_ page.



Page 1.   Where do you see a [Page 0] ?



Really, how did you get http://tools.ietf.org/html/rfc1122
to render with [Page 0] at the end of the title page?



Books usually contain an uncounted cover plus an uncounted inner page
and then start with i, ii, iii, iv, v, vi for preface and table of contents
and then start over with pages 1, 2, 3, ...


-Martin

Re: Pagination requirements

Bjoern Hoehrmann — 2012-05-23T02:37:35

http://tools.ietf.org/html/rfc1122#page-87 seems to refer to page 86.
Does the page number precede or follow the page? Is the Abstract in the
plain text version on page 0 or on page 1? Given that RFC 1122 seems to
end with "Page 116", it seems page numbers are at the bottom, so page 0
seems to be the first one. Books normally start at page 1, after some
non-counted pages perhaps. I would call that confusing...

Re: Pagination requirements

Martin Rex — 2012-05-23T02:13:07


RFC20 ASCII format for Network Interchange, 5.2 Control Characters, page 7

http://tools.ietf.org/html/rfc20#page-7

      FF (Form Feed): A format effector which controls the movement of
   the printing position to the first pre-determined printing line on
   the next form or page.  (Applicable also to display devices.)

And the more modern successor RFC3629 aka STD0063 contains
a normative Reference to Unicode 4.0.0


And Unicode 4.0.0, according to this:

  http://www.unicode.org/Public/4.0-Update/NamesList-4.0.0.txt

does still have the rfc20 ASCII FormFeed character at Codepoint 12 (0x0c)


Complain the vendors/suppliers of your defective software.


-Martin

Re: Pagination requirements

Martin Rex — 2012-05-23T01:43:45

Why do you think they are NOT canonical?

According to

  http://tools.ietf.org/tools/rfcmarkup/

the rfcmarkup tool that creates these output only adds/inserts
information, it does not filter/remove any information (besides FF),
so there is no risk of loosing anything.  That is huge advantage of
the text format and transformations based on it.

The PDF output from tools.ietf.org/html/rfcXXXX is created by
GNU Enscript according to the document properties of the resulting PDF.

  http://www.gnu.org/software/enscript/

so it IS the canonical document with a probability extremely close to 1.


As soon as you start massively inflating I-Ds and RFCs with meta-data
that must be filtered according to the display device, you create the
problem that different rendering engines may (incorrectly) filter
information that it shouldn't have filtered, or that meta-data is
inconsistent or wrong, but it isn't visible/apparent in the
specific output format that the reviewer used.


So any uncertainty problem, that does NOT

Re: Pagination requirements

Leonard Rosenthol — 2012-05-23T01:12:11

I'll note here, as we are talking about reference to "parts" of standards,
that the ISO standard is to use section (or clause) numbers.  So, you
might use something like "ISO 32000-1:2008, 8.6" if I wanted to reference
the section on Colour Spaces in PDF.

(I'll leave the "Pay to Play" vs. "Pay to Read" discussion for /dev/null)

Leonard

Re: Pagination requirements

Joe Hildebrand — 2012-05-23T00:40:03


Nobody created a 100% matching printout with the line-printer format.  If I
had a different daisy wheel loaded, it would look different.  I still
disagree that this has ever been a requirement.


Those aren't canonical, and may not even match the canonical version in
text, since nobody checks for that.


Such as... Every modern OS?  ^L just isn't semantic anymore.


Walk me through what you'd do on Windows7, for example, to print the
canonical version.  Places where I don't have easy access to "lpr" on the
command line.


Let's stop, then.  Declare "victory" for the IETF, and shut it down.


So let's not move the ongoing work to the ISO.

Re: Pagination requirements

Martin Rex — 2012-05-22T23:59:18

I do _not_ have a problem with others creating special printouts that
fit their needs.  But it would be stupid to create a brittle format
of a standard for which no two persons can create 100% matching
printouts _by_default_.



Proably untrue. There is a PDF version for existing RFCs available at

  http://tools.ietf.org/html/rfcXXXX

for those impaired environments that can not produce reasonable printouts
from ASCII text. 

So if your work environment can not cope with the fairly trivial task of
printing vintage LP, and you NEITHER can print the PDF version of it from
tools.ietf.org, then you should REALLY replace your work enviornment,
because it is broken beyond fixing.



Most of the standards that are truely relevant today are 10+ years old.

I have a printed copy of ISO/IEC 9899:1990, and use it regularly.

The drawback with ISO standards is, that few of them are freely available
online and with even fewer of them its possible to provide an URL to
specific sections or pages that others can use.



-

Re: Pagination requirements

Joe Hildebrand — 2012-05-22T23:33:00


Who cares if they produce the same output in any way?  If it's legible, and
you have reference marks that I wrote about in my previous mail, printing
repeatability is a anti-requirement, particularly in the face of low-sight
individuals that would prefer to print out at a much larger font size.


No it's not a necessity.  You can't do that with the current format on most
systems today.

If your odd workflow is that important to you, you could always print to
PDF, and keep that around for stability.


No it doesn't.  Printing the current format is an absolute mess, unless you
have a vintage line printer.


That's clear from your vociferous defense of the status quo.  Nostalgia has
a place and a time, but standards bodies aren't always that place.

Re: Pagination requirements

Joe Hildebrand — 2012-05-22T23:22:12

On 5/22/12 4:31 PM, "Martin Rex" <mrex< at >sap.com> wrote:


I already provided a potential solution for this:

< at >media print {
  p[id]:after {
    content: " [#" attr(id) "]";
  }
}

Since not everyone is a CSS expert, let me break that down and explain what
it does.


Only apply this portion of the CSS when we're printing, not on-screen.


For every paragraph element with an id attribute (which looks like: <p
id='foo'>bar</p>)


Right after that element


Insert some content


That consists of the literal text " [", the value of the id attribute, and
the literal text "]".  In the printout, this looks like:

bar [#foo]

Other styling information like color and font can also be applied so that
the inserted text is less intrusive.  Note that this does not require
JavaScript, works in all modern browsers, and makes every section (or
potentially every paragraph) easy to refer to.

By the way your "for the fun of it" makes me feel like we still have some
explaining to do for you to understand the problem that we're

Re: Pagination requirements

Martin Rex — 2012-05-22T23:13:44

I have not found two browser which produce the exact same printout for
a page, and I regularly run into problems where letters or words get
truncated in the printout or graphics misplaced.  The issue is much
worse on printouts than it is onscreen.



For a 100+ page document, I may not want to print everything at once
all the time, so an option to print 20 pages today and print 20 more
pages in 3 weeks AND having the printouts FIT TOGETHER as if printed
in a single go, is a necessity.  This does work perfectly with the
existing RFC format.  And btw. I'm perfectly fine with the
nostalgic 80-columns fixed pitch format.  In 1996 I wrote myself a
small perl-script feeding into a2ps that puts I-Ds and RFCs 2-up with
pages borders and a prominent title line.  For reviewing and implementing
RFCs and I-Ds ans for reading I-Ds on the plane when travelling to IETFs.
I still use it occasionally, and still use some RFC printouts that are
10+ years old.  My last printouts were rfc2315 & rfc2630, about 6 month ago.


-Ma

Re: Pagination requirements

Tim Bray — 2012-05-22T22:58:50

One of the reasons I want to get rid of the legacy line-printer format is
so I can print an RFC for offline reading.  I don’t think anyone in this
discussion is in favor of offline-unusual.


The “open research problem” remark is just not true; every browser I use
can print beautifully, and deal with a variety of paper sizes depending
where I am in the world.  As you note, doing this requires reformatting and
reflowing, and I appreciate the work that went into the software.
Pagination is an ephemeral artifact of a particular consumption scenario,
and page numbers are intrinsically broken as a basis for location and
reference.

 -Tim

_______________________________________________
rfc-interest mailing list
rfc-interest< at >rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

Re: Pagination requirements

Martin Rex — 2012-05-22T22:33:23


Unusable, because it will not work for a printed copy.


-Martin

Re: Pagination requirements

Martin Rex — 2012-05-22T22:31:59

As I previously mentioned, I regularly print out RFCs that I implement
and use the printed copy, and I am strongly opposed to make future RFCs
offline-unusable just for the sake of the fun of it.

Since printing with Web Browsers is still an open research problem,
the possibility of creating a paper printout of an RFC that will be a
close 100% match for printouts created by different people and
independent of whether I use "Legal" or "ISO A4" paper is also a
requirement.  Including a Table of Contents showing page numbers,
because that is how to navigate in printed copies!

And it really helps when running into ambiguities or defects when
the printout and the online version of the RFCs look similar. 


-Martin

Re: Pagination requirements

Julian Reschke — 2012-05-22T22:23:17

If there is pre-pagination.


They have been helpful for historic RFCs. So?


We are discussing future RFCs-


What if the URI would be

   http://tools.ietf.org/html/rfc5280#ABNF-CRL

instead?

Best regards, Julian

Re: Pagination requirements

Iljitsch van Beijnum — 2012-05-22T22:22:35


Huh?


But the price of that stability is extremely high in the current system: pages are formatted for a size that is inconvenient in the majority of situations.




Current tools are irrelevant to the discussions about a future format.


Well, let's not make any new old RFCs for which this is the case then.


s/ is / has been /g

Even if all your points remain relevant in a new system, which would be unexpected to say the least, I still want pagination to go because linking to a page is something that very rarely happens, while trying to read an RFC with pages, or worse, lines that don't fit on your screen is something that makes me want to kill puppies each time it happens, so I need to spend inordinate amounts of time and effort to make sure to get the right alternative version or massage the printing process to avoid it.

Re: RFC Format - final requirements and next steps

Martin Rex — 2012-05-22T22:19:59

For reading existing RFCs on a Kindle, reflowing the ASCII text would
be a pretty workable approach.  It is simple software shortcoming
that these devices display plain ASCII text so poorly today.

For implementing and discussing an RFC, the Kindly and other
small devices are pretty useless.  Cross-device copy&paste doesn't work.


When I mark some text area in my browser windows and do a right-click
"view selection source" or just "view source" on the whole page,
I am regularly annoyed by the stupid browser that does not wrap
the lines of the HTML(!!) source that it visualizes.  And when you move
to a specific position in a 1000+ chars long line and then move down
two lines to the next huge line over an intervening short line,
you can restart scrolling ...

If there is anything broken, then it is the browser software, really.


-Martin

Re: Pagination requirements

Martin Rex — 2012-05-22T22:10:16

What I dislike is the constant confusion of "screenful" (in particular
for small devices) with "page", a term from the paper-area.

Since RFCs do NOT change after publication, the preformatted page
numbers are completely stable and there is *NO* confusion about what
page 87 of rfc1122 refers to.  And pages are currently the anchor
tags that work for *ALL* existing RFCs through the

   http://tools.ietf.org/html/rfcXXXX

interface.  There are a number of older RFCs where section number anchor
tags work poorly (just top level sections as e.g. rfc1122, rfc1123)

  http://tools.ietf.org/html/rfc1122#page-87
    
or not at all (e.g. rfc2743).

  http://tools.ietf.org/html/rfc2743#page-42

So it is extremely helpful that page number anchor have been available as
stable, unambiguous fallbacks when discussing and refering to
specific contents of existing RFCs with URLs.



It often *IS* much better, in particular with the existing RFCs.

Refering to a specific element from an ASN.1 module or other data
in the appen

Re: feedback on draft-hoffman-rfcformat-canon-others-00,

Brian E Carpenter — 2012-05-22T06:31:04

...


I wouldn't use the word "obfuscation" but it's a fact that some
editors behave awkwardly with very long lines.

    Brian