<div dir="ltr"><div>Hi guys, </div><div> </div><div>There is yet another issue left out of the scope: </div><div>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.</div> <div>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).</div> <div>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?)</div> <div> </div><div>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.</div> <div>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).</div> <div> </div><div>Correct me if I'm wrong.</div><div> </div><div>Best regards, Konstantin <div class="gmail_quote">2014/1/6 Konstantin Ritt <<a href="mailto:ritt.ks@gmail.com" target="_blank">ritt.ks@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div><div class="h5"> <div class="gmail_quote">2014/1/6 Khaled Hosny <<a href="mailto:khaledhosny@eglug.org" target="_blank">khaledhosny@eglug.org</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 </blockquote></div><div> </div></div></div><div>Oh, I thought I'm the only one who felt into that trouble :)</div><div> </div><div>Here is a result of my tries and fails:</div><div>[code] </div> <div> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> ushort *log_clusters = ...; const uint num_glyphs = hb_buffer_get_length(buffer); hb_glyph_info_t *infos = hb_buffer_get_glyph_infos(buffer, 0);</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> for (uint i = 0; i < num_glyphs; ++i) {</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> log_clusters[i] = infos[i].cluster; // ... glyphs[i] = infos[i].codepoint; and so on }</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> // adjust clusters</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> uint glyph_pos = 0;</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> for (uint i = 0; i < num_characters; ++i) {</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> if (i != infos[glyph_pos].cluster) {</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> for (uint j = glyph_pos + 1; j < num_glyphs; ++j) {</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> if (i <= infos[j].cluster) {</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> if (i == infos[j].cluster)</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> glyph_pos = j;</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> break;</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> }</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> }</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> }</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> log_clusters[i] = glyph_pos;</pre> <pre style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> }</pre></div><div> [/code] <div class="gmail_extra"> <div>You could agree that the latter part is not obvious.</div><div>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)".</div> <div> </div><div>Regards, Konstantin</div></div> </div></div> </blockquote></div> </div></div>