[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#306290: ttf-mph-2b-damase and fontconfig



On Fri, 2005-07-22 at 22:17 -0700, Stefan Baums wrote:

> Thanks for looking into the font problem.  Don’t spend too much
> time on it, though, maybe a note in the package description and a
> short README file is enough.

I added the following to the description and added the attached extract
of the earlier discussion with Mark to the README.Debian file.

 The support for some fonts is not complete because the font lacks
 contextual substition (via OpenType tables) and composite glyphs,
 which are required to support Kharosthi and other scripts fully. Please
 read the Debian README for a fuller discussion of the problems this
 may cause.

> I’d feel stronger about this if we already had a full Kharoṣṭhī font
> as an alternative for Damase, but we aren’t quite there yet.

Let me know when this is available and I'll do the debian packaging if
necessary.

I'll now try to look for a sponsor for the package. If I can find
anything to fix fontconfig, I'll add that too, but I don't feel that it
is urgent until there is a better alternative to Damase.

-- 
bye,
pabs

http://qa.debian.org/developer.php?login=Paul+Wise&comaint=yes
Introduction
--------------------------------------------------------------------------------

The below is an edited extract from the discussion that followed the ITP
of this font. For the original discussion, please read the following URL:

http://bugs.debian.org/306290

Discussion
--------------------------------------------------------------------------------

Date: Sun, 8 May 2005 19:06:25 -0700
From: Stefan Baums <baums@u.washington.edu>

Please do not package this font as is. In common with the modern
Indian scripts, a Kharoṣṭhī font also needs contextual replacement
mechanisms (e.g. via OpenType) and a lot of additional composite glyphs to
support the script.  In the absence of these features, such a font with
pseudo‐support for a complex script X is liable to confuse fontconfig
and get in the way of other fonts that do in fact support script X.
The more so if the font with pseudo‐support _appears_ to be covering a
wide range of scripts, like this one. (This is also the biggest problem
with the 'Free UCS Outline Fonts', which contain the basic glyphs of,
e.g., Devanagari, but none of the required replacement mechanisms or
composite glyphs.)

So I request that at a minimum, you remove the Kharoṣṭhī range
from this font unless and until it provides real and complete support
of the script.  That said, (some of) the other Plane 1 scripts that this
font covers may work on a simple
character‐to‐glyph basis, and it would be a welcome addition to
have those available.  But please check which ones of them suffer from
insufficient support like Kharoṣṭhī (hPhags‐pa, for instance).

My colleague Andrew Glass is the main author of the Kharoṣṭhī
Unicode encoding, and he is now working on a proper Kharoṣṭhī font.
When that font is completed, we will make sure to submit it for inclusion
in Debian GNU/Linux.

And of course we are very pleased that people are interested in
support for Kharoṣṭhī.  It’s just a little bit more complicated
than putting those sixty‐odd glyphs in a font.  If you’d like to
develop a real Kharoṣṭhī font yourself, you are absolutely welcome.
The description of contextual replacement mechanisms is apparently not
yet available from the Unicode website, but you could check out our
original encoding proposal at

   http://depts.washington.edu/ebmp/downloads/Kharoshthi.pdf

and work from there.

--------------------------------------------
Date: Mon, 9 May 2005 00:48:36 -0700
From: Mark Williamson <node.ue@gmail.com>

You are correct.

However, I stand by my statement that it covers Kharoṣṭhī because
it does, in the same way that James Kass' Code2000 covers Burmese: it
includes the basic glyphs, but not the OpenType tables necessary for
proper rendering of the script.

When I made the font, I had no information on Kharosthi halant forms
(or whatever they're called - I don't work in Indic scripts much),
so I left it with the silly glyph it has for a Kharosthi virama.

Is there an actual vowel-killer symbol in Kharosthi?

I have since come by information on the glyph shapes. I began to work
on incorporating it into my font, but gave up for a number of reasons:

1. Some of the glyphs I needed to draw from scratch, which takes a lot
of time
2. The other ones, I would have to create composites manually, which
takes time but not as much.
3. I had intended for the current release of the font to be at least
somewhat stable
4. I am very bad with OpenType tables. Yes, I made them for MPH Yangon,
but I tried to make an Arabic font and, well, I totally fucked it
up. I am afraid to proceed to the creation of opentype tables for my new
experimental Syriac font. I might try copying them from an existing font,
but it would probably take a lot of work to adapt it. It would be easier
if I discarded ligatures, which is certainly an option since ligatures
are often wildly different in Nestorian and Jacobite varieties.
5. I am lazy.
6. One of my main motivations for creating fonts is my political
philosophy. I believe that people being able to process text in
their indigenous language in some small way helps them move towards
self-determination. There is currently no population which uses Kharosthi
as its "native script". Only academics have a need to type it, so I don't
feel the same pressure. This isn't to say that I don't care - I do -
but rather that it is less of a priority for me and I don't feel as bad
putting it off as I did when I put off fixing the Tifinagh codepoints.
7. I am lazy AND busy at the same time. I am currently sitting on my bum,
which I do most of the day. I read my e-mail alot and talk to people
over the internet alot. Other than that, I don't do a whole lot, but
when I do, I work on it very determinedly, and right now I'm busy with
a Sardinian-English dictionary.

In short, I may fix it someday. I do sincerely doubt that somebody else
won't produce a better Kharosthi font in the meantime, however. In fact
you are welcome, if you should so desire, to use my glyphshapes to make
a new font.

As for the inspiration for the glyphshapes: I interpolated the outlines
of a couple of different existing Kharosthi fonts, then interpolated
the result and my own drawings of the glyphs.

--------------------------------------------
Date: Mon, 9 May 2005 02:40:29 -0700 (PDT)
From: Andrew Glass <asg@u.washington.edu>

I was interested to see that you had taken the trouble to make a Kharosthi
font. It is exciting to see that people have noticed that Kharosthi is
now part of Unicode, and a complement to our efforts to have it included
in the first place, Thank you!

As for the font, as Stefan has pointed out, and you are aware, Kharosthi
is a complex font, and not surprisingly, you haven't made OpenType tables
(yet). I made the font which is used in the Unicode tables - and have
expermimented with various GSUB AND GPOS tables, but no software currently
supports these tables, so the fact that the tables are lacking in your
font is rather mute for the time being.

In answer to your question,

Is there an actual vowel-killer symbol in Kharosthi?

No, there is no explicit symbol in Kharosthi for halant, hence the
control symbol. In the very few cases in where a halant-form of a
sign is attested in the literature, it is formed by writing it as a
subscript. When I create the OT tables for this character, I will map
to a duplicate set of the base glyphs which are approximately 50% of
full size and set lower on the writing line.

For further information about Kharosthi, please check the Unicode
proposal, and my MA thesis.

http://depts.washington.edu/ebmp/downloads/Kharoshthi.pdf
http://depts.washington.edu/ebmp/downloads/Glass_2000.pdf

I am currently working on a revised version of my Gandhari Unicode font,
once work on this is complete, I will finish adding OpenType tables to
the Kharosthi font I have prepared. If you are interested, I will let
you know when work on this is complete.

Best wishes and congratulations for producing the first Kharosthi Unicode
font available on the internet.

--------------------------------------------
Date: Mon, 09 May 2005 21:36:04 +0800
From: Paul Wise <pabs@zip.to>

On Sun, 2005-05-08 at 19:06 -0700, Stefan Baums wrote:

> Please do not package this font as is.

It has already been packaged, no-one has sponsored the upload yet.

BTW, thanks go to the three of you for the interesting discussion on
fonts :)

