> 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).
I do not know how to inspect the tables, but the `file` tool indicates
that creep2.ttf (provided by upstream) and creep2.otb (built by the
package) are reported as TrueType fonts with BDF tables:
There are a couple of passable options. FontForge *can* show you all the contents, but the drawback is that it doesn't have a good concept of "general overview" and instead it's all split up into different panes of different editable info-windows.
The much easier option (IMO) is probably the "TTX" tool, which is a round-trip-through XML tool, but it has several convenience switches, too, letting you just look at stuff.
So you can run `ttx -l somefilename.ttf` (or whatever it is) and it will just list the tables by name.
$ file creep2.{ttf,otb}
$ creep2.ttf: TrueType Font data, 16 tables, 1st "BDF ", 14 names, Macintosh
$ creep2.otb: TrueType Font data, 15 tables, 1st "BDF ", 14 names, Macintosh
If I take an other font in the opentype directory, the `file` tool
report the file as OpenType:
$ file /usr/share/fonts/opentype/cantarell/Cantarell-Bold.otf
/usr/share/fonts/opentype/cantarell/Cantarell-Bold.otf: OpenType font data
I suspect that it's seeing the filename extension first, then doing as-efficient-of-a-test-as-it-can ... so kind of "file says .ttf, are the first few bytes a valid TrueType file? If yes say TrueType". And if you rename the file it'd be "file says .otf, are the first few bytes a valid OpenType file? If yes say OpenType"
But when it doesn't recognize .otb it probably tests for TrueType first.
I did glance at the source for the `file` utility, but I can't parse it; not easy stuff if you're not familiar with that codebase I guess.
> > 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.
I have looked at the source code of Lintian, and the current checks [1]
are quite simple. Quoting:
return
unless $file->file_type =~ /^TrueType Font data/;
$self->pointed_hint('truetype-font-wrong-filename', $file->pointer)
unless $file->name =~ /\.ttf$/i;
So the check is "if the file type is TrueType and extension != .ttf,
report warning".
[1] https://salsa.debian.org/lintian/lintian/-/blob/ea05801918ed0e87824d89bf16a6ee166450b977/lib/Lintian/Check/Fonts/Truetype.pm
Yeah, I looked at that too... It seems like it's reliant on an external TrueType library for the "TrueType Font data" token, but I really don't know Perl; that may be clearer to trace for someone who does. I wouldn't know valid Perl if it rode up on a camel in a Hawaiian shirt, sorry to say.
It's definitely testing those things in sequential order though; understandable but if you reversed the order of the tests it might report different conclusions on the same input.
> 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.
I really have the impression that the generated file has a TrueType
table structure instead of an OpenType table structure according to the
`file` command (and the check done by lintian on the file_type). I
really need to find a way to be sure that the creep2.otb file is really
an Opentype file and not "just" a TrueType file.
They are the same structure. The tables use the same format; some recent tables in the OpenType spec were not around when TrueType was replaced/upcycled by OpenType; that's the only distinction. "OpenType" as a name was basically rebranding so that Adobe would not have to admit it was also using Apple's TrueType format. Well, and there is certainly value in having it be an open specification that others can add to (as has happened over the years).
Unfortunately there is quite a bit of ambiguity out there (meaning in the web docs published over the decades by the big 3 vendors) about which tables are or are not mandatory for a font to be considered "correct". The reality on the pavement is each implementation is going to be different.
For instance, some old docs will say that every TrueType font has to have a `glyf` table for its Bezier outlines ... but that was written long before emoji fonts, which will only contain raster images in a different table like `sbix` ... so it's demonstrably out-of-date.
Something like that might be the cause of the different counts you see in the `file` output, but it's also possible that `file` doesn't recognize some private tables.
I manually add this .otb extension in the fontforge script, but I think
sourceforge is not generating what I want.
Ah. There are a couple of conversion utilities (I think I linked them in a previous message) that might be worth a shot, at least to make a comparison. I like FontForge as much as anyone, but it has a lot of moving parts so if there's a simpler converter that might be more predictable, it'd be worth some testing.
> Not all proprietary apps and platforms recognize this usage nor the ".otb"
> extension itself, but HarfBuzz / FreeType / Pango do.
In fact I think that this font is the first "otb" font in Debian, so I
think we should take time to discuss if the resulting font is properly
generated as an example for future other Opentype bitmap fonts.
Actually, after a brief look, I'm 99.998% sure there's at least one other. I did a full scan of the font packages ~1.5 years ago, and "fonts-terminus-otb" is one of the package names. Could be some useful details there. I suspect there are actually more than that, since the format has been around (unofficially) since the X11 days. I just didn't test that at the time since bitmaps wasn't part of the research. I haven't re-downloaded and opened that file to poke at it yet; I just have logs of the scan results handy.
I dunno; could at least be useful to look at for you as maintainer, for comparison?
You seem to really know your stuff more than I do. I packaged this font
for fun and to use it sometimes. My current problem is that I am not
sure that the creep2.otb font is *actually* an OpenType font.
But if you say that all TrueType fonts are OpenType fonts, then I guess
I cannot verify this easily. I need your expertise to know if the file
is correct and I should ignore lintian, or if the file is incorrect and
I should fix it somehow.
Tragically, I have been forced by circumstance to spend a lot of time reading those specs in recent years.
We can definitively say that TrueType is a proper subset of OpenType; that relationship is by design.
We can also definitively say that a `BDF ` table is *not* part of the old TrueType specification, since it was invented later and by other people, and only gets added to OpenType-era fonts by build tools like FontForge and those free-software scripts. By that definition, I think everyone in the font industry would say that an .otb file (or any other file extension) using a `BDF ` table is *not* a TrueType font.
(Plus there's always the chance that renaming and moving the file to the /truetype/ directory could confuse some application that doesn't know what to do with the bitmaps in `BDF `, which would actually be a bug in that application making assumptions. I don't know if that actually happens though.)
The slightly more nebulous question is whether some purists out there would say that a font with a `BDF ` table *also isn't* genuinely an OpenType font *if* it's missing some other tables that they think are mandatory.
But the upstream specification doesn't specifically address that question. There are a lot of "unofficial" tables (debug tools and build tools save output in them, for example) and the "this is required" list is demonstrably out-of-date. Besides, if it's neither TrueType nor OpenType (by those purists definitions) then it's not anything.
The reality is that it contains valid data that HarfBuzz, FreeType, fontconfig, and Pango all know how to work with, and it is formatted in compliance with OpenType. So I would say it's an OpenType font, you should ignore that lintian warning, and someday somebody ought to dig into Lintian (and/or file)'s tests.
Anyway, my personal advice would be to ignore that Lintian error; there may be other ways to do the build itself in other .OTB-using font packages that would sidestep it, but I haven't looked.
Either way, do let me say thanks for maintaining this! I'm happy to see people taking care of older font projects like these — and making them available for people to use in modern apps!
(wanted to be sure I said that before I forget)
Nate
--