Expose some fields from the FreeType metrics out via FontMetrics....

Expose some fields from the FreeType metrics out via FontMetrics.
This is needed by the text shaper used in Chrome.

[evan, 2010-06-29 21:42:55]

This is ugly, but a cleaner way of doing this isn't apparent to me.

[reed, 2010-06-29 22:13:02]

On 2010/06/29 21:42:55, evan wrote:
> This is ugly, but a cleaner way of doing this isn't apparent to me.

Aren't these additional values already available from the canvas?
SkCanvas::getTotalMatrix() returns the complete CTM, which provides even more
data than just scale in X,Y (which is what you're getting from freetype).

[evan, 2010-06-29 22:16:47]

On 2010/06/29 22:13:02, reed wrote:
> On 2010/06/29 21:42:55, evan wrote:
> > This is ugly, but a cleaner way of doing this isn't apparent to me.
> 
> Aren't these additional values already available from the canvas?
> SkCanvas::getTotalMatrix() returns the complete CTM, which provides even more
> data than just scale in X,Y (which is what you're getting from freetype).

I *believe* these scales are font-relative units -- that is, deep inside
Harfbuzz it reaches deep into the font's GPOS table, extracts a number, and then
wants to multiply it by a 26.6 number that I'm fetching here.  (That is, these
numbers should be independent of the current transformation matrix.)  But I also
know very little about what I'm talking about except for the above comment about
how the multiplication happens.

[reed, 2010-07-01 14:42:44]

You're right that these are matrix independent, since they come from a call
purely on the Paint, which just as pointsize and its other font-related
attributes.

I think this patch is still unneeded, esp. in this public API. I think these
extra fields are basically just copies of the input (i.e. the paint), and you
could therefore just extract them directly from the paint for your purposes.

e.g.

xppem = paint.getTextSize()

We don't echo other inputs in this struct (e.g. typeface), so I'm not sure we
need to add these fields... unless these are *not* obviously deducible from the
paint. Maybe I'm wrong.

[evan, 2011-01-19 23:51:20]

On 2010/07/01 14:42:44, reed wrote:
> xppem = paint.getTextSize()
> 
> We don't echo other inputs in this struct (e.g. typeface), so I'm not sure we
> need to add these fields... unless these are *not* obviously deducible from
the
> paint. Maybe I'm wrong.

Remember this old change?  I'm returning to it now!
Some background to jog your memory: deep inside the complex text shaper, in its
implementation of GPOS table attributes, it uses a few numbers -- the ones I
naively exposed by this patch.

I still don't think it's correct, but I seek your advice on how to make it
correct.


It appears these numbers vary per font, independent of the paint settings.  I
wrote a simple dumper that dumps some fields out of FreeType, given a character
size and font file.  To make things simpler, I provided a size of 1 so that we
can see numbers without additional scaling.

$ ~/ttf/dump 1 /usr/share/fonts/truetype/ttf-devanagari-fonts/nakula.ttf 
units_per_EM 2048
x_ppem 1
y_ppem 1
x_scale 0x800 0.031250

$ ~/ttf/dump 1 /usr/share/fonts/truetype/ttf-devanagari-fonts/lohit_kok.ttf 
units_per_EM 1024
x_ppem 1
y_ppem 1
x_scale 0x1000 0.062500

For easy clicking, here are the FreeType docs on the relevant fields:
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.h...

With different font sizes, I can see that x_ppem = the input size, and x_scale =
a function of units_per_EM and the input size.  The former I can get directly
from the SkPaint.  But it seems for the latter I still need some way of getting
at font-specific conversion factor for font units.

I'm still not certain how to get that number out of Skia.  Any advice?

[reed1, 2011-01-23 02:19:40]

I still don't clearly see what is needed that isn't already present, except
perhaps units-per-em. If that is what is needed, the right place to return that
is (I think) the SkTypeface (since it is independent of matrix and pointsize).

That said, I certainly don't know the complex shaper, so perhaps a phone call is
due, so we can exchange more info.

On 2011/01/19 23:51:20, evan wrote:
> On 2010/07/01 14:42:44, reed wrote:
> > xppem = paint.getTextSize()
> > 
> > We don't echo other inputs in this struct (e.g. typeface), so I'm not sure
we
> > need to add these fields... unless these are *not* obviously deducible from
> the
> > paint. Maybe I'm wrong.
> 
> Remember this old change?  I'm returning to it now!
> Some background to jog your memory: deep inside the complex text shaper, in
its
> implementation of GPOS table attributes, it uses a few numbers -- the ones I
> naively exposed by this patch.
> 
> I still don't think it's correct, but I seek your advice on how to make it
> correct.
> 
> 
> It appears these numbers vary per font, independent of the paint settings.  I
> wrote a simple dumper that dumps some fields out of FreeType, given a
character
> size and font file.  To make things simpler, I provided a size of 1 so that we
> can see numbers without additional scaling.
> 
> $ ~/ttf/dump 1 /usr/share/fonts/truetype/ttf-devanagari-fonts/nakula.ttf 
> units_per_EM 2048
> x_ppem 1
> y_ppem 1
> x_scale 0x800 0.031250
> 
> $ ~/ttf/dump 1 /usr/share/fonts/truetype/ttf-devanagari-fonts/lohit_kok.ttf 
> units_per_EM 1024
> x_ppem 1
> y_ppem 1
> x_scale 0x1000 0.062500
> 
> For easy clicking, here are the FreeType docs on the relevant fields:
>
http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.h...
> 
> With different font sizes, I can see that x_ppem = the input size, and x_scale
=
> a function of units_per_EM and the input size.  The former I can get directly
> from the SkPaint.  But it seems for the latter I still need some way of
getting
> at font-specific conversion factor for font units.
> 
> I'm still not certain how to get that number out of Skia.  Any advice?