<div dir="ltr"><div>
2014/1/24 Konstantin Ritt <span dir="ltr"><<a href="mailto:ritt.ks@gmail.com" target="_blank">ritt.ks@gmail.com</a>></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> the other<br>
> shapers doesn't respect the scale factor and truncation may occur there (i.e.<br>
> double advance = ..; pos->x_advance = advance;). This also leads to unexpected<br>
> results since 1) pos->x_advance / 64.0 ~= 0 and 2)<br>
> CTFontCreateWithGraphicsFont (face_data->cg_font, font->y_scale, NULL, NULL)<br>
> falls back to pointSize=12 when y_scale is out of bounds. (BTW, what ppem is<br>
> for, then?)<br>
<br>
Then this is a bug that should be fixed.  We should just use font->y_scale /<br>
64. here, and scale back the results accordingly.<br></blockquote><div><br></div></div><div>But if you set scale to upem, font->y_scale / 64 won't give you a correct pixelSize.</div><div>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.</div>


<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
> I'd propose change hb_position_t to be in 26.6 float format everywhere and<br>
> explicitly mention that in the docs.<br>
<br>
</div>The 26.6 is NOT enforced and is NOT a limitation of the code.  For example,<br>
you can do all layout in "font space" by setting scale to upem.<br></blockquote><div><br></div></div><div>Yes. But making it enforced breaks nothing, however solves the truncation issue once and for all.</div><div>


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.</div>


<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
<br>
> This would guarantee an expected/unified<br>
> results for any shaper, w/o having to do some tricky scaling.<br>
<br>
</div>That tricky scaling shouldn't be needed.  If it is, it's a bug we should fix.<br></blockquote><div><br></div></div><div>At least, I can not avoid using it w/o getting truncated results.</div></div></blockquote>

<div><br></div><div>Well, sometimes two images could worth hundred of words :)</div><div>26.6 metrics on the left image, int32 metrics on the right image; both on Mac 10.7 with default font settings.</div><div>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.</div>

<div>Without doing that "fancy scaling" trick, it is not possible to get rendering as on left image.</div><div> </div>
</div><div><br><img src="cid:ii_143d4934ed61d573" alt="Встроенное изображение 3"><br><br></div><div><br></div><div>
Regards,<br>Konstantin
</div><br></div>