Re: [ft-devel] [Patch] CJK autofit/autohint blue zones

[suzuki toshiya]

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 that Korean font without
CJK Ideographs are not so irregular (I think all Korean dejure standard
of coded character sets include CJK Ideorgaphs, but...!), so I inserted
"hani" (OpenType terminology to mean CJK Ideographs) to the name of
the collection of sample CJK Ideographs to compute bluezones. Maybe
I will work for sample characters for Hangul and some Indic scripts
in future.

Regards,
mpsuzuki

Just Fill Bugs wrote:
> On 04/29/2011 01:22 AM, address@hidden wrote:
>> Looking at "想意理生當着" of afoff-afold-afnew_gray_wqyzh0945.png,
>> I think that your patch removes the bumps of surplus vertical stems
>> crossing the lowest horizontal stems of "當着" and lifts the lowest
>> stems of "想意" to align to the lowest stems of other glyphs.
>>
>> I think the bumps of surplus vertical stems crossing the lower
>> horizontal stem (lower-right and lower-left of "口" ) is very
>> popular design of CJK Ideographs, and they are expected to be
>> ignored in low resolution rasterization. So the lower bluezone
>> implementation is good to include. BTW, I'm not sure if lower
>> bluezone should have filled/unfilled distinction. If you have
>> any example showing the requirement, please let me know.
> 
> Well, the filled and unfilled distinction cannot be shown in wqy-zenhei
> with the current state of the freetype2 stem detection. Some of the filled
> stem terminal can be detected, some cannot. As can be seem from '林'
> with my visual segment patch for ftgrid.
> 
> Initially, I was trying to keep vertical stems and horizontal stems to
> align to their own bluezone when the bluezone are different enough.
> maybe at 20pt or 24pt, the 2 blue zones could differ more than 1 pixel.
> 
> 2ndly, since glyphs end with vertical stem has different bottom from
> those end with horizontal stem, By using both filled and unfilled blue
> zones, we can have a bigger range to snap nearby edges.
> 
> Since the matched blue zone is calculated from the absolute distance
> before a blue zone to an edge, when the 2 blue zones are different,
> we effectively can have a reasonable larger blue zone to match more
> candidate stems.
> 
> see 林 and 置.
> 
> Now I think the 2nd reason overweight the 1st because blue zone is
> most useful at smaller size.
> 
>> About the other bluezones, it's difficult for me to recognize
>> remarkable improvement. Talking about the height/width proportion
>> of "想意", the non-autofitted results look like same size, but
>> both (old/new) autofitted results look like different size
>> (rather, "想" looks like as taller than "意").
> 
> That's obviously because we failed to detect a top segment/edge for
> the 2 glyphs. Therefore we cannot 'lift' the top edges of the glyphs. At the
> same time, the first detected horizontal edges are grid-fit to the lower
> grid. The result is a pressed down perception on the top of the glyphs.
> 
> Cannot do much with blue zone before we can detect all the ending of a
> stem and also the extrema of a diagonal stem. It's not a problem of the
> blue zone fitting.
> 
> Well, maybe for the 想, if we can relax the threshold for finding matching
> blue zone, the top of 目 will be matched to top blue zone and be lifted.
> 
> Don't know how much false positive will get if we relax the threshold.
> It will look bad if the horizontal stem of 木 in 想 also matches
> the top blue zone. :(
> 
>> Also the legibility
>> of upper parts of "它" and "當" gets worse than old autofitter.
> 
> That is the horizontal blue zone effect. Since you planned to turn
> horizontal blue zone off, it should not be a problem.
> 
> The other solution is to always expand the blue zones at smaller point
> so we can be guaranteed to have greater or equal sized glyph.
> 
> At lease we can use a 1/4 pixel as threshold for rounding blue zones
> instead of 1/2 pixel  we are currently used.
> 
> The threshold for detecting matched blue zone can also be changed for
> smaller font. But that can be done once the blue zone code is in place.
> 
>> In summary, I think the lower bluezone would be worth to include
>> in next release, but others are questionable, if my samples
>> are appropriate to understand your proposals. Anyway, I think
>> your approach is very good and I want to decide after complete
>> reproduction of the demonstration. If GNU/Linux binary is acceptable,
>> I will upload my ftstring binaries.
>>
> 
> It's ok with me. The bottom line zig-zag is an immediate problem for
> CJK font at small size. Others are just bonus.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> This body part will be downloaded on demand.