Re: [ft-devel] Question on Freetype/OpenType feature
Hi Funda Wang, On Tue, 10 May 2005 06:38:24 +0200 (CEST) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> Can freetype process TrueType/OpenType feature correctly? > >No. This should be done one level higher since it needs contextual >string processing normally. Have a look at the Pango or ICU >libraries, or do it yourself! As previous posts told, FreeType is font library and not text renderer, it should not act as locale-aware softwares. In the architechture of Pango, such OpenType functionalities are handled by dynamic loadable modules in pango-x.y.z/modules/arabic/*.[ch], take a look on them for how Pango uses OpenType. However, it seems that all modules are locale-independent at present. I don't know whether Pango's module-loader is locale-aware (if so we can write simple glyph substituter and let module-loader to use it when expected locale is selected), or locale-unaware (if so we have to write locale-aware module, but i'm afraid it breaks Pango's structural hierarchy). Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
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?
Hi On Thu, 12 May 2005 23:44:11 +0800 Chia I Wu <[EMAIL PROTECTED]> wrote: >As fontconfig and xft already have the code to "embolden" and rely on >FT_GlyphSlot_Embolden to do the real job, I think FT_GlyphSlot_Embolden >should be made standard API. This is an important feature for Chinese >(maybe also Japanese and Korean) users, as most Chinese fonts don't have >a real bold style. > >What do you think? I'm unfamiliar with this API and never checked the bolden result in detail, could you show some demo program? As you pointed out, most CJK font family does not provide "bold" style. I think "weight" (XXX-Light, XXX-Medium, XXX-Heavy etc) - may take similar role of it in the typographical viewpoint. But, most personal computers are shipped with only 1 or 2 fonts for each CJK scripts, and synthesized "bold" is often used in documents generated by PC. 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 * switch to enable/disable changing glyph metrics in embolding * switch to enable/disable embolding of bitmap font * choosing embolding algorithm 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] 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] Freetype 131 for Mac
Hi On Wed, 18 May 2005 16:29:28 +0530 srijith R <[EMAIL PROTECTED]> wrote: >I want to know whether Freetype 131 is available for mac . Search in Fink. http://fink.sourceforge.net/pdb/search.php There are package for 10.3 & 10.4. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] otv in Jamfile
Hi, On Wed, 01 Jun 2005 20:34:14 +0200 (CEST) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> 2005-05-01 David Turner <[EMAIL PROTECTED]> >> >> * Jamfile: Remove `otvalid' from the list of compiled >> modules. > >I think the very reason is the buggy MSVC compiler which can't compile >the otvalid module because of the preprocessor problems. > >> Will otvalid drop from the next release? > >I won't do that. We are happy to hear this. > Maybe it's moved to another library in the future, >but I don't think that this will happen soon. BTW, even if otvalid is not linked to an application, otvalid may be useful as a standalone validator. e.g. otvalid can validate the font file generated by fontforge. > >> (We, gxvalid developers, are discouraged at this log entry.) > > > >Maybe it's best to distribute the expanded files... The code is not completed yet but we have made you wait so long. We decide to make the development version public. Development version gxvalid is available via gnuarch version control system. The gnuarch archive is at name: [EMAIL PROTECTED]/freetype2--gxv-mps--0.1 location: http://www.gyve.org/~mpsuzuki/arch-2005.03.22/ This archive includes both Masatake YAMATO and my work. Our work is synced with freetype official CVS repository; the archive includes the latest change at freetype development. [EMAIL PROTECTED] gxvalid]$ LANG=C wc -l *.c *.h 290 gxvacnt.c 35 gxvalid.c 263 gxvbsln.c 1049 gxvcommn.c 440 gxvfeat.c 475 gxvfgen.c 559 gxvjust.c 636 gxvkern.c 160 gxvlcar.c 347 gxvmod.c 323 gxvmort.c 70 gxvmort0.c 145 gxvmort1.c 181 gxvmort2.c 22 gxvmort4.c 153 gxvmort5.c 153 gxvopbd.c 253 gxvprop.c 404 gxvtrak.c 99 gxvalid.h 373 gxvcommn.h 48 gxverror.h 45 gxvmod.h 6523 total Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] sfnt-housed fonts on MacOS missing "hhea" table
Dear Sirs, It seems that FreeType2 cannot load some bitmap-only fonts on MacOS X (possibly on Classic MacOS too), because such fonts have no "hhea" tables in its sfnt resource. I wrote small patch to bypass the problem (attached to the end of this mail), but I'm not sure about FT2 requirement of data in "hhea" and afraid unexpected subeffect. I hope I could receive some comments. -- As example, "/Library/Fonts/Osaka Bold", "/Library/Fonts/Osaka Narrow" (both resource fork font, data fork is zero-sized) of MacOS X 10.2 and later contains following subtables in its sfnt resource: tt_face_load_sfnt_header: 0x80bcb10, 0 tt_face_load_directory: 0x80bcb10 -- Tables count: 9 -- Format version: 74727565 FT_QAlloc: size = 144, block = 0x0x80bce18, ref = 0x0x80bcbac bdat - 009c - 00048600 bloc - 0004869c - 0ae8 cmap - 00049184 - bca6 feat - 00054e2c - 003c head - 00054e68 - 0036 maxp - 00054ea0 - 0020 mort - 00054ec0 - 587c name - 0005e0b8 - 02aa post - 0005a73c - 397a You can see, there's no "hhea" subtable. As a result, ttload.c::tt_face_load_metrics_header() returns SFNT_Err_Horiz_Header_Missing. But, nothing to say, MacOS X can handle such fonts. According to the TrueType font specification by Microsoft, "hhea" is noted as essential table. But, Apple's specification has strange notes. http://developer.apple.com/fonts/TTRefMan/RM06/Chap6hhea.html -- Mac OS-specific information Although it is officially listed as a "required" TrueType table, the 'hhea' table is not in fact required for all sfnt-housed fonts on the Mac OS. Non-TrueType fonts housed in an sfnt data structure may not have a 'hhea' table. This is allowed by the OFA2 architecture. -- >From this note, I think as "if the font comes from MacOS platform, FT2 had better stand against the lack of hhea subtable". So, I propose a hook to detect "comes from MacOS platform" and softening the error, aslike: --- freetype2/src/sfnt/ttload.c +++ freetype2/src/sfnt/ttload.c @@ -1098,6 +1098,11 @@ if ( error ) { error = SFNT_Err_Horiz_Header_Missing; +if ( face->format_tag == TTAG_true ) +{ + FT_TRACE2(( "no hhea table, but font is sfnt-housed, ignore this error\n" )); + error = SFNT_Err_Ok; +} goto Exit; } As far as I know, TTAG_true is not used on non-MacOS platform. If the infos provided by "hhea" is not essential in FT2, I wish such hook is included in FT2. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] [patch] TrueType GX/AAT validator
Dear FreeType maintainers, We have finished testing gxvalid on Many Apple fonts. gxvalid is ready to be merged to FreeType2's CVS repository. gxvalid patch for CVS version of FreeType2 is available from http://www.gyve.org/~mpsuzuki/gxvalid_20050823.patch The splitted parts are available from * modifications on exisiting files http://www.gyve.org/~mpsuzuki/gxvalid_20050823_modify.patch * new files on existing directories http://www.gyve.org/~mpsuzuki/gxvalid_20050823_newfile.patch * new files under src/gxvalid/ http://www.gyve.org/~mpsuzuki/gxvalid_20050823_module.patch Please review the patch. ChangeLog and outline are attached to the end of this post. Patch for ftvalid will be posted by Masatake YAMATO. Regards, mpsuzuki === ChangeLog - 2005-08-23 suzuki toshiya <[EMAIL PROTECTED]> Add gxvalid module to validate TrueType GX/AAT tables. Modifications on existing files: * Jamfile: Register gxvalid module. * src/base/Jamfile: Register ftgxval.c. * src/base/rule.mk: Register ftgxval.c. * docs/INSTALL.ANY: Register gxvalid/gxvalid.c. * include/freetype/config/ftheader.h: Add macro to include gxvalid header file, FT_TRUETYPEGX_VALIDATE_H. * include/freetype/config/ftmodule.h: Register gxv_module_class. * include/freetype/ftchapters.h: Add comment about gx_validation. * include/freetype/ftotval.h: Change keyword FT_VALIDATE_XXX to FT_VALIDATE_OTXXX to co-exist gxvalid. * include/freetype/tttags.h: Add tag for TrueType GX/AAT tables. * include/freetype/internal/ftserv.h: Add macro to use gxvalid service, FT_SERVICE_TRUETYPEGX_VALIDATE_H * include/freetype/internal/fttrace.h: Add trace facilities for gxvalid. New files on existing directories: * include/freetype/internal/services/svgxval.h: Registration of validation service for TrueType GX/AAT and classic kern table. * include/freetype/ftgxval.h: Public API definition to use gxvalid. * src/base/ftgxval.c: Public API of gxvalid. New files under src/gxvalid/: * src/gxvalid/Jamfile src/gxvalid/README src/gxvalid/module.mk src/gxvalid/rules.mk src/gxvalid/gxvalid.c src/gxvalid/gxvalid.h src/gxvalid/gxvbsln.c src/gxvalid/gxvcommn.c src/gxvalid/gxvcommn.h src/gxvalid/gxverror.h src/gxvalid/gxvfeat.c src/gxvalid/gxvfgen.c src/gxvalid/gxvjust.c src/gxvalid/gxvkern.c src/gxvalid/gxvlcar.c src/gxvalid/gxvmod.c src/gxvalid/gxvmod.h src/gxvalid/gxvmort.c src/gxvalid/gxvmort.h src/gxvalid/gxvmort0.c src/gxvalid/gxvmort1.c src/gxvalid/gxvmort2.c src/gxvalid/gxvmort4.c src/gxvalid/gxvmort5.c src/gxvalid/gxvmorx.c src/gxvalid/gxvmorx.h src/gxvalid/gxvmorx0.c src/gxvalid/gxvmorx1.c src/gxvalid/gxvmorx2.c src/gxvalid/gxvmorx4.c src/gxvalid/gxvmorx5.c src/gxvalid/gxvopbd.c src/gxvalid/gxvprop.c src/gxvalid/gxvtrak.c: New files, gxvalid body. === README -- gxvalid: TrueType GX validator == 1. What is this --- "gxvalid" is a module to validate TrueType GX tables: a collection of additional tables in TrueType font which is used by "QuickDraw GX Text", Apple Advanced Typography (AAT). In addition, gxvalid can validates "kern" table which had been extended for AAT. Like otvalid, gxvalid uses Freetype2's validator framework(ftvalid). You can link gxvalid with your program; before running your own layout engine, gxvalid validates a font file. As the result, you can reduce error-checking code from the layout engine. You can use gxvalid as a stand-alone font validator; ftvalid command included in ft2demo calls gxvalid internally. Stand-alone font validator may be useful for font developers. This documents contains following informations: - supported TrueType GX tables - validation limitation in principle - permissive error handling of broken GX tables - "kern" table issue. 2. Supported tables --- Following GX tables are currently supported. bsln feat just kern(*) lcar mort morx opbd prop trak Following GX tables are currently unsupported. cvar fdsc fmtx fvar gvar Zapf Following GX tables won't be supported. acnt(**) hsty(***) Undocumented tables in TrueType fonts designed for Apple platform. CVTM TPNM addg umif *) "kern" validator includes both of classic kern (format supported by both of Microsoft and Apple platforms) and new kern (a format supported by Apple platform only). **) "acnt" tables is not supported by currently available Apple font
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 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 Based on your detailed analysis (thanks again), I removed the line " - state transition diagram uses undefined glyph ID" from the essential error list, and add following paragraph into the section. If I'm misunderstanding, please let me know. In addition, gxvalid doesn't check "temporal glyph ID" used in the chained State Machines (in "mort" and "morx" tables). When a layout feature is implemented by single State Machine, glyph ID converted by State Machine is passed to the glyph renderer, thus it should not point to undefined glyph ID. But if a layout feature is implemented by chained State Machines, the component State Machine (if it is not final one) is permitted to generate undefined glyph ID for temporal use, because it is handled by next component State Machine, instead of the glyph renderer. To validate such temporal glyph ID, gxvalid must stack all undefined glyph IDs which is possible in the output of previous State Machine and search them in "ClassTable" of current State Machine. It is too complexed work to list all possible glyph IDs from StateTable, especially from ligature substitution table. I think quick hack is not enough to solve this issue, so I want to put it to TODO of gxvalid. 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 numbers>255, >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
Hi, On Wed, 24 Aug 2005 12:41:52 -0400 "Sean McBride" <[EMAIL PROTECTED]> wrote: >These functions have been officially deprecated as of Mac OS 10.4 Tiger, >but unofficially deprecated long ago. The two main points are: > - FSSpecs should be replaced with FSRefs > - <http://developer.apple.com/technotes/tn2002/tn2078.html> > - Font Manager calls should be replaced with ATS for Fonts. > - <http://developer.apple.com/documentation/Carbon/Conceptual/ >ATS_Concepts/atsfonts_intro/chapter_1_section_1.html> > - The main header is ATSFont.h, in ApplicationServices/ATS Thank you for informative references. Do you know any docs to know about: which version of MacOS has which functions? I'm not sure if FreeType maintainers have enough sparetime to support antique MacOSs (System7, MacOS 8 etc), but I think it's important which platforms are dropped in next ftmac.c (if there's). 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, Sorry for lated response. On Fri, 02 Sep 2005 11:14:56 +0200 [EMAIL PROTECTED] (Christian Demmer) wrote: >[EMAIL PROTECTED] wrote: >>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? > >No need to buy anything. Just get MPW from Apple. It's free. ><http://developer.apple.com/tools/mpw-tools/> > >Be sure to apply the latest updates (Updated MPW Components) since the >last release is from 2001. There is no new release because Apple does >not actively support it anymore. Excuse me, please let me ask fundamental question: MPW or CodeWarrior are required to compile ftmac.c? There are 3 building control files in FreeType tree: * freetype2/builds/mac/freetype.makeis for MPW * freetype2/builds/mac/ftlib.prjis for CodeWarrior * freetype2/base/Jamfileis cross platform, but ftmac.c is quoted for MPW Could I compile ftmac.c via UNIX style configure/make process? 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. Christian Demmer, On Sat, 03 Sep 2005 16:42:31 +0200 [EMAIL PROTECTED] (Christian Demmer) wrote: >[EMAIL PROTECTED] wrote: >>Excuse me, please let me ask fundamental question: MPW or CodeWarrior >>are required to compile ftmac.c? > >Not necessarily. It depends on your target OS and runtime environment >ABI. If you want OS 9 (CFM) then you need MPW or Codewarrior. OS X can >run CFM (MPW/Codewarrior) or Mach-O produced by gcc or Codewarrior? >(not sure, I don't use Codewarrior). > >> There are 3 building control files >>in FreeType tree: >> >>* freetype2/builds/mac/freetype.make is for MPW > >MPW is a shell with makefiles but the makefiles are different from Unix. > >>* freetype2/builds/mac/ftlib.prj is for CodeWarrior >>* freetype2/base/Jamfile is cross platform, >> but ftmac.c is quoted for MPW >Not sure here either. I think Jamfiles were used in ProjectBuilder some >time ago, that means OS X/gcc -> Mach-O environment. > >>Could I compile ftmac.c via UNIX style configure/make process? > >Yes, but only on OS X targeting Mach-O. Great Thank you very much for detailed explanation. In fact, I didn't know ProjectBuilder can recognize Jamfile. Now I could compile ftmac.c for Mach-O target by MacOS X's gcc manually. 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, First of all, Great Thanks to people giving helpful informations of Macintosh issues: Sean McBride, George Williams, Tom Bishop, Christian Demmer, David Turner and Werner LEMBERG. I've written a diagram of function-calling-tree of related functions in ftmac.c. http://www.gyve.org/~mpsuzuki/ftmac_c.txt As Sean McBride cited 2 Apple documents, the deprecation issue consists of 2 function groups: FileManager and FontManager. I think fixes can be done separately. For first, I will try fix the problem of FileManager issue. -- According to Apple TechNotes TN2078, it seems that replacement of FSSpecXXX() by FSRefXXX() is not sufficient of the deprecation issue, because the data struture "FSSpec" (which is used to point a file in Macintosh) itself is deprecated and replacement by "FSRef" is recommended. At present, ftmac.c provides a public function to open new face from given "FSSpec": FT_New_Face_From_FSSpec(). Thus, complete cleasing "FSSpec" will cause API incompatibility. Some configuration option to build without FSSpec might be expected (and it is expected to be switched off by default, until the day Apple removes FSSpecXXX() completely). # I don't know PBMakeFSSpecSync() is deprecated in Tiger. # If there are some undeprecated functions handling FSSpec, # it is possible to provide FT_New_Face_From_FSSpec() without # compiler warning of deprecation. However, PBMakeFSSpecSync() # is not easy to use, for me. In addition, from the viewpoint of application programmers, something like FT_New_Face_From_FSRef() is expected to replace "FSSpec" in their applications. Any suggestion about the deprecation of "FSSpec"? 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] Freetype on Mac uses deprecated functions
Dear Sirs, On Thu, 15 Sep 2005 12:11:15 +0900 [EMAIL PROTECTED] wrote: >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. On Thu, 15 Sep 2005 06:34:52 +0200 (CEST) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >Since I don't use a Mac, I have no opinion. Hopefully, others can >comment. On Thu, 15 Sep 2005 09:32:39 -0400 "Sean McBride" <[EMAIL PROTECTED]> wrote: >Well, I don't even use freetype (except via vtk) so I'm not sure my >opinion is important, but I think A sounds better. Mr. Sean McBride and Mr. Werner LEMBERG, Thank you for comments. I attach 2 patch of this issue. migrate_fsspec2fsref.patch This patch changes src/base/ftmac.c to use FSRef at maximum, if TARGET_API_MAC_OS9 is not defined. Originally written by Mr. George Williams and slightly modified by me. migrate_qdfm2ats.patch This patch adds FT_GetFile_From_Mac_ATS_Name() in src/base/ftmac.c, which is an AppleTypeService-based replacement of QuickDraw based FT_GetFile_From_Mac_Name(), written by me. If "HAVE_QUICKDRAW" is set to false on the future Mac OS X system without QuickDraw, FT_GetFile_From_Mac_Name() is changed to a function that returns error always. If "HAVE_ATS" is set to false on old system without ATS, FT_GetFile_From_Mac_ATS_Name() will be a function that returns error always. Also a patch for configure.ac is attached to set HAVE_QUICKDRAW and HAVE_ATS automatically, if --with-old-mac-fonts=yes. At present, yet I've not finished macro hooking for MPW, ProjectBuilder, Xcode and CodeWarriror. By the way, thinking of ATS patch is written to remove deprecated function, the 2nd argument of FT_GetFile_From_Mac_ATS_Name() should be FSRef, than FSSpec? The current API is designed to be same with FT_GetFile_From_Mac_Name(), for programmers' convenience. But, FSSpec is deprecated data type, so I should propose different function using no deprecated data? For example: FT_GetFile_From_Mac_Name( const char* fontName, FSRef* pathRef, FT_Long* face_index) # yet I'm not sure if the idea of "face" fits ATS font model. Mr. Sean McBride (and anybody interested in this issue), how do you think of? Regards, mpsuzuki migrate_fsspec2fsref.patch Description: Binary data migrate_qdfm2ats.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Porting Free Type on 8 Bit platform!
On Fri, 23 Sep 2005 19:34:27 +0530 Kiran Mahajan <[EMAIL PROTECTED]> wrote: >On Fri, 2005-09-23 at 10:31 +0200, Turner, David wrote: >> In theory, FreeType should work on 16-bit platforms, but >> this hasn't been officially verified for a very long time. >> >> However, I don't know of any 8-bit platform that is capable >> of dealing with, say, memory-mapped files or heap blocks >> that are larger than, say, 64 Kb, and this ability is >> required to support certain fonts which require very >> large allocations. >yes it would be difficult or not possible to port whole freetype engine >on 8 bit due to memory shortage but what you say about customized form >of it? means i want to say that freetype having support of such fonts >like BDF which are small. I think, saying just "8 bit platform" is insufficient to ask further. Could you give us example of 8 bit platform system which is similar to your target? There are UNIX like OS for Z80 (e.g. UZI, UZIX), CP/M families etc etc. In fact, on 8 bit platform, the programming model, function calling convention, compilers etc would effect the size of program. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Status of TT_CONFIG_OPTION_UNPATENTED_HINTING
On Wed, 28 Sep 2005 20:07:10 +0200 (CEST) Jan Slupski <[EMAIL PROTECTED]> wrote: >> Is there any definitive list out there of the fonts known to have these >> issues? (I see that MingLiU and KaiU are specifically named in the >> archives). > >Once I have created http://freetype.freedesktop.org/wiki/Fonts >but it seems that the idea of creating such list didn't catched... I was not aware of the exist of the page. Taking a glance on it, I'm afraid, people may wonder what is important information in the list, why the list should be maintained, and how to add new information. I think what is the point of the list should be stated. 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
[ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)
Dear Sirs, Yesterday I've got CodeWarrior 9.0 for MacOS, and checked CW project file at builds/mac/ftlib.prj. There is an issue: the project file tries to compile autohint.c which was already removed from source tree. # Yet I've not checked if built library works well # with ftdemos, sorry I've attached updated CW project file in CW native binary format (ftlib.prj), and in XML format (ftlib.prj.xml). I think, XML project file is better, because we can update it without CW, when some sources are added or removed. I'm unfamiliar old CW can import XML project file, but, at least, even if I choose CW native binary project format, I cannot generate project file for old CW (e.g: CW7, CW8 etc). Any comments about update of CW project file? Regards, mpsuzuki ftlib.prj.gz Description: application/gunzip ftlib.prj.xml.gz Description: application/gunzip ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)
On Tue, 25 Oct 2005 10:37:40 +0200 (CEST) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> There is an issue: the project file tries to compile >> autohint.c which was already removed from source tree. [...] >> >> Any comments about update of CW project file? > >Again, please update the CVS as you think is correct. Neither David >nor me use a Mac. > >It might useful also to exactly document what environment you are >using for a successful compilation. Thank you, I will update builds/mac/README and builds/mac/ftlib.prj within this week. Possibly I will replace ftlib.prj by ftlib.prj.xml. -- Now I'm checking Makefile for vanilla MPW: builds/mac/freetype.mak, I think it's also broken (pointing to autohint.c), and 8bit characters in MPW makefile syntax are broken. I will write an AWK script (Python is prefered?) to convert MPW makefile to pure US-ASCII text file, and its reversal script, to avoid such problem in future. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] update CodeWarrior project file (builds/mac/ftlib.prj)
Dear Sir, On Tue, 25 Oct 2005 10:35:03 -0400 "Sean McBride" <[EMAIL PROTECTED]> wrote: >On 2005-10-25 12:34, [EMAIL PROTECTED] said: > >>Yesterday I've got CodeWarrior 9.0 for MacOS, and > >You should definitely download the free 9.6 update, it fixes many many >bugs: > ><http://www.metrowerks.com/mw/download/updates.asp?date_op=on+or >+after&year=95&month=01&day=1&did=find&vers=CWMACOS9&submit=Select+%3E%3E> Thank you for notice. BTW, I'm looking for infos about the compatibility of CW project file, there's any documentation? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] "comp" is reserved word in Apple SC compiler?
Dear Sirs, Now I'm testing my MPW makefiles to build FreeType2 by vanilla MPW (a free-charged developer environment for classic MacOS). Sorry for my lated work of MacOS issues. In testing, I've found that "SC" (Apple's m68k C compiler) seems to use "comp" as a reserved word. In compilation of ttsbit.c, I receive following error: >SC :src:sfnt:sfnt.c -c :objs:sfnt.c.o -includes unix -i :include: -i :src: > -sym off -model far >SC C Compiler 8.9.0d3e1 >Copyright (C) 1985-2000 by Apple Computer, Inc. > > TT_SBit_Component comp; >^ >File ":src:sfnt:ttsbit.c"; line 1358 #Error: illegal combination of types > #--- > for ( comp > ^ >File ":src:sfnt:ttsbit.c"; line 1371 #Error: expression expected When I replace the variable "comp" by "compo", SC does not complains anymore. I grepped MPW's header files and the output by SC's cpp, but I couldn't find any part which defines "comp" for their own use. In addition, "MrC" (Apple's PowerPC C compiler) does not complain about "comp" at all. So, I think "comp" is undocumented & internal reserved word for SC. A haphazard Workaround for such issue (which replace "comp" by "compo") is acceptable? Regards, mpsuzuki freetype2_mpw.patch Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "comp" is reserved word in Apple SC compiler?
Dear Sirs, Thanks to all who posted this issue. I'm very happy to receive helpful infos about unknown keyword "comp". I will take a look in mpw-devel mailing list, too. As Werner has already pointed out, I think the solution (pass "-ansi strict" option to SC) proposed by Christian Demmer looks most reasonable. Following to his proposal, I could compile FreeType. However, a few explicit typecasts are needed in ftmac.c like this. I think it's acceptable. --- orig/src/base/ftmac.c +++ mod/src/base/ftmac.c @@ -838,8 +838,8 @@ OSStatus status = FMCreateFontFamilyIterator( NULL, NULL, options, &famIter ); -FMFontthe_font = NULL; -FMFontFamily family = NULL; +FMFontthe_font = ( FMFont ) NULL; +FMFontFamily family = ( FMFontFamily ) NULL; *face_index = 0; ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] "comp" is reserved word in Apple SC compiler?
On Fri, 28 Oct 2005 13:29:51 +0900 (JST) Masatake YAMATO <[EMAIL PROTECTED]> wrote: >> -FMFontthe_font = NULL; >> -FMFontFamily family = NULL; >> +FMFontthe_font = ( FMFont ) NULL; >> +FMFontFamily family = ( FMFontFamily ) NULL; > > FMFontFamily family = ( void* ) NULL; > >is not ok with the compiler? Not enough. Speaking exactly, both of FMFont and FMFontFamily in MPW are not pointer-type. I receive following errors: --- SC :src:base:ftmac.c -o :objs:ftmac.c.o \ -ansi strict -includes unix \ -i :include: -i :src: -sym off -model far SC C Compiler 8.9.0d3e1 Copyright (C) 1985-2000 by Apple Computer, Inc. FMFontthe_font = ( void * ) NULL; ^ File ":src:base:ftmac.c"; line 841 #Error: cannot implicitly convert from: (void *) to : (unsigned long) #--- FMFontFamily family = ( void * ) NULL; ^ File ":src:base:ftmac.c"; line 842 #Error: cannot implicitly convert from: (void *) to : (short) --- Now I think the exact solution for MPW might be: FMFontthe_font = 0; FMFontFamily family = 0; I found that MacTypes.h defines NULL as following. --- #ifndef NULL #if !defined(__cplusplus) && (defined(__SC__) || defined(THINK_C)) /* Symantec C compilers (but not C++) want NULL and nil to be (void*)0 */ #define NULL ((void *) 0) #else /* in case int is 16-bits, make sure NULL is 32-bits */ #define NULL 0L #endif #endif --- In the case that target CPU is PowerPC, NULL is defined to 0 in 32bit. Therefore, when ftmac.c is compiled for MacOS on PowerPC, this problem didn't arise. Unfortunately, Apple does not document about whether 0 is suitable for "undefined" or "unresolved" FMFont/FMFontFamily data. In summary, I will replace "NULL" in the part by "0L". 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] "comp" is reserved word in Apple SC compiler?
On Fri, 28 Oct 2005 09:38:54 +0200 "Turner, David" <[EMAIL PROTECTED]> wrote: >> In summary, I will replace "NULL" in the part by "0L". >> How do you think of? >> > >I think you should only use "0", since this is a magic token for C compilers >that can be interpreted either as an integer or as a pointer, depending on >context. Thank you for information! OK, I'll do so: I'll use "0", not "0L" nor "NULL". 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( )
Hi On Wed, 2 Nov 2005 11:55:08 -0500 "Taek Kwan(TK) Lee" <[EMAIL PROTECTED]> wrote: >When this function locates 'StartData' , it reads in by '256 + 10 - >buff_len' from stream. Sometimes, the font data after 'StartData' is >not very long and stream read function fails in this case. >I think stream->size should be considered to get the correct reading length. I think following patch realizes your proposal. I want to test, could you provide some example CIDFont that original FreeType cannot parse correctly? Regards, mpsuzuki 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 4 Nov 2005 02:33:28 - @@ -101,8 +101,15 @@ 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, max_read_len > size ? size : max_read_len ) ) + goto Exit; + } top_position = FT_STREAM_POS() - buff_len; buff_len = 256 + 10; ___ 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
[ft-devel] "make distclean" and objs/apinames, objs/ftexport.sym
Hi When I tested cross building of latest FreeType2 on CVS, I found that "make distclean" deletes all object files but it does not execute "clean_project" in exports.mk, so objs/apinames & objs/ftexport.sym are left. I think "make clean_project" works, but configuration is required to use the target. In FreeType2, which target should be used to clean files to unconfigured status? Regards, mpsuzuki ___ 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
On Thu, 10 Nov 2005 10:10:20 -0500 "Taek Kwan(TK) Lee" <[EMAIL PROTECTED]> wrote: >I accidentally press send button with unfinished docuemnt a while ago. >This one is the finished one. Please ignore the other one. > >In case of Type 42 Incremental downloading, 'glyf' and 'loca' table do >not present in the font data by Adobe specification. However, by >setting parameter and providing incremental interface, Freetype should >be able to print it. I think this issue is same with glyf->glyx, loca->locx issue: http://lists.gnu.org/archive/html/freetype-devel/2002-07/msg00022.html At present, Type42 font handler of FreeType is designed to load persistent Type42 font object from file or memory, I guess. FreeType is intended to support dynamically updated font object in memory? 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? ___ 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
Hi, On Thu, 17 Nov 2005 11:46:09 +0900 [EMAIL PROTECTED] wrote: >>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' Excuse me, you received this error in compiling ftvalid.c into ftvalid.o? Or, you received it in linking ftvalid.o to ftvalid executable? If it's in compiling, I don't know why it's complained, because the compiler should know that FT_Free_Debug is declared as external symbol, by including freetype2/include/freetype/internal/ftmemory.h. If it's in linking, it's a bit complexed problem. GNU ld with --retain-symbols-file removes unlisted symbols from .symtab, but don't remove them from .dynsym. As a result, I cannot find FT_Free_Debug in "nm -a freetype2/objs/.libs/libfreetype.so", but I can find it in "nm -D freetype2/objs/.libs/libfreetype.so". When I link ftvalid.o refering FT_Free_Debug(), with libfreetype.so that does not have FT_Free_Debug() in its .symtab, GNU ld detects that FT_Free_Debug() exists in libfreetype.so, and linking is finished successfully. When I add "-Wl,--trace-symbol=FT_Free_Debug", I receive following output. GNU ld detects FT_Free_Debug() in libfreetype.so. $ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \ -DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY \ -o ./bin/.libs/ftvalid \ ./obj/ftvalid.o ./obj/common.o \ ../freetype2/objs/.libs/libfreetype.so \ -lz ./obj/ftvalid.o: reference to FT_Free_Debug ../freetype2/objs/.libs/libfreetype.so: definition of FT_Free_Debug I guess this is the known behaviour of GNU ld, See: http://sourceware.org/ml/binutils/2001-12/msg00143.html How did you remove FT_Free_Debug() completely? Regards, mpsuzuki P.S. BTW, now I think about this issue: the tools outside of libfreetype should not refer FT_Alloc_Debug(), FT_Free_Debug() etc etc anymore. Therefore, ftvalid.c should include ftdbgmem.c by itself? ___ 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] failed to compile ftvalid.c
On Fri, 18 Nov 2005 08:19:40 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> I attached 4 patches, please check. > >And please install! Just I've committed 4 patches. Thanks to all for helpful comments! Regards, mpsuzuki ___ 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 CVS module
heir implementation will simply return >> > FT_Err_Unimplemented instead. >> >> Ideally, FreeType should have support for external plugins. This is, >> if FreeType finds libftvalid, it uses it, otherwise you get >> FT_Err_Unimplemented. It seems that we have to start with libtool's >> `dlopen' function... >> >> Sigh. All these things mean a lot of additional work. Isn't it >> easier to simply disable those two modules? I'm already thinking how >> to have a central configuration file which controls the used modules >> -- without removing or renaming the rules.mk files... >> >We probably need something like that, but I want, at a minimum, that >these modules be out of a default build. 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. I have no objection against the pointing out: gxvalid is too big as a module built/included by default. I think, otlayout is still very compact in contrast with gxvalid, and no problem to include it in freetype. If I rewrite gxvalid to smaller and limited validation (e.g. memory alignment, number of members etc) by default, it's acceptable to include? Regards, sorry for long mail with poor English. mpsuzuki ___ 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
Re: [ft-devel] Open Type font that contains Adobe CFF (PostScript outlines) data
excuse me, i attached too big files for ft-devel. i reduced screenshot and compressed cff table and send this message again to the list. -- Hi Vitaly, On Sun, 27 Nov 2005 22:08:34 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> This font extracted from PDF 1.6 file. Font was embedded in PDF >> document as subset in the FontFile3 stream and based on Type1 font. >> PDFReference 1.6 describe OpenType embedding in the FontFile3 stream >> in the 3 way > >Well, the font *is* broken. It can't work standalone. Both the GSUB >and GPOS tables refer to non-existent glyphs (and BASE probably too I >suspect). I really wonder which information of this font is valid at >all. It is probably used as a glyph container only, and all other >information is already in the PDF. I agree with Werner, I suppose this font is not standalone. Sorry, yet I'm unfamiliar with OpenType embedding into PDF, although I'm familiar with Type1/Type9/Type11/Type42 embedding. If you seek to CFF table directly, FreeType can load it as usual, and renders included glyphs. I attached extracted CFF table and screenshot by ftview. Almost glyphs are just spaces. Could you send me the original PDF documents? And, current FreeType does not provide OpenType layout functions, loading and handling of OpenType extension tables is the task of other libraries. Regards, mpsuzuki WarnockPro.cff.bz2 Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Adding "-ansi strict" to MPW SC causes unresolved symbol error
Hi, Now I'm porting FreeType library to m68k MacOS (there had ever port for ppc MacOS, but not for m68k), and found strange behaviour of MPW SC. Following is a sample source. -- #if defined(__GNUC__) && defined(__APPLE_CC__) # include # include #else # include # include #endif int main() { CInfoPBRec cipb; PBGetCatInfoSync( &cipb ); return 0; } -- This is building test only, to call FileManager function. If I compile it normally, the compiling/linking finishes normally. But when I add "-strict ansi", I receive following errors in linking. The name of function PBGetCatInfoSync() is capitalized and could not resolve it. SC version is 8.9.0d3e1. In addition, when I tried by MrC, such problem does not occur. [excuse me, long lines are folded] -- # 2:49:34 PM - Build of callPBGetCatInfoSync.exe. # 2:49:34 PM - Analyzing dependencies. # 2:49:34 PM - Executing build commands. SC callPBGetCatInfoSync.c -o :callPBGetCatInfoSync.c.o \ -sym off -model far -ansi strict ILink -o callPBGetCatInfoSync.exe \ ":callPBGetCatInfoSync.c.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:Stubs.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:MathLib.far.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:CLibraries:StdCLib.far.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:MacRuntime.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:IntEnv.far.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:ToolLibs.far.o" \ "works:MPW:MPW::Interfaces&Libraries:Libraries:Libraries:Interface.o" \ -sym off -mf -d -t 'MPST' -c 'MPS ' -model far -state rewrite \ -compact -pad 0 # Undefined entry, name: "PBGETCATINFOSYNC" # Referenced from "main" in file "callPBGetCatInfoSync.c.o" # -- Due to SC uses some undocumented(?) reserved keywords, now I add "-ansi strict" option to compile FreeType sources. I could not find explicit notes about such issue in "Help SC", but there's no problem in building by MrC, I suppose it is SC's bug. If I'm misunderstanding, please let me know. And, mixing objects compiled with "-ansi strict" and without it causes problem? 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] aface->num_faces of FT_New_Face() in ftmac.c
On Wed, 30 Nov 2005 22:05:58 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> In the regression test, I've found that FT_New_Face() in ftmac.c >> does not return correct aface->num_faces. [...] >> >> ...So, now I'm going to fix this, and I want to ask about binary >> compatibility. > >Where's the problem with binary compatibility? You are going to >extend the functionality, not to change, aren't you? Ah, excuse me, "binary compatibility" is wrong word. I wanted to ask the compatibility from current "sfnt/LWFN driver" to future "fbit/NFNT/sfnt/LWFN driver". Your reply about NFNT is enoughly suggestive. >> 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. > >Hmm, is it really just a `strike'? Or is it more like a full-featured >face, similar to the faces in WINFNT files? Because of encoding >issues I have changed the bitmap handling for this driver from strikes >to faces. Yes, thank you for pointing out! NFNT resources are separated for each sizes, just aslike strike of sbit. Could I know more about WINFNT encoding issue in ft-devel archive? I found a note of moving from strikes to faces in docs/CHANGES freetype-2.1.4 to 2.1.5. My initial fix of ftmac.c will ignore the number of NFNT resource. 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] No support for side-by-side installation of x86-64 and i386
On Wed, 7 Dec 2005 18:42:52 +0900 [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. >Do you know Linux's policy to use, or not-to-use lib/lib64 >library separation? FHS v2.3 has "Linux-specific" annex about lib/lib64: http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64 For x86-64, ppc64, s390x and sparc64, using lib64 is recommended. Unfortunately, I've checked FHS and LSB, I could not find documents about the location of arch-dependent header files. 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 all, Sorry for lated post. About Solaris' management for arch-dep & arch-indep header files... On Thu, 08 Dec 2005 15:37:23 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> > * How about header files? >> >> As far as I've seen, most system headers exist in one copy only, and >> use preprocessor macros to detect which the architecture is; usually >> via , which defines macros for most of the >> interesting cases: [...] > >This is the solution I like most. I don't know how difficult it is to >achieve that... I propose 2 step solution. I'm not sure if there's freetype-2.1.11, but I don't want to change the numbers of important header files until freetype-2.2, not to bother binary packagers. Step 1: Modify ftconfig.h to support both of 32 & 64bit archs by single file, for amd64, ppc64, sparc64 and s390x. At least, I will write autoconf patch to do that. Unfortunately, at present, I have no idea to fix this issue on other building systems: Jam, Win32 systems, Mac Xcode etc. I expect this issue is specific to a few Unix style systems. Step 2: Separate arch-dependent part to another file. About the location of arch-dependent header, we should discuss more. I suppose Linux people want to move them from /XXX/include to /XXX/lib, but I'm not sure if it's right solution (I feel /usr/lib of Linux is now being hell-like blackhole). I suspend MacOS porting work, and post quick fix of step1 within this week. I have a question to write step1 fix. The configure script generates dual-platformed ftconfig.h, but built library should be dual-platformed? For example, on amd64 system, something like: $ env CFLAGS="-m32" ./configure $ make $ file ./objs/.libs/libfreetype.so.6.3.6 ELF 32-bit LSB shared object, Intel 80386, version 1 ./build/unix/ftconfig.h supports both of amd64 and i386 (no other platform) but the built library is only for i386. Is it too ugly? 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-64and i386
Hi all, Here is the first revision of my patch to support 32/64bit ABI by generating unified ftconfig.h. Ilya, could you test it? After patching this, ./configure --enable-multi-abi="64_32" will generate unified ftconfig.h which is same in the both cases of "-m32" and "-m64". -- My patch for configure.ac is very very lengthy, so here is the outline about what it does. 1) check new option "--enable-multi-abi". 2) if multi-abi is specified... check the pair of multi-abi-type and host-type objdump (or file) is searched to check whether ABI in object file is default and optional. 2-1) determine the default ABI. 2-2) check CFLAGS to generate objects with optional ABI At present, only "-m32" or "-m64" are tested. 3) if we could know how to generate objects with optional ABI... unset autoconf cache and re-check ABI-dependent features (at present, only sizeof(int) & sizeof(long) are checked) in optional ABI. 4) if ABI-dependent features are different... search CPP macro to determine current ABI from keywords like C features (LP64, etc) or arch-name (AMD64, PPC64 etc). 5) if useful CPP is found... generate dual-ABI header file with the name "arch_dep.tmp" 6) if there is "arch_dep.tmp"... replace ABI-dependent feature part in ftconfig.h by "arch_dep.tmp" At present, only Linux is supported by --enable-multi-abi: Linux + GNU C compiler on x86_64. I think ppc64, s390x and sparc64 could be supported by same hook, but I've not tested yet. Solaris + GNU C compiler on x86_64, sparc64 should be very similar framework. I'm not sure about Intel C compiler and Sun C compiler. My next goal might be AIX on POWER architechture: AIX stores both of 32bit and 64bit libraries into same directories (/lib, /usr/lib), but with _64 suffixes, aslike crt0.o and crt0_64.o. It seems that default is 32bit-ABI, and "-maix64" is usable to generate 64bit-ABI. I can find many __64BIT__ hooks in /usr/include/*.h. Also I have to learn about IRIX (ECOFF, o32, n32, n64) and HP-UX on RISC (32bit-SOM, 32bit-ELF, 64bit-ELF). diff -NBurb freetype2.orig/builds/unix/configure.ac freetype2-multi-abi/builds/unix/configure.ac --- freetype2.orig/builds/unix/configure.ac 2005-12-19 14:08:50.0 +0900 +++ freetype2-multi-abi/builds/unix/configure.ac2005-12-19 14:08:04.0 +0900 @@ -88,6 +89,182 @@ AC_CHECK_SIZEOF([long]) +# when --enable-multi-abi is specified +# some 64bit platforms sharring header files for 32bit & 64bit ABI. +AC_ARG_ENABLE([multi-abi], + [ --enable-multi-abimake ftconfig.h shareable between multiple ABI], + [], []) +if test x"${enable_multi_abi}" = xyes; then + enable_multi_abi="64_32" +fi +rm -f arch_dep.tmp +cflags_64="" +cflags_32="" +case "${enable_multi_abi}":"${host}" in + 64_32:amd64-*linux* | 64_32:x86_64-*linux* | \ + 64_32:ppc64-*linux* | 64_32:s390x-*linux* | 64_32:sparc64-*linux* ) +AC_PATH_PROG(OBJDUMP, ${host}"-objdump", ${PATH}) +if test x"${OBJDUMP}" = x ; then + AC_PATH_PROG(OBJDUMP, objdump, ${PATH}) +fi +if test x"${OBJDUMP}" != x ; then + OBJDUMP="${OBJDUMP} -p" +else + AC_PATH_PROG(OBJDUMP, file, ${PATH}) +fi + +echo "int main()" > conftest.c +echo "{" >> conftest.c +echo " exit(0);" >> conftest.c +echo "}" >> conftest.c + +AC_MSG_CHECKING([default object format]) +${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -c conftest.c +if test 0 != $?; then + AC_MSG_ERROR([compiler does not working]) +fi +default_obj_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'` +if test 0 != $?; then + AC_MSG_ERROR([cannot detect object format]) +fi +case "${default_obj_format}" in +*64* ) + AC_MSG_RESULT([64bit]) + AC_MSG_CHECKING([CFLAGS -m32 is usable to generate 32bit object file]) + ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -m32 -c conftest.c + if test 0 != $?; then +AC_MSG_RESULT([no]) + else +obj32_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'` +if test x"${obj32_format}" = x"${default_obj_format}"; then + AC_MSG_RESULT([compiled, but object file is same with 64bit]) +else + AC_MSG_RESULT([yes]) + cflags_32="-m32" +fi + fi + ;; +*32* ) + AC_MSG_RESULT([32bit]) + AC_MSG_CHECKING([CFLAGS -m64 is usable to generate 64bit object file]) + ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -m64 -c conftest.c + if test 0 != $?; then +AC_MSG_RESULT([no]) + else +obj64_format=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'` +if test x"${obj64_format}" = x"${default_obj_format}"; then + AC_MSG_RESULT([compiled, but object file is same with 32bit]) +else + AC_MSG_RESULT([yes]) + cflags_32="-m64" +fi + fi + ;; +esac +rm -f conftest.c conftest.${OBJEXT} +if test x"${cflags_64}"
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_Resou
[ft-devel] MacOS-specific API regression test tool
Hi all, On Thu, 22 Dec 2005 22:00:54 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: > > Attached is patch for ftmac.c, make it to return the number > > of unique scalable faces. > > Please check in, and document the changes in the docs/CHANGES file. Thanks Werner, I had checked my patch in CVS. Before posting jumbo patch for ftmac.c to fix deprecated FileManager & FontManager API issue, here is a dirty new year gift: small tool for regression-test of MacOS specific APIs. Somers, How do you think of? Attached is a patch of ftoldmac.c and bits to build the tool "ftoldmac" on MacOS X. Makefiles for MPW are now being worked. Yet I'm unfamiliar to write portable Makefile that builds ftoldmac on MacOS only, I cannot apply the this patch to CVS tree of ft2demos. USAGE - ftoldmac [pathname in HFS syntax] e.g. "Macintosh HD:System Folder:Fonts:" quotation is required to avoid shell expansion scan directory and open all font files in there Example: $ ftoldmac "Macintosh HD:System:Library:Fonts:" scans all files in /System/Library/Fonts, try to open as font file, and reports results: how many faces the file includes, the name of face and style, how many glyphs are included in each faces, the style (Bold/Italic) for each faces. Finally, ftoldmac prints how many files are scanned, and how many files are opened (as font) successfully, how many faces are scanned how many faces are opened successfully. So you can know how many faces are lost in the regression, by comparison the numbers for previous libfreetype. ftoldmac --font-listing-api=XXX --font-resolve-api=YYY --font-listing-api={quickdraw_old|quickdraw|ats} specify API to get system font list quickdraw_old: use GetFontName() quickdraw: use FMGetFontFamilyName() ats:use ATSFontGetName() --font-listing-api={quickdraw|ats} specify API to search font file for given font name quickdraw: use FT_GetFile_From_Mac_Name() ats:use FT_GetFile_From_Mac_ATS_Name() Example: $ ftoldmac --font-listing-api=ats --font-resolve-api=quickdraw get the fontname list by ATS, and lookup font file for each fontname by QuickDraw. By comparison the numbers of scanned faces and opened faces, we can know "unresolvable" face name. This is implemented to migrate QuickDraw to ATS, you can know which font name in QuickDraw is unresolvable in ATS. # FT_GetFile_From_Mac_ATS_Name() will be added by forthcoming # jumbo patch. Regards, mpsuzuki ftoldmac.patch.bz2 Description: Binary data ___ 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-64and i386
Hi all, Here's revised version of dual-ABI patch which generates unified ftconfig.h for 64/32bit UNIX platforms. Based on the information by Henrik, I've added experimental support for Solaris (amd64, sparc64) and AIX (ia64, ppc64). Unfortunately, my testing environment is only cross-building system on Linux/i386. Any testing report is welcomed. Regards, mpsuzuki diff -x {arch} -x '.*' -Burb freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac freetype2--mps-multilib--0.1--patch-4/builds/unix/configure.ac --- freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac 2005-12-26 18:37:24.0 +0900 +++ freetype2--mps-multilib--0.1--patch-4/builds/unix/configure.ac 2005-12-26 18:25:25.0 +0900 @@ -88,6 +89,240 @@ AC_CHECK_SIZEOF([long]) +# when --enable-multi-abi is specified +# some 64bit platforms sharring header files for 32bit & 64bit ABI. +rm -f arch_dep.tmp +AC_ARG_ENABLE([multi-abi], + [ --enable-multi-abimake ftconfig.h shareable between multiple ABI], + [], []) +if test x"${enable_multi_abi}" = x; then + enable_multi_abi="no" +elif test x"${enable_multi_abi}" = xyes; then + enable_multi_abi="64_32" +fi + +# prepare known CFLAGS for multilib +case "${enable_multi_abi}":"${host}" in + 64_32:amd64-*linux* | 64_32:x86_64-*linux* | \ + 64_32:ppc64-*linux* | 64_32:s390x-*linux* | 64_32:sparc64-*linux* ) +cflags_to_check="-m64 -m32" +;; + 64_32:amd64-*sunos* | 64_32:x86_64-*sunos* | \ + 64_32:amd64-*solaris* | 64_32:x86_64-*solaris* ) +case x"${CC}" in +*gcc* ) + cflags_to_check="-m64 -m32" + ;; +* ) # assume Sun Forte Studio + cflags_to_check="-xtarget=generic64 -xtarget=generic32 -m64 -m32 -xarch=generic64 -xarch=generic32" + ;; +esac +;; + 64_32:ia64-*aix* ) +case x"${CC}" in +*gcc* ) + cflags_to_check="-m64 -m32" + ;; +* ) # assume IBM compiler + cflags_to_check="-q64 -q32 -m64 -m32" + ;; +esac +;; + 64_32:ppc*-*aix* | 64_32:power*-aix* ) +cflags_to_check="-maix64 -m64 -m32" +;; + no:* | NO:* ) +;; + *) +AC_MSG_ERROR([this platform is unsupported for multilib configuration: ${enable_multi_abi}]) +;; +esac + + +# setup command to detect binary format +cflag_fmt0="" +cflag_fmt1="" +if test x"${cflags_to_check}" != x; then + if test x"${host}" != x"${build}"; then +AC_PATH_PROG(OBJDUMP, ${host}"-objdump", ${PATH}) + fi + if test x"${OBJDUMP}" = x ; then +AC_PATH_PROG(OBJDUMP, objdump, ${PATH}) + fi + if test x"${OBJDUMP}" != x ; then +OBJDUMP="${OBJDUMP} -p" + else +AC_PATH_PROG(OBJDUMP, file, ${PATH}) + fi + + if test x"${OBJDUMP}" = x ; then +AC_MSG_ERROR([no program to detect binary format]) + fi +fi + + +# check the binary format of default object file +if test x"${OBJDUMP}" != x; then + + echo '#include "confdefs.h"' >> conftest.c + echo '#if HAVE_STDLIB_H' >> conftest.c + echo '# include ' >> conftest.c + echo '#endif'>> conftest.c + echo 'int main()' >> conftest.c + echo '{' >> conftest.c + echo ' exit(0);' >> conftest.c + echo '}' >> conftest.c + + AC_MSG_CHECKING([default object format]) + ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -I. -c conftest.c + if test 0 != $?; then +AC_MSG_ERROR([compiler does not working]) + fi + obj_fmt0=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'` + if test 0 != $?; then +AC_MSG_ERROR([cannot detect object format]) + fi + case "${obj_fmt0}" in + *64* ) +AC_MSG_RESULT([64bit]) +;; + *32* ) +AC_MSG_RESULT([32bit]) +;; + *) +AC_MSG_RESULT([unknown]) +;; + esac +fi + +# lookup explicit CFLAG to generate object file in default format +orig_CC="${CC}" +if test x"${obj_fmt0}" != x"${obj_fmt1}"; then + for test_cflag in ${cflags_to_check} NONE + do +if test x"${test_cflag}" != xNONE && test x"${cflag_fmt0}" = x ; then + AC_MSG_CHECKING([${test_cflag} and its output]) + CC=`echo "${orig_CC} x" | sed "s/ / ${test_cflag} /" | sed 's,x$,,'` + ${CC} ${XX_CFLAGS} ${CPPFLAGS} ${CFLAGS} -I. -c conftest.c 2>/dev/null 1>/dev/null + if test 0 != $?; then +AC_MSG_RESULT([unusable flag]) + else +obj_fmt=`${OBJDUMP} conftest.${OBJEXT} | expand | tr ' ' '_'` +if test x"${obj_fmt0}" = x"${obj_fmt}"; then + AC_MSG_RESULT([default]) +
Re: [ft-devel] rendering differences between OS X and Win32
Hi, On Mon, 26 Dec 2005 03:29:22 -0700 Kevin Barabash <[EMAIL PROTECTED]> wrote: >I'm try to write a cross platform application and I'd like there to be >uniform behaviour when it comes to rendering fonts. Unfortunately I >ran into a bug and just to make sure that there wasn't a problem with >my code I wrote a short test program to highlight the bug. Here's a >list of the program and the output for both OS X and Win32. I'm interested in the bug you reported, but I don't have enough time to track indepth mechanism. Give me 2 weeks before join to discussion... BTW, the font file arial.ttf is same? It is taken from MSIE fonts? If you see similar bug in various fonts, please let me know - we can test on other platforms too. 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-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] No support for side-by-side installation of x86-64and i386
Hi On Mon, 26 Dec 2005 20:55:34 +0900 [EMAIL PROTECTED] wrote: >On Mon, 26 Dec 2005 11:28:30 +0100 (CET) >Werner LEMBERG <[EMAIL PROTECTED]> wrote: >>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. Just I've searched documents in libtool-1.5.22 & 2.1a, and libtool mail list archive. In the latest CVS snapshot (2.1a), still multilib support is written as future issue. >From the mail list archive, the last mention about multilib issue is 03/Dec/2004: http://lists.gnu.org/archive/html/libtool/2004-12/msg00020.html I'm afraid no implementation had been worked. Interesting is that they mentioned about RedHat multilib patch for libtool. It just fixes library search path from /usr/lib to /usr/lib64 on 64bit platforms, as attached. Of course, the patch was proposed once, but refused by libtool maintainers. I guess, libtool maintainers want to support to build multi libraries by unified single make target (aslike, current libtool can generate both of static/dynamic libraries by the single make target for libXXX.la), so the work must be very very hard. In fact, if we expect "configure && make" builds multi ABI libraries, config.h must be ABI independent, as the issue now we have :-). Anyway, I will ask future plan and advise to libtool list, but I think my patch is sufficient for urgent fix until future libtool update. Regards, mpsuzuki --- libtool-1.5.14/libtool.m4.multilib 2005-02-12 12:18:34.0 + +++ libtool-1.5.14/libtool.m4 2005-02-15 08:48:42.189498479 + @@ -1456,10 +1456,27 @@ # before this can be enabled. hardcode_into_libs=yes + # find out which ABI we are using + libsuff= + case "$host_cpu" in + x86_64*|s390x*|powerpc64*) +echo '[#]line __oline__ "configure"' > conftest.$ac_ext +if AC_TRY_EVAL(ac_compile); then + case `/usr/bin/file conftest.$ac_objext` in + *64-bit*) +libsuff=64 +sys_lib_search_path_spec="/lib${libsuff} /usr/lib${libsuff} /usr/local/lib${libsuff}" +;; + esac +fi +rm -rf conftest* +;; + esac + # Append ld.so.conf contents to the search path if test -f /etc/ld.so.conf; then lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '` -sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra" +sys_lib_dlsearch_path_spec="/lib${libsuff} /usr/lib${libsuff} $lt_ld_extra" fi # We used to test for /lib/ld.so.1 and disable shared libraries on ___ 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
Re: [ft-devel] No support for side-by-side installation of x86-64and i386
On Tue, 27 Dec 2005 09:15:46 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> Just I've searched documents in libtool-1.5.22 & 2.1a, and libtool >> mail list archive. In the latest CVS snapshot (2.1a), still multilib >> support is written as future issue. > >OK. Here I attach revised patch. It includes: * ft-uniconf.m4 utility macros to generate unified ftconfig.h * configure.ac hook is added to generate ftconfig.h * ftconfig.in add keyphrase to quote ABI-dependent part I changed the feature name to uniconf, because it does not built multi libraries, it just generates unified ftconfig.h which is capable to use for both of 32 & 64bit ABIs on amd64, ppc64, sparc64 and s390x. While I search "multilib" in libtool mail list archive, I remember that "multilib" is also supported in recent gcc, by config-ml.in. Taking a look on that, I think, gcc config-ml.in is designed to work as meta-configure level: it executes configure in separated directories for each configurations (usually, gcc multilib is used to support the CPUs whose FPU is optional (e.g. m68k & ARM), CPUs whoese family is big and instruction sets are defined (e.g. MIPS & ARM), and, finally, CPUs supports both of 64- and 32bit ABI. I think gcc config-ml.in is designed to build libraries for various configuration at once, but it's not designed to generate unified config.h. The goal of gcc config-ml.in is more generic than RedHat's 64bit-32bit issue, but more specified than that of libtool future plan. The goal of libtool multilib is, I guess, to build libraries at once, for more various configurations: archive/shared/debug/profiled (as X11), untuned/tuned (as GNU libc), and 32/64bit ABI. However, I don't think libtool is designed to distribute the header files to suitable directories (e.g. Linux's /usr/lib/freetype/include and /usr/lib64/freetype/include), nor designed to unify the header files (as my patch does). I think, such header file management is not libtool's business. Attached patch has ugly hook to flush informations (sizeof(int) and sizeof(long)) for the default configuration and reconfigure them for non-default target. I think it's not easy to maintain. Because, when a developer modifies configure.ac, he must care if it's reconfigured in multilib case and he must know how to reset cached informations (as I reset unset ac_cv_type_int etc). He have to keep the integrity among ft-uniconf.m4, configure.ac and ftconfig.in. This is troublesome work. Now I think, the next step to improve multilib support would be modification of freetype2/configure, instead of freetype2/builds/unix/configure. It's like gcc config-ml.in. By executing configure in separated directories, we can collect ftconfig.h files for each configuration easily, and exactly. I've already wrote several useful macros for multilib support (they are in ft-uniconf.h): * check how many object formats are available * check required CFLAG for specified object format * check CPP macro to specify the object format The left task is gathering ftconfig.h from each configured directories and merge them into single unified ftconfig.h. I will propose a patch for freetype2/configure to support. But, freetype2/configure has not been autoconfized, so I'm afraid I should not use macros in ft-uniconf.m4...? Werner, could you tell me about the restriction to modify that? Regards, mpsuzuki -- diff -NBurb -x {arch} -x '.*' freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac freetype2--mps-multilib--0.1--patch-11/builds/unix/configure.ac --- freetype2--mps-multilib--0.1--base-0/builds/unix/configure.ac 2005-12-31 19:19:10.0 +0900 +++ freetype2--mps-multilib--0.1--patch-11/builds/unix/configure.ac 2005-12-31 19:19:26.0 +0900 @@ -88,6 +89,23 @@ AC_CHECK_SIZEOF([long]) +# generate unified header file, if requested + +FT_UNICONF_ENABLE([uniconf_type]) +FT_UNICONF_CFLAGS_GETLIST([uniconf_type],[cflags_to_check]) +if test x"${uniconf_type}" != xno; then + FT_UNICONF_PROG_OBJDUMP([OBJDUMP],[objdump_filter]) +fi +if test x"${uniconf_type}" != xno && test x"${OBJDUMP}" != x; then + FT_UNICONF_MAKE_OBJFMT_LIST([${cflags_to_check}],[obj_fmt0 obj_fmt1],[objdump_filter]) + FT_UNICONF_GET_CFLAG_FOR_OBJFMT([${cflags_to_check}],[obj_fmt0],[cflag_fmt0],[objdump_filter]) + FT_UNICONF_GET_CFLAG_FOR_OBJFMT([${cflags_to_check}],[obj_fmt1],[cflag_fmt1],[objdump_filter]) +fi +if test x"${cflag_fmt0}" != x"${cflag_fmt1}"; then + FT_UNICONF_MAKE_ARCHDEP([arch_dep.tmp],[cflag_fmt0],[cflag_fmt1]) +fi + + # checks for library functions # Here we check whether we can use our mmap file component. @@ -168,8 +186,10 @@ AC_CONFIG_HEADERS([ftconfig.h:ftconfig.in], [mv ftconfig.h ftconfig.tmp sed 's|/undef|#undef|' < ftconfig.tmp > ftconfig.h +
Re: [ft-devel] MacOS-specific API regression test tool
happy new year! On Wed, 04 Jan 2006 18:15:08 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> Before posting jumbo patch for ftmac.c to fix deprecated FileManager >> & FontManager API issue, here is a dirty new year gift: small tool >> for regression-test of MacOS specific APIs. > >What about adding this to the CVS? Probably not building it by >default, but for reference. Thank you! I will add ftoldmac.c (any better name?) to ft2demos/mac/, and write ft2demos/mac/Makefile (for MacOS X) to build ftoldmac in the directory. I've already finished MPW makefile for m68k MacOS, and checked it works as expected. BTW, yet I've not checked if ftview_m.c, ftlint_m.c are ft2demos/mac/ are still usable. MacOS GUI application cannot receive argc/argv, so Just van Rossum wrote a hook to pass essential data via GUI menu. At present, it seems that only CodeWarrior target is prepared (no MPW targets are written). But, if these programs are executed via MPW shell, they can receive argc/argv. I think such are easier to maintain, because it will be almost platform independent. The left issue is that "how to display graphical results" by ftview & ftstring. I think, if they are enabled to work as fully commandline tool, they will be easier to maintain. I remember, a volunteer was wanted to add PNM output to ftstring, in Werner's post: Date: Fri, 07 Oct 2005 01:18:55 +0200 (CEST) Message-Id: <[EMAIL PROTECTED]> Subject: Re: [ft] Simple CL Tool From: Werner LEMBERG <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > >> > Why not using the `ftstring' demo program, then capturing the image? >> >> Probably becuase it's easier to just load a PNG file (or a BMP >> or a TIF or whatever) into an image viewer than it is to monkey >> around with a capturing images, etc. > >Well, it should be rather straightforward to add PNM output to >ftstring as an option (this can be then converted with, say, pnmtopng >or pnmtojpeg). Any volunteers? If there's nobody yet, I want to do that, although I cannot give the highest priority to this task. 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, On Sun, 08 Jan 2006 14:36:04 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> Finally I post my jumbo patch to fix "deprecated function >> XXX is used" issue on MacOS X 10.4, since 25/Aug/2005. > >In case you patch is ready for inclusion into the CVS, please do so. OK, I will commit the patch to CVS (although I wish if I could receive any comments by Sean). I've grepped Xcode (Apple's official SDK based on gcc) and applications on Mac OS X, and I could find no Apple application that requires FT_GetFile_From_Mac_Name() or FT_New_Face_From_FSSpec(), so I think my jumbo patch won't cause severe problem. I wrote detailed document about the deprecated function issue (as a patch to builds/mac/README). In the document, I refered my benchmarks of QuickDraw & ATSUI font name resolver (to notice that it's hard to provide QuickDraw compatible functions by ATS). If required, I can transfer the document onto FreeType website. Regards, mpsuzuki --- freetype2--official-maintrunk--0.1--patch-123/builds/mac/README 2006-01-10 14:18:36.0 +0900 +++ freetype2-macos/builds/mac/README 2006-01-10 14:13:27.0 +0900 @@ -18,6 +18,9 @@ However, Mac OS X is most useful to manipulate files in vanilla FreeType to fit classic MacOS. +The information about MacOS specific API is written in +appendix of this document. + 2. Requirement -- @@ -205,8 +208,190 @@ to MPW. To update classic MacOS support easily, building by Jam is expected on MPW. + +APPENDIX I +-- + + A-1. Framework dependencies + --- + + src/base/ftmac.c adds two Mac-specific features to + FreeType. These features are based on MacOS libraries. + + * accessing resource-fork font + The fonts for classic MacOS store their graphical data + in resource forks which cannot be accessed via ANSI C + functions. FreeType2 provides functions to handle such + resource fork fonts, they are based on File Manager + framework of MacOS. Following functions are for this + purpose. + +FT_New_Face_From_Resource() +FT_New_Face_From_FSSpec() +FT_New_Face_From_FSRef() + + * resolving font name to font file + The font menu of MacOS application prefers font name + written in FOND resource than sfnt resoure. FreeType2 + provides functions to find font file by name in MacOS + application, they are based on QuickDraw Font Manager + and Apple Type Service framework of MacOS. + +FT_GetFile_From_Mac_Name() +FT_GetFile_From_Mac_ATS_Name() + + Working functions for each MacOS are summarized as + following. + + upto MacOS 6: +not tested (you have to obtain MPW 2.x) + + MacOS 7.x, 8.x, 9.x (without CarbonLib): +FT_GetFile_From_Mac_Name() +FT_New_Face_From_Resource() +FT_New_Face_From_FSSpec() + + MacOS 9.x (with CarbonLib): +FT_GetFile_From_Mac_Name() +FT_New_Face_From_Resource() +FT_New_Face_From_FSSpec() +FT_New_Face_From_FSRef() + + Mac OS X upto 10.4.x: +FT_GetFile_From_Mac_Name() deprecated +FT_New_Face_From_FSSpec() deprecated +FT_GetFile_From_Mac_ATS_Name() deprecated? +FT_New_Face_From_FSRef() + + A-2. Deprecated Functions + - + +A-2-1. FileManager +-- + +For convenience to write MacOS application, ftmac.c +provides functions to specify a file by FSSpec and FSRef, +because the file identification pathname had ever been +unrecommended method in MacOS programming. + +Toward to MacOS X 10.4 & 5, Carbon functions using FSSpec +datatype is noticed as deprecated, and recommended to +migrate to FSRef datatype. The big differences of FSRef +against FSSpec are explained in Apple TechNotes 2078. + +http://developer.apple.com/technotes/tn2002/tn2078.html + +- filename length: the max length of file +name of FSRef is 255 chars (it is limit of HFS+), +that of FSSpec is 31 chars (it is limit of HFS). + +- filename encoding: FSSpec is localized by +legacy encoding for each language system, +FSRef is Unicode enabled. + +A-2-2. FontManager +-- + +Following functions receive QuickDraw fontname: + + FT_GetFile_From_Mac_Name() + +QuickDraw is deprecated and replaced by Quartz +since Mac OS X 10.4. They are still kept for +backward compatibility. By undefinition of +HAVE_QUICKDRAW in building, you can change these +functions to return FT_Err_Unimplemented always. + +Replacement functions are added for migration. + + FT_GetFile_From_Mac_ATS_Name() + +They are usable on Mac OS X only. On older systems, +these functions return FT_Err_Unimplemented always. + +The detailed incompatibilities and possibility +of FontManager emulation without QuickDraw is +explained in + + http://www.gyve.org/~mpsuzuki/ats_benchmark.html + + A-3. Framework Availabilities + -
Re: [ft-devel] Freetype on Mac uses deprecated functions
Hi, Sean, Thank you for comment! Just I've commited my jumbo patch to CVS. On Tue, 10 Jan 2006 11:47:53 -0500 "Sean McBride" <[EMAIL PROTECTED]> wrote: >On 2006-01-10 14:34, [EMAIL PROTECTED] said: > Finally I post my jumbo patch to fix "deprecated function XXX is used" issue on MacOS X 10.4, since 25/Aug/2005. >>> >>>In case you patch is ready for inclusion into the CVS, please do so. >> >>OK, I will commit the patch to CVS (although I wish if >>I could receive any comments by Sean). >> >>I've grepped Xcode (Apple's official SDK based on gcc) >>and applications on Mac OS X, and I could find no Apple >>application that requires FT_GetFile_From_Mac_Name() or >>FT_New_Face_From_FSSpec(), so I think my jumbo patch >>won't cause severe problem. > >I only use freetype indirectly by using vtk. I have checked the vtk >source and it uses neither of those two functions. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] MacOS-specific API regression test tool
Hi, On Thu, 05 Jan 2006 07:25:48 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >> >What about adding this to the CVS? Probably not building it by >> >default, but for reference. >> >> Thank you! I will add ftoldmac.c (any better name?) to >> ft2demos/mac/, and write ft2demos/mac/Makefile (for MacOS X) to >> build ftoldmac in the directory. I've already finished MPW makefile >> for m68k MacOS, and checked it works as expected. > >Thank you in advance. Just I've added ftoldmac.c & makefiles into ft2demos/mac/ in CVS. To build ftoldmac.c on MacOS X, typing "make -C mac" in ft2demos top directory is enough. Update of ft2demos/mac/README is not completed, because the old works by Just van Rossum (written for CodeWarrior) is not updated yet, I added only short note about ftoldmac. The step-by-step usage (e.g. how to use it regression test) is not described yet. If it's essential, I'll write more. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] is it possible to retrieve whole kerning table?
Hi, >I am trying to figure out how to implement WIN32 GetKerningPairs[1] function >in Wine. Unfortunately, I can't find a similar function in freetype API. >There is FT_Get_Kerning, but in order to build a whole table I would need to >know all the kerning pairs in a font, or brute-force check all >combinations :) Yes, current FreeType2 does not provide the functions like Win32 GetKerningPairs(). I think, such functions require large memory allocation to load whole of kern subtable. Due to memory alignment and byte order (Win32 struct KERNINGPAIR looks native byte order - the size and byte order is exactly same among all platforms?), passing the pointer to the memory image of kern subtable is not enough. We have to rewrite all entries explicitly. My propose is writing a simple function to: pickup file stream or memory image from font object loaded by FreeType, allocate memory to store converted kern subtable, and convert the entries internally (without kern table handler of FreeType2). By conversion without FreeType, the conversion time can be minimized. BTW, if kern table has multiple subtables, how WIN32 API choose the "best" subtable? The device context is used? There are a "cross-platform" issue to discuss. Microsoft supports kern subtable format 0 only, but there are two dialects in format 0: Microsoft and Apple. For detail, please check freetype2/src/gxvalid/README in latest CVS version of freetype2, or viewCVS: http://cvs.savannah.nongnu.org/viewcvs/freetype2/src/gxvalid/README?rev=1.2&root=freetype&view=markup In the rendering procedure, FreeType2 supports horizontal kerning in Microsoft dialect only. For example, FreeType2 does not count the number of entries in vertical kerning table, even in Microsoft dialect. Other formats (Apple dialect, new formats 1, 2, 3) are not used at all. It it expected behaviour? I think some people want WINE to run on MacOS X, with TrueType fonts bundled to MacOS X. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] is it possible to retrieve whole kerning table?
Hi, On Sat, 14 Jan 2006 15:46:03 +0100 (CET) Werner LEMBERG <[EMAIL PROTECTED]> wrote: >>>I am trying to figure out how to implement WIN32 GetKerningPairs[1] >>>function in Wine. Unfortunately, I can't find a similar function >>>in freetype API. >> >>Yes, current FreeType2 does not provide the functions like Win32 >>GetKerningPairs(). >>We have to rewrite all entries explicitly. > >I have the feeling that such a function doesn't belong to FreeType but >should be added one level higher. Talking personally, as you say, such a function should be out of FreeType. Although I'm not sure how many, I guess many functions should be written to emulate font functions in Win32 GDI, and there's possibility that Win32 specific datatypes & macros are required (for GetLastError). It's too early to decide whether a module for Win32 GDI emulation is reasonable, I think. # I suppose, GetKerningPairs() assumes that the font # data is already validated/restructured and loaded # onto kernel space memory, so GetKerningPairs() just # lookups the header of subtable and returns it. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] when does the next version of freetype release?
Hi, On Wed, 18 Jan 2006 11:18:00 +0100 david turner <[EMAIL PROTECTED]> wrote: >> And will the major .so version be bumpped up? >> >Nope, because this would create problems as Owen Taylor pointed out, >since through indirect linking, a given program might find itself dependent >on both libfreetype6 and libfreetype7, which could cause major problems >depending on the code paths being used. Could you tell me about the condition that libfreetype.so "must" bump its major version? Today FreeType is very widely used as the most important foundation for text rendering, and the request for full binary compatibility (unfortunately, including internal functions, internal data types, macros, etc etc :-)) is getting stronger and stronger, I'm afraid. Some people may want libfreetype3.so.X instead of libfreetype.so.7. Regards, mpsuzuki ___ 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 CVSROOT :pserver:[EMAIL PROTECTED]:/cvsroot/freetype + align=center>:pserver:[EMAIL PROTECTED]:/cvsroot/freetype When asked for a password, simply press Enter for cvs login. The module names are freetype (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 @@ Use anonymous CVS access + GNU 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. The FreeType sources can be downloaded to you through CVS. Use the following value for CVSROOT ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Freetype crashes on ARM
Hi, On Thu, 26 Jan 2006 09:54:24 +0100 Frank Meerkoetter <[EMAIL PROTECTED]> wrote: >i'm using poppler(xpdf derived) and freetype on an ARM based system >to render pdf documents. >I encounter crashes when loading documents which contained embedded >Type1 fonts. The crashes were due to "Illegal Intructions". >I could track it down to FT_Get_Name_Index(). I will check the issue, could you provide sample PDF to crash poppler? And, it can crash xpdf too? # my ARM box is not tuned for Desktop environment, so # I have to build xpdf and poppler by myself. Please # give me a few weeks. Regards, mpsuzuki ___ 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 Just I've built libttf.a successfully. Following is my procedure: 0. install autoconf-2.54 I suppose older (2.52 etc) can work, but I don't know the lowest version. 1. unpack freetype-1.3.1 2. fix freetype-1.3.1/configure.in remove the line "AC_REQUIRE([AC_PROG_MAKE_SET])" which newer autoconf cannot handle correctly. 3. rebuild configure by "autoconf -I ." 4. configure for cross building ./configure \ --disable-shared --enable-static \ --host=arm-uclibc-linux --build=arm-linux 5. check the compiler is arm-uclibc-linux-gcc, instead of gcc. 6. make Regards, mpsuzuki On Tue, 21 Feb 2006 13:02:14 +0900 [EMAIL PROTECTED] wrote: >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
[ft-devel] Re: [ft-cvs] freetype2 ./ChangeLog src/sfnt/ttmtx.c
Hi, On Tue, 21 Feb 2006 17:06:35 + David Turner <[EMAIL PROTECTED]> wrote: >CVSROOT: /cvsroot/freetype >Module name: freetype2 >Branch: >Changes by:David Turner <[EMAIL PROTECTED]>06/02/21 17:06:35 > >Modified files: > . : ChangeLog > src/sfnt : ttmtx.c > >Log message: > * src/sfnt/sfmtx.c: disabling memory optimization when > FT_CONFIG_OPTION_OLD_INTERNALS is used. This is because libXfont > is directly accessing the HMTX data. Gr Now you're working for libXfont from the side of FreeType? I was working for libXfont to build with FreeType-2.2 with correct manner (my scratch is available https://www.codeblog.org/blog/mpsuzuki/20060211.html), but my work is now stopped because I found that libXfont accesses internal TrueType font table directly, as you pointed out, and I didn't have quick fix. If you have any comment to libXfont side, please let me know. However, the packages depending libXfont are small part of X11R7.0, and I'm looking for test tools for comprehensive regression test. 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=" -DFT2_BUILD_LIBRARY \ "-DFT_CONFIG_MODULES_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
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
Excuse me, I was misunderstanding new modularized building system. On Mon, 27 Feb 2006 13:28:57 +0900 [EMAIL PROTECTED] wrote: >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. In module.cfg, gxvalid, otvalid, ftgxval are disabled, but ftotval is enabled. I think ftgxval and ftotval are thin wrappers to provide public interface of gxvalid and otvalid modules. 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, except of the cases that the memory filled by these wrappers are not negligible (e.g. very small systems). If ftgxval/ftotval are always built, we can always build ftvalid, and ft2demos/Makefile is not needed to be modified. But, now I found that modules.cfg disables ftgxval. ft2demos/Makefile should be capable for such cases? 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] CJK rendering screenshots
Hi, On Thu, 04 May 2006 14:09:49 +0200 David Turner <[EMAIL PROTECTED]> wrote: >My first item is titled "improved CJK text rendering", and I'd like to add >some screenshots that demonstrate the improvements obtained by the >inclusion of FireFly's enhancements. > >However, I'm certainly not a native Chinese or Japanese speaker, and I >don't feel I have enough experience to choose an example that demonstrate >the improvements in a radical way. > >So, is anyone here willing to contribute two screenshots of the same >"scene" ?, one with FT 2.1.10 (or earlier), another one with FT 2.2, >demonstrating the changes to the full auto-hinting algorithm ? Of course I'm interested in. There's any requirement about font size, to match with screenshots for Roman alphabets? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Direct Rendering with Win32
Hi, You want FreeType to render glyphs by GDI vector graphic operations, instead of transfering rasterized bitmap data? Regards, mpsuzuki On Tue, 9 May 2006 17:04:26 -0600 "Murillo, Alex" <[EMAIL PROTECTED]> wrote: >Hello, > > > >I am attempting to render freetype glyphs directly into a windows device >context. In other words, I do not want glyphs rendered as bitmaps >because in print scenarios the print spooler becomes exponentially >larger than the original document size. Specifically, in our >application, text rendering uses the standard freetype mechanism (under >windows), which is to lookup the glyph, render the glyph, then take the >returned bitmap and BitBlt (GDI API) the bitmap into a memory compatible >device context (which is based on an actual device context e.g. screen >or printer...). As you might already recognize, in a print scenario we >simply reuse the display code to render text into the printer device >(instead of the screen). > > > >However, as stated before, this is the source of our problem because >ultimately the operation performed against the printer device is a >raster operation and not a vector operation. In my limited >understanding, the raster operation results in bitmaps actually pushed >into the postscript and not vector commands, which results in large >printer spool files (I have confirmed in testing). Incidentally, I have >scoured the web and this mail group but have not seen anyone who has >experienced this issue on any level. Nor have I have discovered anyone >who has made any attempt to direct render the glyphs into a windows >device context. Ironically, I have seen other font engines that use >freetype as their underlying font library, which seem to offer this >functionality. So, I have to believe this is possible. I'm still >searching but hope someone here has an answer, as I am running out of >options. > > > > > >Thanks Alex > > > > ___ 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 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
Re: [ft-devel] ftvalid
I think the original design (check face, then check tables, and finally check service-availability) was by Werner, on 2004. At that time, the modularization of validators was not expected. Please check: http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/base/ftotval.c?rev=1.1&view=markup Regards, mpsuzuki On Fri, 16 Jun 2006 06:17:44 +0900 (JST) Masatake YAMATO <[EMAIL PROTECTED]> wrote: >At George's suggestons, I've rewritten some part of ftvalid. >In my new code ftvalid tries to detect gxvalid is available >or not with following code: > > /* Checking availability of FT_TrueTypeGX_Validate > before running validator */ > error = FT_TrueTypeGX_Validate( NULL, 0, NULL, 0 ); > if ( error == FT_Err_Unimplemented_Feature ) > panic (error, "FT_TrueTypeGX_Validate is not available ); > >However, this code doesn't work. NULL and zero args are checked >before checking the module availability in FT_TrueTypeGX_Validate. > > FT_EXPORT_DEF( FT_Error ) > FT_TrueTypeGX_Validate( FT_Face face, > FT_UInt validation_flags, > FT_Bytes tables[FT_VALIDATE_GX_LENGTH], > FT_UInt table_length ) > { >FT_Service_GXvalidate service; >FT_Error error; > > >if ( !face ) >{ > error = FT_Err_Invalid_Face_Handle; <<<<<<<<<<<<<<<<<<<<<<<<< > goto Exit; >} > >if ( tables == NULL ) >{ > error = FT_Err_Invalid_Argument; <<<<<<<<<<<<<<<<<<<<<<<<<< > goto Exit; >} > >FT_FACE_FIND_GLOBAL_SERVICE( face, service, GX_VALIDATE ); > >if ( service ) > error = service->validate( face, > validation_flags, > tables, > table_length ); >else > error = FT_Err_Unimplemented_Feature; <<<<<<<<<<<<< FINALY... > > Exit: >return error; > } > > >I think FT_Err_Unimplemented_Feature should be returned immediately >if gxvalid module is not available. However, current implementation >requires non-NULL face and non-NULL tables in any case. >libfreetype2.so itself knows gxvalid module is available or not. > >Toshiya-san, do you remember who wrote this code? Did I? > >Masatake YAMATO ___ 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 #else @@ -74,6 +75,20 @@ #include #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 #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
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 #else #include #include +#include #include #include #include @@ -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