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