Re: metric for block coverage

For Latin, usually looking for the coverage of Vietnamese works quite
well... except for African languages that need additional uncommon Latin
letters (open o, open e, alpha, some turned/mirrored/stroked letters), in
which case you should look also for IPA coverage (but you may missing their
associated capital letters sometimes needed too in these African
languages). Unfortunately the IPA subset of "Latin" symbols includes many
letters (only lowercase) that have no associated capitals, and trying to
match the full coverage of IPA is not needed for African languages (and the
variant of "g" added in Latin for IPA only is really unfortunate where it
should have been encoded as a variant of standard "g"). And the capital
SHARP S (ESSTSETT in German) may still be frequently missing in the font (I
don't know if renderers will try to lookup the glyph from another font, or
if they'll fallback to the lowercase sharp s mapped in the font !).

2018-02-18 22:39 GMT+01:00 David Starner via Unicode <unicode_at_unicode.org>:

> 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.
>
Received on Sun Feb 18 2018 - 17:06:51 CST