[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 tools. ***) There is one more Apple extension "hsty" but it is for Newton-OS,
Re: [ft-devel] [patch] TrueType GX/AAT validator
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 This is useful on the mac because only two substitutions can be made once a pattern has been matched. Suppose one wants to change "abcd" => "efgh" changing nothing until the "d" was read. This can't be done with a single state machine, but one way to do it would be to create two state machines, one which matches "abcd" and upon the match changes the "a" to GID65534, and a second which enters a magic state when it gets GID65534 which it changes to "e", changes "b"->"f", and so forth. A long winded explanation to say that out of bounds GIDs are not always undesirable -- as long as a later substitution will prevent them from reaching the output string. (I've been wrestling with this in fontforge for a while, trying to figure out what Zapfino was up to -- I think that's the gist of it) ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
Dear Mr. George Williams, On 22 Aug 2005 22:04:00 -0700 George Williams <[EMAIL PROTECTED]> wrote: >On Mon, 2005-08-22 at 18:29, [EMAIL PROTECTED] wrote: >> - state transition diagram uses undefined glyph ID >A note of caution here, the apple world makes use of undefined glyph IDs >as temporary state flags. One state machine will test for a condition >and apply a substitution which creates an invalid GID, then another >state machine will detect the bad GID, change it to something valid and >enter a new state where it does other substitutions. > Example font: Zapfino 4.1d6 Great Thank you for important information about the utilization undefined GID. At present, I cannot find Zapfino in my MacOS X (I'm not sure if I did misconfigured installation), so we have not tested the font. Please let me know where I can find Zapfino? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
on 8/22/2005 10:50 PM [EMAIL PROTECTED] wrote: 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 For this font (which is included in 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. Regards, Steve Hartwell http://stevehartwell.home.comcast.net/proj/fontinspector ___ 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] [patch] TrueType GX/AAT validator
On Mon, 2005-08-22 at 23:17, [EMAIL PROTECTED] wrote: > 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. I have one example font containing a kern format 1 table (which David Opstad, formerly at Apple, made for me). He did not say I should not distribute it so I shall pass it on to you (off list). The table specifies kerning for the three glyphs "F", "." and "quotedouble". Given the string 'F."' then the "F." pair is kerned by -382 the '."' pair is kerned by 0 Otherwise given '."' the pair is kerned by -526 Otherwise given "F." the pair is kerned by -382 (the final bit of a kerning offset in the ValueTable marks the end of the value list, so the kerning offset has a resolution of 2 FUnits rather than 1, thus the -382 above actually appears as -381) As with the ligature state machine, the offsets are applied as the glyphs are popped off the stack (which appears backwards). So in the F." case, first the " glyph is popped (with an offset of 0) and then the . glyph is popped (with an offset of -381). ___ 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
On Tue, 2005-08-23 at 08:18, [EMAIL PROTECTED] wrote: > 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. I think your summary matches what I said. > In addition, gxvalid doesn't check "temporal glyph ID" used in the > chained State Machines (in "mort" and "morx" tables). I've never seen it in a 'mort' table, it is much less likely to occur there. A 'morx' table allows a compact representation of substitution tables associated with a state machine, while a 'mort' table requires a per-glyph lookup. So using a glyph ID like 32000 (Zapfino does) would require a huge lookup. I would leave the check in but flag it as a warning myself > 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. Checking that they occur in the class table isn't a requirement since a substitution can occur on a glyph in class 1 (the class of unspecified glyphs). So a state machine >could< be built which made such GIDs vanish even if they didn't get named in the class table. > I think quick hack is not enough to solve this issue, > so I want to put it to TODO of gxvalid. Um... I think this is equivalent to the halting problem -- at least I think you'd want to run all secondary state machines and make sure they made the GIDs vanish in all possible contexts. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
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:-) (And there are certainly fonts which use feature numbers>255, Osaka.dfont for one) > (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) Given that features and settings are in some sense "defined" by the string(s) attached to them in the 'name' table to me it makes sense to allow a font to create its own text features rather than restricting them to the predefined list. Also my understanding is that there is a difference in philosophy between Apple & OpenType on features. Apple's feature/settings define something useful to the user, while OpenType features are expected to be a sub-part of a greater whole -- an application possibly combining several features to get a desired effect. If this is true it seems reasonable to me for a font to be able to define its own features. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
On Tue, 2005-08-23 at 14:50, George Williams wrote: > > 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. Sorry I didn't finish... I think the real reason feature/settings must be extensible (use numbers not defined in Apple's Registry) is that there would be no need for the 'feat' table otherwise -- it conveys no information that is not already in the registry. 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. 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. Or did you mean that 'morx' referred to a feature not defined in 'feat'? That one should be illegal. 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. ___ 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] [patch] TrueType GX/AAT validator
On Tue, 2005-08-23 at 18:06, [EMAIL PROTECTED] wrote: > I agree. I remove it from the error list. Yes, sorry about that. > 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, > 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? I haven't the faintest idea. You might be right. It didn't occur to me. But AquaKanaRegular.dfont (Copyright Apple) uses feature 27 for Unicode decomposition. > >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: > [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. My thought is that if the setting is defined in the 'feat' table then it's ok to use in mort/morx. (or in the case of a non-exclusive feature, if the even version of the setting is defined, the odd never seems to be). I don't know, I just don't see any limits placed on the use of feature/settings in the docs... so my tendency is to assume there are none. Just as a type designer might need extra features, I expect one might decide that s/he needed extra settings, for example a way to turn off long-s ligatures in a latin font, or perhaps a way to turn on or off ligatures depending on different styles of arabic writing. Unfortunately the courier on my Mac 9.0.4 does not have the version of courier you describe so I could not check and see if this is what happened there. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [patch] TrueType GX/AAT validator
on 8/23/2005 1:57 PM George Williams wrote: In addition, gxvalid doesn't check "temporal glyph ID" used in the chained State Machines (in "mort" and "morx" tables). I've never seen it in a 'mort' table, it is much less likely to occur there. A 'morx' table allows a compact representation of substitution tables associated with a state machine, while a 'mort' table requires a per-glyph lookup. So using a glyph ID like 32000 (Zapfino does) would require a huge lookup. No, if I recall correctly the glyph action table is trimmed, so an action table containing large glyph IDs would not necessarily be huge. At any rate, these transient glyph IDs have been used since 'mort' tables were introduced; 'morx' is just a longword-aligned version of 'mort'. --- to: [EMAIL PROTECTED] George is correct in suggesting that to verify all correct use of these transient glyph IDs, you would have to run all the state machines (the "halting" problem). However, a reasonable shortcut would be to examine all of the glyph action tables, and to verify that for any "anyGlyphID -> aTransientGlyphID" mapping (where 'aTransientGlyphID' is an id greater than the number of actual glyphs) that there is a corresponding "aTransientGlyphID -> anyGlyphID" somewhere else in the same chain. This is not a comprehensive check, since there is no guarantee that the substitution actually occurs, but as a longtime 'mort/morx' table developer, I would say that this would cover a large part of the errors in practice. If you have not already done so, reading the ICU layout sources might shed some light on some of the many good questions raised on this thread. Thanks very much for your fine work on this validator; I'm looking forward to using (and possibly extending) it when my free time permits, Regards, Steve Hartwell http://stevehartwell.home.comcast.net/proj/fontinspector ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
