On 12-Oct-2012 23:56, Felix Miata wrote:
On 2012-10-12 18:15 (GMT-0400) mathog composed:
Can somebody suggest what I might be doing wrong to cause the
cumulative
text extent to not scale linearly with font size * DPI?
I would give it another try using DPIs that M$ expects most desktops
to be using, all multiples of 12. So, use e.g. 72, 96, 120, 144, 192,
288 and see if you like the results better. Key on 96 as your
baseline, since that's what most Windows and Mac desktops use, many
Linux environments force, and clueless web designers presume whether
they know it or not. 96 is even in the CSS specs.
More data:
FT_LOAD_TARGET_NORMAL,FT_KERNING_UNFITTED
Pnts Dpi Tot.Adv. Ratio
16 72 8173
32 72 16539 2.023614
64 72 33590 2.030957
128 72 66732 1.986663
256 72 133336 1.998082
16 75 8621
32 75 16985 1.970189
64 75 34995 2.060347
128 75 69478 1.985369
256 75 139468 2.007369
16 96 10919
32 96 22543 2.064566
64 96 44381 1.968726
128 96 89275 2.011559
256 96 178165 1.995687
16 150 16985
32 150 34995 2.060347
64 150 69478 1.985369
128 150 139468 2.007369
256 150 278039 1.993568
In all cases the total extent starts to approach the expeced FS*DPI
ratio,but only at very large font sizes.
Vary a couple of other parameters:
FT_LOAD_TARGET_NORMAL,FT_KERNING_UNFITTED
Pnts Dpi Tot.Adv. Ratio kern Adv-kern Ratio-kern
16 72 8173 -19 8192
32 72 16539 2.023614 -37 16576 2.023438
64 72 33590 2.030957 -74 33664 2.030888
128 72 66732 1.986663 -148 66880 1.986692
256 72 133336 1.998082 -296 133632 1.998086
FT_LOAD_TARGET_NORMAL,FT_KERNING_DEFAULT
Pnts Dpi Tot.Adv. Ratio kern Adv-kern Ratio-kern
16 72 8192 0 8192
32 72 16512 2.015625 -64 16576 2.023438
64 72 33600 2.034884 -64 33664 2.030888
128 72 66752 1.986667 -128 66880 1.986692
256 72 133312 1.997124 -320 133632 1.998086
FT_LOAD_NO_SCALE,FT_KERNING_UNFITTED
Pnts Dpi Tot.Adv. Ratio kern Adv-kern Ratio-kern
16 72 16712 -19 16731 1.000000
32 72 16694 1.001078 -37 16731 1.000000
64 72 16657 1.002221 -74 16731 1.000000
128 72 16583 1.004462 -148 16731 1.000000
256 72 16435 1.009005 -296 16731 1.000000
FT_LOAD_NO_SCALE,FT_KERNING_DEFAULT
Pnts Dpi Tot.Adv. Ratio kern Adv-kern Ratio-kern
16 72 16731 0 16731 1.000000
32 72 16667 1.003840 -64 16731 1.000000
64 72 16667 1.000000 -64 16731 1.000000
128 72 16603 1.003855 -128 16731 1.000000
256 72 16411 1.011699 -320 16731 1.000000
Clearly the last two have a problem - when FT_LOAD_NO_SCALE is employed
the kerning still scales
with font size, while the advance does not. Moreover, it does not do
so consistently, because
Pnt32 should be -32, not -64, and Pnt16 sould be -16, not 0. Take the
kerning out of the advances
calculated in the last two groups and the ratio is 1.0, as it should
be. For the first groups the total
scaled advance, including kerning, approaches the expected FS*DPI
scaling factor for very large font sizes.
One more test...
FT_LOAD_NO_SCALE,FT_KERNING_UNFITTED
Pnts Dpi Tot.Adv. Ratio kern Adv-kern Ratio-kern
16 144 16694 -37 16731 1.000000
32 144 16657 1.002221 -74 16731 1.000000
64 144 16583 1.004462 -148 16731 1.000000
128 144 16435 1.009005 -296 16731 1.000000
256 144 16139 1.018341 -592 16731 1.000000
As expected, kern values doubled, so kerning is always scaled by
(FS*DPI) even when advance is not scaled.
The application here is the automatic reassembly of formatted text.
That is if the original
text was "Red Green Blue", with the words colored as indicated by their
names, then when written to EMF, PDF,
(or most other graphics formats) the result would be three strings "Red
", "Green ", "Blue". To reassemble
the offset from the end of "Red " to the start of "Green " must be
known precisely, and that appears to be very
much a function of how the application that reads these three strings
in has set up FreeType. This one
happens to be for Inkscape, and that has:
src/libnrtype/FontInstance.cpp: if (FT_Load_Glyph (theFace,
glyph_id, FT_LOAD_NO_SCALE | FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP)) {
and no call to FT_Get_Kerning(), at least directly.
Now the million dollar question: what are the units for advance.x and
what determines the scale for
advance.x for FT_LOAD_NO_SCALE?
These examples all used Arial, which is a 12 point TT font (weight 80,
width 100) and the measured distance of "First Second Third" starting on
the origin of the "F", and ending on the origin of the next following
character is 129.448 points.
The relationship between total advance calculated, total advance
measured, and point size is apparently not "simple":
16731/129.448 = 129.248810
16731/(12*129.448) = 10.770734
16731/(129.448/12) = 1550.985724
Thanks,
David Mathog
mathog@xxxxxxxxxxx
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
