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

George, Wes wesley.george at twcable.com
Tue Jun 24 14:37:08 PDT 2014


On 6/24/14, 3:29 PM, "Dave Crocker" <dhc at dcrocker.net> wrote:


>  The document essentially
>makes ascii art of questionable utility.

WG] No, that happened as soon as something better was widely available,
many, many years ago. This is just admitting that such newfangled
technology exists and pretty much works. ;-)

>You did not see me say that page numbers should be retained.  Rather,
>I'm noted the concern about 'direct' access that was cited elsewhere and
>I've suggest it get attention.

WG] I think that's the accurate point. It should NOT be a primary goal
that page numbers or indeed pagination be retained. It should be a primary
goal that there be useful anchors that are visible in multiple display
formats such that they identify the same location in the document's text
regardless of the method used to render it. It should be a primary goal to
identify how granular those anchors should be and how they should interact
with sections and subsections to allow readers and reviewers to reference
a given area of the text of the document.

>We need to be much more clear about the reason for doing graphics art.
>If it is for prettiness, then we shouldn't make the switch.  There is no
>evidence that what we've done using ASCII art has not been sufficient,

WG] You're dramatically oversimplifying things. The process required to
get useful ASCII art that meets the formatting requirements breaks the
workflow most people use to author modern documents that can support
vector graphics. Even when using a tool to do so, generating ASCII art
diagrams wastes a lot of time creating output that is mediocre at best at
the task of conveying the visual information it's trying to convey, in
order to meet limitations that are not and have not been due to the limits
of technology for ~2 decades. Do our ASCII diagrams convey the point their
authors intended? Mostly, but that's a pretty low bar. I don't know what
you're looking for in terms of evidence that ASCII isn't sufficient, so
here's some anecdotal evidence: Because I'm used to looking at modern
graphics, it takes me consistently longer to parse an ASCII graphic than a
Visio-style graphic. This is because ASCII is, and always has been, a
second-rate substitute for an actual drawing, selected because vector
graphics were not consistently supported on some rendering platforms long
ago. Now that limitation is purely arbitrary and self-imposed, and it
needs to go away. I have fond memories from when I was 8 years old of
ASCII art Peanuts calendars printed out on green-bar fan-fold paper via a
daisy-wheel printer, but I'd rather have the full-color, 1000dpi Dilbert
calendar sitting on my desk, because it's much easier to read, even at 1/4
the size.

>and we /do/ know it always can be displayed.
WG] No, actually we have multiple existence proofs of devices that can't
display ASCII art properly because they don't support enough fixed-width
horizontal characters per line at the right font size, but do just fine
with an inline vector graphic accompanying a volume of plain text
(E-readers, for example). That's exactly the sort of thing we're trying to
fix.

The other consideration that comes to mind is whether ASCII art is any
more useful than a graphic at conveying information for those who use a
screen reader. I can't see ASCII art being any more valuable than a
graphic as the screen reader says "asterisk asterisk greater than less
than emdash emdash period period open bracket" but I'm not visually
impaired, so I can't really assume anything there. I think where we left
this debate was that it was impossible to have a normative graphic because
there was no way to make it usable for a visually impaired person, and
thus the text had to be normative with the graphic as an embellishment.

That said, it should be simple to toggle the "text only" version so that
it shows the graphics such that they print inline when one goes to read or
print the document or it instead shows the URIs to the graphics in order
to produce a lightweight, mostly text version as well as a true text-only
version, but I think that requiring the ASCII art alternative is catering
to a small (albeit vocal) minority that made a *choice* to consume this
info in a format that "can't support" anything but ASCII.


Thanks,

Wes George


Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


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 mailing list