于 07/04/2012 11:28 PM, Werner LEMBERG 写道:
please test the current git. I have slightly changed the code in the
auto-hinter which recognizes flat segments; it now accepts a broader
group of shapes. As a consequence, handling of serif fonts like
Palatino or Quattrocento should be much improved.
On 05/14/2011 02:46 AM, Just Fill Bugs wrote:
The 主,些,它,生,里 are not adjusted by the blue zone because their
bottom line were too high in the original design. With compensation, the
distance between blue zone to the un-adjust bottom line increased by 1px.
To conclude, if we cannot catch the
On 05/13/2011 09:32 PM, Werner LEMBERG wrote:
In af_cjk_metrics_scale_dim(), when we scale the blue zone to the
font size, the blue zone is also rounded to pixel grid. The offset
introduced in the rounding at both the bottom and top could have
undesirable effect on the glyph height at certain f
On 05/13/2011 09:01 PM, Алексей Подтележников wrote:
Why do you even create and calculate temporary shoot_delta?
You can explicitly increment/decrement blue->shoot.fit the same way
you do blue->ref.fit.
Like this:
+AF_CJKBlue blue;
+
+if ( delta_t>= delta_b )
+{
+
In af_cjk_metrics_scale_dim(), when we scale the blue zone to the font
size, the blue zone is also rounded to pixel grid. The offset introduced
in the rounding at both the bottom and top could have undesirable effect
on the glyph height at certain font size.
There are 4 states for the sum of t
On 05/12/2011 01:02 AM, suzuki toshiya wrote:
> I attached 3 pictures comparing 4 cases for Japanese hi quality commercial
> PostScript fonts (Ryumin-Light, GothicBBB-Medium and Shuei-Min. Ryumin-Light
> and GothicBBB-Medium would be the most referential font in Japanese market
> because they are b
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 for
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 one
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
Freetype-
On 05/07/2011 01:35 PM, Werner LEMBERG wrote:
Thanks for you suggestions! Working with bytecode instructions must
be actively trained, like any other programming language, then the
obstacles diminish.
Just for the fun of it, I installed the xgridfit. Learnt and wrote a
xgridfit version of
On 04/30/2011 04:07 AM, Werner LEMBERG wrote:
I've had some hope to show working bytecode stuff at the beginning of
May, but things are a bit more complicated, unfortunately: While the
library has been extended to support generated bytecode already, I
have first to define some auxiliary bytecode
On 04/29/2011 02:01 PM, Just Fill Bugs wrote:
This patch adds the -s and -u options to start ftgrid for a given UTF-8
character or unicode code in a font.
Ping?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org
On 05/05/2011 03:37 AM, Werner LEMBERG wrote:
>> It turned out that the culprit was, that the surrounding anchor points
>> have no 'out direction' when searching for segments. [...]
>>
>> Cross out that part will solve the problem for "一" , of cause might
>> also screw up some other parts. It's the
I traced the autofit a bit to find out why some segments were missed at
the ends of stems. like the vertical segments at the end of 一 of
wqy-zenhei.ttc
It turned out that the culprit was, that the surrounding anchor points
have no 'out direction' when searching for segments.
The code in afhi
On 05/01/2011 03:27 PM, Just Fill Bugs wrote:
> On 04/29/2011 01:22 AM, mpsuz...@hiroshima-u.ac.jp wrote:
>> About the other bluezones, it's difficult for me to recognize
>> remarkable improvement. Talking about the height/width proportion
>> of "想意", the n
On 04/29/2011 01:22 AM, mpsuz...@hiroshima-u.ac.jp 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 s
This patch adds the -s and -u options to start ftgrid for a given UTF-8
character or unicode code in a font.
diff --git a/src/ftgrid.c b/src/ftgrid.c
index 711da2b..7860c7e 100644
--- a/src/ftgrid.c
+++ b/src/ftgrid.c
@@ -66,6 +66,7 @@ typedef struct status_
int ptsize;
int
On 04/24/2011 02:05 PM, Werner LEMBERG wrote:
I very much dislike the use of afhints.h and aftypes.h within the user
space. Could you instead add debug hooks to afhints.c which can be
used for communication? The simplest form could be something like
these two functions:
FT_Error
af_glyph
Oops, a bug fixed.
diff --git a/src/autofit/afcjk.c b/src/autofit/afcjk.c
index c15d343..2be157a 100644
--- a/src/autofit/afcjk.c
+++ b/src/autofit/afcjk.c
@@ -45,8 +45,456 @@
/*/
/*
On 04/21/2011 09:24 PM, Just Fill Bugs wrote:
I meant some steps were missing in the code. The bluezone is not
properly grid fit before the numbers being used to align segments.
There are indeed some problems with the patch. They happened when
the bluezones were scaled at
On 04/22/2011 09:06 PM, Just Fill Bugs wrote:
Besides, the vertical segments are abnormal. There are some non-uniform
drift from where it supposed to be. I don't know where the problem are.
Apparently, handle->hinted = 0 will not completely disable hinting. 'V'
and 'H
On 04/20/2011 02:52 PM, Werner LEMBERG wrote:
Are there any tool which visually present segments of autofit
module? Something like stems shown in the glyph view of fontforge.
No, but I'll probably add this to ftgrid since it would be helpful for
my work on the ttfautohint stuff. But it isn't
On 04/20/2011 09:27 PM, mpsuz...@hiroshima-u.ac.jp wrote:
> On Wed, 20 Apr 2011 14:53:08 +0200 (CEST)
> Werner LEMBERG wrote:
>
>>> It's kinda weird because the bluezones should be grid fit before
>>> being used to align stems. In the pictures, the top bluezone was
>>> obviously not grid fit. Ma
On 04/20/2011 08:34 PM, Just Fill Bugs wrote:
> On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote:
>> Maybe my impression about vertical bluezone is based on the
>> typography in Japanese market, so, I don't think this is
>> generic. Please let me know if th
On 04/20/2011 06:35 PM, Werner LEMBERG wrote:
>
> Thanks for reviewing. Do you have an idea how to increase the
> legibility of the longest strokes? Contrary to the proposed patch I
> think that this what you suggest is quite hard a job to achieve since
> you not only have to do feature analysis
On 04/20/2011 07:31 PM, mpsuz...@hiroshima-u.ac.jp wrote:
>
> Here is the anti-aliasing comparison. The patch makes
> the contrast of some top horizontal strokes (因, 置,
> 里, 面) weak.
>
It's kinda weird because the bluezones should be grid fit before being
used to align stems.
In the pictures, th
On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote:
> Q1) The vertical bluezones are essential?
>
> In vertical CJK typography, there would be the requirement
> to align long center stems (of the glyphs like "十", "土",
> "王"), to pretend the centerlines of the glyphs are aligned.
> However, I
27 matches
Mail list logo
