I'm sorry for long long delay after your first post of blue zone patch.
Just I've committed your patch to git head.
Testing the latency for bluezone calculation by ftbench, I found that
the bluezone patched version is not slower than the original.
BTW, from a Korean expert in SC34/WG2, I heard
On 05/08/2011 06:32 PM, suzuki toshiya wrote:
I'm sorry for long long delay after your first post of blue zone patch.
Just I've committed your patch to git head.
Thanks for your review and commit work.
___
Freetype-devel mailing list
Now that the CJK blue zone code are in the freetype repository, further
tweak on the parameters can be performed.
One thing that I can think of is that the threshold of best_dist0 used
in the af_cjk_hints_compute_blue_edges(). best_dist0 is used to
initialize the snap distant from edges to
Hi,
If further tweak is needed for CJK bluezone, the code
would be unmatured, I will disable it by default.
In fact, the original demonstration was given by 11pt
glyph of WenQuanYi-ZenHei, but your new tweak seems to
change the dist value for the glyphs smaller than 17pt
I think 17pt is
On 05/09/2011 08:21 AM, mpsuz...@hiroshima-u.ac.jp wrote:
If further tweak is needed for CJK bluezone, the code
would be unmatured, I will disable it by default.
In fact, the original demonstration was given by 11pt
glyph of WenQuanYi-ZenHei, but your new tweak seems to
change the dist value
How long do you need to find stable values for the tunable
parameters?
This is never finished :-) Even for the latin autohinter, improvements
or different approaches are always possible (cf. `latin2').
If it is difficult to estimate, I will propose new API
to manipulate the parameters by
