[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.
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
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
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
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.
More information about the rfc-interest