[...] I also found this bug, and used about the same fix as you
committed. The only difference is a minor nit, in the case
FT_LOAD_NO_SCALE is used and the quick way failed with ErrNotImplem,
10 scaling might not be done.
Patch, please (or please commit by yourself).
The next two are more
Werner LEMBERG wrote:
While looking at the whole issue more closely, I've identified at
least four bugs :-( One is extremely serious, making
`FT_Get_Advance' return wrongly scaled values if fast advance
loading isn't available (now fixed in git).
Yesterday I was away from my mail, but I also
While looking at the whole issue more closely, I've identified at
least four bugs :-(
One is extremely serious, making `FT_Get_Advance' return wrongly
scaled values if fast advance loading isn't available (now fixed in
git). IMHO, it's very embarassing that we haven't found this scaling
problem
Werner LEMBERG wrote:
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/msg0.html;
under such a
Behdad Esfahbod wrote:
In Chromium, there's a bug being discussed right now about what the expected
return value of FT_Get_Advance() is:
http://code.google.com/p/chromium/issues/detail?id=66073
If I understand correctly the bug report, particularly the advance.cc
snippet (and without peeking
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
Testing suggests that [FT_Get_Advance] returns
glyph-linearHoriAdvance, not glyph-advance.x. This is
understandable, but unintuitive and not documented.
Hmm.
In fact, the following suggests that FT_Get_Advance() may in fact
take hinting into account:
This is correct.
But apparently it
or FT_Get_Advances will fail with
FT_Err_Unimplemented_Feature.
Graham
From: Werner LEMBERG w...@gnu.org
To: beh...@behdad.org
Cc: freetype-devel@nongnu.org
Sent: Wednesday, 30 November 2011, 14:30
Subject: Re: [ft-devel] FT_Get_Advance() docs
Testing suggests
I know this isn't a welcome remark, but I'm going to say it anyway,
because it's a rule I apply to myself: if an API is difficult to
explain then it should be changed.
:-) Fortunately, it's not me to blame for the design of this API. And
I haven't written the documentation either.
Yes, I
The problem that your description starts with long cumbersome condition.
Start description with what the flag actually does:
FT_ADVANCE_FLAG_FAST_ONLY:
. Enable quick retrieval of advance in the special cases of
- unhinted (FT_LOAD_NO_HINTING),
- lightly hinted (FT_RENDER_MODE_LIGHT),
The problem that your description starts with long cumbersome
condition. Start description with what the flag actually does:
FT_ADVANCE_FLAG_FAST_ONLY:
. Enable quick retrieval of advance in the special cases of
- unhinted (FT_LOAD_NO_HINTING),
- lightly hinted
Hi,
In Chromium, there's a bug being discussed right now about what the expected
return value of FT_Get_Advance() is:
http://code.google.com/p/chromium/issues/detail?id=66073
Testing suggests that it returns glyph-linearHoriAdvance, not
glyph-advance.x. This is understandable, but unintuitive
12 matches
Mail list logo
