Bug#1034050: fonts-creep2: generated font is TrueType, not OpenType

[Nathan Willis]

On Fri, Apr 7, 2023 at 8:28 PM Agathe Porte  wrote:

>
> > 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

Bug#1034050: fonts-creep2: generated font is TrueType, not OpenType

[Nathan Willis]

On Fri, Apr 7, 2023 at 4:39 PM Fabian Greffrath  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 

Bug#902981: Font Awesome v5 in Debian

[Nathan Willis]

On Sun, Jan 29, 2023 at 12:21 PM Julian Gilbey  wrote:

> On Sun, Jan 29, 2023 at 12:21:29PM +0100, Jonas Smedegaard wrote:
> > Quoting Julian Gilbey (2023-01-29 12:03:30)
> > > If you would like me to go ahead and work on this, please say.
> >
> > Sure I would like you to go ahead - why would I not want that?
> >
> > Sounds like a fun project, and Free, and beneficial to Debian.
>
> Great!
>
> > One thing you might consider is to name the resulting package something
> > (similar but) different than fontawesome, to not upset upstream
> > developers by hijacking their name for something arguably different.
>
> A good point.  I was thinking of creating a GitHub project called
> FontAwesome-DFSG, with a README explaining what is it, how it was
> created and how it is not endorsed by the FontAwesome "owners".  But
> I'm not sure what to call the Debian package - it is essentially just
> a repackaging of the FontAwesome fonts.  Perhaps we could call the
> source package fonts-font-awesome-dfsg, and the binary packages
> fonts-font-awesome-4.7, fonts-font-awesome-dfsg-5,
> fonts-font-awesome-dfsg-6 and fonts-font-awesome-dfsg (for the current
> version of the upstream font)?
>

Please don't take the following info as stop-energy (which it's not), but
there is already an active project doing the task of liberating the
no-longer-free symbols from Font Awesome, called ForkAwesome:
https://github.com/ForkAwesome/Fork-Awesome ... which has also added a fair
number of new glyphs since it was founded (6+ years ago).

It's also already packaged for Debian. I certainly agree that it's a
problem that too many other packages pull in FoNT Awesome as a dependency,
but the harder work is in persuading maintainers to switch. Convincing them
to utilize a package that is already available to them would, I think, be
quicker. ForkAwesome certainly hasn't reached 100%, so maybe some people
will never make that switch.

But perhaps I misunderstand what you're wanting to do; if you are wanting
to do something different than what ForkAwesome already does, like just
build a new build script to show it can be done, I may be missing the
nuance.

However, If it's just about fixing the dependent packages, having two forks
of the original runs some risk of confusing people, and it does kind of
divide the community momentum.

Nate
-- 
nathan.p.willis
nwil...@glyphography.com 

Bug#970357: fonts-adf-tribun: Inappropriate ligatures for ae and oe

[Nathan Willis]

On Tue, Sep 15, 2020 at 8:54 AM Mikko Rasa  wrote:

> Recent versions of the ADF fonts contain an rlig (required ligatures) table
> which replaces the letters ae with æ and oe with œ.  This is incorrect for
> at
> least Finnish and English and probably many other languages as well.  I
> know
> Norwegian uses the ligated versions as separate letters, but I'm not sure
> if
> the non-ligated letter combination also appears (and so if the ligature
> substitution could actually change the meaning of the text).
>
> I'm not convinced that the ligatures are useful, since languages where
> those
> ligated letters are used are typically able to enter the relevant Unicode
> characters directly from the keyboard.  And having them as required
> ligatures
> is definitely wrong since there are many examples of using those letters
> separately.
>

Hi Mikko,

Personally, I would concur with your assessment that by making the
ligatures required, people get output text that is, shall we say,
"orthographically incorrect".

However, at the project level, it seems like this is a design decision made
by Arkandis. There's always *some* gray area between "it's a bug in the
font" and "it's a weird-but-intentional design decision that makes the font
a poor choice" and you might find that Arkandis believes (convincingly or
not) that they have the right to make that design decision Like, if the
intent was to have a font that resembles ancient Latin inscriptions, it
might just be that you won't persuade them to change the feature settings.

I would highly encourage you to take the issue, as you've described it, to
Arkandis directly. I think citing the confusion for real-world languages is
the strongest possible argument. So they might be willing to move the
substitutions into a more appropriate feature like hlig or a stylistic
set That's worth a try because fixing it upstream would fix it for
other users.

If that doesn't work, the package is "GPL2 WITH Font-Exemption" so at least
it is functionally patchable. But upstream fixes would be better.

Actually, don't mean to make assumptions — did you already try reaching out
to upstream? Worth a shot, IMO.

Nate


-- 
nathan.p.willis
nwil...@glyphography.com 

Bug#897162: fonts-cardo: missing font Reserved Font Name notice

[Nathan Willis]

Package: fonts-cardoVersion: 1.04-2Severity: seriousUser:
debian-fonts@lists.debian.orgUsertags: rfn-violation
license-violationX-Debbugs-CC: debian-fonts@lists.debian.orgYour
package contains a OFL font: Cardofonts-cardo:
usr/share/fonts/truetype/cardo/Cardoi99.ttfThis looks to be from
here:http://scholarsfonts.net/cardofnt.html

(Note: the RFN notice is declared mid-way down the page, with the copyright

notice. It is also included in the PDF "manual" download.)


Your package does not contain the Reserved Font Name (RFN) notice in
thedebian/copyright file, as it was published in the upstream font,
thereforeyour distribution of the font constitutes a violation of the
license.Please update the debian/copyright file in your package to
reproducethe RFN notice from the upstream font.This message is brought
to you by the Debian Fonts Task Force:https://wiki.debian.org/Fonts

Bug#774148: Reported upstream

[Nathan Willis]

I've reported this upstream at
https://github.com/fontforge/fontforge/issues/2490

Nate
-- 
nathan.p.willis