On Fri, Aug 7, 2026 at 2:42 PM Jonas Smedegaard <[email protected]> wrote:
> > More important than file size is whether the two formats use same font > identifiers, so that font systems like fontconfig cannot reliably > distinguish between them: If that is the case, then I believe they need > to either be packaged in separate binary packages that conflict with > each other, or installed *outside* of the normal font area and then > provide some mechanism at package install time to choose which set gets > symlinked into the font area. > If you're referring to the patterns used by fc-match, there certainly appears to be enough differentiation between the two build outputs to do that. E.g., using the various `hint`/`hinting` keys. Possibly also `fontformat`, but I rather suspect that in the real world there's a lot of confusion lurking there (which is why I posited -tt- and -cff- in the moot package names; steering clear of the file-extension at least helps). At present, the files do seem to use different extensions, so fc-match *could* currently lean on that, as-is; I just think it's not recommendable as a way to identify font internals anymore, so finding other keys is better. Anyway, I certainly agree that detailed matching would be great; I just also think that _also_ pushing more detail into the names of font packages would be even more plusgreat. OTOH, if you're just referring to the `name`-table entries, that's probably doable, but I haven't checked those myself. Nate -- nathan.p.willis [email protected] <http://identi.ca/n8>
