I have MinionPro-Regular.otf file. I working with it's structure. I have found it have:
Table 'hhea': reference on 1668 metrics in 'hmtx' table.
Table 'hmtx': 1668 pairs of hMetrics('advanceWidth', 'leftSideBearing').
Table 'CFF ': 1429 glyph names.
Table 'CFF ': param 'CharStrings' have offset to the index of 1668 elements.
Each element consist the Width property if it is not the same
as DefaultWidth.
CFF specification told as, that OTF font total glyphs quantity (or just presented in CFF stream of PDF file if the font is embedded) has to be:
1429 + 228 = 1649
; 1429 + 115 = 1544
;1429 + 116 =
1515
.The closest to 1668 number is 1649, but the difference 19 means I lost some thing important in this indexing idea.
The questions are:
IMPORTANT UPDATE
The Charsets do not matter! It was the wrong way!
OK, finally I understood it!
in high resolution: https://docs.google.com/drawings/pub?id=1gM7gs-ibJ_0qsUrsxIkF5rYUmC9Ix2F9WD9d3aqwc0g&w=1209&h=1179
How it is works:
Open Type Font file (OTF) consists hhea
table with the parameter numberOfHMetrics
and hmtx
table with the array of the horizontal metrics for each glyph in the font.
CFF
table consists array of strings. There are 0...1428 glyph names and 1429...1432 strings-values for version
, Notes
, FullName
, FamilyName
parameters. How I understood, this 4 strings in always extra.
Now we have Predefined Standard Strings
- common for all Open Type Fonts entire world. The table have 0...378 common glyph names and 379...390 extra names for parameters, as mentioned above.
Now we have to combine two tables of names in one array. First elements of the predefined names table, include .nondef
element (it is strange for me, because it is system "nothing", but as we see horizontal metric 500) and whole CFF strings array, except the parameter's names. Total count of elements have to be numberOfHMetrics
.
I waste 60 hours to understand the whole picture.