Font::TTF::Ttopen(3)

πŸ’… NAME πŸ’…

okay so bestie, welcome to the Font::TTF::Ttopen era β€” this is a page from the User Contributed Perl Documentation (iykyk, the classic Perl manpage vibes), and the whole thing is literally just one little module with main character energy πŸŽ€

Font::TTF::Ttopen β€” it's the Opentype superclass for the standard Opentype lookup-based tables, aka GSUB and GPOS ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so picture this: Font::TTF::Ttopen is the momager πŸ‘‘ of the operation. It handles all the script, lang, feature, lookup stuff for a Font::TTF::Gsub / Font::TTF::Gpos table β€” like, every single bit of that shared machinery? yeah, she's got it πŸ’…

and then the ✨*class specifics*✨ are left to the subclass, because Font::TTF::Ttopen is generous like that 🫢 she does the heavy lifting, the subclass gets to be its own special little guy 🌸

ngl that's the whole page for part 1 β€” the vibe check is: superclass handles the shared script/lang/feature/lookup business, subclass handles the rest πŸ’–

πŸ’… INSTANCE VARIABLES πŸ’…

okay so the instance variables of an opentype table are not a flat list, bestie β€” they form a whole complex sub-module hierarchy, like a group chat with sub-group chats, and each sub-group chat has its own sub-group chat. buckle up πŸŽ€


✨ Version ✨

  • Version β€” this holds the version of the table, stored as a floating point number. that's it, that's the whole vibe ✨

πŸŽ€ SCRIPTS πŸŽ€

The scripts list is a hash of script tags. Every script tag β€” which you grab as $t->{'SCRIPTS'}{$tag} β€” has the following info hanging off it:

  • OFFSET β€” heads up, this variable is preceded by a space πŸ‘€ (yes fr, the key literally starts with a space). it gives the offset from the start of the table β€” not the table section β€” to the script table for this script.
  • REFTAG β€” also preceded by a space! this gives a corresponding script tag to this one, such that the offsets in the file are the same. when writing, it's up to you, the caller, to make sure the REFTAGs are set correctly, because they get used to assume that the scripts are identical. and ngl, watch out: REFTAG must refer to a script that has no REFTAG of its own. no tag-chains, no recursion, we don't do that here πŸ’€
  • DEFAULT β€” this corresponds to the default language for this script, if there even is one, and it contains the exact same information as an itemised language does.
  • LANG_TAGS β€” this contains an array of language tag strings (each one is 4 bytes) corresponding to the languages listed by this script.
  • $lang β€” each language is a hash containing its own info, and the keys are:
    • OFFSET β€” again preceded by a space 🫢. gives the offset from the start of the whole table to the language table for this language.
    • REFTAG β€” preceded by a space, same exact job as the script REFTAG, only it's for the languages within a script.
    • RE-ORDER β€” this indicates re-ordering information, and honestly it has not been set. the value should always be 0. periodt.
    • DEFAULT β€” this holds the index of the default feature, if there is one, or -1 otherwise.
    • FEATURES β€” an array of feature tags for all the features enabled for this language 🌸

πŸ”₯ FEATURES πŸ”₯

The features section of instance variables corresponds to the feature table in the opentype table. it's giving very organised.

  • FEAT_TAGS β€” this array gives the ordered list of feature tags for this table. it gets used during reading and writing for converting between feature index and feature tag πŸ”

The rest of the FEATURES variable is itself a hash based on the feature tag for each feature. every single feature has this structure:

  • OFFSET β€” this attribute is preceded by a space, and it gives the offset relative to the start of the whole table of this particular feature.
  • PARMS β€” if FeatureParams are defined for this feature, this contains a reference to the corresponding FeatureParams object. otherwise it's set to null. no params, no problem πŸ™ˆ
  • LOOKUPS β€” an array containing indices to lookups in the LOOKUP instance variable of the table.
  • INDEX β€” gives the feature index for this feature, and it's used during reading and writing for converting between feature tag and feature index. the round trip is real πŸ’…

πŸ‘‘ LOOKUP πŸ‘‘

