RE: #conform-mustSpecifyGlyfTableSize

Thank you for your reply!




As for the padding, I was not referring to the padding between tables, but within the glyf table between each glyph entry, which in turn is reflected in the loca offsets.




The reference implementation still "normalises" the glyf table according to the now outdated notion of nominal size, by rounding the glyph lengths to multiples of 4 bytes. When it comes to reconstructing a glyf table which was not internally padded and has therefore has a shorter origLength, the reference decoder fails because the reconstructed table (with 4-byte glyph padding) doesn't fit the encoded origLength from the third-party encoder.




All best,




Cosimo

On Thu, Apr 16, 2015 at 5:37 PM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotype.com> wrote:

> Hello Cosimo,
> On Thursday, April 16, 2015 11:37 AM Cosimo Lupo wrote:
>>        As the notion of "nominal size" was dropped, I no longer understand what "an adequate amount of space" for the reconstructed glyf table actually means.
> The text of the paragraph that immediately follows this requirement attempts to clarify this, and clearly says that “Typically, the origLength field value would specify the actual glyf table size; however, since there may be multiple valid reconstructions of a glyph record,… it is possible that depending on the context and on the level of optimizations being applied to reconstructed glyf table data, the size of the reconstructed glyf table may be greater than, less than, or equal to the actual size of the glyf table in the source font compressed by WOFF2. It is the responsibility of WOFF2 implementations to make sure that an adequate amount of memory is allocated when glyph records are being reconstructed from the WOFF2 file.”
> I believe this  describes in sufficient details (with the reference to the appropriate part of the OT spec) why the reconstructed length might differ from the original length of the table.
>>        Is it, or is it not, the "actual" table size? And by actual, I mean the "original length" of the sfnt glyf table, whatever that was before the woff2 encoding, with all the equally legal encoding rules?
> The ‘glyf’ table origLength value would be a good starting point but there is no guarantee that the reconstructed table will end up being of the same exact size – the result depends on the level of optimizations applied to defining outline point coordinates, both in the original input font that was subject to WOFF2 encoding and the output font created by a decoder. It is possible that a highly optimized reconstructed output glyf table might end up being smaller in size than the input data, but it is also possible that if the output is not optimized a decoder will produce larger table size than was specified by origLength. The spec doesn’t mandate any particular level of glyf data optimization, it is really  up to individual implementers to consider how much effort they want to put into it.
>>        The spec also says that it's the responsibility of WOFF2 decoders to make sure that "an adequate amout [ditto] of memory" is allocated when glyphs are being reconstructed from a WOFF2 file.
> Yes, for the reasons we just discussed.
>>        What I get from this is that, unlike with the loca's origLength (which is normative), the glyf's origLenth has now become simply orientative and should not be relied upon too when allocating memory during the glyf reconstruction. This also means that a decoder should not reject a font when the reconstructed glyf length happens to be different from the encoded origLength.
>>        Is this the correct interpretation?
> Yes, your interpretation is correct. The output data size will depend on the decoder implementation, and different decoders might produce different results. From the font rendering point of view it doesn’t really matter if e.g. repeated delta point coordinates are optimized using flags or explicitly encoded as repeated values – for as long as the font rendering is not affected this is fine, but the memory allocation has to be able to handle a possibility where an originally allocated chunk will not be large enough to store the reconstructed glyf table and the memory would have to be dynamically reallocated.
>>        If this is the case, then both the reference implementation and the OTS decoder need to be updated accordingly. They both fail to decode a WOFF2 font whose glyf.origLength is smaller than the reconstructed glyf length.
> Yes, this is likely to be an implementation bug and should definitely be fixed.
>>        The lengths differences have to do with the absence or presence of padding between glyphs --- which I gather was also dropped along with the notion of nominal size.
> I am not sure I understand your last point. There may be various reasons (discussed above) why the reconstructed data can be larger in size than the input, or vice versa. There are no padding when the glyf data is preprocessed and converted into a WOFF2 byte stream (subject to Brotli compression) but when the data is reconstructed it is done according to the OpenType/OFF spec requirements, WOFF2 specifies a reconstruction process on a per glyf record basis, collecting those glyph records into a ‘glyf’ table (and reconstruction of the ‘loca’ table) is done according to the OpenType/OFF spec.
> Thank you,
> Vlad