[rfc-i] draft-iab-rfcformatreq-01: fixed-width != ASCII

Paul Kyzivat pkyzivat at alum.mit.edu
Wed Jan 23 11:37:48 PST 2013


On 1/23/13 11:07 AM, George, Wes wrote:
>> From: rfc-interest-bounces at rfc-editor.org [mailto:rfc-interest-
>> bounces at rfc-editor.org] On Behalf Of Paul Hoffman
>>>
>>> Yes, but it's a de facto requirement (as Nico says, strongly implied
>>> by the use of ASCII art).
>>
>> No, it is not. It is a requirement *for ASCII art only*. In a display
>> format that supports multiple fonts, monospace is only needed there (and
>> maybe for headings that are centered in renderers that are width-
>> dependent).
>>
>>> I think it's a de facto requirement and I'm pretty sure we're
>>> proposing to drop it.
>>
>> Some of us have proposed to drop it where it is not needed.
>>
> [WEG] +1
> This is why the use of metadata is so important in the canonical format - so that specific areas of text can be identified as requiring a monospace font for proper display without locking us into its use for the entire document/series. If we wanted to go further, we could add explicit guidance that devices/derivative formats incapable of rendering multiple fonts in the same document (if exist) MUST render the documents completely in monospace font if any part of the document requires monospace. Otherwise it really shouldn't matter to us.
>
> Though I will also note that the creation of manual layout using monospace fonts for things like ASCII art also requires the definition of a maximum (or minimum supported) line width, which is being removed from the requirements. I support removal of that requirement for the *entire document*, because there is no line width limit on reflowable text, but there is probably some need in the updated style guide for guidance on line widths for items tagged in metadata as requiring a monospace font for layout reasons.
> Here's an example of a common use case that we've been talking about needing to support: Based on a quick search, a Kindle can display about 45 characters of monospace text per line. Do we then assume that as our width limit? But wait, that's only on the smallest font size...
> I think the reality is that ASCII art will not display properly on all devices and is therefore not an acceptable lowest common denominator choice anymore. This is leading me to conclude that supporting vector graphics first (which can be scaled for screens large and small) and ASCII as a fallback makes more sense.

Many (most) modern devices and displays can handle arbitrary width via 
scrolling. That is reasonably acceptable for viewing line art, while 
line *wrapping* makes hash of line art.

But of course that doesn't help those who view their drafts on dead trees.

Within reason this could also be handled by shifting to a smaller fixed 
width font in order to fit the art on the page.

My point is that we might be able to relax the constraint on the number 
of characters per line for line art.

	Thanks,
	Paul

> Wes George
>
> 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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>



More information about the rfc-interest mailing list