[ft-devel] Make FT_GlyphSlot_Embolden standard API?
Hi all, As fontconfig and xft already have the code to "embolden" and rely on FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden should be made standard API. This is an important feature for Chinese (maybe also Japanese and Korean) users, as most Chinese fonts don't have a real bold style. What do you think? Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 11:44:59AM +0900, [EMAIL PROTECTED] wrote:
> Hi
>
> On Thu, 12 May 2005 23:44:11 +0800
> Chia I Wu <[EMAIL PROTECTED]> wrote:
> >As fontconfig and xft already have the code to "embolden" and rely on
> >FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden
> >should be made standard API. This is an important feature for Chinese
> >(maybe also Japanese and Korean) users, as most Chinese fonts don't have
> >a real bold style.
> >
> >What do you think?
>
> I'm unfamiliar with this API and never checked the bolden result in
> detail, could you show some demo program?
I've made a quick hack to ftview.c for demo. See applied patch.
>
> As you pointed out, most CJK font family does not provide "bold" style.
> I think "weight" (XXX-Light, XXX-Medium, XXX-Heavy etc) - may take
> similar role of it in the typographical viewpoint. But, most personal
> computers are shipped with only 1 or 2 fonts for each CJK scripts,
> and synthesized "bold" is often used in documents generated by PC.
The only commercial fonts I own are Dynaware's. They have severial
weights for each family, named by XXX-W3, XXX-W4, XXX-W5, etc. But no
application take advantage of that to get better quality.
Also, the size of a Chinese font is very large, ranaging from 5MB to
25MB (the 25MB one includes glyphs of both traditional and simplicial
Chinese). I personally prefer synthesized bold than having all those
weights installed.
>
> Considering there is such root of embolding request, I wonder whether
> FT_GlyphSlot_Embolden() API is already enough for the purpose. It does
> not receive much parameters to control embolding (am I misunderstanding?).
> I'm afraid several control parameters are requested in future, for example:
>
> * strength to embolding
I think this is important.
> * switch to enable/disable changing glyph metrics in embolding
> * switch to enable/disable embolding of bitmap font
I think glyph metrics should be changed automagically. Bitmap glyph
should be emboldened automatically too. As we are synthesizing, you know
you can't expect a high-quality result, thus it makes no difference
which format the glyph is in.
> * choosing embolding algorithm
>
BTW, I have done some experiment to embolden a bitmap glyph, by printing
the same glyph severial times (depending on strength), with starting
point shift to the right by 1 pixel each time. The result is ok.
> How do you think of?
>
> Regards,
> mpsuzuki
Index: src/ftview.c
===
RCS file: /cvsroot/freetype/ft2demos/src/ftview.c,v
retrieving revision 1.58
diff -u -r1.58 ftview.c
--- src/ftview.c4 Mar 2005 05:58:35 - 1.58
+++ src/ftview.c13 May 2005 06:06:25 -
@@ -131,20 +131,23 @@
gindex = get_glyph_index( gindex );
#endif
error = FT_Load_Glyph( size->face, i, FT_LOAD_NO_BITMAP );
- if ( !error && slot->format == FT_GLYPH_FORMAT_OUTLINE )
+ if ( !error )
{
FT_Glyph glyphb;
+FT_GlyphSlot_Embolden( slot);
error = FT_Get_Glyph( slot, &glyphp );
if ( error )
goto Next;
+ /*
error = FT_Glyph_Stroke( &glyphp, stroker, 1 );
if ( error )
{
FT_Done_Glyph( glyphp );
goto Next;
}
+ */
error = glyph_to_bitmap( glyphp, &bit3, &left, &top,
&x_advance, &y_advance, (FT_Pointer*)&glyphb
);
@@ -654,7 +657,8 @@
break;
case grKEY( ' ' ):
- render_mode = ( render_mode + 1 ) % 4;
+ //render_mode = ( render_mode + 1 ) % 4;
+ render_mode = (render_mode == 0) ? 2 : 0;
switch ( render_mode )
{
case 0:
@@ -664,9 +668,8 @@
new_header = (char*)"rendering test text string";
break;
case 2:
- new_header = (char*)"rendering stroked text";
+ new_header = (char*)"rendering emboldened text";
break;
-
default:
new_header = (char*)"rendering glyph waterfall";
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 05:33:54PM +0900, [EMAIL PROTECTED] wrote: > >> * switch to enable/disable changing glyph metrics in embolding > >> * switch to enable/disable embolding of bitmap font > >I think glyph metrics should be changed automagically. > > Umm, yes, so, when fixed-width font is embolded, the result can be > proportional? I think there are many X applications (terminal emulators > and curses applications may be typical examples) which assumes/expects > the Hanzi glyphs are always fixed to full-width, regardless with > bold/oblique style. Therefore (if i'm not misunderstanding) switch > to enable/disable changing glyph metrics is required. > If we don't change glyph metrics accordingly, won't the script be rendered wrongly (e.g. two glyphs comes too close)? I think we should always keep glyph metrics correct, i.e. since "width", "height", "bearings" are changed, we should keep it up-to-date. Then there leaves some flexibility in "advance". I don't know how applications determine whether a font is monospace or not. Fontconfig uses "advance" to do so and I think it's reasonable. So maybe we can let user set whether they want fixed advance or not. > >Bitmap glyph should be emboldened automatically too. > >As we are synthesizing, you know you can't expect a high-quality result, > >thus it makes no difference which format the glyph is in. > > Yet I've not tested in detail, I have no strong objection at present. > One of my anxiety is: in some UCS collective fonts, bitmap data is > provided to partial glyphs. For example, TrueType font bundled in AIX > has bitmap data for Hanzi, but no bitmap data for Bopomofo. You are worrying about inconsistency? When one tries to embolden a mixed sequence of both outline and bitmap glyphs, yes, he gets inconsistency , since we use different algorithms for both kinds of glyphs. But if we embolden only outline glyphs, he still gets inconsistency. Furthermore, we are not forcing he to embolden every glyph. He can just skip bitmap glyphs. > > >> * choosing embolding algorithm > >> > >BTW, I have done some experiment to embolden a bitmap glyph, by printing > >the same glyph severial times (depending on strength), with starting > >point shift to the right by 1 pixel each time. The result is ok. > > How do you think of embolding procedure for high-resolution output > (like printing device) and vector device? Well, I don't know how that work. Does it make a big difference? (I am really asking :P) > > Regards, > mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 13, 2005 at 07:51:12AM +0200, Werner LEMBERG wrote: > > > As fontconfig and xft already have the code to "embolden" and rely > > on FT_GlyphSlot_Embolden to do the real job, I think > > FT_GlyphSlot_Embolden should be made standard API. This is an > > important feature for Chinese (maybe also Japanese and Korean) > > users, as most Chinese fonts don't have a real bold style. > > Basically, I don't object, but this won't happen in the next release > which is in pretest stage right now. Sure. After some more inspection, I find there is already FT_Glyph for glyph manipulation. Then, why not FT_Glyph_Embolden FT_Glyph_Oblique ? Also I tried to modify the embolden algorithm for outline glyph, and it now uses similar algorithm as the one I use for bitmap glyph. This is done because the old algorithm generates some artifact. See: http://www.olv.idv.tw/~olvaffe/tmp/freetype2/b-old.png http://www.olv.idv.tw/~olvaffe/tmp/freetype2/b-new.png ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] consistency of ftoutln.c and ftbitmap.c
Hi all, I am trying to make ftbitmap.c the same thing to FT_Bitmap as ftoutln.c is to FT_Outline, but there's one problem. FT_Outline has "flags" and yet FT_Bitmap don't. I plan to add "flags" to FT_Bitmap and removes FT_GLYPH_OWN_BITMAP from FT_GlyphSlot_InternalRec. Will this break anything? Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] using FT_Bitmap_* calls in ftglyph.c
Hi all,
This patch moves ft_bitmap_copy from ftglyph.c to ftbitmap.c and makes
ftglyph.c depends on ftbitmap.c.
The old dependency is:
ftbitmap.c
ftglyph.c (code for FT_Bitmap manipulation duplicated)
/
ftoutln.c
And now it is:
ftbitmap.c
\
ftglyph.c
/
ftoutln.c
It also adds some error checkings to ftoutln.c.
Index: include/freetype/ftbitmap.h
===
RCS file: /home/cvs/freetype2/include/freetype/ftbitmap.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftbitmap.h
--- include/freetype/ftbitmap.h 15 May 2005 07:10:28 - 1.1.1.1
+++ include/freetype/ftbitmap.h 16 May 2005 02:34:47 -
@@ -69,6 +69,29 @@
/*/
/* */
/* */
+ /*FT_Bitmap_Copy */
+ /* */
+ /* */
+ /*Copies an bitmap into another one. */
+ /* */
+ /**/
+ /*source :: A handle to the source bitmap. */
+ /* */
+ /* */
+ /*target :: A handle to the target bitmap. */
+ /* */
+ /* */
+ /*FreeType error code. 0 means success. */
+ /* */
+ FT_EXPORT_DEF( FT_Error )
+ FT_Bitmap_Copy( FT_Librarylibrary,
+ const FT_Bitmap *source,
+ FT_Bitmap*target);
+
+
+ /*/
+ /* */
+ /* */
/*FT_Bitmap_Convert */
/* */
/* */
Index: src/base/ftbitmap.c
===
RCS file: /home/cvs/freetype2/src/base/ftbitmap.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftbitmap.c
--- src/base/ftbitmap.c 15 May 2005 07:10:28 - 1.1.1.1
+++ src/base/ftbitmap.c 16 May 2005 02:41:24 -
@@ -18,8 +18,7 @@
#include
-#include FT_FREETYPE_H
-#include FT_IMAGE_H
+#include FT_BITMAP_H
#include FT_INTERNAL_OBJECTS_H
@@ -39,6 +38,65 @@
/* documentation is in ftbitmap.h */
FT_EXPORT_DEF( FT_Error )
+ FT_Bitmap_Copy( FT_Librarylibrary,
+ const FT_Bitmap *source,
+ FT_Bitmap*target)
+ {
+FT_Memory memory = library->memory;
+FT_Error error = FT_Err_Ok;
+FT_Int pitch = source->pitch;
+FT_ULong size;
+
+
+if ( source == target )
+ return FT_Err_Ok;
+
+if ( source->buffer == NULL )
+{
+ *target = *source;
+
+ return FT_Err_Ok;
+}
+
+if ( pitch < 0 )
+ pitch = -pitch;
+size = (FT_ULong)( pitch * source->rows );
+
+if ( target->buffer )
+{
+ FT_Inttarget_pitch = target->pitch;
+ FT_ULong target_size;
+
+
+ if ( target_pitch < 0 )
+ target_pitch = -target_pitch;
+ target_size = (FT_ULong)( target_pitch * target->rows );
+
+ if ( target_size != size )
+ FT_QREALLOC( target->buffer, target_size, size );
+}
+else
+ FT_QALLOC( target->buffer, size );
+
+if ( !error )
+{
+ unsigned char *p;
+
+
+ p = target->buffer;
+ *target = *source;
+ target->buffer = p;
+
+ FT_MEM_COPY( target->buffer, source->buffer, size );
+}
+
+return error;
+ }
+
+
+ /* documentation is in ftbitmap.h */
+
+ FT_EXPORT_DEF( FT_Error )
FT_Bitmap_Convert( FT_Librarylibrary,
const FT_Bitmap *source,
FT_Bitmap*target,
Index: src/base/ftglyph.c
===
RCS file: /home/cvs/freetype2/src/base/ftglyph.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftglyph.c
--- src/base/ftglyph.c 15 May 2005 07:10:28 - 1.1.1.1
+++ src/base/ftglyph.c 16 May 2005 02:38:28 -
@@ -31,6 +31,7 @@
#include
#include FT_GLYPH_H
#include FT_OUTLINE
[ft-devel] [patch] several memory leaks when more than one glyph slot are created
Hi,
Changes are list below, though currently no module uses more than one
glyph slot in a face.
* fixed a memory leak in FT_Done_GlyphSlot
* removed a non-necessary loop in T42_GlyphSlot_Done
* prepend glyph slot to face->glyph when FT_New_GlyphSlot is called,
otherwise a new second glyph slot cannot be done
Index: base/ftobjs.c
===
RCS file: /home/cvs/freetype2/src/base/ftobjs.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftobjs.c
--- base/ftobjs.c 15 May 2005 07:10:28 - 1.1.1.1
+++ base/ftobjs.c 16 May 2005 15:37:15 -
@@ -348,11 +348,9 @@
FT_GlyphSlot slot;
-if ( !face || !aslot || !face->driver )
+if ( !face || !face->driver )
return FT_Err_Invalid_Argument;
-*aslot = 0;
-
driver = face->driver;
clazz = driver->clazz;
memory = driver->root.memory;
@@ -370,8 +368,15 @@
goto Exit;
}
- *aslot = slot;
+ slot->next = face->glyph;
+ face->glyph = slot;
+
+ if ( aslot )
+ *aslot = slot;
}
+else if ( aslot )
+ *aslot = 0;
+
Exit:
FT_TRACE4(( "FT_New_GlyphSlot: Return %d\n", error ));
@@ -386,25 +391,30 @@
{
if ( slot )
{
- FT_Driver driver = slot->face->driver;
- FT_Memory memory = driver->root.memory;
- FT_GlyphSlot* parent;
- FT_GlyphSlot cur;
+ FT_Driver driver = slot->face->driver;
+ FT_Memory memory = driver->root.memory;
+ FT_GlyphSlot prev;
+ FT_GlyphSlot cur;
/* Remove slot from its parent face's list */
- parent = &slot->face->glyph;
- cur= *parent;
+ prev = NULL;
+ cur = slot->face->glyph;
while ( cur )
{
if ( cur == slot )
{
- *parent = cur->next;
+ if ( !prev )
+ slot->face->glyph = cur->next;
+ else
+ prev->next = cur->next;
+
ft_glyphslot_done( slot );
FT_FREE( slot );
break;
}
+ prev = cur;
cur = cur->next;
}
}
@@ -1679,18 +1689,11 @@
FT_List_Add( &face->driver->faces_list, node );
/* now allocate a glyph slot object for the face */
-{
- FT_GlyphSlot slot;
-
-
- FT_TRACE4(( "FT_Open_Face: Creating glyph slot\n" ));
+FT_TRACE4(( "FT_Open_Face: Creating glyph slot\n" ));
- error = FT_New_GlyphSlot( face, &slot );
- if ( error )
-goto Fail;
-
- face->glyph = slot;
-}
+error = FT_New_GlyphSlot( face, NULL );
+if ( error )
+ goto Fail;
/* finally, allocate a size object for the face */
{
Index: type42/t42objs.c
===
RCS file: /home/cvs/freetype2/src/type42/t42objs.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 t42objs.c
--- type42/t42objs.c15 May 2005 07:10:28 - 1.1.1.1
+++ type42/t42objs.c16 May 2005 14:34:59 -
@@ -515,21 +515,7 @@
FT_LOCAL_DEF( void )
T42_GlyphSlot_Done( T42_GlyphSlot slot )
{
-FT_Face face= slot->root.face;
-T42_Face t42face = (T42_Face)face;
-FT_GlyphSlot cur = t42face->ttf_face->glyph;
-
-
-while ( cur )
-{
- if ( cur == slot->ttslot )
- {
-FT_Done_GlyphSlot( slot->ttslot );
-break;
- }
-
- cur = cur->next;
-}
+FT_Done_GlyphSlot( slot->ttslot );
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Fri, May 20, 2005 at 06:15:15AM +0200, Werner LEMBERG wrote:
>
> > > > As fontconfig and xft already have the code to "embolden" and
> > > > rely on FT_GlyphSlot_Embolden to do the real job, I think
> > > > FT_GlyphSlot_Embolden should be made standard API. This is an
> > > > important feature for Chinese (maybe also Japanese and Korean)
> > > > users, as most Chinese fonts don't have a real bold style.
> >
> > After some more inspection, I find there is already FT_Glyph for
> > glyph manipulation. Then, why not
> >
> > FT_Glyph_Embolden
> > FT_Glyph_Oblique
> > ?
>
> Are these new structures? Do you suggest them because you can't
> modify the public `FT_Glyph'?
They are new function calls.
We already have FT_Glyph_Translate to translate glyphs,
FT_Glyph_Transform to transform glyphs,
FT_Glyph_Stroke to stroke glyphs,
then why not
FT_Glyph_Embolden to embolden glyphs?
>
> > Also I tried to modify the embolden algorithm for outline glyph, and
> > it now uses similar algorithm as the one I use for bitmap glyph.
> > This is done because the old algorithm generates some artifact.
>
> Aah, another user has reported problems. Can you post the patch to
> the freetype-devel list, please?
Check the patch (algorithm only) in the attachment.
Index: src/base/ftsynth.c
===
RCS file: /home/cvs/freetype2/src/base/ftsynth.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ftsynth.c
--- src/base/ftsynth.c 15 May 2005 07:10:28 - 1.1.1.1
+++ src/base/ftsynth.c 20 May 2005 05:24:57 -
@@ -115,7 +115,9 @@
{
FT_Pos d;
FT_Vector in, out;
+#ifdef OLD_ALGORITHM
FT_Fixed scale;
+#endif
FT_Angle angle_diff;
@@ -132,6 +134,7 @@
angle_in = FT_Atan2( in.x, in.y );
angle_out = FT_Atan2( out.x, out.y );
angle_diff = FT_Angle_Diff( angle_in, angle_out );
+#ifdef OLD_ALGORITHM
scale = FT_Cos( angle_diff/2 );
if ( scale < 0x400L && scale > -0x400L )
@@ -148,6 +151,23 @@
outline->points[n].x = v_cur.x + distance + in.x;
outline->points[n].y = v_cur.y + distance + in.y;
+#else
+ angle_diff = angle_in + angle_diff / 2 - rotate;
+ angle_diff = FT_Angle_Diff( 0, angle_diff );
+
+ d = distance * 2; /* strength */
+
+ if ( -FT_ANGLE_PI2 < angle_diff && angle_diff <= 0 ) {
+ outline->points[n].x = v_cur.x + d;
+ }
+ else if ( 0 < angle_diff && angle_diff < FT_ANGLE_PI2 ) {
+ outline->points[n].x = v_cur.x + d;
+ outline->points[n].y = v_cur.y + d;
+ }
+ else if ( FT_ANGLE_PI2 <= angle_diff && angle_diff < FT_ANGLE_PI ) {
+ outline->points[n].y = v_cur.y + d;
+ }
+#endif
v_prev = v_cur;
v_cur = v_next;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] remove cmap from face's list when FT_CMap_Done
Hi,
This is yet another (and hopefully last) useless patch, because no
module "done"s a cmap :)
Anyway, as new cmap is always appended to face's list, we should remove
it from the list when it gets done. Otherwise, we get sigsegv when we
try to iterate the list.
BTW, is the changelog entry converted from cvs log or hand-written? I
guess I am supposed to write changelog entry myself, but I don't know
how to do that. Sorry for the inconvenience.
Regards,
olv
Index: include/freetype/ftbitmap.h
===
RCS file: /home/cvs/freetype2/include/freetype/ftbitmap.h,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.1.2.2
diff -u -r1.1.1.2 -r1.1.1.1.2.2
--- include/freetype/ftbitmap.h 21 May 2005 00:23:44 - 1.1.1.2
+++ include/freetype/ftbitmap.h 21 May 2005 00:38:01 - 1.1.1.1.2.2
@@ -75,10 +75,12 @@
/*Copies an bitmap into another one. */
/* */
/**/
- /*source :: A handle to the source bitmap. */
+ /*library :: A handle to a library object. */
+ /* */
+ /*source :: A handle to the source bitmap. */
/* */
/* */
- /*target :: A handle to the target bitmap. */
+ /*target :: A handle to the target bitmap. */
/* */
/* */
/*FreeType error code. 0 means success. */
Index: include/freetype/internal/ftobjs.h
===
RCS file: /home/cvs/freetype2/include/freetype/internal/ftobjs.h,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.2.1
diff -u -r1.1.1.1 -r1.1.1.1.2.1
--- include/freetype/internal/ftobjs.h 15 May 2005 07:10:28 - 1.1.1.1
+++ include/freetype/internal/ftobjs.h 21 May 2005 01:52:22 -
1.1.1.1.2.1
@@ -159,7 +159,7 @@
FT_CharMap charmap,
FT_CMap *acmap );
- /* destroy a charmap (don't remove it from face's list though) */
+ /* destroy a charmap and remove it from face's list */
FT_BASE( void )
FT_CMap_Done( FT_CMap cmap );
Index: src/base/ftobjs.c
===
RCS file: /home/cvs/freetype2/src/base/ftobjs.c,v
retrieving revision 1.1.1.3
retrieving revision 1.1.1.1.2.8
diff -u -r1.1.1.3 -r1.1.1.1.2.8
--- src/base/ftobjs.c 21 May 2005 00:23:45 - 1.1.1.3
+++ src/base/ftobjs.c 21 May 2005 01:52:22 - 1.1.1.1.2.8
@@ -687,6 +687,10 @@
static void
+ ft_cmap_done_internal( FT_CMap cmap );
+
+
+ static void
destroy_charmaps( FT_Faceface,
FT_Memory memory )
{
@@ -698,7 +702,7 @@
FT_CMap cmap = FT_CMAP( face->charmaps[n] );
- FT_CMap_Done( cmap );
+ ft_cmap_done_internal( cmap );
face->charmaps[n] = NULL;
}
@@ -2255,20 +2259,63 @@
}
+ static void
+ ft_cmap_done_internal( FT_CMap cmap )
+ {
+FT_CMap_Class clazz = cmap->clazz;
+FT_Faceface = cmap->charmap.face;
+FT_Memory memory = FT_FACE_MEMORY(face);
+
+
+if ( clazz->done )
+ clazz->done( cmap );
+
+FT_FREE( cmap );
+ }
+
+
FT_BASE_DEF( void )
FT_CMap_Done( FT_CMap cmap )
{
if ( cmap )
{
- FT_CMap_Class clazz = cmap->clazz;
- FT_Faceface = cmap->charmap.face;
- FT_Memory memory = FT_FACE_MEMORY(face);
+ FT_Faceface = cmap->charmap.face;
+ FT_Memory memory = FT_FACE_MEMORY(face);
+ FT_Error error;
+ FT_Int i, j;
+
+ for ( i = 0; i < face->num_charmaps; i++ )
+ {
+if ( (FT_CMap)face->charmaps[i] == cmap )
+{
+ FT_CharMap last_charmap = face->charmaps[face->num_charmaps - 1];
+
+
+ if ( FT_RENEW_ARRAY( face->charmaps,
+face->num_charmaps,
+face->num_charmaps - 1 ) )
+return;
+
+ /* remove it from our list of charmaps */
+ for ( j = i + 1; j < face->num_charmaps; j++ )
+ {
+if ( j == face->num_charmaps - 1 )
+ face->charmaps[j - 1] = last_charmap;
+else
+ face->charmaps[j - 1] = face->charmaps[j];
+ }
+
+ face->num_charmaps--;
+
+ if ( (FT_CMap)face->charmap == cmap )
+face->charmap = NULL;
- if ( clazz->done )
-clazz->done( cmap );
+ ft_
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
Hi all, This patch implements FT_Bitmap_Embolden and FT_Outline_Embolden. It is intended for testing the algorithm and for discussing what arguments should these function calls take. Both function calls are documented, and you can read them directly in the patch. I also make FT_GlyphSlot_Embolden to use these function calls. You can see it as an example of how applications are gonna use the function calls and it will eventually be removed. Regards, olv === include/freetype/ftbitmap.h == --- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 240) +++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local) @@ -92,6 +92,42 @@ /*/ /* */ /* */ + /*FT_Bitmap_Embolden */ + /* */ + /* */ + /*Emboldens a bitmap. The new bitmap will be about xStrength */ + /*pixels wider and yStrength pixels higher. (The left and bottom */ + /*borders are kept unchanged)*/ + /* */ + /**/ + /*library :: A handle to a library object. */ + /* */ + /**/ + /*bitmap:: A handle to the target bitmap.*/ + /* */ + /*xStrength :: How strong the glyph is emboldened horizontally. */ + /* Expressed in 16.16 pixel format. */ + /* */ + /*yStrength :: How strong the glyph is emboldened vertically.*/ + /* Expressed in 16.16 pixel format. */ + /* */ + /* */ + /*FreeType error code*/ + /* */ + /* */ + /*Current implementation restricts xStrength to be less than or */ + /*equal to 8.*/ + /* */ + FT_EXPORT_DEF( FT_Error ) + FT_Bitmap_Embolden( FT_Library library, + FT_Bitmap* bitmap, + FT_Pos* xStrength, + FT_Pos* yStrength ); + + + /*/ + /* */ + /* */ /*FT_Bitmap_Convert */ /* */ /* */ === include/freetype/ftoutln.h == --- include/freetype/ftoutln.h (/freetype2/trunk) (revision 240) +++ include/freetype/ftoutln.h (/freetype2/branches/embolden) (local) @@ -58,6 +58,7 @@ /*FT_Outline_Copy*/ /*FT_Outline_Translate */ /*FT_Outline_Transform */ + /*FT_Outline_Embolden*/ /*FT_Outline_Reverse */ /*FT_Outline_Check */ /* */ @@ -306,6 +307,33 @@ /*/ /* */ /* */ + /*FT_Outline_Embolden*/ + /* */ + /* */ + /*Emboldens an outline. The new outline will be about xStrength */ + /*
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Wed, May 25, 2005 at 07:54:56AM +0200, Werner LEMBERG wrote:
>
> > > I'm unfamiliar with this API and never checked the bolden result
> > > in detail, could you show some demo program?
> >
> > I've made a quick hack to ftview.c for demo. See applied patch.
>
> Can you update this patch too, please? This is, add emboldening to
> the rendering mode cycle.
>
>
> Werner
I tried to make this patch elegant, but, well, ftview.c needs
refactoring.
Most codes of Render_Embolden are copied from Render_Stroke.
--
Regards,
olv
=== src/ftcommon.i
==
--- src/ftcommon.i (revision 901)
+++ src/ftcommon.i (local)
@@ -19,6 +19,7 @@
#include FT_STROKER_H
#include FT_BITMAP_H
+#include FT_SYNTHESIS_H
/* the following header shouldn't be used in normal programs */
#include FT_INTERNAL_DEBUG_H
@@ -79,7 +80,15 @@
int graph_init = 0;
double the_gamma = 1.0;
- int render_mode = 0;
+ enum {
+RENDER_MODE_ALL = 0,
+RENDER_MODE_EMBOLDEN,
+RENDER_MODE_STROKE,
+RENDER_MODE_TEXT,
+RENDER_MODE_WATERFALL,
+RENDER_MODE_GAMMAGRID /* this mode must be the last one */
+ } render_mode = 0;
+
int debug = 0;
int trace_level = 0;
=== src/ftview.c
==
--- src/ftview.c (revision 901)
+++ src/ftview.c (local)
@@ -191,7 +191,105 @@
return error;
}
+
+ /* most codes are copied from Render_Stroke */
static FT_Error
+ Render_Embolden( int first_index )
+ {
+FT_F26Dot6 start_x, start_y, step_x, step_y, x, y;
+FTC_ScalerRec scaler;
+inti;
+grBitmap bit3;
+
+
+start_x = 4;
+start_y = 16 + current_font.height;
+
+
+scaler.face_id = current_font.face_id;
+scaler.width = current_font.width;
+scaler.height = current_font.height;
+scaler.pixel = 1;
+
+error = FTC_Manager_LookupSize( cache_manager, &scaler, &size );
+if ( error )
+ goto Exit;
+
+step_x = size->metrics.x_ppem + 4;
+step_y = ( size->metrics.height >> 6 ) + 4;
+
+x = start_x;
+y = start_y;
+
+i = first_index;
+i = first_index;
+
+while ( i < face->num_glyphs )
+{
+ int left, top, x_advance, y_advance, x_top, y_top;
+ FT_GlyphSlot slot = size->face->glyph;
+ FT_Glyph glyphp;
+
+#if 0
+ gindex = *(unsigned char*)p;
+ if ( encoding == FT_ENCODING_NONE )
+gindex = get_glyph_index( gindex );
+#endif
+ error = FT_Load_Glyph( size->face, i, FT_LOAD_DEFAULT );
+ if ( !error )
+ {
+FT_Glyph glyphb;
+
+
+FT_GlyphSlot_Embolden( slot );
+error = FT_Get_Glyph( slot, &glyphp );
+if ( error )
+ goto Next;
+
+error = glyph_to_bitmap( glyphp, &bit3, &left, &top,
+ &x_advance, &y_advance, (FT_Pointer*)&glyphb
);
+if ( !error )
+{
+ /* now render the bitmap into the display surface */
+ x_top = x + left;
+ y_top = y - top;
+ grBlitGlyphToBitmap( &bit, &bit3, x_top, y_top, fore_color );
+
+ FT_Done_Glyph( glyphb );
+ FT_Done_Glyph( glyphp );
+
+ x += x_advance + 1;
+
+ if ( x + size->metrics.x_ppem > bit.width )
+ {
+x = start_x;
+y += step_y;
+
+if ( y >= bit.rows )
+ goto Exit;
+ }
+}
+else
+ FT_Done_Glyph( glyphp );
+
+if ( error )
+ goto Next;
+ }
+ else
+ {
+ Next:
+Fail++;
+ }
+
+ i++;
+}
+
+ Exit:
+return error;
+ }
+
+
+ static FT_Error
Render_All( int first_index )
{
FT_F26Dot6 start_x, start_y, step_x, step_y, x, y;
@@ -649,26 +747,32 @@
break;
case grKEY( 'K' ):
- render_mode = 4;
+ render_mode = RENDER_MODE_GAMMAGRID;
new_header = (char*)"rendering gamma grid";
break;
case grKEY( ' ' ):
- render_mode = ( render_mode + 1 ) % 4;
+ render_mode = ( render_mode + 1 ) % RENDER_MODE_GAMMAGRID;
switch ( render_mode )
{
-case 0:
- new_header = (char*)"rendering all glyphs in font";
- break;
-case 1:
- new_header = (char*)"rendering test text string";
- break;
-case 2:
- new_header = (char*)"rendering stroked text";
- break;
-
-default:
- new_header = (char*)"rendering glyph waterfall";
+ case RENDER_MODE_ALL:
+new_header = (char*)"rendering all glyphs in font";
+break;
+ case RENDER_MODE_EMBOLDEN:
+new_header = (char*)"rendering emboldened text";
+break;
+ case RENDER_MODE_STROKE:
+new_header = (char*)"rendering stroked text";
+break;
+ case RENDER_MODE_TEXT:
+new_header = (char*)"rendering test text string";
+break;
+ case
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Thu, May 26, 2005 at 07:32:49AM +0200, Werner LEMBERG wrote:
> Anyway, there is a bug, either in your emboldening code or in ftview.
> Load the attached font with
>
> ftview 15 Chicago.12.bdf
>
> then press the space key, arrow up, arrow down, arrow up, arrow down,
> etc., and you can see that the glyphs get fatter and fatter.
Thanks for testing. The attached patch should fix the problem.
(Changelog entry included. You may need to change the date.)
This happens when slot is not bitmap-owner (like this case of bdf font).
I also make the metrics always being modified in this patch, as those
who want more control should use FT_{Bitmap,Outline}_Embolden instead.
--
Regards,
olv
=== ChangeLog
==
--- ChangeLog (/freetype2/trunk) (revision 904)
+++ ChangeLog (/freetype2/branches/embolden) (local)
@@ -1,3 +1,12 @@
+2005-05-26 Chia I Wu <[EMAIL PROTECTED]>
+
+ * include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Improve
+ documentation.
+
+ * src/base/ftsynth.c: Remove macro FT_BOLD_THRESHOLD.
+ (FT_GlyphSlot_Embolden): Check whether slot is bitmap-owner.
+ Always modify the metrics.
+
2005-05-24 Werner Lemberg <[EMAIL PROTECTED]>
* docs/CHANGES: Updated.
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 904)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -118,6 +118,10 @@
/*The current implementation restricts `xStrength' to be less than */
/*or equal to 8. */
/* */
+ /*Don't embolden the bitmap owned by a @FT_GlyphSlot. Call */
+ /*@FT_Bitmap_Copy to get a copy and work on the copy.*/
+ /* */
+ /* */
FT_EXPORT_DEF( FT_Error )
FT_Bitmap_Embolden( FT_Library library,
FT_Bitmap* bitmap,
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 904)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -23,7 +23,6 @@
#include FT_BITMAP_H
-#define FT_BOLD_THRESHOLD 0x0100
/*/
@@ -90,7 +89,7 @@
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
{
error = FT_Outline_Embolden( &slot->outline, xstr );
- xstr = ( xstr * 4 ) & ~63;
+ xstr = xstr * 4 ; /* according to the document */
ystr = xstr;
}
else if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
@@ -100,25 +99,41 @@
xstr = 1 << 6;
ystr = FT_PIX_FLOOR( ystr );
- error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
+ /* slot must be bitmap-owner */
+ if ( !(slot->internal->flags & FT_GLYPH_OWN_BITMAP) )
+ {
+FT_Bitmap bitmap;
- /* XXX should we set these? */
+
+FT_Bitmap_New( &bitmap );
+error = FT_Bitmap_Copy( library, &slot->bitmap, &bitmap );
+
+if ( !error )
+{
+ slot->bitmap = bitmap;
+ slot->internal->flags |= FT_GLYPH_OWN_BITMAP;
+}
+ }
+
if ( !error )
-slot->bitmap_top += ystr >> 6;
+error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
}
else
error = FT_Err_Invalid_Argument;
-/* XXX should we set these? */
+/* modify the metrics accordingly */
if ( !error )
{
-#if 0
- slot->advance.x+= xstr;
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
-#endif
slot->metrics.horiAdvance += xstr;
+ slot->metrics.vertBearingX -= xstr / 2;
+ slot->metrics.vertBearingY += ystr;
+ slot->metrics.vertAdvance += ystr;
+
+ if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
+slot->bitmap_top += ystr >> 6;
}
}
Property changes on:
___
Name: svk:merge
+5f392c16-9bf0-0310-b16c-a65848a4e34f:/freetype2/trunk:903
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Thu, May 26, 2005 at 05:25:33PM +0800, Chia I Wu wrote:
> On Thu, May 26, 2005 at 07:32:49AM +0200, Werner LEMBERG wrote:
> > Anyway, there is a bug, either in your emboldening code or in ftview.
> > Load the attached font with
> >
> > ftview 15 Chicago.12.bdf
> >
> > then press the space key, arrow up, arrow down, arrow up, arrow down,
> > etc., and you can see that the glyphs get fatter and fatter.
> Thanks for testing. The attached patch should fix the problem.
> (Changelog entry included. You may need to change the date.)
>
> This happens when slot is not bitmap-owner (like this case of bdf font).
> I also make the metrics always being modified in this patch, as those
> who want more control should use FT_{Bitmap,Outline}_Embolden instead.
There is one stupid bug in the last patch. Please apply this one.
Sorry for the inconvenience.
--
Regards,
olv
=== ChangeLog
==
--- ChangeLog (/freetype2/trunk) (revision 904)
+++ ChangeLog (/freetype2/branches/embolden) (local)
@@ -1,3 +1,12 @@
+2005-05-26 Chia I Wu <[EMAIL PROTECTED]>
+
+ * include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Improve
+ documentation.
+
+ * src/base/ftsynth.c: Remove macro FT_BOLD_THRESHOLD.
+ (FT_GlyphSlot_Embolden): Check whether slot is bitmap-owner.
+ Always modify the metrics.
+
2005-05-24 Werner Lemberg <[EMAIL PROTECTED]>
* docs/CHANGES: Updated.
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 904)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -118,6 +118,10 @@
/*The current implementation restricts `xStrength' to be less than */
/*or equal to 8. */
/* */
+ /*Don't embolden the bitmap owned by a @FT_GlyphSlot. Call */
+ /*@FT_Bitmap_Copy to get a copy and work on the copy.*/
+ /* */
+ /* */
FT_EXPORT_DEF( FT_Error )
FT_Bitmap_Embolden( FT_Library library,
FT_Bitmap* bitmap,
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 904)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -23,7 +23,6 @@
#include FT_BITMAP_H
-#define FT_BOLD_THRESHOLD 0x0100
/*/
@@ -78,8 +77,8 @@
{
FT_Library library = slot->library;
FT_Face face= FT_SLOT_FACE( slot );
+FT_Errorerror = FT_Err_Ok;
FT_Pos xstr, ystr;
-FT_Errorerror;
/* some reasonable strength */
@@ -90,7 +89,7 @@
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
{
error = FT_Outline_Embolden( &slot->outline, xstr );
- xstr = ( xstr * 4 ) & ~63;
+ xstr = xstr * 4 ; /* according to the document */
ystr = xstr;
}
else if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
@@ -100,25 +99,41 @@
xstr = 1 << 6;
ystr = FT_PIX_FLOOR( ystr );
- error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
+ /* slot must be bitmap-owner */
+ if ( !(slot->internal->flags & FT_GLYPH_OWN_BITMAP) )
+ {
+FT_Bitmap bitmap;
- /* XXX should we set these? */
+
+FT_Bitmap_New( &bitmap );
+error = FT_Bitmap_Copy( library, &slot->bitmap, &bitmap );
+
+if ( !error )
+{
+ slot->bitmap = bitmap;
+ slot->internal->flags |= FT_GLYPH_OWN_BITMAP;
+}
+ }
+
if ( !error )
-slot->bitmap_top += ystr >> 6;
+error = FT_Bitmap_Embolden( library, &slot->bitmap, xstr, ystr );
}
else
error = FT_Err_Invalid_Argument;
-/* XXX should we set these? */
+/* modify the metrics accordingly */
if ( !error )
{
-#if 0
- slot->advance.x+= xstr;
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
-#endif
slot->metrics.horiAdvance += xstr;
+ slot->metrics.vertBearingX -= xstr / 2;
+ slot->metrics.vertBearingY += ystr;
+ slot->metrics.vertAdvance += ystr;
+
+ if ( slot->format == FT_GLYPH_FORMAT_BITMAP )
+slot->bitmap_top += ystr >> 6;
}
}
Property changes on:
__
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Wed, May 25, 2005 at 07:50:16AM +0200, Werner LEMBERG wrote:
>
> Thanks, applied! Note that I've changed the third and fourth argument
> of FT_Bitmap_Embolden to be normal values, not pointers. Please test.
>
>
> Werner
Hi Werner,
This patch fixes some bugs in FT_Bitmap_Embolden.
ChangeLog:
* src/base/ftbitmap.c (FT_Bitmap_Embolden): fix a bug when pitch is
negative.
fix a bug when pixel_mode is FT_PIXEL_MODE_GRAY and num_gray != 256.
some speed-up when pixel_mode is FT_PIXEL_MODE_GRAY.
(ft_bitmap_assure_buffer): accept FT_PIXEL_MODE_LCD and
FT_PIXEL_MODE_LCD_V.
--
Regards,
olv
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (revision 909)
+++ src/base/ftbitmap.c (local)
@@ -115,6 +115,8 @@
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_MONO:
+case FT_PIXEL_MODE_LCD:
+case FT_PIXEL_MODE_LCD_V:
ppb = 8;
break;
case FT_PIXEL_MODE_GRAY2:
@@ -210,7 +212,7 @@
else
{
pitch = -pitch;
- p = bitmap->buffer + pitch * ( bitmap->rows - ystr - 1 );
+ p = bitmap->buffer + pitch * ( bitmap->rows - 1 );
}
/* for each row */
@@ -237,16 +239,30 @@
/* the maximum value of 8 for `xstr' comes from here */
if ( x > 0 )
p[x] |= p[x - 1] << ( 8 - i );
+
+#if 0
+if ( p[x] == 0xff )
+ break;
+#endif
}
else if ( bitmap->pixel_mode == FT_PIXEL_MODE_GRAY )
{
if ( x - i >= 0 )
{
- if ( p[x] + p[x - i] > 0xff )
-p[x] = 0xff;
+ if ( p[x] + p[x - i] > bitmap->num_grays )
+ {
+p[x] = bitmap->num_grays;
+break;
+ }
else
+ {
p[x] += p[x - i];
+if ( p[x] == bitmap->num_grays )
+ break;
+ }
}
+else
+ break;
}
}
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Sat, May 28, 2005 at 03:47:49PM +0200, Werner LEMBERG wrote:
>
> > This patch fixes some bugs in FT_Bitmap_Embolden.
>
> Applied, thanks. I think there is still a bug for graymap fonts.
> Have a look at the attached test glyph. Emboldening produces a
> strange result.
This is introduced by the last patch :(
I've dirty hacked ftview for testing bitmap emboldening of various
pixel_mode. You can find the hack in the attachments.
For testing, launch ftview with outline font and press 'c' to disable
cache first. Then you can use 'l' to switch between normal/emboldened
mode, and 'L' to rotate between LCD modes. I hope this would help bug
hunting the bitmap emboldening algorithm (and help me not send buggy
patches).
Anyway, here's the changelog:
ft2-bitmap-embolden-fix2.patch
* src/base/ftbitmap.c (FT_Bitmap_Embolden): Fix emboldening bitmap of
mode FT_PIXEL_MODE_GRAY. Also add support for mode FT_PIXEL_MODE_LCD
and FT_PIXEL_MODE_LCD_V.
(ft_bitmap_assure_buffer): FT_PIXEL_MODE_LCD and FT_PIXEL_MODE_LCD_V
should have ppb (pixel per byte) 1.
Zero the padding when there's no need to allocate memory.
ft2-ftsynth-advance.patch
* src/base/ftsynth.c (FT_GlyphSlot_Embolden): Modify slot->advance
accordingly.
--
Regards,
olv
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (/freetype2/trunk) (revision 923)
+++ src/base/ftbitmap.c (/freetype2/branches/embolden) (local)
@@ -115,8 +115,6 @@
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_MONO:
-case FT_PIXEL_MODE_LCD:
-case FT_PIXEL_MODE_LCD_V:
ppb = 8;
break;
case FT_PIXEL_MODE_GRAY2:
@@ -126,15 +124,44 @@
ppb = 2;
break;
case FT_PIXEL_MODE_GRAY:
+case FT_PIXEL_MODE_LCD:
+case FT_PIXEL_MODE_LCD_V:
ppb = 1;
break;
default:
return FT_Err_Invalid_Glyph_Format;
}
-/* check whether we must allocate memory */
+/* if no need to allocate memory */
if ( ypixels == 0 && pitch * ppb >= bitmap->width + xpixels )
+{
+ /* zero the padding */
+ for ( i = 0; i < bitmap->rows; i++ )
+ {
+unsigned char* last_byte;
+int bits = xpixels * ( 8 / ppb );
+int mask = 0;
+
+
+last_byte = bitmap->buffer + i * pitch + ( bitmap->width - 1 ) / ppb;
+
+if ( bits >= 8 )
+{
+ FT_MEM_ZERO( last_byte + 1, bits / 8 );
+ bits %= 8;
+}
+
+if ( bits > 0 )
+{
+ while ( bits-- > 0 )
+mask |= 1 << bits;
+
+ *last_byte &= ~mask;
+}
+ }
+
return FT_Err_Ok;
+}
new_pitch = ( bitmap->width + xpixels + ppb - 1 ) / ppb;
@@ -187,16 +214,22 @@
if ( !bitmap )
return FT_Err_Invalid_Argument;
+xstr = FT_PIX_ROUND( xStrength ) >> 6;
+ystr = FT_PIX_ROUND( yStrength ) >> 6;
+
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_GRAY2:
case FT_PIXEL_MODE_GRAY4:
return FT_Err_Invalid_Glyph_Format;
+case FT_PIXEL_MODE_LCD:
+ xstr *= 3;
+ break;
+case FT_PIXEL_MODE_LCD_V:
+ ystr *= 3;
+ break;
}
-xstr = FT_PIX_ROUND( xStrength ) >> 6;
-ystr = FT_PIX_ROUND( yStrength ) >> 6;
-
if ( xstr == 0 && ystr == 0 )
return FT_Err_Ok;
else if ( xstr < 0 || ystr < 0 || xstr > 8 )
@@ -245,19 +278,19 @@
break;
#endif
}
- else if ( bitmap->pixel_mode == FT_PIXEL_MODE_GRAY )
+ else
{
if ( x - i >= 0 )
{
- if ( p[x] + p[x - i] > bitmap->num_grays )
+ if ( p[x] + p[x - i] > bitmap->num_grays - 1 )
{
-p[x] = bitmap->num_grays;
+p[x] = bitmap->num_grays - 1;
break;
}
else
{
p[x] += p[x - i];
-if ( p[x] == bitmap->num_grays )
+if ( p[x] == bitmap->num_grays - 1 )
break;
}
}
=== src/ftcommon.i
==
--- src/ftcommon.i (/freetype2/trunk/ft2demos) (revision 923)
+++ src/ftcommon.i (/freetype2/branches/embolden/ft2demos) (local)
@@ -752,6 +752,39 @@
&glyf,
NULL );
+ /* XXX dirty hack for testing bitmap emboldening */
+ if ( glyf->format == FT_GLYPH_FORMAT_OUTLINE )
+ {
+FT_Render_Mode render_mode;
+
+if ( lcd_mode <= 1 )
+ render_mode = FT_RENDER_MODE_NORMAL;
+else if ( lcd_mode <= 3 )
+ render_mode = FT_RENDER_MODE_LCD;
+else
+ render_mode = FT_RENDER_MODE_LCD_V;
+
+if ( !antialias )
+ render_mode = FT_RENDER_MODE_MONO;
+
+/* render the glyph to a bitmap, don't destroy original */
+error = FT_Glyp
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Sat, May 28, 2005 at 03:47:49PM +0200, Werner LEMBERG wrote:
>
> > This patch fixes some bugs in FT_Bitmap_Embolden.
>
> Applied, thanks. I think there is still a bug for graymap fonts.
> Have a look at the attached test glyph. Emboldening produces a
> strange result.
Oops, I forgot to adjust emboldening strength in the last ftsynth.c
patch. Please ignore that one.
These changes are suggested by some brave testers.
Changelog:
ft2-ftsynth-advance-fix2.patch:
* src/base/ftsynth.c (FT_GlyphSlot_Embolden): Modify slot->advance
accordingly.
More suited emboldening strength.
--
Regards,
olv
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (/freetype2/trunk) (revision 923)
+++ src/base/ftsynth.c (/freetype2/branches/embolden) (local)
@@ -81,7 +81,7 @@
/* some reasonable strength */
xstr = FT_MulFix( face->units_per_EM,
- face->size->metrics.y_scale ) / 32;
+ face->size->metrics.y_scale ) / 42;
ystr = xstr;
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
@@ -122,6 +122,9 @@
/* modify the metrics accordingly */
if ( !error )
{
+ slot->advance.x += xstr;
+ slot->advance.y += ystr;
+
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
slot->metrics.horiBearingY += ystr;
Property changes on:
___
Name: svk:merge
+5f392c16-9bf0-0310-b16c-a65848a4e34f:/freetype2/trunk:921
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Mon, May 30, 2005 at 08:26:44AM +0200, Werner LEMBERG wrote: > > > This is introduced by the last patch :( > > Hehe, there still seem to be problems :-) The glyphs in the two > attached fonts don't change at all (neither the appearance nor the > advance width) if I check embolding with ftview (not using your > patch). gray2 and gray4 are not supported now. I'll see if I can add support to them. If I can't, I'll submit a patch to update the documentation :) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Make FT_GlyphSlot_Embolden standard API?
On Mon, May 30, 2005 at 03:24:30PM +0800, Chia I Wu wrote:
> gray2 and gray4 are not supported now. I'll see if I can add support to them.
> If I can't, I'll submit a patch to update the documentation :)
Ok, this patch should fix the problem. Instead of supporting gray[24]
directly, convertion from gray[24] to gray8 is done before emboldening.
Changelog:
* include/freetype/ftbitmap.h (FT_Bitmap_Embolden): Fix typos.
Update documentaion a little.
* include/freetype/ftoutline.h (FT_Outline_Embolden): Fix typos.
* src/base/ftbitmap.c (FT_Bitmap_Embolden): Add support for bitmap of
pixel_mode FT_PIXEL_MODE_GRAY2 or FT_PIXEL_MODE_GRAY4.
When xstr is larger than 8 and bitmap is of pixel_mode
FT_PIXEL_MODE_MONO, set xstr to 8 instead of returning error.
--
Regards,
olv
=== include/freetype/ftbitmap.h
==
--- include/freetype/ftbitmap.h (/freetype2/trunk) (revision 931)
+++ include/freetype/ftbitmap.h (/freetype2/branches/embolden) (local)
@@ -97,7 +97,7 @@
/*FT_Bitmap_Embolden */
/* */
/* */
- /*Emboldens a bitmap. The new bitmap will be about `xStrength' */
+ /*Embolden a bitmap. The new bitmap will be about `xStrength' */
/*pixels wider and `yStrength' pixels higher. The left and bottom */
/*borders are kept unchanged.*/
/* */
@@ -105,10 +105,10 @@
/*library :: A handle to a library object. */
/* */
/*xStrength :: How strong the glyph is emboldened horizontally. */
- /* Expressed in 16.16 pixel format. */
+ /* Expressed in 26.6 pixel format. */
/* */
/*yStrength :: How strong the glyph is emboldened vertically.*/
- /* Expressed in 16.16 pixel format. */
+ /* Expressed in 26.6 pixel format. */
/* */
/**/
/*bitmap:: A handle to the target bitmap.*/
@@ -118,7 +118,7 @@
/* */
/* */
/*The current implementation restricts `xStrength' to be less than */
- /*or equal to 8. */
+ /*or equal to 8 when bitmap is of pixel_mode @FT_PIXEL_MODE_MONO.*/
/* */
/*Don't embolden the bitmap owned by a @FT_GlyphSlot directly! Call */
/*@FT_Bitmap_Copy to get a copy and work on the copy instead.*/
=== include/freetype/ftoutln.h
==
--- include/freetype/ftoutln.h (/freetype2/trunk) (revision 931)
+++ include/freetype/ftoutln.h (/freetype2/branches/embolden) (local)
@@ -319,7 +319,7 @@
/* */
/**/
/*strength :: How strong the glyph is emboldened. Expressed in */
- /*16.16 pixel format.*/
+ /*26.6 pixel format. */
/* */
/* */
/*FreeType error code. 0 means success. */
=== src/base/ftbitmap.c
==
--- src/base/ftbitmap.c (/freetype2/trunk) (revision 931)
+++ src/base/ftbitmap.c (/freetype2/branches/embolden) (local)
@@ -211,17 +211,45 @@
if ( !library )
return FT_Err_Invalid_Library_Handle;
-if ( !bitmap )
+if ( !bitmap || !bitmap->buffer )
return FT_Err_Invalid_Argument;
xstr = FT_PIX_ROUND( xStrength ) >> 6;
ystr = FT_PIX_ROUND( yStrength ) >> 6;
+if ( xstr == 0 && ystr == 0 )
+ return FT_Err_Ok;
+else if ( xstr < 0 || ystr < 0 )
+ return FT_Err_Invalid_Argument;
+
switch ( bitmap->pixel_mode )
{
case FT_PIXEL_MODE_GRAY2:
case FT_PIXEL_MODE_GRAY4:
- return FT_Err_Inv
Re: [ft-devel] does the face cache really work ?
On Thu, Jun 02, 2005 at 02:52:58AM +, Anstinus Anstinus wrote: > Consider the situation: I looked up a FT_Face by myFaceID1 at first, then > at a later time, I want to get the same FT_Face. Should I find the > myFaceID1 in my list and use it to lookup a FT_Face , or create a new > myFaceID2 with the same content as myFaceID1 ? Use myFaceID1. It's the id itself (or memory address, if you feels clearer) being used to look up the face, not the contents hidden behind the id. > > Another question: The chars freetype rendered are all "solid". Can freetype > render only the outline without fill it ? I didn't find such interface in > documents. You may need to use FT_Outline_Render and set your own version of gray_spans in the raster parameters. But I am not sure if this is feasible. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] minor documentation and comment update
Hi, This patch does: include/freetype/freetype.h (FT_Set_Transform): Minor documentation update. src/base/ftobjs.c (ft_glyphslot_clear): Remove outdated comment. As for the removed comment in ft_glyphslot_clear, it says "don't touch slot->bitmap.buffer", but slot->bitmap.buffer is set to NULL by FT_FREE in ft_glyphslot_free_bitmap. So I think the comment is outdated. -- Regards, olv === include/freetype/freetype.h == --- include/freetype/freetype.h (revision 964) +++ include/freetype/freetype.h (patch - level 1) @@ -2370,8 +2370,8 @@ /* */ /* */ /*A function used to set the transformation that is applied to glyph */ - /*images just before they are converted to bitmaps in a glyph slot */ - /*when @FT_Render_Glyph is called. */ + /*images when they are loaded into a glyph slot throught */ + /*@FT_Load_Glyph.*/ /* */ /**/ /*face :: A handle to the source face object. */ === src/base/ftobjs.c == --- src/base/ftobjs.c (revision 964) +++ src/base/ftobjs.c (patch - level 1) @@ -292,7 +292,6 @@ slot->bitmap.rows = 0; slot->bitmap.pitch = 0; slot->bitmap.pixel_mode = 0; -/* don't touch 'slot->bitmap.buffer'! */ slot->bitmap_left = 0; slot->bitmap_top= 0; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] glyph metrics rounded to integer when hinting?
Hi, I find that glyph metrics are rounded to integer in font drivers when loading a glyph with hinting. I think this is to prevent application from accidentally ruining the hinting (i.e. from translating the glyphs by non integral offset). Is it true? If it's true, then maybe the rounding process is better being done in FT_Load_Glyph, so that font drivers don't have to do this themselves. (after 2.1.10, of course) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] rewrite of ftview and ftstring
Hi all, I have rewritten ftview.c and ftstring.c of ft2demos. It's available here: http://www.olv.idv.tw/~olvaffe/tmp/freetype2/ft2demos-partial-rewrite.tar.gz The motivation of the rewrite is, for me, to get familiar with the freetype APIs. Yet I think it is still worth going into CVS, because the old code is really horrible and I guess few users try to read the code to learn freetype. As I couldn't figure out how the Makefile works, ftcommon.c is simply #include'd in ftstring.c and ftview.c. This should be fixed. The changelog is: * src/ftcommon.c: New file * src/ftcommon.h: New file * src/ftstring.c: Rewritten. Make the function keys more compatible with ftview.c. New key 'V' for vertical rendering. * src/ftview.c: Rewritten. Now we can use number keys (i.e. 1, 2, ...) to select rendering mode. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] make up vertical metrics for truetype fonts
Hi,
This patch fixes some bugs in vertical metrics of truetype fonts. Some
of the bugs are subtle, so I list the reasons of the changes:
1. loader->pp3.y, loader->pp4.y are in 26.6, not in font units.
2. the advance height is fixed and the height of glyphs differs,
therefore glyphs should be vertically centered, instead of having fixed
top bearing,
3. as we use glyph's cbox to calculate the top bearing now (in contrast
to revision 1.2!), there's no need to adjust `top'.
The changelog entries are:
* src/sfnt/ttsbit.c (tt_face_load_sbit_image): Make up vertBearingY such
that glyphs are vertically centered.
* src/truetype/ttgload.c (compute_glyph_metrics): Make up vertBearingY
such that glyphs are vertically centered.
Fix some bugs in vertical metrics.
--
Regards,
olv
=== src/truetype/ttgload.c
==
--- src/truetype/ttgload.c (revision 975)
+++ src/truetype/ttgload.c (patch - level 1)
@@ -1765,42 +1765,41 @@
if ( face->vertical_info &&
face->vertical.number_Of_VMetrics > 0 )
{
-advance_height = (FT_UShort)( loader->pp4.y - loader->pp3.y );
-top_bearing= (FT_Short)( loader->pp3.y - bbox.yMax );
+top_bearing= (FT_Short)FT_DivFix( loader->pp3.y - bbox.yMax,
y_scale );
+
+if ( loader->pp3.y <= loader->pp4.y )
+ advance_height = 0;
+else
+ advance_height = (FT_UShort)FT_DivFix( loader->pp3.y -
loader->pp4.y, y_scale );
}
else
{
-/* Make up the distances from the horizontal header. */
+FT_Short max_height, height;
+
+/* XXX Make up top side bearing and advance height in */
+/* Get_VMetrics instead of here. */
+
/* NOTE: The OS/2 values are the only `portable' ones, */
/* which is why we use them, if there is an OS/2 */
/* table in the font. Otherwise, we use the */
/* values defined in the horizontal header. */
-/* */
-/* NOTE2: The sTypoDescender is negative, which is why */
-/*we compute the baseline-to-baseline distance */
-/*here with: */
-/* ascender - descender + linegap */
-/* */
-/* NOTE3: This is different from what MS's rasterizer */
-/*appears to do when getting default values*/
-/*for the vertical phantom points. We leave */
-/*the old code untouched, but relying on */
-/*phantom points alone might be reasonable */
-/*(i.e., removing the `if' above). */
+
+height = FT_DivFix( bbox.yMax - bbox.yMin, y_scale );
if ( face->os2.version != 0xU )
{
- top_bearing= (FT_Short)( face->os2.sTypoLineGap / 2 );
- advance_height = (FT_UShort)( face->os2.sTypoAscender -
-face->os2.sTypoDescender +
-face->os2.sTypoLineGap );
+ /* sTypoDescender is negative */
+ max_height = face->os2.sTypoAscender - face->os2.sTypoDescender;
+
+ top_bearing= (FT_Short)( ( max_height - height ) / 2 );
+ advance_height = (FT_UShort)( max_height + face->os2.sTypoLineGap );
}
else
{
- top_bearing= (FT_Short)( face->horizontal.Line_Gap / 2 );
- advance_height = (FT_UShort)( face->horizontal.Ascender +
-face->horizontal.Descender +
-face->horizontal.Line_Gap );
+ max_height = face->horizontal.Ascender + face->horizontal.Descender;
+
+ top_bearing= (FT_Short)( ( max_height - height ) / 2 );
+ advance_height = (FT_UShort)( max_height + face->horizontal.Line_Gap
);
}
}
@@ -1817,7 +1816,7 @@
metrics.bearing_x = 0;
metrics.bearing_y = top_bearing;
-metrics.advance = advance_height;
+metrics.advance = advance_height;
error =
face->root.internal->incremental_interface->funcs->get_glyph_metrics(
face->root.internal->incremental_interface->object,
@@ -1834,20 +1833,15 @@
#endif /* FT_CONFIG_OPTION_INCREMENTAL */
- /* We must adjust the top_bearing value from the bounding box given */
- /* in the glyph header to the bounding box calculated with */
- /* FT_Get_Outline_CBox(). */
-
/* scale the metrics */
if ( !( loader->load_flags & FT_LOAD_NO_SCALE ) )
{
-top = FT_MulFix( top_bearing + loader->bbox.yMax, y_scale )
-- bbox.yMax;
+top = FT_MulFix( top_bear
Re: [ft-devel] glyph metrics rounded to integer when hinting?
On Sun, Jun 05, 2005 at 11:51:44AM +0800, Chia I Wu wrote: > Hi, > > I find that glyph metrics are rounded to integer in font drivers when > loading a glyph with hinting. I think this is to prevent application > from accidentally ruining the hinting (i.e. from translating the glyphs > by non integral offset). Is it true? Any comment on this? I am really not sure why rounding is applied. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] bugs in emboldening
Hi,
This patch fixes some bugs in emboldening.
The `strength' in FT_Outline_Embolden is halved so that, for example, a
vertical bar of width W will be, after emboldening, of width "W +
strength". And now it works as the documentation says.
--
Regards,
olv
* src/base/ftoutln.c (FT_Outline_Embolden): Strength should be halved.
* src/base/ftsynth.c (FT_GlyphSlot_Embolden): Change the default strength.
Don't increase slot->advance.y.
=== src/base/ftoutln.c
==
--- src/base/ftoutln.c (revision 976)
+++ src/base/ftoutln.c (local)
@@ -683,6 +683,7 @@
if ( !outline )
return FT_Err_Invalid_Argument;
+strength /= 2;
if ( strength == 0 )
return FT_Err_Ok;
=== src/base/ftsynth.c
==
--- src/base/ftsynth.c (revision 976)
+++ src/base/ftsynth.c (local)
@@ -81,7 +81,7 @@
/* some reasonable strength */
xstr = FT_MulFix( face->units_per_EM,
- face->size->metrics.y_scale ) / 42;
+ face->size->metrics.y_scale ) / 24;
ystr = xstr;
if ( slot->format == FT_GLYPH_FORMAT_OUTLINE )
@@ -122,8 +122,8 @@
/* modify the metrics accordingly */
if ( !error )
{
+ /* assume the layout is horizontal */
slot->advance.x += xstr;
- slot->advance.y += ystr;
slot->metrics.width+= xstr;
slot->metrics.height += ystr;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: eliminating ftcommon.i
On Thu, Jun 23, 2005 at 04:30:40PM +0200, Werner LEMBERG wrote: > do you have some time to eliminate ftcommon.i (from ft2demos) > completely, transferring the remaining code to ftcommon.c? I will > then simplify the Makefile. I'll do it after next week, after finishing my term paper :( -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] looking for truetype fonts for testing
Hi, I'm looking for truetype fonts with apple's variation tables or with composite glyph constructed with various different flags, especially with ARGS_ARE_XY_VALUES and UNSCALED_COMPONENT_OFFSET set to false. Can anyone tell me where I can fine one? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] discussion of truetype glyph loading code
Hi,
I am reading ttgload.c and I have some questions I would like to discuss
with you all. I present my thoughts along with diff snippets.
==
@@ -886,24 +886,13 @@
}
}
-cur_to_org( n_points, zone );
+#ifdef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
/* eventually hint the glyph */
if ( IS_HINTED( load->load_flags ) )
{
- FT_Pos x = zone->org[n_points-4].x;
+ cur_to_org( n_points, zone );
-
- x = FT_PIX_ROUND( x ) - x;
- translate_array( n_points, zone->org, x, 0 );
-
- org_to_cur( n_points, zone );
-
- zone->cur[n_points - 3].x = FT_PIX_ROUND( zone->cur[n_points - 3].x );
- zone->cur[n_points - 1].y = FT_PIX_ROUND( zone->cur[n_points - 1].y );
==
This snippet is part of TT_Process_Simple_Glyph. The original code
translates the points so that the origin (pp1) has integral coordinates
and rounds pp2 and pp4, before hinting. I think the translation is not
necessary. When bytecode interpreter is enabled, we move points
relative to reference point or to itself. Thus the translation has no
effect. When disabled, the translation doesn't help make other points
having integral coordinates.
And for rounding pp2 and pp4, doesn't it make the result of hinting
inaccurate? Plus, pp2 and pp4 are rounded when calculating metrics
later.
I also make cur_to_org only be called when hinting is applied.
==
@@ -1406,15 +1395,12 @@
{
FT_Vector* cur = gloader->base.outline.points +
num_base_points;
-FT_Vector* org = gloader->base.extra_points +
- num_base_points;
FT_Vector* limit = cur + num_new_points;
for ( ; cur < limit; cur++, org++ )
{
FT_Vector_Transform( cur, &subglyph->transform );
- FT_Vector_Transform( org, &subglyph->transform );
}
}
@@ -1528,10 +1514,6 @@
translate_array( num_new_points,
gloader->base.outline.points + num_base_points,
x, y );
-
-translate_array( num_new_points,
- gloader->base.extra_points + num_base_points,
- x, y );
}
}
==
This snippet is after each composite component is loaded. zone->org is
overwritten later by cur_to_org so we don't have to do any
transformation to it here.
==
@@ -1479,7 +1465,7 @@
int n = c > d ? c : d;
- if ( a - b <= 33 && a - b >= -33 )
+ if ( a - c <= 33 && a - c >= -33 )
m *= 2;
if ( c - d <= 33 && c - d >= -33 )
n *= 2;
==
This snippet is in deciding the mac scale of component offsets. It is
commented out because the result is bad. But in this page
http://developer.apple.com/fonts/TTRefMan/RM06/Chap6glyf.html, the
algorithm described is slightly different (typo?) from what we use here.
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: xorg crashes with freetype2-2.1.10
On Wed, Aug 03, 2005 at 08:39:06AM +0100, Hin-Tak Leung wrote: > Werner LEMBERG wrote: > The "sbit" part remains me of the earlier two-line patch which adds > back two function pointers which David Turner removed between 2.1.9 and > 2.1.10. Then the call stack going funny - most probably > FT_Do_SBit_Metrics () in /usr/X11R6/lib/modules/fonts/libfreetype.so > is trying to call one of those two function pointers. The main question > is why David did it and/or what is the recommended change in Xorg. The freetype module of Xorg tries to get accurate glyph metrics without loading the glyph. To achieve this, it uses some internal function calls (checking if the sbit metrics is available and looking at the hmtx table). If both failed, it loads the glyph at last. This behavior is chosen because it wants to avoid loading the same glyph twice (in XTextExtents and in XDrawString), if possible. A better way would be caching the glyphs loaded. Then it can simply load the glyphs to get the metrics when user wants them. Later, when the glyph is to be drawn, it can read the glyph directly from the cache. This way no freetype's internal calls are needed and the same glyph would never have to be loaded twice. (The implementation can be made easy by employing the cache subsystem of freetype.) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] looking for truetype fonts for testing
On Tue, Aug 02, 2005 at 02:01:12PM -0700, George Williams wrote: > On Mon, 2005-08-01 at 21:56, Chia I Wu wrote: > > I'm looking for truetype fonts with apple's variation tables > The standard example I use is Skia, a font that ships with the mac. I've > seen others mentioned but don't know where to find them. I finally found it after quite a lot of google :) > > or with > > composite glyph constructed with various different flags, especially > > with ARGS_ARE_XY_VALUES and UNSCALED_COMPONENT_OFFSET set to false. > I believe Chicago (also ships with the mac) uses this. It turns out freetype has TT_CONFIG_OPTION_COMPONENT_OFFSET_SCALED undefined, which I always thought it is defined. After defining it, I found I already some fonts to test with. I don't know if this is because the fonts I tested are for MAC, defining it gives me better result. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
Hi, This patch does the changes (avoiding unnecessary array copying) I mentioned in the last post, along with a heavy cleanup of the truetype module. It is, roughly tested, ~20% faster to load a glyph without hinting. I'd like to see if it works right before committing. So please give it a try. Since the only good thing of the cleanup is to make the code more readible and it risks unstablizing the truetype module, I'll remove it and provide a new patch without the cleanup if someone thinks it's totally stupid to include the cleanup. -- Regards, olv ft2-truetype-cleanup.patch.gz Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
On Tue, Aug 09, 2005 at 07:40:38AM +0200, Werner LEMBERG wrote: > PS: Please don't include ChangeLog entries in a diff file directly. Oops.. I forgot to cut them out when I generated the diff. > > PPS: I can't see a ChangeLog entry that tt_prepare_zone is now > compiled conditionally. > > PPPS: Perhaps it is useful to use uppercase letter for even for macros > which look like a function (like tt_loader_set_pp), just as a > reminder that calling them might have secondary effects. BTW, > this macro isn't mentioned in the ChangeLog either... I thought "heavily clean up" implies "some changes are not listed" :) Anyway, I'll write a more detailed changelog when I commit. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
On Tue, Aug 09, 2005 at 07:50:41AM +0200, Werner LEMBERG wrote: > > The original code translates the points so that the origin (pp1) has > > integral coordinates and rounds pp2 and pp4, before hinting. I > > think the translation is not necessary. When bytecode interpreter > > is enabled, we move points relative to reference point or to itself. > > Thus the translation has no effect. When disabled, the translation > > doesn't help make other points having integral coordinates. > > > > And for rounding pp2 and pp4, doesn't it make the result of hinting > > inaccurate? Plus, pp2 and pp4 are rounded when calculating metrics > > later. > > Whether this improves the rendering process can only be decided in > direct comparison with the Windows hinting engine. Whether it becomes > worse is hopefully visible immediately... It gives bad result on verdana.ttf! Here's try 2. TT_Hint_Glyph now works as the original code does. -- Regards, olv ft2-truetype-cleanup-try2.patch.gz Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] discussion of truetype glyph loading code
On Tue, Aug 09, 2005 at 06:55:54PM +0200, Werner LEMBERG wrote: > This is a lame excuse :-) Seriously, your clean-ups are still > comprehendable -- it's more a code shifting than a complete rewrite, > isn't it? Yes, I just moved the code around and gave it sensible names. The few practical changes are all listed in the changelog. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Export services?
Hi, There are some functions which are wrappers to services. Then why not simply export the services to clients? The idea is, we let modules decide which services, among those they provide, to export. For a exported service, it should provide headers, not depending on internal headers, to describe the interface. Of course error-checking should be done with more care in this case. To make finding a service faster, we can use integers as service id, instead of strings. These are what I can think of now. Surely there are more things we should pay attention to when exporting services, but it also means freetype can get more powerful. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Export services?
On Fri, Oct 14, 2005 at 08:39:13PM +0200, Werner LEMBERG wrote: > > There are some functions which are wrappers to services. Then why > > not simply export the services to clients? > Please give an example how you would like to rearrange services. For example, we can export WINFNT. Then instead of calling "FT_Get_WinFNT_Header", which is simply a wrapper, client can call "FT_Find_Service" to request the service directly. Same other services, like OPENTYPE_VALIDATE, GLYPH_DICT, POSTSCRIPT_FONT_NAME, etc., are also ready to be exported. > > To make finding a service faster, we can use integers as service id, > > instead of strings. > > Do you really think that this is of great importance? Strings are > more user-friendly IMHO. We now call "FT_FACE_FIND_SERVICE( GLYPH_DICT )" to find a service. After the change, we still call "FT_FACE_FIND_SERVICE( GLYPH_DICT )" to find a service. So most part of the library won't know the differences, except "ft_service_list_lookup". This may be of some importance when trying to find a global service. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Export services?
On Fri, Oct 14, 2005 at 10:11:21PM +0200, David Turner wrote:
> the "wrapper" functions are here to protect the users of the service's
> implementation details. They have various advantages:
>
> - they expose a "clean" API that doesn't depend on internals of
> the font engine. Allowing us to redesign services when needed
>
> - services can be used either internally or to implement a public
> API.
> in other words, exposing services publicly has many problems:
>
> - it forces us to expose more internals of the font engine, which
> means less possibilities for improvements in the future. And
> it's not like we've not been burned by this already
> (i.e. FT_OPTIMIZE_MEMORY breaks rogue libraries)
> - it forces us to add a way to distinguish between "internal"
> and "public" services.
This won't be hard because we can list services like
{ SERVICE_ID, POINTER_TO_FUNCTION, PUBLIC_OR_NOT },
where PUBLIC_OR_NOT is the new field.
An exported service is like an exported function call, once get
exported, it allows no change. Or we may say it's a way for the modules
to export module-specific API. Since it is module-specific, I think
it's better exported by the module itself, and not by a wrapper function
in "base".
Currently, wrapper functions in "base" are either simply wrappers, which
are good candicates of services to be exported, or high-level functions
of the services, i.e. they ease the pain of using the low-level
services. In the latter case, we can hide the low-level service and
export a high-level one, like the wrapper function is. The bottom line
is, it's a way for the module to export API.
> And I don't see how they could make the engine "more powerful".
Those services I can think of are already wrapped :(
Hmm, maybe we can export the byte interpreter as a service, then a
client can use this service to show how intructions instruct a glyph
vividly.
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Glyphslot_Embolden is broken at sometimes.
On Wed, Oct 26, 2005 at 11:00:09PM +0200, Werner LEMBERG wrote: > > FT_Glyphslot_Embolden works at most of time, but sometimes it > > doesn't(see attachment). To run the testcase, you need simsun.ttc > > from windows. Any comments? > > Which FT version? > > Unfortunately, I don't have simsun.ttc so I can't test it. Chai-I? > > BTW, I don't have cairo either -- can you reproduce the problem with > ftview from the ft2demos package, using the current CVS? The character shown in the .png (U+60CA) has a contour of width 0, namely all points have same x value (bug?), in the left top corner. It misleads FT_Outline_Get_Orientation. Thus instead of emboldened, each stroke got shrinked. Similar issues have already been seen in some free traditional Chinese fonts. They have glyphs consisting of components of different orientations. I think it's a bug of the font and since those fonts are actively maintained, I reported the issue to the font authors, after failed to work around this in freetype. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] some functions are FT_EXPORT declared in the internal headers
Hi, These functions are FT_EXPORT_DEF'ed and declared by FT_EXPORT in the internal headers: FT_Sqrt32 FT_SqrtFixed FT_Trace_Get_Count FT_Trace_Get_Name FT_Message FT_Panic FT_New_Memory FT_Done_Memory FT_Stream_Open Shouldn't they be declared by FT_BASE instead? If they are, I can fix them. And there are two FT_EXPORT_DEF'ed functions in the sources: FT_MulTo64 TT_New_Context The first one should have a declaration in the headers, or be commented out as it is not used. And the second one should be FT_LOCAL_DEF'ed. (or is it used by fontforge?) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype CVS & fontconfig
On Tue, Nov 15, 2005 at 11:24:56PM +0200, Ismail Donmez wrote: > On Tuesday 15 November 2005 23:21, Ismail Donmez wrote: > > On Tuesday 15 November 2005 23:18, you wrote: > > > Hello, > > > > > > FT_Free was *never* public. You should upgrade your fontconfig to a more > > > recent version, since it must include the necessary patch to get rid of > > > all FT2 internals dependencies. > > Sorry for empty reply. I use Fontconfig from CVS so I don't think there is > any > more recent version of it. There is a patch here: https://bugs.freedesktop.org/show_bug.cgi?id=4779 (Is this patch going to be applied upstream?) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] failed to compile ftvalid.c
Hi, When compiling ftvalid.c, I get this error: ft2demos/obj/ftvalid.o: In function `run_ot_validator': ft2demos/src/ftvalid.c:447: undefined reference to `FT_Free_Debug' ft2demos/obj/ftvalid.o: In function `run_gx_validator': ft2demos/src/ftvalid.c:498: undefined reference to `FT_Free_Debug' ft2demos/obj/ftvalid.o: In function `run_ckern_validator': ft2demos/src/ftvalid.c:566: undefined reference to `FT_Free_Debug' FT_Free_Debug is called indirectly by FT_FREE to free various tables, which is no longer public. (and freetype reports leaks when use `free' , not FT_FREE, to free these tables) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
On Thu, Nov 17, 2005 at 03:47:38PM +0900, [EMAIL PROTECTED] wrote: > Hi, > > On Thu, 17 Nov 2005 11:46:09 +0900 > [EMAIL PROTECTED] wrote: > Excuse me, you received this error in compiling ftvalid.c > into ftvalid.o? Or, you received it in linking ftvalid.o > to ftvalid executable? It's in linking. > If it's in linking, it's a bit complexed problem. GNU ld > with --retain-symbols-file removes unlisted symbols from > .symtab, but don't remove them from .dynsym. As a result, > I cannot find FT_Free_Debug in > "nm -a freetype2/objs/.libs/libfreetype.so", > but I can find it in > "nm -D freetype2/objs/.libs/libfreetype.so". On my machine, $ nm -a objs/.libs/libfreetype.so | grep Free_Debug 6cb8 t FT_Free_Debug $ nm -D objs/.libs/libfreetype.so | grep Free_Debug (gives nothing) $ nm --version GNU nm 2.16.91 20050902 Debian GNU/Linux > > When I link ftvalid.o refering FT_Free_Debug(), > with libfreetype.so that does not have FT_Free_Debug() in its > .symtab, GNU ld detects that FT_Free_Debug() exists in > libfreetype.so, and linking is finished successfully. > When I add "-Wl,--trace-symbol=FT_Free_Debug", I receive > following output. GNU ld detects FT_Free_Debug() in > libfreetype.so. > > $ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \ > -DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY \ > -o ./bin/.libs/ftvalid \ > ./obj/ftvalid.o ./obj/common.o \ > ../freetype2/objs/.libs/libfreetype.so \ > -lz > > ./obj/ftvalid.o: reference to FT_Free_Debug > ../freetype2/objs/.libs/libfreetype.so: definition of FT_Free_Debug > $ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \ -DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY -o \ ./bin/.libs/ftvalid ./obj/ftvalid.o ./obj/common.o \ ../freetype2/objs/.libs/libfreetype.so -lz ./obj/ftvalid.o: reference to FT_Free_Debug ./obj/ftvalid.o: In function `run_ot_validator': /home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:447: undefined reference to `FT_Free_Debug' ./obj/ftvalid.o: In function `run_gx_validator': /home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:498: undefined reference to `FT_Free_Debug' ./obj/ftvalid.o: In function `run_ckern_validator': /home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:566: undefined reference to `FT_Free_Debug' collect2: ld returned 1 exit status $ gcc --version gcc (GCC) 4.0.3 20051023 (prerelease) (Debian 4.0.2-3) $ ld --version GNU ld version 2.16.91 20050902 Debian GNU/Linux > I guess this is the known behaviour of GNU ld, See: > http://sourceware.org/ml/binutils/2001-12/msg00143.html > > How did you remove FT_Free_Debug() completely? Same error message. > > P.S. > BTW, now I think about this issue: the tools outside of libfreetype > should not refer FT_Alloc_Debug(), FT_Free_Debug() etc etc anymore. > Therefore, ftvalid.c should include ftdbgmem.c by itself? I suggest exporting another function, which simply calls FT_FREE, to free the tables. When FT_DEBUG_MEMORY is not defined, the clients can `free' the table without causing any problem. But when it is, this confuses leak detection (some FT_ALLOC'ed memories are not FT_FREE'ed) and causes double free. Or, we can have two versions of validating. One does everything automatically, like the current one, and free the tables before returning. The other only validates. Clients should prepare buffers and FT_Load_Sfnt_Table themselves. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] fixed offset calculation in EBLC table
Hi, In memory optimized `tt_sbit_decoder_load_image', when index_format is 2 or 5, image_offset is added to image_start twice. This bug is trivial. But as I don't have a font to test, I send this patch to the list for review, in case I misunderstood the code. BTW, are there fonts having EBSC table? It seems fun to add support for this table. -- Regards, olv 2005-11-18 Chia-I Wu <[EMAIL PROTECTED]> * src/sfnt/ttsbit0.c (tt_sbit_decoder_load_image): image_offset is added to image_start twice when image_format is 2 or 5. === src/sfnt/ttsbit0.c == --- src/sfnt/ttsbit0.c (revision 2826) +++ src/sfnt/ttsbit0.c (local) @@ -830,7 +830,7 @@ if ( tt_sbit_decoder_load_metrics( decoder, &p, p_limit, 1 ) ) goto NoBitmap; -image_start = image_offset + image_size * ( glyph_index - start ); +image_start = image_size * ( glyph_index - start ); image_end = image_start + image_size; } break; @@ -910,7 +910,7 @@ if ( mm >= num_glyphs ) goto NoBitmap; -image_start = image_offset + image_size*mm; +image_start = image_size*mm; image_end = image_start + image_size; } break; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] fixed offset calculation in EBLC table
On Fri, Nov 18, 2005 at 05:24:26PM +0800, Chia-I Wu wrote: > In memory optimized `tt_sbit_decoder_load_image', when index_format is 2 > or 5, image_offset is added to image_start twice. > > This bug is trivial. But as I don't have a font to test, I send this > patch to the list for review, in case I misunderstood the code. I've committed this fix, untested. If someone finds it wrong later, I will undo it. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] current cvs on suse 10
On Mon, Nov 21, 2005 at 01:06:22AM +0100, Hans-Peter Jansen wrote: > (FT_Stream_OpenGzip and FT_Stream_OpenLZW still used FT_EXPORT). They should be FT_EXPORT'ed as they are not used inside freetype. I don't know how to use them though. > That leaves me with a couple of questions: > - Should I prepare some (more) diffs from these issues? If you just want to test CVS freetype, you can use the attached _hack_ to make freetype export all symbols. Then all apps using freetype should compile. BTW, Should this hack be included in CVS temporary? Current CVS sort of discourages people from testing. > - What are your plans with this unofficial ftstream interface? You can find ftglue.[ch] in pango which re-implement many FT_Stream related functions. There is also a patch for fontconfig to use ftglue. > - Any rough estimation on code maturity of current CVS? -- Regards, olv === builds/exports.mk == --- builds/exports.mk (revision 2912) +++ builds/exports.mk (local) @@ -64,6 +64,7 @@ $(subst /,$(SEP),$(APINAMES_EXE)) -o$@ $(APINAMES_OPTIONS) $(PUBLIC_HEADERS) @echo TT_New_Context >> $(EXPORTS_LIST) @echo TT_RunIns >> $(EXPORTS_LIST) + @echo '*' >> $(EXPORTS_LIST) $(PROJECT_LIBRARY): $(EXPORTS_LIST) ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] use binary search for cmap format 12
Hi,
This patch makes freetype use binary search to map charcode to glyph
index for truetype cmap format 12.
Testing with fonts from
http://freedesktop.org/wiki/Software_2fCJKUnifonts gives:
ukai.ttf
-
(original)
Get_Char_Index : 61.833 us/op
Charmap iteration : 1605377.533 us/op
(binary)
Get_Char_Index : 0.444 us/op
Charmap iteration : 2807.427 us/op
uming.ttf
-
(original)
Get_Char_Index : 63.230 us/op
Charmap iteration : 1643916.969 us/op
(binary)
Get_Char_Index : 0.440 us/op
Charmap iteration : 2749.562 us/op
Please test. If there is no problem nor objections, I will commit it in
2 or 3 days.
I am also looking into cmap format 4, to make freetype consider
overlapped segments sorted, provided their start/end points are sorted.
This could help a lot for bkai00mp.ttf:
bkai00mp.ttf
-
(original)
Get_Char_Index : 32.298 us/op
Charmap iteration : 460667.588 us/op
(sorted)
Get_Char_Index : 0.407 us/op
Charmap iteration : 1304.434 us/op
But there is one small performance problem with segment having offset
0x. Currently, such segment is interpreted as empty segment. Can
it be interpreted in other ways, like map every charcode to 0 or just
treat it as if the offset is 0? The latter makes sense if it is always
used like this:
Segment=33 unicode-start= end= range-offset=65535 delta=1 End
--
Regards,
olv
2005-11-28 Chia-I Wu <[EMAIL PROTECTED]>
* src/sfnt/ttcmap.c (struct TT_CMap12Rec_, tt_cmap12_init,
tt_cmap12_next): New struct/function for fast "next char".
(tt_cmap12_char_map_binary): New function to do "charcode => glyph
index" by binary search.
(tt_cmap12_char_index, tt_cmap12_char_next): Use
tt_cmap12_char_map_binary.
(tt_face_build_cmaps): Check table and offset correctly (equality is
missing).
=== src/sfnt/ttcmap.c
==
--- src/sfnt/ttcmap.c (revision 2916)
+++ src/sfnt/ttcmap.c (local)
@@ -1916,7 +1916,34 @@
#ifdef TT_CONFIG_CMAP_FORMAT_12
+ typedef struct TT_CMap12Rec_
+ {
+TT_CMapRec cmap;
+FT_Bool valid;
+FT_ULongcur_charcode;
+FT_UInt cur_gindex;
+FT_ULongcur_group;
+FT_ULongnum_groups;
+
+ } TT_CMap12Rec, *TT_CMap12;
+
+
FT_CALLBACK_DEF( FT_Error )
+ tt_cmap12_init( TT_CMap12 cmap,
+ FT_Byte* table )
+ {
+cmap->cmap.data = table;
+
+table+= 12;
+cmap->num_groups = FT_PEEK_ULONG( table );
+
+cmap->valid = 0;
+
+return SFNT_Err_Ok;
+ }
+
+
+ FT_CALLBACK_DEF( FT_Error )
tt_cmap12_validate( FT_Byte* table,
FT_Validator valid )
{
@@ -1968,77 +1995,176 @@
}
- FT_CALLBACK_DEF( FT_UInt )
- tt_cmap12_char_index( TT_CMapcmap,
-FT_UInt32 char_code )
+ /* find the index of the charcode next to cmap->cur_charcode */
+ /* cmap->cur_group should be set up properly by caller */
+ /* */
+ static void
+ tt_cmap12_next( TT_CMap12 cmap )
{
-FT_UIntresult = 0;
-FT_Byte* table = cmap->data;
-FT_Byte* p = table + 12;
-FT_UInt32 num_groups = TT_NEXT_ULONG( p );
-FT_UInt32 start, end, start_id;
+FT_Byte* p;
+FT_ULong start, end, start_id, char_code;
+FT_ULong n;
+FT_UInt gindex;
-for ( ; num_groups > 0; num_groups-- )
+if ( cmap->cur_charcode >= 0xUL )
+ goto Fail;
+
+char_code = cmap->cur_charcode + 1;
+
+n = cmap->cur_group;
+
+for ( n = cmap->cur_group; n < cmap->num_groups; n++ )
{
+ p= cmap->cmap.data + 16 + 12 * n;
start= TT_NEXT_ULONG( p );
end = TT_NEXT_ULONG( p );
- start_id = TT_NEXT_ULONG( p );
+ start_id = TT_PEEK_ULONG( p );
if ( char_code < start )
-break;
+char_code = start;
- if ( char_code <= end )
+ for ( ; char_code <= end; char_code++ )
{
-result = (FT_UInt)( start_id + char_code - start );
-break;
+gindex = (FT_UInt)( start_id + char_code - start );
+
+if ( gindex )
+{
+ cmap->cur_charcode = char_code;;
+ cmap->cur_gindex = gindex;
+ cmap->cur_group= n;
+
+ return;
+}
}
}
-return result;
+
+ Fail:
+cmap->valid = 0;
}
- FT_CALLBACK_DEF( FT_UInt )
- tt_cmap12_char_next( TT_CMap cmap,
- FT_UInt32 *pchar_code )
+ static FT_UInt
+ tt_cmap12_char_map_binary( TT_CMap cmap,
+ FT_UInt32* pchar_code,
+
Re: [ft-devel] Problem with Verdana font
On Sat, Nov 26, 2005 at 05:51:59PM +0200, Ismail Donmez wrote: > I never remember seeing this bug before but maybe this is a bug in font newly > exposed. Comments? I have no such problem, using Freetype CVS. The `N' in the screenshot looks like from some fallback font, not from verdanab.ttf. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] distinguish overlapped and unsorted segments in cmap format 4
Hi,
The problem I mentioned in the last mail is solved by replacing the bool
`cmap->unsorted' by `cmap->flags.' So here is the patch.
For "bad" fonts, the improvement is great, since we can do binary search
now:
bkai00mp.ttf
-
(original)
Get_Char_Index : 31.956 us/op
Charmap iteration : 454657.805 us/op
(new)
Get_Char_Index : 0.376 us/op
Charmap iteration : 1274.315 us/op
As for "good" fonts, there is no big impact on them. FT_Get_Char_Index
is slightly slower partly because of function call overhead, i.e.
`char_index' and `char_next' are wrappers to the same function. I have
not yet check how other cmap classes implment `char_index' and
`char_next'. If it turns out only one function is needed, we can change
the cmap class interface and the overhead disappears.
Charmap iteration is faster for unknown reason :-)
Vera.ttf
-
(original)
Get_Char_Index : 0.191 us/op
Charmap iteration : 25.127 us/op
(new)
Get_Char_Index : 0.209 us/op
Charmap iteration : 23.035 us/op
Please test if fonts still work correctly, "good" or "bad". Also,
please let me know if you find other fonts which is "bad" too.
(according to the comments in the code, they are Asian fonts. I am kind
of afraid it only refers to bkai00mp.ttf.)
--
Regards,
olv
Major update to distinguish between unsorted and overlapped segments
for cmap format 4. For overlapped but sorted segments, which is
previously considered unsorted, we still use binary search.
* src/sfnt/ttcmap.h (struct TT_CMapRec_): Replace `unsorted' by
`flags'.
(TT_CMAP_FLAG_UNSORTED, TT_CMAP_FLAG_OVERLAPPED): New macros.
* src/sfnt/ttcmap.c (OPT_CMAP4): Removed as it is always defined.
(struct TT_CMap4Rec_): Remove `old_charcode' and `table_length'.
(tt_cmap4_reset): Removed.
(tt_cmap4_init): Update accordingly.
(tt_cmap4_next): Update accordingly.
Take care of overlapped segments.
(tt_cmap4_validate): Make sure the subtable is large enough.
Do not check glyph_ids because some fonts set the length wrongly. Also
when all segments have offset 0, glyph_ids is always invalid. It does
not cause any problem so far because the check misses equality.
Distinguish between unsorted and overlapped segments.
(tt_cmap4_char_map_linear, tt_cmap4_char_map_binary): New functions to
do "charcode => glyph index" by linear/binary search.
(tt_cmap4_char_index, tt_cmap4_char_next): Use
tt_cmap4_char_map_linear and tt_cmap4_char_map_binary.
(tt_face_build_cmaps): Treat the return value of validator as flags
for cmap.
=== src/sfnt/ttcmap.c
==
--- src/sfnt/ttcmap.c (revision 2937)
+++ src/sfnt/ttcmap.c (local)
@@ -625,18 +625,12 @@
#ifdef TT_CONFIG_CMAP_FORMAT_4
-#define OPT_CMAP4
-
-#ifdef OPT_CMAP4
-
typedef struct TT_CMap4Rec_
{
TT_CMapRec cmap;
-FT_UInt32 old_charcode; /* old charcode */
FT_UInt32 cur_charcode; /* current charcode */
FT_UInt cur_gindex; /* current glyph index */
-FT_UInt table_length;
FT_UInt num_ranges;
FT_UInt cur_range;
FT_UInt cur_start;
@@ -656,14 +650,9 @@
cmap->cmap.data= table;
-p = table + 2;
-cmap->table_length = FT_PEEK_USHORT( p );
-
p = table + 6;
cmap->num_ranges = FT_PEEK_USHORT( p ) >> 1;
-cmap->cur_range= cmap->num_ranges;
-cmap->old_charcode = 0xUL;
-cmap->cur_charcode = 0;
+cmap->cur_charcode = 0xUL;
cmap->cur_gindex = 0;
return SFNT_Err_Ok;
@@ -707,22 +696,28 @@
range_index++;
}
-cmap->old_charcode = 0xUL;
-cmap->cur_charcode = 0;
-cmap->cur_gindex = 0;
-cmap->cur_range= num_ranges;
return -1;
}
+ /* find the index of the charcode next to cmap->cur_charcode; */
+ /* caller should call tt_cmap4_set_range with proper range*/
+ /* before calling this function */
+ /**/
static void
tt_cmap4_next( TT_CMap4 cmap )
{
-FT_UInt charcode = cmap->cur_charcode + 1;
+FT_UInt charcode;
+
+if ( cmap->cur_charcode >= 0xUL )
+ goto Fail;
-cmap->old_charcode = cmap->cur_charcode;
+charcode = cmap->cur_charcode + 1;
+if ( charcode < cmap->cur_start )
+ charcode = cmap->cur_start;
+
for ( ;; )
{
FT_Byte* values = cmap->cur_values;
@@ -775,27 +770,16 @@
if ( tt_cmap4_set_range( cmap, cmap->cur_range + 1 ) < 0 )
break;
- charcode = cmap->cur_start;
+ if ( charcode < cmap->cur_start )
+charcode = cmap->cur_start;
}
- }
Re: [ft-devel] [patch] distinguish overlapped and unsorted segments in cmap format 4
Hi, > > The problem I mentioned in the last mail is solved by replacing the > > bool `cmap->unsorted' by `cmap->flags.' So here is the patch. > Both patches look good! Please add them to the CVS. I'll then run my > suite of bad and problematic fonts... Ok, I've committed. There is one difference in format 4, in how charcode 0 is mapped when offset is 0. In my code and the original `tt_cmap4_char_next', `delta' is always added to `charcode' to get `gindex', as the spec says. On the other hand, in original `tt_cmap4_char_index', `delta' is added to `charcode' only when `charcode' != 0. Take this segment, Segment=0 unicode-start= end=007f range-offset=0 delta=1, for example, 0 is mapped to 1 in the new code, while it is mapped to 0 in the original code. There are also some differences when segments are unsorted. The original code assumes the unsorted segments are still somewhat sorted and these assumptions are all removed now. Other differences should be bugs. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New warnings
On Wed, Nov 30, 2005 at 01:06:58AM +0200, Ismail Donmez wrote: Hi, > Looks like latest cmap commit introduced some new warnings: I've commit a fix. Please test again. (they are false positive, btw) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A simple script to test
Hi,
I've commit a patch to make ftdump support -c, show charmap contents.
With that, and the simple script `cmaptest' which can be found in the
attachment, you can easily test if things still work correctly.
The usage is ./cmaptest and it will show the differences.
Note that it assumes there is an unmodified version of freetype under
/usr/lib.
--
Regards,
olv
#!/bin/sh
[ -d $1 ] || exit
for i in $1/*.{ttf,TTF,ttc,TTC,otf,OTF}
do
[ -f "$i" ] || continue
fn=`basename "$i"`
echo "testing $fn"
LD_LIBRARY_PATH=/usr/lib ftdump -c -c "$i" > "$fn".old
ftdump -c -c "$i" > "$fn".new
diff -u "$fn".old "$fn".new || echo
rm "$fn".old "$fn".new
done
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] BDF and FT_Set_Pixel_Sizes
Hi,
According to the document,
This means that setting the pixel size to, say, 8x8 doesn't guarantee in
any way that you get glyph bitmaps that all fit within an 8x8 cell
(sometimes even far from it).
...
For BDF and PCF formats, this function uses the sum of the `FONT_ASCENT'
and `FONT_DESCENT' properties of the bitmap font.
I find these two paragraphs conflicting. If we use the sum of
FONT_ASCENT and FONT_DESCENT to match against, then all glyphs are
within the 8x8 cell, provided FT_Set_Pixel_Size( face, 8, 8 ) returns
success. Or put it in another way, it means when the face is scalable,
we should set
x_scale = 8 / ( face->bbox.xMax - faec->bbox.xMin ),
y_scale = 8 / ( face->bbox.yMax - faec->bbox.yMin ),
so that all glyphs are within the 8x8 cell. And this is really not
intuitive.
I also have a (maybe stupid) question. Why don't we simply have
FT_Set_Pixel_Sizes( face, w, h )
{
FT_Set_Char_Size( face, w, h, 72, 72 ):
}
?
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
On Sat, Dec 03, 2005 at 04:15:09PM +0800, Chia-I Wu wrote:
> I find these two paragraphs conflicting. If we use the sum of
> FONT_ASCENT and FONT_DESCENT to match against, then all glyphs are
> within the 8x8 cell, provided FT_Set_Pixel_Size( face, 8, 8 ) returns
> success. Or put it in another way, it means when the face is scalable,
> we should set
> x_scale = 8 / ( face->bbox.xMax - faec->bbox.xMin ),
> y_scale = 8 / ( face->bbox.yMax - faec->bbox.yMin ),
> so that all glyphs are within the 8x8 cell. And this is really not
> intuitive.
Any comment?
I found this mail
http://lists.gnu.org/archive/html/freetype-devel/2004-07/msg00011.html
and BDF_Set_Pixel_Sizes was changed because otherwise
FTC_Manager_LookupSize would return error if we set
scaler.width = face->available_sizes->width;
scaler.height = face->available_sizes->height;
scaler.pixel = TRUE;
But shouldn't the scaler be set up like this:
scaler.width = face->available_sizes->x_ppem;
scaler.height = face->available_sizes->y_ppem;
scaler.pixel = TRUE;
?
> I also have a (maybe stupid) question. Why don't we simply have
>
> FT_Set_Pixel_Sizes( face, w, h )
> {
> FT_Set_Char_Size( face, w, h, 72, 72 ):
> }
>
> ?
(More looking forward to comments on this question actually)
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
On Tue, Dec 06, 2005 at 11:53:01AM +0100, Werner LEMBERG wrote: > How do you come to this conclusion? The original BDF specification > (found in the X11 distribution) says that both FONT_ASCENT and > FONT_DESCENT are *logical* values. They don't guarantee that all > bitmap glyphs are within this range. Sorry, I thought they are calculated (5005.BDF_Spec.pdf doesn't mention them). Still, then we should set y_scale to 8 / (face->ascender + face->descender) in, for example, Set_Pixel_Sizes in ttdriver.c, shouldn't we? I found docs/CHANGES mentions this change and it says FT_Set_Pixel_Size is used to select actual font dimensions (the `strike'), not the nominal size. Maybe my question is what "actual font dimensions" mean? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
Hi, > The question isn't stupid at all. The difference comes from the TrueType > bytecode specification, which makes a specific distinction between these > two scaling modes. > I can't remember the details though... Hmm... the truetype driver doesn't seem to distinguish them. Is it unimplemented or something? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
On Wed, Dec 07, 2005 at 03:26:12PM +0100, Werner LEMBERG wrote:
> > > How do you come to this conclusion? The original BDF
> > > specification (found in the X11 distribution) says that both
> > > FONT_ASCENT and FONT_DESCENT are *logical* values. They don't
> > > guarantee that all bitmap glyphs are within this range.
> >
> > Still, then we should set y_scale to 8 / (face->ascender +
> > face->descender) in, for example, Set_Pixel_Sizes in ttdriver.c,
> > shouldn't we?
>
> I'm not sure -- and too lazy to really think about it :-) Do you
> encounter problems with bitmap sizes?
I have two fonts, Chicago.12.bdf and Chicago.bin. The former has
FONT_ASCENT 12 and FONT_DESCENT 3 and the latter is scalable.
When I `ftview' Chicago.bin, at size 12, it looks almost the same as
Chicago.12.bdf, while at size 15, it is obviously larger. This
inconsistency comes from the fact that for BDF font, FT_Set_Pixel_Sizes
selects the real dimensions, while for scalable font, it selects the
nominal size. With the scaling I mentioned in the last mail, then we
have the consistency back (assuming real dimensions mean ascent +
descent, see below).
Actually, I think fixed sizes should be selected by its index in
face->available_sizes, not by FT_Set_{Char,Pixel}_Sizes. Since font
drivers have enumerated all sizes in face->available_sizes, clients can
choose the one best match their desire directly.
> > I found docs/CHANGES mentions this change and it says
> > FT_Set_Pixel_Size is used to select actual font dimensions (the
> > `strike'), not the nominal size. Maybe my question is what "actual
> > font dimensions" mean?
>
> Well, if the font contains an 8x16 bitmap, the parameters are `8' and
> `16'. This is to get a unified interface to all bitmap formats,
> including Windows FNT. Note that the ppem values in WinFNT files are
> normally incorrect.
`16' means ascent + descent? I thought 8x16 is the size of the canvas,
which is equal to or larger than the glyph bounding box.
> BTW, your latest changes to the SFNT driver broke FNT files with
> multiple faces (this is, if they contain more than a single bitmap
> font). Reason is that the check for `face_index' in the SFNT driver
> is done before validation of the font format -- the driver incorrectly
> returns SFNT_Err_Bad_Argument instead of the correct
> SFNT_Err_Unknown_File_Format. I've fixed that now.
Thank you.
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
Hi,
I guess I better describe the problem more thoroughly. Let's begin with
a review of the current status of FT_Set_Pixel_Sizes.
FT_Set_{Char,Pixel}_Sizes, at the first place, is used to set the size
of the em square (nominal size). It works well with all scalable fonts.
And in theory, it should work well with all bitmap fonts supported
because they all come with nominal size information.
But the world is not perfect and WinFNT fonts often have incorrect
nominal size information. Without better solution, WinFNT driver is
forced to use the real height (ascent + descent) as fonts' nominal size.
As a result, WinFNT fonts look smaller than others at the same nominal
size.
To remedy this, the definition of FT_Set_Pixel_Sizes is changed to set
the real height, not the nominal height. BDF/PCF drivers are also
updated to reflect this change.
As you can see, the problem is that other drivers are not updated. The
scaling I mentioned in my another mail should be used for scalable font
drivers. Sbit needs update too.
Actually, I personally don't like this change. Because
- When use FT_Set_Char_Sizes, WinFNT fonts still look smaller.
- We made or will have to make all the changes only because WinFNT fonts
give incorrect nominal size information.
I think a better solution is undo all the changes and add a special note
for WinFNT fonts. Or even better, I propose following INTERNAL changes:
--- ftdriver.h 2005-12-06 17:38:43.0 +0800
+++ ftdriver.new.h 2005-12-09 08:19:48.0 +0800
@@ -51,18 +51,29 @@
typedef void
(*FT_Slot_DoneFunc)( FT_GlyphSlot slot );
+ enum
+ {
+SIZE_REQUEST_NOMINAL,
+SIZE_REQUEST_REAL_DIM,
+SIZE_REQUEST_BOUNDING_BOX
+ }
+
+ typedef struct FT_Size_RequestRec_
+ {
+FT_F26Dot6 width;
+FT_F26Dot6 height;
+FT_UInt horiResolution;
+FT_UInt vertResolution;
+FT_Int type;
+ } FT_Size_RequestRec, *FT_Size_Request;
typedef FT_Error
- (*FT_Size_ResetPointsFunc)( FT_Size size,
- FT_F26Dot6 char_width,
- FT_F26Dot6 char_height,
- FT_UInt horz_resolution,
- FT_UInt vert_resolution );
+ (*FT_Size_RequestFunc)( FT_Size size,
+ FT_Size_Request req );
typedef FT_Error
- (*FT_Size_ResetPixelsFunc)( FT_Size size,
- FT_UInt pixel_width,
- FT_UInt pixel_height );
+ (*FT_Face_SelectSizeFunc)( FT_Face face,
+ FT_Int index );
typedef FT_Error
(*FT_Slot_LoadFunc)( FT_GlyphSlot slot,
@@ -129,13 +140,15 @@
/* */
/*done_slot:: The format-specific slot destructor. */
/* */
- /*set_char_sizes :: A handle to a function used to set the new */
- /*character size in points + resolution. Can be */
- /*set to 0 to indicate default behaviour.*/
- /* */
- /*set_pixel_sizes :: A handle to a function used to set the new */
- /*character size in pixels. Can be set to 0 to */
- /*indicate default behaviour.*/
+ /*request_size :: A handle to a function used to set the new */
+ /*character size. It is used only when */
+ /*@FT_FACE_FLAG_SCALABLE is set. Can be set to */
+ /*0 to indicate default behaviour. */
+ /* */
+ /*select_size :: A handle to a function used to select a new*/
+ /*character size. It is used only when */
+ /*@FT_FACE_FLAG_FIXED_SIZES is set. Can be set */
+ /*to 0 indicate default behaviour. */
/* */
/*load_glyph :: A function handle to load a given glyph image */
/*in a slot. This field is mandatory! */
@@ -186,8 +199,8 @@
FT_Slot_InitFunc init_slot;
FT_Slot_DoneFunc done_slot;
-FT_Size_ResetPointsFunc set_char_sizes;
-FT_Size_ResetPixelsFunc set_pixel_sizes;
+FT_Size_RequestFunc request_size;
+FT_Face_SelectSizeFuncselect_size;
FT_Slot_LoadFunc load_glyph;
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] global font metrics are rounded?
Hi, freetype rounds the global font metrics in ft_recompute_scaled_metrics in a conservative way. That is, ascender is ceiled and descender is floored. This gives unpleasant gaps between lines in big5 art, i.e. ascii art with big5 characters: http://homepage.ntu.edu.tw/~r94221003/big5art1.png Xft also rounds global font metrics. However, it rounds by flooring ascender and ceiling descender. Thus when rounding is disabled in freetype, the gaps are gone (note that glyphs in the menu bar are also affected): http://homepage.ntu.edu.tw/~r94221003/big5art2.png For comparison, this is what windows users expect to see: http://homepage.ntu.edu.tw/~r94221003/big5artwin.png (different resolutions and different font) To sum up, I think freetype should not round global font metrics (nor glyph metrics) and let clients decide how to deal with them, despite that clients are able to get the unrounded values by scaling themselves. As the effect is large (all apps using Xft), I need your opinions. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] global font metrics are rounded?
On Fri, Dec 09, 2005 at 01:59:37PM +0800, Chia-I Wu wrote:
> To sum up, I think freetype should not round global font metrics (nor
> glyph metrics) and let clients decide how to deal with them, despite
> that clients are able to get the unrounded values by scaling themselves.
>
> As the effect is large (all apps using Xft), I need your opinions.
If there is no objection, I will commit the attached patch later today.
--
Regards,
olv
=== include/freetype/internal/ftobjs.h
==
--- include/freetype/internal/ftobjs.h (revision 2971)
+++ include/freetype/internal/ftobjs.h (local)
@@ -452,13 +452,6 @@
/* */
/*
- * grid-fit slot->metrics
- */
- FT_BASE( void )
- ft_glyphslot_grid_fit_metrics( FT_GlyphSlot slot );
-
-
- /*
* Free the bitmap of a given glyphslot when needed
* (i.e., only when it was allocated with ft_glyphslot_alloc_bitmap).
*/
=== src/base/ftobjs.c
==
--- src/base/ftobjs.c (revision 2971)
+++ src/base/ftobjs.c (local)
@@ -251,29 +251,6 @@
FT_BASE_DEF( void )
- ft_glyphslot_grid_fit_metrics( FT_GlyphSlot slot )
- {
-FT_Pos tmp;
-
-
-tmp = FT_PIX_CEIL( slot->metrics.horiBearingX + slot->metrics.width );
-slot->metrics.horiBearingX = FT_PIX_FLOOR( slot->metrics.horiBearingX );
-slot->metrics.width= tmp - slot->metrics.horiBearingX;
-
-tmp = FT_PIX_FLOOR( slot->metrics.horiBearingY - slot->metrics.height );
-slot->metrics.horiBearingY = FT_PIX_CEIL( slot->metrics.horiBearingY );
-slot->metrics.height = slot->metrics.horiBearingY - tmp;
-
-slot->metrics.horiAdvance = FT_PIX_ROUND( slot->metrics.horiAdvance );
-
-slot->metrics.vertBearingX = FT_PIX_FLOOR( slot->metrics.vertBearingX );
-/* note that vertBearingY should be floor'ed */
-slot->metrics.vertBearingY = FT_PIX_FLOOR( slot->metrics.vertBearingY );
-slot->metrics.vertAdvance = FT_PIX_ROUND( slot->metrics.vertAdvance );
- }
-
-
- FT_BASE_DEF( void )
ft_glyphslot_set_bitmap( FT_GlyphSlot slot,
FT_Byte* buffer )
{
@@ -1983,17 +1960,17 @@
{
/* Compute root ascender, descender, test height, and max_advance */
-metrics->ascender= FT_PIX_CEIL( FT_MulFix( face->ascender,
- metrics->y_scale ) );
+metrics->ascender= FT_MulFix( face->ascender,
+ metrics->y_scale );
-metrics->descender = FT_PIX_FLOOR( FT_MulFix( face->descender,
-metrics->y_scale ) );
+metrics->descender = FT_MulFix( face->descender,
+ metrics->y_scale );
-metrics->height = FT_PIX_ROUND( FT_MulFix( face->height,
-metrics->y_scale ) );
+metrics->height = FT_MulFix( face->height,
+ metrics->y_scale );
-metrics->max_advance = FT_PIX_ROUND( FT_MulFix( face->max_advance_width,
-metrics->x_scale ) );
+metrics->max_advance = FT_MulFix( face->max_advance_width,
+ metrics->x_scale );
}
=== src/cff/cffgload.c
==
--- src/cff/cffgload.c (revision 2971)
+++ src/cff/cffgload.c (local)
@@ -2687,9 +2687,6 @@
metrics->horiBearingX = cbox.xMin;
metrics->horiBearingY = cbox.yMax;
-
-if ( hinting )
- ft_glyphslot_grid_fit_metrics( &glyph->root );
}
}
=== src/cid/cidgload.c
==
--- src/cid/cidgload.c (revision 2971)
+++ src/cid/cidgload.c (local)
@@ -402,9 +402,6 @@
/* make up vertical ones */
metrics->vertBearingX = 0;
metrics->vertBearingY = 0;
-
-if ( hinting )
- ft_glyphslot_grid_fit_metrics( cidglyph );
}
}
=== src/truetype/ttgload.c
==
--- src/truetype/ttgload.c (revision 2971)
+++ src/truetype/ttgload.c (local)
@@ -1801,9 +1801,6 @@
glyph->metrics.width = bbox.xMax - bbox.xMin;
glyph->metrics.height = bbox.yMax - bbox.yMin;
-if ( IS_HINTED( loader->load_flags ) )
- ft_glyphslot_grid_fit_metrics( glyph );
-
return 0;
}
=== src/type1/t1gload.c
==
--- src/type1/t1gload.c (revision 2971)
+++ src/type1/t1gload.c (local)
@@ -359,9 +359,6 @@
/* make up vertical ones */
metrics->vertBearingX = 0;
metrics
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sat, Dec 17, 2005 at 04:01:38PM -0800, George Williams wrote:
> Ok, here is an iterator.
>FT_GetIterate_BDF_Property(FT_Face,BDF_PropertyIteratorRec *aprop)
> To get the first property set,
>aprop->index = 0
> (each call will automagically increment)
>
> aprop->cnt will be set to the number of properties in the face
> aprop->name the name string
> aprop->property standard BDF_PropertyRec with the value.
I suggest the following APIs, making iterator merely an iterator:
/* to iterate... */
FT_Get_BDF_Iterator( face, &iter );
while ( FT_Iterare_BDF_Property( face, &iter, &name, &aprop ) )
{
/* do something; */
}
/* to get property count... */
FT_Get_BDF_Property_Count( face );
--
Regards,
olv
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft] Creating an [OT]TF font from BDF font
On Sun, Dec 18, 2005 at 02:07:50PM -0800, George Williams wrote: > On Sat, 2005-12-17 at 18:42, Chia-I Wu wrote: > > I suggest the following APIs, making iterator merely an iterator: > > > > /* to iterate... */ > > FT_Get_BDF_Iterator( face, &iter ); > > while ( FT_Iterare_BDF_Property( face, &iter, &name, &aprop ) ) > > FT_Get_BDF_Property_Count( face ); > > How about: > FT_Get_BDF_PropertyCount(face) Good to me. I was thinking about charmap iteration yesterday and I suggested taking property count out of bdf iterator because charmap iterator cannot know the char count. BTW, if you look into FT_Face, you'll find that `size_list' is an FT_List, `glyph' is a custom list, and `charmaps' is a dynamic array, while they all do the same thing :-) > FT_Iterate_BDF_Property(face,void *,BDF_IteratorFunc) > Calls the iterator function once with each property. > + typedef FT_Error > + (*BDF_IteratorFunc)( FT_Face face, > +void * data, > +const char* prop_name, > +const BDF_PropertyRec* aproperty); s/Iterat(e|or)/ForEach/... well, I must be affected by gtk+ :-) > FT_Get_BDF_Fontname(face) > FT_Get_BDF_Comments(face) Couldn't they just be treated like normal properties? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
On Fri, Dec 09, 2005 at 09:30:27AM +0800, Chia-I Wu wrote:
> To remedy this, the definition of FT_Set_Pixel_Sizes is changed to set
> the real height, not the nominal height. BDF/PCF drivers are also
> updated to reflect this change.
>
> As you can see, the problem is that other drivers are not updated. The
> scaling I mentioned in my another mail should be used for scalable font
> drivers. Sbit needs update too.
Ok, back on this issue :)
Since FT_Set_Pixel_Sizes might set the nominal size or the real
dimension in a unpredictable way, this is the first thing to fix. I
chose to make it always set the nominal size.
This effectively undo one of the changes between 2.1.9 and 2.1.10, which
says:
- The method how BDF and PCF bitmap fonts are accessed has been
refined. Formerly, FT_Set_Pixel_Sizes and FT_Set_Char_Size
were synonyms in FreeType's BDF and PCF interface. This has
changed now. FT_Set_Pixel_Sizes should be used to select the
actual font dimensions (the `strike', which is the sum of the
`FONT_ASCENT'and`FONT_DESCENT'properties), while
FT_Set_Char_Size selects the `nominal' size (the `PIXELSIZE'
property). In both functions, the width parameter is ignored.
Then what if the user wants to set the real dimension? To meet this
need, I changed the driver interface and combined the `set_char_sizes'
and `set_pixel_sizes' to `request_size', which takes FT_Size_RequestRec
as its argument, which is prototyped by
typedef struct FT_Size_RequestRec_
{
FT_Size_Request_Type type;
FT_F26Dot6width;
FT_F26Dot6height;
FT_UInt horiResolution;
FT_UInt vertResolution;
} FT_Size_RequestRec, *FT_Size_Request;
The field `type' can be NOMINAL, REAL_DIMENSION, or more.
Further, I added `select_size' to the driver interface, which selects a
fixed size by its index in available_sizes. If you imagine how clients
choose a fixed size from the available ones, you will find it useful.
In spite of this, `request_size' still looks into avaiable sizes and
selects one of them if it matches the request, as we had always done.
You can find the detail from the attached file, which is a diff of the
headers. If everyone agrees on these changes, I'll commit them.
--
Regards,
olv
=== include/freetype/freetype.h
==
--- include/freetype/freetype.h (/freetype2/trunk) (revision 3035)
+++ include/freetype/freetype.h (/freetype2/branches/size_selection)(local)
@@ -147,6 +147,7 @@
/*FT_Attach_File */
/*FT_Attach_Stream */
/* */
+ /*FT_Select_Size */
/*FT_Set_Char_Size */
/*FT_Set_Pixel_Sizes */
/*FT_Set_Transform */
@@ -293,10 +294,10 @@
/*where `size' is in points. */
/* */
/*Windows FNT: */
- /* The `size' parameter is not reliable: There exist fonts (e.g., */
- /* app850.fon) which have a wrong size for some subfonts; x_ppem*/
- /* and y_ppem are thus set equal to pixel width and height given in */
- /* in the Windows FNT header. */
+ /* The nominal size given in a FNT font is not reliable. Thus when */
+ /* it is obviously incorrect, we set `size' to some calculated */
+ /* values and set `x_ppem' and `y_ppem' to pixel width and height */
+ /* given in the font, respectively. */
/* */
/*TrueType embedded bitmaps: */
/* `size', `width', and `height' values are not contained in the*/
@@ -2071,16 +2072,40 @@
/*/
/* */
/* */
+ /*FT_Select_Size */
+ /*
Re: [ft-devel] BDF and FT_Set_Pixel_Sizes
Hi all, I've commited the patch. It's much larger than I thought. diffstat says, "31 files changed, 801 insertions(+), 838 deletions(-)." :-) The patch became so large partly becaue I moved "sbit metrics loading" code to the sfnt module, which is now shared by cff and truetype modules. This changed the interface of SFNT_Interface and I hope it's ok. Please test, especially for cff and truetype fonts. > PS: It would be nice if you could provide some problematic cases which > demonstrate the problems with the old solution. This might be > then added to the documentation, explaining why those > (incompatible) changes have to be done. I'll add back the selection of size through real dimensions for bdf/pcf fonts and mention the changes in the docs/CHANGES tomorrow. Too tired now :( -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] AFM parser and track kerning support
Hi all, I've committed a patch to have a full AFM parser. As a result, track kerning is supported. The track kerning can be retrieved by a call to `FT_Get_Track_Kerning'. And internally, it is implemented through a service called `kerning'. If you think the name or prototype is really bad and you've came up with a good one, please let me know. `ftstring' is also patched to support track kerning. All you need to do is name the AFM file after the font file and put them in the same directory. Then the AFM file will be loaded automatically. Further, a new display mode called `kerning comparision' is added. I guess this screenshot can explain what it is: http://www.olv.idv.tw/~olvaffe/tmp/freetype2/kerning.png Besides testing AFM support, please also check whether your favorite Type 1 fonts still work. BTW, does the PFM support work? I tried with some PFM files from ghostscript and all failed to load. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] when does the next version of freetype release?
On Tue, Jan 17, 2006 at 06:22:45PM +0100, Werner LEMBERG wrote: > > I want to know when does the next version (ver 2.2.0?) > > of freetype release? > Hopefully within a month or so. Will it be released with FT_OPTIMIZE_MEMORY defined? And will the major .so version be bumpped up? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] when does the next version of freetype release?
Hi David,
After defining FT_OPTIMIZE_MEMORY, trutype sbits (bit-aligned) stop to
work. I found the glyph size checking in
`tt_sbit_decoder_load_bit_aligned' is not done right. Fixing that makes
glyphs load, but the loaded bitmaps are still not right.
--
Regards,
olv
=== src/sfnt/ttsbit0.c
==
--- src/sfnt/ttsbit0.c (revision 3141)
+++ src/sfnt/ttsbit0.c (local)
@@ -582,7 +582,7 @@
goto Exit;
}
-if ( p + ( ( width + 7 ) >> 3 ) * height > limit )
+if ( p + ( ( ( width * height ) + 7 ) >> 3 ) > limit )
{
error = SFNT_Err_Invalid_File_Format;
goto Exit;
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)
Hi, This is not related to the discussion but related to freetype internal. On Mon, Jan 23, 2006 at 11:20:41AM +0100, david turner wrote: > src/type1/t1objs.c (403): > root->bbox.xMin = type1->font_bbox.xMin >> 16; > root->bbox.yMin = type1->font_bbox.yMin >> 16; > root->bbox.xMax = ( type1->font_bbox.xMax + 0xU ) >> 16; > root->bbox.yMax = ( type1->font_bbox.yMax + 0xU ) >> 16; It looks to me that type1->font_matrix and type1->font_offset should be applied to type1->font_bbox to get root->bbox, since glyphs are always transformed by the driver on loading. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)
On Fri, Jan 27, 2006 at 06:14:48AM +0100, Werner LEMBERG wrote: > > > src/type1/t1objs.c (403): > > > root->bbox.xMin = type1->font_bbox.xMin >> 16; > > > root->bbox.yMin = type1->font_bbox.yMin >> 16; > > > root->bbox.xMax = ( type1->font_bbox.xMax + 0xU ) >> 16; > > > root->bbox.yMax = ( type1->font_bbox.yMax + 0xU ) >> 16; > > > > It looks to me that type1->font_matrix and type1->font_offset should > > be applied to type1->font_bbox to get root->bbox, since glyphs are > > always transformed by the driver on loading. > Can you verify or falsify this, please? The values given in the PFB are raw. They should be transformed for use in face->bbox. Yet direct application of the transformations to the FontBBox is wrong. The transformations should be applied to each glyph's bbox and the FontBBox should be recalculated. As this is not affordable, maybe we should document this and provide some means for access to FontMatrix. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] when does the next version of freetype release?
On Fri, Jan 27, 2006 at 06:35:50AM +0100, Werner LEMBERG wrote: > > After defining FT_OPTIMIZE_MEMORY, trutype sbits (bit-aligned) stop > > to work. I found the glyph size checking in > > `tt_sbit_decoder_load_bit_aligned' is not done right. Fixing that > > makes glyphs load, but the loaded bitmaps are still not right. > I've seen that you've committed a lot of changes -- is this problem > gone now? Nope :-) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox)
On Fri, Jan 27, 2006 at 03:19:02PM +0800, Chia-I Wu wrote: > The values given in the PFB are raw. They should be transformed for use > in face->bbox. Yet direct application of the transformations to the > FontBBox is wrong. The transformations should be applied to each > glyph's bbox and the FontBBox should be recalculated. > > As this is not affordable, maybe we should document this and provide > some means for access to FontMatrix. Or, the transformed values are available from an AFM too. We can make use of it. There are also some other interested fields like `Ascender' and `Descender' which I would like to add support to. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] autofit CJK module
Hi all, I've just committed autofit CJK module. It is based on akito's autohint patch. Here's some screenshots... with hinting disabled (some people might like this best): http://homepage.ntu.edu.tw/~b88401031/ming-no-hint.png with normal hinting: http://homepage.ntu.edu.tw/~b88401031/ming-normal.png with light hinting: http://homepage.ntu.edu.tw/~b88401031/ming-light.png with CJK module disabled: http://homepage.ntu.edu.tw/~b88401031/ming-latin.png The CJK module is currently in experimental stage and is disabled by default. If you are interested in helping or want to have a try on it, it can enabled by #define AF_MOD_CJK in src/autofit/afcjk.c. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] autofit CJK module
On Fri, Feb 10, 2006 at 03:46:27PM +0100, Werner LEMBERG wrote: > > The CJK module is currently in experimental stage and is disabled by > > default. If you are interested in helping or want to have a try on > > it, it can enabled by #define AF_MOD_CJK in src/autofit/afcjk.c. > Please move AF_MOD_CJK to ftoption.h and enable it by default. This > makes it easier to test. > > BTW, I see code like this in the new module: > > FT_Pos threshold = 50 * metrics->units_per_em / 2048; > > Where does the `2048' come from? Please add a comment. I wanted to ask about this on the list but I forgot :( The thresholds here and in segment linking are in font units. They should be proportional to units_per_em. As they work great for fonts with 2048 units, I assume they are decided with 2048 units in mind. If this is not the case, please replace 2048 with an appropriate value. I did the same to the latin module. All Type 1 fonts would be affected. (And I just found that the 3000 in the scoring formula should be scaled too.) -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] How can I do to make the font a little thin?
Hi, On Mon, Feb 13, 2006 at 09:09:44AM +0800, DingLi(丁力) wrote: > I use simsun.ttf(宋體)，the upper is the image which use FreeType 2.0.9,and the > lower is which I want to get. You can pass a negative strength value to the FT_Outline_Embolden. This function is only available from freetype 2.1.10 on. If upgrading freetype is not a choice, you can copy the code to your application. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] internal differences between 2.1.10 and current CVS
Hi David,
I've cooked a quick patch to make fc-cache work again. I'll comment in
the next mail.
--
Regards,
olv
=== include/freetype/config/ftoption.h
==
--- include/freetype/config/ftoption.h (revision 3230)
+++ include/freetype/config/ftoption.h (local)
@@ -591,6 +591,7 @@
#define FT_STRICT_ALIASING
*/
+#define FT_CONFIG_OPTION_OLD_INTERNALS
FT_END_HEADER
=== include/freetype/internal/ftobjs.h
==
--- include/freetype/internal/ftobjs.h (revision 3230)
+++ include/freetype/internal/ftobjs.h (local)
@@ -175,18 +175,6 @@
/*FreeType. */
/* */
/* */
- /*max_points :: */
- /* The maximal number of points used to store the vectorial outline */
- /* of any glyph in this face. If this value cannot be known in */
- /* advance, or if the face isn't scalable, this should be set to 0. */
- /* Only relevant for scalable formats. */
- /* */
- /*max_contours ::*/
- /* The maximal number of contours used to store the vectorial */
- /* outline of any glyph in this face. If this value cannot be */
- /* known in advance, or if the face isn't scalable, this should be */
- /* set to 0. Only relevant for scalable formats. */
- /* */
/*transform_matrix ::*/
/* A 2x2 matrix of 16.16 coefficients used to transform glyph */
/* outlines after they are loaded from the font. Only used by the */
@@ -213,6 +201,11 @@
/* */
typedef struct FT_Face_InternalRec_
{
+#ifdef FT_CONFIG_OPTION_OLD_INTERNALS
+FT_UShort reserved1;
+FT_Shortreserved2;
+#endif
+
FT_Matrix transform_matrix;
FT_Vector transform_delta;
FT_Int transform_flags;
=== include/freetype/internal/psaux.h
==
--- include/freetype/internal/psaux.h (revision 3230)
+++ include/freetype/internal/psaux.h (local)
@@ -784,7 +784,6 @@
const PS_Parser_FuncsRec* ps_parser_funcs;
const T1_Builder_FuncsRec* t1_builder_funcs;
const T1_Decoder_FuncsRec* t1_decoder_funcs;
-const AFM_Parser_FuncsRec* afm_parser_funcs;
void
(*t1_decrypt)( FT_Byte* buffer,
@@ -793,6 +792,8 @@
T1_CMap_Classes t1_cmap_classes;
+const AFM_Parser_FuncsRec* afm_parser_funcs;
+
} PSAux_ServiceRec, *PSAux_Service;
/* backwards-compatible type definition */
=== include/freetype/internal/sfnt.h
==
--- include/freetype/internal/sfnt.h(revision 3230)
+++ include/freetype/internal/sfnt.h(local)
@@ -510,9 +510,9 @@
/* these functions are called by `load_face' but they can also */
/* be called from external modules, if there is a need to do so */
+TT_Load_Metrics_Func load_hmtx;
TT_Load_Table_Func load_head;
TT_Load_Metrics_Func load_hhea;
-TT_Load_Metrics_Func load_hmtx;
TT_Load_Table_Func load_cmap;
TT_Load_Table_Func load_maxp;
TT_Load_Table_Func load_os2;
@@ -529,24 +529,24 @@
TT_Load_Table_Func load_bhed;
/* see `ttsbit.h' */
-TT_Load_Table_Func load_eblc;
-TT_Free_Table_Func free_eblc;
TT_Set_SBit_Strike_Func set_sbit_strike;
-TT_Load_Strike_Metrics_Func load_strike_metrics;
+TT_Load_Table_Func load_eblc;
TT_Find_SBit_Image_Func find_sbit_image;
TT_Load_SBit_Metrics_Funcload_sbit_metrics;
TT_Load_SBit_Image_Func load_sbit_image;
+TT_Free_Table_Func free_eblc;
/* see `ttkern.h' */
TT_Face_GetKerningFunc get_kerning;
-TT_Get_Metrics_Func get_metrics;
-
/* see `ttpost.h' */
TT_Get_PS_Name_Func get_psname;
TT_Free_Table_Func free_psnames;
+TT_Get_Metrics_Func get_metrics;
+TT_Load_Strike_Metrics_Func load_strike_metrics;
+
} SFNT_Interface;
=== include/freetype/internal/tttypes.h
==
--- include/freetype/internal/tttypes.h (revision 3230)
+++ include/freetype/internal/tttypes.h (local)
@@ -311,8 +311,6
Re: [ft-devel] internal differences between 2.1.10 and current CVS
On Wed, Feb 15, 2006 at 02:31:16PM +0100, david turner wrote: > internal/ftdriver.h: > FT_Size_ResetPointsFunc and FT_Size_ResetPixelsFunc are replaced > by FT_Size_RequestFunc and FT_Size_SelectFunc, which have different > signatures and usage. This impacts some fields in FT_Driver_ClassRec, > namely: > >'set_char_sizes' => 'request_size' >'set_pixel_sizes' => 'select_size' > > the layout of other fields is untouched The chance that rogue clients use them is low. I suggest not fixing this. > internal/ftobjs.h: > two new fields at the start of FT_Face_InternalRec, named > 'max_points' and 'max_contours' They are removed by me yesterday. I've added them back and renamed them to `reserved1' and `reserved2'. > > FT_New_Memory was FT_EXPORT and is now FT_BASE, i.e. no longer > exported > > same for FT_Done_Memory ! > > internal/ftstream.h: > FT_Stream_Open was FT_EXPORT and is now FT_BASE > They were labeled wrongly. No special care needed. > internal/psaux.h: > PSAux_ServiceRec has a new field added in its middle, named > 'afm_parser_funcs'. > > obvious solution: move it to the end of the structure Done. > internal/sfnt.h: > **VERY BAD** > > changes here have been extremely drastic, more details will follow > but we need to be very careful. The types defined here are *very* > likely to be used by rogue clients > > **MORE DETAILS LATER** After re-ordering the members of SFNT_Interface, the problems are restricted to: 1) load_sfnt_header => tt_face_load_font_dir load_directory => tt_face_load_hmtx load_metrics => tt_face_load_hhea Functional-wise, the first two functions on the left are equal to the first function on the right. The third function on the left is equal to the last two functions on the right. I've cooked a patch for a possible solution. With it, freetype should never crash. Depending on how rogue clients call the functions, they are mostly like to get zero width and zero advance later in `get_metrics' when FT_OPTIMIZE_MEMORY is defined, or get error in `tt_face_load_hmtx' when not. (if we let `tt_face_load_hhea' call `tt_face_load_hmtx', everything will work as well as before, but I don't like it :-) 2) set_sbit_strike changed. the second parameter was x_ppem and is a size request (a pointer). If there is a reliable way to distinguish a interger and a pointer, say, rogue clients never call `set_sbit_strike' with x_ppem >= 0x1000 and a pointer always points to somewhere >= 0x1000, we can tell who is calling this function and return error when the rogue clients call it. > internal/tttypes.h: > a new field named 'max_components' was added in the middle of > TT_FaceRec => move it to the end of the structure It was removed by me yesterday. I've added it back and renamed it to `reserved'. > when FT_OPTIMIZE_MEMORY is defined, this adds new fields within > the structure => move them to the end as well > > same for TT_CONFIG_OPTION_BDF and 'bdf' field Done. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] internal differences between 2.1.10 and current CVS
Hi,
Sorry, I forgot to attach the patch I mentioned in the second mail.
--
Regards,
olv
=== src/sfnt/ttmtx.c
==
--- src/sfnt/ttmtx.c(revision 3231)
+++ src/sfnt/ttmtx.c(local)
@@ -85,6 +85,9 @@
ptable_size = &face->horz_metrics_size;
}
+if ( *ptable )
+ return SFNT_Err_Ok;
+
if ( FT_FRAME_EXTRACT( table_size, *ptable ) )
goto Fail;
@@ -142,6 +145,9 @@
shorts = (TT_ShortMetrics**)&face->horizontal.short_metrics;
}
+if ( num_longs == 0 )
+ return SFNT_Err_Invalid_Table;
+
/* never trust derived values */
num_shorts = face->max_profile.numGlyphs - num_longs;
@@ -352,6 +358,9 @@
limit = p + face->horz_metrics_size;
}
+if ( !p )
+ goto NoData;
+
k = header->number_Of_HMetrics;
if ( k > 0 )
=== src/sfnt/ttsbit.c
==
--- src/sfnt/ttsbit.c (revision 3231)
+++ src/sfnt/ttsbit.c (local)
@@ -640,6 +640,11 @@
FT_Size_Request req,
FT_ULong*astrike_index )
{
+#ifdef FT_CONFIG_OPTION_OLD_INTERNALS
+if ( (FT_UInt)req < 0x1000 )
+ return FT_Err_Invalid_Pixel_Size;
+#endif
+
return FT_Match_Size( (FT_Face)face, req, 0, astrike_index );
}
=== src/sfnt/ttsbit0.c
==
--- src/sfnt/ttsbit0.c (revision 3231)
+++ src/sfnt/ttsbit0.c (local)
@@ -170,6 +170,11 @@
FT_Size_Request req,
FT_ULong*astrike_index )
{
+#ifdef FT_CONFIG_OPTION_OLD_INTERNALS
+if ( (FT_UInt)req < 0x1000 )
+return FT_Err_Invalid_Pixel_Size;
+#endif
+
return FT_Match_Size( (FT_Face)face, req, 0, astrike_index );
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] BUG-REPORT: Verdana 10px regular and character '7'
Hi, On Fri, Feb 17, 2006 at 02:08:47PM +0100, lefti wrote: > Hi, > There is bug in freetype: look at > http://mbox.troja.mff.cuni.cz/~peak/ftdemo/index.cgi and set hinting > :on, antialiasing:off,font:verdana.ttf,size:10 and text to 0123456789 or > something else what containts character 7 and look at "7". The downest > pixel is missing. There is no such problem with freetype 2.1.10. The CGI uses `ftstrpnm' to render the string, which is part of freetype1. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog builds/amiga/src/base/fts...
On Sun, Feb 19, 2006 at 05:26:14PM +0100, Werner LEMBERG wrote: > > When FT_OPTIMIZE_MEMORY is defined, `long_metrics' is always NULL > > while `number_Of_HMetrics' is usually non-zero. This crashes > > libXfont and thus xorg. > > > > The only fix I come up with is always set > > face->horizontal.number_Of_HMetrics to zero, add > > `number_Of_HMetrics' to the end of `TT_FaceRec' and use it when > > FT_OPTIMIZE_MEMORY is defined. `vhea' should be handled similarly. > This sounds good. Please provide a patch. Although this prevents crashes, the multi-byte glyphs are no more shown, i.e. libXft malfuctions. There is another problem. libXfont uses sfnt->find_sbit_image and sfnt->load_sbit_metrics, which are now moved to the end of SFNT_Interface. Therefore, another two functions would be called and the behavior may be unpredictable. For a distribution maintainer, if upgrading freetype would render some package broken (crash or malfunction), it is definitely unacceptable. As a result, freetype can be upgraded only after the package is patched and recompiled. In this point of view, we don't need to pay special attention to the internal ABI compatibility. Things are solved in the package managing level. Meanwhile, we can still make binaries under /usr/local happier by, say, keeping those APIs which can be easily kept or which are known to be used by some rogue client. If having the degree of intenal ABI compatibility we have now in the CVS can make _all_ clients happy, despite the code is ugly, it's worth it. But we already know that this is not true. Any comment? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog builds/amiga/src/base/fts...
On Mon, Feb 20, 2006 at 12:21:33AM +0100, David Turner wrote: > ok, apparently, the 'find_sbit_image' and 'load_sbit_metrics' fields > were added in the middle > of the SFNT_Service structure in FreeType 2.1.8. They've been moved to > the end of the structure > because we want to target the internals of 2.1.7. > > *However*, I'm ready to make a special exception for this specific case, > i.e. re-move the fields > to their 2.1.8 location. That's because it is _very_ unlikely that > another rogue client might be > interested by the fields that are replaced/moved by this operation. > > this would allow a safe install with an xorg-xserver. > > If you agree, I'll do the change myself, with a meaningful comment to > explain the exception. To me, `sfnt_interface' in sfdirver.c is made way too horrible only to have certain degree of ABI compatibility with the target release, i.e. 2.1.7. This does not help distribution maintainers at all. If we do not target any previous release, but instead, try to please certain rogue clients, things can be much easier. In fact, we are now making exceptions for them, don't we? Anyway, this is just my thought. If we are targeting 2.1.7, exceptions do have to be made. Please go ahead. As for the issue I mentioned in the first mail, memory optimization for the hmtx table should be disabled then. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Some black and white dot
Hi, On Mon, Feb 20, 2006 at 04:20:14PM +0800, DingLi(丁力) wrote: > Why these phenomenons appear? Is the font MINGLIU.TTC? Which version of freetype and which pixel size do you use? I tried with MINGLIU.TTC and there is no such problem (freetype 2.1.10 and CVS). But the strokes are thiner than yours. To test if it's a bug of freetype, you can use ftview, by $ ftview -e unic -f 23478 MINGLIU.TTC -- Regards, olv home.png Description: PNG image ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: [bug #15785] character "7" in verdana regular 10px with hinting without antialiasing is bad rendered.
Hi,
On Sun, Feb 19, 2006 at 11:29:23PM +0100, Rogier van Dalen wrote:
> This indicates that the TrueType rasteriser is right. The Windows
> rasteriser might have a rounding error in the interpreter or in the
> actual rasteriser. I didn't look into it very deeply though.
> Hope this helps!
I've coded a program to dump the hinted glyph outline on windows. I
don't know if it works correctly (my first win32 app!), but the outline
dumped is exactly the same as what we get from freetype.
--
Regards,
olv
#include
#include
#include
#include
void dump_ttpolygon(unsigned char *buf)
{
LPTTPOLYGONHEADER header = (void*)buf;
int buf_size = header->cb;
printf("pfxStart %f %f\n",
header->pfxStart.x.value + header->pfxStart.x.fract / 65536.,
header->pfxStart.y.value + header->pfxStart.y.fract / 65536.);
buf += sizeof(*header);
buf_size -= sizeof(*header);
while (buf_size > 0)
{
LPTTPOLYCURVE curve = (void*)buf;
int curve_size;
int i;
curve_size = 2 * sizeof(WORD) + curve->cpfx * sizeof(POINTFX);
if (curve_size > buf_size)
{
printf("curve too large\n");
return;
}
printf("(%s)\n", (curve->wType == TT_PRIM_LINE)
? "polyline" : "spline");
for (i = 0; i < curve->cpfx; i++)
{
LPPOINTFX pt = curve->apfx + i;
printf("%f %f\n",
pt->x.value + pt->x.fract / 65536.,
pt->y.value + pt->y.fract / 65536.);
}
buf_size -= curve_size;
buf += curve_size;
}
}
int print_glyph_metrics(char ch)
{
LOGFONT lf;
HFONT font;
HDC dc;
unsigned char *buf;
DWORD buf_size;
TEXTMETRIC tm;
GLYPHMETRICS gm;
MAT2 mat;
UINT format = GGO_NATIVE;
//format |= GGO_UNHINTED;
memset(&lf, 0, sizeof(lf));
lf.lfHeight = -13;
strcpy(lf.lfFaceName, "Verdana");
font = CreateFontIndirect(&lf);
if (!font)
return 0;
dc = GetDC(NULL);
SelectObject(dc, font);
memset(&gm, 0, sizeof(gm));
memset(&mat, 0, sizeof(mat));
mat.eM11.value = 1;
mat.eM22.value = 1;
buf_size = GetGlyphOutline(dc, ch, format, &gm, 0, NULL, &mat);
buf = malloc(buf_size);
GetTextFace(dc, buf_size, buf);
printf("Face %s\n", buf);
if (GetGlyphOutline(dc, ch, format, &gm, buf_size, buf, &mat) != GDI_ERROR) {
int i = 0;
while (buf_size > 0 )
{
LPTTPOLYGONHEADER ttpoly = (LPTTPOLYGONHEADER)buf;
if (ttpoly->cb > buf_size)
{
printf("ttpoly too large\n");
return 0;
}
printf("Contour %d\n", i++);
dump_ttpolygon((void*)ttpoly);
printf("\n");
buf += ttpoly->cb;
buf_size -= ttpoly->cb;
}
}
ReleaseDC(NULL, dc);
DeleteObject(font);
return 1;
}
int main()
{
print_glyph_metrics('7');
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Outline dumper for windows
On Wed, Feb 22, 2006 at 08:46:12AM +0100, Werner LEMBERG wrote: > Very good that you've written that! I've asked for such a program > years ago. BTW, perhaps you find a better name for this smal > program... On my box, I name it `a.c' :-) > Using FontForge to single-step through the bytecode instructions! > This makes great fun (and drives George crazy because of my many bug > reports and feature suggestions). I tried to debug the `7' of verdana with fontforge's bytecode debugger and verify every calculation by hand. It was fun until I met SDPVTL... -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftview peculiarity
On Sun, Feb 26, 2006 at 06:49:23PM +0100, Werner LEMBERG wrote: > please fix ftview so that it doesn't emit a message for each loaded > font if the AFM file is missing -- it does that currently for fonts in > any format... That happens only when freetype is compiled in debug mode (FT_DEBUG_LEVEL_ERROR defined). I'll make it try to attach the .afm only when opening .pfa or .pfb. Is this enough? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Third Release candidate for FT 2.2 available
Hi, On Sun, Feb 26, 2006 at 05:22:48PM +0100, David Somers wrote: > RC3 seems to work on my Gentoo/Linux system... although I now seem to have > problems with the edges of some glyphs being clipped on fixed-width fonts. This should be fixed in the CVS. It's due to metrics rounding which has been re-enabled. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] hinting regression in 2.2.1?
Hi, On Sat, May 20, 2006 at 04:41:03PM -0400, Izaak Branderhorst wrote: > I've attached two screenshots which illustrate a difference in rendering > Arial at 11px bold. > > My configuration doesn't change between running 2.1.10 and 2.2.1. The only > thing I've found that fixes the problem is reducing hinting from full to > medium. freetype 2.1.10 has a bug in determining whether it's doing horizontal or vertical hinting, which prevents stem snapping in some cases: 2005-09-26 David Turner <[EMAIL PROTECTED]> * src/autofit/aflatin.c (af_latin_compute_stem_width): Fix bad computation of the `vertical' flag, causing ugly things in LCD mode and others. But in this case, bypassing stem snapping gives better result. Maybe we can adjust the algorithm so that font styles are taken into consideration when snapping? -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] suggested improvement to FT_GlyphSlot_Embolden
On Thu, Jul 26, 2007 at 11:50:14PM +0200, Werner LEMBERG wrote: > > If we can't change the existing function then I agree that a new one > > is a good idea, but I would prefer FT_GlyphSlot_Embolden_By_Weight > > or something like that to give an idea of the meaning of the new > > parameter. FT_GlyphSlot_Embolden exists only for historial reasons, and is a wrapper to FT_Bitmap_Embolen and FT_Outline_Embolden. One can copy the code and modify it to suit his/her need. If new APIs are to be added, I would prefer to have FT_Glyph_Embolden and FT_Glyph_Oblique. Glyph transformations should be done to FT_Glyph, not to FT_GlyphSlot. -- Regards, olv ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
