Additional OpenType tables.

Additional OpenType tables.

[bungeman, 2012-11-19 23:31:21]

This CL

* adds support for the 'glyf', 'loca', and 'maxp' tables
* cleans up the Versions to match the newer, clearer, style
* puts TableDirectoryEntry inside SkSFNTHeader, since that is where it logically
belongs.

Most of these changes and additions are in preparation for code cleanup in
SkFontHost_mac_coretext.cpp.

[bungeman, 2012-11-19 23:37:42]

To motivation for these changes can be seen in
https://codereview.appspot.com/6843087/ Patch Set 1, which shows how the final
SkFontHost_mac_coretext.cpp is envisioned.

[caryclark1, 2012-11-20 13:36:06]

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V0.h
File src/sfnt/SkOTTable_OS_2_V0.h (right):

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V0.h#ne...
src/sfnt/SkOTTable_OS_2_V0.h:22: static const SK_OT_USHORT Version =
SkTEndian_SwapBE16(0);
Why the rename? Two variables that only differ in case looks fragile. Also, the
comment no longer matches (even more).

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V1.h
File src/sfnt/SkOTTable_OS_2_V1.h (right):

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V1.h#ne...
src/sfnt/SkOTTable_OS_2_V1.h:22: 
Ditto on two variables that only vary by case. Is this a standard somewhere or
matches naming or documentation elsewhere? I didn't find any reference to this
in the future version of SkFontHost_mac_coretext.cpp you referred to.

[bungeman, 2012-11-20 18:18:31]

Here's my explanation for the name change. If a better naming convention can be
found which can be implemented, I'd be happy for that.

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V0.h
File src/sfnt/SkOTTable_OS_2_V0.h (right):

https://codereview.appspot.com/6850075/diff/1/src/sfnt/SkOTTable_OS_2_V0.h#ne...
src/sfnt/SkOTTable_OS_2_V0.h:22: static const SK_OT_USHORT Version =
SkTEndian_SwapBE16(0);
On 2012/11/20 13:36:06, caryclark1 wrote:
> Why the rename? Two variables that only differ in case looks fragile. Also,
the
> comment no longer matches (even more).

Well, one is a constant and one is the variable. I think they should be more
parallel than they were (or I wouldn't have made the change). Accessing the
variable here looks something like os2Table.version.version or
os2Table.version.v0.version. Accessing the constant would now be done like
SkOTTableOS2::Version::V0::Version. Without this change accessing the constant
looks like SkOTTableOS2::Version::V0::version0. The capitalization doesn't match
the general pattern (static accesses are capitalized) and it duplicates the
version number. The change was made to the OS2 table because I wan't happy with
the prior pattern when creating SkOTTable_maxp. So I fiddled about and came up
with this way of doing the versions for SkOTTable_maxp and then updated OS2 to
match. One can already 'do the wrong thing' with os2Table.version.v0.version0.

I'd really like to do away with the first 'version' in 'version.version' and the
first 'Version' in 'Version::V0::Version', but unions can't have static members.
Perhaps changing that first 'Version' to 'Variant' or something.

I can change the comment to read "The only way to differentiate VA and V0 is by
size." here and in SkOTTable_OS_2_VA. I'm not sure how the comment didn't match
before. It would have been nice if Microsoft hadn't extended the OS2 table and
changed the meaning of some bits and then failed to update the version number.

[bungeman, 2012-11-20 18:54:41]

Committed revision 6509.