I am getting only Playfair Micro SmCond SmLight and nothing else

[jozsefk9]

Is this a normal behavior on Linux, to get only that one variety of Playfair font (Playfair Micro SmCond SmLight)?

I downloaded "Playfair_2_2_fonts.zip", extracted it to "~/.fonts" just like I do with all other fonts.

[clauseggers]

I have no idea what constitutes normality on ‘Linux’. Playfair is a variable font with some predefined instances. Looks like your software has elected to just display one of them.

[kenmcd]

LibreOffice uses the STAT table.
And the STAT table in v2.200 is still completely messed-up.
I tested yesterday in Samsa - which still shows problems - and then tested in LibreOffice which also shows the problems.

There are also problems with the named instances.
I figured once the GF folks get involved this stuff will get fixed.

[clauseggers]

I’ll put @schriftgestalt and @mekkablue on this.
The GF folks will only fix the fonts they generate. There is no traffic from them to me.
The Glyphs people will have to take a look at this.

@kenmcd What are the particular issues?

[RGB-es]

The problem is not Linux, but LibreOffice: variable fonts are unusable there. See this bug report

Bug 152396 - Font width (expanded, condensed, etc.) is not supported

Recent versions of LuaTeX offer good support for variable fonts.

[clauseggers]

I had a hunch this was the case. The fonts in Samsa looks fine – at least I couldn’t see anything amiss.
Whether the STAT table is indeed malformed @schriftgestalt is looking into. He will report back if there are indeed issues.

I hope @kenmcd will posts the specific STAT table issues soon.

[kenmcd]

The problem is not Linux, but LibreOffice: variable fonts are unusable there. See this bug report

Bug 152396 - Font width (expanded, condensed, etc.) is not supported

Recent versions of LuaTeX offer good support for variable fonts.

That is an old report.
I have tested current versions of LibreOffice (v24.8.3.1) with the current versions of Junicode (v2.209) - and created documents which display all pre-defined instances - and it works fine.

Here is an image of an earlier test with Junicode v2.208 from LibreOffice.

Looks the same with v2.209.
And the correct fonts get embedded in the Export to PDF.
That will not happen with this current Playfair v2.200 (I tested it).
I doubt it is even possible to create a working test document which correctly displays all the named instances (such as above), or export to PDF correctly.

[clauseggers]

Hello @schriftgestalt and @mekkablue
I’d like to get this issue resolved. Is this a bug in Glyphs or not? FontSpector says it is and I agree.

>> googlefonts/font_names
FAIL: [bad-names]: Font names are incorrect:

│           Name           │                 Current                 │Expected │
├──────────────────────────┼─────────────────────────────────────────┼─────────┤
│Family Name               │Playfair Micro SmCond SmLight            │Playfair │
│Subfamily Name            │Regular                                  │Regular  │
│Full Name                 │Playfair Micro SemiCondensed SemiLight   │Playfair │
│Postscript Name           │PlayfairRoman-MicroSemiCondensedSemiLight│Playfair-│
│Typographic Family Name   │Playfair                                 │Playfair │
│Typographic Subfamily Name│Micro SemiCondensed SemiLight            │         │

NOTE: This check turns out to be misleading. It is a check that validates the very specific Google Fonts house-style of styles. Parsing non-Google fonts on it will yield misleading results.

[schriftgestalt]

As fare as I know, the name table should look like the static instance of on the origin masters. So if all variable tables are removed, it is a valid font. You can overwrite this like this:

[clauseggers]

The best source I can find is the Microsoft summary of the name table, and they write

It is also strongly recommended that applications support extended typographic-family groupings using name IDs 16 and 17. Note that variable fonts can include a large number of named instances, each of which will use a shared typographic family name (name ID 16) and will have a typographic subfamily name (equivalent to name ID 17). Applications that assume a four-style family grouping based on name IDs 1 and 2 are likely to provide a poor user experience with variable fonts.

George is therefore correct, Fontspector is incorrect, and this is not a bug.

[kenmcd]

I hope @kenmcd will posts the specific STAT table issues...

Note: this is for Playfair v2.202 Roman VF
The most obvious issue is the Weight 400 axis instance being named SemiExpanded instead of Regular.
(which is shown in the Samsa image I posted above)
If you dump just the STAT table using TTX, down around line 130 you will see something like below (but without my notes to myself):

<AxisValue index="16" Format="3">
  <AxisIndex value="2"/>
  <Flags value="0"/>
  <ValueNameID value="760"/>  <!-- SemiExpanded --><!-- WRONG - FOR REGULAR WEIGHT -->
  <Value value="400.0"/>        <!-- FOR Regular 400 WEIGHT not SemiExpanded WIDTH -->
  <LinkedValue value="700.0"/>  <!-- correctly linked to BOLD WEIGHT -->
</AxisValue>

When I open that font in FontLab and look at the Axes settings I see image below.
Original settings:

Which shows the same Weight 400 error.

Note: some applications are confused by duplicate names in the various axes instance styles.

So I made some changes and fixes.

Optical Size (opsz)
Original
Micro=5, Minuscule=6, Miniature=7, Caption=8, (Regular)=12, SubHeading=16, Trumpet=21, Headline=32, Display=48, Titling=72, Hairline=96, Needlepoint=1200
Changed
Micro=5, Minuscule=6, Miniature=7, Caption=8, (Text)=12, SubHead=16, Trumpet=21, Headline=32, Display=48, Titling=72, Hairline=96, Needlepoint=1200
this changed
(Regular)=12 to (Text)=12
or better yet
(Regular)=12 to Text=12 to show the opsz like the rest do
or perhaps even better
(Regular)=12 to Pica=12 to continue your old names theme (this would be my choice)
I would also change SubHeading=16 to SubHead=16 to shorten it a bit

Width (wdth)
Original
SemiCondensed=88, Medium=100, SemiExpanded=113
Changed
SemiCond=88, (Normal)=100, SemiExpd=113
Changed Medium=100 to (Normal)=100 so it would get elided
And to prevent Medium Medium
And to prevent duplicate style names (which will confuse the application)

• Playfair-Medium (width, with an elided weight)
• Playfair-Medium (weight)
  And to shorten the names a bit.

Weight (wght)
Original
SemiLight=360, SemiExpanded=400, Medium=500, SemiBold=600, Bold=700, ExtraBold=800, Black=900
Fixed
SemiLight=360, (Regular)=400, Medium=500, SemiBold=600, Bold=700, ExtraBold=800, Black=900
This was the most obvious issue which showed up on Samsa.
Changed SemiExpanded=400 to (Regular)=400

So the Modified version now looks like this:

Then I had FontLab (FL) rebuild the instances from the axes.
Which does result in usable unique style names.
(but they are a mess which must be fixed manually, which I did not do in this test).
Was not successful in exporting the font from FL.
FL simply cannot finish.
Lots of error messages about smcp glyphs, and then lock-up.
FL is the problem, not the font. Just cannot handle some things in Glyphs files.

Anyway, I think most of the issue can be solved in the Axes settings.
And then cleaning-up the instance names.
I made just a couple shorter-names changes above.
But more is needed to get under the 31-character limit to work properly in most apps.
I can fix those manually if needed, once the axes are sorted.