loca table: local offsets should be word aligned

[vadim-160102]

Related to: ssimms/pdfapi2#37

Please see TTF documentation, e.g. https://docs.microsoft.com/en-us/typography/opentype/spec/loca: "Note that the local offsets should be word aligned."

In 0.113 release notes, "building the fonts no longer requires FontForge". Previously (I've only checked 0.112 version of Amiri-Regular.ttf), offsets in loca table were even. I assume it was FontForge which was responsible for correct alignment. In Amiri-Regular.ttf from 0.113 release, observed offsets can be odd or even i.e. not word aligned. I assume custom font-building procedure, used in 0.113, does not assure strict alignment.

What follows is Font::TTF, when it produces a subset of Amiri font and switches from "long" to "short" variant of loca table, generates an invalid font subset, embedded in a PDF.

It could be argued that Font::TTF must enforce correct alignment, and it actually does, when producing modified glyph data. But if data is merely passed-through unchanged from old to new font (subset), then no checks are made, each glyph data length expected to be even.

Short of (a) instructing PDF::API2 not to subset, or (b) monkey-patching Font::TTF, or (c) sticking to 0.112 version, I still think it would be better to fix the Amiri font to strictly adhere to specification.

[khaledhosny]

The font is generated with FontTools, and I don’t have any control over such binary level details, you might have better luck reporting this to either FontTools or Font::TTF (the spec is saying “should” which reads as recommendation not a requirement).

[vadim-160102]

You are right about recommendation level (my non-native English playing tricks with me sometimes), please feel free to close this ticket then. I'll suggest a patch for Font::TTF later. "Unaligned" fonts must be abundant on the Web already anyway, considering FontTools popularity. I was, after casual inspection, under wrong impression you implemented your own procedure, sorry.