Hi,
Op 2 mrt 2011, om 04:24 heeft Werner LEMBERG het volgende geschreven:
Below you can find two links to images (from David Turner, who is
testing and evaluating the warping stuff again). Please compare.
http://img848.imageshack.us/img848/9311/wikigitwarpoff.png
Not sure if you were inviting comments from interested bystanders
too, but I do think that the 'warp off' image has more consistent
visual density.
Thanks for chiming in. I'm interested in all opionions; the more, the
better.
The weight from glyph to glyph seems to have more variation with
If the bottom line of the warped glyph is shifted away from a
bluezone, then the whole glyph should be shifted back a whole
1 pixel back toward the bluezone after being warped.
This won't work. If you shift one pixel back, all other optimized
zones, would be at the wrong position.
Werner LEMBERG w...@gnu.org writes:
What is improvable, however, is
the algorithm to decide which stems are `main features', and which
features (e.g. serifs) must be handled specially. In particular,
handling of diagonal stems might be improved.
BTW, that's what sort of worried me about the
On 2011-03-01, Werner LEMBERG w...@gnu.org wrote:
If the bottom line of the warped glyph is shifted away from a
bluezone, then the whole glyph should be shifted back a whole
1?pixel back toward the bluezone after being warped.
This won't work. If you shift one pixel back, all other
On 2011-03-01, Miles Bader mi...@gnu.org wrote:
Werner LEMBERG w...@gnu.org writes:
What is improvable, however, is
the algorithm to decide which stems are `main features', and which
features (e.g. serifs) must be handled specially. In particular,
handling of diagonal stems might be
Currently it's a compile-time option,
cf. AF_CONFIG_OPTION_USE_WARPER.
Oops! Forgot to commit and push. Now it's really in the git
repository.
Below you can find two links to images (from David Turner, who is
testing and evaluating the warping stuff again). Please compare.
On 03/01/11 22:24, Werner LEMBERG wrote:
Interestingly, David thinks that the autohinter warping produces much
worse results, while I consider exactly the opposite...
I agree with David :). I guess warping may produce superior results if
combined with correct lsb/rsb adjustment. But
[Umpf. Large emails are rejected by nongnu.org without giving any
reasons. I would have expected that they get queued and I have to
approve them as the list administrator of freetype-devel.]
Interestingly, David thinks that the autohinter warping produces
much worse results, while I
Werner LEMBERG w...@gnu.org writes:
Below you can find two links to images (from David Turner, who is
testing and evaluating the warping stuff again). Please compare.
http://img848.imageshack.us/img848/9311/wikigitwarpoff.png
http://img852.imageshack.us/img852/3342/wikigitwarpon.png
From: Miles Bader mi...@gnu.org
Subject: Re: [ft-devel] a hidden gem: the autohint warper code
Date: Wed, 02 Mar 2011 16:01:28 +0900
Werner LEMBERG w...@gnu.org writes:
Below you can find two links to images (from David Turner, who is
testing and evaluating the warping stuff again). Please
*I have noticed however that inter-character spacing can still
*affected under LIGHT hinting, is that a bug?
Good question. I don't know yet, but I'm studying the code right
now and I probably can answer this soon.
I've just played a bit with ftdiff: Activating the light hinter
(by
however are there any plans to make it warp in the y direction?
No. By its very nature, such warping can't happen in the `main'
hinting direction $(Q#|(B you would get uneven glyph heights if you do so.
Also, does it operate in tandem with existing hinting techniques, or
as an
On 28 Feb 2011, at 23:10, Werner LEMBERG wrote:
however are there any plans to make it warp in the y direction?
No. By its very nature, such warping can't happen in the `main'
hinting direction $(Q#| you would get uneven glyph heights if you do so.
Could it not do something like pick a
On 2011-02-28, Werner LEMBERG w...@gnu.org wrote:
however are there any plans to make it warp in the y direction?
No. By its very nature, such warping can't happen in the `main'
hinting direction – you would get uneven glyph heights if you do so.
Without blue zone treatment, glyphs always
No. By its very nature, such warping can't happen in the `main'
hinting direction $(Q#|(B you would get uneven glyph heights if you do
so.
Could it not do something like pick a selection of key letters and
work out how best to vertically warp these, using the scoring
system, and then
On 1 Mar 2011, at 09:19, Werner LEMBERG w...@gnu.orgmailto:w...@gnu.org
wrote:
No. By its very nature, such warping can't happen in the `main'
hinting direction $(Q#|(B you would get uneven glyph heights if you do
so.
Could it not do something like pick a selection of key letters and
work
No. By its very nature, such warping can't happen in the `main'
hinting direction – you would get uneven glyph heights if you do so.
Without blue zone treatment, glyphs always have uneven bottom line.
I think the warp can be combined with bluezone management.
I don't think this is possible.
18 matches
Mail list logo
