[rfc-i] tiny tablet text was Fwd: draft-flanagan-plaintext-00.txt
dhc at dcrocker.net
Fri Jun 27 09:24:10 PDT 2014
On 6/27/2014 8:47 AM, John Levine wrote:
>>> In my experience, the problem is that it's not easy to tell a
>>> tablet to show you something in a fixed pitch typeface if it
>>> isn't already marked up that way.
>> I have a text editor app on my android which I tell to use a
>> fixed-width font. There are lots of those.
> I can get it to display, too, but perhaps I am more nearsighted than
> you are.
>> However in the example I cited (of reading RFC 5598) it was
>> directly in Firefox, with no special settings and it looked
> The PDF version of 5598 looks fine,
Which is irrelevant to this thread, as I've already noted.
The issuethat was raised was ascii art. So look at the txt version.
>> The proposal is for ascii art line length to grow to 85
>> characters. That will make the characters smaller, which will make
>> the art harder to read. That's why it's a bad proposal.
> I'm not sure it makes much difference. I'd rather read something
> other than fixed pitch page image on my tablet.
Then this thread isn't relevant to you.
On 6/27/2014 9:00 AM, George, Wes wrote:> On 6/27/14, 11:16 AM, "Dave
Crocker" <dhc at dcrocker.net> wrote:
>> So somebody, somewhere, used a /converted/ version of an RFC and
>> had some sort of problem and folk here think that is a reasonable
>> justification for dismissing ascii art on ereaders
> https://tools.ietf.org/ebook/ is the somewhere, I am the somebody
> (but my experience is not unique, as anyone with similar hardware can
> replicate it), and I have described in detail what "some sort of
> problem" was.
And the question then should be whether the device you are using and the
file you are using with it should be a target for ascii art.
We probably are not going to target a 4" display at any resolution. We
probably are going to target a higher-res 7" full tablet. We should
list other targets to include or exclude.
I've no idea whether we should be targeting the specific category of
size and resolution you've cited. However we /should/ get some
community sense of the constraints we are trying to meet, rather than
having choices driven by the whimsey of our various anecdotes.
> Being dismissive of the quality of the data that you
> asked for when it doesn't support your view really helps to further
> the productive conversation. We're checking all the boxes on logical
> fallacy bingo today...
Wes, please review your own postings carefully, in terms of the
aspersions you are casting. And please do consider focusing on the
substance of the topic.
>>> I can say for certain that the monospace font, even at smallest
>>> size, is capable of <70 columns in portrait mode, and less than
>>> the 55-ish rows we paginate at today.
>> That assertion is factually incorrect, on both counts.
> WG] Which is in turn an incorrect assertion. How very meta.
>> I am presently looking at RFC 5598, on my 7" android tablet,
>> showing exactly one page, zoomed so that it all just fits on the
> WG] Am I really being this unclear? Your tablet is a different class
> of device, and does not refute the experience on my monochrome,
> e-ink, *not a tablet* Kindle e-reader. On the class of device I was
> providing detailed info about, that information is factually
Kindle and Nook sell ereaders that are comparable to the android tablet
I cited. The term 'ereader' is far too generic to be sufficient in a
technical discussion on constraints and goals.
That's why I asked for specific clarification. So yes, you did
eventually provide it and I therefore responded by posing the basic
question this ought to motivate.
>> What this mostly highlights is the need to properly characterize
>> target device categories for specific output formats.
> WG] I believe I've tried to do that.
> There is a class of device that
> cannot display enough character width to properly display ASCII art
> that adheres to the current text formatting and pagination rules. I
There are a number of classes of devices with that limitation. Which
ones should we seek to support (and why and for which display formats?)
And which ones should we not?
> explained the limitations. I think we should be able to support this
> device due to its relative ubiquity and utility as a device for which
> to do a lot of reading in a portable form, and to me that means we
> shouldn't require ASCII art, lest we have to dramatically *reduce*
> the maximum allowable width to have it display properly on this type
> of device.
OK. An entirely reasonable point of view, IMO.
There are, of course, counters to it.
For example, there are a large number of 4" devices that qualify
according to the criteria you've set. Why not seek to support them,
too? That is, what makes the specific class you seek to support both
distinctive and essential?
More information about the rfc-interest