[rfc-i] Font selection for RFCs (was: Re: a short note about the use of non-ASCII characters)

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Mon Oct 27 18:45:28 PDT 2014

On 2014/10/28 06:01, Heather Flanagan (RFC Series Editor) wrote:

> On 10/27/14 4:53 PM, Nico Williams wrote:

> Actually, that's not entirely accurate.  See
> http://tools.ietf.org/pdf/draft-flanagan-nonascii-03.pdf.  The rules
> are more permissive than just author name; it's more a question of
> when the tool chain used by the RFC Editor can support the necessary
> checking and representation.
> That draft will stay a draft until such time as we have running code
> to see how things work; expect some changes as reality hits the plan.

> 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.

Hello Heather,

At least in the general case, trying to cover everything with a single 
font is a bad idea. This is a common understanding among Unicode experts 
(I came to that understanding around 1995 (see 
http://www.sw.it.aoyama.ac.jp/2005/pub/FontComposition1995.pdf), some 
others probably even earlier).

For a start, there are extremely few typefaces that include both a 
mono-space and a variable-width variant. The requirements are already 
set too high at this point, without even including Unicode. What you 
want to look for is a combination of a variable-width and a mono-space 
typeface that work well together. The first issue here is to get the 
visual height to match, because e.g. not all 12pt fonts have the same 
visual height. But if you have a typography expert, s/he should be able 
to help you figure this out pretty well.

The next issue is coverage of Unicode. There are some fonts that have a 
fair coverage of Unicode, but it's difficult to find a font that e.g. 
covers all of Han, Korean, Arabic,... The main reason for this is that 
depending on the document, in particular the percentage of the different 
scripts and the function of the text in each script (e.g. one script is 
used only for example vs. a parallel text), the ideal combination can be 
quite different.

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. Somebody able to create a beautiful font for Arabic 
isn't necessarily good at creating a font for Japanese. These days, 
volunteers can work together almost as easily as company employees or 
contractors, but it's still easier for a company to pull in the 
expertise they think they need.

As a result, it's still quite difficult to find free fonts with wide 
coverage. The exception are cases where a company is funding the work 
but releasing the result for free use. The only example I know of such a 
typeface with wide coverage is Noto (www.google.com/get/noto/, sponsored 
by Google). But that as far as I can see doesn't contain any monospace 

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. There are other languages affected (e.g. Russian vs. Serbian), 
but to a lesser extent. In high quality typography, even European 
languages are affected. An English novel printed with a typeface 
customarily used for French or Italian or German novels would feel 
somewhat strange. The advent of desktop publishing and Helvetica has 
numbed us a bit in this respect, but the issue is still there if you 
look carefully.

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.

This mail already got long, so I'll stop here, but I'll be glad to 
discuss some of these issues further.

Regards,   Martin.

More information about the rfc-interest mailing list