[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-00.txt
wesley.george at twcable.com
Fri Jun 27 04:47:00 PDT 2014
On 6/27/14, 6:29 AM, "Dearlove, Christopher (UK)"
<chris.dearlove at baesystems.com> wrote:
>No one has suggested not being able to put things on an iPad.
WG] Well, no, but the problem with the current format, especially the
ASCII art, is that it actually doesn't render properly on some eReaders
due to the width+font requirements, where a graphic will. So suggesting
that the current format is perfectly adequate is in a way doing so.
>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
>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
WG] Look, while I don't read and review on paper, I have nothing against
paper. That said, I do not believe that your legitimate request for a
printer-friendly format translates to a need to keep the existing
nongraphical *line printer*-friendly format, and if that's not what you're
advocating for, I apologize for misunderstanding you, but given some of
the discussion on this thread, it'd be an easy mistake to make. I am,
however, prepared to steamroller those who believe that the current format
is perfectly acceptable but are unwilling to provide any objective reasons
why other than "it works for me" or "it's worked for many years", while
continuing to suggest that we haven't properly considered the benefits of
the current system before deciding to change it and accusing those
suggesting changes of being distracted by shiny objects.
>At the moment what appears to be on offer is
WG] You really do need to go read the draft before making this
>- Text, but freeflowing and not suitable (tables and figures will break).
WG] This problem is known and has been addressed. The Canonical (XML) RFC
format has tags to identify where text that cannot be reflowable and must
be displayed with a fixed-width font to ensure that there aren't rendering
problems. It should also be straightforward to treat those blocks of text
as objects such that they can't break over pages when rendered down for a
printer-friendly format. The value of the XML canonical version is that
anyone willing to write a processor to do it can render it down to
whatever format they'd like.
>- HTML, where some (but definitely not all) browsers might offer what you
>want, but at the least not guaranteed.
WG] as I've said in other threads, you need to be a good bit more specific
in your concerns here if we are to properly address them. Hand-waving
around interop and compatibility problems is not helpful in the least.
What are the specific limitations that you're concerned about, keeping in
mind that IETF will be keeping to standards-based HTML, and not one
optimized for a certain browser, and unlikely to require any too many
features that aren't in the early HTML specs in order to ensure maximum
>- PDF, where format is stated as not defined yet. (It's still my best
>hope, and I think people planning it are thinking of this issue, maybe
>more than they were.)
WG] Appears you should make friends with these chaps:
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
More information about the rfc-interest