Re: metric for block coverage

The most useful feature for me (Debian user, linguist) would be a search
system where I can provide a string, and filter fonts to those who include
glyphs for all characters; ideally if I could also combine it with other
search criteria, like OTF features (true small caps, etc.). I often write
academic texts where I use specialized characters not really classifiable
by language, script or block (say, 'ǎ/ǚ' for pīnyīn, plus IPA tone marks,
plus multiple combining diacritics like 'ā́', all in the same running
text). I then need visual inspection to choose a font that actually looks
halfway decent, typographically speaking, and to check for bugs in IPA
kerning, etc. For a long time now, I've been using a simple Python script
to filter fonts in this manner (it just straightforwardly renders the
provided characters, then uses `pango.Layout.get_unknown_glyphs_count()` to
remove fonts lacking them, and displays all the rest for inspection).

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 - 16:03:48 CST