[rfc-i] not just 'lineprinter' (was Re: Fwd: New Version Notification for draft-flanagan-plaintext-00.txt)

Dave Crocker dhc at dcrocker.net
Mon Jun 30 13:09:00 PDT 2014


On 6/30/2014 12:29 PM, Joe Hildebrand (jhildebr) wrote:
> On 6/30/14, 10:30 AM, "Dave Crocker" <dhc at dcrocker.net> wrote:
>> As usual, I guess it's important that we ignore the difference between
>> retaining something we've been using for 40+ years, versus adding
>> something we haven't been using at all...
> 
> The current format hasn't worked for its intended purpose for years except

Joe, the continuing and fallacious hyperbole is tiresome, at best, but
mostly it's distracting from serious discussion.


> Can we please focus on what those
> issues are and how to solve them, rather than trying to desperately cling
> to a format that is no longer fulfills its mission?

+1.

However that includes refraining from constantly bashing established
formats that remain a requirement to support.


> Calling the current set of requirements my preferences is a little
> insulting. 

>From a quick scan of my last two postings, I've no idea what you are
referring to.

I've no particular reticence to include you (or pretty much anyone else)
amongst the folk I insult, but I really do prefer to know when I'm doing it.


> Then I don't understand what we're talking about anymore, sorry.  Perhaps
> you could restate it.  I thought what we were talking about is whether it
> is feasible to have a non-paginated XML file produce a printable form that
> was adequately aesthetically pleasing. 

I thought the question was /whether/ to generate the ^L, and not whether
it is feasible.

I read Brian's suggestion as an assertion of efficacy to generate the
^L, for txt format.

I am expressing support for doing it, since I believe his description of
the benefit that accrues made sense.  I'm not in the least worried about
whether it's possible or even easy.



>> Feel free to make your case for that, with specifics, but again note the
>> counter points that Brian raised, which demonstrate their own
>> problematic visuals that significantly affect utility of the printed
>> document.
> 
> 1) I go to http://tools.ietf.org/rfc/rfc6120.txt in my browser (Chrome 35
> on OSX 10.9.3).  I hit cmd-P to print.  Page 126 of the output is attached
> as PDF; you'll note that a) it's some combination of page 136, 137, or 138
> of the RFC b) there's a header/footer blooped in the middle of the page
> that makes the example hard to read.

Hmmm.  Let's see.  The source file is entirely legal.  You process it
through an engine that does not properly support the constructs in the
file, and that somehow represents a failing of the file format?

But much more importantly, you base your criticism on the presence of
headers and footers, out of place, when Brian's suggestion was for FF
and /not/ headers and footers.

That is, a file that has FF but no headers or footers would not surface
the limitations of your browser and processing txt data.


> 2) I rsync the RFC repo and get the raw .txt file.  Two of the text
> editors I use daily (SublimeText and Atom) don't even have print options.

MS Notepad has never processed FF properly either.  So I guess we should
have tossed out pagination 20-30 years ago.


> TextEdit does the same thing as my browser.  Word 14.4.3 inserts an extra

The blank page problem is usually due to having the last line of a page
hit the 'physical' end of page, so that the FF occurs on the first
'physical' line of the next page.  The usual solution is to make the
font a bit smaller.  I just did that with Word -- 10pt courier -- and it
eliminated the extra pagination.  But then I've had to do that for
decades...


> blank page between each page (which I guess if I printed duplex would
> produce something readable).  Pages 5.2 does the same thing as a browser.

I'm impressed with the range and severity of user complaints about Pages
5.2, from a very quick search.

Generally, though, products labeled as 'word processor' have often had a
problem with simple txt format, including pagination.  Again, that issue
goes back well into the 80s.  So the 'current' problem would serve to
argue that we should have tossed out txt 20-30 years ago.

FWIW, the text editor I use has no problem properly processing txt
pagination and printing it properly.  The browser I use has always
ignored FF; it's never occurred to me to blame an html-oriented engine
for having limited skills with raw txt.


>> As for the continuing argumentation style that chooses to say the way to
>> deal with deficiencies in one form is to use a different form, please
>> no, let's not.
> 
> I don't understand this.  If there are deficiencies in one form, we either
> need to fix that form (and deal with the side-effects), use another form,
> or decide to live with brokenness forever.  It seems like the RFC Editor
> has decided that the last choice is no longer viable, so we're left with
> one of the other two.

1. The basic line of commentary is to harp on the deficiencies of txt,
rather than just do the engineering work needed here.

2. We have already got a path chartered for 'another form', in fact more
than one.

3. Consequently constantly decrying the deficiencies of txt is what in
sales is called 'selling past the sale'. The other cliche'd punchline
ends with "and it irritates the pig".

Brian made a modest suggestion for a modest and useful choice.  Rather
than focus on that suggestion, discussion has -- as usual -- devolved
into txt bashing.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


More information about the rfc-interest mailing list