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

[Konstantin Ritt]

Hi guys,

There is yet another issue left out of the scope:
hb_position_t is a typedef of int32_t, you know, and to avoid
float-to-integer truncation the proposed solution was to specify scale
factor shifted left.
For example to make all results in 26.6 float format, scale shall be
shifted 6 bits left and then the result must be divided to 64.0 to get the
original float (well, almost original but 6 digit after the point is quite
enough for all use-cases).
However, the scale factor applied to results in OT shaper only, 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?)

I'd propose change hb_position_t to be in 26.6 float format everywhere and
explicitly mention that in the docs. This would guarantee an
expected/unified results for any shaper, w/o having to do some tricky
scaling.
We could also want to introduce an API to fine-tune the hinting preference,
so that all metrics would be either in design units or in hinted advances
(after a brief review, it looks like it isn't possible to achieve that on
client side only).

Correct me if I'm wrong.

Best regards,
Konstantin

2014/1/6 Konstantin Ritt <ritt.ks at gmail.com>

>
> 2014/1/6 Khaled Hosny <khaledhosny at eglug.org>
>
>> Another thing that I’d like to see sorted before the API is finalised,
>> is reverse mapping of output glyphs to input characters with proper
>> handling of combing marks. I feel we should keep the current cluster
>> stuff since it might have its uses (I’m not sure though) and introduce a
>> separate way for that mapping. Either way, I think a more indicative
>> name would be better (it took me sometime to understand what those
>> clusters are for and they mislead me quit a bit when I tried to use
>> HarfBuzz for the first time).
>>
>> Regards,
>> Khaled
>>
>
> Oh, I thought I'm the only one who felt into that trouble :)
>
> Here is a result of my tries and fails:
> [code]
>
>         ushort *log_clusters = ...;
>
>         const uint num_glyphs = hb_buffer_get_length(buffer);
>
>         hb_glyph_info_t *infos = hb_buffer_get_glyph_infos(buffer, 0);
>
>         for (uint i = 0; i < num_glyphs; ++i) {
>
>             log_clusters[i] = infos[i].cluster;
>
>
>             // ... glyphs[i] = infos[i].codepoint; and so on
>         }
>
>
>         // adjust clusters
>
>         uint glyph_pos = 0;
>
>         for (uint i = 0; i < num_characters; ++i) {
>
>             if (i != infos[glyph_pos].cluster) {
>
>                 for (uint j = glyph_pos + 1; j < num_glyphs; ++j) {
>
>                     if (i <= infos[j].cluster) {
>
>                         if (i == infos[j].cluster)
>
>                             glyph_pos = j;
>
>                         break;
>
>                     }
>
>                 }
>
>             }
>
>             log_clusters[i] = glyph_pos;
>
>         }
>
> [/code]
>
> You could agree that the latter part is not obvious.
> And except of bringing some inconvenience to the user, lack of reverse
> mapping API also hits the performance a bit since we can not avoid this
> loop with "if (num_glyphs != num_characters)".
>
> Regards,
> Konstantin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20140123/6687eaa4/attachment.html>