[rfc-i] Font selection for RFCs
pkyzivat at alum.mit.edu
Tue Oct 28 15:06:41 PDT 2014
On 10/28/14 4:43 PM, Nico Williams wrote:
> On Mon, Oct 27, 2014 at 8:45 PM, "Martin J. Dürst"
> <duerst at it.aoyama.ac.jp> wrote:
>> On 2014/10/28 06:01, Heather Flanagan (RFC Series Editor) wrote:
>>> My biggest challenge in this area is a question of what typeface to
>>> use that includes enough Unicode characters to be useful, has and
>>> acceptable license, and includes at least a mono-space font and
>>> hopefully a variable-width font as well. But that's a subject for its
>>> own thread, and it's something I'm talking to a typography expert about.
>> For a start, there are extremely few typefaces that include both a
>> mono-space and a variable-width variant. The requirements are already set
> The two are probably for different purposes anyways, right?
> (mono-space largely being needed for code examples and such)
Another requirement for the mono-space font is that it work well for
ascii art. (E.g., good looking vertical bars, slashes and backslashes
that line up properly on different lines, "+" lining up with vertical
Is it a requirement to have more than ascii with mono-spaced fonts?
>> The next issue is coverage of Unicode. There are some fonts that have a fair
> Again, we shouldn't need wide coverage for mono-space fonts, just for
> variable-width fonts.
>> Also, creating a font, in particular if it's supposed to cover a significant
>> part of Unicode, is a lot of work, and needs a lot of different expertise.
> Hopefully that's not something anyone wants the RSE, ISOC, or related,
> to be doing.
>> Then there is the issue of different languages having different font
>> preferences. The most widely known example is Chinese vs. Japanese. Although
>> the characters are the same, and legible either way, the fonts that the
>> Chinese are used to and the fonts that the Japanese are used to are quite
>> different. Showing a Japanese text with a standard Chinese font feels weird,
>> and the same the other way round. That's why XML and HTML have xml:lang/lang
>> attributes, and we should make sure they are usable. [...]
> I suspect this is also why Unicode used to have language tag codepoints.
> This is probably a problem that I bet the RSE will have to deal with.
> I'm glad you pointed it out.
Can we perhaps have an assortment of unicode fonts, and have the
formatters choose one based on what code points are used in the text?
(That won't work in all cases, but maybe in most common cases.)
>> Today's technology is pretty much able to handle this. Advanced font
>> technology allows to create 'combined' fonts collected from various sources.
>> But may have to pay somebody to do that for you. What's easier is to use
>> CSS, which also comes with machinery (language selectors, @font-face)
>> specifically designed for some of these issues.
> But CSS won't help with all the output formats that the RSE will be
> producing, right?
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest