Hi, while working with the glyph_stream_provider callback I noticed that it has some issues, especially around TTF fonts. Especially LuaTeX analyzes the glyph streams *before* the callback get involved to identify composite glyphs. If composite glyphs are found, the corresponding components get added to the subset bug get new glyph ids. Later, when glyph_stream_provider is called to get the glyph streams, the parameters are the new glyph ids which are assigned by LuaTeX and the mapping is not made available. This leads to two issues: - When glyph_stream_provider is used, composite glyphs can't be preserved but have to be expanded since the callback has no way of knowing the final (remapped) glyph ids of the components. This can not only make the file bigger, it can also invalidate hinting instructions. - Even though the remapped components can't be found from the composite glyphs, they still trigger a call to the callback which can't be distinguished from normal calls and therefore still lead to something being added to the embedded font. Since only the remapped GID is made available, this will not even be the correct component glyph which happens to be in the slot described by the glyph id the component got mapped to (typically glyphs 1, 2, etc. since the remapping maps to the smallest unused glyph ids). This mostly just makes the embedded font bigger and it's confusing when looking at these subsetted fonts with weird glyphs included in the subset. - Somewhat independently, this current code does not allow the side bearings and advance widths to be modified which means that some table values can get inconsistent for variable fonts which change these values. This this is used by existing code and mostly just causes inefficiencies and not outright errors, the existing behavior should probably be kept available for compatibility, so I suggest the following addition: When a font has font_streamprovider set to 3, behave exactly as if the streamprovider was 2, except that before the "normal" glyph_stream_provider provider calls for a font happen (with arguments fontid, (remapped) gid, 2) call the `glyph_stream_provider` once for every glyph with the four arguments (fontid, remapped gid, 3, original gid) and expect four return values, corresponding to horizontal advance width, left side bearing, vertical advance width and top side bearing. This ensures that when the glyphstreams are generated, the callback code is aware of the full mapping between original and remapping GIDs and can therefore use these remapped GIDs correctly. An example implementation is attached. Best regards, Marcel