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
Which font it is? Without this information it is not possible to investigate. How work other fonts ? Best regards. JBF
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
*** Bug 67744 has been marked as a duplicate of this bug. ***
*** Bug 69881 has been marked as a duplicate of this bug. ***
*** Bug 68889 has been marked as a duplicate of this bug. ***
*** Bug 71034 has been marked as a duplicate of this bug. ***
Setting to regression as this affects existing documents that previously displayed normally
LO 4.0.x displays font weights correctly
Created attachment 100588 [details] LO 4.2.4 Windows, original document
Created attachment 100589 [details] LO 4.3.0 beta 1 Mac OS X, original Windows document opened with Mac version
*** Bug 79726 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 89242 has been marked as a duplicate of this bug. ***
(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.
(In reply to Alex Thurgood from comment #16) > Not being a developer, I could well be wrong You are. Stop messing around.
Adolfo, I am not messing around. If that is how you consider my input then so be it, but I'm not going to stop just because you seem to take askance at the reports I either file or intervene in. Consider yourself more knowledgeable by all means, but dissing the non-dev people who attempt to help out in QA is not going to move this bug further towards resolution. Or perhaps you are implying that my place isn't here ?
Created attachment 125599 [details] Font Book with Fira Sans Medium
Created attachment 125600 [details] LibreOffice without Fira Sans Medium
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.
*** Bug 101905 has been marked as a duplicate of this bug. ***
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
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 ?
Duplicate of Bug 35538. Still valid for 5.3.4.
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.
*** This bug has been marked as a duplicate of bug 35538 ***
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.
(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.
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.
(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...)
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.
Also, interoperability of those additional styles in .odt documents is broken with Word 2013, at least.
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.
> 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.
(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.
(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."
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).
(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.
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.
(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.
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).
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.
(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
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.
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.
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?
*** Bug 95816 has been marked as a duplicate of this bug. ***
*** Bug 100835 has been marked as a duplicate of this bug. ***
*** Bug 83006 has been marked as a duplicate of this bug. ***
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?)
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; }
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.
> (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.
> 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.
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
(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?)
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.
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.
*** Bug 98397 has been marked as a duplicate of this bug. ***
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.
(In reply to Tor Lillqvist from comment #60) > 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 Hi, https://bugzilla.gnome.org/show_bug.cgi?id=766148 https://github.com/GNOME/pango/blob/master/pango/pangocoretext-fontmap.c (see https://mail.gnome.org/archives/commits-list/2016-May/msg04616.html ) could be interesting documentation. The discussion is very informative.
(In reply to Thomas Linard from comment #65) > 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. The same test (almost: LibreOffice 6.0.2, Fira Sans 4.3 https://bboxtype.com/typefaces/FiraSans/ ) on Linux gives very similar results. See bug 98596.
From the link above https://github.com/GNOME/pango/blob/master/pango/pangocoretext-fontmap.c#L121 static const PangoCTWeight ct_weight_map[] = { { ct_weight_min, PANGO_WEIGHT_THIN }, { -0.5, PANGO_WEIGHT_ULTRALIGHT }, { -0.23, PANGO_WEIGHT_LIGHT }, { -0.115, PANGO_WEIGHT_SEMILIGHT }, { 0.00, PANGO_WEIGHT_NORMAL }, { 0.2, PANGO_WEIGHT_MEDIUM }, { 0.3, PANGO_WEIGHT_SEMIBOLD }, { 0.4, PANGO_WEIGHT_BOLD }, { 0.6, PANGO_WEIGHT_ULTRABOLD }, { ct_weight_max, PANGO_WEIGHT_HEAVY } }; So this "coretext" is stuffing all fonts into one of these 10 weights. Correct? And as mentioned above, coretext is assigning different weights the same weight. This causes multiple fonts to be assigned the same weight, causes conflicts, and display errors. Fira Sans has 16 visual weights. These are the weights designated in the font files. Fira Sans Two (100) Fira Sans Four (100) Fira Sans Eight (100) Fira Sans Hair (100) Fira Sans Thin (100) Fira Sans UltraLight (200) Fira Sans ExtraLight (200) Fira Sans Light (300) Fira Sans Book (350) Fira Sans Regular (400) Fira Sans Medium (500) Fira Sans SemiBold (600) Fira Sans Bold (700) Fira Sans ExtraBold (800) Fira Sans Heavy (900) Fira Sans Ultra (950) There is no way coretext can stuff all 16 of those into 10 weights. Google fonts only shows 9 weights (which fits nicely with CSS). Fira Sans Thin (100) Fira Sans ExtraLight (200) Fira Sans Light (300) Fira Sans Regular (400) Fira Sans Medium (500) Fira Sans SemiBold (600) Fira Sans Bold (700) Fira Sans ExtraBold (800) Fira Sans Black (900) (Heavy) They simply ignore the rest. Overpass Overpass Thin (100) Overpass ExtraLight (200) Overpass Light (300) Overpass Regular (400) Overpass SemiBold (600) Overpass Bold (700) Overpass ExtraBold (800) Overpass Heavy (900) 8 weights There is no reason why this should not work properly. Assigning the first three fonts the same weight (see above) makes no sense. EB Garamond 12 (octaviopardo) EB Garamond Regular (400) EB Garamond Medium (500) EB Garamond SemiBold (600) EB Garamond Bold (700) EB Garamond ExtraBold (800) 5 weights. The Medium and SemiBold should work properly (see above). I do not see how this coretext thing can ever work properly with modern typefaces. It simply does not fit. LO is already displaying the unique Full Font Name from the font file. Why not just use that? Other apps do. And the bold and italics buttons still work where appropriate. Most modern fonts have structured the font info fields to work either way. If the weight is needed to map to HTML for example, just read it from the font file. It looks to me that coretext will never work. Or can someone please tell ignorant me how it possibly can work. Why is coretext needed for selecting fonts when the metadata can be used instead?
"There is no reason why this should not work properly" Congratulations, you have now discovered the simplest definition of what a bug is.
(In reply to LibreTraining from comment #68) > So this "coretext" is stuffing all fonts into one of these 10 weights. > Correct? Pango seems to do that. Doesn't seem very wise, but if it suits them… > And as mentioned above, coretext is assigning different weights the same > weight. Not exactly. https://bugzilla.gnome.org/show_bug.cgi?id=766148 is a must-read. > This causes multiple fonts to be assigned the same weight, causes conflicts, > and display errors. LibreOffice seems to do that, yes. > It looks to me that coretext will never work. My tests show no bug in Font Book, TextEdit, Apple Pages and MS Word (well, almost for Word). > Or can someone please tell ignorant me how it possibly can work. > > Why is coretext needed for selecting fonts when the metadata can be used > instead? Keep in mind than the same behavior (almost) is observable with LibreOffice on Linux, so CoreText isn't the real problem.
(In reply to Thomas Linard from comment #70) > (In reply to LibreTraining from comment #68) > > > So this "coretext" is stuffing all fonts into one of these 10 weights. > > Correct? > > Pango seems to do that. Doesn't seem very wise, but if it suits them… > > > And as mentioned above, coretext is assigning different weights the same > > weight. > > Not exactly. https://bugzilla.gnome.org/show_bug.cgi?id=766148 is a > must-read. It is surprising after reading through that entire thing that the bug was marked fixed. The tables in Comment 8 show the same issues we have here. The same OS2 weight being mapped to multiple Pango-CoreText weights. The results in the different tables were all over the place. It is easy to see why Fira Sans Book, Regular, and Medium get broken. > > This causes multiple fonts to be assigned the same weight, causes conflicts, > > and display errors. > > LibreOffice seems to do that, yes. > > > It looks to me that coretext will never work. > > My tests show no bug in Font Book, TextEdit, Apple Pages and MS Word (well, > almost for Word). I expect that any font utility will work correctly. The three different font management utilities on my Win 7 system all list the fonts correctly, and display them correctly. The fonts all display correctly in InDesign and in QuarkXpress. > > Or can someone please tell ignorant me how it possibly can work. > > > > Why is coretext needed for selecting fonts when the metadata can be used > > instead? > > Keep in mind than the same behavior (almost) is observable with LibreOffice > on Linux, so CoreText isn't the real problem. I also read through Bug 98596 - Correct handling of font families (weight, style, stretches) on Linux before posting here. The issues seem pretty much the same. Multiple fonts being confused as one based on a faulty weighting system. I tested the fonts mentioned here and in that bug on my Windows 7 + LO6.0.3.2. Fira Sans, Overpass, EB Garamond 12, and Lato (9 weights), and others. With one commercial Pro font I gave-up and edited the font family to be unique for each weight and width I wanted to use. Works fine now in LO6. This issue appears to affect Mac, Linux, and Windows pretty much the same. From these two bug discussions, and the Pango bug discussion you linked to above, it appears this will not be working properly any time soon. So for now the workarounds are: - limited fonts installed from a font family to avoid conflicts or - edit the fonts to make the family name unique for each weight/width
According to https://www.collaboraoffice.com/community-news/recent-mac-specific-fixes-in-libreoffice/ the bug is gone. So, I did my tests again: in reality, nothing has changed. Test report with LibreOffice 6.1 Beta 2, macOS 10.13.5 Open-source fonts installed (in OTF version each): EB Garamond version 1.0 (10 styles) https://github.com/octaviopardo/EBGaramond12 Fira Sans version 4.3.1 (92 styles) https://github.com/bBoxType/FiraSans Overpass version 3.0.2 (16 styles) http://overpassfont.org/ All fonts are correctly viewed in Font Book, TextEdit, Apple Pages (version 7.1) and Microsoft Word 2016 for Mac (version 16.14.1). Fira Sans is presented as 3 families: Fira Sans, Fira Sans Compressed, Fira Sans Condensed). In LibreOffice 6.1.0 Beta 2: 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.1.0 Beta 2 on macOS effectively handles italics and stretches (nothing changed), but still fails on some weights, in both extremes of the spectrum and in the middle (nothing changed). I think the same test on Linux will still gives very similar results. See bug 98596.
Nobody has said that everything is perfect now. Some details for some specific fonts have been fixed. As can be seen from the actual commits.
The webpage you linked to says "The fix for this was to simply handle these special cases separately. If resources allow and more similar problematic fonts are identified, some more generic fix would be needed."
(In reply to Tor Lillqvist from comment #74) > The webpage you linked to says "The fix for this was to simply handle these > special cases separately. If resources allow and more similar problematic > fonts are identified, some more generic fix would be needed." Well… "If (…) more similar problematic fonts are identified": this kind of statement implies that the problems are yet to be discovered. I think my tests show a general problem, both on macOS and on Linux. That the same behavior occurs on two systems managing fonts in very different ways shows in my opinion (and for any observer, I think) that the problem is systematic. It would be more accurate to say: "we know there is a general problem, that it is still not solved, and we've only solved some very specific cases".
(In reply to Thomas Linard from comment #72) > According to > https://www.collaboraoffice.com/community-news/recent-mac-specific-fixes-in- > libreoffice/ the bug is gone. So, I did my tests again: in reality, nothing > has changed. > > > Test report with LibreOffice 6.1 Beta 2, macOS 10.13.5 > > Open-source fonts installed (in OTF version each): > ... > Overpass version 3.0.2 (16 styles) > http://overpassfont.org/ > ... > Overpass: 2 styles are missing > Overpass Heavy > Overpass Heavy Italic I tested Overpass on Windows 7 today and found different issues. Perhaps on the different OSs different font meta data is used resulting in different issues. I am guessing that if the fonts had all the meta data filled-in My findings today: Overpass -------- Thin and ExtraLight - wrong screen display and print output. Export to PDF is correct. There is an error in the SemiBold regular font file – it has the font family set to Overpass Light. After fixing this file the Overpass SemiBold regular displays correctly. Overpass Mono ------------- There is an error in the OverpassMono SemiBold font file – it has the font family set to Overpass Mono Light. After fixing this file the OverpassMono SemiBold displays correctly. Since you did not have these errors, but different errors, I am wondering what font info is read by default, and then by fallback if missing, in each OS. And if this may be one source of issues. p.s. doing Fira Sans tomorrow ...
This is a Mac-specific bug report. It even says so in the title. Please don't confuse it by reporting findings on Windows here.
Thomas: Of course any writing can always be improved. And depending on who one asks, one even gets different ideas how to improve it. Endless bike-shedding possibilities! But is this bugzilla really the place to discuss what was written in some marketing material some time ago? Also, yes, I don't think anybody who has worked on the code is unaware that the handling of styles of a font family in LibreOffice could be improved a lot, cross-platform.
(In reply to Tor Lillqvist from comment #78) > Thomas: Of course any writing can always be improved. And depending on who > one asks, one even gets different ideas how to improve it. Endless > bike-shedding possibilities! But is this bugzilla really the place to > discuss what was written in some marketing material some time ago? > > Also, yes, I don't think anybody who has worked on the code is unaware that > the handling of styles of a font family in LibreOffice could be improved a > lot, cross-platform. I only want to point out that the bug isn't about some bad fonts or some specific fonts. I've chosen three typeface families for testing (open source, no problem to download for everybody), but I could take 30, 300 or 3000 with the same kind of results. If this point is clear for everybody, fine!
(In reply to Tor Lillqvist from comment #77) > This is a Mac-specific bug report. It even says so in the title. Please > don't confuse it by reporting findings on Windows here. I think part of the problem is these are not looked at together. Some of the problems appear to be font defects. Some of the problems may be the font meta data, or lack thereof. Until Windows, Mac, and Linux testers are testing the same font families, and those font families are determined to not have bugs or have been fixed, and comparing what works and what does not work by platform, this is just a scattershot approach. Bundled fonts may be "corrected/enhanced* and some issues may go away. Right now this is just random problem reports.
(In reply to LibreTraining from comment #80) > I think part of the problem is these are not looked at together. > Some of the problems appear to be font defects. > Some of the problems may be the font meta data, or lack thereof. If you think fonts have bugs, please report them to their creator (it can actually happen, but it's rare, and if the tricks around the nameID 1 & 2 that were used 15 years ago to get around the problems beyond RIBBI are no longer those in favor today, it doesn't matter, as long as the nameID 4, 6, 16 and 17, possibly 21 and 22, are correct). > Until Windows, Mac, and Linux testers are testing the same font families, > and those font families are determined to not have bugs or have been fixed, > and comparing what works and what does not work by platform, > this is just a scattershot approach. > > Bundled fonts may be "corrected/enhanced* and some issues may go away. Most of the time, proprietary licenses for fonts doesn't allow modification (and never, ever, distribution of modified fonts). So you've to deal with the fonts in the state they're in.
*** Bug 118897 has been marked as a duplicate of this bug. ***
*** Bug 119116 has been marked as a duplicate of this bug. ***
I seem to be having the same problem on Ubuntu and on Fedora and I stumbled upon an interesting discovery. My fonts are installed system-wide (/usr/share/fonts) and initially are all recognized by libreoffice. Once I change the default language though, in my case from English US to English UK the different font weight/families are not recognized properly. The same happens with libreoffice installed from the repositories and from flatpak. I though you should know as it might help you determine the source of this bug
(In reply to giannis.sc from comment #84) > I seem to be having the same problem on Ubuntu and on Fedora and I stumbled > upon an interesting discovery. > > My fonts are installed system-wide (/usr/share/fonts) and initially are all > recognized by libreoffice. Once I change the default language though, in my > case from English US to English UK the different font weight/families are > not recognized properly. > > The same happens with libreoffice installed from the repositories and from > flatpak. > > I though you should know as it might help you determine the source of this > bug Hi, you're right, this isn't a Mac only bug: Linux bug is bug 98596.
(In reply to Thomas Linard from comment #85) > (In reply to giannis.sc from comment #84) > > I seem to be having the same problem on Ubuntu and on Fedora and I stumbled > > upon an interesting discovery. > > > > My fonts are installed system-wide (/usr/share/fonts) and initially are all > > recognized by libreoffice. Once I change the default language though, in my > > case from English US to English UK the different font weight/families are > > not recognized properly. > > > > The same happens with libreoffice installed from the repositories and from > > flatpak. > > > > I though you should know as it might help you determine the source of this > > bug > > Hi, you're right, this isn't a Mac only bug: Linux bug is bug 98596. Well I know that it is not an Mac only bug. My point is I think i have found the source of the bug. I have initially installed Libreffice with the US locale and initially LibreOffice works fine recognize all fonts, weights and their families once I go into LibreOffice settings and attempt to change the language say from US to UK and upon restart it stops recognizing font families and weight. As soon I go back to the default then the problem is solved Might be worth looking into
*** Bug 123725 has been marked as a duplicate of this bug. ***
*** Bug 124187 has been marked as a duplicate of this bug. ***
*** Bug 127377 has been marked as a duplicate of this bug. ***
Changing priority to 'high' since the number of duplicates is 5 or higher
Changing priority to 'highest' since this a regression and the number of duplicates is higher than 5 or the number of people in CC higher than 20
(In reply to giannis.sc from comment #86) > I have initially installed Libreffice with the US locale and initially > LibreOffice works fine recognize all fonts, weights and their families once > I go into LibreOffice settings and attempt to change the language say from > US to UK and upon restart it stops recognizing font families and weight. As > soon I go back to the default then the problem is solved > > Might be worth looking into I have tested that, and it’s true: With locale setting "German (Germany)", font families, optical sizes and styles get recognized differently than with locale setting "Englisch (USA)" (see my attached image below). Under the German settings, Optical sizes (Subhead, Caption etc.) don’t appear at all. Under the USA settings, i get a non-structured "stew". As you can see in the attached image, both settings are not satisfying. Either, everything should be summarized under one single Family (Adobe Jenson Pro, Cecilia LT Pro), or all the Optical Sizes should have one entry (Adobe Jenson Pro, Adobe Jenson Pro Cap, Adobe Jenson Pro Subh, Adobe Jenson Pro Disp) with all the weights under them. Also widths (e.g. Condensed or Narrow) could get a separate entry, but weights should never have one because they belong to "Style". Instead of writing a long manual about how I think it would best be done, I highly recommend: Just look at how it is done in Scribus 1.5.5 (also see image). Maybe it is possible to do it that way.
Created attachment 156391 [details] Font recogniction in LibreOffice Writer
I have to partly relativize what I said above: The "stew" came from inconsistencies in the font files. I have adjusted the attached image accordingly. But what holds true is that, depending on the locale setting, LO accesses different information in the font files. It seems that, with the USA setting, LO accesses the information behind "family" in the "TTF Names", and with the German setting, LO accesses the information behind "Preferred Family". At the moment, the way it is done by the USA setting is better because, as another bug report stated, LO can only handle a limited amount of font weights/styles. What that leads to is that different optical sizes are simply not shown and thus unusable. Therefore, it needs to be done either the "USA way" or the "Scribus way". Scribus seems to access "Preferred Family" too, but it can handle more font weights and styles.
Created attachment 156419 [details] Font recognition in LibreOffice (locale USA and Germany) and Scribus
This bug is marked as Mac related but I see the issue somehow on all platforms. So what about having a common bug describing the generic issues related to the LO code and three depending bug tickets describing the OS specific issues? We use TrueType Font Titillium (https://fontain.org/titillium/) which has similar issues like Fira Sans. The generic issue I see is the way how LO retrives the font (family) names and style names. Is there any pattern/logic we could describe here to identif the wrong behavior? On Windows and Mac for most applications this is not an issue. Font family names are retrived from TTF metadata (Preferred Family, Family, Postscript Name) and similar Style names (Preferred Syles, Styles (SubFamily), OS/2 Style Map, OS/2 Panose Weight, Postscript Weight). Using LibreOffice 6.3.4.2 On Windows 10: * Font names seems to be retrieved from Postscript Family Name (I checked with different locales - same result) * Style names are quite unclear - some are translated from TTF Style names, some from PS style names? * Once I modified all PS family names to absolute names like "Titillium Lite", "Titillium Black" instead of "Titillium" I was able to work with the font on Windows since LO handles the fonts as different fonts. This also works on printouts / created PDFs. Still unclear is how LO retrieves the font style. The distinct font "Titillium Lite" should only contain one style "light" but contains Standard, Italic, Bold, Italic Bold. How to force only the styles contained in the font family name? On MacOS 10.13 / Ubuntu 18: * Font names seem to be retrieved from TTF "Preferred Family" which is different (!): "Titillium". As a consequence it is not possible to share LO docs between Windows and MacOS/Linux becuase LO complains about missing fonts. * Style "Thin" could be selected but style "Light" is used for display an printout. I played with different OS/2 Panose Weight, Postscript Weight and OS/2 weight classes without success. It seems there is a hardcoded issue to distinguesh thin and light styles even the OS/2 weight classes differ (100, 200). As a first step LO should retrieve the font family and font style name the same way on all platforms. Of course then at least one platform has to translate font names in existing documents but that is already the daily nightmare in mixed OS environments. Addtionally we should know how LO maps style names to the 10 possible variants it supports. What are the priorities and which properties are relevant? Same for special style variants regular/italic/bold - which property is used for the LO style list? Understanding this logic would help uses to work around todays restrictions by manipulating their fonts. Long term LO should refactor the font style limitation by supporting unlimited number of styles and to use "Preferred Family" and "Preferred Styles" from TTF metadata if available.
> This bug is marked as Mac related but I see the issue somehow on all platforms Sure, but have you looked at the source code? LO uses different code on different platforms to enumerate fonts and classify them. There might be bugs in the code for one platform that doesn't as such exist identically on other platforms. But yeah, if bug reporters insist on mixing in issues seen on other platforms in this bug, go ahead, this bug report is practically useless already with so much noise.
*** Bug 145041 has been marked as a duplicate of this bug. ***
I suggest people stop marking more bugs as duplicates of this bug since it is not really helpful. I don’t even know what this bug is about anymore and I’m inclined to close it after reviewing the rest of the duplicates.
I’m closing this bug now since there is nothing left here, all duplicated bugs have been de-duplicated and are either left open or closed as appropriate.