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

[Konstantin Ritt]

> 26.6 metrics on the left image, int32 metrics on the right image; both on
Mac 10.7 with default font settings.

Any comments, thoughts? (aka ping)

Regards,
Konstantin


2014-01-27 18:55 GMT+02:00 Konstantin Ritt <ritt.ks at gmail.com>:

>  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/20140222/cf63c7a0/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/20140222/cf63c7a0/attachment-0001.png>