On Fri, Apr 7, 2023 at 4:39 PM Fabian Greffrath <fab...@debian.org> wrote:
> > I'd say we make the distinction by container format. Though, I agree > that this distinction is still pretty arbitrary. > But the container formats are the same, though: SFNT. You can rename a foo.ttf file to foo.otf and it behaves exactly the same. It's literally just a different file extension. The only distinctions possible are down inside the optional contents, like an OpenType font *might* include some tables (like CFF) that originated in the Type-1 spec and not in Apple's version of the original TrueType. But even in that case, it's table-level, not container-level. So if you renamed a CFF-including bar.otf to bar.ttf, an old enough Mac might ignore the CFF table, but would see the rest fine. 20.odd years ago, proprietary systems had to stick to their conventions because the big vendors (Apple, MS, and Adobe) didn't support _each_other's_ contributions in their own various applications, but that's changed since then and, way more importantly, the free-software stack today is one pipeline that supports them all. The MS spec even references this — https://learn.microsoft.com/en-us/typography/opentype/spec/otff#filenames — it's just Newton's First Law that keeps the old-timey ways stuck in place.... For the record, I do advocate for user-facing font managers to do better here (on presenting the important internal distinctions, not the filename extension), particularly because it would clear up more serious confusion between the various emoji formats and in variable fonts, but it's identifiably archaic stuff at the system and package level, which users and apps shouldn't ever need to think about. Hashtag cloudyelling, Nate -- nathan.p.willis nwil...@glyphography.com <http://identi.ca/n8>