This variable is an array of lookups, in order, and it's indexed via the features of a language of a script. each lookup contains subtables and other info, like:

  • OFFSET β€” this name is preceded by a space, and it contains the offset from the start of the table to this particular lookup.
  • TYPE β€” this is a subclass specific type for a lookup. it stipulates the type of lookup and hence the subtables within the lookup.
  • FLAG β€” holds the lookup flag bits ⭐
  • FILTER β€” holds the MarkFilteringSet (that is, the index into GDEF->MARKSETS) for the lookup.
  • SUB β€” this holds an array of subtables which are subclass specific. every subtable must have an OFFSET. the other variables described right here are an abstraction used in both the GSUB and GPOS tables β€” which are the target subclasses of this class, iykyk.
    • OFFSET β€” preceded by a space, gives the offset relative to the start of the table for this subtable.
    • FORMAT β€” gives the sub-table sub format for this GSUB subtable. it's assumed that this value is correct when it comes time to write the subtable πŸ‘€
    • COVERAGE β€” most lookups consist of a coverage table corresponding to the first glyph to match. the offset of this coverage table is stored here, and the coverage table gets looked up against the GSUB table proper. there are two lookups that don't have this initial coverage table β€” that one's used to index into the RULES array. these lookups have one element in the RULES array, and it's used for the whole match.
    • RULES β€” okay this one's a whole complex array, buckle up πŸ¦‹. in most cases, each element of the array corresponds to an element in the coverage table (governed by the coverage index). in a few cases β€” like when there's no coverage table β€” there's considered to be only one element in the rules array. each element of the array is itself an array, corresponding to the possibly multiple string matches which may follow the initial glyph. each element of that array is a hash with fixed keys corresponding to the info needed to match a glyph string or act upon it. so basically: the RULES element is an array of arrays of hashes, and those hashes contain these keys 🫢
      • MATCH β€” contains a sequence of elements held as an array. the elements may be glyph ids (gid), class ids (cids), or offsets to coverage tables. each element corresponds to one glyph in the glyph string. see MATCH_TYPE for the deets on how the different element types are marked πŸ”
      • PRE β€” this array holds the sequence of elements preceding the first match element, and it has the same form as the MATCH array.
      • POST β€” this array holds the sequence of elements to be tested for following the match string, and it's of the same form as the MATCH array.
      • ACTION β€” this array holds the info about what should be done if a match is found. the array may either hold glyph ids (which get used to replace or insert or whatever glyphs in the glyph string), or 2 element arrays consisting of:
        • OFFSET β€” offset from the start of the matched string that the lookup should start at when processing the substring.
        • LOOKUP_INDEX β€” the index to a lookup to be acted upon on the match string πŸ‘‘
    • CLASS β€” for those lookups which use class categories rather than glyph ids for matching, this is the offset to the class definition used to categories glyphs in the match string.
    • PRE_CLASS β€” the offset to the class definition for the before-match glyphs.
    • POST_CLASS β€” the offset to the class definition for the after-match glyphs.
    • ACTION_TYPE β€” this string holds the type of information held in the ACTION variable of a RULE. it's subclass specific 🌈
    • MATCH_TYPE β€” this holds the type of information in the MATCH array of a RULE. also subclass specific.
    • ADJUST β€” this corresponds to a single action for all items in a coverage table. the meaning is subclass specific.
    • CACHE β€” this key starts with a space πŸŽ€. it's a hash of other tables (such as coverage tables, classes, anchors, device tables) based on the offset given in the subtable to that other information. and ngl the documentation is particularly unhelpful here, because those tables are given as offsets relative to the beginning of the subtable, not the whole GSUB table 😭 this includes those items which are stored relative to another base within the subtable. yeah. we know. we're sorry.

