freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Just Fill Bugs
Subject: Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Date: Sun, 01 May 2011 15:27:40 +0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15pre) Gecko/20110207 Shredder/3.1.9pre

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.


Attachment: grid-lin-nq8.png
Description: PNG image

Attachment: grid-zhi-nq8.png
Description: PNG image

Attachment: grid-xiang-nq8.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]