Bug 69254 - Correct handling of font families (weight, style, stretches) on Mac
Summary: Correct handling of font families (weight, style, stretches) on Mac
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA target:6.1.0 target:6.0.0
Keywords: bibisectRequest, regression
: 68889 79726 83006 89242 95816 98397 100835 101905 (view as bug list)
Depends on:
Blocks: 35538 MacOS-UI Fonts
  Show dependency treegraph
 
Reported: 2013-09-12 08:11 UTC by Carlo Bertelli
Modified: 2018-02-14 08:28 UTC (History)
20 users (show)

See Also:
Crash report or crash signature:


Attachments
LO 4.2.4 Windows, original document (54.39 KB, image/png)
2014-06-07 07:59 UTC, Thomas Linard
Details
LO 4.3.0 beta 1 Mac OS X, original Windows document opened with Mac version (137.06 KB, image/png)
2014-06-07 08:00 UTC, Thomas Linard
Details
Font Book with Fira Sans Medium (115.17 KB, image/png)
2016-06-11 08:19 UTC, b4stien
Details
LibreOffice without Fira Sans Medium (172.28 KB, image/png)
2016-06-11 08:19 UTC, b4stien
Details
With https://gerrit.libreoffice.org/#/c/48409/ (92.99 KB, image/png)
2018-01-23 13:10 UTC, Tor Lillqvist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Carlo Bertelli 2013-09-12 08:11:03 UTC
Problem description: 
We have a corporate font which is behaving perfecly elsewhere, but fails to recognize regular (and bold), detecting only italic and bold-italic styles.

Steps to reproduce:
Try to define a style.

Current behavior:
Shows only italic and bold-italic

Expected behavior:
Detect or at least accept "Normal" or "Regular".
Operating System: Mac OS X
Version: 4.1.1.2 release
Comment 1 Jean-Baptiste Faure 2013-11-16 17:03:45 UTC
Which font it is? Without this information it is not possible to investigate.
How work other fonts ?

