Re: [ft] Bad emulation of boldness.
On Tue, Oct 10, 2006 at 02:10:08PM +0200, Daniel M. wrote: Is it possible somehow to improve the situation? The problem might be that the glyph drawing backend calls a convenient function provided by freetype to embolden the glyphs, which lacks parameters to control how embolden is done. Enabling antialias should help: http://people.debian.org.tw/~olv/freetype/monaco-lin-10pt.png Another solution is to convert the font to a bitmap one for the pixel size used. The convenient function uses different algorithm to embolden bitmap glyphs, which is similar to what Windows does. -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] Bad emulation of boldness.
On Wed, Oct 11, 2006 at 12:39:02AM +0200, Werner LEMBERG wrote: though it is possible that I missed something while reading a map page, going to take a better look at it later. In any case, the best option is to make an original .ttf look good. I suggest to use FontForge to do what you want. This can be controlled with scripts also. FontForge seems to ignore the hints in the font. I use gbdfed instead to generate the bitmaps. That is, use gbdfed to generate a bdf font (10pt at 96 dpi). Then use FontForge to open the original Monaco.ttf, import this bdf font, and generate a bitmap-embedded TrueType font. The result is: http://people.debian.org.tw/~olv/freetype/monaco-lin-13px_bitmap.png -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] bold problem with some fonts
On Wed, Oct 04, 2006 at 07:22:18AM +0200, Werner LEMBERG wrote: Now I have a question about problem in bold rendering with some font, for example VLGothic font (http://dicey.org/vlgothic/). Attached is a font file which contains just the zero glyph of this font. This is another issue than what I originally thought. The outer most contour has only off-line points and is thus ignored when trying to identify the orientation of the glyph. This change was introduced here: http://lists.gnu.org/archive/html/freetype-devel/2006-03/msg00027.html I'll see if I can find the fonts mentioned there to test. This mail is also forwarded to Zhe Su. -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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
[ft-cvs] ft2demos ./ChangeLog src/ftcommon.c
CVSROOT:/cvsroot/freetype Module name:ft2demos Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/03/02 09:05:12 Modified files: . : ChangeLog src: ftcommon.c Log message: * src/ftcommon.c (string_render_prepare): Fix a possible crash. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/ft2demos/ChangeLog.diff?tr1=1.148tr2=1.149r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/ft2demos/src/ftcommon.c.diff?tr1=1.10tr2=1.11r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog src/base/ftobjs.c
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/27 11:11:40 Modified files: . : ChangeLog src/base : ftobjs.c Log message: * src/base/ftobjs.c (FT_Set_Char_Size): Ahh.. forgot to check the case width or height is 0. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1256tr2=1.1257r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftobjs.c.diff?tr1=1.246tr2=1.247r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog src/autofit/afloader.c sr...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/27 09:18:07 Modified files: . : ChangeLog src/autofit: afloader.c src/base : ftobjs.c Log message: * src/base/ftobjs.c (ft_glyphslot_grid_fit_metrics, FT_Load_Glyph): Re-enable glyph metrics grid-fitting. It is now done in the base layer. (FT_Set_Char_Size, FT_Set_Pixel_Sizes): Make sure the width and height are not too small or too large, just like we were doing in 2.1.10. * src/autofit/afloader.c (af_loader_load_g): The vertical metrics are not scaled. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1254tr2=1.1255r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/autofit/afloader.c.diff?tr1=1.21tr2=1.22r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftobjs.c.diff?tr1=1.245tr2=1.246r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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
[ft-cvs] freetype2 ./ChangeLog include/freetype/freetype...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/24 06:11:30 Modified files: . : ChangeLog include/freetype: freetype.h src/base : ftobjs.c Log message: * include/freetype/freetype.h (FT_Size_RequestRec): Change the type of `width' and `height' to `FT_Long'. (enum FT_Size_Request_Type), src/base/ftobjs.c (FT_Request_Metrics): New request type `FT_SIZE_REQUEST_TYPE_SCALES' to specify the scales directly. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1240tr2=1.1241r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/freetype.h.diff?tr1=1.180tr2=1.181r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftobjs.c.diff?tr1=1.242tr2=1.243r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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] 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 pixel_size 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
[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] 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
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. */
/* */
/* Fields */
- /*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
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
[ft-cvs] freetype2 ./ChangeLog src/sfnt/ttmtx.c
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/14 13:36:28 Modified files: . : ChangeLog src/sfnt : ttmtx.c Log message: * src/sfnt/ttmtx.c (tt_face_get_metrics): Typo. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1220tr2=1.1221r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.c.diff?tr1=1.4tr2=1.5r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog include/freetype/internal...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/14 06:40:10 Modified files: . : ChangeLog include/freetype/internal: fttrace.h sfnt.h src/cff: cffgload.c cffobjs.c src/sfnt : rules.mk sfdriver.c sfnt.c sfobjs.c ttload.c ttload.h ttsbit.c ttsbit.h ttsbit0.c src/truetype : ttgload.c ttobjs.c ttpload.c ttpload.h Added files: src/sfnt : ttmtx.c ttmtx.h Log message: Clean up the SFNT_Interface. Table loading functions are now named after the tables' tags; `hdmx' is TrueType-specific and thus the code is moved to the truetype module; `get_metrics' is moved here from the truetype module so that the code can be shared with the cff module. This pass involves no real changes. That is, the code is moved verbatim mostly. The only exception is the return value of `tt_face_get_metrics'. * include/freetype/internal/sfnt.h, src/sfnt/rules.mk, src/sfnt/sfdriver.c, src/sfnt/sfnt.c, src/sfnt/sfobjs.c, src/sfnt/ttload.c, src/sfnt/ttload.h, src/sfnt/ttsbit.c, src/sfnt/ttsbit.h, src/sfnt/ttsbit0.c: Clean up the SFNT_Interface. * src/sfnt/ttmtx.c, src/sfnt/ttmtx.h: Metrics-related tables' loading and parsing code is moved here. Move `tt_face_get_metrics' here from the truetype module. The return value is changed from `void' to `FT_Error'. * include/freetype/internal/fttrace.h: New trace: ttmtx. * src/truetype/ttpload.c, src/truetype/ttpload.h: `hdmx' loading and parsing code is moved here. New function `tt_face_load_prep' splitted from `tt_face_load_fpgm'. `tt_face_load_fpgm' returns `FT_Err_Ok' if `fpgm' doesn't exist. * src/cff/cffgload.c, src/cff/cffobjs.c: Update. * src/truetype/ttgload.c, src/truetype/ttobjs.c: Update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1215tr2=1.1216r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/internal/fttrace.h.diff?tr1=1.10tr2=1.11r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/internal/sfnt.h.diff?tr1=1.37tr2=1.38r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/cff/cffgload.c.diff?tr1=1.78tr2=1.79r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/cff/cffobjs.c.diff?tr1=1.78tr2=1.79r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/rules.mk.diff?tr1=1.25tr2=1.26r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfdriver.c.diff?tr1=1.81tr2=1.82r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfnt.c.diff?tr1=1.22tr2=1.23r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfobjs.c.diff?tr1=1.108tr2=1.109r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttload.c.diff?tr1=1.123tr2=1.124r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttload.h.diff?tr1=1.26tr2=1.27r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.c?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.h?rev=1.1 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttsbit.c.diff?tr1=1.67tr2=1.68r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttsbit.h.diff?tr1=1.29tr2=1.30r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttsbit0.c.diff?tr1=1.16tr2=1.17r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/truetype/ttgload.c.diff?tr1=1.160tr2=1.161r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/truetype/ttobjs.c.diff?tr1=1.97tr2=1.98r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/truetype/ttpload.c.diff?tr1=1.33tr2=1.34r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/truetype/ttpload.h.diff?tr1=1.16tr2=1.17r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog include/freetype/internal...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/14 07:01:29 Modified files: . : ChangeLog include/freetype/internal: sfnt.h src/sfnt : sfdriver.c sfobjs.c ttload.c ttload.h Log message: Clean up the SFNT_Interface. In this pass, we want to treat the font directory (offset table and table directory) as a normal table like the others. This also means that TTC is no longer recognized there, but in `init_face'. * include/freetype/internal/sfnt.h (SFNT_Interface), src/sfnt/sfdriver.c: `load_sfnt_header' and `load_directory' are combined and renamed to `load_font_dir'. * src/sfnt/ttload.h, src/sfnt/ttload.c: s/sfnt_dir_check/check_table_dir/. `sfnt_init' is moved to sfobjs.c and renamed to `sfnt_open_font'. `tt_face_load_sfnt_header' and `tt_face_load_directory' are combined and renamed to `tt_face_load_font_dir'. * src/sfnt/sfobjs.c (sfnt_init_face): Recognize TTC here. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1216tr2=1.1217r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/internal/sfnt.h.diff?tr1=1.38tr2=1.39r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfdriver.c.diff?tr1=1.82tr2=1.83r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfobjs.c.diff?tr1=1.109tr2=1.110r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttload.c.diff?tr1=1.124tr2=1.125r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttload.h.diff?tr1=1.27tr2=1.28r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog src/sfnt/ttmtx.c src/sfnt...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/14 07:20:06 Modified files: . : ChangeLog src/sfnt : ttmtx.c ttmtx.h Log message: * src/sfnt/ttmtx.h, src/sfnt/ttmtx.c: Why are there two copies of code... CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1217tr2=1.1218r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.c.diff?tr1=1.1tr2=1.2r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.h.diff?tr1=1.1tr2=1.2r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog include/freetype/internal...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/14 07:25:57 Modified files: . : ChangeLog include/freetype/internal: sfnt.h src/sfnt : sfdriver.c sfobjs.c ttmtx.c ttmtx.h Log message: Clean up the SFNT_Interface. In this final pass, `load_hmtx' is splitted from `load_hhea'. * include/freetype/internal/sfnt.h, src/sfnt/sfdriver.c, src/sfnt/ttmtx.c, src/sfnt/ttmtx.h: Split `hmtx' from `hhea'. * src/sfnt/sfobjs.c (sfnt_load_face): Update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1218tr2=1.1219r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/internal/sfnt.h.diff?tr1=1.39tr2=1.40r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfdriver.c.diff?tr1=1.83tr2=1.84r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/sfobjs.c.diff?tr1=1.110tr2=1.111r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.c.diff?tr1=1.2tr2=1.3r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttmtx.h.diff?tr1=1.2tr2=1.3r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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
[ft-cvs] freetype2 ./ChangeLog docs/CHANGES docs/TODO in...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/02/11 12:12:02 Modified files: . : ChangeLog docs : CHANGES TODO include/freetype/config: ftoption.h src/autofit: afcjk.c aflatin.c aflatin.h Log message: * include/freetype/config/ftoption.h (AF_CONFIG_OPTION_CJK): #define to enable autofit CJK script support. (#define'd by default) * src/autofit/aflatin.h (AF_LATIN_CONSTANT): New macro. * src/autofit/aflatin.c (af_latin_metrics_init_widths): Make sure that `edge_distance_threshold' is always set. (af_latin_hints_link_segments): Potential divide by 0 bug. Use latin constant in the scoring formula. * src/autofit/afcjk.c: Minor updates due to the above three changes. * docs/TODO, docs/CHANGES: Updated. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1212tr2=1.1213r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/docs/CHANGES.diff?tr1=1.136tr2=1.137r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/docs/TODO.diff?tr1=1.11tr2=1.12r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/config/ftoption.h.diff?tr1=1.99tr2=1.100r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/autofit/afcjk.c.diff?tr1=1.2tr2=1.3r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/autofit/aflatin.c.diff?tr1=1.28tr2=1.29r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/autofit/aflatin.h.diff?tr1=1.11tr2=1.12r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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
[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
[ft-cvs] freetype2 ./ChangeLog include/freetype/freetype...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 06/01/31 07:01:24 Modified files: . : ChangeLog include/freetype: freetype.h include/freetype/internal: t1types.h src/psaux : afmparse.c src/tools : test_afm.c src/type1 : t1afm.c Log message: * include/freetype/internal/t1types.h (AFM_FontInfo), src/psaux/afmparse.c, src/tools/test_afm.c: Read `FontBBox', `Ascender', and `Descender' from an AFM. * src/type1/t1afm.c (T1_Read_Metrics): Use the metrics from the AFM. * include/freetype/freetype.h (FT_FaceRec): Mention that fields may be changed after file attachment. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1199tr2=1.1200r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/freetype.h.diff?tr1=1.178tr2=1.179r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/include/freetype/internal/t1types.h.diff?tr1=1.41tr2=1.42r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/psaux/afmparse.c.diff?tr1=1.5tr2=1.6r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/tools/test_afm.c.diff?tr1=1.2tr2=1.3r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/type1/t1afm.c.diff?tr1=1.47tr2=1.48r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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] 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] 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] FT_New_Memory_Face and .ttc
On Tue, Jan 17, 2006 at 07:40:54PM +1100, Michael Day wrote: N := num. of tables Min:= min(offset of tables) Offset := Min - (12 + 16 * N). I don't quite follow this -- is the number of tables the number of tables in the individual font face? Given that GetFontData returns only the data for a single font face, how can this find the offset to subtract? I was wrong. I thought that a TTC has the layout like: [TTC Header][Offset Table + Data 1][Offset Table + Data 2]... Anyway, so when GetFontData are called with both the `table' and `offset' parameters set to 0, it won't read the data from the beginning of the file? -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
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] Creating an [OT]TF font from BDF font
Hi,
Juliusz wrote fonttosfnt which combines multiple BDF sizes into a single
SFNT. It's in CVS at freedesktop.org in the xapps module
I tried fonttosfnt some weeeks ago and found that it uses
FT_Bitmap_Size-{height,width} for ppemY and ppemX. Shouldn't it be
ppemX = ppemY = FT_Bitmap_Size-y_ppem?
The reason that ppemX should be equal to ppemY is that an em-sqaure with
unequal ppems means x and y axes are scaled differently so that the
glyphs would look stretched.
--
Regards,
olv
___
Freetype mailing list
Freetype@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype
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 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
[ft-cvs] ft2demos ./ChangeLog src/ftbench.c
CVSROOT:/cvsroot/freetype Module name:ft2demos Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 05/12/04 02:39:31 Modified files: . : ChangeLog src: ftbench.c Log message: * src/ftbench.c: Formatting. Make `face' and `charset' local variables. (btest_t): Use `const' qualifier for `title'. (bcharset_t): Change the type of `size' to `FT_Int'. (face_requester, benchmark): Updated because `face' is no longer global. (test_get_char_index, test_cmap_cache, get_charset): Updated because `charset' is no longer global. (main): New variables, `face' and `charset'. Updated because `face' and `charset' are local now. `get_charset' only when perform FT_BENCH_CMAP. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/ft2demos/ChangeLog.diff?tr1=1.136tr2=1.137r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/ft2demos/src/ftbench.c.diff?tr1=1.22tr2=1.23r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-devel] BDF and FT_Set_Pixel_Sizes
Hi,
According to the document,
quote
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.
/quote
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
[ft-cvs] freetype2 ./ChangeLog src/sfnt/ttcmap.c src/sfn...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 05/11/29 11:32:53 Modified files: . : ChangeLog src/sfnt : ttcmap.c ttcmap.h Log message: 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): Updated accordingly. (tt_cmap4_next): Updated 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 only 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. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1143tr2=1.1144r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/sfnt/ttcmap.c.diff?tr1=1.57tr2=1.58r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/sfnt/ttcmap.h.diff?tr1=1.17tr2=1.18r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[ft-cvs] freetype2 ./ChangeLog src/sfnt/ttcmap.c
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia-I Wu [EMAIL PROTECTED] 05/11/30 02:39:10 Modified files: . : ChangeLog src/sfnt : ttcmap.c Log message: * src/sfnt/ttcmap.c (tt_cmap4_char_map_binary, tt_cmap12_char_map_binary): Fix compiler warnings. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1144tr2=1.1145r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/sfnt/ttcmap.c.diff?tr1=1.58tr2=1.59r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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 fonts-dir 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] [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,
+ FT_Bool next )
{
-FT_Byte* table = cmap-data;
-FT_UInt32 result = 0;
-FT_UInt32
Re: [ft-cvs] freetype2 ./ChangeLog src/sfnt/ttload.c
On Sun, Nov 20, 2005 at 02:32:00PM +0100, Werner LEMBERG wrote: I'm not aware of any other tag, so it seems that your idea makes sense. Maybe a compromise is useful too, this is, to check for a mandatory table, then for the tag, then for the remaining tables. Why check for a mandatory table before for the tag? If the tag is not known good, then no check would be needed. The font is simply considered non-SFNT. Further checking is done only when the tag is good. -- Regards, olv ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[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
[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
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
Re: RE: Re: [ft] Monochrome Bitmap Trouble
Hi, On Mon, Oct 24, 2005 at 07:08:32AM +, Paresh Deshmukh wrote: Hello, I am still puzzling with bitmap. Please tell me is it possible to get a fixed size characters or can we specify the fixed inter character space rather using You can always use fixed inter-character space if you want to, in your application. This is not related to freetype. kerning. Also I am not able to get Japanese character from MsMincho font. How we can use FT_Select_Charmap(face,FT_ENCODING_SJIS). MSMINCHO.TTC seems not have a cmap of encoding FT_ENCODING_SJIS. -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft-cvs] freetype2 ./ChangeLog include/freetype/ftbitmap...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia I Wu [EMAIL PROTECTED] 05/10/20 02:13:46 Modified files: . : ChangeLog include/freetype: ftbitmap.h src/base : ftbdf.c src/cache : ftcmru.c Log message: * include/freetype/ftbitmap.h (FT_Bitmap_Copy, FT_Bitmap_Embolden), src/base/ftbdf.c (FT_Get_BDF_Property), src/cache/ftcmru.c (FTC_MruList_Reset, FTC_MruList_Done, FTC_MruList_Lookup): Misuse of FT_EXPORT/FT_EXPORT_DEF. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1107tr2=1.1108r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/include/freetype/ftbitmap.h.diff?tr1=1.7tr2=1.8r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/base/ftbdf.c.diff?tr1=1.12tr2=1.13r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/cache/ftcmru.c.diff?tr1=1.8tr2=1.9r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
[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] Vertical layout
On Wed, Oct 12, 2005 at 03:59:18PM -0700, Sergey Tolstov wrote: Hi, Hello, In what state is FT support for vertical glyph metrics? The problem you encountered has been fixed in CVS: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/truetype/ttgload.c.diff?r1=1.138r2=1.139 I am encountering problem with vertical glyph metrics, when they are present in a font file. I get a huge number for the linearVertAdvance, other values look fine, because of that, glyphs are not generated. I need advance value in design units for WYSIWYG. While debugging, I found: In the ttgload.c, line 1768, subtraction is incorrect advance_height = (FT_UShort)( loader-pp4.y - loader-pp3.y ); should be, according to earlier calculations advance_height = (FT_UShort)( loader-pp3.y - loader-pp4.y ); Even with that fix, linearVertAdvance is calculated incorrectly. (Should they use loader-vadvance instead?) As loader-pp's are in 26.6, advance_height should be divided by y_scale after the calculation. -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft-cvs] freetype2 ./ChangeLog src/truetype/ttinterp.c s...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia I Wu [EMAIL PROTECTED] 05/08/16 02:06:01 Modified files: . : ChangeLog src/truetype : ttinterp.c ttinterp.h Log message: * src/truetype/ttinterp.c, src/truetype/ttinterp.h: Update copyright messages. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1073tr2=1.1074r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/truetype/ttinterp.c.diff?tr1=1.73tr2=1.74r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/truetype/ttinterp.h.diff?tr1=1.28tr2=1.29r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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] 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-cvs] freetype2 ./ChangeLog src/truetype/ttdriver.c s...
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia I Wu [EMAIL PROTECTED] 05/07/26 08:14:04 Modified files: . : ChangeLog src/truetype : ttdriver.c ttobjs.h Log message: * src/truetype/ttdriver.c (Set_Char_Sizes): Avoid unnecessary computations and clean up. * src/truetype/ttobjs.h (struct TT_SizeRec_): Comment on the internal copy of metrics. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/ChangeLog.diff?tr1=1.1067tr2=1.1068r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/truetype/ttdriver.c.diff?tr1=1.78tr2=1.79r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src/truetype/ttobjs.h.diff?tr1=1.36tr2=1.37r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
Re: [ft] Bold and italic, cache manager
On Tue, Jul 19, 2005 at 09:43:18AM +, Tom Sparthate wrote: Hello, I wonder if freetype can draw bold and italic characters with a simply arial file. (by an transformation?) You can use FT_Outline_Embolden and FT_Outline_Transform. And I have a question concerning the cache manager, do you know how to use it? If you are looking for an example, I would suggest reading ftcommon.c of ft2demos (from cvs head). -- Regards, olv ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft-cvs] freetype2/docs CHANGES
CVSROOT:/cvsroot/freetype Module name:freetype2 Branch: Changes by: Chia I Wu [EMAIL PROTECTED] 05/06/22 03:56:15 Modified files: docs : CHANGES Log message: Add an entry about rewritten of `ftview' and `ftstring' CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/docs/CHANGES.diff?tr1=1.114tr2=1.115r1=textr2=text ___ Freetype-cvs mailing list Freetype-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-cvs
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_Glyph_To_Bitmap( glyf, render_mode, NULL, 0 );
+
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 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 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
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
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
[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
