Bug#306290: ITP: ttf-mph-2b-damase -- font with ranges from the latest version of unicode
Dear Paul and Mark,
> I'm not very familiar with OpenType/fonts, or editing them, so
> I'd have to defer any changes to Mark.
let me explain the problem a bit more. In any program where you
don’t explicitly configure a separate font for every script under
the sun, which means pretty much anything but Mozilla, including
all GTK+ and Qt etc. programs, one main font is chosen (say,
Bitstream Vera Sans), and whenever the program encounters a
character (say Kharoṣṭhī) that is not covered by that main font,
it asks the fontconfig library to find a font that does contain
glyphs for that character, and then automatically gets them from
there.
The problem is that a) fontconfig does not know very much about
the capabilities of fonts apart from what glyphs there are in
there, and b) it prefers fonts with a broader script coverage
(thus determined) over those with a more narrow coverage. That
means that on a system with
– Mark’s Damase font (with glyphs for many scripts, but no
OpenType mechanism for Kharoṣṭhī, Limbu, hPhags‐pa etc.),
and
– a to‐be‐developed specialised Kharoṣṭhī font (with glyphs for
only Kharoṣṭhī, but proper OpenType support)
fontconfig, when asked to provide for Kharoṣṭhī, will prefer the
Damase font over the specialised Kharoṣṭhī font, thus causing
broken rendering for Kharoṣṭhī text even though a font for proper
rendering would have been available. (As far as Kharoṣṭhī is
concerned, this is a bit theoretic at this point, since the
specialised font does not exist yet, but may already affect Limbu
etc. users.)
This has been discussed on the fontconfig mailing list, and
somebody suggested that fontconfig should check for OpenType
support, but it’s not sure that that is going to happen. At the
same time, the usefulness of a non‐OpenType Kharoṣṭhī (Limbu,
etc.) font for actual users (academic or native) is very limited,
since all one can do with it really is typeset an alphabet table,
but not any connected run of text. That’s why I suggested that
removing Kharoṣṭhī, at least from the Debian package, may be the
best thing to do at this point, pending potential future
improvements in fontconfig that would mean that fonts with partial
support can no longer negatively impact fonts with full support on
the same system.
And of course this situation sucks, because it discourages
enthusiastic developers who want to get started somewhere, but
don’t have the time or resources to go all the way with
replacement tables and everything. In our research project, at
the moment we also use non‐OpenType Kharoṣṭhī fonts, with just the
basic glyphs in the codepoints, and the composite glyphs in the
PUA, and everything has to be handpicked. But that’s a
specialised internal use, and having a font distributed as part of
Debian is a different issue, especially if it impacts multiple
scripts. Sorry if all that sounds a bit negative.
[I’ll send you some remarks on Burmese in a separate email,
outside this bug report.]
All best,
Stefan
--
Stefan Baums
Asian Languages and Literature
University of Washington
Reply to: