[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-----
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)

Yes.

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

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

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUUApzAAoJEER/xjINbZoGga0IAJXVTQxu27ZKBINQu9i6R6cD
OPYbFr7FJZo6XNfVFPDXAZuiUyT/f7nwR977e6x+grnsiRJKFL2LHo55iOdG/a8/
+y3aN0QIa4UhNiAhr4BMio8IIJa9Upn10szCk6ybRC4vxoiP3n/A3i4/UNPaT4xc
9Gf86EZIvZLkJq/52IOuTkPU2FU9VPQmXOpozIz+JqwRIMx99WzNdQdLHIzdgFsN
45CsTBbvuaVwpepeR8p6PSbykg+N1nWejuTjCbeH4RL2IhcTpEB7VOtMe5fmNLx8
CPIa+UOeyuv+xO5ADoScFxVYeYcoeGA5kPm+Dd0aHVBXd6B1XttIXod7MvkNRvM=
=oIKX
-----END PGP SIGNATURE-----




More information about the rfc-interest mailing list