[rfc-i] Font selection for RFCs
Heather Flanagan (RFC Series Editor)
rse at rfc-editor.org
Tue Oct 28 14:28:19 PDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
More information about the rfc-interest