SILGraphite: rendering non-roman scripts

Greetings Sharon,

I highly recommend you bring up this issue on the OpenType list. At the 
Type Tech Forum in Prague, there was a lengthy informal discussion 
about vertical metrics definition inconsistencies across OSes, 
libraries, applications and fonts. John Hudson brought it up. He and 
his colleague Ross do lots of technical consulting work for Microsoft 
and a number of foundries. There are people aware of these problems and 
probably already have work underway, and I suspect they would value 
your input. I believe Peter Constable was in that room at the time, so 
he might be a good contact.

If you like, I can with your permission cross-post your question to the 
list myself.

Regards,
--John

Dear Sharon,

>For instance, Doulos SIL has considerable internal leading. When the app
>requests a 20 point font, this translates into 26 pixels on a typical
>device. The LOGFONT gets the value -26 to request the height of the font.
>But the resulting font has an ascent of 30 pixels and a descent of 10
>pixels, which is actually 40 pixels in height.
>
>My question is: is there a need for a height method that returns the height
>that was originally used to set up the internal font, as opposed to
>ascent+descent? Is there any need for the client app to get this
>information back from the font? If so, is there a better name? Like:
>  
>
My first question is: what information does Graphite need to query from 
the font? We aren't writing a generalised font querying API here. If 
people want that, they can create a subclass with all the extra methods 
in, etc. So, assuming Graphite needs to know the em square, then we only 
need an em square querying API. I think that the exta ascent information 
in GDL was a wrong way to go and should be deprecated.

GB,
Martin

Sharon:
> >For instance, Doulos SIL has considerable internal leading. When the app
> >requests a 20 point font, this translates into 26 pixels on a typical
> >device. The LOGFONT gets the value -26 to request the height of the
font.
> >But the resulting font has an ascent of 30 pixels and a descent of 10
> >pixels, which is actually 40 pixels in height.
> >
> >My question is: is there a need for a height method that returns the
height
> >that was originally used to set up the internal font, as opposed to
> >ascent+descent? Is there any need for the client app to get this
> >information back from the font? If so, is there a better name? Like:

Martin:
> My first question is: what information does Graphite need to query from
> the font? We aren't writing a generalised font querying API here. If
> people want that, they can create a subclass with all the extra methods
> in, etc. So, assuming Graphite needs to know the em square, then we only
> need an em square querying API. I think that the exta ascent information
> in GDL was a wrong way to go and should be deprecated.

Okay, so I should just implement what the Graphite engine needs? Well, that
makes it easy.

I guess I'm still a little confused about the purpose of having both the
getFontMetrics method (which Tim originally marked "protected") and the
ascent, descent, and height methods (which Tim called "public"). I gather
from what Tim said that the protected methods are the ones that the various
subclasses of Font should implement, and the public methods are the ones
that the Graphite engine calls? If were the  case, then we need a public
emSquare method for sure. But doesn't totally make sense to me because
Graphite definitely needs to directly call some of the other methods Tim
called "protected"--getTable, getGlyphMetrics, getGlyphPoint.

I'm not on the OpenType list, but I wouldn't at all object to somebody else
bringing up this topic there. I'm trying to think specifically of what kind
of information we really need (since I know from experience that certain
kinds of questions spawn off discussions about all kinds of things that
wouldn't really worth reporting back here). At this point probably a
summary of the different approaches that are used across the OSes,
libraries, etc, to specify font height/vertical metrics would be useful. If
you would like to do that, John, you're welcome.


John Butler wrote:
> Greetings Sharon,
>
> I highly recommend you bring up this issue on the OpenType list. At the
> Type Tech Forum in Prague, there was a lengthy informal discussion
> about vertical metrics definition inconsistencies across OSes,
> libraries, applications and fonts. John Hudson brought it up. He and
> his colleague Ross do lots of technical consulting work for Microsoft
> and a number of foundries. There are people aware of these problems and
> probably already have work underway, and I suspect they would value
> your input. I believe Peter Constable was in that room at the time, so
> he might be a good contact.
>
> If you like, I can with your permission cross-post your question to the
> list myself.
>
> Regards,
> --John