[MPEG-OTSPEC] comments wrt wide glyph ID proposal

[Behdad Esfahbod]

On Tue, Dec 12, 2023 at 7:14 AM Hin-Tak Leung <htl10 at users.sourceforge.net>
wrote:

> 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.
>

Contextual is just an storage-optimized version of the ChainingContextual
when there's no context (backtrack / lookahead). There's no ambiguity there.


> 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
> _______________________________________________
> 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/319658f8/attachment.html>