[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A protuberant Chinese pixel
From: |
Wenlin Institute |
Subject: |
Re: A protuberant Chinese pixel |
Date: |
Thu, 19 Oct 2000 21:07:04 -0700 |
Werner, you were right. I changed this:
ttOutline.dropout_mode = (TT_Char) 5;
to this:
ttOutline.dropout_mode = (TT_Char) 0;
and the protuberant Chinese pixel disappeared. With
dropout_mode = 1, 2, or 4 the result is the same as with 5.
Unfortunately, with dropout_mode = 0 there are drop-outs in
other kinds of strokes.
In the process of making the following short demo program, I
discovered that the "ornament" at the left side of the stroke
is also involved.
#include <stdio.h>
#include "freetype.h" /* Compiled with FreeType 1.2 */
#define N_POINTS 8 /* Change to 7 for surprising result. */
static TT_Vector points[N_POINTS] = {
{560, 288},
#if (N_POINTS == 8)
{416, 252},
#endif
{320, 384},
{3226, 384},
{3415, 635},
{3572, 571},
{3771, 360},
{3810, 288},
};
static TT_Byte flags[N_POINTS] = {1,
#if (N_POINTS == 8)
1,
#endif
1, 1, 1, 0, 0, 1};
#define WIDTH 72
#define HEIGHT 12
static unsigned char bitmap[((WIDTH+7)/8)*HEIGHT];
int main(void)
{
TT_Engine ttEngine;
TT_Raster_Map ttMap;
TT_Outline ttOutline;
TT_UShort ttContour = N_POINTS - 1;
unsigned char *p;
size_t row, col;
if (TT_Init_FreeType(&ttEngine) != 0) {
return 1;
}
ttMap.flow = TT_Flow_Down;
ttMap.rows = HEIGHT;
ttMap.width = WIDTH;
ttMap.cols = (WIDTH + 7) / 8;
ttMap.size = (long) sizeof(bitmap);
ttMap.bitmap = bitmap;
ttOutline.points = points;
ttOutline.flags = flags;
ttOutline.contours = &ttContour;
ttOutline.n_contours = 1;
ttOutline.n_points = N_POINTS;
ttOutline.high_precision = 1;
ttOutline.second_pass = 1;
ttOutline.owner = 0;
ttOutline.dropout_mode = (TT_Char) 5;
if (TT_Get_Outline_Bitmap(ttEngine, &ttOutline, &ttMap) != 0) {
return 1;
}
p = bitmap;
for (row = 0; row < HEIGHT; row++) {
unsigned char bit = 0x80;
for (col = 0; col < WIDTH; col++) {
fputc(((*p) & bit) ? 'O' : '-', stdout);
if ((bit >>= 1) == 0) {
++p;
bit = 0x80;
}
}
fputc('\n', stdout);
}
return 0;
}
Here is the output:
-----------------------------------------------------------
--------------------------------------------------O--------
-------------------------------------------------OOOO------
-------------------------------------------------OOOOO-----
------------------------------------------------OOOOOOO----
--OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO---
---OOO--------------------------------------------------O--
-----------------------------------------------------------
If dropout_mode is changed to 0, the output is:
-----------------------------------------------------------
--------------------------------------------------O--------
-------------------------------------------------OOOO------
-------------------------------------------------OOOOO-----
------------------------------------------------OOOOOOO----
--OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO---
---OOO-----------------------------------------------------
-----------------------------------------------------------
Or, if N_POINTS is changed to 7 (discarding the second
point), (regardless of dropout_mode) the result is:
-----------------------------------------------------------
-------------------------------------------------O---------
------------------------------------------------OOOO-------
------------------------------------------------OOOOO------
-----------------------------------------------OOOOOOO-----
--OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO----
-----OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO---
-----------------------------------------------------------
where one would expect the change to be limited to the left
end. (Or maybe that's a naive expectation by someone who
doesn't understand drop-out control :-) Since the main
body of the stroke is bounded by two exactly horizontal
straight lines, it's surprising that its thickness could
be altered by the presence or absence of a "serif" at one
end.
I revised the illustration:
http://www.wenlin.com/freetype.gif
Anyway, it's just one stupid pixel. FreeType is great!
Thanks,
Tom
At 01:31 PM 10/19/00 +0200, Werner LEMBERG wrote:
>
>Sorry for the late response.
>
>> There is one small point where it looks like the rasterizer could do
>> better. A picture and brief description are at this URL:
>>
>> http://www.wenlin.com/freetype.gif
>>
>> I don't know the internals of the rasterizer well enough to tell
>> where the problem is in the source code, but it seems to involve
>> rounding one way or the other from a coordinate exactly half-way
>> between pixel boundaries (64*n+32 where n is an integer).
>
>It would be nice if you could send us some demo code (i.e., a simple C
>program with outline data) which shows the problem.
>
>> By the way, the Chinese character outlines in which the protuberant
>> pixel is manifested don't come from a TrueType font file (though
>> they could have).
>
>Have you experimented with different drop-out modes? Currently, the
>rasterizes only uses drop-out mode #2. This is hard-coded in
>ftraster.c in the function Render_Glyph; look for the line
>
> ras.dropOutControl = 2;
>
>Maybe you should try a different one.
>
>
> Werner
>
Wenlin Institute, Inc. Software for Learning Chinese
E-mail: address@hidden Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)