Best regards. JBF
Comment 2 QA Administrators 2014-06-01 21:30:34 UTC Comment hidden (obsolete)
Comment 3 Alex Thurgood 2014-06-06 22:40:19 UTC
*** Bug 67744 has been marked as a duplicate of this bug. ***
Comment 4 Alex Thurgood 2014-06-06 22:40:53 UTC
*** Bug 69881 has been marked as a duplicate of this bug. ***
Comment 5 Alex Thurgood 2014-06-06 22:42:48 UTC
*** Bug 68889 has been marked as a duplicate of this bug. ***
Comment 6 Alex Thurgood 2014-06-06 22:43:28 UTC
*** Bug 71034 has been marked as a duplicate of this bug. ***
Comment 7 Alex Thurgood 2014-06-06 22:47:33 UTC
Setting to regression as this affects existing documents that previously displayed normally
Comment 8 Alex Thurgood 2014-06-06 22:49:31 UTC
LO 4.0.x displays font weights correctly
Comment 9 Thomas Linard 2014-06-07 07:59:15 UTC
Created attachment 100588 [details]
LO 4.2.4 Windows, original document
Comment 10 Thomas Linard 2014-06-07 08:00:27 UTC
Created attachment 100589 [details]
LO 4.3.0 beta 1 Mac OS X, original Windows document opened with Mac version
Comment 11 Alex Thurgood 2014-06-07 09:51:27 UTC
*** Bug 79726 has been marked as a duplicate of this bug. ***
Comment 12 Alex Thurgood 2014-06-07 09:56:53 UTC
Don't know which developer might be knowledgable in this area, font support on OSX using Apple's new API is afaik incomplete / not fully implemented.
Comment 13 Alex Thurgood 2015-04-03 15:09:21 UTC
*** Bug 71034 has been marked as a duplicate of this bug. ***
Comment 14 Milan Bouchet-Valat 2015-04-03 15:25:46 UTC
Alex: Since you marked all the bug reports as duplicates of this one, maybe you could give more details about what's common to them. Currently, this report is much less detailed than the duplicates, and the font needed to reproduce is not easily available. Bug 71034 for example contains many more technical details and provides a reproducer with free/standard fonts.
Comment 15 Alex Thurgood 2015-04-03 15:59:32 UTC
*** Bug 89242 has been marked as a duplicate of this bug. ***
Comment 16 Alex Thurgood 2015-04-03 16:10:40 UTC
(In reply to Milan Bouchet-Valat from comment #14)
> Alex: Since you marked all the bug reports as duplicates of this one, maybe
> you could give more details about what's common to them. Currently, this
> report is much less detailed than the duplicates, and the font needed to
> reproduce is not easily available. Bug 71034 for example contains many more
> technical details and provides a reproducer with free/standard fonts.

Not being a developer, I could well be wrong, but it seems to me that the common issue here is incorrect weighting of a fairly large number of font families that occurred somewhere between 4.0 and 4.1 release, particularly with bold weights.

All I know is that this issue has been with us on Mac since the transition between 4.0 and 4.1 and has had no takers thus far from any dev. If others deem it appropriate to reset the main bug to another one, then who am I to argue.
Comment 17 Adolfo Jayme 2015-04-29 16:30:29 UTC Comment hidden (off-topic)
Comment 18 Alex Thurgood 2015-04-29 21:30:20 UTC Comment hidden (off-topic)
Comment 19 b4stien 2016-06-11 08:19:01 UTC
Created attachment 125599 [details]
Font Book with Fira Sans Medium
Comment 20 b4stien 2016-06-11 08:19:30 UTC
Created attachment 125600 [details]
LibreOffice without Fira Sans Medium
Comment 21 b4stien 2016-06-11 08:20:18 UTC
This bug is still affecting versions 5.1.3.2 and 5.2.0.0.beta_2.

Attached are screenshots of "Font Book" and LibreOffice 5.1.3.2 where you can see that the "Medium" variant of "Fira Sans" is missing in LibreOffice (although working everywhere else). "Fira Sans" is a free font from Google, you can download it to reproduce there: https://www.google.com/fonts#UsePlace:use/Collection:Fira+Sans.
Comment 22 Alex Thurgood 2016-09-06 09:46:30 UTC
*** Bug 101905 has been marked as a duplicate of this bug. ***
Comment 23 Xisco Faulí 2016-09-13 08:29:27 UTC
Adding keyword 'bibisectRequest'.
This regression can be bibisected with http://dev-downloads.libreoffice.org/bibisect/mac/Bibisect_MacOSX10.6%2b_lo-4.1_to_lo-4.2.tar.bz2
Comment 24 Alex Thurgood 2017-07-28 08:02:44 UTC
With the move to harfbuzz and the recent coretext changes made in 5.3, shouldn't we be asking people to retest with current production release and reporting back ?
Comment 25 Thomas Linard 2017-07-28 13:05:25 UTC
Duplicate of Bug 35538.

Still valid for 5.3.4.
Comment 26 ikjt 2017-07-28 16:10:45 UTC
The freely available Overpass typeface from Red Hat has enough weights (8 plus italics) to clearly demonstrate the problem.

http://overpassfont.org/

What happens with typefaces like this is that some of the weights will fail to show up in the font selector in LO. And of those that do show up, some will randomly produce the wrong weight. Testing just now, I'm missing "Extra Light" and "Heavy" entirely. "Thin" and "Light" both produce the the same weight.

As another example, I have the commercial typeface Akagi in a five-weight configuration. The heaviest one (Ultra) will not show up in LO. Using the second-heaviest (Extra Bold) actually produces Ultra instead. Disabling Ultra in Font Book makes Extra Bold work correctly.
Comment 27 Thomas Linard 2018-01-05 09:55:37 UTC

*** This bug has been marked as a duplicate of bug 35538 ***
Comment 28 Tor Lillqvist 2018-01-22 14:39:09 UTC
Re: comment #26, but where would different styles of a typeface show up in LibreOffice?  Doesn't LibreOffice only have a selector for typeface "family", and then one can only modulate that using the Bold and Italic buttons? You don't see separate entries in the selector for "Liberation Serif Regular", "Liberation Serif Bold", etc either.

But yeah, I guess there could be some logic to add more entries when a typeface family has more than four variants, or something. Not sure why that would be a Mac-spefici feature, though? And anyway, bug #35538, that this bug now is marked as duplicate of, is cross-platform, not Mac-specific.
Comment 29 ikjt 2018-01-23 11:21:05 UTC
(In reply to Tor Lillqvist from comment #28)
> Re: comment #26, but where would different styles of a typeface show up in
> LibreOffice?  Doesn't LibreOffice only have a selector for typeface
> "family", and then one can only modulate that using the Bold and Italic
> buttons? You don't see separate entries in the selector for "Liberation
> Serif Regular", "Liberation Serif Bold", etc either.

There's both a family selector and a typeface selector: https://i.imgur.com/tPNJjea.png

The Bold and Italic buttons are merely shortcuts for certain styles, but a font can contain many more styles or weights than just two.
Comment 30 Tor Lillqvist 2018-01-23 11:30:08 UTC
Ooh, I didn't know/remember that, interesting. IMHO the style selector should ideally be visible in the toolbar, too, if (as it seems) it is more and more common that typefaces have more styles than just the boring R/B/I/BI. Wonder if there is an enhancement request for that already.
Comment 31 Tor Lillqvist 2018-01-23 11:40:59 UTC
(Side remark: I only now notice that LO on the Mac indeed calls a style of a typeface a "typeface" (and not "style") in that Character dialog. How odd. But indeed that terminology seems to what is normal on the Mac, it's what Pages uses, too. Sad. Probably some random accidental wrong choice of terminology made 30 years ago that has stayed with us...)
Comment 32 Tor Lillqvist 2018-01-23 11:52:02 UTC
Anyway, for me all the styles of the Overpass typeface do show up in the Character:Font dialog? And I am able to choose for instance the Thin Italic style. 

It also saves that to .odt, and reloads it correctly.

But when roundtripping through .doc or .docx, the "Overpass Thin Italic" indeed turns into plain Overpass Italic. 

So is that the actual problem then, that only the four traditional styles of a typeface can be saved to / loaded from the .doc or .docx formats? 

It probably would be a good enhancement request to want the full style selector (or "typeface selector", if one insists on using the Mac terminology) to be part of the normal toolbar.
Comment 33 Tor Lillqvist 2018-01-23 12:00:04 UTC
Also, interoperability of those additional styles in .odt documents is broken with Word 2013, at least.
Comment 34 Tor Lillqvist 2018-01-23 12:01:35 UTC
But in general, my advice would naturally be that if one wants as good roundtrippability, interoperability, and cross-platformness as possible, one should stick to the traditional four styles of well-known fonts available either as such, or as metrics-compatible equivalents, on all platforms.
Comment 35 ikjt 2018-01-23 12:03:02 UTC
> Anyway, for me all the styles of the Overpass typeface do show up in the
> Character:Font dialog? And I am able to choose for instance the Thin Italic
> style. 

Right, they show up in the list, but go ahead and compare Light with Thin, or Light Italic with Thin Italic. It's using the same font for both! It's as if there's a limit to the number of styles that LO can actually use at once.

If you disable (via Font Book) the style that appears in place of another style, the previously unavailable style becomes available. So it's not a case of LO failing to understand some styles at all; they just can't be displayed simultaneously for some reason.
Comment 36 Thomas Linard 2018-01-23 12:10:19 UTC
(In reply to Tor Lillqvist from comment #32)
> It also saves that to .odt, and reloads it correctly.

Yes, but open it in LibreOffice Windows (with the same typeface installed, of course).

Or, on Windows, choose "Calibri Light" (for example), and open it on macOS.
Comment 37 Thomas Linard 2018-01-23 12:13:02 UTC
(In reply to Tor Lillqvist from comment #33)
> Also, interoperability of those additional styles in .odt documents is
> broken with Word 2013, at least.

According to https://glyphsapp.com/tutorials/naming

"Microsoft Word [2016 ?] currently focuses on Family Name and Style Name, or the WWSFamilyName and WWSSubfamilyName, if present. WWS stands for Weight, Width and Slope."
Comment 38 Tor Lillqvist 2018-01-23 12:17:20 UTC
To ikjt in comment #35:

Ah yes, now I see what you mean. This is presumably caused by the fact that all three of Overpass:Thin, Overpass:Light, and Overpass:ExtraLight have the same weight, and probably that is what LO stores internally when enumerating the fonts, not the style name as a string. So which one LO actually gets when it asks for Overpass in weight 3 is probably then arbitrary. See here some debugging output from yesterday:

instdir/LibreOfficeDev.app/Contents/MacOS/soffice 2>&1 | grep 'Overpass:'
debug:63911:23372987: ===> AddFont: Overpass: Heavy Italic 9 140392521171392
debug:63911:23372987: ===> AddFont: Overpass: Heavy 9 140392521029872
debug:63911:23372987: ===> AddFont: Overpass: Light Italic 3 140392521251056
debug:63911:23372987: ===> AddFont: Overpass: ExtraBold 9 140392520801456
debug:63911:23372987: ===> AddFont: Overpass: SemiBold 7 140392521357216
debug:63911:23372987: ===> AddFont: Overpass: SemiBold Italic 7 140392520805120
debug:63911:23372987: ===> AddFont: Overpass: Light 3 140392521268800
debug:63911:23372987: ===> AddFont: Overpass: ExtraLight 3 140392521388656
debug:63911:23372987: ===> AddFont: Overpass: Thin 3 140392521150848
debug:63911:23372987: ===> AddFont: Overpass: Bold 8 140392521276736
debug:63911:23372987: ===> AddFont: Overpass: Italic 5 140392521291920
debug:63911:23372987: ===> AddFont: Overpass: ExtraBold Italic 9 140392521301488
debug:63911:23372987: ===> AddFont: Overpass: ExtraLight Italic 3 140392521095824
debug:63911:23372987: ===> AddFont: Overpass: Regular 5 140392521141872
debug:63911:23372987: ===> AddFont: Overpass: Thin Italic 3 140392521407216
debug:63911:23372987: ===> AddFont: Overpass: Bold Italic 8 140392521368992

where you see the family name, style, weight, and an internal ID (a pointer value).
Comment 39 ikjt 2018-01-23 12:23:41 UTC
(In reply to Tor Lillqvist from comment #38)
> Ah yes, now I see what you mean. This is presumably caused by the fact that
> all three of Overpass:Thin, Overpass:Light, and Overpass:ExtraLight have the
> same weight, and probably that is what LO stores internally when enumerating
> the fonts, not the style name as a string.

Yeah, I suspected something like this might be happening. But where is LO pulling the weight number from? Does it simply make it up? I can't imagine all these fonts containing some kind of weight attribute that is not unique within the family.
Comment 40 Tor Lillqvist 2018-01-23 12:46:12 UTC
To ikjt in comment #39:

It seems that what CoreText actually gives us is a floating point number between -1.0 and 1.0, with 0 being the "normal" weight. See https://developer.apple.com/documentation/coretext/kctfontweighttrait

That is then turned into LO's FontWeight enumeration (in include/tools/fontenum.hxx, which does have a relatively nice collection of named weights:

> enum FontWeight { WEIGHT_DONTKNOW, WEIGHT_THIN, WEIGHT_ULTRALIGHT,
>                   WEIGHT_LIGHT, WEIGHT_SEMILIGHT, WEIGHT_NORMAL,
>                   WEIGHT_MEDIUM, WEIGHT_SEMIBOLD, WEIGHT_BOLD,
>                   WEIGHT_ULTRABOLD, WEIGHT_BLACK

(This enumeration is the weight I mentioned in comment #38, 3 == WEIGHT_LIGHT.)

Some debugging output:

> debug:33677:25401597: ===> Overpass: Light: w=-0.4
> debug:33677:25401597: ===> Overpass: ExtraLight: w=-0.5
> debug:33677:25401597: ===> Overpass: Thin: w=-0.5
> debug:33677:25401597: ===> Overpass: Regular: w=0

So Light should be distinguishable from ExtraLight or Thin, but ExtraLight has the same weight as Thin, so distinguishing between those would be harder.
Comment 41 ikjt 2018-01-23 13:06:26 UTC
(In reply to Tor Lillqvist from comment #40)
> > debug:33677:25401597: ===> Overpass: Light: w=-0.4
> > debug:33677:25401597: ===> Overpass: ExtraLight: w=-0.5
> > debug:33677:25401597: ===> Overpass: Thin: w=-0.5
> > debug:33677:25401597: ===> Overpass: Regular: w=0

Interesting. So is this an Apple bug? Apple's own Pages handles Overpass (and other multi-style typefaces) just fine.

Perhaps the CoreText-supplied weight value should be used for ordering at most and use the actual font names to distinguish between variants.
Comment 42 Tor Lillqvist 2018-01-23 13:10:39 UTC
Created attachment 139292 [details]
With https://gerrit.libreoffice.org/#/c/48409/

As can be seen, with this patch Light is different from ExtraLight, but Thin still turns up the same as ExtraLight (as expected, as their weight is identical).
Comment 43 Tor Lillqvist 2018-01-23 13:13:16 UTC
To comment #41:

Sure, there are lots of things that could be done. This particular fix above was very small and easy. (But still took almost one work-day to investigate and figure out.) There are not really much resources available for a more thorough re-work.
Comment 44 ikjt 2018-01-23 13:17:41 UTC
(In reply to Tor Lillqvist from comment #43)
> To comment #41:
> 
> Sure, there are lots of things that could be done. This particular fix above
> was very small and easy. (But still took almost one work-day to investigate
> and figure out.) There are not really much resources available for a more
> thorough re-work.

Well, even if we have to rely on the CoreText-supplied values for now, what's the point of doing proprietary arithmetics and guessing the intended weight, when the possible values and their interpretation is apparently well-defined?

https://developer.apple.com/documentation/appkit/nsfontweight?language=objc
Comment 45 Tor Lillqvist 2018-01-23 13:34:09 UTC
Sure, but the weights of the Overpass styles do not correspond to the AppKit weights with the corresponding names:

https://stackoverflow.com/questions/32570968/what-are-the-canonical-font-weights-in-core-text

2018-01-23 15:31:15.229169+0200 fontweights[34458:25564989] UltraLight: -0.800000
2018-01-23 15:31:15.229374+0200 fontweights[34458:25564989] Thin: -0.600000
2018-01-23 15:31:15.229383+0200 fontweights[34458:25564989] Light: -0.400000
2018-01-23 15:31:15.229390+0200 fontweights[34458:25564989] Regular: 0.000000
2018-01-23 15:31:15.229397+0200 fontweights[34458:25564989] Medum: 0.230000
2018-01-23 15:31:15.229403+0200 fontweights[34458:25564989] Semibold: 0.300000
2018-01-23 15:31:15.229410+0200 fontweights[34458:25564989] Bold: 0.400000
2018-01-23 15:31:15.229416+0200 fontweights[34458:25564989] Heavy: 0.560000
2018-01-23 15:31:15.229423+0200 fontweights[34458:25564989] Black: 0.620000
 
Overpass Thin has weight -0.5, but NSFontWeightThin is -0.6. Fun.
Comment 46 Aron Budea 2018-01-23 13:45:13 UTC
Let's keep this separate from bug 35538, it's more helpful if platform-specific discussions/fixes are separate, and don't get confused with each other.
Comment 47 ikjt 2018-01-23 13:50:19 UTC
Okay, I'm inclined to file a bug with Apple about CoreText returning the same weight value for two clearly distinct weights.

But... Even if CoreText returned unique weights, would this thing still work? Looking at the patch posted above, it looks like LO is shoehorning the weights into its own weight classification system (WEIGHT_NORMAL, WEIGHT_THIN, etc.) anyway. Does this also stand in the way of supporting fonts with a large number of weights?
Comment 48 Thomas Linard 2018-01-23 13:58:24 UTC
*** Bug 68889 has been marked as a duplicate of this bug. ***
Comment 49 Thomas Linard 2018-01-23 14:00:57 UTC
*** Bug 79726 has been marked as a duplicate of this bug. ***
Comment 50 Thomas Linard 2018-01-23 14:01:54 UTC
*** Bug 89242 has been marked as a duplicate of this bug. ***
Comment 51 Thomas Linard 2018-01-23 14:02:28 UTC
*** Bug 95816 has been marked as a duplicate of this bug. ***
Comment 52 Thomas Linard 2018-01-23 14:03:01 UTC
*** Bug 100835 has been marked as a duplicate of this bug. ***
Comment 53 Thomas Linard 2018-01-23 14:03:48 UTC
*** Bug 101905 has been marked as a duplicate of this bug. ***
Comment 54 Thomas Linard 2018-01-23 14:04:46 UTC
*** Bug 83006 has been marked as a duplicate of this bug. ***
Comment 55 Tor Lillqvist 2018-01-23 14:07:54 UTC
One difference between Overpass ExtraLight and Overpass Thin that is visible in CoreText is the width, kCTFontWidthTrait:

debug:34633:25641404: ==> Overpass: ExtraLight width=0 -> 5
debug:34633:25641404: ==> Overpass: Thin width=-0.7 -> 1

and that is then mapped to different values of the LibreOffice enum FontWidth: Overpass Thin gets WIDTH_ULTRA_CONDENSED (the 1 above) and Overpass ExtraLight gets WIDTH_NORMAL  (the 0 above). But I don't see in the LibreOffice Character...:Font dialog a way to select the width of the font?

(Compared to how the Thin vs ExraLight styles actually look, I think it's an exaggeration from the font creators to give the Thin style the width value -0.7, as it is not really that much condensed, if at all?)
Comment 56 Tor Lillqvist 2018-01-23 14:28:29 UTC
To comment #47:

Yes, seems so. If a typeface has more than 9 weights, those could not even in theory be distinguished by LO's FontWeight. (And in practice, it is likely that the mapping from the floating-point weights to the enum will cause overlaps anyway even for less than 9, as seen originally here where both -0.5 and -0.4 were mapped to the same WEIGHT_LIGHT).

This is not unique to the Mac backend, the LO code for Windows has:

static FontWeight ImplWeightToSal( int nWeight )
{
    if ( nWeight <= FW_THIN )
        return WEIGHT_THIN;
    else if ( nWeight <= FW_ULTRALIGHT )
        return WEIGHT_ULTRALIGHT;
    else if ( nWeight <= FW_LIGHT )
        return WEIGHT_LIGHT;
    else if ( nWeight < FW_MEDIUM )
        return WEIGHT_NORMAL;
    else if ( nWeight == FW_MEDIUM )
        return WEIGHT_MEDIUM;
    else if ( nWeight <= FW_SEMIBOLD )
        return WEIGHT_SEMIBOLD;
    else if ( nWeight <= FW_BOLD )
        return WEIGHT_BOLD;
    else if ( nWeight <= FW_ULTRABOLD )
        return WEIGHT_ULTRABOLD;
    else
        return WEIGHT_BLACK;
}
Comment 57 Commit Notification 2018-01-23 14:32:40 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=407546e7c3f8c732ccf60e5fb3844f6efb86f932

tdf#69254: Tweak mapping from CoreText weight to our FontWeight a bit

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 58 ikjt 2018-01-23 14:39:19 UTC
> (Compared to how the Thin vs ExraLight styles actually look, I think it's an
> exaggeration from the font creators to give the Thin style the width value
> -0.7, as it is not really that much condensed, if at all?)

Using https://opentype.js.org/font-inspector.html and looking at the "OS/2 and Windows Metrics table", I get the following values:

Overpass Light        weight 300, width 5
Overpass ExtraLight   weight 200, width 5
Overpass Thin         weight 100, width 5

But according to Apple's documentation, macOS does not use the OS/2 metrics table. So do the font files contain a second set of metadata somewhere that is wrong, or is CoreText making things up?

Also, I just noticed that, for me at least, the Extra Light weight is missing from the LO UI. To summarize, Light and Thin are listed but rendered identically, while Extra Light is missing completely.
Comment 59 Tor Lillqvist 2018-01-23 14:54:10 UTC
> the Extra Light weight is missing from the LO UI

But is that with the patch above or not?

And yes, it does seem likely that CoreText is just making things up;) It's just software, presumably with layer upon layer of bugs and fixes and hacks and backward compatibility. Just like LibreOffice. Also, as the Overpass typeface that I have been using to test now was designed by Red Hat, it is likely that it is "tuned" to match typical FLOSS stacks, i.e. fontconfig, freetype, harfbuzz etc, and has not necessarily been tested that much by its designers on macOS. If that matters.
Comment 60 Tor Lillqvist 2018-01-23 14:57:49 UTC
Some discussion in https://lists.w3.org/Archives/Public/www-style/2015Jan/0076.html , and (linked from that) https://bugzilla.mozilla.org/show_bug.cgi?id=931426
Comment 61 Tor Lillqvist 2018-01-23 15:03:55 UTC
(But it is weird that in the Mozilla bug discussion they talk about the "appkit weight" or "apple weight" being a small integer between 2 and 9 (a bit like LO's FontWeight), not a floating-point number between -1.0 and 1.0. Maybe they actually mean some Mozilla-specific type with that?)
Comment 62 Commit Notification 2018-01-24 15:55:21 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3aeda82b09253d20d234d50b39e76977031f2102&h=libreoffice-6-0

tdf#69254: Tweak mapping from CoreText weight to our FontWeight a bit

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 63 Commit Notification 2018-01-24 16:27:35 UTC
Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-6-0-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e9a6a9e59a38a77d383dcbe1e289e7e5a6db8554&h=libreoffice-6-0-0

tdf#69254: Tweak mapping from CoreText weight to our FontWeight a bit

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 64 Thomas Linard 2018-01-24 16:49:29 UTC
*** Bug 98397 has been marked as a duplicate of this bug. ***
Comment 65 Thomas Linard 2018-01-31 15:31:01 UTC
Test report with LibreOffice 6.0, macOS 10.12.6

Open-source fonts installed (in OTF version each):

EB Garamond version 1.0 (10 styles)
https://github.com/octaviopardo/EBGaramond12

Fira Sans version 4.2.3 (92 styles)
https://carrois.com/typefaces/FiraSans/

Overpass version 3.0.2 (16 styles)
http://overpassfont.org/

All fonts are correctly viewed in Font Book, TextEdit and Apple Pages (version 6.3.1). Fira Sans is presented as 3 families: Fira Sans, Fira Sans Compressed, Fira Sans Condensed).

All fonts are (almost) correctly viewed in Microsoft Word 2016 for Mac (version 16.9.1). Fira Sans is presented as 5 families: Fira Sans, Fira Sans Eight, Fira Sans Four, Fira Sans Hair, Fira Sans Two. But: Fira Sans Condensed Book (and Italic) and Fira Sans Compressed Book (and Italic) are presented as Fira Sans Condensed 350 and Fira Sans Compressed 350. Fira Sans Book is presented as Fira Sans Book.

In LibreOffice 6.0.0:

EB Garamond: 4 styles are missing.
Medium
Medium Italic
SemiBold
SemiBold Italic

Fira Sans is presented as 3 families: Fira Sans, Fira Sans Compressed, Fira Sans Condensed.

Fira Sans: 16 styles are missing.
Four
Four Italic
Hair
Hair Italic
Heavy
Heavy Italic
Medium
Medium Italic
SemiBold
SemiBold Italic
Two
Two Italic
Ultra 
Ultra Italic
Ultra Light
Ultra Light Italic

Fira Sans Compressed: 16 styles are missing.
Same as Fira Sans (except Ultra styles, unique to Fira Sans) + Fira Sans Compressed Thin (and Italic)

Fira Sans Condensed: 14 styles are missing.
Same as Fira Sans (except Ultra styles, unique to Fira Sans)

Overpass: 2 styles are missing
Overpass Heavy
Overpass Heavy Italic

So, it seems that LibreOffice 6.0.0 on macOS effectively handles italics and stretches, but fails on some weights, in both extremes of the spectrum and in the middle.