🌟 METHODS 🌟

  • $t->read β€” Reads the table and hands control over to the subclass to deal with the subtable-specific details ✨
  • $t->read_sub($fh, $lookup, $index) β€” This stub lets subclasses read subtables of lookups in a table-specific way. You pass in a reference to the lookup plus the subtable index. The file is sitting at the start of the subtable to be read πŸŽ€
  • $t->extension() β€” Returns the lookup number for the extension table that allows access to 32-bit offsets πŸ”₯
  • $t->out($fh) β€” Writes this Opentype table to the output, calling $t->out_sub for each subtable at the appropriate point in the output. The assumption is that on entry the number of scripts, languages, features, lookups, etc. are all resolved and the relationships are fixed. This includes a LANG_TAGS list for a script, and that all scripts and languages in their respective dictionaries either have a REFTAG or contain real data πŸ‘‘
  • $t->num_sub($lookup) β€” Asks the subclass to count the number of subtables for a particular lookup and return that value. Used in out() πŸ’…
  • $t->out_sub($fh, $lookup, $index) β€” This stub lets subclasses output subtables of lookups in a table-specific way. You pass in a reference to the lookup plus the subtable index. The file is located at the start of the subtable to be output 🌸
  • $t->dirty β€” Setting GPOS or GSUB dirty means that OS/2 may need updating, so set it dirty πŸ’–
  • $t->maxContext β€” Returns the length of the longest opentype rule in this table πŸ“
  • $t->update β€” Performs various housekeeping items:
    • For all lookups, set/clear the 0x0010 bit of flag words based on 'FILTER' value.
    • Sort the COVERAGE table and RULES for all lookups.
    • Unless $t->{' PARENT'}{' noharmony'} is true, update will make sure that GPOS and GSUB include the same scripts and languages. Any added scripts and languages will have empty feature sets 🌈

🧰 Internal Functions & Methods 🧰

Most of these methods are used by subclasses for handling things like coverage tables, bestie 🫢

  • copy($ref) β€” Internal function to copy the top level of a dictionary to create a new dictionary. Only the top level is copied πŸŽ€
  • $t->read_cover($cover_offset, $lookup_loc, $lookup, $fh, $is_cover) β€” Reads a coverage table and stores the results in $lookup->{' CACHE'}, that is, if it has not been read already πŸ‘€
  • ref_cache($obj, $cache, $offset [, $template]) β€” Internal function to keep track of the local positioning of subobjects such as coverage and class definition tables, and their offsets. What happens is that the cache is a hash of subobjects indexed by the reference (using a string mashing of the reference name which is valid for the duration of the reference) and holds a list of locations in the output string which should be filled in with the offset to the subobject when the final string is output in out_final. Uses tricks for Tie::Refhash πŸͺ„
  • out_final($fh, $out, $cache_list, $state) β€” Internal function to actually output everything to the file handle, given that now we know the offset to the first subobject to be output and which subobjects are to be output and what locations need to be updated β€” we can now generate everything. $cache_list is an array of two-element arrays. The first element is a cache object, the second is an offset to be subtracted from each reference to that object made in the cache. If $state is 1, then the output is not sent to the filehandle and the return value is the string to be output. If $state is absent or 0, then output is not limited by storing in a string first and the return value is "" πŸ’Ύ
  • $self->read_context($lookup, $fh, $type, $fmt, $cover, $count, $loc) β€” Internal method to read context (simple and chaining context) lookup subtables for the GSUB and GPOS table types. The assumed values for $type correspond to those for GSUB, so GPOS should adjust the values upon calling 🧚
  • $self->out_context($lookup, $fh, $type, $fmt, $ctables, $out, $num) β€” Provides shared behaviour between GSUB and GPOS tables during output for context (chained and simple) rules. In addition, support is provided here for type 4 GSUB tables, which are not used in GPOS. The value for $type corresponds to the type in a GSUB table, so calling from GPOS should adjust the value accordingly πŸ¦‹

πŸ’€ BUGS πŸ’€

  • No way to share cachable items (coverage tables, classes, anchors, device tables) across different lookups. The items are always output after the lookup and repeated if necessary. Within lookup sharing is possible 😭

πŸ‘‘ AUTHOR πŸ‘‘

Martin Hosken, http://scripts.sil.org/FontUtils πŸ’–


πŸ“œ LICENSING πŸ“œ

Copyright (c) 1998-2016, SIL International (http://www.sil.org)

This module is released under the terms of the Artistic License 2.0. For details, see the full text of the license in the file LICENSE πŸŽ€


Okay that’s the whole page, bestie πŸ’– β€” this one came from perl v5.42.0, dated 2016-08-28. Byeee! πŸ‘‘βœ¨

πŸ“¦ where this page comes from