I'm not very familiar with OpenType/fonts, or editing them, so I'd have
to defer any changes to Mark.

--------------------------------------------
Date: Mon, 9 May 2005 13:51:18 -0700
From: Stefan Baums <baums@u.washington.edu>

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.

--------------------------------------------
Date: Mon, 9 May 2005 20:25:43 -0700
From: Mark Williamson <node.ue@gmail.com>

> 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.)

Limbu text isn't messed up in my font. True, there are no opentype tables,
but if you think that is actually as big a problem as it is for Kharosthi,
you are very wrong - I was actually /thanked/ by some Limbu guy in Nepal
for having the first Unicode font to support his language, and on top
of that he did not make any bug reports. From what I know about Limbu,
complex shaping requirements are minimal and text can be read almost as
easily without them.

As regards Kharosthi, although it may not display properly, I am pretty
sure that text in Kharosthi in my font is still readable, although it
definitely doesn't look good and is probably very difficult and irritating
to read.

I think it's similar to the way that many Chinese linguistics journals
write Mongolian script horizontally due to typographic limitations,
and nobody makes a big fuss.

In addition, if I did have the OT tables for Kharosthi, I don't believe
there is any support in _any_ OS for some of the complex rendering
nessecary for the language.

I'm also under the impression that the situation of hPhags-pa is similar
to that of Limbu, although I don't know much about the script.

> 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.

I highly disagree. If you are interested in publishing a newspaper in
the language, then you are indeed correct - it would not be acceptable.

But if you are using it in a scholarly document otherwise writtten in
English, the Kharosthi should still be perfectly readable - it's in the
wrong direction, yes, it uses an ugly control symbol where there should be
conjunct consonants, yes, but for me at least English is still readable
when written backwards or upside down, and Arabic is still readable when
written using all isolated forms (although it is irritating, after a
while it becomes easier to read).

