metric for block coverage

[David Starner via Unicode]

On Sun, Feb 18, 2018 at 3:42 AM Adam Borowski <kilobyte at angband.pl> wrote:

> I probably used a bad example: scripts like Cyrillic (not even Supplement)
> include both essential letters and those which are historic only or used by
> old folks in a language spoken by 1000, who use Russian (or English...) for
> all computer use anyway -- all within one block.
>
> What I'm thinking, is that a beautiful font that covers Russian, Ukrainian,
> Serbian, Kazakh, Mongolian cyr, etc., should be recommended to users before
> one whose only grace is including every single codepoint.
>

I'm not sure what your goal is. Opening up gucharmap shows me that
FreeSerif and Noto Serif both have complete coverage of Cyrillic and
Cyrillic Supplemental. We have reasonable fonts to offer users that cover
everything Cyrillic, or pretty much any script in use. I'm not sure where
and how you're trying to cut a line between a beautiful multilingual font
and a workable full font.

Ultimately, when I look at fonts, I look for Esperanto support. I'd be a
little surprised if it didn't come with Polish support, but it's unlikely
to be my problem. A useful feature for a font selector for me would be able
to select English, German, and Esperanto and get just the fonts that
support those languages (in an extended sense, including the extra-ASCII
punctuation and accents English needs, for example.) It does me absolutely
no good to know that it has "good, but not complete" Latin-A support.
Likewise, if you're a Persian speaker, knowing that the Arabic block has
"good, but not complete" support is worthless.

For single language ancient scripts, like Ancient Greek, then virtually any
font with decent coverage should cover the generally useful stuff. For more
complex ancient scripts, it pretty much has to be on a per language matter.
For some ancient scripts, like Runic and Old Italic, I understand that
after unifying the various writings, most people feel a language-specific
font is necessary for any serious work.

The ultimate problem is that the question is will it support my needs.
Language can often be used as a proxy, but names can often foil that. And
symbols are worse; € is the only character from Currency Symbols that's
used in an extended work in many, many instances, but so is ₪. Percentage
of block support is minimally helpful. Miscellaneous symbols lives up to
its name; ⛤, ⚇, ♷, ♕, and ☵ are all useful symbols, but not likely to be
found in the same work. Again, recommend 100% coverage or do the manual
work of separating them into groups and offering a specific font (game,
occult, etc.) that covers it, but messing around with a beautiful font with
less than 100% coverage versus a decent font with 100% coverage seems
counterproductive.

Not sure if I understand your advice right: you're recommending to ignore
> all the complexity and going with just raw count of in-block coverage?
> This could work: a released font probably has codepoints its author
> considers important.
>

I guess separating out by language when you need to is going to be the way
that helps people the most. Where that's most complex, I'm not sure why
you're not just offering a decent 100% coverage font (which Debian has a
decent selection of) and stepping back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/unicode/attachments/20180218/b49bd96d/attachment.html>