Re: Codepoint Set Compression Round 2

For both fontTools and harfbuzz we currently collect all glyphs that can be
reached via any sequence of feature applications via the G* tables. In
harfbuzz we don't yet do glyph closure for cmap 14, but I've added that to
our task list. fontTools currently handles computing the closure for cmap
14:
https://github.com/fonttools/fonttools/blob/master/Lib/fontTools/subset/__init__.py#L2139
.

On Tue, Aug 6, 2019 at 5:29 AM Ken Lunde <lunde@adobe.com> wrote:

> Jonathan and others,
>
> Don't forget about sequences that resolve to glyphs, which can be
> cultivated from 'ccmp' and other ligature-like features, along with the
> Format 14 'cmap' subtable. Perhaps the most complex sequences are those
> expressed via the 'ljmo', 'vjmo', and 'tjmo' features that are used for
> combining jamo for which there are 11,875 two-character sequences (LV) and
> 1,626,875 three-character ones (LVT). The Source Han / Noto CJK fonts can
> serve as example implementations of everything I described above.
>
> -- Ken
>
> > On Aug 6, 2019, at 2:44 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
> >
> > On 05/08/2019 23:35, Garret Rieger wrote:
> >
> >> This will of course add some extra size to the first response, but
> having the client know in advance the specific code points in the source
> font has value beyond compressing the sets. For example if the browser
> knows which codepoints are in the font it doesn't need to waste
> requests/bytes sending augmentation requests for codepoints that aren't
> actually in the font.
> >
> > It's pretty important for the browser to know early on which codepoints
> are in the font. It needs this in order to be able to appropriately fall
> back to the next font in the font-family list (perhaps kicking off a new
> font load for a different resource) for characters that aren't going to be
> supported by this one even after it is fully loaded.
> >
> > Equally, if a given character *is* going to be supported by the current
> font (even though it hasn't been fetched yet), we don't want the browser to
> start loading further fonts in the stack.
> >
> > JK
> >
>
>
>