Re: [ft-devel] FT_Get_Advance() docs

[Werner LEMBERG]

Hello Antoine!


> Another point can be made that the "default" behaviour (when
> load_flags=0) for FT_Get_Advance is to return the *hinted*
> advances :-( Some can even be see it as a bug, but I cannot decide
> if either of documentation or of code.

It's clearly a documentation-only bug, caused by the unfortunate
`default' sentence.

> Even stranger is that the /documented/ behaviour has been /applied/
> to CFF fonts, in
> http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=14de111f
> (last hunk, replacing advance.[xy] with linear{Hori,Vert}Advance.)

This is not correct.  In CFF's (and all other PS flavours), advance
widths are *never* hinted if the native hinter is used.  The only
difference between `advance.[xy]' and `linear{Hori,Vert}Advance' is
that the former is in 26.6 and the latter in 16.16 format.  The commit
you mention fixes the scaling.

> I am not sure (so comment are welcome), but also I remember that a
> property of "light rendering" was to not change the advance (i.e.,
> enforce AF_SCALER_FLAG_NO_ADVANCE); see also
> http://lists.nongnu.org/archive/html/freetype-devel/2008-09/msg00000.html;
> under such a constraint/compromise, it does make sense to take the
> quick path to compute the advances.

This is correct.  However, this condition is not carved in stone and
might change (even if this is unlikely), thus the `fast only' test
flag.

> On the other side, if advances could be modified by "light" hinting
> in the same way as it can with "normal" hinting, then I believe the
> FT_Get_Advance() function should not take the quick way in the
> former case but not the later, should it?

Exacly.  `Quick advance widths' essentially means `advance widths
won't be changed by the hinting process'.

> Does something changed on this area since September 2008?

No.  The original poster's confusion was only due to bad
documentation, as far as I can see.

> Also on a related point, in TrueType there is a way to get the
> hinted advances quicker than executing the full bytecode program,
> even if it is not alluded above: when the requested ppem has an
> associated hdmx/VDMX table within the font.  Why it is not currently
> available in Freetype I do not know.

Noone has requested it.  Do you volunteer to implement support for
those two tables?  I currently lack the time in doing that by myself.

> If memory serves, a number of [bad] fonts out there have this data
> wrong, which could be a problem (it certainly was seen as a real
> problem for Microsoft a few years ago.)

Well, ...

> Also, perhaps the Freetype byte code interpreter does not exactly
> issue the same results as the patented one (read Apple, S. Kaasila,
> and Microsoft), so perhaps we can have unwelcome differences here.

Not that I'm aware of.

> Or perhaps it is just lack of time which prevented the add of a
> 'fast loading' version for TrueType-with-bytecode (see David's
> comment dated 2008-09-01 in Changelog.23)

This might be a possible reason.

> Finally, after that whole area has been cleaned up, we should
> revisit the FAQ:
> http://www.freetype.org/freetype2/docs/ft2faq.html#other-bbox is out
> of phase.

Patches please!


    Werner