[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] FT_Get_Advance() docs
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] FT_Get_Advance() docs |
Date: |
Sat, 03 Dec 2011 00:23:00 +0100 (CET) |
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