[Top][All Lists]

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

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

From: mpsuzuki
Subject: Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Date: Fri, 29 Apr 2011 02:22:50 +0900

Sorry for lated review. I've attached 2 PNGs:

* afoff-afold-afnew_gray_wqyzh0626.png
  comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.6.26
  - autofit is off
  - old autofit (git 2011-04-18)
  - new autofit (git 2011-04-18 + your patch version 2.1)

* afoff-afold-afnew_gray_wqyzh0945.png
  comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.9.45
  - autofit is off
  - old autofit (git 2011-04-18)
  - new autofit (git 2011-04-18 + your patch version 2.1)

Please check if afoff-afold-afnew_gray_wqyzh0945.png reproduces
the points you wanted to improve. For simplicity, I didn't apply
the blurring patch for overcrowded strokes. If it is required,
I will remake examples.

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.

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 "意"). Also the legibility
of upper parts of "它" and "當" gets worse than old autofitter.

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.


On Sat, 23 Apr 2011 10:01:23 +0200 (CEST)
Werner LEMBERG <address@hidden> wrote:

>> There are indeed some problems with the patch. They happened when
>> the bluezones were scaled at af_cjk_metrics_scale_dim() [...]
>> I update the patch to the current git and address the problems.
>> Please review the logic behind the idea.
>Thanks!  I leave this to Toshiya-san for testing.
>> There could be other improvements when scaling the bluezone. Like
>> under small size, round the bluezones to the ceiling
>> unconditionally.  That could make glyph bigger and clearer.  But
>> could make it 1 pixel extra bigger than the intended size.
>Well, what is the `intended size'?  As we all know, it's impossible to
>exactly find out the bbox of a glyph string without actually rendering
>it, and it rarely happens that you get for, say, a 10pt font at 72dpi
>a bbox height of 10 pixels.  Additionally, bytecode instructions in
>TrueType fonts modify the size also, sometimes rather drastically --
>in other words, I don't mind if a patch increases the size by one
>pixel if legibility improves, provided this size fits (more or less)
>with the non-CJK glyphs in the same font.
>    Werner
>Freetype-devel mailing list

Attachment: afoff-afold-afnew_gray_wqyzh0626.png
Description: PNG image

Attachment: afoff-afold-afnew_gray_wqyzh0945.png
Description: PNG image

reply via email to

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