[HarfBuzz] HarfBuzz 1.0 API; the message you were hoping would never come

[Konstantin Ritt]

 2014/1/24 Konstantin Ritt <ritt.ks at gmail.com>
>
> > the other
>> > shapers doesn't respect the scale factor and truncation may occur there
>> (i.e.
>> > double advance = ..; pos->x_advance = advance;). This also leads to
>> unexpected
>> > results since 1) pos->x_advance / 64.0 ~= 0 and 2)
>> > CTFontCreateWithGraphicsFont (face_data->cg_font, font->y_scale, NULL,
>> NULL)
>> > falls back to pointSize=12 when y_scale is out of bounds. (BTW, what
>> ppem is
>> > for, then?)
>>
>> Then this is a bug that should be fixed.  We should just use
>> font->y_scale /
>> 64. here, and scale back the results accordingly.
>>
>
> But if you set scale to upem, font->y_scale / 64 won't give you a correct
> pixelSize.
> That's the dilemma -- if scale is aimed to mean "pixelSize", then the
> behavior looks unified but em_scale() above and all other shapers would
> return truncated result (note: not rounded); if it could be any value, like
> `pixelSize * 64` in my case, then the behavior certainly differers from
> shaper to shaper.
>
>
>>
>>
>> > I'd propose change hb_position_t to be in 26.6 float format everywhere
>> and
>> > explicitly mention that in the docs.
>>
>> The 26.6 is NOT enforced and is NOT a limitation of the code.  For
>> example,
>> you can do all layout in "font space" by setting scale to upem.
>>
>
> Yes. But making it enforced breaks nothing, however solves the truncation
> issue once and for all.
> I mean it is still possible to do all layout in "font space" by setting
> scale to upem, the only difference is that that output values are 26.6
> floats rather than ints. 26 bits for integrals won't cause overflows for
> calculations in design metrics.
>
>
>>
>>
>> > This would guarantee an expected/unified
>> > results for any shaper, w/o having to do some tricky scaling.
>>
>> That tricky scaling shouldn't be needed.  If it is, it's a bug we should
>> fix.
>>
>
> At least, I can not avoid using it w/o getting truncated results.
>

Well, sometimes two images could worth hundred of words :)
26.6 metrics on the left image, int32 metrics on the right image; both on
Mac 10.7 with default font settings.
Note that whilst a series of 'i' looks better with integer metrics (nothing
unexpected, though), "Ed" and "Times New Roman" looks just awful due to
truncation issue.
Without doing that "fancy scaling" trick, it is not possible to get
rendering as on left image.


[image: Встроенное изображение 3]


Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20140127/f2d6b91c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HB-trunc.png
Type: image/png
Size: 116769 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20140127/f2d6b91c/attachment-0001.png>