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 _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
