[MPEG-OTSPEC] comments wrt wide glyph ID proposal

Hin-Tak Leung htl10 at users.sourceforge.net
Tue Dec 12 15:14:19 CET 2023


 I am somewhat on Peter's side - there are known poor combinations of usage of different "allowed" part of the spec... and there comes a point where people are asking to formalize quirks/bugs/implementations as spec, when bits are being used beyond what they were designed for.

One primary example is people asking for 16-bit mathematics to overflow in specific ways to support glyph ids higher than 65536. There are cmap tables designed for large glyph ids, asking for 16-bit cmap sub types to overflow in specific/implementation-defined ways is formalizing quirks/bugs as features...

I think adding a few clauses about where *not* to use GSUB type 5 and GPOS type 7 (contextual) may be a good idea.
     On Tuesday, 12 December 2023 at 12:45:07 GMT, Simon Cozens <simon at simon-cozens.org> wrote:  
 
 On 12/12/2023 02:54, Peter Constable wrote:
> This may be an opportunity to deprecate certain formats from use in 
> wide-GID fonts. E.g., GSUB type 5 and GPOS type 7 (contextual) were 
> effectively obsoleted when the chaining contextual formats were added. 

My understanding is that OFF often contains multiple ways of doing the 
same thing, to give font producers opportunities to produce the most 
efficient binary representation. (for example, cmap subtables). These 
"obsolete" layout table formats can be used for the same purpose; 
fontTools has code to select the most efficient representation of 
chaining subtable and I've used it to knock quite a few bytes of fonts 
which make heavy use of chaining rules.

So I don't see a reason for taking these away; even if you want to do 
that, the change is not germane to wide glyph IDs. I'm in favour of 
keeping the scope of the change focused.

Simon

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231212/3c4b8681/attachment.html>


More information about the mpeg-otspec mailing list