|
|
|
Expose some fields from the FreeType metrics out via FontMetrics.
This is needed by the text shaper used in Chrome.
Patch Set 1 #
Total messages: 6
|
evan
This is ugly, but a cleaner way of doing this isn't apparent to me.
|
15 years, 6 months ago (2010年06月29日 21:42:55 UTC) #1 | ||||||||||||||||||||||
This is ugly, but a cleaner way of doing this isn't apparent to me.
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).
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.
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.
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?
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?