[rfc-i] Font selection for RFCs

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Tue Oct 28 14:28:19 PDT 2014

Hash: SHA1

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)


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

Depends on what's in the code examples.  I'm thinking of the SIP example
in the non-ascii draft.

>> Also, creating a font, in particular if it's supposed to cover a
>> part of Unicode, is a lot of work, and needs a lot of different
>> [...]
> Hopefully that's not something anyone wants the RSE, ISOC, or related,
> to be doing.

Creating a font?  No, that's not expected of the RFC Editor.  That ...
would not be fun.

>> Then there is the issue of different languages having different font
>> preferences. The most widely known example is Chinese vs. Japanese.
>> 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
>> and the same the other way round. That's why XML and HTML have
>> 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.

Indeed.  I track the W3C's internationalization list (www-international)
which has definitely increased my awareness of these types of issues.

>> Today's technology is pretty much able to handle this. Advanced font
>> technology allows to create 'combined' fonts collected from various
>> 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?

Right.  I find the PDF/A-3 more of a challenge here than the plain text
or HTML.  The PDF/A-3 embeds the font information in the file.   Perhaps
there are ways to deal with this more cleanly than to try and find or
commission a typeface, but I still poking at this whole gnarly issue.

- -Heather
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org


More information about the rfc-interest mailing list