And regarding Limbu I must protest again: I'm pretty sure there are no
problems big enough with the current Limbu rendering that somebody would
not want to use it to print a newspaper.

> 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.

"discourages enthusiastic developers who want to get started somewhere"
- if you really want, you are welcome to dismantle my font and totally
revamp it. I would like to know, but you don't have to tell me, and you
can even sell it for 300 bucks for a 1 computer licence.

Are you saying that these enthusiastic developers would be less
discouraged if there were no Kharosthi support /at all/ in Debian? I
somehow doubt it - my font provides them with basic glyphshapes already,
which they would otherwise have to come up with on their own, and all they
have to come up with is opentype tables and a good name for their font.

And I will repeat, this does _not_ impact multiple scripts.

-------------------------------------------
Date: Mon, 9 May 2005 21:18:00 -0700
From: Stefan Baums <baums@u.washington.edu>

> From what I know about Limbu, complex shaping requirements are
> minimal and text can be read almost as easily without them.

I am glad to hear that.

> As regards Kharosthi [...]  although it definitely doesn't look
> good and is probably very difficult and irritating to read.

Yes.

> I think it's similar to the way that many Chinese linguistics
> journals write Mongolian script horizontally due to typographic
> limitations,

No, the effect is greater.  This is not just about the writing direction,
but consonants and vowels won’t get connected correctly.

> In addition, if I did have the OT tables for Kharosthi, I don't
> believe there is any support in _any_ OS for some of the complex
> rendering nessecary for the language.

That is correct.  A chicken‐and‐egg problem, since as long as there
isn’t a font, people won’t feel motivated to add the rendering
code either.  Though from what I hear on the Pango development list,
the Indic script code that they have is actually fairly generic, and
needs only minor tweaking for adding new Indic fonts.  Then again,
things may be complicated by the right‐to‐left writing direction
of Kharoṣṭhī.  That will be for the programmers to sort out, which
I am not, so I concentrate on the encoding and font side.

> I'm also under the impression that the situation of hPhags-pa is
> similar to that of Limbu, although I don't know much about the
> script.

Neither do I, but here is a page

   http://www.ancientscripts.com/hphagspa.html

that says hPhags‐pa (like Tibetan, from which it is derived) uses medial
vowel signs (which aren’t illustrated on that page).  The encoding of
Tibetan (and therefore presumably hPhags‐pa) is handled differently
from the standard Indian model in Unicode.

> But if you are using it in a scholarly document otherwise
> writtten in English, the Kharosthi should still be perfectly
> readable

Here I disagree.  Yes, scholarly applications is what we are interested
in, and there rendering needs to be _accurate_.  At least as much as in
a hypothetical newspaper.

> - it's in the wrong direction, yes, it uses an ugly control
> symbol where there should be conjunct consonants,

For a scholarly publication, those are major and unacceptable points
right there.  Add to that the fact that vowels would not be correctly
connected with their bases.

Also, this is not just for palaeographic discussions with the occasional
letter in Kharoṣṭhī.  For that we would not have needed an
encoding the first places, but could just have inserted a few images.
Rather, think of whole new applications that make actual use of the
computer‐encoded form of the Kharoṣṭhī material, like comprehensive
palaeographic databases.  Have a look at:

   http://www.indoskript.de/

> I somehow doubt it - my font provides them with basic
> glyphshapes already, which they would otherwise have to come up
> with on their own, and all they have to come up with is opentype
> tables and a good name for their font.

First and foremost, let me stress that your development of those
glyph shapes is _highly_ appreciated.  It really makes us happy to see
that people outside our small circle start getting interested in the
Kharoṣṭhī script, now that it is included in Unicode.

So now we have actually quite a number of glyph shapes in different
styles.  Not only yours, the letter illustrations that
Andrew uses throughout his MA thesis (that he sent you a link to) are
also outlines in TrueType format.  The next step forward will now be to
develop a set of OpenType rules, and maybe we can even agree on common
glyph naming schemes and such, so that we can easily share those OpenType
rules between our fonts and yours. That would be great.

> And I will repeat, this does _not_ impact multiple scripts.

Even if none of the other scripts in your font need complex rendering
rules, there is still the fontconfig issue.  Definitely
not your fault, but fontconfig’s.  But since fontconfig is the basis
for font matching in Debian, and since this is about making a package
for Debian, the problem has to be addressed and worked around until
(hopefully) fontconfig becomes smart enough to look beyond the glyphs
and recognise which fonts also have combining rules.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: