Bug#1034050: fonts-creep2: generated font is TrueType, not OpenType
Interesting dilemma ....
On 2023-04-07 14:02, Agathe Porte wrote:
Package: fonts-creep2
Version: 0.0~git20210325.69dc0de+ds-4
Severity: minor
X-Debbugs-Cc: debian@microjoe.org
Dear Maintainer (currently me, self-reporting for tracking),
The generated font is a TrueType font, not an OpenType font. This does
not impact the useability of the package to my knowledge, but would be
On the contrary, all TrueType fonts are also OpenType fonts. OpenType is
a superset of TrueType, which is older.
That is clearly a misconception that the font industry has been battling
unsuccessfully, but if the intent is to make some sort of distinction
based on the outline format contained within (quadratic vs cubic
Beziers), then filename extension alone is not adequate.
Similarly, if the intent is to make some sort of distinction based on
the contents of the tables (e.g., GSUB and GPOS), then the filename
extension still isn't adequate, because .ttf files can and do include
those tables (see Noto and many many others).
nice to be fixed. This bug is reported by Lintian under the tag
`truetype-font-wrong-filename`.
Well, if that's so, then this indicates that Lintian is likely overdue
for a refresh on how it determines these things. That might be a big
undertaking; I don't know at the moment.
However, with this particular font:
The problem is that the font is located in /usr/share/fonts/opentype
instead of /usr/share/fonts/truetype, and that its name is creep2.otb
instead of creep2.ttf.
The .otb extension (as well as the .bdf in the package) indicates that
this is a bitmap font re-wrapped in an OpenType table structure (see
https://github.com/fonttools/fonttools/issues/684 for the history, and
code at https://github.com/freedesktop/fonttosfnt or possibly
https://github.com/ctrlcctrlv/bitmapfont2otb for the internal details);
that definitely makes it an OpenType font and not a TrueType font,
because the older TrueType spec did not allow that sort of skullduggery:
it required vector outlines.
Not all proprietary apps and platforms recognize this usage nor the
".otb" extension itself, but HarfBuzz / FreeType / Pango do.
Proposed solution is to rename the directory and the font itself to
match the TTF filetype.
Just doing a rename of the binary file could trigger accidental breakage
for users on apps/stacks who aren't running HarfBuzz / FreeType etc (as
above) via the standard, modern stack. That would not seem to be a
beneficial change.
Long term, the underlying fix is that Lintian's font-detection likely
needs a scrubbing by somebody with a lot more free time at hand than me
(although billionaires who wish to fund this should still reach out...).
*Long* long term, the FHS and so on likely really need to drop the
*/truetype/ */opentype/ directory distinction, since it's not doing
anything useful. It's a bit like saying there should be separate /jpg/
and /jpeg/ directories and older images should only be put in one of
them....
I know this TTF/OTF confusion is widespread, but I maintain that fixing
it is still possible....
Nate
Reply to: