1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
|
= Graphite Table Format =
:docinfo:
:numbered:
== Introduction ==
The Graphite font table format is structured in order that a Graphite binary
description may be incorporated into a TrueType font. Thus the binary format
uses the TrueType table structure, identically to how it is used in a TrueType
font. The only difference between using an external file containing Graphite
binary information in tables, and inserting the binary information into tables
in the font is that tables are considered local to their file and are considered
to override those found in the font file. This allows there to be multiple,
independent descriptions held in separate files. Those independent descriptions
would have to be merged, in a way described in this document, if they were to be
held together in the same font file or binary file.
The description consists of a set of table descriptions. The format of a file
follows that of a TrueType font containing only those tables pertinent to the
description (i.e. for a separate binary description, those tables listed here).
As is standard for all TrueType tables, the data is in big-endian format
(most significant byte first).
== Version ==
This file describes version 4.0 of the Graphite font table specification.
Modifications from previous versions are indicated in the “Version notes” column
of the various tables.
== Tables ==
This document describes several additional TrueType table types. The “Silf” and
“Sile” tables are unique to the needs of Graphite, whilst “Gloc” and “Glat”
provide an extended glyph attribute mechanism. The “Feat” table is based very
closely on the GX “feat” table. (If necessary the tables could be restructured
to be stored inside the single “Silf” table.) In addition, use is made of the
“name” table type.
This version of the Graphite format includes the ability to compress “Glat” and
“Silf” tables, the extensions to those table provide a compression scheme field
permitting up to 32 compression schemes. Currently only 2 schemes are defined:
0 – no compression, and 1 – an LZ4 block decompressor. This is not the LZ4
framing format just the inner block level format without any checksum.
All compressed tables have the same form the original table's 32bit version
number followed by a 32 bit compression header. This consists of the top 5 bits
for the scheme and 27 remaining bits for the uncompressed table size. This is
then followed by the compression scheme's data.
[[comp_table]]
.Compressed table
[cols="3,3,8,3",options="unbreakable,header,compact",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Uncompressed Table version number |
|ULONG:5 |scheme |Compression scheme must not be 0 |5.0 – added
|ULONG:27 |full_size |Size of uncompressed table |5.0 – added
|BYTE[] |compressed_data |Compression scheme data |5.0 – added
|===============================================================================
The uncompressed form is the complete table including the version number but
with the scheme always set to 0. The remaining 27 bits are available to the
uncompressed table.
=== Glat ===
The Glat table type is used for storing glyph attributes. Each glyph may be
considered to have a sparse array of, at the most, 65536 16-bit signed
attributes. The Glat table is the mechanism by which they are stored.
The Glat table consists of a table header and an array of Glat_entry items. Two
formats for the Glat table are typically used. Most fonts will use a version 2
table without Octabox metrics. Those few fonts that have collision avoidance
support, will use a version 3 table.
.Glat version 2
[cols="3,3,8,3",options="unbreakable,header,compact",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00030000 |4.0 – 00020000
|Glat_entry[] |entries |Glyph attribute entries |
|===============================================================================
.Glat version 3
[cols="3,3,8,3",options="unbreakable,header,compact",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00030000 |5.0 – 00030000
|ULONG:5 |scheme |Compression scheme must be 0 |5.0 – added
|ULONG:28 |reserved | |5.0 – added
|ULONG:1 |octaboxes |Octaboxes are present flag |5.0 – added
|Glyph_attrs[] |entries |Glyph attribute entries |
|===============================================================================
For the compressed layout see <<comp_table>>.
.Glyph_attrs
[cols="3,3,8,3",options="unbreakable,header,compact",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|Octabox_metrics |octabox |Octabox metrics, only present if
the Glat header indicates |5.0 – added
|Glat_entry[] |entries |Glyph attribute entries |
|========================================================================
If the octaboxes flag is set in the Glat header then for each per glyph block
of data specified by the Gloc table, first set of data includes metrics that
approximate the glyph’s curves. The approximation uses “octoboxes”—rectangles
with corners that may be cut out at an angle of 45 degrees. Each octobox
requires 8 values to define. There are metrics for the entire glyph and for a
4x4 approximation grid, resulting in up to 16 sub-boxes. For some glyphs, no
sub-box data will be present, in which case the bitmap will be zero. Note that
the rectangle for the full glyph is not included here, as the bounding box
rectangle is stored elsewhere in the font.
.Octabox_metrics
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|USHORT |subbox_bitmap |Which subboxes exist on 4x4 grid; +
bit-index = (y-index*4) + x-index |
|BYTE |diag_neg_min |Defines min negatively-sloped diagonal (di) |
|BYTE |diag_neg_max |Defines max negatively-sloped diagonal (da) |
|BYTE |diag_pos_min |Defines min positively-sloped diagonal (si) |
|BYTE |diag_pos_max |Defines max positively-sloped diagonal (sa) |
|Subbox_entry[] |subboxes |One entry per bit in subbox_bitmap |
|===============================================================================
Note that in the subbox bitmap, bit 3 indicates the presence of the lower right
cell, and bit 12 the upper left cell as per this diagram.
.subbox_bitmap
[cols=",,,",width="20%",grid="all"]
|==============
|12 |13 |14 |15
| 8 | 9 |10 |11
| 4 | 5 | 6 | 7
| 0 | 1 | 2 | 3
|==============
.Subbox_entry
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|BYTE |left |Left of subbox |
|BYTE |right |Right of subbox |
|BYTE |bottom |Bottom of subbox |
|BYTE |top |Top of subbox |
|BYTE |diag_neg_min |Defines min negatively-sloped diagonal (si) |
|BYTE |diag_neg_max |Defines max negatively-sloped diagonal (sa) |
|BYTE |diag_pos_min |Defines min positively-sloped diagonal (di) |
|BYTE |diag_pos_max |Defines max positively-sloped diagonal (da) |
|===============================================================================
Following the glyph curve approximation data, the glyph attributes appear. The
glyph attributes associated with a particular glyph are identified by number and
value. To conserve space, this storage is run-length encoded. Thus a glyph will
have a series of Glat_entrys corresponding to each non-contiguous set of
attributes. The structure of a Glat_entry is:
.Glat_entry, version 2 & 3
[cols="2,2,8,5",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|USHORT |attNum |Attribute number of first attribute |4.0 – BYTE to SHORT
|USHORT |num |Number of attributes in this run |4.0 – BYTE to SHORT
|SHORT |attributes[] |Array of num attributes |
|===============================================================================
Notice that all glyph attributes are 16-bit signed values. If a 32-bit value is
required, then two attributes should be assigned and joined together by
the application.
Attribute numbers are application specific.
Note that if the font does not require more than 256 glyph attributes, version 1
of the Glat table will be generated, which is defined as follows.
.Glat version 1
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00010000 |
|Glat_entry[] |entries |Glyph attribute entries |
|===============================================================================
.Glat_entry, version 1
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|BYTE |attNum |Attribute number of first attribute |
|BYTE |num |Number of attributes in this run |
|SHORT |attributes[] |Array of num attributes |
|===============================================================================
=== Gloc ===
The Gloc table is used to index the Glat table. It is structured identically to
the loca table type, except that it has a header.
TODO: add a field indicating the number of glyphs in the table (the current
dependence on the Silf table is not architecturally clean).
.Gloc
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00010000 |
|USHORT |flags |bit 0 = 1 for Long format,
0 for short format; +
bit 1 = 1 for attribute names,
0 for stripped |
|USHORT |numAttribs |Number of attributes |
|USHORT/ULONG |locations[] |Offsets into Glat for each glyph; +
(number of glyph IDs + 1) of these |
|USHORT |attribIds[] |Debug id for each attribute |
|===============================================================================
A version 1.1 (0x00010001) table indicates that the Glat table has octabox
information. But such a version is not required in that case.
The flags entry contains a bit to indicate whether the locations array is of
type USHORT or ULONG. The locations array is identically structured to that of
the loca table. There is one entry per glyph and an extra entry to identify the
length of the final glyph’s attribute entries. Offsets are given to a Glat_entry
in the Glat table. The second bit indicates whether there is an attribIds array
at the end of this table. If there is, then it contains name IDs for each
attribute. If this bit is not set, then there is no array and the table ends
after the locations array.
As of version 2 of the Silf table, the values of the breakweight attribute are
interpreted as follows:
....
BREAK_WHITESPACE = 10
BREAK_WORD = 15
BREAK_INTRA = 20
BREAK_LETTER = 30
BREAK_CLIP = 40
....
=== Feat ===
Graphite stores features in a table whose format is very similar to the GX feat
table. This makes reference to the name table which is use for storing feature
names and feature value names.
.Feat
[cols="3,3,8,5",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00020001 |
|USHORT |numFeat |Number of features |
|USHORT |reserved | |
|ULONG |reserved | |
|FeatureDefn |features[] |Array of numFeat features |
|FeatureSettingDefn |featSettings[] |Array of feature setting
values, indexed by offset |
|===============================================================================
.FeatureDefn
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|ULONG |id |Feature ID number |2.0 – added
|USHORT |numSettings |Number of settings |
|USHORT |reserved | |2.0 – inserted
|ULONG |offset |Offset into featSettings list |
|USHORT |flags | |2.1 - reserved to flags
|USHORT |label |Index in name table for UI label |
|===============================================================================
The flags value has its own bit structure:
.FeatureFlags
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Bits |Mask |Description |Version notes
|0 |0x0001 |This feature is an alias of the previous one. |2.1 - added
|1-15 |0xFFFE |Reserved |
|===============================================================================
.FeatureSettingDefn
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|SHORT |value |Feature setting value |
|USHORT |label |Index into name table for UI label |
|===============================================================================
=== Silf ===
The “Silf” table will be used for storing rules and actions for the various
types of tables in a rendering description. The structure of the Silf table is:
.Silf
[cols="2,3,8,5",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00050000 |2.0 – changed to 00020000
| | | |3.0 – changed to 00030000
| | | |5.0 – changed to 00050000
|ULONG:5 |scheme |scheme must be 0 |5.0 – added
|FIXED:27 |compilerVersion |Compiler version that
generated this font |3.0 – added +
5.0 – changed to 27 bits
|USHORT |numSub |Number of SIL subtables |
|USHORT |reserved | |
|ULONG |offset[] |Array of numSub offsets to
the subtables relative to
the start of this table |
|SIL_Sub |tables[] |Array of independent
rendering description
subtables |
|===============================================================================
For the compressed layout see <<comp_table>>. Since one TrueType file may hold
multiple independent rendering descriptions, each rendering description is
described in a subtable. The subtable contains all that is necessary to describe
the rendering of one set of writing systems.
.SIL_Sub
[cols="4,6,28,7",options="header",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |ruleVersion |Stack-machine language version |3.0 – added
|USHORT |passOffset |offset of oPasses[0] relative to
start of sub-table |3.0 – added
|USHORT |pseudosOffset |offset of pMaps[0] relative to
start of sub-table |3.0 – added
|USHORT |maxGlyphID |Maximum valid glyph ID (including
line-break & pseudo-glyphs) |
|SHORT |extraAscent |Em-units to be added to the
font’s ascent |
|SHORT |extraDescent |Em-units to be added to the
font’s descent |
|BYTE |numPasses |Number of rendering description
passes |
|BYTE |iSubst |Index of 1st substitution pass |
|BYTE |iPos |Index of 1st Positioning pass |
|BYTE |iJust |Index of 1st Justification pass |
|BYTE |iBidi |Index of 1st pass after the
bidi pass(must be <= iPos); +
0xFF implies no bidi pass |
|BYTE |flags |0 - has line end contextuals, +
1 - contextuals, +
2-4 - space contextuals, +
5 - has collision pass |4.0 – add Bit 1
|BYTE |maxPreContext |Max range for preceding
cross-line-boundary contextualization |
|BYTE |maxPostContext |Max range for following
cross-line-boundary contextualization |
|BYTE |attrPsuedo |Glyph attribute number that is
used for actual glyph ID for a
pseudo-glyph |
|BYTE |attrBreakWeight |Glyph attribute number of
breakweight attribute |
|BYTE |attrDirectionality |Glyph attribute number for
directionality attribute |
|BYTE |attrMirroring |Glyph attribute number for
mirror.glyph (mirror.isEncoded
directly after) |2.0 – added; +
4.0 – used
|BYTE |attrSkipPasses |Glyph attribute of bitmap
indicating key glyphs for pass
optimization |2.0 – added; +
4.0 – used
|BYTE |numJLevels |Number of justification levels;+
0 if no justification |2.0 – added
|JestLevel |jLevels[] |Justification information for
each level. |2.0 – added
|USHORT |numLigComp |Number of initial glyph
attributes that represent
ligature components |
|BYTE |numUserDefn |Number of user-defined slot
attributes |
|BYTE |maxCompPerLig |Maximum number of components per
ligature |
|BYTE |direction |Supported direction(s) |
|BYTE |attCollisions |First of a set of attributes
that hold collision flags and
constraint box | 5.0 - used
|BYTE |reserved | |
|BYTE |reserved | |
|BYTE |reserved | |2.0 – added
|BYTE |numCritFeatures |Number of critical features |2.0 – added
|USHORT |critFeatures[] |Array of critical features |2.0 – added
|BYTE |reserved | |2.0 – added
|BYTE |numScriptTag |Number of scripts in scriptTag |
|ULONG |scriptTag[] |Array of script tags |
|USHORT |lbGID |Glyph ID for line-break
psuedo-glyph |
|ULONG |oPasses[] |Offets to passes relative to the
start of this subtable; +
numPasses + 1 of these |
|USHORT |numPseudo |Number of Unicode ->
pseudo-glyph mappings |
|USHORT |searchPseudo |(max power of 2 <= numPseudo)
* sizeof(PseudoMap) [Deprecated]|
|USHORT |pseudoSelector |log2(max power of 2<= numPseudo)
[Deprecated] |
|USHORT |pseudoShift |numPseudo - searchPseudo
[Deprecated] |
|PseudoMap |pMaps[] |Unicode ->pseudo-glyph mappings
in Unicode order |
|ClassMap |classes |Classes map storing replacement
classes used in actions |
|SIL_Pass |passes[]] |Array of passes |
|===============================================================================
Deprecated values will not be removed from the structure, but their meaning is
lost, they become reserved values that will not be reassigned. Each
justification level has several glyph attributes associated with it.
Notice that reserved values do not have to be 0. In addition, some values that were
transitioned from reserved to having a meaning, may also be used in Silf tables
whose version number is lower than the version in which the meaning was introduced.
This structure was new as of version 2.0.
.JustificationLevel
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|BYTE |attrStretch |Glyph attribute number for justify.X.stretch |
|BYTE |attrShrink |Glyph attribute number for justify.X.shrink |
|BYTE |attrStep |Glyph attribute number for justify.X.step |
|BYTE |attrWeight |Glyph attribute number for justify.X.weight |
|BYTE |runto |Which level starts the next stage |
|BYTE |reserved | |
|BYTE |reserved | |
|BYTE |reserved | |
|===============================================================================
A pseudo-glyph is a glyph which contains no font metrics (it has a GID greater
than the numGlyphs entry in the maxp table) but is used in the rendering
process. Each pseudo-glyph has an attribute which is the glyph ID of a real
glyph which will be used to actually render the glyph. The pseudo-glyph map
contains a mapping between Unicode and pseudo-glyph number:
.PseudoMap
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|ULONG |unicode |Unicode codepoint |2.0 – changed from USHORT to ULONG
|USHORT |nPseudo |Glyph ID of pseudo-glyph |
|===============================================================================
The ClassMap stores the replacement class information for the passes in this
description. Replacement classes are used during substitution where a glyph id
is looked up in one class and the glyph ID at the corresponding index in another
class is substituted. The difficulty with the storage of such classes is in
looking up a glyph ID in an arbitrarily ordered list. One approach is to use a
linear search; this is very slow, but is stored very simply. Another approach is
to order the glyphs in the class and to store the index against the glyph. Both
approaches are supported in the ClassMap table structure:
.ClassMap
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|USHORT |numClass |Number of replacement classes |
|USHORT |numLinear |Number of linearly stored
replacement classes |
|ULONG |oClass[] |Array of numClass + 1 offsets
to class arrays from the
beginning of the class map | 4.0 changed from USHORT
|USHORT |glyphs[] |Glyphs for linear classes |
|LookupClass |lookups[] |An array of numClass –
numLinear lookups |
|===============================================================================
The LookupClass stores a fast lookup association between glyph ID and index.
Each lookup consists of an ordered list of glyph IDs with the corresponding
index for that glyph. The number of elements in the lookup is specified by
numIds along with a search Range and shift to initialize a fast binary search
engine:
.LookupClass
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|USHORT |numIDs |Number of elements in the lookup |
|USHORT |searchRange |(max power of 2<= numIDs) |
|USHORT |entrySelector |log2(max power of 2<= numIDs) |
|USHORT |rangeShift |numIds – searchRange |
|LookupPair |lookups[] |lookups; there are numIDs of these |
|===============================================================================
Each element in the lookup consists of a glyphId and the corresponding index in
the original ordered list.
.LookupPair
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|USHORT |glyphId |glyph id to be compared |
|USHORT |index |index corresponding to glyphId in ordered list |
|===============================================================================
=== Pass ===
Each processing pass consists of a finite state machine description for rule
finding, and the actions that are executed when a rule is matched.
.SIL_Pass
[cols="5,9,34,8",options="header",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|BYTE |flags |0-2 - number of collision runs; +
3-4 - kerning collisions; +
5 - reverse direction pass |5.0 - add bits 0-5
|BYTE |maxRuleLoop |MaxRuleLoop for this pass |
|BYTE |maxRuleContext |Number of slots of input
needed to run this pass |
|BYTE |maxBackup |Maximum number of slots this
pass is allowed to back up) |
|USHORT |numRules |Number of action code blocks |
|USHORT |fsmOffset |offset to numRows relative to
the beginning of the SIL_Pass
block |2.0 - added; +
3.0 - used
|ULONG |pcCode |Offset to pass constraint
code from start of subtable
(*passConstraints[0]*) |2.0 - added
|ULONG |rcCode |Offset to rule constraint
code from start of subtable
(*ruleConstraints[0]*) |
|ULONG |aCode |Offset to action code from
start of subtable
(*actions[0]*) |
|ULONG |oDebug |Offset to debug arrays
(*dActions[0]*); +
0 if debug stripped |
|USHORT |numRows |Number of FSM states |
|USHORT |numTransitional |Number of transitional states
in the FSM (length of
*states* matrix) |
|USHORT |numSuccess |Number of success states in
the FSM (size of *oRuleMap*
array) |
|USHORT |numColumns |Number of FSM columns |
|USHORT |numRange |Number of contiguous glyph ID
ranges which map to columns |
|USHORT |searchRange |(maxi power of 2 <= numRange)
*sizeof(Pass_Range)[Deprecated]|
|USHORT |entrySelector |log2(maximum power of 2
<= numRange) [Deprecated] |
|USHORT |rangeShift |numRange*sizeof(Pass_Range)
- searchRange [Deprecated] |
|Pass_Range |ranges[] |Ranges of glyph IDs in this FSM; +
*numRange* of these |
|USHORT |oRuleMap[] |Maps from success state to offset into ruleMap
array from start of array. 1st item corresponds
to state # (numRows – numSuccess);
ie, non-success states are omitted.
[0xFFFF implies rule number is equal to state
number (no entry in ruleMap) – NOT IMPLEMENTED].
There are (numSuccess + 1) entries. |
|USHORT |ruleMap[] |Linear arrays of rule numbers
maping to a success state number |
|BYTE |minRulePreContext |Min number of items in any rule
context before 1st modified rule item |
|BYTE |maxRulePreContext |Max number of items in any rule
context before 1st modified rule item |
|USHORT |startStates[] |Array of size (maxRulePreContext
- minRulePreContext + 1), indicating the start
state in the state machine based on how many
pre-context items a rule has |
|USHORT |ruleSortKeys[] |Array of *numRules* sort keys,
indicating precedence of rules |
|BYTE |rulePreContext[] |Array of *numRules* items indicating
the number of items in the context
before the 1st modified item,
one for each rule |
|BYTE |collisionThreshold| |2.0 - inserted, +
5.0 – used
|USHORT |pConstraint |passConstraint block length |2.0 – added
|USHORT |oConstraints[] |numRules + 1 offsets to constraint code blocks
from start of ruleConstraints. |
|USHORT |oActions[] |numRules + 1 offsets to action code blocks
from start of actions. |
|USHORT |stateTrans[][] |Array of *numTransitional* rows of *numColumns*
state transitions. |
|BYTE |reserved | |2.0 – inserted
|BYTE |passConstraints[] |Sequences of constraint code
for pass-level constraints |2.0 – added
|BYTE |ruleConstraints[] |Sequences of constraint code
for rules |
|BYTE |actions[] |Sequences of action code |
|footnote:[ Should debug tables go at the end, and be
marked via a flag as per Gloc?
]USHORT |dActions[] |Name index for each action for
documentation purposes. +
0 = stripped. length numRules |
|USHORT |dStates[] |Name index for each intermediate
FSM row/state for debugging. +
0 = stripped.
Corresponds to the
last numRows – numRules |
|USHORT |dCols[] |Name index for each state
(length numRows) |
|===============================================================================
Deprecated values will not be removed from the structure, but their meaning is
lost, they become reserved values that will not be reassigned.
Notice that the ranges array has fast lookup information on the front to allow
for the quick identification of which range a particular glyph id is in. Each
range consists of the first and last glyph id in the range.
.Pass_Range
[cols="3,3,8",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description
|USHORT |firstId |First Glyph id in the range
|USHORT |lastId |Last Glyph id in the range
|USHORT |colId |Column index for this range
|===============================================================================
==== Pass Contents ====
A pass contains a Finite State Machine (FSM) which is used to match input
strings to rules. It also contains constraints for further testing whether a
matched string should fire, and it contains the action code to execute against
the matched string.
The FSM consists of a set of states. A state consists of a row of transitions
between that state and another state dependent upon the next glyph in the input
stream. Each state may be an acceptance state, in which case it corresponds to a
rule match, or a transition state, in which case the state is on the way to
matching a rule, or both. A null state transition is one in which the occurrence
of this particular class of the following glyph, will result in no extension of
a rule match anywhere, just fail on all further searching. A final state is one
in which all its transitions are null transitions.
Note that the stateTrans array only needs to represent transitional states, not
final states. Similarly, the oRuleMap array only needs entries for acceptance
states (whether final or transitional). For this reason the FSM is set up
(conceptually) in the following order: transitional non-accepting states first,
followed by transitional accepting states, followed by final (accepting) states.
Note also that because there may be more than one matched rule for a given state,
oRuleMap indicates a list of rule indices in the ruleMap array;
oRuleMap[i+1] - oRuleMap[i] indicates how many there are for state i.
Normally the start state for an FSM is zero. But for each pass there is the idea
of a “pre-context,” that is, there are slots that need to be taken into
consideration in the rule-matching process that are before the current position
of the input stream. If we are very near the beginning of the input, we may need
to adjust by skipping some states, which corresponds to skipping the
“pre-context” slots that not present due to being prior to the beginning of the
input. This is what the maxRulePreContext, minRulePreContext, and startStates
items are used for. Specifically, we need to skip the number of transitions
equal to the difference between the maxRulePreContext and the current stream
position, if greater than zero. The startStates array indicates what the
adjusted start state should be. If the current input position is less than
minRulePreContext, no rule will match at all.
Rules are matched in order of length, so that longest rules are given precedence
over shorter rules. However, the length of some rules may have been adjusted to
allow for a consistent “pre-context” for all rules, so the number of matched
states in the FSM may not correspond to the actual number of matched items in
the rule. For this reason, it is not adequate to simply order rules based on the
number of traversed states in the FSM. Rather, rules are given sort keys
indicating their precedence, which is based primarily on the length of the rule
and secondarily on its original position within the source code.
The FSM engine keeps track of all the acceptance states it passes through on its
path to a final state. This results in a list of rules matched by the string
sorted by precedence. The engine takes the first rule index off the list and
looks up the offset to some constraint code. This code is executed and if the
constraint passes, then the action code associated with that offset is executed
and the FSM restarts at the returned slot position. If the constraint fails,
then the FSM considers the next-preferred rule, tests that constraint, and so
forth. If no accepting state is found or all rules fail their constraints, then
no rule applies, in which case a single glyph is put into the output stream and
the current position advances by one slot.
The action strings are simply byte strings of actions, much like hinting code,
but using a completely different language. (See “Stack Machine Commands.doc”.)
=== Sile ===
This table is used in Graphite table files that rely on an external font for
rendering of the glyphs. When this table is present, the Graphite file is in
effect a minimal font that contains information about the actual font to use in
rendering. This information is stored in the Sile table.
This table was added as of version 2. It is not currently being used.
.Sile
[cols="3,3,8",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description
|FIXED |version |Table version: 00010000
|ULONG |checksum |master checksum (checkSumAdjustment) from the head
table of the base font
|ULONG |createTime[2] |Create time of the base font (64-bits)
from the head table
|ULONG |modifyTime[2] |Modify time of the base font (64-bits)
from the headtable
|USHORT |fontNameLength |Number of characters in fontName
|USHORT |fontName[] |Family name of base font
|USHORT |fontFileLength |Number of characters in baseFile
|USHORT |baseFile[] |Original path and name of base font file
|===============================================================================
There are four possible situations with regard to the Sile table. The first two
are considered normal and the second two pathological.
No Sile table is present. In this case, it is assumed that the Graphite table
file is a normal font containing not only the Graphite tables but also the
glyphs and metrics needed for rendering.
The base font named in the Sile table is present on the system, and its master
checksum and dates match those in the Sile table. In this case, the Graphite
tables are read from the Graphite table file, but the glyphs, metrics, and cmap
from the base font are what are used for rendering (with the modification
performed by the Graphite tables).
The base font named in the Sile table is present, but its master checksum and/or
dates do not match those in the Sile table. In this case the base font is used
to perform the rendering, but with no Graphite behaviors.
The base font named in the Sile table is not present on the system. In this case
the Graphite table file is used for the rendering, with no Graphite behaviors,
resulting in square boxes in place of the expected glyphs.
=== Sill ===
This table maps ISO-639-3 language codes onto feature values. Each language code
can be a maxmum of 4 ASCII characters (although 2 or 3 characters is what is
used by the ISO standard).
This table was added as of version 3.
.Sill
[cols="4,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|FIXED |version |Table version: 00010000 |
|USHORT |numLangs |Number of languages supported|
|USHORT |searchRange |(max power of 2 <= numLangs)
[Deprecated] |
|USHORT |entrySelector |log2(max power of
2 <= numLangs) [Deprecated] |
|USHORT |rangeShift |numLangs-searchRange
[Deprecated] |
|LanguageEntry |entries[] |Languages and pointers to
feature settings; +
numLang + 1 length |
|LangFeatureSetting |settings[] |Feature ID / value pairs |
|===============================================================================
Each language entry contains a 4-character language code and an offset to the
list of features. There is one bogus entry at the end that facilitates finding
the size of the last entry. The offsets are relative to the beginning of the
Sill table.
The language code is left-aligned with any unused characters padded with NULLs.
For instance, the code “en” is represented by the four bytes [101, 110, 0, 0].
.LanguageEntry
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|BYTE |langcode[4] |4-char ISO-639-3 language code |
|USHORT |numSettings |Number of feature settings of language |
|USHORT |offset |Offset to 1st feature setting of language |
|===============================================================================
.LangFeatureSetting
[cols="3,3,8,3",options="unbreakable,header",width="90%",frame="topbot",grid="none"]
|===============================================================================
|Type |Name |Description |Version notes
|ULONG |featureId |Feature identifer number (matches ID in
Feat table) |
|SHORT |value |Default feature value for this language |
|USHORT |reserved |Pad bytes |
|===============================================================================
=== Sild ===
This table holds the debug strings for debugging purposes. Since the strings are
only used for debugging, they are held somewhat optimised for space over speed
and are not considered to be multilingual. Thus strings are considered to be
7-bit ASCII, with a possible extension to UTF-8 at a later stage. The table
consists of a sequence of strings each preceded by a length byte. The first
string is id 0 and so on to the end of the table.
NOTE: this table has not been implemented.
== Multiple Descriptions ==
In the case where multiple descriptions are to be stored in the same set of
tables, the following unifications need to occur:
The feature sets must be unified, thus limiting two features with the same name
to having the same settings and corresponding values.
The glyph attributes must be unified. This can be done by using different
attribute number ranges, or by examining for identical attribute mappings or for
non-intersecting attribute mappings.
The use of the name table must be unified to ensure that two features or feature
settings do not refer to the same entry in the name table.
Notice that the requirement that any tables declared in an external binary
description override the corresponding font table in the font, means that a name
table in an external binary description must be complete, including all the
strings from the original font.
include::OpCodes.asc[]
|
