Re: [ft-devel] First pretest of FreeType 2.1.10
Hi On Thu, 12 May 2005 09:22:02 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: I've uploaded a first pretest version of 2.1.10! This is mainly to test whether the library compiles on various platforms, and to check whether the library itself works correctly. There are still some rough edges with documentation files... Just I've tested on AIX5.2 with gcc-3.3.2, shared library built successfully, and ft2demos can display bundled TTF well. If building with XLC (proprietary cc of AIX) is expected, please let me know. As previous threads regarding to AIX complained, libtool's support status for XLC is questionable (as it is often). 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, 13 May 2005 14:52:24 +0800 Chia I Wu [EMAIL PROTECTED] wrote: On Fri, May 13, 2005 at 11:44:59AM +0900, [EMAIL PROTECTED] 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. Great Thank you, soon I will test it. 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 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. Yes, I think your comment is exactly right in the viewpoint of desktop window systems and application on them. And, I suppose standardizing embolding API is not harmful against other FreeType functionalities. 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. 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. 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. * 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? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
Dear Mr. George Williams, On 22 Aug 2005 22:04:00 -0700 George Williams [EMAIL PROTECTED] wrote: On Mon, 2005-08-22 at 18:29, [EMAIL PROTECTED] wrote: - state transition diagram uses undefined glyph ID A note of caution here, the apple world makes use of undefined glyph IDs as temporary state flags. One state machine will test for a condition and apply a substitution which creates an invalid GID, then another state machine will detect the bad GID, change it to something valid and enter a new state where it does other substitutions. Example font: Zapfino 4.1d6 Great Thank you for important information about the utilization undefined GID. At present, I cannot find Zapfino in my MacOS X (I'm not sure if I did misconfigured installation), so we have not tested the font. Please let me know where I can find Zapfino? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
Dear Mr. Steve Hartwell, On Mon, 22 Aug 2005 23:04:19 -0700 Steve Hartwell [EMAIL PROTECTED] wrote: on 8/22/2005 10:50 PM [EMAIL PROTECTED] wrote: I cannot find Zapfino in my MacOS X (I'm not sure if I did misconfigured installation), so we have not tested the font. Please let me know where I can find Zapfino? For this font (which is included in MacOS X) OK, I will re-install MacOS X. and perhaps other fonts which might be useful for your testing, I suggest you contact Peter Lofting [EMAIL PROTECTED]. Peter is very interested in tools for testing the quality and correctness of fonts, and I'm sure he'd be happy to provide you with suitable test material. Great Thank you for introduction! I'd seen his name when Mr. George Williams asked Apple's TTF specification for kern table on 2003. As written in README, some of TrueType GX tables (mort, feat, prop) are widely used, others (lcar, opbd) are very rare, and there are a few tables (kern format1) we cannot find samples. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] gxvalid patch for ftvalid.c
Dear Mr. Werner LEMBERG, On Tue, 23 Aug 2005 11:50:35 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: thanks a lot for your work! I've given both of you write access to the FreeType repository -- please add everything to the CVS; I'll revise it later on. Great Thank you for CVS permission! I will commit gxvalid patch within 48 hours from now. Just a minor nit: Wouldn't it be better if you thoroughly use `TRUETYPE_GX' instead of `TRUETYPEGX'? Or maybe `GX' is sufficient to avoid too long tags? Thank you for pointing out. Yes, the keyword TRUETYPEGX is ugly and lengthy for capitalized keyword. We've chosen it by a process of elimination. TRUETYPE_GX is more natural analogous of the name TrueType GX. But there are existing FT_TRUETYPE_XXX macros, so we've thought TRUETYPEGX is better to avoid namespace confusion, for the people unfamiliar with font formats. GX looks enoughly short, in fact, ICU uses such naming rule. But I'm afraid that GX is a bit too generic keyword, it can be used in different context, in future. If GX is expected to be particular keyword in future, I will rewrite with GX. How do you think about? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
Dear Mr. George Williams, On 23 Aug 2005 14:50:54 -0700 George Williams [EMAIL PROTECTED] wrote: On Mon, 2005-08-22 at 18:29, [EMAIL PROTECTED] wrote: 4-5. invalid feature number (117/183) - GX/AAT extension can include 255 different features for layout, but popular layout features are predefined Are you sure it's only 255? The 'feat' table stores both feature and setting ids as uint16. The 'mort'/'morx' chains also use uint16. I didn't see anything which said they were limited to 255 -- but I haven't read everything:-) Excuse me, it was my mistake in documentation: 65535, not 255. gxvalid can use uint16 feature number, does not limit to 255. (And there are certainly fonts which use feature numbers255, Osaka.dfont for one) Thanks for giving concrete example, OK, following is (part of) output of gxvalid on Osaka 4.2. [ftvalid:gx] validation targets: mort --- validation mort table validate chain 1/1 mort chain header table mort feature list table featureType 16000 is out of registered range, setting 0 is unchecked featureType 16000 is out of registered range, setting 1 is unchecked featureType 16001 is out of registered range, setting 0 is unchecked featureType 16001 is out of registered range, setting 1 is unchecked featureType 4 is registeredsetting 0 featureType 4 is registeredsetting 1 featureType 103 is registeredsetting 0 featureType 103 is registeredsetting 2 featureType 25 is registeredsetting 0 featureType 25 is registeredsetting 1 featureType 0 is registeredsetting 1 I see, as you've pointed out, featureType 255 are used, and gxvalid handles them correctly. (see http://developer.apple.com/fonts/Registry/index.html). Some fonts include feature number which is incompatible with predefined feature registry. In our survey, there are 140 fonts including feat table. a) 14 fonts uses too-large feature number (out of defined range). b) 67 fonts uses feature number which should not be used. c) 117 fonts set wrong feature range (nSetting). this infraction is found in mort/morx. The 'feat' (and 'mort') documentation says: Apple has defined a standard set of text features. You may include one or more of these or create your own text features. Font features that will be supported by your font must be part of the Font Feature Registry maintained by Apple Computer, Inc. To me this seems contradictory. First we are told we can create our own features, then we are told we can only use standard ones. (I really dislike Apple's TrueType documentation) I see. In fact, Osaka.dfont is manifactured by Apple themselves, but uses non-standard feature number, and it is not registered. Umm, I remove too-large feature number from the error list, because it is 'officially' permitted to use non-standard feature number, and Apple themselves do so, as you pointed out. As attached in above, at present, gxvalid shows tracing message about such feature number: featureType is not in predefined range, so the correctness of setting value cannot be validated. I think it is acceptable point of compromise. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
Dear Mr. George Williams,
Oops, sorry for crossing of paths.
On 23 Aug 2005 17:35:12 -0700
George Williams [EMAIL PROTECTED] wrote:
So:
a) 14 fonts uses too-large feature number (out of defined range).
I can't find anything that says the range is a byte, but there may be
something I've missed.
I agree. I remove it from the error list.
b) 67 fonts uses feature number which should not be used.
I'm assuming this means features not defined in Apple's Registry. I
think this should be ok.
No, I was meaning about the hole of predefined range.
According to http://developer.apple.com/fonts/Registry/index.html,
kanaSpacingType = 25,
ideographicSpacingType = 26,
cjkRomanSpacingType = 103,
/* The following types are provided for compatibility; note that
their use is deprecated. */
adobeCharacterSpacingType = 100,/* prefer 22 */
adobeKanaSpacingType = 101, /* prefer 25 */
adobeKanjiSpacingType = 102,/* prefer 26 */
adobeSquareLigatures = 104, /* prefer 1 */
There is a hole from 27 to 99, I thought it is reserved area,
although I could not find any documentation about it.
It should be used as same as the undefined area 105?
c) 117 fonts set wrong feature range (nSetting).
do you mean that more settings are defined for a feature than are
present for that feature in the 'feat' table? If so, I agree this should
be an error.
Or do you mean more settings are defined than are present in the
registry? I think that should be ok.
The latter. I was meaning the nSetting value is out of range
defined in Apple registry. For example, feature number 1
(ligatureType) has 15 settings aslike:
enum {
...
ligaturesType = 1,
requiredLigaturesOnSelector = 0,
...
abbrevSquaredLigaturesOffSelector= 15,
But, Courier 3.5 in MacOS 9.2.2:
[ftvalid:gx] validation targets: mort
---
validation mort table
validate chain 1/2
mort chain header table
mort feature list table
...
featureType 1 is registeredsetting 2
featureType 1 is registeredsetting 3
featureType 1 is registeredsetting 32out of defined range 15
featureType 1 is registeredsetting 33out of defined range 15
setting 32, 33 are out of defined range.
Your suggestion is that undefined setting values should be handled
as the same way for user-defined feature number (so they are not errors)?
If so, I will remove this from the error list.
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] gxvalid patch for ftvalid.c
On Wed, 24 Aug 2005 00:14:10 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: I will rewrite with GX. How do you think about? This is fine with me. After replacing _TRUETYPEGX_ macros to _GX_, I've just committed whole of gxvalid patch to CVS. Yamato-san, please commit ft2demos patch, after replacing the line in ftvalid.c #include FT_TRUETYPEGX_VALIDATE_H to #include FT_GX_VALIDATE_H Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
On Thu, 01 Sep 2005 23:39:34 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: Another reason to move away from the old Font Manager and to ATS, is that some of the Font Manager stuff will not carry over to Mac OS X on Intel without extra work, [...] Any volunteers? Neither David nor I use a Mac... I want to do. I have MacOS 9.2 + MacOS X 10.0 + MacOS 10.1 + MacOS 10.3 machine. Unfortunately, I have no developer kit for MacOS 9. Any recommendation what I have to buy? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
Dear Sirs, Status for Tiger's API deprecation issue: My working source is available from GNU arch archive from URL: http://www.gyve.org/~mpsuzuki/arch-2005.09.03 archive name: [EMAIL PROTECTED] project: freetype2--mps-macos--0.1 George Williams sent me his patch skelton to replace FSSpec by FSRef, it's slightly fixed and applied in the working tree. Now I'm working for replacement of FontManager by AppleTypeService, used in FT_GetFile_From_Mac_Name(). The function resolves abstract fontname recognized by system to concrete file, but the resolved result is returned by obsolete FSSpec structure. ATS provides the replacements for the most functions of FontManager, by 1:1 corresponding functions. But FontManager does not provide function to return font file by FSRef structure, and ATS does not either. In fact, there's no ATS function to find font file for a given font name, except of ATSFontGetFileSpecification(). I'm afraid it will be deprecated in future. However, I've already written sample programs to resolve font name - font file by ATS functions and FSRef data. They are available from GNU arch in above, project: carbon-sample--mps--0.0 Yet I've not checked other APIs, I suppose ATS is designed to hide concrete font data, and I should search other API to find concrete font data. Any suggestions? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
Dear Mr. Sean McBride, On Tue, 6 Sep 2005 13:31:13 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 2005-09-06 10:54, [EMAIL PROTECTED] said: In fact, there's no ATS function to find font file for a given font name, except of ATSFontGetFileSpecification(). Unfortunately I think you are right. :( But ATSFontGetFileSpecification () is not deprecated, so you can use that. Then convert the FSSpec it gives you into something else, like an FSRef. I filed a bug with Apple to make an FSRef version of that function. Thank you for advice. OK, I write this issue in TODO and use ATSFontGetFileSpecification() as temporal workaround. If you receive any reply from Apple about this issue, please inform ft-devel people. I'm afraid it will be deprecated in future. They will only deprecated it if/when they replace it. I wish this issue is fixed before Intel Mac :-) Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
Dear Sirs, Now I'm afraid the replacement of obsolete QuickDraw FontManager by AppleTypeService with keeping API compatibility is POSSIBLE but will be complexed. Please allow me spend a few weeks more. I attached the memo of working direction. Regards, mpsuzuki How to handle QuickDraw FontName without FontManager? = outline To build FreeType2 without compiler's warning on Tiger, we have to replace almost FM functions by ATS functions. To handle QuickDraw FM's font name without FM functions, devious technique may be required. 1. How to specify a font in QuickDraw FontManager system In FM, a font is specified by family typed as FMFamily (e.g. Courier) and its instance typed as FMFont (e.g. Courier, Courier Bold, Courier Italic: usually suffixes like Bold Italic etc are called as style). The FMFont instance itself has no storage for its own name, the name of instance is specified by joined string of family-name and style-suffix. This is QuickDraw FontName. The font name passed to FT_GetFile_From_Mac_Name() is QuickDraw FontName. So, to keep API compatibility, we have to handle QuickDraw FontName. # [NOTE] # The suffixes for style are not reserved word. # Fonts designed for Windows are not in suitcase format, # and the family is named directly, as Courier New Bold. 2. How to specify a font in Apple Type Service system - In ATS, a font is specified by font typed as ATSFontRef. Also there is family typed as ATSFontFamilyRef, but there's no hierarchical relationship between font and family. ATS has no support to find a font as a member of given family. # [NOTE] # There are conversion functions for migration purpose. # FMFontFamily - ATSFontFamilyRef, FMFont - ATSFontRef. 3. How to handle QuickDraw FontName in ATS system? 3-1. Problem: discontinuity between ATS font and family --- ATS family can be searched by QuickDraw FamilyName, but ATS font cannot be searched by QuickDraw FontName. On the other hand, ATS font can be used to find a font file, but ATS family cannot be. Making the situation worse, the naming conventions of ATS font and ATS family are incompatible. Although I've not find exact regularity, it seems that ATS font pefers to ASCII/Roman names but ATS family prefers to nationalized names. QuickDraw FamilyName is usually nationalized. For example, for a Korean font file /Library/Fonts/#Gungseouche.dfont, ATSFontGetName() returns #GungSeo Regular, ATSFontFamilyGetName() returns a Korean script. Therefore, it's difficult to find a ATS font from given ATS family by scanning font names. 3-2. Suggestion: utilization of ATSUI system Apple Type Services for Unicode Imaging (ATSUI) is text layout system on the top of ATS. Although it's system at higher layer, it has its own (in the other word, incompatible with ATS) font management system, and ATSUI font-id is compatible with QuickDraw FontManager. In the font name extraction of ATSUI system, we can specify the encoding of font name. Therefore, ATSUI can be used as a translator of font-name. [continues to experimental result which is now prepared...] ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
Dear Sirs, Finally I've finished benchmark testing of Resolving QuickDraw FontName by ATS, without QuickDraw API. The result is summarized at: http://www.gyve.org/~mpsuzuki/ats_benchmark.html From the benchmark result, rewriting FT_GetFile_From_Mac_Name() with keeping full compatibility with QuickDraw FontName without QuickDraw FontManager API is very very slow, it wouldn't payable solution. In fact, in comparison with original QuickDraw API, it will be 20 times slower on Panther (Mac OS X 10.3), and 500 times slower on Cheetar (Mac OS X 10.0). I think using QuickDraw FontManager API is simple and better. When we ignore the QuickDraw compatibility, some font names will be unresolvable after upgrading FreeType. For example, on Panther, I can find Courier CE by QuickDraw, but cannot find that by ATS. Correctly speeking, this is not FreeType's problem. There is fundamental incompatibility of font menu based on QuickDraw FontManager and that based on ATS. Also this difference is summarized in the page in above. Let me ask a question, which is better solution? Fix A: FT_GetFile_From_Mac_Name() is kept for QuickDraw. Add FT_GetFile_From_ATS_Name() for ATS. To avoid XXX is deprecated warning, FT_GetFile_From_Mac_Name() should be excluded in building. Fix B: Change the behaviour of FT_GetFile_From_Mac_Name() as system-dependent. If configured for ATS only, it will be incompatible with QuickDraw configuration. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Status of 2.2
Hi, On Mon, 03 Oct 2005 14:24:49 -0400 Matthias Clasen [EMAIL PROTECTED] wrote: - Does FT_OPTIMIZE_MEMORY still break apps ? I know that Pango has been patched, but I hear xfs segfaults with the memory optimizations. Are there patches beyond the (applied) pango patches to fix breakage due to this ? Yet I'm unfamiliar with the reason why they want to use FT_OPTIMIZE_MEMORY, if you know, please let me know. If it's something like maximum optimization is required, is there any benchmark tests comparing FreeType with/without FT_OPTIMIZE_MEMORY? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Question about cidparse.c/cid_parser_new( )
On Tue, 08 Nov 2005 10:12:19 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: And I think there should be more change in this code section: 'limit' should be reset by 'buffer + readsize' in where readsize is actual read size. Please provide a patch. Excuse me, give me 4 hours. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Question about cidparse.c/cid_parser_new( )
On Tue, 8 Nov 2005 19:17:02 +0900
[EMAIL PROTECTED] wrote:
On Tue, 08 Nov 2005 10:12:19 +0100 (CET)
Werner LEMBERG [EMAIL PROTECTED] wrote:
And I think there should be more change in this code section:
'limit' should be reset by 'buffer + readsize' in where readsize is
actual read size.
Please provide a patch.
Excuse me, give me 4 hours.
I've written 2 patchs to fix a bug reported by Mr. Taek Kwan Lee.
I want to hear comments which is easier to maintain in future.
Regards,
mpsuzuki
Following is the first one. Shorter.
Index: src/cid/cidparse.c
===
RCS file: /cvsroot/freetype/freetype2/src/cid/cidparse.c,v
retrieving revision 1.44
diff -u -r1.44 cidparse.c
--- src/cid/cidparse.c 13 Feb 2005 21:42:42 - 1.44
+++ src/cid/cidparse.c 8 Nov 2005 14:10:00 -
@@ -101,10 +101,24 @@
p = buffer + buff_len;
- if ( FT_STREAM_READ( p, 256 + 10 - buff_len ) )
-goto Exit;
+ {
+FT_ULong oldpos = FT_STREAM_POS();
+FT_ULong size = stream-size - oldpos;
+FT_Intmax_read_len = 256 + 10 - buff_len;
+
+
+if ( FT_STREAM_READ( p, FT_MIN( max_read_len, size ) ) )
+ goto Exit;
+
+if ( max_read_len size )
+{
+ limit = p + size - 10;
+ top_position = FT_STREAM_POS() - size - 10;
+}
+else
+ top_position = FT_STREAM_POS() - buff_len;
+ }
- top_position = FT_STREAM_POS() - buff_len;
buff_len = 256 + 10;
/* look for `StartData' */
The second one is deep rewriting and make the function shoter,
so I attach modified one.
Again:
/* now, read the rest of the file until we find a `StartData' */
{
FT_Byte buffer[256 + 10];
FT_Intread_len = 256 + 10;
FT_Byte* p= buffer;
for ( offset = (FT_ULong)FT_STREAM_POS(); ; offset += 256 )
{
FT_Intstream_len;
FT_Byte* limit;
stream_len = stream-size - FT_STREAM_POS();
if ( stream_len == 0 )
goto Exit;
read_len = FT_MIN( read_len, stream_len );
if ( FT_STREAM_READ( p, read_len ) )
goto Exit;
if ( read_len 256 )
p[read_len] = '\0';
limit = p + read_len - 10;
for ( p = buffer; p limit; p++ )
{
if ( p[0] == 'S' ft_strncmp( (char*)p, StartData, 9 ) == 0 )
{
/* save offset of binary data after `StartData' */
offset += p - buffer + 10;
goto Found;
}
}
FT_MEM_MOVE( buffer, p, 10 );
read_len = 256;
p = buffer + 10;
}
}
Found:
-
src_cid_cidparse_fix1.c.patch
Description: Binary data
src_cid_cidparse_fix2.c.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
Hi On Thu, 17 Nov 2005 10:36:00 +0800 Chia-I Wu [EMAIL PROTECTED] wrote: 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) Thank you, it's task of me (or Yamato-san). Give me 24 hours to fix it. Regards, mpsuzuki ___ 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, 17 Nov 2005 16:04:45 +0900 (JST) Masatake YAMATO [EMAIL PROTECTED] wrote: 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) mpsuzuki, I don't have time now. Could you compare gxvalid with otvalid? * @note: * This function only works with OpenType fonts, returning an error * otherwise. * * After use, the application should deallocate the five tables with * `free'. A NULL value indicates that the table either doesn't exist * in the font, or the application hasn't asked for validation. */ In otvalid, documents say `free' should be used. I see. The usage of FT_ALLOC() and FT_FREE() is very same between otvalid and gxvalid. Yet I'm not sure the reason why free() should be used for tools using otvalid, I suppose it is to make FreeType report the consumed memory for validation, by memory leak detection. If it's correct, ftvalid should use free() instead of FT_FREE(), to report the consumed memory for validation. Werner, my supposition about why tools using otvalid should use free() is right? Regards, mpsuzuki ___ 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, 17 Nov 2005 17:04:43 +0800 Chia-I Wu [EMAIL PROTECTED] wrote: $ 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 Thanks, I think, the result is really what we want to do by apinames. At present, I don't have enough machines to install latest Debian... Regards, mpsuzuki ___ 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, 17 Nov 2005 20:48:05 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: I suggest exporting another function, which simply calls FT_FREE, to free the tables. Yes, David suggests the same. Toshiya or Masatake, do you have time to implement proper functions, say, FT_TrueTypeGX_Validate_Free, which do the obvious? Maybe you find better function names. OK, I will do that. Give me 6 hours. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] failed to compile ftvalid.c
Dear Sirs, On Fri, 18 Nov 2005 10:05:32 +0900 [EMAIL PROTECTED] wrote: OK, I will do that. Give me 6 hours. I attached 4 patches, please check. freetype2_fix-FT_FREE_GX.patch: add FT_TrueTypeGX_Free() and FT_ClassicKern_Free() freetype2_fix-FT_FREE_OT.patch add FT_OpenType_Free() ft2demos_fix-FT_FREE_GX.patch fix ftvalid.c to use FT_TrueTypeGX_Free(), FT_ClassicKern_Free() ft2demos_fix-FT_FREE_OT.patch fix ftvalid.c to use FT_OpenType_Free() I wrote FT_TrueTypeGX_Free() to receive FT_Face (to identify the memory object) and FT_Bytes to free, but it is possible to receive FT_Memory instead of FT_Face. Any recommendation? Regards, mpsuzuki freetype2_fix-FT_FREE_GX.patch Description: Binary data freetype2_fix-FT_FREE_OT.patch Description: Binary data ft2demos_fix-FT_FREE_GX.patch Description: Binary data ft2demos_fix-FT_FREE_OT.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Problem with Type 42 incremental downloading font
Thanks to all. I asked: And, the incremental downloaded Type42 font object only I know is in PostScript printing data: especially that generated for Distiller. I agree, if FreeType can supporting incremental is good idea, but what application uses it? Werner wrote: The incremental code has been contributed by Graham Asher, mainly for use with GhostScript, IIRC (or was it Symbian?). We don't actively maintain it. On Mon, 14 Nov 2005 15:08:20 - Graham Asher [EMAIL PROTECTED] wrote: GhostScript can use it. I am not sure whether the current version of GhostScript does actually use it,. but that was what I wrote it for. On Mon, 14 Nov 2005 10:41:14 -0800 Dirck Blaskey [EMAIL PROTECTED] wrote: This code is also used by the Liberty Systems Postscript Interpreter (CentraDoc). It is quite handy in dealing with Postscript Type 42 fonts defined on-the-fly. I had no idea it wasn't actively maintained. Now I think that incrementally-loaded Type42 font driver is almost impossible to utilize without PostScript interpreter. From the viewpoint of PostScript interpreter maintainer, the current implementation incrementally-loaded Type42 font driver should be improved? There's any expected feature in future issue status? Regards, mpsuzuki P.S. I suppose generating subsetted Type42 font object is expected by various applications, but it is another issue, and I think it's not task of FreeType library. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Migrating layout table validation code to a new CVSmodule
On Mon, 21 Nov 2005 10:39:32 +0100 Turner, David [EMAIL PROTECTED] wrote: About plugin, it is good idea (although I'm afraid that FreeType is very very widely used on platforms without dlopen etc), but it will be long way work. It should be FreeType3, even if the binary compatibility is kept. There is no need for dlopen() or equivalent. We have FT_Add_Module which can be called just after FT_Init_FreeType to add modules to the font engine. That's what I use on my company's embedded software, to register custom font drivers for some proprietary bitmap formats we need to support. All is done statically. Excuse me, I'm unfamiliar with FT_Add_Module(). I think, FT_Add_Modules() is capable to use functions that are available in linking time. I'm not sure if it can add modules derived from dlopen()-ed objects, but, at least, on no-dlopen() systems, we have to link both of libfreetype.a and libftvalid.a, to retain the possibility to use otvalid/gxvalid module. Therefore, I think, the situation is same with the case that otvalid /gxvalid are included but disabled-by-default in libfreetype.a itself. I'm afraid the difference is just in the viewpoint of FreeType maintainer: the separate update of libftvalid.a is enabled. My understanding is right? If I rewrite gxvalid to smaller and limited validation (e.g. memory alignment, number of members etc) by default, it's acceptable to include? I think that wouldn't solve the issue: - it's not really part of the font engine's work, since we don't provide APIs to process the tables. Indeed, but still I want the validation functions are included to check the available feature before real font file loading procedure. Werner, how do you think of this issue? - it ties the releases of the validation and FT2 code, when these could be independent. I think, the feature of otvalid is almost fixed and won't cause urgent update to fix severe bug in otvalid. And, my propose is the simplification gxvalid for such level. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] aface-num_faces of FT_New_Face() in ftmac.c
Hi, Sorry for long lated working for FreeType classic MacOS port. I've almost finished to modularize framework-dependent parts of ftmac.c (as initial revision), and now I proceed to regression test. # BTW, the commandline interface of MPW (classic MacOS developer # environment) is very difficult to use for UNIX junkies, like me. # I wrote a MPW program which scans specified folder and tries # to open all files as font. The current status is available from GNU arch archives at URL http://www.gyve.org/~mpsuzuki/arch-2005.09.03 Archive Name [EMAIL PROTECTED] Project Name freetype2--mps-macos--0.2 ft2demos--mps-macos--0.2 In the regression test, I've found that FT_New_Face() in ftmac.c does not return correct aface-num_faces. From the document in freetype.h, original FT_New_Face() is designed to return available number of faces: if 2 TTF faces are embedded in single TTC file, aface-num_faces must be 2. But, aface-num_faces is not touch in ftmac.c (you can know easily by grep ftmac.). Therefore, FT_New_Face() in ftmac.c cannot count the faces of special font format supported by ftmac.c: old PS font for MacOS (LWFN: LaserWriter FoNt), and Suitcase. About LWFN, it is noted that FT_New_Face() cannot count the faces in it, in ftmac.c. However, I never seen LWFN font including multiple resources, and I suppose it's not widely used. On the other hand, Suitcase font format is designed to include multiple sfnt scalable font resources into single font file. It is still used in classic MacOS (you can find Courier of MacOS 9.2 includes 2 sfnt resources). I think it is expected to count the faces in Suitcase correctly. ...So, now I'm going to fix this, and I want to ask about binary compatibility. At present, via FT_New_Face() in ftmac.c, we can access the 2nd sfnt resource as the 2nd face of the font, although we don't know how many sfnt resources are included in the font. Other resources, like fbit bitmap, NFNT bitmap, are ignored and not counted at all. At present, fbit and NFNT bitmap resources are not supported by FreeType, but I want to support it in future (I've ever written a ruby script to parse it). In my understanding, the usage of NFNT bitmap is similar to the bitmap font in sfnt. So, it is expected to ignore the number of NFNT in available-face-counting. Possibly FreeType user don't want to receive the number of embedded bitmap font (numSizes of EBLC table) via aface-num_faces. I wish so. By excluding NFNT resource from available-face-counting, we can use Suitcase font aslike TTC. In fact, think about the situation: the first face is outline only, the second face is bitmap only, the third face is outline only... everyone will be confused. But, if we exclude NFNT bitmap resources from available-face-counting, we cannot access them anymore, because they are separated from sfnt resource. To solve this problem, some ugly hook in sfnt resource handler will be required. From the viewpoint of FreeType developer, I don't want to do so - counting NFNT resource as separated resource is better to code modularization. Yet I don't have ready-to-commit NFNT driver, so this issue can be suspended. This font has 4 faces, but 2 faces are in unsupported formats is not good reply, my first fix must be counting without NFNT. Any comments are welcome. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64 and i386
Hi On Tue, 06 Dec 2005 19:02:52 +0200 Ilya Konstantinov [EMAIL PROTECTED] wrote: Currently, freetype i386 and x86-64 collide in the following files: /usr/bin/freetype-config /usr/include/freetype2/freetype/config/ftconfig.h I see. This makes installation of two freetype development kits impossible. Installing two development kits is desirable when the developer does plenty of cross-compiling to x86-64/i386, which is often the case on x86-64 machines. I see. Let me clarify the condition: the issue you reported is specific to GNU/Linux on x86-64, ppc64 and s390x. Grepping configuration files of X11R6.8.2, I found that only GNU/Linux on these processors use special separation of libraries by lib lib64 (no separation for binary executables, header files). Such co-existence of multiple binary formats might be useful on mips64, sparc64 and sh64 either, but I could not find such library separation for these processors. Oops, yet I've not checked the situation of MacOS using ppc32 and ppc64. Do you know Linux's policy to use, or not-to-use lib/lib64 library separation? It's important to determine the suitable directory to install. For the first step, configure script can be used to find the system uses lib/lib64 library separation, but it's insufficient to support cross-building completely. It would be very much desired that: 1. freetype-config would be recoded to detect its environment and return the appropriate directories, thus creating a single copy of freetype-config on equal-prefix builds *or* freetype moved to pkgconfig (freetype-config may remain a frontend) Umm, moving to pkgconfig sounds easy solution. But I'm afraid about the systems using freetype-config without pkgconfig. How pkgconfig separates lib/lib64? 2. ftconfig.h would be moved to the lib(64)/config directory, just as it is for glib2 etc. Sounds reasonable, although I want to revise configure.ac and builds/unix/ftconfig.in to support both platforms (ah, I must learn more about Jam for multi binary formats). BTW, when the header files are different between i386 x86-64 (I call it as arch-dependent), GNU/Linux for x86-64 always separates arch- dependent files out of /usr/include? Such softwares are exceptional? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64 andi386
Hi, On Wed, 7 Dec 2005 11:30:03 +0100 Antoine Leca [EMAIL PROTECTED] wrote: BTW, this is not really cross-compiling. Real cross-compiling IMHO usually involves having a cross-compiling target environment, different from the host environment (usually selected as higher priority flags overriding the normal ones). Yeah, as you pointed out, the standard cross-compiling by GNU tools use completely separated directories: aslike /usr/i386-pc-linux-gnu and /usr/amd64-pc-linux-gnu, to avoid mixing files for target platform with files for host platform. GNU/Linux for x86-64 stores i386 libraries into /lib and x86-64 native libraries into /lib64. Without doubt, it's for runtime binary compatibilities with existing GNU/Linux for i386, but I don't know if it's for developer environment compatibility. I'm afraid that there are many softwares that we cannot share header files between i386 and x86-64 architechtures. perhaps select the correct ones according to flags such as -m32 and -m64 for gcc..., that is, _not_ really doing something as complex as setting up a complete cross-compiling environment. I agree. It's a bit confusing to call such compiling as cross-compiling It would be very much desired that: 1. freetype-config would be recoded to detect its environment Can you please elaborate on what do you mean by your environment here? I am sorry if it seems ingenious. I am not currently running Linux, nor GLib; as such I am not sure what is the current official process of configuration of Freetype; if I am not a normal user of Freetype and as such my remarks are irrelevant, please say so, I won't be sad. I'm afraid there's no official process in this issue - there might be just how popular GNU/Linux distributors (wanna) do. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] No support for side-by-side installation of x86-64 and i386
Hi, On Wed, 7 Dec 2005 14:15:52 +0100 (CET) On Wed, 7 Dec 2005, [EMAIL PROTECTED] wrote: I see. Let me clarify the condition: the issue you reported is specific to GNU/Linux on x86-64, ppc64 and s390x. Solaris 64-bit also has ABI-separated library directories: Great Thank you for helpful info. Let me ask more about the separations on Solaris: * Optional softwares use same separation rules? For example, there are something like /usr/X11R6/lib/64 ? * How about header files? The header files are separated completely? Or, the shareable headers are installed in /usr/include and other arch-dependent headers are separated in other directories? Or, system has only headers for most-suitable architechture? Regards, mpsuzuki P.S.: Hey, any guys on IRIX, AIX and HP-UX? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] aface-num_faces of FT_New_Face() in ftmac.c
Hi all,
Attached is patch for ftmac.c, make it to return the number
of unique scalable faces. I've tested with TrueType fonts
bundled to MacOS. The functionalities for resource-fork based
PS font (LWFN font) are not tested at all (although I think
I don't change behaviour for LWFN resource), please give me
informations about where I can obtain from.
Also I attached ftoldmac.c that is (unifinished) small test
program: scanning fonts in a directory and passing them to
FT_New_Face_From_FSSpec(). If anybody interested in regression
test, ask me to hurry for the documentation.
NOTE: this is a part of forthcoming jumbo patch to fix ftmac.c's
obsolete functions issue on Tiger.
Regards,
mpsuzuki
original patched
---
* face-num_faces is always 0* face-num_faces is the number of
included sfnt or LWFN resource
* face-num_fixed_size is set* face-num_fixed_size is set
to the number of embeddedto the number of embedded
bitmap in sfnt resource. bitmap in sfnt resource.
The number of NFNT resource is
ignored.
* face index counts both of * face index does not count NFNT
sfnt and NFNT resource, resource (until the day NFNT
although FT_New_Face() bitmap font is supported).
with the face index to
NFNT resource returns the
previous sfnt resource.
In following example,
when you call face 1/2/3,
you receive face 0.
+-+- sfnt A face 0 +--+- sfnt A face 0
| | | |
| +- NFNT A1 face 1 | +- NFNT A1 x
| +- NFNT A2 face 2 | +- NFNT A2 x
| +- NFNT A3 face 3 | +- NFNT A3 x
||
+-+- sfnt B face 4 +--+- sfnt B face 1
| | | |
| +- NFNT B1 face 5 | +- NFNT B1 x
| +- NFNT B2 face 6
| +- NFNT B3 face 7
|
--- freetype2.orig/src/base/ftmac.c 2005-12-14 09:10:29.0 +0900
+++ freetype2_ftmacfix/src/base/ftmac.c 2005-12-14 10:42:49.0 +0900
@@ -23,15 +23,11 @@
support this I use the face_index argument of FT_(Open|New)_Face()
functions, and pretend the suitcase file is a collection.
-Warning: Although the FOND driver sets face-num_faces field to the
-number of available fonts, but the Type 1 driver sets it to 1 anyway.
-So this field is currently not reliable, and I don't see a clean way
-to resolve that. The face_index argument translates to
-
- Get1IndResource( 'FOND', face_index + 1 );
-
-so clients should figure out the resource index of the FOND.
-(I'll try to provide some example code for this at some point.)
+Warning: fbit and NFNT bitmap resources are not supported yet.
+In old sfnt fonts, bitmap glyph data for each sizes are stored in
+each NFNT resources, instead of bdat table in sfnt resource.
+Therefore, face-num_fixed_sizes is set to 0, because bitmap
+data in NFNT resource is unavailable at present.
The Mac FOND support works roughly like this:
@@ -267,6 +263,8 @@
}
+ /* count_faces_sfnt() counts both of sfnt NFNT refered by FOND */
+ /* count_faces_scalable() counts sfnt only refered by FOND */
static short
count_faces_sfnt( char *fond_data )
{
@@ -277,6 +275,28 @@
}
+ static short
+ count_faces_scalable( char *fond_data )
+ {
+AsscEntry* assoc;
+FamRec* fond;
+short i, face, face_all;
+
+
+fond = (FamRec*)fond_data;
+face_all = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+assoc = (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
+face = 0;
+
+for ( i = 0; i face_all; i++ )
+{
+ if ( 0 == assoc[i].fontSize )
+face ++;
+}
+return face;
+ }
+
+
/* Look inside the FOND data, answer whether there should be an SFNT
resource, and answer the name of a possible LWFN Type 1 file.
@@ -411,7 +431,7 @@
if ( have_lwfn ( !have_sfnt || PREFER_LWFN ) )
return 1;
else
- return count_faces_sfnt( *fond );
+ return count_faces_scalable( *fond );
}
@@ -744,36 +764,33 @@
FT_Long face_index,
FT_Face*aface )
{
-FT_Error error = FT_Err_Ok;
+FT_Error error = FT_Err_Cannot_Open_Resource;
short res_index;
Handlefond;
-short num_faces;
+short num_faces_in_res, num_faces_in_fond;
UseResFile( res_ref );
+num_faces_in_res = 0;
for ( res_index = 1; ; ++res_index )
{
fond = Get1IndResource( 'FOND', res_index );
if ( ResError() )
- {
-error = FT_Err_Cannot_Open_Resource;
-goto Error;
- }
- if ( face_index 0 )
break
Re: [ft-devel] No support for side-by-side installation of x86-64and i386
On Mon, 26 Dec 2005 11:28:30 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: AC_ARG_ENABLE([multi-abi], [...] Please put all this stuff into one or more separate files (similar to ft-munmap.m4) to make it more comprehensible. Additionally I wonder whether there isn't already some stuff in, say, libtool. Otherwise you could probably contribute your code -- I'm quite sure that the libtool maintainers can give you additional advice. OK, I'll check libtool and reconsider to reduce the script size. Although I believe mine is not the first autoconf macro, I've checked macros bundled with automake, autoconf, and http://ac-archive.sourceforge.net/ but I could not find. + /* ARCH_DEP_BEGIN */ #undef SIZEOF_INT #undef SIZEOF_LONG + /* ARCH_DEP_END */ Here we need more comments to explain what the comments mean and that they must not be changed. OK! Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype on Mac uses deprecated functions
Hi all, Finally I post my jumbo patch to fix deprecated function XXX is used issue on MacOS X 10.4, since 25/Aug/2005. PROBLEM --- You will see the warning when you build for Intel-based Mac, aslike: $ env \ CC=i686-apple-darwin8-gcc-4.0.1 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ \ ./configure \ --with-old-mac-fonts \ --host=i686-apple-darwin8 \ --build=powerpc-apple-darwin8.3.0 ... $ make ... In file included from /Users/mps/redhat/BUILD/freetype2/src/base/ftbase.c:35: /Users/mps/redhat/BUILD/freetype2/src/base/ftmac.c: In function 'FT_GetFile_From_Mac_Name': /Users/mps/redhat/BUILD/freetype2/src/base/ftmac.c:150: warning: 'FMCreateFontFamilyIterator' is deprecated (declared at /Developer/SDKs/MacOSX10.4u.sdk//System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:573) ... SOLUTION After applying my jumbo patch to latest freetype2 (on CVS) and recreate builds/unix/configure, it provides several switches to use or ignore MacOS specific APIs. --with-fsspec use obsolete FSSpec API of MacOS, if available (default=yes) --with-fsrefuse Carbon FSRef API of MacOS, if available (default=yes) --with-quickdraw-toolbox use MacOS QuickDraw in ToolBox, if available (default=yes) --with-quickdraw-carbon use MacOS QuickDraw in Carbon, if available (default=yes) --with-ats use AppleTypeService, if available (default=yes) By default, these switchs check availability automatically, but you can set them explicitly. If FSRef API is available (checked automatically), ftmac.c uses FSRef API instead of deprecated FSSpec API, at maximum, so deprecated warning about FSSpec won't appear. On the other hand, even if QuickDraw APIs are deprecated, the switchs detect them automatically, and use them for FT_GetFile_From_Mac_Name(). To remove deprecated warning, you have to set --with-quickdraw-toolbox=no and --with-quickdraw-carbon=no manually. By disabling QuickDraw, FT_GetFile_From_Mac_Name() is changed to pseudo function which returns FT_Err_Unimplemented_Feature always. Apple recommends to migrate from QuickDraw to ATS, but, as I've ever reported, compatible function is hard to implement and will be unbelievably slow. As a quick replacement, I added FT_GetFile_From_Mac_ATS_Name() that returns FSSpec (oops, it's obsolete!) for given ATS font name. About the abscondence of font in migration from QuickDraw to ATS, use my ftoldmac tool (see previous post in this list). By ftoldmac tool, I checked that the number of loadable font files and loadable font faces are same with original FreeType, on MacOS X 10.4. TODO * Tests on real System6 7. It seems that new QuickDraw APIs in Carbon (e.g. FMCreateFontFamilyIterator() etc) are not available on ToolBox library (say, System 7 environment) I classify 2 groups of QuickDraw FontManager APIs: quickdraw-toolbox is old API described in ancient Inside Macintosh: Fonts. quickdraw-carbon is new API described in Carbon reference. * On MacOS X, giving --with-fsref=no disables FreeType2 to load most data-fork fonts FreeType2 uses stdio functions to load font files. On MacOS, there are several incompatible font access APIs: FSSpec comes from FileManager, not from POSIX, so its pathname separator is always :. stdio in MPW's StdCLib uses such syntax. But, on MacOS X, stdio comes from POSIX, its pathname separator is /. FSRef API has support to work on both syntax, but FSSpec does not have. Maybe you wish if there's regression test for all combination of FSSpec|FSRef and QuickDraw|ATS. MacOS X might be best platform for such automated regression test. Unfortunately it's impossible, at present. * Complete cleaning of FSSpec. Apple recommends to migrate from FSSpec to FSRef, because FSSpec cannot handle long file name and UTF-16 encoded file name. But some Carbon functions are left in FSSpec- dependent because there's no replacements. * Unification with POSIX resource fork accessor. Masatake Yamato wrotes resource fork accessor by POSIX functions, to use resource-fork fonts on real UNIX system that can access resource fork. To reduce the cost of maintainance, unification is expected. Regards, mpsuzuki freetype2_ftmac_jumbo.patch.bz2 Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft] updating www.freetype.org
Hi, On Mon, 16 Jan 2006 22:42:23 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: I've updated all top-level documents of www.freetype.org. Please report any problems and/or inconsistencies you find. Excuse me, this is not about top-level documents. I found that CVS repository is still pointing to the lost server of savannah. Following patch fixes it. Should I write some warning (or color the line to show up) for the developpers who have source trees with obsolete CVS repository? Regards, mpsuzuki --- developer.html.orig Tue Jan 17 06:24:20 2006 +++ developer.html Thu Jan 26 10:13:55 2006 @@ -189,7 +189,7 @@ following value for ttCVSROOT/tt/p div - align=centertt:pserver:[EMAIL PROTECTED]:/cvsroot/freetype/tt/div + align=centertt:pserver:[EMAIL PROTECTED]:/cvsroot/freetype/tt/div pWhen asked for a password, simply press Enter for ttcvs login/tt. The module names are ttfreetype/tt (Freetype ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: [ft] updating www.freetype.org
Hi, On Thu, 26 Jan 2006 05:56:53 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: Should I write some warning (or color the line to show up) for the developpers who have source trees with obsolete CVS repository? Yes, this might be helpful. OK, following short patch is enough? I think I should not write too lengthy notes (like howto update ~/.cvspass, how to rewrite files under CVS/). Regards, mpsuzuki --- developer.html.orig Thu Jan 26 14:33:51 2006 +++ developer.html Thu Jan 26 14:42:03 2006 @@ -185,6 +185,9 @@ /li li pa name=anoncvsbUse anonymous CVS access/b/abr + pfont color=redGNU Savannah CVS server moved to + cvs.savannah.nongnu.org on 12-Dec-2005. You should login again + and update the trees that checked out before./font/p The FreeType sources can be downloaded to you through CVS. Use the following value for ttCVSROOT/tt/p ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] zos / ebcdic platform
Hi, On Fri, 27 Jan 2006 11:59:08 +0100 regis bertrand [EMAIL PROTECTED] wrote: can't be found. True type files now work in both versions but opentype can't be open with the last version. Excuse me, I think FreeType does not provide any OpenType specific features, so I guess you mean CFF OpenType (which includes PS font in its CFF table instead of sfnt table). Is it right? And, what kind of errors you had? If you could build FreeType with debug option as written in docs/DEBUG, please post detailed debug messages you receive. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] fix --with-old-mac-fonts option
Hi all,
I'm sorry that --with-old-mac-fonts option in
configure.ac was broken by my previous jumbo
patch (to fix deprecated API issue on MacOS X).
At present, the option does not work well on
UNIX platforms. Following is patch to fix it.
Thinking of that CoreFoundation library is
published under OSI license, Carbon subset
is possible on traditional UNIX platform.
(maybe, we cannot expect opensource Quartz,
but can expect opensource FSRef functions)
In such case, I should change linking test
for MacOS X specific LDFLAGS -Xlinker -framework ...
into more generic test. If anybody knows
such implementation, please let me know.
Regards,
mpsuzuki
--- freetype2.orig/builds/unix/configure.ac
+++ freetype2/builds/unix/configure.ac
@@ -140,10 +140,17 @@
AS_HELP_STRING([--with-old-mac-fonts],
[allow Mac resource-based fonts to be used]))
if test x$with_old_mac_fonts = xyes; then
+ orig_LDFLAGS=${LDFLAGS}
+ AC_MSG_CHECKING([CoreServices ApplicationServices of Mac OS X])
LDFLAGS=$LDFLAGS -Xlinker -framework -Xlinker CoreServices \
-Xlinker -framework -Xlinker ApplicationServices
-else
- CFLAGS=$CFLAGS -DDARWIN_NO_CARBON
+ AC_TRY_LINK([ ], [ ], [
+AC_MSG_RESULT([ok])
+ ], [
+AC_MSG_RESULT([not found])
+LDFLAGS=${orig_LDFLAGS}
+CFLAGS=$CFLAGS -DDARWIN_NO_CARBON
+ ])
fi
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] fix --with-old-mac-fonts option
Hi, Just I've committed my fix to configure.ac, thank Werner for comment. On Mon, 6 Feb 2006 11:09:42 -0500 Sean McBride [EMAIL PROTECTED] wrote: On 2006-02-06 10:12, [EMAIL PROTECTED] said: Thinking of that CoreFoundation library is published under OSI license, Carbon subset is possible on traditional UNIX platform. (maybe, we cannot expect opensource Quartz, but can expect opensource FSRef functions) Only a subset of CoreFoundation (called CoreFoundationLite IIRC) is available as open source. None of Carbon is open source, and I would not expect that to change. Thank you, I've not known the difference between CF and CFLite. I with my fix is enough for next release :-). Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Some fragmentized characters.
Hi, On Wed, 15 Feb 2006 20:31:13 +0800 DingLi(丁力) [EMAIL PROTECTED] wrote: When I use Freetype, I found that some phenomenon that some fragmentized characters. For example, the mingliu.tcc(True Collection), is it a bug? This is not bug of FreeType. MingLiU.ttc requires bytecode hinting support which is covered by Apple patent. Possibly you will find same issue in Ghostscript. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] about freetype-1.3.1 compile issue
Hi On Mon, 20 Feb 2006 17:03:15 +0800 Giant SZ Li [EMAIL PROTECTED] wrote: How do you compile static library libttf.a for ARM7? our arm7 platform run linux 2.4, our cross compiler is arm-linux-uclibc-(3.4.2 version)! I download freetype-1.3.1.tar.gz, and uncompress it, cd freetype-1.3.1 ./configure --disable-shared --enable--static then make I think freetype-1.3.1 had been packaged before autoconf knows the name of arm-uclibc-linux, I'm not sure if configure works well for the target. Have you checked the object files are really compiled with uclibc headers? Now I'm trying to cross build on glibc-based Linux/ARM to uclibc library. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] about freetype-1.3.1 compile issue
Hi, A few exchange with Giant, we could build libttf.a, so I post a short summary to cross build freetype-1.3.1, for search engine users :-). On Tue, 21 Feb 2006 07:01:23 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: but how can I configure for my embedded arm7 system? Normally this is controlled with the --host, --build, and --target options of the configure script. I can't remember whether version 1.x supports cross compiling. configure in freetype-1.3.1 tarball is not ready for cross building. to recreate configure supporting cross buidling, commenting-out AC_REQUIRE([AC_PROG_MAKE_SET]) and executing autoconf again is enough. However, in this case (target is arm-linux-uclibc, not arm-uclibc-linux) config.sub could not recognize target system name. small fix is required for config.sub aslike: --- config.sub.orig 2006-02-21 19:42:24.0 +0900 +++ config.sub 2006-02-21 19:40:12.0 +0900 @@ -68,7 +68,7 @@ # Here we must recognize all the valid KERNEL-OS combinations. maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'` case $maybe_os in - linux-gnu*) + linux-gnu* | linux-uclibc* ) os=-$maybe_os basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'` ;; I think it's enough to build libttf.a. Unfortunately, test programs (like ftdump) are not ready for cross build. Anyway, I wish people to migrate to FreeType2, as Werner wrote. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] last fixes for forthcoming release
Hi Sorry for my inactivity for the urgent tasks to release freetype-2.2.. Just I've tested cvs HEAD on GNU/Linux and MacOSX 10.4., and I'm afraid that gcc-4.x cannot build ftccache.c. I received complains aslike: gcc -pedantic -ansi -I/Users/mps/redhat/BUILD/ft22test/freetype2/objs \ -I./builds/unix -I/Users/mps/redhat/BUILD/ft22test/freetype2/include \ -c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DHAVE_FSSPEC=1 \ -DHAVE_FSREF=1 -DHAVE_QUICKDRAW_TOOLBOX=1 -DHAVE_QUICKDRAW_CARBON=1 \ -DHAVE_ATS=1 -DFT_CONFIG_CONFIG_H=ftconfig.h -DFT2_BUILD_LIBRARY \ -DFT_CONFIG_MODULES_H=ftmodule.h \ -I/Users/mps/redhat/BUILD/ft22test/freetype2/src/cache \ /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c \ -fno-common -DPIC -o \ /Users/mps/redhat/BUILD/ft22test/freetype2/objs/.libs/ftcache.o In file included from /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c:24: /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftccache.c:262: error: static declaration of 'ftc_node_destroy' follows non-static declaration /Users/mps/redhat/BUILD/ft22test/freetype2/include/freetype/cache/ftccache.h:89: error: previous declaration of 'ftc_node_destroy' was here make: *** [/Users/mps/redhat/BUILD/ft22test/freetype2/objs/ftcache.lo] Error 1 mps-iBook:~/redhat/BUILD/ft22test/freetype2 mps$ gcc --version powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5247) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I received same error on GNU/Linux with gcc-4.0, although no error in building by gcc-2.95.3 and gcc-3.3.x. Am I testing wrong branch? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] last fixes for forthcoming release
Hi I found following tasks I have to finish before freetype-2.2. 1. Makefile in ft2demos should refer freetype2/modules.cfg, but does not at present. Therefore, libfreetype.la is built without gxvalid/otlavid module by default, but make -C ft2demos tries to build ftvalid and failed. 2. Makefiles for MPW should be updated. I've not updated MPW header files for the modification for internal headers. Regards, mpsuzuki On Mon, 27 Feb 2006 12:39:37 +0900 [EMAIL PROTECTED] wrote: On Mon, 27 Feb 2006 12:23:36 +0900 [EMAIL PROTECTED] wrote: In file included from /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftcache.c:24: /Users/mps/redhat/BUILD/ft22test/freetype2/src/cache/ftccache.c:262: error: static declaration of 'ftc_node_destroy' follows non-static declaration /Users/mps/redhat/BUILD/ft22test/freetype2/include/freetype/cache/ftccache.h:89: error: previous declaration of 'ftc_node_destroy' was here The error caused by following conflict: ftccache.h declares, around line #89 FT_BASE( void ) ftc_node_destroy( ... ) ftccache.c declares, around line #262 FT_LOCAL_DEF( void ) ftc_node_destroy( ... ) Which type is correct? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] last fixes for forthcoming release
Hi, On Mon, 27 Feb 2006 22:57:13 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: The interface functions in ftgxval and ftotval return errors safely, when libfreetype is built without gxvalid and otvalid. So, I think, ftgxval/ftotval should be enabled always, [...] I agree. Please change this. Thank you, I changed ftgxval.c in modules.cfg by default. But, now I found that modules.cfg disables ftgxval. ft2demos/Makefile should be capable for such cases? Maybe, but I think it's not an urgent problem. Following is my idea: 1. ft2demos/Makefile includes modules.cfg to check whether ftgxval.c and ftotval.c are built /or not. 2. Rule to build ftvalid is quoted by conditionals. Index: Makefile === RCS file: /cvsroot/freetype/ft2demos/Makefile,v retrieving revision 1.33 diff -u -r1.33 Makefile --- Makefile1 Feb 2006 21:17:54 - 1.33 +++ Makefile28 Feb 2006 01:27:48 - @@ -36,6 +36,20 @@ endif +## +# +# MODULES_CFG points to the current `modules.cfg' to use. It is defined +# by default as $(TOP_DIR)/modules.cfg. +# +ifndef MODULES_CFG + MODULES_CFG := $(TOP_DIR)/modules.cfg +endif + +ifeq ($(wildcard $(MODULES_CFG)),) + no_modules_cfg := 1 +endif + + # # Check that we have a working `config.mk' in the above directory. @@ -62,6 +76,10 @@ # include $(CONFIG_MK) + ifndef no_modules_cfg +include $(MODULES_CFG) + endif + have_makefile := $(strip $(wildcard Makefile)) ifeq ($(PLATFORM),unix) @@ -229,11 +247,20 @@ # # The list of demonstration programs to build. # - EXES := ftlint ftmemchk ftdump testname fttimer ftbench ftchkwd ftvalid + EXES := ftlint ftmemchk ftdump testname fttimer ftbench ftchkwd # Comment out the next line if you don't have a graphics subsystem. EXES += ftview ftmulti ftstring ftgamma + # ftvalid requires ftgxval.c and ftotval.c + # + ifneq ($(findstring ftgxval.c,$(BASE_EXTENSIONS)),) +ifneq ($(findstring ftotval.c,$(BASE_EXTENSIONS)),) + EXES += ftvalid +endif + endif + + # Only uncomment the following lines if the truetype driver was # compiled with TT_CONFIG_OPTION_BYTECODE_INTERPRETER defined. # ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType version 2.2.1 released
Hi, On Tue, 16 May 2006 13:19:33 -0400 Matthias Clasen [EMAIL PROTECTED] wrote: We looked at updating freetype to 2.2.1 in Fedora recently, but discovered that libXfont still depends on the internal freetype headers (in the X 7.1 release candidate). So I wondered if anybody has a libXfont patch. There is none on the list of rogue clients... I think Turner is aware of libXfont issue. I was working to fix libXfont but not finished, see http://lists.gnu.org/archive/html/freetype-devel/2006-02/msg00098.html At least, I can't have a time to restart the work until 2006/06/18. Too late? oops. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
Hi, Sorry for spending your time by non-intuitive behaviour of validation modules and ftvalid. On 14 Jun 2006 20:47:48 -0700 George Williams [EMAIL PROTECTED] wrote: I tried ftvalid for the first time today. At first it just told me that every font I fed it was invalid. I discovered this was because the default freetype does not include the validation modules. After changing modules.cfg everything passed. Oops. Possibly the exist of ftvalid itself made you confused. At present, ft2demos builds ftvalid whenever the public APIs of validation modules (FT_OpenType_Validate()) are available, even if it's just pseudo function and the internal validation functions are disabled by modules.cfg. If it's bad idea, I will fix ft2demos/Makefile to build ftvalid only when the internal validation functions are enabled. Please let me know your thought. I wonder... would it be possible to have FT_OpenType_Validate return something other than FT_Err_Invalid_Argument if the validation service is not present, and have ftvalid check for the service missing error and generate an error saying that the service isn't present rather than that the font is invalid? Sorry, when the internal validators are disabled, FT_XXX_Validate() should return FT_Err_Unimplemented, instead of FT_Err_Invalid_Argument. It was my mistake. I remember we had ever discussed this issue and agreed to implement so, when validation functions are decided to be disabled by default (around 2005-11?), but I slipped to fix that. Within 6 hours, I will fix it in CVS. Thanks and Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ftvalid
On Thu, 15 Jun 2006 18:22:14 +0900 (JST)
Masatake YAMATO [EMAIL PROTECTED] wrote:
Toshiya-san, could you add following code to ftvalid.c?
status = validator_function();
if ( status = FT_Err_Unimplemented_Feature ) {
fprintf(xx_validator module is not compiled in your libfreetype2);
...
OK, following messages are enough?
Index: src/ftvalid.c
===
RCS file: /cvsroot/freetype/ft2demos/src/ftvalid.c,v
retrieving revision 1.7
diff -u -r1.7 ftvalid.c
--- src/ftvalid.c 25 Feb 2006 22:32:36 - 1.7
+++ src/ftvalid.c 15 Jun 2006 10:36:51 -
@@ -439,7 +439,10 @@
face,
validation_flags,
data[0], data[1], data[2], data[3], data[4] );
-
+
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( FT_OpenType_Validate is disabled, replace FreeType2 with
otvalid-enabled version\n );
+
report_result( data, validation_flags, ot_table_spec, N_OT_TABLE_SPEC );
for ( i = 0; i N_OT_TABLE_SPEC; i++ )
@@ -489,7 +492,10 @@
validation_flags,
data,
N_GX_TABLE_SPEC );
-
+
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( FT_TrueTypeGX_Validate is disabled, replace FreeType2 with
gxvalid-enabled version\n );
+
report_result( data, validation_flags, gx_table_spec, N_GX_TABLE_SPEC );
for ( i = 0; i N_GX_TABLE_SPEC; i++ )
@@ -552,6 +558,8 @@
validation_flags,
data );
+if ( error == FT_Err_Unimplemented_Feature )
+ printf( FT_ClassicKern_Validate is disabled, replace FreeType2 with
gtvalid-enabled version\n );
if ( data )
printf( pass\n );
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] endian issue in ftmac.c
Hi,
2 weeks ago, I received a report from Mr. David Sachitano:
ftmac.c is dependent with system endian and does not
work on Intel Mac. Afterwards, he sent me a patch written
by Mr. Apple Lawrence Coopet (from Apple). His patch uses
CoreFoundation functions to fix endian issue, e.g.
CFSwapInt16BigToHost(). Of course, they are unavailable in
MPW environment, so I replaced them by macro functions.
Attached patch is my modified version.
# I have to apologize. My indepth rewrite of ftmac.c was
# a fix for the legacy functions which are deprecated for
# Intel Mac. But I didn't have Intel Mac at that time and
# slipped to prepair the expected endian issue.
I've tested patched ftmac.c on Intel Mac, and checked
that the outputs by ft2demos' ftoldmac are exactly same
between PowerPC binary (executed via Rosetta emulation)
and Intel native binary. So, I think, the patch is not
perfect solution (some internal data is still stored in
reverse byte-order), but it can work quick fix of endian
issue, for public API. Without the patch, almost functions
of ftmac.c causes SEGV crashes, because its core part
(FOND parser) has endian issue.
However, the coding style of ftmac.c is quite different from
official FreeType2. The patch fixes the endian issue of the
platforms without memory alignments: m68k, PowerPC and x86,
but the type declaration by raw short long should be
removed (although I don't think there is any MacOS on MIPS).
I'm thinking of rewriting ftmac.c to fit the official coding
style of FreeType2. But it spends more time, so I suppose
the quick fix is expected, until the indepth rewrite of ftmac.c.
David, Werner, how do you think of applying the patch to CVS?
Regards,
mpsuzuki
--- freetype2--official-maintrunk--0.2--patch-111/src/base/ftmac.c
2006-06-20 17:09:13.0 +0900
+++ freetype2/src/base/ftmac.c 2006-06-20 17:01:27.0 +0900
@@ -64,6 +64,7 @@
/* This is for Mac OS X. Without redefinition, OS_INLINE */
/* expands to `static inline' which doesn't survive the */
/* -ansi compilation flag of GCC. */
+#undef OS_INLINE
#define OS_INLINE static __inline__
#include Carbon/Carbon.h
#else
@@ -74,6 +75,20 @@
#include TextUtils.h
#endif
+/*
+ * XXX: convertors for byte-order issue on Intel Mac.
+ */
+#if defined( TARGET_RT_LITTLE_ENDIAN ) ( TARGET_RT_LITTLE_ENDIAN 0 )
+#define FT_INT16BE_HOST( s ) \
+ ( ( ( ( s ) 8 ) 0xFF00 ) + ( ( ( s ) 8 ) 0x00FF ) )
+#define FT_INT32BE_HOST( l ) \
+ ( ( ( ( l ) 24 ) 0xFF00 ) + ( ( ( l ) 8 ) 0x00FF ) \
+ + ( ( ( l ) 8 ) 0xFF00 ) + ( ( ( l ) 24 ) 0x00FF ) )
+#else
+#define FT_INT16BE_HOST( s ) ( s )
+#define FT_INT32BE_HOST( l ) ( l )
+#endif
+
#if defined( __MWERKS__ ) !TARGET_RT_MAC_MACHO
#include FSp_fopen.h
#endif
@@ -536,7 +551,7 @@
/* The count is 1 greater than the value in the FOND. */
/* Isn't that cute? :-)*/
-return 1 + *( (short*)( fond_data + sizeof ( FamRec ) ) );
+return FT_INT16BE_HOST( *( (short*)( fond_data + sizeof ( FamRec ) ) ) ) +
1;
}
@@ -549,13 +564,13 @@
fond = (FamRec*)fond_data;
-face_all = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+face_all = FT_INT16BE_HOST( *( (short *)( fond_data + sizeof ( FamRec ) )
) ) + 1;
assoc= (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
face = 0;
for ( i = 0; i face_all; i++ )
{
- if ( 0 == assoc[i].fontSize )
+ if ( 0 == FT_INT16BE_HOST( assoc[i].fontSize ) )
face++;
}
return face;
@@ -597,19 +612,19 @@
/* if the face at this index is not scalable,
fall back to the first one (old behavior) */
- if ( assoc-fontSize == 0 )
+ if ( FT_INT16BE_HOST( assoc-fontSize ) == 0 )
{
*have_sfnt = 1;
-*sfnt_id = assoc-fontID;
+*sfnt_id = FT_INT16BE_HOST( assoc-fontID );
}
else if ( base_assoc-fontSize == 0 )
{
*have_sfnt = 1;
-*sfnt_id = base_assoc-fontID;
+*sfnt_id = FT_INT16BE_HOST( base_assoc-fontID );
}
}
-if ( fond-ffStylOff )
+if ( FT_INT32BE_HOST( fond-ffStylOff ) )
{
unsigned char* p = (unsigned char*)fond_data;
StyleTable* style;
@@ -619,10 +634,10 @@
int i;
- p += fond-ffStylOff;
+ p += FT_INT32BE_HOST( fond-ffStylOff );
style = (StyleTable*)p;
p += sizeof ( StyleTable );
- string_count = *(unsigned short*)(p);
+ string_count = FT_INT16BE_HOST( *(unsigned short*)(p) );
p += sizeof ( short );
for ( i = 0; i string_count i 64; i++ )
@@ -770,13 +785,13 @@
Str255lwfn_file_name;
UInt8 buff[HFS_MAXPATHLEN];
FT_Error err;
+short num_faces;
have_sfnt = have_lwfn = 0;
HLock( fond );
parse_fond( *fond, have_sfnt, sfnt_id, lwfn_file_name, 0 );
-HUnlock( fond );
if ( lwfn_file_name
Re: [ft-devel] endian issue in ftmac.c
Hi, On Tue, 20 Jun 2006 10:36:58 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 2006-06-20 17:54, [EMAIL PROTECTED] said: CFSwapInt16BigToHost(). Of course, they are unavailable in MPW environment, so I replaced them by macro functions. Attached patch is my modified version. You must be the last person on Earth still using MPW. :) Oops :-) True, CFSwapInt16BigToHost is Mac OS X only. But I think you can use the functions in Endian.h on both Mac OS 9 and X. For example: EndianU16_BtoN(). Ah, thank you for notice. I will use them. Have you read the Universal Binary Programming Guidelines? Specifically, this page: https://developer.apple.com/documentation/MacOSX/Conceptual/ universal_binary/universal_binary_tips/chapter_5_section_14.html#// apple_ref/doc/uid/TP40002217-CH239-CJBCCBDD Again thank you for information. The page is helpful. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] endian issue in ftmac.c
Hi,
On Tue, 20 Jun 2006 10:36:58 -0400
Sean McBride [EMAIL PROTECTED] wrote:
True, CFSwapInt16BigToHost is Mac OS X only. But I think you can use
the functions in Endian.h on both Mac OS 9 and X. For example:
EndianU16_BtoN().
Attached is revised version that uses Endian.h macros
suggested by Mr. Sean McBride.
Regards,
mpsuzuki
--- freetype2--official-maintrunk--0.2--patch-111/src/base/ftmac.c
2006-06-20 17:09:13.0 +0900
+++ freetype2/src/base/ftmac.c 2006-06-21 11:45:17.0 +0900
@@ -64,11 +64,13 @@
/* This is for Mac OS X. Without redefinition, OS_INLINE */
/* expands to `static inline' which doesn't survive the */
/* -ansi compilation flag of GCC. */
+#undef OS_INLINE
#define OS_INLINE static __inline__
#include Carbon/Carbon.h
#else
#include Resources.h
#include Fonts.h
+#include Endian.h
#include Errors.h
#include Files.h
#include TextUtils.h
@@ -536,7 +539,7 @@
/* The count is 1 greater than the value in the FOND. */
/* Isn't that cute? :-)*/
-return 1 + *( (short*)( fond_data + sizeof ( FamRec ) ) );
+return EndianS16_BtoN( *( (short*)( fond_data + sizeof ( FamRec ) ) ) ) +
1;
}
@@ -549,13 +552,13 @@
fond = (FamRec*)fond_data;
-face_all = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+face_all = EndianS16_BtoN( *( (short *)( fond_data + sizeof ( FamRec ) ) )
) + 1;
assoc= (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
face = 0;
for ( i = 0; i face_all; i++ )
{
- if ( 0 == assoc[i].fontSize )
+ if ( 0 == EndianS16_BtoN( assoc[i].fontSize ) )
face++;
}
return face;
@@ -597,19 +600,19 @@
/* if the face at this index is not scalable,
fall back to the first one (old behavior) */
- if ( assoc-fontSize == 0 )
+ if ( EndianS16_BtoN( assoc-fontSize ) == 0 )
{
*have_sfnt = 1;
-*sfnt_id = assoc-fontID;
+*sfnt_id = EndianS16_BtoN( assoc-fontID );
}
else if ( base_assoc-fontSize == 0 )
{
*have_sfnt = 1;
-*sfnt_id = base_assoc-fontID;
+*sfnt_id = EndianS16_BtoN( base_assoc-fontID );
}
}
-if ( fond-ffStylOff )
+if ( EndianS32_BtoN( fond-ffStylOff ) )
{
unsigned char* p = (unsigned char*)fond_data;
StyleTable* style;
@@ -619,10 +622,10 @@
int i;
- p += fond-ffStylOff;
+ p += EndianS32_BtoN( fond-ffStylOff );
style = (StyleTable*)p;
p += sizeof ( StyleTable );
- string_count = *(unsigned short*)(p);
+ string_count = EndianS16_BtoN( *(short*)(p) );
p += sizeof ( short );
for ( i = 0; i string_count i 64; i++ )
@@ -770,13 +773,13 @@
Str255lwfn_file_name;
UInt8 buff[HFS_MAXPATHLEN];
FT_Error err;
+short num_faces;
have_sfnt = have_lwfn = 0;
HLock( fond );
parse_fond( *fond, have_sfnt, sfnt_id, lwfn_file_name, 0 );
-HUnlock( fond );
if ( lwfn_file_name[0] )
{
@@ -787,9 +790,12 @@
}
if ( have_lwfn ( !have_sfnt || PREFER_LWFN ) )
- return 1;
+ num_faces = 1;
else
- return count_faces_scalable( *fond );
+ num_faces = count_faces_scalable( *fond );
+
+HUnlock( fond );
+return num_faces;
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] endian issue in ftmac.c
Hi, Werner LEMBERG [EMAIL PROTECTED] wrote: Attached is revised version that uses Endian.h macros suggested by Mr. Sean McBride. If you don't mind I would like to put the responsibility for the Mac OS part into your hands. Neither David (AFAIK) nor me are using a Mac, so please go on! Thank you for steering, just I've committed the quick workaround as temporal fix, now I've started to full byte-order cleaning of ftmac.c. BTW, considering previous posts about ftmac.c's dependency with Carbon framework, I have a few questions about FreeType2 policy. (1) freetype2.pc should include CFLAGS and LDFLAGS for ftmac.c? --- At present, both files don't refrect LDFLAGS in configuration. So, when freetype2 is configured on MacOS X to use ftmac.c with Carbon framework, both of freetype-config and pkg-config return CFLAGS LDFLAGS without options to use ftmac.c. Therefore, when package builders make some MacOS X software which is dependent with FreeType2, they have to be careful whether their prebuilt-FreeType2 is Carbon dependent or Carbon independent. In the case of MacOS X developer community, I think, the number of developers who build ./configure make, as just same with common UNIX, is not negligible. In fact, freetype-config and freetype2.pc are introduced to avoid the manual management of configuration options. I suppose, the reason why freetype-config and freetype2.pc don't include CFLAGS and LDFLAGS is to drop unexpected options like optimization, uninstalled libary linking etc. So, now I'm thinking of import ftmac.c-specific CFLAGS LDFLAGS to freetype-config freetype2.pc. How do you think of? (2) dummy functions for ftmac.c are required? - Considering the binary compatibility when ftmac-enabled FreeType2 is replaced by ftmac-disabled FreeType2 on MacOS X, adding dummy functions returning just FT_Err_Unimplemented is expected to avoid problem by unresolvable symbols? However, rather I hesitate to add new functions even if they are portable dummy. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Urdu Edit Control
Hi On Tue, 27 Jun 2006 17:36:17 -0700 (PDT) Sher Ali Asad [EMAIL PROTECTED] wrote: can anyone help me building an URDU edit control using font library I'm not sure what is URDU edit control you want to build, but I think, FreeType2 does not support OpenType text layout feature to support Arabic script. Although there are some technologies to display Arabic text without OpenType, editing some text is difficult. I recommend you to check Qt (ah, free Qt is only for X11. no Win32, no MacOS), or GTK2 libraries. I think their text widget is already capable to edit Arabic script (although I'm not sure if special features for Urdu is required). Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Apple's bitmap only sfnt format
Hi, On 10 Jul 2006 18:09:01 -0700 George Williams [EMAIL PROTECTED] wrote: Does anyone have a bitmap only sfnt produced by Apple (not one made by fontforge) so I can see what Apple actually does in this case? Apple bundles several bitmap-only sfnt fonts to MacOS (rather, classic MacOS), but it's not permitted to use them on non-Apple-computers. So I report a few examples. As you reported, these font files has no head nor hmtx. Regards, mpsuzuki SaiMinchoTai (for Japanese script) -- bdat offset 0x00bc length 0x0011b663 checkSum 0x6494d911 bhed offset 0x00132b2c length 0x0036 checkSum 0xebc7ca8e bloc offset 0x0011b720 length 0x12f8 checkSum 0x87fefeac cmap offset 0x0011ca18 length 0xbcfe checkSum 0xf3d0f92e evrs offset 0x00128718 length 0x0004 checkSum 0x004e feat offset 0x0012871c length 0x004c checkSum 0x7d0a0928 maxp offset 0x00128768 length 0x0020 checkSum 0x24570012 mort offset 0x00128788 length 0x6528 checkSum 0x4b1046e1 name offset 0x0012ecb0 length 0x032b checkSum 0xd5e6e901 post offset 0x0012efdc length 0x3980 checkSum 0x3d470789 prop offset 0x0013295c length 0x01d0 checkSum 0x25e3876c ChuGothicTai (for Japanese script) -- bdat offset 0x00bc length 0x0011b84b checkSum 0x431ae2f8 bhed offset 0x00132d2c length 0x0036 checkSum 0x1bd0b2f9 bloc offset 0x0011b908 length 0x12f8 checkSum 0x8afe579c cmap offset 0x0011cc00 length 0xbcfe checkSum 0xf3d0f92e evrs offset 0x00128900 length 0x0004 checkSum 0x004e feat offset 0x00128904 length 0x004c checkSum 0x7d0a0928 maxp offset 0x00128950 length 0x0020 checkSum 0x24570012 mort offset 0x00128970 length 0x6528 checkSum 0x4b1046e1 name offset 0x0012ee98 length 0x0344 checkSum 0x5b1786b3 post offset 0x0012f1dc length 0x397e checkSum 0x3d470769 prop offset 0x00132b5c length 0x01d0 checkSum 0x25e4882e Beijing (for Simplified Chinese script) --- EBSC offset 0x001839d0 length 0x0078 checkSum 0x9f3ce3e8 bdat offset 0x00ec length 0x001652a6 checkSum 0x2f03b085 bhed offset 0x00165394 length 0x0036 checkSum 0xbf4a9b28 bloc offset 0x001653cc length 0x11a8 checkSum 0xccbae8fc cmap offset 0x00179904 length 0xa0cc checkSum 0xa4024a73 evrs offset 0x00166574 length 0x0004 checkSum 0x0046 fdsc offset 0x00166578 length 0x0030 checkSum 0x40192b35 feat offset 0x001665a8 length 0x00f8 checkSum 0x80c530da just offset 0x001666a0 length 0x0078 checkSum 0x226b01f4 maxp offset 0x00166718 length 0x0020 checkSum 0x28910011 mort offset 0x00166738 length 0xe8b4 checkSum 0x1b99bdc8 name offset 0x00174fec length 0x05a5 checkSum 0x77f1e915 post offset 0x00175594 length 0x414c checkSum 0x1f0d8148 prop offset 0x001796e0 length 0x0224 checkSum 0x44e466c1 Taipei (for Traditional Chinese script) --- EBSC offset 0x0026a750 length 0x0078 checkSum 0x3b3ce3e8 bdat offset 0x00ec length 0x0024b14b checkSum 0x2df8270e bhed offset 0x0024b238 length 0x0036 checkSum 0xbdfc79e4 bloc offset 0x0024b270 length 0x11a8 checkSum 0xd4d7451d cmap offset 0x0025c764 length 0xdfea checkSum 0x8c830e40 evrs offset 0x0024c418 length 0x0004 checkSum 0x0046 fdsc offset 0x0024c41c length 0x0030 checkSum 0x40192b35 feat offset 0x0024c44c length 0x00a4 checkSum 0x80711c65 just offset 0x0024c4f0 length 0x0078 checkSum 0x374d01f4 maxp offset 0x0024c568 length 0x0020 checkSum 0x3d730011 mort offset 0x0024c588 length 0x9054 checkSum 0x415fa20d name offset 0x002555dc length 0x03e0 checkSum 0x155100a9 post offset 0x002559bc length 0x6b10 checkSum 0x7229e788 prop offset 0x0025c4cc length 0x0298 checkSum 0x20ca9aaf ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Crash because of invalid use of setjmp
Hi, On Mon, 14 Aug 2006 08:27:28 -0700 (PDT) Jens Claudius [EMAIL PROTECTED] wrote: on my system ftvalid crashes when I run it on SIL Charis (get it from http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=CharisSILfont_sc=1). So it seems that we cannot encapsulate setjmp() within a function. Indeed, if I replace the function declaration of ft_validator_run() with a macro like this #define ft_validator_run( valid ) setjmp( (valid)-jump_buffer ) the crash is gone. I would check in this change to CVS, but I_d like to know first why it wasn_t done this way before. Are there compatibility problems with systems that don_t have (working) setjmp/longjmp? Thank you for finding the bug. The original implementation of ft_validator_run was introduced as a part of (PS-)CMap handler (before ftvalid), 2002-03-22 (raw setjmp() was used). http://cvs.savannah.nongnu.org/viewcvs/freetype2/src/base/ftobjs.c?root=freetyper1=1.125r2=1.126 At present, ft_validator_run() is only used by otvalid/gxvalid. Unfortunately, the platforms of ftvalid maintainers (Masatake Yamato and me) are quite limited: Linux/i386 and a few Mac OS X, thus the bug does not appear. Yet I'm not sure of the intention of original author, give me a few weeks. If urgent fix is required, I will write a patch for configure to check ft_validator_run() works well and replace ft_setjmp() if does not work. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Crash because of invalid use of setjmp
Hi Henrik, On Mon, 14 Aug 2006 19:07:44 +0200 (CEST) Unfortunately, the platforms of ftvalid maintainers (Masatake Yamato and me) are quite limited: Linux/i386 and a few Mac OS X, thus the bug does not appear. Yet I'm not sure of the intention of original author, give me a few weeks. If urgent fix is required, I will write a patch for configure to check ft_validator_run() works well and replace ft_setjmp() if does not work. Having ft_validator_run() be a function can not be trusted on any platform. Thank you for info. According to Yamato's post: http://lists.nongnu.org/archive/html/freetype-devel/2005-07/msg8.html I think otvalid was originally designed to use ft_setjmp() and using ft_validator_run() was not essential. Possibly gxvalid is same. I've searched the mailing list archive, but I could not find the discussion about why ft_validator_run() was introduced: possibly David Turner had written it. Anyway, in CVS, I could not find any evidence that this function was used before, always ft_setjmp() was used. So, now I think, replacing ft_validator_run() in otvalid/gxvalid by ft_setjmp() won't be problematic. Yamato-san, how do you think of? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Crash because of invalid use of setjmp
Hi, Sorry for lated fix. Just I've fixed CVS to avoid ft_validator_run(). On Tue, 15 Aug 2006 16:05:00 +0900 (JST) Masatake YAMATO [EMAIL PROTECTED] wrote: If we can replace a FT_BASE_DEF'ed function with a macro without ABI-breaking, I think using Jens's macro: #define ft_validator_run( valid ) setjmp( (valid)-jump_buffer ) is the best. Although I could find no softwares that calls it, ft_validator_run() is published function, so I replaced all calling of ft_validator_run() by ft_setjmp(). I think left ft_validator_run() should be replaced by some warning-only functions. To avoid unexpected crashing, it should not call ft_setjmp(). Jens, how do you think? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] What and where are the fonts that require the unpatented hinter ?
On Sat, 26 Aug 2006 09:33:59 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: Could anyone remind me what these fonts are, and where I could find them for analysis and testing ? I believe that nearly all of them were designed by DynaLabs, but I'm a bit unsure about that. mingli.ttf is one of them (*not* mingliu.ttc). Antoine has a huge collection of old fonts (which he sent me a long time ago and which I can't find right now); maybe he has time to check the CJK fonts. I don't have mingli.ttf, but all of mingliu in my hand have same problem. filenameversion (where I got) MINGLIU.TTF 3.00OfficeXP proofing kit MINGLIU.TTC 3.00OfficeXP proofing kit MINGLIU.TTC 3.21Windows XP SP2 Other DynaLab chinese fonts in my hand have no problem. filenameversion (where I got) DFHEI5A.TTF 3.0 Dynalab TypeX 150 DFSONG3A.TTF3.0 Dynalab TypeX 150 DFFN_B5.TTC 2.0 Dynalab TypeX 150 DFFN_M3.TTC 2.0 Dynalab TypeX 150 Yet I cannot remember any Japanese fonts by Dynalab has such problem. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] What and where are the fonts that require the unpatented hinter ?
Hi, On Tue, 29 Aug 2006 07:30:21 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: As a solution, I suggest that we add a function to FreeType which registers such font names. David? A question from curious: blacklisting by font name is usable for embedded fonts in PDF? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] freetype library performance
Hi, On Thu, 31 Aug 2006 16:06:58 +0300 Ivan Tarapov [EMAIL PROTECTED] wrote: Using built in Linux fonts makes the application work faster. Does anybody have any idea, why such slowdown happens? Maybe there're some tunable parameters in freetype library that can influence this? built in Linux fonts is not clear, I could not understand what you compared with FreeType. What is it? You mean kernel builtin fonts for framebuffer console? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Issue with migration from OSX to freetype based rendering...
Hi, Sorry for your inconvenience. Due to the manpower squeeze of MacOS experts in FreeType developer, I want to decompose the issue into platform-dependent and -independent problems. And I have to apologize for I don't know WebKit at all. On Thu, 31 Aug 2006 17:29:17 +0200 Jean-Charles VERDIE [EMAIL PROTECTED] wrote: Unsurprisingly, the FreeType render block is different from the Quartz one. For the same font, and the same text: the ft rendered block is generally larger than the mac one and sometimes higher too. Excuse me, I'm confused a bit, please let me get myself together. I understand as following: * the reference implementation is WebKit on MacOS X Quartz (only). * the tested implementation is WebKit on Linux X11. * the rendering result onto screen by WebKit-on-Linux-X11 is bigger than that by WebKit-on-OSX-Quartz. If the issue is more generic (e.g. how about on WebKit-on-Win32, if there's such?), please let me know. We tried to hack FreeType to make the two rendering fit. We changed in ftobjs.c the values of 72 dpi and the 64 coefficient in I have 2 questions: * this is not WebKit specific? for example, comarison between text shown by TextEdit.app at specified pointsize and text shown by FreeType2 application on X11/Quartz at same pointsize is enough for testing? * when the output device is not screen, e.g. printing, the scaling coefficient 64 is better than 72? Has anyone already tried to make such a port, or is there any planned effort on making such a compatibility possible ? I suppose there's nobody working for, at present. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] OpenType and Truetype
Hi, On Sat, 2 Sep 2006 17:38:40 +0200 Soeren Muehlbauer [EMAIL PROTECTED] wrote: i have a question depending the embedding of opentype or truetype fronts into postscript/eps. Can i use freetype for this. I really have no idea how font have to be embedded into ps/eps. I don't think bare FreeType is not suitable for your purpose. FreeType is a font renderer, doesn't provide features to convert font formats nor to generate subsetted fonts. I think, using cairo library to generate PS/PDF makes your task easy, because cairo has font subsetting feature, and its API is similar to low level PS command. However, its license LGPL 2.1 or MPL 1.1 is slightly more restricted than FreeType2. I'm writing a converter for emf to eps conversion and want to use unicode characters. I'm unfamiliar indepth of EMF, but I suppose there are only Unicode encoded string and the name of font to display the string in EMF. By unicode characters, you mean the characters which requires complexed text layout system (e.g. Arabic Indic)? If so, FreeType2 does not provide such, you have to choose a text layout library (there are Pango, Qt, ICU and m17n). For the affinity with cairo, pango or m17n might be better. I have read the redbook. I know i have to create a font directory and have to provide the font i want to refer. But in which format i have to write this subfont is a great mistery for me. If someone knows reference or something please let me know. I know no good guidance of PS/PDF font embedding technology, however everybody have to check Adobe Technote 5012: The Type42 Font Format Specification http://partners.adobe.com/public/developer/en/font/5012.Type42_Spec.pdf Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: Preliminary support to CMap files on CID-keyed fonts.
Hi, On Sat, 09 Sep 2006 09:14:56 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: Hidetoshi, three years ago you've sent a preliminary version of your CMap support to the list. Today this is still missing in FreeType. Is there any progress? A few months ago, I discussed with Masatake Yamato about this issue: it should be finished soon (or not)? with Masatake Yamato. I thought, there was a few remarkable changes around the FreeType2 and typographic technology in OSS, after Hidetoshi's proposal. I understand Hidetoshi's work was an intention to emulate TTF-like properties in FT_Face, by builtin charcode-cid conversion with CMap. If I'm misunderstanding, please correct me and discard following text. In following, I note 2 points why I hesitate to start working. Any comments are welcomed. Regards, mpsuzuki -- (1) migration from CJK PS font to OpenType/CFF When Hidetoshi posted his proposal, the popular CJK PS font was CID-keyed PS font which has no interface for character code handling. But, today, most commercial font vendors switched to sell OpenType/CFF as replacement of CID-keyed PS font. Although CID-keyed PS font are still sold, they are for PS printers legacy RIP systems that was not updated for OpenType/CFF. In free fonts, there is fontforge which can convert CID-keyed PS font into OpenType/CFF. So, the requirement for character code features by CMap is being less important, I suppose. What kind of situation that emulation by CID-keyed PS font + CMap works better than real OpenType/CFF? Only for legacy systems? Or, exact handling of legacy encodings like 78-RKSJ-H, 78ms-RKSJ-H, 90ms-RKSJ-H etc etc are required? (2) FreeType2 does not handle OpenType layout In Hidetoshi's post, he noted about GSUB emulation issue. Let me explain again. When we create a TTF-style cmap from CJK PS font by CMap, nothing to say, it cannot store various glyph variations (for Adobe-Japan1, Japanese character code does not specify writing direction, same character code point is used for horizontal vertical forms). Thus, to retain cid for glyph variations, GSUB emulation is required. But FreeType2's FT_FaceRec has no member to convey such information to clients. Pango, Qt and m17n libraries access OpenType tables without FT2, therefore, even if FT2 provides GSUB emulation, such libraries don't use it. Most of glyph variations which should be specified by OpenType extension will be lost. To avoid such inconsistency (FT2 reports a font file as OpenType, but when a client accesses the file, it is CID-keyed font, no OpenType tables, oops), the font file conversion into OpenType/CFF is more simple solution, I suppose. How can we solve this issue? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Re: Preliminary support to CMap files on CID-keyed fonts.
On Sat, 09 Sep 2006 15:16:46 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: A few months ago, I discussed with Masatake Yamato about this issue: it should be finished soon (or not)? with Masatake Yamato. What should be finished? The discussion or the implementation? Sorry, we've discussed how to implement what Hidetoshi wanted to do. I understand Hidetoshi's work was an intention to emulate TTF-like properties in FT_Face, by builtin charcode-cid conversion with CMap. I currently can't remember how his code works. The idea that I have is to load a CID PS font into FreeType, then attach a CMap file to it. This gives proper charcode-glyph conversion. It's not really clear to me what you mean with `TTF-like properties'. Please elaborate. I meant TTF cmap, a few names (family name, style name), and several flags (italic, bold). (1) migration from CJK PS font to OpenType/CFF When Hidetoshi posted his proposal, the popular CJK PS font was CID-keyed PS font which has no interface for character code handling. But, today, most commercial font vendors switched to sell OpenType/CFF as replacement of CID-keyed PS font. Indeed, but I'm quite sure that people who have bought CID-keyed PS fonts won't be able to switch easily. First of all, buying new fonts might be expensive, and secondly, most font licenses forbid modification of fonts. I agree. But I'm not sure what kind of applications they want to use with their CID-keyed PS font, so it's difficult to discuss what kind of support in FT2 is required. I'm not sure if attaching fully-specified CMap to CID-keyed font (a minimum implementation of composefont operator) is what they want. If you receive some concrete request for CMap + CID font support, please let me know. I suppose, Hidetoshi wanted to implement full-featured composefont operation into FT2, but it was too big task. (2) FreeType2 does not handle OpenType layout In Hidetoshi's post, he noted about GSUB emulation issue. Uh, oh, I can't remember at all :-( Please check his TODO list: http://lists.gnu.org/archive/html/freetype-devel/2001-09/msg7.html Let me explain again. When we create a TTF-style cmap from CJK PS font by CMap, nothing to say, it cannot store various glyph variations (for Adobe-Japan1, Japanese character code does not specify writing direction, same character code point is used for horizontal vertical forms). Thus, to retain cid for glyph variations, GSUB emulation is required. ??? I don't understand that. By selecting the proper CMap you automatically get vertical glyph variants, say. Compare, for example, the CMap files `EUC-V' and `EUC-H'. Excuse me, you are thinking of the application which can determine the proper CMap? In such cases, I have no objection. I suppose, Hidetoshi's proposal was for others. As Hidetoshi's TODO item #2, he thought such support was required for the softwares which cannot determine proper CMap name. In summary, please check Hidetoshi's TODO list, and give me comment which item should be solved and which item can be suspended as future issue. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] embedding Carbon dependency info into freetype2.pc freetype-config
Dear Sirs, Since freetype-2.2.1 release, I received several complains from MacOSX developers/users saying as: freetype-2.2.1 links Carbon library (non POSIX, MacOS-specific APIs) by default, but freetype-config/freetype2.pc does not mention whether libfreetype depends on Carbon /or not. To link Carbon library, non-standard option -Xlinker -framework -Xlinker CoreServices ... is added to LDFLAGS. If I could embed this option to freetype2.pc and freetype-config (if libfreetype is configured to use Carbon), the reported problem will be solved. Although I was afraid such non-standard option introduce some confusion, recently I heard that sdl.pc includes such option: -Wl,-framework,Cocoa. So now I think embedding such option is into freetype2.pc and freetype-config (when required) is acceptable. Please let me know how do you think of. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] how to forbid to link public-but-unrecommended function in libfreetype.dylib?
Dear Sirs,
As I've written in previous post, for MacOSX, I want to replace
Carbon-based MacOS font support by Carbon-free implementation.
However, a few functions using MacOS specific legacy datatypes
(like FSSpec which cannot handle long UTF-8 filename) in their
arguments cannot be replaced. When freetype2 is built on modern
MacOSX systems, using such functions is not recommended.
On the other hand, the legacy systems like classic MacOS/m68k
don't know modern datatypes, the functions using legacy datatypes
are essential. (the binary executable format for classic MacOS:
CEF cannot be mixed with Mach-O, thus, different framework for
classic MacOS and MacOSX won't cause serious problem)
Due to this discontinuity, moving all of unrecommended functions
to internal headers (regardless of the system) is not good idea.
Some Unix desktop applications on MacOSX using freetype2 are
growing up bigger and bigger, and runtime testing before release
is insufficient. Thus, runtime warning message is insufficient
to notice unrecommended function is used to the developer.
So, I wish if I could forbid (or disturb) the functions in building
phase of the problematic application. Of course, keeping the function
available for runtime linker is important (to avoid users from
unresolved symbol trouble). There's any standard method to issue
an error in cc1, with meaningful informative message?
I tried a trick in attached patch. Possibly, even if the application
uses unrecommended function, it will include header file which defines
the function's interface. Thus, if I replace the unrecommended
functions by uncompilable macro functions when building procedure
is not for libfreetype, the building procedure of the application
will be interrupted.
Also I insert undeclared variable array, so cc1 will issue an
error including the variable name, so the variable name can be
used to show some message to developer.
However, this trick is very very ugly. There's any better method?
Regards,
mpsuzuki
--- freetype2/include/freetype/ftmac.h
+++ freetype2/include/freetype/ftmac.h
@@ -92,6 +92,11 @@
FT_Face*aface );
+#if !defined(FT2_BUILD_LIBRARY)
+#defineFT_GetFile_From_Mac_Name(a, b, c) {
FT_GetFile_From_Mac_Name_uses_obsolete_FSSpec[]; }
+#defineFT_GetFile_From_Mac_ATS_Name(a, b, c) {
FT_GetFile_From_Mac_ATS_Name_uses_obsolete_FSSpec[]; }
+#defineFT_New_Face_From_FSSpec(a, b, c){
FT_New_Face_From_FSSpec_uses_obsolete_FSSpec[]; }
+#else
/*/
/* */
/* Function*/
@@ -175,6 +180,7 @@
const FSSpec *spec,
FT_Longface_index,
FT_Face *aface );
+#endif
/*/
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)
Dear Sirs, On Thu, 12 Oct 2006 08:15:20 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: However, often I find people doing wrong style as: [...] Don't worry. We just have to document the right way, perhaps in a new file called `INSTALL.CROSS'. I see, I will add freetype2/doc/CROSSDEV.GNU for 8.3 naming convention - at present, cross-building is only for Unix-like systems, such platform specific document is out of 8.3 convention? I think the name INSTALL.CROSS is better and easier to know what it is. I'm unfamiliar with the naming convension in .mk files, so I want comments by David or Werner about the variable names like CCraw_build E_BUILD. Just go on. Thank you, within 48 hours, I will commit my patch and document. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Re: autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)
Dear Werner, On Thu, 12 Oct 2006 16:25:34 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: I see, I will add freetype2/doc/CROSSDEV.GNU for 8.3 naming convention - at present, cross-building is only for Unix-like systems, such platform specific document is out of 8.3 convention? I think the name INSTALL.CROSS is better and easier to know what it is. Well, I think today it is sufficient just to obey that names stripped to 8.3 stay unique. So INSTALL.CROSS is just fine. I see. Following is my manuscript for INSTALL.CROSS, Please give me comment. I thought I should refer some reliable document to guide cross building by GNU autoconf, but I could not hit upon - most of cross-building howto-documents (and automated scripts) are strenuously written from scratch, soon left over, and obsoleted. For a document in freetype2 package, I thought refering nothing is better than refering a document which can be obsoleted in future. Regards, mpsuzuki This document contains instructions on how to cross-build the FreeType library on Unix systems, for example, building binaries for Linux/MIPS on FreeBSD/i386. Before this document, see INSTALL.UNIX for required tools and basic self-building procedure. 1. Required Tools - As self-building on Unix system, GNU Make 3.78.1 or newer is required. INSTALL.UNIX contains how to check the installed `make'. GNU C compiler to cross-build for target system is required. At present, non-GNU cross compiler is not tested. The cross compiler is expected to be installed with system-prefix. For example, when your building system is FreeBSD/i386 and the target system is Linux/MIPS, the cross compiler should be installed with name: mips-ip22-linuxelf-gcc. Also C compiler for self-build is required. Non-GNU self compiler is acceptable, but not tested yet. This is used to build a tool that is executed in building procedure. 2. Configuration 2-1. Building and target system --- To configure for cross-build, the options `--host=system' and `--build=system' must be passed to configure. For example, when your building system is FreeBSD/i386 and the target system is Linux/MIPS, ./configure \ --build=i386-unknown-freebsd \ --host=mips-ip22-linuxelf \ [other options] It should be noted that `--host=system' specifies the system that built binaries are executed, not the system of host to cross-build. In legacy GNU autoconf, the options `--host=' and `--target=' are used, it is broken and obsoleted. Either explicit CC specification like `env CC=mips-ip22-linux-gcc ./configure' or `env CC=/usr/local/mips-ip22-linux/bin/gcc ./configure' do not work, such configuration makes configure confused to find cross and native C compilers. 2-2. Prefix to install FreeType2 Setting `--prefix=prefix' properly is important. The prefix to install FreeType2 is written in freetype-config and freetype2.pc. If the built FreeType2 is used as a part of cross-building system, the prefix is expected to be different from self-building system. For example, configuration with `--prefix=/usr/local' will install unexecutable binaries into system wide `/usr/local', thus it causes a confusion in configuration of the application using FreeType2. Configure to install cross-building system tree (for example, `--prefix=/usr/local/mips-ip22-linux/') is better. On the other hand, if the built FreeType2 is used a part of target system, the prefix to install should reflect file system structure of the target system. 3. Build If the configuration finishes successfuly, invoking GNU make builds FreeType2, like, make or gmake 4. Install -- Invoking GNU make for the target `install', built FreeType2 is directly installed into the directory configured by `--prefix='. As noted in 2-2, sometimes FreeType2 is configured to be installed system directory of the target system, and should not be installed into the cross-building system. In such case, a make variable `DESTDIR' is useful to change the root directory in installation. For example, invoking make with `DESTDIR=' option, like make DESTDIR=/mnt/target_system_root/ install the built FreeType2 files are installed into `/mnt/target_system_root/prefix_in_configure/lib' etc. 5. TODO --- Cross building between Cygwin (or MSys) and Unix must be tested. -- Copyright 2006 by suzuki toshiya David Turner, Robert Wilhelm, and Werner Lemberg. This file is part of the FreeType project
[ft-devel] Re: autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)
Dear Sir, Thank you for improvement and formatting, just I've committed cross-building patch to CVS! Regards, mpsuzuki On Sat, 14 Oct 2006 08:30:38 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: I see. Following is my manuscript for INSTALL.CROSS, Please give me comment. Below is a revised version. Werner == This document contains instructions on how to cross-build the FreeType library on Unix systems, for example, building binaries for Linux/MIPS on FreeBSD/i386. Before reading this document, please consult INSTALL.UNIX for required tools and the basic self-building procedure. 1. Required Tools - For self-building the FreeType library on a Unix system, GNU Make 3.78.1 or newer is required. INSTALL.UNIX contains hints how to check the installed `make'. The GNU C compiler to cross-build the target system is required. At present, using non-GNU cross compiler is not tested. The cross compiler is expected to be installed with a system prefix. For example, if your building system is FreeBSD/i386 and the target system is Linux/MIPS, the cross compiler should be installed with the name `mips-ip22-linuxelf-gcc'. A C compiler for a self-build is required also, to build a tool that is executed during the building procedure. Non-GNU self compilers are acceptable, but such a setup is not tested yet. 2. Configuration 2.1. Building and target system To configure for cross-build, the options `--host=system' and `--build=system' must be passed to configure. For example, if your building system is FreeBSD/i386 and the target system is Linux/MIPS, say ./configure \ --build=i386-unknown-freebsd \ --host=mips-ip22-linuxelf \ [other options] It should be noted that `--host=system' specifies the system where the built binaries will be executed, not the system where the build actually happens. Older versions of GNU autoconf use the option pair `--host=' and `--target='. This is broken and doesn't work. Similarly, an explicit CC specification like env CC=mips-ip22-linux-gcc ./configure or env CC=/usr/local/mips-ip22-linux/bin/gcc ./configure doesn't work either; such a configuration confuses the `configure' script while trying to find the cross and native C compilers. 2.2. The prefix to install FreeType2 Setting `--prefix=prefix' properly is important. The prefix to install FreeType2 is written into the freetype-config script and freetype2.pc configuration file. If the built FreeType 2 library is used as a part of the cross-building system, the prefix is expected to be different from the self-building system. For example, configuration with `--prefix=/usr/local' installs binaries into the system wide `/usr/local' directory which then can't be executed. This causes confusion in configuration of all applications which use FreeType 2. Instead, use a prefix to install the cross-build into a separate systemtree, for example, `--prefix=/usr/local/mips-ip22-linux/'. On the other hand, if the built FreeType2 is used as a part of the target system, the prefix to install should reflect the file system structure of the target system. 3. Building command --- If the configuration finishes successfuly, invoking GNU make builds FreeType2. Just say make or gmake depending on the name the GNU make binary actually has. 4. Installation --- Saying make install as usual to install FreeType2 into the directory tree specified by the argument of the `--prefix' option. As noted in section 2.2, FreeType 2 is sometimes configured to be installed into the system directory of the target system, and should not be installed in the cross-building system. In such cases, the make variable `DESTDIR' is useful to change the root directory in the installation. For example, after make DESTDIR=/mnt/target_system_root/ install the built FreeType2 library files are installed into the directory `/mnt/target_system_root/prefix_in_configure/lib'. 5. TODO --- Cross building between Cygwin (or MSys) and Unix must be tested. -- Copyright 2006 by suzuki toshiya David Turner, Robert Wilhelm, and Werner Lemberg. This file is part of the FreeType project, and may only be used, modified, and distributed under the terms of the FreeType project license, LICENSE.TXT. By continuing to use, modify
Re: [ft-devel] ftconfig.h in LSB
Hi, On Tue, 12 Dec 2006 11:11:27 -0800 Camp, TracyX E [EMAIL PROTECTED] wrote: Are there any cases where (say macros), depend on the defines in ftconfig.h? fttypes.h seems to nicely encapsulate the API/ABI types independantly from ftconfig.h. Bad/Good assumption? 32/64bit issues may arise. Check the discussion on 2005, http://lists.gnu.org/archive/html/freetype-devel/2005-12/msg00014.html Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Mac install instructions don't seem to exist
Hi, On Thu, 21 Dec 2006 16:04:07 -0500 Sean McBride [EMAIL PROTECTED] wrote: generating `configure.ac' running `aclocal -I . --force' aclocal: unrecognized option -- `--force' Try `aclocal --help' for more information. error while running `aclocal -I . --force' The autotools (automake, autoconf) bundled in Xcode are legacy. You have to install newer autotools out of Xcode. I use automake-1.9.6 autoconf-2.59. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] 64 bit build of freetype on Mac OS X, compiler warnings
Hi, On Fri, 22 Dec 2006 15:38:24 -0500 Sean McBride [EMAIL PROTECTED] wrote: I would imagine these warnings would be seen on linux too, has anyone built freetype in 64 bit on linux? I guess you've checked with -Wshorten-64-to-32 that Apple added to their gcc4 diversion. The building on Linux/x86_64 with -Wall don't warn about implicit cast from 64bit long to 32bit int. Thus, most developers using Linux/x86_64 never seen the warning, I suppose. The option -Wconversion of genuine gcc may detect similar casting issues, but it's too strict than Apple's option. I won't have enough time to work this issue until 2007-01-15, sorry. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Mac install instructions don't seem to exist
Hi, I think Turner and Werner gave me comment to proceed the work, thank you. On Mon, 25 Dec 2006 10:29:30 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: At present, configure (not builds/unix/configure) has a hook to ascertain whether make is GNU make /or not. I think, putting detailed version check into configure is the simplest improvement. Yep. This has benefits for other platforms too. Or, the documentation improvement is better? Werner, please let me know your thought. Both. A small `README.Darwin' or something similar doesn't hurt -- it would be sufficient that it contains a pointer to another README file. I see, I will start from the improvement of configure, README.Darwin will be later. In my personal opinion, putting some hooks to check autotools versions into autogen.sh is not bad idea. I don't object, but it doesn't have a high priority for me. Of course, it's task of me who proposed. I will write version checking hooks for autogen.sh, after 2007-01-15. Please wait. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] the font can not be displayed correct
Hi, On Fri, 5 Jan 2007 13:53:51 +0800 DingLi(丁力) [EMAIL PROTECTED] wrote: 1.jpg is incorrect image by the ftview, and the 2.jpg is the correct image. I have known why it can not be displayed correctly. Because the font file is not complete, it lack of several tables for the hint, so It is correct, when I opened the auto hint of the ftview. thank you. I've built vanilla freetype2 on latest CVS, and I could not reproduce 1.jpg. My result is same with 2.jpg. Please describe detail of your ftview. By commenting-out following 2 macros: /* #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER */ /* #define TT_CONFIG_OPTION_UNPATENTED_HINTING */ I disabled bytecode interpreter, but the result is same with 1.jpg. I'm not sure whether your trouble is related with hinting. My analysis of the font file is following, no cmap but not broken. [sfnt] version = 0x00 0x01 0x00 0x00 [sfnt] numTables = 0x0009 tag hmtx offset 0x03d4 length 0x0018 checkSum 0x29018003 tag hhea offset 0x03b0 length 0x0024 checkSum 0xe402 tag maxp offset 0x0408 length 0x0020 checkSum 0xa8026901 tag post offset 0x06ce length 0x0020 checkSum 0x0c00edff tag head offset 0x037a length 0x0036 checkSum 0x1e2560a5 tag loca offset 0x03ec length 0x001c checkSum 0x7004 tag name offset 0x0428 length 0x02a6 checkSum 0x0f152ff3 tag glyf offset 0x00f2 length 0x0288 checkSum 0xa6f7136f tag OS/2 offset 0x009c length 0x0056 checkSum 0xda67ed4c [OS/2] usWeightClass = 0x0190, usWidthClass = 0x0005 [OS/2] fsType = 0x [OS/2] sFamilyClass = 0x [OS/2] panose[2, 1, 6, 0, 3, 1, 1, 1, 1, 1] UnicodeRange: 0 [Basic Latin] UnicodeRange: 49 [Hiragana] UnicodeRange: 50 [Katakana] UnicodeRange: 51 [Bopomofo, Extended Bopomofo] UnicodeRange: 59 [CJK Unified Ideographs, Radicals, Description and Extension A] CodePageRange: 18 [Chinese: Simplified chars--PRC and Singapore] [loca] glyph[0] starts @ 0 [loca] glyph[1] starts @ 0 [loca] glyph[2] starts @ 0 [loca] glyph[3] starts @ 0 [loca] glyph[4] starts @ 270 [loca] glyph[5] starts @ 474 [loca] glyph[6] starts @ 648 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] 2.2.2
Dear Sir, On Mon, 08 Jan 2007 17:23:51 +0100 David Turner [EMAIL PROTECTED] wrote: Expect a releast tag in the CVS tonight or tomorrow. There, I said it !! Sorry for my lated activity about MacOS issues. I couldn't have sufficient time to woek, until 2007-01-15. If acceptable, I want to spend a week to write and commit (2007-01-16 - 23) and another week (2007-01-23 - 30) to wait comments in ft-devel. Is is too late? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
Dear Werner, Sorry for my inactivity during this 4 weeks. On Sat, 13 Jan 2007 09:52:29 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: I think Suzuki-San's changes here may need elaboration. Perhaps just something along the lines of if you use ftmac.c, please note that it is now Mac OS X-only, and that some old APIs now return errors. Thus your code should still build unchanged, but may change in behaviour. I've added this to the CHANGES file, thanks. Please check JPEG picture summarizing the difference from 2.1.10 and 2.2, http://www.gyve.org/mpsuzuki/ft23-history.jpeg http://www.gyve.org/mpsuzuki/ft23-behaviour.jpeg and please review attached patch for documents. I think the important change is only FT_GetFile_From_Mac_Name(). However, appropriate configure option can make fully compatible libfreetype. I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. Regards, mpsuzuki freetype2-macdoc.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft] Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
On Sun, 14 Jan 2007 00:00:42 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: and please review attached patch for documents. Committed (with slight modifications). Please check. I've checked, your modification improves well, thank you. I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. This is fine for me, if it helps to resolve compatibility issues with older FreeType versions. No, FT_GetFileRef_From_Mac_ATSName() won't help the behaviour compatibility issues with older FreeType2 versions, at all. It is a public function for (near-)future Mac OS X missing the functions and data-types that have been announced as deprecated. On such system missing deprecated Carbon function data-types, I cannot provide behaviour-compatible function (of FT_GetFile_xxx), only I can do is providing a function with similar behaviour (FT_GetFileRef_xxx) to help the migration. If adding new symbol in 2.3.0 - 2.3.1 is better than that in 2.2.1 - 2.3.0, I will postpone. # IMHO, FT_GetFileRef_xxx() will be deprecated in long-future. # The incompatible behaviour issues will continue until Carbon- # free Mac font support (that I'm working but long work). # The root of problem was introduced between 2.0.5 and 2.0.6. # http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftmac.c?r1=1.15r2=1.16 Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FreeType 2.3.0 release candidate 1 is available
Excuse me, I cancell my previous post. On Sun, 14 Jan 2007 09:17:18 +0900 [EMAIL PROTECTED] wrote: I was going to add new function FT_GetFileRef_From_Mac_ATSName(). If adding new function in release-candidate phase is acceptable, please let me know. I will do that within 24 hours. This is fine for me, if it helps to resolve compatibility issues with older FreeType versions. No, FT_GetFileRef_From_Mac_ATSName() won't help the behaviour compatibility issues with older FreeType2 versions, at all. # IMHO, FT_GetFileRef_xxx() will be deprecated in long-future. # The incompatible behaviour issues will continue until Carbon- # free Mac font support (that I'm working but long work). Considering the compatibility stability in freetype-2.3.x series, I want to postpone FT_GetFileRef_From_Mac_ATSName(). Considering the direction to remove Carbon dependency, the introduction of API using FSRef (Carbon dependent data type) is not good idea, FT_GetFilePath_From_Mac_ATSName() may be more stable API and it is easy for programmers to replace it by fontconfig library. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Stroke fonts - Stroker
Hi, On Tue, 30 Jan 2007 14:00:33 +0100 Anders Eriksson [EMAIL PROTECTED] wrote: I don't have any knowledge of fonts or FreeType, but I have read about Stroke Fonts, which I think is what I am interested in, and FreeType Glyph Stroker. ftstroke.c of freetype2 is a file collecting functions to compute the borderlines of stroke by given outline bezier curves, not for stroke based font. What I want is that instead of an outline I get one line/single line font, the way it's described here: http://www.colortune.com/ProductsServices/stroke_fonts.aspx I guess various font producers around CJK markets have their own stroke-based font formats, e.g. Wada-laboratory font project collected stroke-based glyph database (but their final product is standard outline font format: PostScript and TrueType), Dynalab has their own stroke based font format. However most of them are closed format, no format specification is disclosed, so FreeType cannot support such kind of closed stroke based fonts. Since we engrave in many languages, not CJK, it would be wonderful if I could use Arial Unicode MS and the automatically create Stroke characters when rendering. I guess you want the stroke vector data (instead of outline vector data) of characters, not the stroke-based font itself - if I'm misunderstanding, please correct. Is this possible, or have I totally misunderstood Stroke Fonts/Characters and Stroker? I think, at least in FreeType, there's no functions to compute stroke vector data by given outline vector data. In fact, it's not easy work to compute the suitable stroke by given outline. I guess you can find more suitable things in bitmap-to-vector softwares, like autotrace. However, I don't know anything recommended for you. I've ever tried to make stroke vector data by hand-written Yi-script, by autotrace, but result was worse than outline vector data. Improvement of the algorithm to determine suitable stroke is required. https://www.codeblog.org/blog/mpsuzuki/20060710.html Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
autotools version check in autogen.sh (Re: [ft-devel] Mac install instructions don't seem to exist)
Dear Sir,
I thank Turner for his quick fix of autogen.sh for Mac OS X's
glibtool issue, on 2007-01-11.
On Fri, 29 Dec 2006 00:57:12 +0900
[EMAIL PROTECTED] wrote:
In my personal opinion, putting some hooks to check autotools
versions into autogen.sh is not bad idea.
I don't object, but it doesn't have a high priority for me.
Of course, it's task of me who proposed. I will write version
checking hooks for autogen.sh, after 2007-01-15. Please wait.
Following is my first manuscript patch to add the version checking
feature to autogen.sh. In addition to basic aclocal/libtoolize/autoconf,
it scans aclocal-1.9, glibtoolize, libtoolize-1.5, autoconf-2.59
for fallbacking.
This is too lengthy for other developers to maintain, possibly
I can reduce to 50% shorter. If more compression is essential,
please let me know.
Regards,
mpsuzuki
--
Index: autogen.sh
===
RCS file: /sources/freetype/freetype2/autogen.sh,v
retrieving revision 1.6
diff -u -r1.6 autogen.sh
--- autogen.sh 12 Jan 2007 09:28:44 - 1.6
+++ autogen.sh 31 Jan 2007 06:43:31 -
@@ -20,6 +20,123 @@
fi
}
+compare_version_number ()
+{
+ r=`( echo $1 ; echo $2 ) | tr ',' ' ' | \
+ awk 'BEGIN{getline;vn=split($0,v, )}\
+ {\
+ for(i=1;i=NF;i++)\
+ {\
+ if(v[i] $i){print no;exit}\
+ if($i v[i]){print yes;exit}\
+ }\
+ if ( length( v[NF + 1] ) 0 ) { print no } \
+ else { print yes } \
+ }'`
+
+ if test x${r} = xyes ; then
+return 0
+ else
+return 1
+ fi
+}
+
+
+check_program_version ()
+{
+ prog_name=$1
+ min_version=$2
+ vendor_keyword=$3
+
+ matched_prog=
+
+ p=
+ for d in `echo ${PATH} | tr ':' ' '`
+ do
+if test -x ${d}/${prog_name} ; then
+ p=${d}/${prog_name}
+ break;
+fi
+ done
+
+ if test x = x${p} ; then
+return 1
+ fi
+
+ echo -n 'Checking version of '${p}' (= '${min_version}')... '
+
+ v=`${p} --version 2/dev/null | head -1`
+ if test x != x${v} ; then
+v=`${p} --version 21 | head -1`
+ fi
+ case `echo ${v} | wc -w` in
+ 0) # cannot extract program version
+;;
+
+ 1) # assumed format: [version]
+echo -n ${v},
+vn=`echo ${v} | sed 's/[^0-9 ][^0-9 ]*/ /g;s/ */,/g;s/\.,//g' `
+vm=`echo ${min_version} | sed 's/\./ /g;s/[^0-9 ]/ /g;s/ */,/g' `
+compare_version_number ${vm} ${vn}
+if test 0 != $? ; then
+ echo too old
+else
+ echo ok
+ matched_prog=${p}
+fi
+;;
+
+ 3) # assumed format: [progname] version [version]
+vn=`echo ${v} | sed 's/^.* //' `
+echo -n ${vn},
+vn=`echo ${vn} | sed 's/[^0-9 ][^0-9 ]*/ /g;s/ */,/g;s/\.,//g' `
+vm=`echo ${min_version} | sed 's/\./ /g;s/[^0-9 ]/ /g;s/ */,/g' `
+compare_version_number ${vm} ${vn}
+if test 0 != $? ; then
+ echo too old
+else
+ echo ok
+ matched_prog=${p}
+fi
+;;
+
+ *) # assumed format: [progname] ([vendor]) [version] [extra-comment]
+v=`echo ${v} | sed 's/ */ /g;s/ /_/g;s/_(/ (/g;s/)_/) /g;s/\.,//g'`
+vn=`echo ${v} | cut -d -f3`
+echo -n ${vn},
+vn=`echo ${vn} | sed 's/[^0-9 ][^0-9 ]*/ /g;s/ */,/g;;s/\.,//g' `
+vm=`echo ${min_version} | sed 's/\./ /g;s/[^0-9 ]/ /g;s/ */,/g' `
+compare_version_number ${vm} ${vn}
+if test 0 != $? ; then
+ echo too old
+else
+ echo ok
+
+ vendor=`echo ${v} | cut -d -f2`
+ if test x != x${vendor} -a x != x${vendor_keyword}; then
+echo -n 'Checking ${p}...'
+case ${vendor} in
+*${vendor_keyword}* )
+ echo ' '${vendor_keyword}' '${prog_name}
+ ;;
+*)
+ echo ' not '${vendor_keyword}' '${prog_name}
+ exit 1
+ ;;
+esac
+ fi
+ matched_prog=${p}
+fi
+;;
+ esac
+
+ if test x != x${matched_prog} ; then
+return 0
+ else
+return 1
+ fi
+}
+
if test ! -f ./builds/unix/configure.raw; then
echo You must be in the same directory as \`autogen.sh'.
echo Bootstrapping doesn't work if srcdir != builddir.
@@ -40,16 +157,50 @@
sed -e s;@VERSION@;$freetype_major$freetype_minor$freetype_patch; \
configure.raw configure.ac
-# On MacOS X, the GNU libtool is named `glibtool'.
-HOSTOS=`uname`
-LIBTOOLIZE=libtoolize
-if test $HOSTOSx = Darwinx; then
- LIBTOOLIZE=glibtoolize
+
+# autotool version check
+for p in aclocal aclocal-1.9
+do
+ if test x = x${ACLOCAL} ; then
+check_program_version $p 1.9.6
+if test 0 = $? ; then
+ ACLOCAL=$p
+fi
+ fi
+done
+if test x = x${ACLOCAL} ; then
+ exit 1
+fi
+
+for p in libtoolize libtoolize-1.5 glibtoolize
+do
+ if test x = x${LIBTOOLIZE} ; then
+check_program_version $p 1.5.22
+if test 0 = $? ; then
+ LIBTOOLIZE=$p
+fi
+ fi
+done
+if test x = x${LIBTOOLIZE} ; then
+ exit 1
+fi
+
+for p in autoconf autoconf-2.59
+do
+ if test x = x${AUTOCONF
Re: [ft-devel] Fix a minor memory leak in ftmac.c
Dear Sir, Thank you, I will apply within 24 hours. Regards, mpsuzuki Jjgod Jiang wrote: Hi, The patch attached fixed a minor memory leak in ftmac.c, just CFStringRef created without release. - jjgod. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] ANSI flag requirement to build freetype2
Dear Sirs, Before a few weeks, I fixed builds/unix/configure.raw to detect ANSI-incompatible macros in header files of Mac OS X Carbon framework and insert workarounds. http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/builds/unix/configure.raw?r1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftmac.c?r1=1.51r2=1.52 http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/builds/mac/ftmac.c?r1=1.1r2=1.2 But the ANSI incompatibility of Carbon headers I could check is only inlining macro (OS_INLINE), and there is possibility that further development can hit another ANSI incompatibility that I've not provided workaround. Thinking of such possibility, omitting ANSI mode CFLAGS can be easier to maintain than insertion of workaround collection (I thank Sean McBride for giving idea). However, my thought comes up from my short experience on Mac OS X header, not tested with wide variety of C compilers. There's anybody who experienced compiling with ANSI C mode generates better results than compiling in default non-ANSI C mode? Turner, have you ever heard of? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Now I'm going to commit your patch to CVS head, but I have small question. Your patch to builds/unix/ftconfig.in will disable Carbon support on 64bit ABI in Intel Mac. It means that the resource-fork based font support (ftmac.c) are unavailable completely. Not only deprecated QuickDraw and FileManager (FSSpec etc) functions, but also ATS and FSRef functions. It is intended design? Regards, mpsuzuki On Tue, 20 Mar 2007 11:24:49 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 3/20/07 9:56 AM, [EMAIL PROTECTED] said: 1) builds/unix/ftconfig.in - minor Mac fix, test against __LP64__ not __ppc64__. There are also 64 bit Intel CPUs. Thank you for notice 64bit API in Intel Mac, yet I don't have that. #if __LP64__ ... #endif might be simpler, how do you think? As David said, I do this to prevent a warning from gcc's -wundef. Apple is inconsistent in their own headers. Sometimes they do #if __LP64__ sometimes they do #ifdef __LP64__. I suspect __LP64__ is either not defined at all, or defined to 1. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Sean McBride wrote: On 3/23/07 7:04 AM, [EMAIL PROTECTED] said: I see. Yet I've not checked 10.4.9, can it run 64bit Intel Mac executables? I think Mac OS X upto 10.4.8 cannot execute 64bit Intel Mac executables. In the other word, the case we have to exclude is building 64bit Intel Mac binary ON 10.4.9, not building 64bit Intel Mac binary FOR 10.4.9 ? 64 bit support is the same for both Intel and PPC. 64 bit support is the same from 10.4.0 to 10.4.9. 64 bit support is the same wether you are 'building on' or 'building for'. Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sir, Sean McBride wrote: On 3/24/07 12:02 AM, [EMAIL PROTECTED] said: I see. Yet I've not checked 10.4.9, can it run 64bit Intel Mac executables? I think Mac OS X upto 10.4.8 cannot execute 64bit Intel Mac executables. In the other word, the case we have to exclude is building 64bit Intel Mac binary ON 10.4.9, not building 64bit Intel Mac binary FOR 10.4.9 ? 64 bit support is the same for both Intel and PPC. 64 bit support is the same from 10.4.0 to 10.4.9. 64 bit support is the same wether you are 'building on' or 'building for'. Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Yes. (Of course, it must be a 64-bit CPU, not all Intel Macs have 64 bit CPUs. The Mac Pro is 64 bit, the Mac Mini is 32 bit.) Maybe this will be helpful: http://www.apple.com/jp/macosx/features/64bit/ Thank you, yet I don't have access to Mac Pro. 64bit-x86 Carbon will be provided in future, and it is possible that ppc64 Carbon is still missing in future. Thus, unified conditional __LP64__ for current status may be disunified in future, aslike #if defined( __ppc64__ ) || \ ( defined( __x86_64__ ) MAC_OS_X_VERSION_MIN_REQUIRED 1050 ) I will rewrite the conditional without unification by __LP64__. Please wait a few days (now I'm in duty-trip without Macintosh). However, I remember configure checks Carbon framework availability, so I wish building FreeType2 on 64bit Intel Mac 10.4.x won't cause such problem. You had problem? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Minor misc patches to freetype cvs, from custom changes in vtk
Dear Sirs, Thank you for correcting my misunderstanding. On Sat, 24 Mar 2007 16:39:43 +0800 Jjgod Jiang [EMAIL PROTECTED] wrote: 2007/3/23, [EMAIL PROTECTED] [EMAIL PROTECTED]: Excuse me, please let me alter the phraseology: Mac OS X 10.4.x on Intel Mac can execute 64bit Intel Mac binary? Yes, I can confirm that, Intel Core 2 Duo (now all upgraded MacBook Pro, MacBook and iMac using) is 64-bit CPU. Xcode Tools support generating x86_64 binaries since version 2.4. On Fri, 23 Mar 2007 15:23:37 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 3/24/07 1:48 AM, [EMAIL PROTECTED] said: it is possible that ppc64 Carbon is still missing in future. No. Apple has already said that 64 bit Carbon will be for both Intel and PPC. See: http://www.apple.com/macosx/leopard/64bit.html Just I've updated ftconfig.in and ftconfig.h (for some building system without running configure) as following: #if ( defined( __APPLE__ ) !defined( DARWIN_NO_CARBON ) ) || \ ( defined( __MWERKS__ ) defined( macintosh )) /* no Carbon frameworks for 64bit 10.4.x */ #include AvailabilityMacros.h #if defined( __LP64__ ) \ ( MAC_OS_X_VERSION_MIN_REQUIRED = MAC_OS_X_VERSION_10_4 ) #define DARWIN_NO_CARBON 1 #else #define FT_MACINTOSH 1 #endif #endif However, I'm not sure whether 10.5.x will set default MAC_OS_X_VERSION_MIN_REQUIRED to 10.5 (system including Carbon) or 10.4 (Carbon-free system). Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Regression] Font doesn't open with Freetype CVS but works with Freetype 2.2.1
Hi, On Sat, 26 May 2007 02:16:54 +0300 On Saturday 26 May 2007 02:13:52 Werner LEMBERG wrote: Hmm, this font doesn't have a `cmap' table, which is invalid according to the OpenType standard, and the behaviour is defined as `implementation specific' in PDF standard (see section 5.5. in the PDF 1.6 specification). I see but lots of real world PDF files have this kind of fonts :-/ I remember, ft-devel list receives several posts per year saying I found an embedded font in PDF that FT2 cannot load, FT2 should load it. It's not always stated which application or library using FT2 to load embedded TrueType data from PDF. In my opinion, embedded font in PDF is NOT self-standing font file. Even if it's forcibly loaded by ignoring essential tables, it is no more than jumping the first hurdle. Without cmap, most character-based API are not usable. One of the next expected hurdle might be we want to convert glyph index to character code, to extract or search a text in PDF. FT2 should do... It is impossible. Such requirement should be supplied by slightly higher level library which can associate the text object, embedded font object, CMap object, ToUnicode object. I think it's far higher than FT2. As a result, the behaviour of current FT2 is reasonable, I think. However, if somebody can define the reasonable subset of FT2 API which is required by most PDF parser, it will be quite helpful for both of FT2 and PDF-related softwares. If you have some idea of subsetted API for embedded font, please let me know. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Regression] Font doesn't open with Freetype CVS but works with Freetype 2.2.1
Dear Sir,
On Sun, 27 May 2007 11:40:27 +0200 (CEST)
Werner LEMBERG [EMAIL PROTECTED] wrote:
In this particular case I think FreeType should do a default action;
this is, a missing `cmap' table should completely disable functions
like FT_Get_Char_Index (by returning either an appropriate error
and/or -1 for the glyph index) but still make FT_Load_Glyph and
friends work as expected.
David, what do you think? Anyone here who would like to implement
this (which should be rather trivial)?
Of course I'm interested in its implementation.
I wish if fallbacked face (loaded without cmap)
can be modified to full featured face by applying
FT_Attach_{File|Stream}.
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A question about freetype and harfbuzz
On Mon, 28 May 2007 13:48:20 +0800 LingNing Zhang [EMAIL PROTECTED] wrote: Hi all, I have a question about freetype and harfbuzz. FreeType1 includes an extension to support OpenType text layout processing. But this support hasn't become part of FreeType2. Why? Why does FreeType2 not use the codes of harfbuzz to support OpenType text layout processing? Thanks! # Personally, I'm one of the people who want FT2 to have # support for text layout feature. I guess I feel sympathy # with you. But we are minority among FT2 developers :-). Excuse me, HarfBuzz developers want FT2 to include built-in OT table parsers? Or, there is non-ICU/ non-HarfBuzz/non-M17NLib/non-Pango/non-Qt library their developers want FT2 to have OT table parser and don't want to copy such from existing libraries? One of the disadvantage might be: if FT2 has OT table parser, the rasterizer in FT2 won't use it at all (because full featured text layout would be too big work to include in FT2). The integrity relationship between FT2 rasterizer and OT support would be confusing. For example, FT2 can parse BASE table, but FT2 does not reflect its content to rasterization is confusing. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Autohinting Indic text and the default script module used by FreeType2
Dear Sir, On Mon, 28 May 2007 17:41:15 +0530 Rahul Bhalerao [EMAIL PROTECTED] wrote: I have been trying to device a module for Indic hinting in FT2. The current default script module used by FT2 is latin which is not suitable for indic text and affects the display significantly. I found out that CJK module is much suitable for Indic text and it renders quality display even at small sizes. I appreciate quite interesting report! To illustrate the above findings, attached is the screenshot showing three different cases of hinted Indic text: 1. hinted indic text using latin module since default script is latin 2. hinted indic text using cjk based indic module and default script as latin 3. hinted indic text using cjk based indic module and default script as cjk/indic Taking a glance on the pictures, the significant difference is found in hangling baseline. By latin module, the position of baseline is varied. By CJK/Indic module, the position is almost constant. If you have more characteristic difference to be focused, please let me know. I guess CJK/Indic module can tune the hanging baseline in Bengali, Gurumkhi and Tibetan scripts well. Although hanging baseline is important feature for Indic script, some Indic scripts have no hanging baseline. Oriya, Telugu and Kannada scripts have some marks to be aligned, so CJK/Indic module might be better, I guess. But I cannot guess about Gujarati, Tamil, Malayalam, Sinhala (and South-East-Asian) scripts. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] A question about freetype and harfbuzz
Dear Sirs, Before all, Werner asked the question that I wanted to ask, thank you very much. On Mon, 28 May 2007 08:42:10 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: # Personally, I'm one of the people who want FT2 to have support for # text layout feature. I guess I feel sympathy with you. But we # are minority among FT2 developers :-). Perhaps a misunderstanding: I don't object to make FreeType handle OpenType tables (see the validating stuff which we have developed together). I'm glad to hear that. In addition, I'm not sure if validating OT-tables only is sufficient. For example, otvalid checks whether the substituted glyph ID by GSUB is within the range declared by maxp. I suppose HarfBuzz lets the handling of too-large glyph ID to the clients. I think it's reasonable because HarfBuzz parses and interprets only OT-tables. But from the client viewpoint, it's slightly inconvenient to check the glyphID by itself, after choosing a font to use. On Mon, 28 May 2007 17:37:03 -0400 Behdad Esfahbod [EMAIL PROTECTED] wrote: There is further work to make HarfBuzz *the* shaper API for Linux systems. That is, again, Pango, Qt, ICU, Scribus, OO.o, etc all will be using HarfBuzz. This has been discussed extensively at the Text Layout Summit in Boston, and discussion is going on on the harfbuzz list and will be at the next Text Layout Summit at aKademy in a few weeks. Pango had already included HarfBuzz (as OpenType parser). I suppose Qt is also moving to adopt HarfBuzz. Although I could find the developers of other softwares (ICU, Scribus, OO.o) in Text Layout Summit 2006, I don't know the status and directions of them. Please let me know more about the migration movement. At present, Text Layout Summit 2007 page: http://www.freedesktop.org/wiki/TextLayout2007?highlight=%28%28HarfBuzz%29%29 has only 1 agenda of HarfBuzz. On Mon, 28 May 2007 18:05:19 -0400 Behdad Esfahbod [EMAIL PROTECTED] wrote: On Mon, 2007-05-28 at 23:48 +0200, Werner LEMBERG wrote: [...] I believe that any OpenType Layout engine should do its own validation, Why? What is bad about letting FreeType doing that? Afterwards you can omit any error handling... For one thing, FreeType is not necessarily available. We are removing FreeType dependency from HarfBuzz, and Qt wants to use HarfBuzz on Windows too. I think it's slightly different issue, because FT2 does work on Windows. I suppose Qt wants to use Windows native rasterizer instead of FT2, but Qt wants to use HarfBuzz shaping engine? Using OTLS is difficult? The other reason is that, for example, HarfBuzz is forgiving about some problems. A nonexistent lookup index for example is automatically ignored. Or a subtable that is not ever referenced can have an (invalid) offset of zero and it will still work. These kind of exceptions were added to make fonts that already worked with Windows work with Pango too. Hmm, the severity of ftvalid is controlled by validation level, although the fine tuning of default level for otvalid is not finished. Considering the fact most Open Type layout engine follows the behaviour of OTLS (to share existing OpenType font resources), I think it's not disadvantage of layout-engine-independent validation approach, like ftvalid. Rather, I think the OT-table validation in HarfBuzz will be one side of its runtime failsafe mechanism. I remember what I wrote 2 years ago: http://lists.gnu.org/archive/html/freetype-devel/2005-11/msg00084.html Another reason is that: if the text layout engine includes its own validator, it will be runtime checking to avoid from wrong behaviour and crashing, and won't validate unaccessed parts. It's not easy to use text layout functions to crawl all features declared in the OpenType/TrueTypeGX. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Two very minor freetype patch suggestions
Dear Sir, Thank you for sending new patches for ftmac.c, I will check them within 1 weeks. Please wait. On Fri, 1 Jun 2007 11:50:53 -0400 Sean McBride [EMAIL PROTECTED] wrote: 2) HLock() and HUnlock() are nop's (and deprecated) on OS X (See MacMemory.h) and as ftmac.c is now OS X-only, they can be removed. 3) other misc warnings fixed in ftmac.c Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Two very minor freetype patch suggestions
Dear Sir,
On Sat, 2 Jun 2007 01:18:07 +0900
[EMAIL PROTECTED] wrote:
Thank you for sending new patches for ftmac.c,
I will check them within 1 weeks. Please wait.
Sorry for lated reply. I have 2 questions.
--- src/base/ftmac.c 2007-06-11 18:34:19.0 +0900
+++ ../ftmac.c 2007-06-11 18:28:51.0 +0900
@@ -105,6 +105,10 @@
FSSpec* pathSpec,
FT_Long* face_index )
{
+(void)fontName;
+(void)pathSpec;
+(void)face_index;
+
return FT_Err_Unimplemented_Feature;
}
I think these declarations are introduced to avoid
compilers warning against unused arguments. FreeType2
has macros for such purpose: FT_UNUSED(). So I rewrote
these parts as
+FT_UNUSED( fontName );
+FT_UNUSED( pathSpec );
+FT_UNUSED( face_index );
If I'm misunderstanding, please let me know.
@@ -466,13 +481,14 @@
NULL, NULL, NULL, par_ref ) )
return FT_Err_Invalid_Argument;
+/* This gives a path in POSIX format */
if ( noErr != FSRefMakePath( par_ref, path_lwfn, path_size ) )
return FT_Err_Invalid_Argument;
if ( ft_strlen( (char *)path_lwfn ) + 1 + base_lwfn[0] path_size )
return FT_Err_Invalid_Argument;
-/* now we have absolute dirname in lookup_path */
+/* now we have absolute dirname in path_lwfn */
if ( path_lwfn[0] == '/' )
ft_strcat( (char *)path_lwfn, / );
else
According to Apple TN #2078, as you wrote,
FSRefMakePath() is primarily introduced to
get POSIX + UTF8 pathname from FSRef. But
the technote mentions about the possibility
of FSRefMakePath() returns HFS ptahname.
If we restrict the scope to Mac OS X,
FSRefMakePath() always returns POSIX + UTF8
pathname delimited by / ? If so, the code
checking the delimiter (/ or :) can be
removed.
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] cross-compile configure error (patch)
Dear Sir,
Great Thank you for checking the cross compiling feature of
freetype2, I'm the author of the part you fixed.
On Fri, 10 Aug 2007 18:38:21 -0600
Ryan Hill [EMAIL PROTECTED] wrote:
When cross-compiling freetype, when the build compiler executable ends
in -gcc and CC_BUILD is not set in the environment, configure will
fail to find the native compiler and die. The attached patch sets
CC_BUILD to ${build}-gcc rather than ${build-gcc}.
Sorry, ${build-gcc} is completely my mistake, it should
be ${build}-gcc. I will commit your fix within 24 hours,
please wait.
I've seen a similar patch in some embedded-centric distros, so this may
have been reported before. Is this the correct fix?
Your fix is correct, but I think yet I don't receive the
bug report about this (if somebody reported and I overlooked
it, I'm very sorry). I was thinking that cross building
feature of freetype-2.2.x and later is not used popularly,
because there are too many legacy programs using freetype
internal headers which cannot build with freetype-2.2.x
and later don't install.
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux)
Hi,
Recently David Turner proposed to use dlsym()-type features for
ftmac.c to solve the incompatibilities of libfreetype.dylib
with ftmac.c and without ftmac.c, in freetype mailing list.
As a proof of his idea, I wrote a sample header file ftmacdyn.h
to replace Carbon-derived functions in ftmac.c by the function
pointers. By including ftmacdyn.h, ftmac.c is changed to resolve
the Carbon functions in runtime, without writing the code but
insersion a few initialization routines. libfreetype.dylib has
no explicit symbol reference to Carbon frameworks.
I want to discuss with developers importing Unix applications
to Mac OS X, about the idea using such hook to remove the
explicit symbol reference of Mac OS specific frameworks.
--
I think it's sufficient as a draft for further discussion,
but attached ftmacdyn.h is NOT finished work, there are several
issues:
* CPP feature: Current ftmacdyn.h uses C99 preprocessor macros
(to handle variadic arguments). They are incompatible with
-ansi option. The legacy C compiler of Mac OS X 10.0 (using
precompiled header by default) cannot process it by default.
* Softening of compiler's inspection: The types of function
pointers are declared by ftmacdyn.h, not by the system.
The mismatching between ftmacdyn.h and system cannot be
checked. Either the deprecated functions cannot be found.
* Maintainancability: If a developer inserts ftmac.c new Carbon
functions, he has to update ftmacdyn.h: declaration of function
pointer types, allocation of function pointer, and initialization
of function pointer. It's troublesome. If he slipped to update
ftmacdyn.h, he will receive unexpected error in both phases of
compilation of libfreetype.dylib and linking built libfreetype
with other applications.
I think these issues must be solved by auto generation of
ftmacdyn.h. It's not difficult to generate ftmacdyn.h if we
have the list of required Carbon functions. The compilation
of ftmac.c (without ftmacdyn.h) is convenient to obtain the
list and check type mismatching issues, but repeating
compile ftmac.c, generate ftmacdyn.h, recompile ftmac.c is
not smart, even if it's automatic.
Regards,
mpsuzuki
On Fri, 21 Sep 2007 17:31:35 +0900
[EMAIL PROTECTED] wrote:
On Fri, 21 Sep 2007 00:32:35 +0200
David Turner [EMAIL PROTECTED] wrote:
the traditional, and painful, way to deal with this sort of problems
in a seamless way (at least for the user) is to use dlopen()-style dynamic
linking to access the missing Carbon functions.
do you think it'd be possible to add this to FreeType, to get rid of the
--with-old-mac-fonts and related issues ?
I think it's possible.
I know it's non trivial work, but that would be the right thing to do.
Although I've proposed a replacement by Carbon-free MacOS
font support, I have to agree this pointing out. ftmac.c
provides a few functions that cannot be implemented without
QuickDraw or ATS (getting a font file from QuickDraw/ATS
font name), runtime resolving of Carbon dependency is required
to provide these functions safely.
The expected procedure would be:
step 1: check whether runtime linker has already loaded
Carbon framework (even if the application developer
doesn't care Carbon-dependent feature of FreeType,
some applications load Carbon framework for other
purpose, e.g. to use native GUI library etc).
step 2: if Carbon framework is not loaded, try to load it.
if could not load, returniappropriate error.
step 3: if Carbon framework is loaded, try to resolve
required Carbon-dependent symbols. If could not
resolve, return appropriate error.
In last year, I've written testing code for step 3 during
the discussion about how to deprecate the legacy Carbon
functions.
The headache is, step 1 + 2 are expected to be implemented
without non-standard frameworks, to avoid unexpected dependency.
If the softwares are built only with POSIX APIs, the binaries
are linked with libSystem.B.dylib only. The external libraries
(e.g. libdl.dylib or CoreFoundation framework) should not be
used even if they provide convenient functions.
The latest libSystem.B.dylib on Mac OS X 10.4 includes dlsym(),
but older libSystem.B.dylib on Mac OS X 10.{0, 1} doesn't.
In such old systems, NSIsSymbolNameDefined() may be used for,
but they are deprecated :-( I have to think over smart
implementation after the investigation of function availabilities
on each Mac OS X revisions. Anyway, I will write small code
to demonstrate on specific platform within 1 month, please wait.
Regards,
mpsuzuki
Index: src/base/ftmac.c
===
RCS file: /sources/freetype/freetype2/src/base/ftmac.c,v
retrieving revision 1.59
diff -u -r1.59 ftmac.c
--- src/base/ftmac.c29 Aug 2007 06:08:59 - 1.59
+++ src/base/ftmac.c22 Sep 2007 08:30:21 -
@@ -91,6 +95,8 @@
#undef FT_GetFile_From_Mac_ATS_Name( a, b, c )
#undef FT_New_Face_From_FSSpec( a, b, c
Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux)
Hi, On Wed, 26 Sep 2007 10:39:56 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 9/22/07 6:32 PM, [EMAIL PROTECTED] said: Recently David Turner proposed to use dlsym()-type features for ftmac.c to solve the incompatibilities of libfreetype.dylib with ftmac.c and without ftmac.c, in freetype mailing list. I guess I missed this discussion... what date was the first post? Please check a thread from this post: http://lists.gnu.org/archive/html/freetype/2007-09/msg00016.html I will answer following parts in later. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Hide Carbon-dependency of ftmac.c ([ft] cannot open some fonts on mac and linux)
Hi, # I dropped freetype list because this post is already too specific # for developers. On Wed, 26 Sep 2007 10:39:56 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 9/22/07 6:32 PM, [EMAIL PROTECTED] said: As a proof of his idea, I wrote a sample header file ftmacdyn.h to replace Carbon-derived functions in ftmac.c by the function pointers. By including ftmacdyn.h, ftmac.c is changed to resolve the Carbon functions in runtime, without writing the code but insersion a few initialization routines. libfreetype.dylib has no explicit symbol reference to Carbon frameworks. I want to discuss with developers importing Unix applications to Mac OS X, about the idea using such hook to remove the explicit symbol reference of Mac OS specific frameworks. I don't understand what problem this is trying to solve. Can someone summarise? I can understand that some developers may not want to bring in Carbon dependency, but freetype already has a switch to turn off all the Carbon functions, is it not sufficient? Yes, the background of the proposal takes the configuration switch is insufficient. By the switch, there are 2 incompatible libfreetype.dylib on Mac OS X: (a) without Carbon (b) with Carbon. It seems that (b) is a superset of (a) and no confusion... it's misunderstanding. If (b) is introduced into the system based on (a), new dependency of Carbon framework makes the linker confused. If the developer correctly replace freetype-config and libfreetype.la correctly, the new dependency is reflected automatically. But there are many softwares and developers don't use them, they try to link -lfreetype only. The patch is designed to hide the dependency of Carbon from the eye of linker, not to make FreeType2 independent with Carbon. But here are my thoughts anyway... - even with your changes, Carbon.h must still be included (for structure type definitions, etc.) Yes, my patch is not designed to hide the Carbon dependency from the eye of cpp/cc1. But your pointing out is important, to keep the compatibility of public header files. I have to reconsider. - although you don't call Carbon functions explicitly, the code is still Mac-only Yes, my patch is not designed to make libfreetype independent with Carbon. - the code is much less readable and much less maintainable. Yes, I agree, as I wrote in the post, I don't think the developer of FreeType2 can maintain ftmacdyn.h manually. I have to write automating system to generate it. BTW, you want ftmacdyn.h to be easier for FreeType2 users (who use FreeType2 as a component of their softwares)? One of my anxiety is ftmacdyn.h is ugly hack by cpp, and if there's incompatibility between ftmacdyn.h versus ftmac.c, the error messages generated by cpp would be very very difficult to understand. - the code uses private symbols (ex: ApplicationServicesVersionNumber) OK, this must be fixed immediately. * CPP feature: Current ftmacdyn.h uses C99 preprocessor macros (to handle variadic arguments). They are incompatible with -ansi option. The legacy C compiler of Mac OS X 10.0 (using precompiled header by default) cannot process it by default. _Nobody_ uses 10.0! 10.0 cannot play DVDs, 10.0 cannot burn CDs. It was essentially a beta OS. I strongly suggest that you target 10.2 as a minimum. At their summer 2007 WWDC conference, Apple stated that 67% of the 22 million active Mac OS X users are using 10.4, 23% are using 10.3, and 10% are using 10.2 or older. Ah, I think the generator of ftmacdyn.h should not include variadic arguments, because it's incompatible with -ansi (it's generally expected compiler option of FreeType2) primarily. The difficulty for Mac OS X 10.0 compiler is the second reason. Sorry for confusing you. -- Anyway, thank you for comment, I have to propose ftmacdyn.h generator and I will ask if it's easy for developers. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)
Hi, On Sun, 30 Sep 2007 21:13:00 +0900 Dmitry Timoshkov [EMAIL PROTECTED] wrote: http://bugs.winehq.org/show_bug.cgi?id=9840 has a ttf font attached to it which can be perfectly displayed in Windows, but Wine is not able to actually show any character using this font, only 'c' is displayed. Thank you for providing the sample font. It seems that the first cmap (platformID, platformSpecificID) = (0, 0) = (Unicode, Default Semantics) is not broken, but designed to ignore most of glyph. Its contents is like this: [cmap]format = 4, length=0x007a, languageID=0x(unknown) startCode=0x0022, endCode=0x0022, idDelta=0x0036, idRangeOffset=0x startCode=0x0026, endCode=0x0027, idDelta=0x, idRangeOffset=0x0012 startCode=0x002c, endCode=0x002c, idDelta=0x0025, idRangeOffset=0x startCode=0x002e, endCode=0x002f, idDelta=0x, idRangeOffset=0x0012 startCode=0x003b, endCode=0x003c, idDelta=0x, idRangeOffset=0x0014 startCode=0x003e, endCode=0x003e, idDelta=0x0021, idRangeOffset=0x startCode=0x005b, endCode=0x005d, idDelta=0x, idRangeOffset=0x0014 startCode=0x0060, endCode=0x0060, idDelta=0xfff5, idRangeOffset=0x startCode=0x007b, endCode=0x007e, idDelta=0x, idRangeOffset=0x0016 startCode=0x, endCode=0x, idDelta=0x0001, idRangeOffset=0x subtable0 cmap fmt4 : code 0x0022 - gid 0x0058(88) glyfLength=22 subtable0 cmap fmt4 : code 0x0026 - gid 0x0053(83 = 83 + 0) glyfLength=0 subtable0 cmap fmt4 : code 0x0027 - gid 0x0052(82 = 82 + 0) glyfLength=18 subtable0 cmap fmt4 : code 0x002c - gid 0x0051(81) glyfLength=20 subtable0 cmap fmt4 : code 0x002e - gid 0x0054(84 = 84 + 0) glyfLength=14 subtable0 cmap fmt4 : code 0x002f - gid 0x0056(86 = 86 + 0) glyfLength=16 subtable0 cmap fmt4 : code 0x003b - gid 0x0061(97 = 97 + 0) glyfLength=24 subtable0 cmap fmt4 : code 0x003c - gid 0x0060(96 = 96 + 0) glyfLength=22 subtable0 cmap fmt4 : code 0x003e - gid 0x005f(95) glyfLength=22 subtable0 cmap fmt4 : code 0x005b - gid 0x0059(89 = 89 + 0) glyfLength=20 subtable0 cmap fmt4 : code 0x005c - gid 0x0057(87 = 87 + 0) glyfLength=16 subtable0 cmap fmt4 : code 0x005d - gid 0x005a(90 = 90 + 0) glyfLength=20 subtable0 cmap fmt4 : code 0x0060 - gid 0x0055(85) glyfLength=14 subtable0 cmap fmt4 : code 0x007b - gid 0x005e(94 = 94 + 0) glyfLength=52 subtable0 cmap fmt4 : code 0x007c - gid 0x005d(93 = 93 + 0) glyfLength=14 subtable0 cmap fmt4 : code 0x007d - gid 0x005c(92 = 92 + 0) glyfLength=52 subtable0 cmap fmt4 : code 0x007e - gid 0x005b(91 = 91 + 0) glyfLength=0 subtable0 cmap fmt4 : code 0x - gid 0x(0) glyfLength=0 In HUDfont.ttf, most alphabets have glyphIndex 81, so this cmap cannot access them. One of the problem is that the cmap is NOT broken in the viewpoint of the data structure, so non-intellectual validator (that does not compare the coverage of accessible glyph and the coverage of included glyph) cannot refuse it. Your patch assumes that Apple Unicode cmap is often broken but others are more reliable, but I'm afraid that this is not generic assumption. That's because Freetype selects first unicode cmap table which happens to be with platform id 0 (Apple Unicode), and that cmap table is incomplete (or truncated). cmap tables for other platforms (1 and 3) are good, and making Freetype ignore cmap with platform id 0 makes the font display properly in Wine's notepad. Attached is the hack that makes Freetype ignore cmaps with platform id 0. What Freetype developers think about this problem? Excuse me, do you think the selection of best cmap is the role of FreeType? I think, FreeType2 provides an API for users to select cmap subtable by the pair of platformID platform-specificID. http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html I think, it's better for Wine to have internal priorities of prefered cmap and try to load from the best to the worst. For example, thinking about UCS-4 capable fonts (like SURSONG.TTF or SIMSUN-EXTB.TTF). Such fonts have cmap subtables for Microsoft UCS2, and Microsoft UCS4. Usually Microsoft UCS4 cmap subtable appears after MS UCS2 cmap subtable. So, if we let FreeType to choose the cmap subtable automatically, we cannot reach Microsoft UCS4 cmap subtable, even if we ignore Apple Unicode. From the viewpoint of compatibility with Microsoft products, it's not good idea. So, I think, it's better for Wine to have internal priorities of prefered cmap subatble and choose the best cmap subatble by himself. How do you think of? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)
Dear Sir, On Mon, 1 Oct 2007 11:52:19 +0900 Dmitry Timoshkov [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: So, I think, it's better for Wine to have internal priorities of prefered cmap subatble and choose the best cmap subatble by himself. How do you think of? Wine uses FT_Select_Charmap API to select either FT_ENCODING_UNICODE, FT_ENCODING_MS_SYMBOL or FT_ENCODING_APPLE_ROMAN when appropriate. So that's actually Freetype's responsibility to choose the best/correct/ working charmap table in that case. I see, I was misunderstanding. Now I think your report says that FT_ENCODING_UNICODE is too rough to choose the best cmap subtable for Unicode encoding. I guess, if you can specify Microsoft platform and UCS2 or UCS4 encoding cmap subtable explicitly, it serves your purpose. Am I understanding correctly? I think it's reasonable request. Yes, Wine can arrange some kind of cmap priorites, what if some of preferred cmap tables is broken? How an application can decide which cmap table is better without digging into internal cmap data? Shouldn't that be a responsibility of Freetype to ignore incomplete/broken cmaps, especially since it already parses cmap tables and can easily decide which one is better? As I've shown in previous post, Apple Unicode cmap in the sample font is NOT broken from the viewpoint of data structure, I think. To detect broken cmap as you say, it's required to investigate cmap, loca, glyf subtables content semantically. After checking the all cmap, loca, glyf subtables, the best cmap subtable would be chosen. I'm not against the fact that such feature is convenient, but I'm questionable if it should be built-in feature of FreeType and should be enabled by default. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Incomplete cmap table for platform 0 (Apple Unicode)
Dear Sir, On Mon, 01 Oct 2007 09:39:06 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: Following is a function whose API is similar to FT_Select_Charmap() but ignores non-Microsoft cmap subtables. Does it serve your purpose? I think my quick fixes already serves Dmitry's purposes. Your special code is thus not necessary (and honestly, I don't think we should add such a function). Ah, I was not going to propose the function to FreeType tree. It was just an external workaround for FreeType before your quick fix. Sorry for confusing you. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] About the Cmap format 12
Hi, On Mon, 01 Oct 2007 00:22:41 +0200 (CEST) Werner LEMBERG [EMAIL PROTECTED] wrote: I found that FreeType can not get the correct glyph index from the font Simsun-extb corroding the Unicode of the character. Using version 0.90 of this font, I see no problems with `ftview -e unic'. However, this font version's `post' table is buggy; it misses all indices 0x7FFF into the glyph name string array, thus FreeType displays `.notdef' instead of the correct glyph name for Unicode characters = U+27EFC. Yet I've not checked the contents of post table, but my experiment on version 5.00 (MD5 is following), with freetype-2.3.5 is same with Werner. 417a85ff314928adc67e51bb1b458f04 simsunb.ttf I could not reproduce the bug Ding Li reported. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Japenese OTF font with funny encoding
Hi, Werner had already given the answer, but it's a pity for japanese macintosh user to say nothing. I don't have exactly same font with Deron, but I've bought several TrueType and ATM font packages from Dynalab. I want to add 2 supplementary comments. 1) Some Dynalab font has problematic cmap for Shift-JIS. If you have Osaka font on Mac OS X, ftdump will list 3 cmaps: Unicode, Roman, and Shift-JIS. There's no problem. But, some Japanese fonts from Dynalab, ftdump won't list Shift-JIS cmap, in some cases. This is because Dynalab's TTF often includes problematic cmap for Shift-JIS. FreeType2 ignores it. 2) Shift-JIS variants on MacOS At least, there were 2 kinds of Shift-JIS variants on Japanese Macintosh. One was designed for KanjiTalk 6 (MacOS 6) and another was designed for KanjiTalk 7 (MacOS 7). I think there's no official method to distinguish them. I guess if PostScript name of the font finishes with 83pv-RKSJ-H, it's supposed to be Shift-JIS for KT6, and if it finishes with 90pv-RKSJ-H, it's supposed to be Shift-JIS for KT7. However, there are Japanese fonts without such extensions (e.g. Apple's Osaka). Regards, mpsuzuki On Tue, 01 Jan 2008 11:00:07 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: For ftface-charmaps[1] encoding=0(!!) platform=1 encoding_id=1 (iterating using FT_Get_First/Next_Char yeilds 8589 chars). Hmm, PID/EID 1,1 is Japanese on a Mac, so FreeType is correct in saying that encoding = FT_ENCODING_NONE because it doesn't contain mapping tables. This font works with OS X applications, so I wonder how do I determine what the encoding is for 0 in this case? Value `0' means that FreeType can't handle it, not that it is an unknown encoding! You have to use other means handle the encoding, for example, looking at the PID/EID pair directly. The charcodes that FT_Get_First/Next_Char yields ranges from 0-128, 33088-40956 and 57408-60924. Looking at the characters, it _looks_ like they are Shift-JIS encoded. Yes. I'm quite sure that Japanese for older Macs is always encoded in SJIS. However, you should look up the Mac documentation to verify this. How would I determine that programatically using FreeType? You can't. Second, can I supply a synthetic charmap somehow to synthesis a Unicode table, or do I need to convert my Unicode to Shift-JIS and just use the existing charmap? The latter. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel -- 鈴木 ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Dynalab SJIS cmap (Re: Japenese OTF font with funny encoding)
Hi, On Tue, 01 Jan 2008 11:16:57 -0700 Deron Kazmaier [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: 1) Some Dynalab font has problematic cmap for Shift-JIS. If you have Osaka font on Mac OS X, ftdump will list 3 cmaps: Unicode, Roman, and Shift-JIS. There's no problem. But, some Japanese fonts from Dynalab, ftdump won't list Shift-JIS cmap, in some cases. This is because Dynalab's TTF often includes problematic cmap for Shift-JIS. FreeType2 ignores it. Do you know what the fonts are so I can get one to test? Do those fonts still list a Unicode cmap? I bought DynaFont Type Studio TrueType for Macintosh including 50 japanese TrueType fonts which was released on 2001-Sept. Sorry, this product is already obsolete. http://www.dynacw.co.jp/dynafont/archive/03mac.html All of them have Roman and Shift-JIS cmap only (no Unicode cmap), and FreeType2 recognizes all (!) MacOS Shift-JIS cmaps are broken. Here's the list of PostScript font names and their versions. DFBunChoMin-W2-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFBunChoMin-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFDanKaiSho-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnKai-W10-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnKai-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnKai-W8-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGyoKaiSho-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFGyoSho-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGyoSho-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGothicP-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKKaiShoA-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKKaiShoB-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKKaiShoC-W7-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKaiSho-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKaiSho-W9-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFMinchoP-W3-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W7-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuPop-W9-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFKakuTaiHi-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFKanTeiRyu-W11-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKanTeiRyu-W6-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFGanKaiSho-W9-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFKiSouKyu-W5-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFHGKaiSho-W3-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFGaGei-W6-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFPOPMix-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPOPMix-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPOPMix-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFLeiGaSo-W5-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFLeiGaSo-W7-90pv-RKSJ-H,20 Aug 2001 Version 2.00 DFYuGaSo-W3-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFYuGaSo-W5-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFYuGaSo-W7-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFEnEnA-W2-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnA-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnB-W2-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFEnEnB-W4-90pv-RKSJ-H, 1 Aug 1999 Version 2.00 DFHorrorA-W3-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorA-W5-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorB-W3-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFHorrorB-W5-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFPenJi-W2-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFPenJi-W4-90pv-RKSJ-H, 20 Aug 2001 Version 2.00 DFRenRenA-W2-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenA-W4-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenB-W2-90pv-RKSJ-H,1 Aug 1999 Version 2.00 DFRenRenB-W4-90pv-RKSJ-H,1 Aug 1999 Version 2.00 Also I've checked fonts bundled to MS Office v.X for Mac. There are 3 Dynalab fonts which has only Roman and Shift-JIS cmap (without Unicode cmap, again). FreeType2 recognizes all Shift-JIS cmap as broken. DFPKaiSho-Md-MP-RKSJ-H, 1 Apr 1997 Version 2.10 DFPMaruGothic-SB-MP-RKSJ-H, 1 Sep 1997 Version 2.00 DFPSNGyoSho-W5-MP-RKSJ-H, 28 Feb 1997 Version 2.10 Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Dynalab SJIS cmap
Hi, On Wed, 02 Jan 2008 09:20:37 +0100 (CET) Werner LEMBERG [EMAIL PROTECTED] wrote: I bought DynaFont Type Studio TrueType for Macintosh including 50 japanese TrueType fonts which was released on 2001-Sept. [...] All of them have Roman and Shift-JIS cmap only (no Unicode cmap), and FreeType2 recognizes all (!) MacOS Shift-JIS cmaps are broken. Hmm. If so many fonts are broken, it's probably worth to add a hack to FreeType's cmap support so that they can be successfully handled. What do you think? Can you investigate? Yes, of course. Now I'm investigating the problem. I guess there might be existing hacks for Dynalab fonts since freetype-1 era. If anybody knows recommended patches, please let me know. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
