shadowfacts/fonttools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[meta] Remove comments about intentionally deviating from Apple's spec

Browse Source 
Today, Apple has kindly fixed a bug in the [specification of the
meta table](https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6meta.html).  The existing fonttools implementation matches the
revised specification.  Therefore, the comments about fonttools
intentionally deviating from Apple's spec can be removed.
This commit is contained in:
Sascha Brawer 2016-04-01 15:50:52 +02:00
parent 919e98c3bb
commit 13e862da72
2 changed files with 1 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
Lib/fontTools/ttLib/tables/_m_e_t_a.py
View File

@ -16,15 +16,6 @@ META_HEADER_FORMAT = """
numDataMaps: L
"""
# According to Apple's spec, the dataMaps entries contain a dataOffset
# that is documented as "Offset from the beginning of the data section
# to the data for this tag". However, this is *not* the case with
# the fonts that Apple ships pre-installed on MacOS X Yosemite 10.10.4,
# and it also does not reflect how Apple's ftxdumperfuser tool is parsing
# the 'meta' table (tested ftxdumperfuser build 330, FontToolbox.framework
# build 187). Instead of what is claimed in the spec, the data maps contain
# a dataOffset relative to the very beginning of the 'meta' table.
# The dataOffset field of the 'meta' header apparently gets ignored.
DATA_MAP_FORMAT = """
> # big endian

9
Lib/fontTools/ttLib/tables/_m_e_t_a_test.py
View File

@ -9,14 +9,7 @@ import unittest
# From a real font on MacOS X, but substituted 'bild' tag by 'TEST',
# and shortened the payload. Note that from the 'meta' spec, one would
# expect that header.dataOffset is 0x0000001C (pointing to the beginning
# of the data section) and that dataMap[0].dataOffset should be 0 (relative
# to the beginning of the data section). However, in the fonts that Apple
# ships on MacOS X 10.10.4, dataMap[0].dataOffset is actually relative
# to the beginning of the 'meta' table, i.e. 0x0000001C again. While the
# following test data is invalid according to the 'meta' specification,
# it is reflecting the 'meta' table structure in all Apple-supplied fonts.
# and shortened the payload.
META_DATA = deHexStr(
"00 00 00 01 00 00 00 00 00 00 00 1C 00 00 00 01 "
"54 45 53 54 00 00 00 1C 00 00 00 04 CA FE BE EF")