[rfc-i] Font selection for RFCs

"Martin J. Dürst" duerst at it.aoyama.ac.jp
Tue Oct 28 15:54:18 PDT 2014


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

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

Agreed. That's why I was a bit surprised that the initial mail said 
"typeface ... that includes ... at least a mono-space font and hopefully 
a variable-width font as well".


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

Yes. The non-ascii in the examples should match the ascii in the 
examples in terms of font style (e.g. serif vs. sans-serif,...). But 
please be aware of the fact that for some scripts (e.g. Arabic), 
mono-spaced doesn't really work well anyway, and that for some other 
scripts (Han, Kana, Hangul), each character will be double the width of 
a Latin character by design.


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

Agreed.


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

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

I'll send an example in a separate mail.

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

I'm sure there are ways to deal with this other than to commission a 
typeface! But I agree  that PDF will be more of a challenge. It would be 
good if it were possible to leverage the CSS to produce the PDF.

Regards,   Martin.


More information about the rfc-interest mailing list