Bug 35538 - Handling of fonts with more than 4 styles (R/B/I/BI) is suboptimal
Summary: Handling of fonts with more than 4 styles (R/B/I/BI) is suboptimal
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: topicUI
: 69881 93157 112857 143013 144868 (view as bug list)
Depends on: 112973
Blocks: Font-Rendering Font-List 151322
  Show dependency treegraph
 
Reported: 2011-03-22 05:06 UTC by GwenDragon
Modified: 2024-09-18 06:10 UTC (History)
47 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of character formatting with Kallos ITC (56.18 KB, image/jpeg)
2011-03-22 05:06 UTC, GwenDragon
Details
PDF of galliard test document (244.69 KB, application/pdf)
2012-05-25 16:27 UTC, NoOp
Details
ODT of galliard test document. (227.75 KB, application/vnd.oasis.opendocument.text)
2012-05-25 16:27 UTC, NoOp
Details
PDF of with Kallos formatted ODT (expected result) (236.31 KB, application/pdf)
2014-06-24 07:15 UTC, GwenDragon
Details
PDF of with Kallos formatted ODT (real result) (156.89 KB, application/pdf)
2014-06-24 07:17 UTC, GwenDragon
Details
Screen recording (GIF) showing loss of font format with font family Kallos (1.57 MB, image/gif)
2016-11-10 09:37 UTC, GwenDragon
Details
Screenshot of Style Editor showing the wrong font variant name (22.05 KB, image/png)
2019-08-15 11:54 UTC, Jorrit Linnert
Details
Screenshot showing all variants in Merriweather Sans typeface family (in PT-BR locale with mixed EN-US names) (30.69 KB, image/png)
2023-08-17 19:21 UTC, João Paulo
Details
Screenshot with different behavior of Merriweather Sans (72.60 KB, image/png)
2023-08-18 11:32 UTC, Eyal Rozenberg
Details
Merriweather Sans showing as three different typeface's families. (40.57 KB, image/png)
2024-05-14 16:00 UTC, João Paulo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description GwenDragon 2011-03-22 05:06:08 UTC
Created attachment 44709 [details]
Screenshot of character formatting with Kallos ITC

I'm using Kallos ITC family and in this family six fonts exists:
Kallos ITC Book
Kallos ITC Book Italic
Kallos ITC Medium
Kallos ITC Medium Italic
Kallos ITC Bold
Kallos ITC Bold Italic

Linux shows the fonts as:

user12@pc:~$ fc-list | grep Kallos
Kallos ITC:style=Bold
Kallos ITC:style=Book
Kallos ITC:style=Medium
Kallos ITC:style=Bold Italic
Kallos ITC:style=Medium Italic
Kallos ITC:style=Book Italic

1) LibreOffice shows Kallos ITC Medium as Regular in font selection (picture)!
Strange!

2) If i create a textdocument with a text formatted as Kallos ITC Medium and Kallos ITC Medium italic and reopens in LibreOffice the charcater settings are reset to Kallos ITC Book
LibreOffice does not remmber the font settings.

Seems to be the same as openoffice bug from 2007: http://openoffice.org/bugzilla/show_bug.cgi?id=82986
Comment 1 GwenDragon 2011-03-22 05:07:54 UTC
Font pack can be send to tester for testing only if desired.
Comment 2 GwenDragon 2011-04-02 01:02:33 UTC
Bugfix is important.

LibreOffice should support komplex font families and handle the character formatting with thes fonts.
It would be useless for professionell office work with missing font support.
Comment 3 GwenDragon 2011-07-19 05:23:05 UTC
Same problem in 3.3.2
Comment 4 Cor Nouws 2011-08-02 11:29:52 UTC
.
Comment 5 Björn Michaelsen 2011-12-23 11:43:26 UTC Comment hidden (obsolete, spam)
Comment 6 GwenDragon 2011-12-27 10:21:49 UTC
Bug still exists in:  
LOdev 3.5.0beta2 
Build-ID: c3bcb31-760cc4d-f39cf3d-1b2857e-60db978

Tested on Ubuntu 11.04 x64
Comment 7 GwenDragon 2012-04-27 05:01:38 UTC
Problem exists on 
LibreOffice 3.5.2.2 
Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f

Linux KUbuntu 11.04 x64
Comment 8 NoOp 2012-05-25 16:25:22 UTC
I can verify with another ITC OpenType font:

I have _many_ ITC fonts on my Ubuntu/Debian system (way too many to list here), and for the most part I can select them in LO (3.5.3.2)[1]. For example, if I select an ITC .otf font galliard:

$ locate galliard
/home/<user>/.fonts/galliard-black.otf
/home/<user>/.fonts/galliard-blackitalic.otf
/home/<user>/.fonts/galliard-bold.otf
/home/<user>/.fonts/galliard-bolditalic.otf
/home/<user>/.fonts/galliard-italic.otf
/home/<user>/.fonts/galliard-roman.otf
/home/<user>/.fonts/galliard-ultra.otf
/home/<user>/.fonts/galliard-ultraitalic.otf

As you can see, the only galliard fonts on this system are .otf.

In LO 3.5 (via Format|Character) I can select ITC Galliard:
Ultra
UltraItalic
Roman
Italic
Bold
Bold Italic
Black
Ultra Italic
Black Italic

I made a file with each font selection, took a screenshot & added it to the file, saved the file, closed LO and reopened LO and the file.

Before saving I noticed that the bolding seemed to be backwards (with bold selected the font appears normal, with bold unselected from LO icon the font appears bold).

After saving I noticed (in addition to the bolding) when checking Format|Charater:
- Italic changed UltraItalic
- Roman changed to Ultra
It is repeatable & I'll add a pdf and odt of the document.

[1] LibreOffice 3.5.3.2 
Build ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b8
Comment 9 NoOp 2012-05-25 16:27:05 UTC
Created attachment 62116 [details]
PDF of galliard test document
Comment 10 NoOp 2012-05-25 16:27:48 UTC
Created attachment 62117 [details]
ODT of galliard test document.
Comment 11 GwenDragon 2012-10-17 13:42:42 UTC
Problem still exists in LibreOffice 3.6.1.2 with Linux Debian 6 x64
Comment 12 GwenDragon 2012-10-17 13:47:21 UTC
Forgot information about sys for previous comment:

LibreOffice 3.6.1.2  Build ID e29a214
KDE 4.8.4
Debian 6.06
Comment 13 GwenDragon 2013-04-10 14:38:00 UTC
My problem with font described in 1) and 2) still exists in:

Libreoffice Version 3.6.5.2 (Build ID: 5b93205)
Debian 6 x64, KDE 4.8.4

1) Kallos ITC Bold is displayed as Bold
Kallos ITC Medium is displayed as Standard

2) Formatting for Kallos ITC Medium is reset to Kallos ITC Book
Comment 14 GwenDragon 2014-04-28 10:30:06 UTC
Bug confirmed for 
Libreoffice 4.1.5.3 Build-ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24
Debian 7.2 x64, KDE 4.8.4
Comment 15 GwenDragon 2014-06-24 07:03:27 UTC
Bug mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=35538#c13 confirmed for LbreOffice 4.2.4.2 Build-ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
on Debian 7.5 x64 KDE
Comment 16 GwenDragon 2014-06-24 07:15:06 UTC
Created attachment 101641 [details]
PDF of with Kallos formatted ODT (expected result)

Formatted with Kallos ITC as it should really be after opening ODT with LibreOffice
Comment 17 GwenDragon 2014-06-24 07:17:05 UTC
Created attachment 101642 [details]
PDF of with Kallos formatted ODT (real result)

This PDF shows that LibreOffice lost format of text KallosITCMedium after reopening ODT
Comment 18 GwenDragon 2014-10-27 15:20:17 UTC
Confirmed for Libreoffice Version: 4.2.6.3 Build-ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
on Debian 7.7 x64 with KDE 4.8.4
Comment 19 GwenDragon 2014-11-28 10:39:15 UTC
Same problem of loosing formatting after saving and reopening document.
 
LibreOffice 4.3.3.2 Build-ID: 430m0(Build:2)
KDE 4.14.2 on Debian 7 Testing
Comment 20 dkcmtdfned 2015-11-06 13:08:44 UTC
I have been experiencing what I believe to be the same problem described in this bug with LibreOffice versions 4.4.6.3 and 5.0.3.2.
Comment 21 QA Administrators 2016-11-08 11:56:09 UTC Comment hidden (obsolete, spam)
Comment 22 GwenDragon 2016-11-08 13:35:32 UTC
Confirmed for
Libreoffice 5.2 x64 
Version: 5.2.3.1 Build-ID: 1:5.2.3~rc1-4~bpo8+1
Debian 8.6 x64 KDE 4.14.2
Comment 23 GwenDragon 2016-11-08 13:53:43 UTC
Confirmed for
Libreoffice  4.3 
Version: 4.3.3.2 
Build ID: 430m0(Build:2)
Debian 8.6 x64 KDE 4.14.2
Comment 24 Cor Nouws 2016-11-09 20:07:41 UTC
@Khaled

is this something that touches your work on fonts/rendering, maybe? Thanks!

Subject: Re: [tdf-discuss] Libnreoffice Writer (3.x, 4.x, 5.x) on Linux
looses font  formt after repening document
Date: Wed, 9 Nov 2016 19:49:19 +0100
From: GwenDragon <info@gwendragon.de>
To: Cor Nouws <oolst@nouenoff.nl>

Hello Cor,
On Wed, 9 Nov 2016, at 13:23:34 [GMT +0100] (which was 13:23 where I
live) Cor wrote:

> Now that I'm writing this: there is some changes ongoing in font
> handling at the moment. Can you try a fresh daily build maybe?
> http://dev-builds.libreoffice.org/daily/master/

Unfortunately the daily 5.3 dev build did not find the Type 1 fonts.
The fonts are not shown in fonts list/dropdown.
Comment 25 GwenDragon 2016-11-10 09:37:30 UTC
Created attachment 128639 [details]
Screen recording (GIF) showing loss of font format with font family Kallos

Shows that the previous set font style of Kallos ITC Medium is reset after saving and reopening document.
Comment 26 ⁨خالد حسني⁩ 2016-11-10 18:54:01 UTC
This might be related to the fact that we don’t handle fonts that has more than four styles R/B/I/BI quite well. But that is related to font selection not layout.
Comment 27 Thomas Linard 2016-12-30 15:57:33 UTC
Indeed, LibreOffice doesn't handle fonts that has more than four styles R/B/I/BI quite well. I don't know for Linux, but Windows and macOS (since LO 4.1) use platform dependent handling.
LibreOffice on Windows use traditional GDI handling, LibreOffice on macOS use CoreText (and, probably, incorrectly, as the styles names are localised). See my Bug 69881 for LibreOffice 4.1, still valid for 5.3. And the numerous duplicates of Bug 69254.
Comment 28 Xisco Faulí 2017-07-13 11:00:11 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 29 Thomas Linard 2018-01-05 09:55:07 UTC
*** Bug 72944 has been marked as a duplicate of this bug. ***
Comment 30 Thomas Linard 2018-01-05 09:55:37 UTC
*** Bug 69254 has been marked as a duplicate of this bug. ***
Comment 31 Thomas Linard 2018-01-05 09:57:09 UTC
*** Bug 101905 has been marked as a duplicate of this bug. ***
Comment 32 Thomas Linard 2018-01-05 09:57:28 UTC
*** Bug 89242 has been marked as a duplicate of this bug. ***
Comment 33 Thomas Linard 2018-01-05 09:57:41 UTC
*** Bug 79726 has been marked as a duplicate of this bug. ***
Comment 34 Thomas Linard 2018-01-05 09:57:51 UTC
*** Bug 69881 has been marked as a duplicate of this bug. ***
Comment 35 Thomas Linard 2018-01-05 09:58:10 UTC
*** Bug 68889 has been marked as a duplicate of this bug. ***
Comment 36 Thomas Linard 2018-01-05 09:59:08 UTC
*** Bug 72938 has been marked as a duplicate of this bug. ***
Comment 37 Thomas Linard 2018-01-05 10:01:41 UTC
*** Bug 100835 has been marked as a duplicate of this bug. ***
Comment 38 Thomas Linard 2018-01-05 10:02:23 UTC
*** Bug 87288 has been marked as a duplicate of this bug. ***
Comment 39 Thomas Linard 2018-01-05 10:03:20 UTC
*** Bug 98596 has been marked as a duplicate of this bug. ***
Comment 40 Thomas Linard 2018-01-05 10:06:20 UTC
*** Bug 105298 has been marked as a duplicate of this bug. ***
Comment 41 Thomas Linard 2018-01-05 10:16:23 UTC
*** Bug 83006 has been marked as a duplicate of this bug. ***
Comment 42 Thomas Linard 2018-01-05 10:16:47 UTC
*** Bug 93157 has been marked as a duplicate of this bug. ***
Comment 43 Thomas Linard 2018-01-05 10:17:15 UTC
*** Bug 95816 has been marked as a duplicate of this bug. ***
Comment 44 How can I remove my account? 2018-01-22 17:47:39 UTC
Even if this problem apparently is present on all platforms, the actual font enumeration code is still platform-specific, so separate fixes might well be needed for macOS, Windows, and Linux.
Comment 45 How can I remove my account? 2018-01-22 21:23:53 UTC
The font enumeration and UI aspect is just one part of the issue. What apparently hasn't been taken into consideration at all in the comments above is how to handle the "extra" styles in the document formats, in a backward-compatible way, so that the document wouldn't break horribly if opened in another application reading the same format, or in an older version of LibreOffice. Far from trivial.
Comment 46 Thomas Linard 2018-01-22 22:15:06 UTC
But the documents are already "breaking horribly" because of platform-specific handling…
Comment 47 How can I remove my account? 2018-01-23 12:07:08 UTC
Actually, I take my previous comment back. It was pointed out to me that even if the toolbar just has a typeface selector and the B and I buttons, in the right-click:Character...:Font dialog there is a separate "Style" selector (sadly called "Typeface" on the Mac), and with that one can select any of the styles the typeface is available in. For instance, for the Overpass typeface, "Thin Italic".

See my further comments in https://bugs.documentfoundation.org/show_bug.cgi?id=69254#c32
Comment 48 Thomas Linard 2018-01-30 14:02:11 UTC
I organized the bugs this way:

Bug 35538 (this bug)
  blocked by:
  bug 69254 (CoreText bugs - Mac)
  bug 72944 (future DirectWrite implementation - Windows)
  bug 98596 (FontConfig bugs - Linux)
  bug 105298 (cross-platform bugs)

Bug 35538 (this bug)
   blocking:
   bug 103596 (future Variable Fonts implementation)
Comment 49 ⁨خالد حسني⁩ 2018-02-01 19:26:37 UTC
*** Bug 112857 has been marked as a duplicate of this bug. ***
Comment 50 V Stuart Foote 2018-08-06 01:30:58 UTC
*** Bug 119116 has been marked as a duplicate of this bug. ***
Comment 51 Jorrit Linnert 2019-08-15 11:54:08 UTC
Created attachment 153410 [details]
Screenshot of Style Editor showing the wrong font variant name

This dialogue belongs to the Heading 2 style, but that is probably unimportant
Comment 52 Jorrit Linnert 2019-08-15 12:09:23 UTC
LibreOffice 6.2.5.2, Ubuntu Linux 19.04:

After adding the Futura font to my system and refreshing the font cache, only the general font name 'Futura' appears in the font selection dropdown in the main UI of Writer. Not the variant weights (see below)

A .docx-file featuring the Medium font weight, seems to convert the sections using the Medium variant to the Condensed ExtraBold variant. 
I have not tested what happens if another File Format is used to save the file.

When I open the style editor to edit the Heading 2 style, I do see the weights, but one of the variants has the wrong name.

Variants in Font:
- Medium
- Condensed Medium
- Condensed ExtraBold
- Italic

Variants shown in Style Editor (see screenshot)
- Condensed Medium
- 中黑
- Condensed ExtraBold
- Italic

Note that my default language is English
The two Chinese characters are Zhong Hei (middle black), which might translate to 'Medium Black'. I'm no expert in Chinese, so I can only take a guess.

Thank you in advance for fixing this annoying bug.
Comment 53 Volga 2020-05-07 09:47:17 UTC
(In reply to Thomas Linard from comment #27)
> Indeed, LibreOffice doesn't handle fonts that has more than four styles
> R/B/I/BI quite well. I don't know for Linux, but Windows and macOS (since LO
> 4.1) use platform dependent handling.
> LibreOffice on Windows use traditional GDI handling, LibreOffice on macOS
> use CoreText (and, probably, incorrectly, as the styles names are
> localised). See my Bug 69881 for LibreOffice 4.1, still valid for 5.3. And
> the numerous duplicates of Bug 69254.
Windows GDI can handle only 4 styles: R/B/I/BI

Additionally, there are some fonts has limited use of style-linking, for example, Source Han Sans has only Regular and Bold weights are style-linked, other weights will appearing in the font menu.
See: https://github.com/adobe-fonts/source-han-sans/blob/release/SourceHanSansReadMe.pdf
Comment 54 Henrik 2020-05-17 11:23:46 UTC
Confirming a very similar issue on a fresh install Ubuntu 20.04 with LibreOffice  Writer v6.4.3.2 from the Ubuntu repository.

Issue
=====

OTF font weights "Medium", "Medium Italic", "Mediumxxxxyyyyzzzz"
are not selectable in LibreOffice v6.4.3.2. Those fonts have to be renamed "-Medium", "-Medium Italic", "-Mediumxxxxyyyyzzzz" to show up as selectable weights.

Proposed Discussion
===================

According to
https://www.webtype.com/info/articles/fonts-weights/
https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass
Section 2.3 Weight in
https://monotype.github.io/panose/pan2.htm

the following commonly appearing font weights should at least be able to be detected and shown as selectable by LibreOffice Writer font selector:

Thin
Very Light
Extra Light
Ultra Light
Light
Semi Light
Book
Demi
Normal
Regular
Medium
Semibold
Demibold
Bold
Heavy
Black
Extra Bold
Extra Black
Fat
Poster
Ultra Black
Nord

Test case
=========

Create a random test font with FontForge.
Fill the font with some glyphs like A-Z,a-z for testing.
In the "Font Info..." dialog (Ctrl+Shift+F)
select "TTF Names" table
and set entry 
"Styles (Subfamily)" = "Medium"
and entry
"Preferred Styles" = "Medium"
Create OTF font (test.otf) with FontForge.
Install the new test font (test.otf) in $HOME/.local/share/fonts/
Restart LibreOffice Writer so it detects the new font.
Type some text, select it, right-click, select "Character..."
and change the font to your new font with font weight "Medium".
"Medium" will not appear in the list of selectable font weights.

Result
======

If an OTF font's TTF Name table entry "Styles (Subfamily)" or "Preferred Styles" has a string starting with "Medium", LibreOffice Writer will not display it as selectable font weight in the font selection dialog. It does not matter if you set the "Styles (Subfamily)" = "Mediumxyz" and "Preferred Styles" = "Mediumxyz". Strings like "Medium Italics" wont show up either.

Workaround
==========

With FontForge:
In the "Font Info..." dialog (Ctrl+Shift+F)
select "TTF Names" table
Set entry 
"Styles (Subfamily)" = "-Medium"
and entry
"Preferred Styles" = "-Medium"

Regenerate the test font (test.otf) with FontForge.
Install/overwrite the new test font (test.otf) in $HOME/.local/share/fonts/
Restart LibreOffice Writer so it detects the new font.
Type some text, select it, right-click, select "Character..."
and change the font to your new font with font weight "-Medium".
"-Medium" will now appear in the list of selectable font weights.
Comment 55 jach hunter 2020-12-17 12:16:26 UTC Comment hidden (spam)
Comment 56 V Stuart Foote 2021-06-23 21:20:28 UTC
*** Bug 143013 has been marked as a duplicate of this bug. ***
Comment 57 V Stuart Foote 2021-06-24 13:22:41 UTC Comment hidden (obsolete)
Comment 58 Heiko Tietze 2021-06-28 09:42:44 UTC Comment hidden (obsolete)
Comment 59 Ming Hua 2021-10-02 14:49:45 UTC
*** Bug 144868 has been marked as a duplicate of this bug. ***
Comment 60 GwenDragon 2022-04-27 12:48:59 UTC
Issue still exists 7.3.3.2 Windows and 7.3.1.3 Linux.
Have trouble with an other font "ITC Souvenir Std".
Comment 61 ⁨خالد حسني⁩ 2022-10-02 07:21:28 UTC
This is basically a Windows/MS Office compatibility issue.

First, LibreOffice is can fonts with more than 4 styles (though it can be improved). However, GDI and MS Office can’t.

On Windows we use GDI to get font family and style, and it can only give is families with max of 4 styles, OpenType even have a workaround for this, so fonts with more styles can appear as multiple families in such applications (e.g. Foo, Foo Light, Foo Black, etc). On Linux and macOS we use APIs that has no such limitation, so a document made on Windows would be using font family Foo Light and style Regular, but on Linux or macOS we want family Foo and style Light.

There are two ways to fix this whole mess:
1) Forgo Windows/MS Office compatibility and find a way to get the real family and style on Windows.
2) Enforce the compatibility contains on Linux and macOS and use the same family and style names as on Windows.

On the technical side, solution 1) means using name ID 1 for family and ID 2 for style, and solution 2) means using IDs 16 and 17 (and falling back to IDs 1 and 2 if they are missing).

It shouldn’t be hard to implement either of these two solutions, but I don’t know whose call is to make this decision.
Comment 62 Eyal Rozenberg 2022-10-02 10:59:28 UTC
(In reply to خالد حسني from comment #61)
> This is basically a Windows/MS Office compatibility issue.

I disagree, see argument below.

> On Windows we use GDI

Considering that GDI is a legacy component:
https://en.wikipedia.org/wiki/Graphics_Device_Interface

we should probably not be using it on Windows, regardless of anything else.

> to get font family and style, and it can only give is
> families with max of 4 styles, OpenType even have a workaround for this, so
> fonts with more styles can appear as multiple families

That's better than nothing, but not good enough, as it creates its own problems - compatibility-wise and by confusing users, with the list of font families no longer containing just font families.

> There are two ways to fix this whole mess:
> 1) Forgo Windows/MS Office compatibility and find a way to get the real
> family and style on Windows.
> 2) Enforce the compatibility contains on Linux and macOS and use the same
> family and style names as on Windows.

That's not true. We can _keep_ Windows/MS-Office compatibility, _and_ get the real family, weight and style on Windows, _and_ expose the range of weights to the user, _and_ be compatible with Linux and MacOS. 

The only "problem" seems to be writing documents intended to be opened in MS-Office. When we do that, we would probably need to sort-kinda keep doing what were doing today, so that MS-Word can use the right font.

But that should be addressed at most as a toggle-able save option, not by crippling LibreOffice... 


PS - Of course that would take some serious low-level work. So an argument such as "this is not a high priority" could perhaps be made.
Comment 63 ⁨خالد حسني⁩ 2022-10-02 13:31:25 UTC
(In reply to Eyal Rozenberg from comment #62)
> (In reply to خالد حسني from comment #61)
> > This is basically a Windows/MS Office compatibility issue.
> 
> I disagree, see argument below.
> 
> > On Windows we use GDI
> 
> Considering that GDI is a legacy component:
> https://en.wikipedia.org/wiki/Graphics_Device_Interface
> 
> we should probably not be using it on Windows, regardless of anything else.

That is besides the point, even if we switch to something else, we will need to emulate the old naming scheme otherwise existing documents using it will be broken.

> > to get font family and style, and it can only give is
> > families with max of 4 styles, OpenType even have a workaround for this, so
> > fonts with more styles can appear as multiple families
> 
> That's better than nothing, but not good enough, as it creates its own
> problems - compatibility-wise and by confusing users, with the list of font
> families no longer containing just font families.
> 
> > There are two ways to fix this whole mess:
> > 1) Forgo Windows/MS Office compatibility and find a way to get the real
> > family and style on Windows.
> > 2) Enforce the compatibility contains on Linux and macOS and use the same
> > family and style names as on Windows.
> 
> That's not true. We can _keep_ Windows/MS-Office compatibility, _and_ get
> the real family, weight and style on Windows, _and_ expose the range of
> weights to the user, _and_ be compatible with Linux and MacOS. 
> 
> The only "problem" seems to be writing documents intended to be opened in
> MS-Office. When we do that, we would probably need to sort-kinda keep doing
> what were doing today, so that MS-Word can use the right font.
> 
> But that should be addressed at most as a toggle-able save option, not by
> crippling LibreOffice... 

Adding more options is dodging the issue (by exposing the internal to the user) not fixing it. It isn’t only MS Office, but versions of LibreOffice on Windows before the fix, and probably other Windows office suites.

My inclination is to keep things simple and do it the MS way. But, again, that is not my call.
Comment 64 Eyal Rozenberg 2022-10-02 14:32:25 UTC
(In reply to خالد حسني from comment #63)
> even if we switch to something else, we will need
> to emulate the old naming scheme otherwise existing documents using it will
> be broken.

We will only need to do that for documents created before the switch to proper recognition of fonts within a family. But in the UI, and new documents, that should not be a problem. I may be wrong about ODF support, though, since I don't know the ODF spec, so if there are issues there, please mention them.

> Adding more options is dodging the issue (by exposing the internal to the
> user) not fixing it.

It is fixing the issue, because it will allow proper handling of multiple variants of font families. Whenever we have a feature which MS Office doesn't - we can either let our files always break in MS-Office (bad), or drop that feature (also bad - features should not be dictated by Microsoft, especially whe they get things wrong), or distinguish somehow between whether we need to save with or without MS compatibility.

But actually... perhaps it _is_ possible to save both kinds of information at the same time. i.e. save the MSO-compatible font info we do today, but also save some meta-data that MS doesn't use, but we can use, which tells us what the real font variants are. 

What do you think?

> It isn’t only MS Office, but versions of LibreOffice on
> Windows before the fix, and probably other Windows office suites.

Yes, these may all need a compatibility mode when saving in MSO-targeting formats. If it's ODF files - it's no different than saving in a newer version of ODF which is unsupported by older versions of LO.

> My inclination is to keep things simple and do it the MS way. But, again,
> that is not my call.

This is a significant missing feature in LO, and was recognized as NEW, so the question IMNSHO is how to best do this, rather than if it should be done. 

Actually, it goes beyond just that: The choice of some SW makers, in the 1980s or early 1990s, to arbitrarily force the 2x2 style space, is a historic blunder. It needs to be fixed in all personal computing applications. Our not fixing this is holding back others as well, and is mis-educating users about fonts.
Comment 65 Eyal Rozenberg 2022-10-02 18:00:04 UTC
... and one final point is that fixing this offers an advocacy advantage vs MS-Office: It will let us say "LibreOffice offers you fine control over font weight while MS Office only supports Bold/not Bold". Now, sure, that's not some killer feature - but it's very easy to _understand_.
Comment 66 ⁨خالد حسني⁩ 2022-10-02 19:22:22 UTC
Fair points, but that is much more work than I can afford. The simple option is something I think can be done relatively easily, so if no one is going to do the more complex work, that is still better than the inconsistent status quo.

Also, to make sure this is clear, both options allow using all styles of the font option 1) you get:

Foo
 Light
 Light Italic
 Thin
 Thin Italic
 Regular
 Italic
 Medium
 Medium Italic
 Bold
 Bold Italic
 Black
 Black Italic

While with option 2) you get:

Foo
 Regular
 Italic
 Bold
 Bold Italic

Foo Light
 Regular
 Italic

Foo Thin
 Regular
 Italic

Foo Medium
 Regular
 Italic

Foo Black
 Regular
 Italic
Comment 67 Eyal Rozenberg 2022-10-03 04:13:35 UTC
(In reply to خالد حسني from comment #66)
> Also, to make sure this is clear, both options allow using all styles of the
> font option 1) you get:
> 
> Foo
>  Light
>  Light Italic
>  Thin
>  Thin Italic
>  Regular
>  Italic
>  Medium
>  Medium Italic
>  Bold
>  Bold Italic
>  Black
>  Black Italic
> 

Actually, possibly more, see e.g.:
https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight

in terms of weight, there are:
100 	Thin (Hairline)
200 	Extra Light (Ultra Light)
300 	Light
400 	Normal (Regular)
500 	Medium
600 	Semi Bold (Demi Bold)
700 	Bold
800 	Extra Bold (Ultra Bold)
900 	Black (Heavy)
950 	Extra Black (Ultra Black)

and double that by 2, potentially, for an italic variant, or maybe 3 for slanted? etc. 

Now, this also relates to the question of artificial italicization or emboldening. In theory, a font could specify the logic for setting arbitrary weights between 1 and 1000 (at least, CSS4 supports this). There is the question of whether to expose only variants available apriori, or also artificially-obtainable; and how to expose them (e.g. is it a list of all variants, or do we separate weights from other aspects).
Comment 68 ⁨خالد حسني⁩ 2022-10-03 04:40:32 UTC
(In reply to Eyal Rozenberg from comment #67)
> (In reply to خالد حسني from comment #66)
> > Also, to make sure this is clear, both options allow using all styles of the
> > font option 1) you get:
> > 
> > Foo
> >  Light
> >  Light Italic
> >  Thin
> >  Thin Italic
> >  Regular
> >  Italic
> >  Medium
> >  Medium Italic
> >  Bold
> >  Bold Italic
> >  Black
> >  Black Italic
> > 
> 
> Actually, possibly more

This was just an example!
Comment 69 Heiko Tietze 2022-10-04 09:42:06 UTC
I believe users expect a boldness and a slantness category. Today it's on/off for B and I but could become a togglemenubutton with the average bold value for on and all variants in the dropdown, respectively for italic.

IIUC, the font can even be on a interval scale. Meaning we have to allow a setting per spinbox or scalebutton, which restricts it to the dialog. Users should apply PS/CS rather than direct formatting anyway. And B/I in the toolbar could just enable/disable the defined boldness/slantness for this PS/CS.

(In reply to خالد حسني from comment #61)
> It shouldn’t be hard to implement either of these two solutions, but I don’t
> know whose call is to make this decision.

First of all the users by giving input on the ticket. Then the ESC by agreeing to a compromise or by deciding between two options. But ultimately it's the doer who decides.
Comment 70 Eyal Rozenberg 2022-10-04 10:07:31 UTC
(In reply to Heiko Tietze from comment #69)
> I believe users expect a boldness and a slantness category.

Just reminding us that slanted/oblique and italic are two different things:

https://creativepro.com/typetalk-italic-vs-oblique/

... and a font family can theoretically have either, or both. Or - can it?

It may or may not surprise you to know, that in Hebrew typesetting, there's no such thing as an "italic" form; and that doesn't exist in Arabic either. In fact, that's only relevant to Latin fonts. As for slanting - that is always possible, but is _very strongly_ discouraged for Hebrew, and never ever used in any professional typography; it's just not done. I assume the same is true for Arabic, Farsi and Urdu (Khaled or Hossein may know more).

The fact that Microsoft got people used to there being an [I] button is simply another way they were being careless/lazy. It was simply a mistake, which has led to many users of MS-Office to produce horrid printed documents which are simply horrid. In fact, users need to "un-learn" the use of "italic" and "slanted" in Hebrew and Arabic (and users of Latin languages should be more aware of the difference between slanting and italic).
Comment 71 Ming Hua 2022-10-04 13:04:06 UTC
(In reply to Eyal Rozenberg from comment #70)
> Just reminding us that slanted/oblique and italic are two different things:
> 
> [...]
> 
> ... and a font family can theoretically have either, or both. Or - can it?
It's pretty rare, but yes, there exists font families that have both italic and oblique sub-fonts.  A web search gives me Supria Sans [1] as an example.

Also I don't know why you are using oblique and slanted/slantness as synonyms in this discussion.  I am merely a hobbyist of font design, but AFAIK both italic and oblique fonts are considered slanted variants of the upright/roman ones.  And the upright/italic/oblique style differences are usually called slantness of the font.

1. https://www.myfonts.com/collections/supria-sans-font-hvd-fonts
Comment 72 Eyal Rozenberg 2022-10-04 13:37:41 UTC
(In reply to Ming Hua from comment #71)
> (In reply to Eyal Rozenberg from comment #70)
> > ... and a font family can theoretically have either, or both. Or - can it?
> It's pretty rare, but yes, there exists font families that have both italic
> and oblique sub-fonts.  A web search gives me Supria Sans [1] as an example.

By "can it" I just meant that in many non-Latin alphabets it can be said that you can't have either. (Even though technically you can define it and it'll work). 

> Also I don't know why you are using oblique and slanted/slantness as
> synonyms in this discussion. 

I think I'm used to such usage because it's common in the TeX world, see:
https://tex.stackexchange.com/q/68931/5640

but I agree that this might be confusing, so - apologies.
Comment 73 Callegar 2023-02-24 17:43:57 UTC
> AFAIK both italic and oblique fonts are considered slanted variants of the upright/roman ones

As a matter of fact things are more complicated: there are fonts that include italic variants that are not slanted. Formally for some fonts "it is possible to have 'upright italic' designs that have a cursive style but remain upright". In other words, italics is about the letter shape not the slant, even if the large majority of italic fonts have slanted letters. As an example, Knuth's Computer Modern has an upright italics. A more modern example is the Literata font that was commissioned by Google for Play Books.
Comment 74 ⁨خالد حسني⁩ 2023-08-03 16:50:37 UTC
We only support R/B/I/BI font family model for various legacy and compatibility reasons, and that is why families with styles other than these four get handles as separate font families. This is intentional and not a bug.
Comment 75 Eyal Rozenberg 2023-08-04 10:09:47 UTC
(In reply to ⁨خالد حسني⁩ from comment #14)
Ok, so, this is the bug I should have reopened. I made a bit of a mess and I apologize. Now on to my scathing comments...

> We only support R/B/I/BI font family model for various legacy
> and compatibility reasons

The fact that it is easier not to support additional variants, and to force this 2x2 dichotomy, because of how we've done things in the past, or because some inputs have this model, does not legitimize us keeping this limitation. It might mean more work to support a more expressive font selection/specification mechanism and maintain compatibility, but - that's just the work that's required.

> and that is why families with styles other than these
> four get handles as separate font families. This is intentional and not a bug.

It's a bug, even if done intentionally. "Done intentionally" just means someone made the wrong call. It is unreasonable for an office suite to just decide it won't properly support things like a style for making one's font oblique, or increasing the weight to a certain fraction of the maximum etc., because of an ugly "jerry-rigging" of variants into a separate font family.
Comment 76 Eyal Rozenberg 2023-08-04 10:33:11 UTC
See also my longer comment here:

https://bugs.documentfoundation.org/show_bug.cgi?id=66792#c27

(as it is really the same discussion.)
Comment 77 João Paulo 2023-08-08 21:29:34 UTC
(In reply to ⁨خالد حسني⁩ from comment #74)
> We only support R/B/I/BI font family model for various legacy and
> compatibility reasons, and that is why families with styles other than these
> four get handles as separate font families. This is intentional and not a
> bug.

As of Version: 7.5.5.2 (X86_64) / LibreOffice Community, Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e, (or even earlier) LibreOffice supports more than the R/B/I/BI, as it supports Book / Book Italic / Regular / Italic / Bold / Bold Italic / Extra Bold / Extra Bold Italic when the Merriweather Sans font family is selected (available at "https://www.fontsquirrel.com/fonts/merriweather-sans" and at "https://github.com/EbenSorkin/Merriweather-Sans").

However, it doesn't handle the font family well when the character style applied changes the typeface from Book (a lighter variant) to Regular (a bolder variant):  It keeps the typeface as Book instead of changing it to Regular.

Steps to reproduce:

1. Create a new document and change the Default Paragraph Style to use the Merriweather Sans Book typeface.
2. Create or modify a Character Style to use the Merriweather Sans Regular typeface.
3. Type some text and then apply the new or modified Character Style and see that the typeface does not change.
4. Directly apply the change to the character by going to Menu, Format, Character, Font, and select Merriweather Sans Regular, then the typeface will change.

Is it the same bug as the original poster wrote about or is it a new, but related, bug?
Comment 78 Eyal Rozenberg 2023-08-08 22:13:54 UTC
(In reply to João Paulo from comment #77)
Not quite following you... There is no "Book" variant at the link you gave. LO splits Merriweather Sans into 3 families: the original name, "ExtraBold" and "Light", with the ExtraBold having two styles (ExtraBold and ExtraBold Italic) with the others having 4 styles (R/B/I/BI).

(PS - At the link, it tells you to follow a link to a newer and up-to-date version of the fonts: https://github.com/SorkinType/Merriweather-Sans )
Comment 79 Volga 2023-08-17 18:50:21 UTC
So LibreOffice have to jump out of GDI and CoreText for fix, and probably need to implement additional interface to let user choose font weight.

https://www.digitaling.com/articles/956220.html
https://zhuanlan.zhihu.com/p/647925453
https://mattesontypographics.com/
Comment 80 João Paulo 2023-08-17 19:19:08 UTC
(In reply to Eyal Rozenberg from comment #78)
> (In reply to João Paulo from comment #77)
> Not quite following you... There is no "Book" variant at the link you gave.
> LO splits Merriweather Sans into 3 families: the original name, "ExtraBold"
> and "Light", with the ExtraBold having two styles (ExtraBold and ExtraBold
> Italic) with the others having 4 styles (R/B/I/BI).
> 
> (PS - At the link, it tells you to follow a link to a newer and up-to-date
> version of the fonts: https://github.com/SorkinType/Merriweather-Sans )

Maybe it's because I'm on PT-BR locale, but to me it shows Regular / Livro (Book) / Negrito (Bold) / ExtraBold / Itálico (Italic) / BookItalic / Itálico Negrito (Bold Italic) / ExtraBold Italic, as in the screenshot I'll send now.
Comment 81 João Paulo 2023-08-17 19:21:03 UTC
Created attachment 189013 [details]
Screenshot showing all variants in Merriweather Sans typeface family (in PT-BR locale with mixed EN-US names)
Comment 82 Eyal Rozenberg 2023-08-18 11:32:46 UTC
Created attachment 189026 [details]
Screenshot with different behavior of Merriweather Sans

(In reply to João Paulo from comment #81)
> Created attachment 189013 [details]
> Screenshot showing all variants in Merriweather Sans typeface family (in
> PT-BR locale with mixed EN-US names)

Here's what I get. Perhaps we don't have the exact same version(s) of the font family downloaded?

Anyway, I'd say this kind of exemplifies one aspect of the problem, which is the appearance of supposedly different font families. It's inconsistent across applications but I guess it can sometimes be inconsistent within LO due to some changes to the fonts themselves (or LO code? or the locale?).
Comment 83 Volga 2023-09-09 12:39:01 UTC
Another example can be seen on recent version of Microsoft Office/365, which is showing by Matteson Typographics. I've mentioned in comment 79.

https://img1.wsimg.com/isteam/ip/d627c7cf-7c1f-470d-ad76-dda84041d982/AptosFontMenuImage.png

Here you can see so many typefases have a sub menu to choose what font weight you want to use on document.
Comment 84 Robert Deck 2023-12-07 11:53:42 UTC Comment hidden (spam)
Comment 85 GwenDragon 2023-12-07 12:02:56 UTC
The bug is still valid in 7.6.3.2
Comment 86 Robert Deck 2023-12-07 12:03:40 UTC Comment hidden (spam)
Comment 87 Robert Deck 2023-12-07 12:10:14 UTC Comment hidden (spam)
Comment 88 Robert Deck 2023-12-07 12:14:38 UTC Comment hidden (spam)
Comment 89 João Paulo 2024-05-14 16:00:13 UTC
Created attachment 194118 [details]
Merriweather Sans showing as three different typeface's families.

I think the problem got worse, as now the Merriweather Sans typeface family (the latest version available at "https://github.com/SorkinType/Merriweather-Sans") shows as three different typeface's families.

It is bad because when we chose the Merriweather Sans Light ("Claro", in PT-BR), if we apply the bold style (either with the toolbar button or with the "Emphasis" character style), LibreOffice Writer applies a fake bold style derived from the Merriweather Sans Light instead of getting the Merriweather Sans Bold.

A (ugly) workaround is creating several styles to choose, but it easily gets prone to errors:

* My documents are formatted with both the Merriweather Sans Regular (for the main body text) and Light styles (for the quotation blocks), and I have to use two character styles for emphasis (the default "Strong Emphasis" character style that adds only bold and a dark-green color to the characters, and an additional, custom, "Emphasis on light to bold" that selects the Merriweather Sans Bold and a dark-green color to the characters -- this is needed to avoid the fake Merriweather Sans Light-Bold typeface;

* If I decide to use another typeface, say Times New Roman, and change the Default Paragraph Style to use it (as it will reflect on "Body Text" and "Block Quotation" paragraph styles), the "Strong Emphasis" is correct as it only adds bold to the character that has it applied, but the custom "Emphasis on light to bold" character style will change the typeface from Times New Roman to Merriweather Sans Bold;

* If the document has other custom character styles, such as styles that apply UPPERCASE, Small Capitals, other colors etc., there will be a need to change every character style to reflect the new default typeface selected on the document, and it gets very easily error-prone besides tedious.
Comment 90 Eyal Rozenberg 2024-05-14 22:44:05 UTC
(In reply to João Paulo from comment #89)
> I think the problem got worse, as now the Merriweather Sans typeface family
> (the latest version available at
> "https://github.com/SorkinType/Merriweather-Sans") shows as three different
> typeface's families.

Same as my last screenshot; perhaps it has indeed gotten worse; or the font has a newer version? 

> ... if we apply the bold style...  LibreOffice Writer applies a fake bold
> style derived from the Merriweather Sans Light instead of getting the
> Merriweather Sans Bold.

Good point! Another sense in which a two-state "bold" vs "not bold" doesn't really make sense.

> A (ugly) workaround is creating several styles to choose

Actually, using styles is generally a good idea, not an ugly workaround - but if one already uses styles, one should avoid emulating all kinds of DF, and rather use styles with semantic meaning. :-)
Comment 91 João Paulo 2024-05-15 06:25:39 UTC
(In reply to Eyal Rozenberg from comment #90)
> 
> Actually, using styles is generally a good idea, not an ugly workaround -
> but if one already uses styles, one should avoid emulating all kinds of DF,
> and rather use styles with semantic meaning. :-)

Oh, I didn't express myself correctly, it's not the use of styles that is ugly (I love using styles), but the workaround I could come with that is ugly because it multiplies the needed styles to keep the document visual style consistent, i.e., (In reply to Eyal Rozenberg from comment #90)
> 
> Same as my last screenshot; perhaps it has indeed gotten worse; or the font
> has a newer version? 

I think it is because of the new version (I noticed this bug got worse when I updated the font file).  Even if the regression is on the font itself (the older version used to show all the variants inside a single typeface family -- maybe a compatibility tag was removed?), there are lots of other fonts that also show up on LibreOffice as different typeface families instead of a single grouped family:

* Arial Nova is shown as Arial Nova, Arial Nova Light, Arial Nova Cond, Arial Nova Cond Light);
* Bahnschrift (a single variable font file) is almost a nightmare:  it is shown as Bahnschrift, Bahnschrift Condensed, Bahnschrift Light, Bahnschrift Light Condensed, Bahnschrift Light SemiCondensed, Bahnschrift SemiBold, Bahnschrift SemiBold Condensed, Bahnschrift SemiBold SemiConden, Bahnschrift SemiCondensed, Bahnschrift SemiLight, Bahnschrift SemiLight Condensed, Bahnschrift SemiLight SemiConde.  The truncated names are a limitation of LibreOffice, as Windows 11's Control Panel and the Settings app (and I think Windows 10 also) shows the names completely;
* Calibri is shown as Calibri and Calibri Light;
* Candara is shown as Candara and Candara Light;
* Cascadia Code is shown as Cascadia Code, Cascadia Code Extra Light, Cascadia Code Light, Cascadia Code SemiBold, Cascadia Code SemiLight;
* Cascadia Mono has the same variants as Cascadia Code;
* Corbel is shown as Corbel and Corbel Light;
* and many other examples.

Those typeface families (all provided by Microsoft, in Windows 10 and 11) are grouped correctly by the Control Panel and the Settings app, i.e., they are shown as a grouped font icon with the typeface family name (Bahnschrift, for example) and when that icon is opened then it shows all the typeface members of the family.  Even the Merriweather Sans typeface family shows up nicely grouped together in Control Panel and the Settings app, so it's safe to assume that LibreOffice doesn't use the better API to handle fonts and typeface names with more than the classic R/B/I/BI variants.

> Actually, using styles is generally a good idea, not an ugly workaround -
> but if one already uses styles, one should avoid emulating all kinds of DF,
> and rather use styles with semantic meaning. :-)

The ugliness doesn't come from using styles, but from having to use extra styles that has "another" typeface set instead of just another style (bold, italic, bold italic, light, regular, etc.) on that typeface family, which makes it easy to make a mistake when changing typefaces on the base style.  Instead of a single character style named Emphasis that just adds the bold style to the typeface, I have to use a secondary "Emphasis Merriweather Light to Bold", a secondary "Emphasis Cascadia Light to Bold", and so on, to avoid using fake emboldened fonts.
Comment 92 João Paulo 2024-05-18 23:03:38 UTC
Is this the same bug as reported or a new bug?

* Use Merriweather Sans in Light and Bold styles in your document;
* Save the document and close all instances of LibreOffice;
* Reopen the document in LibreOffice Writer;
* LibreOffice uses a fake bold style derived from the Light style instead of the real Bold style installed in your system;
* Extra:  If you first open a document which was formatted Merriweather Sans Regular and Bold before opening the (second) document which was formatted with Light and Bold, when you open the second document LibreOffice Writer shows correctly the Light and Bold styles; however, when printing or exporting to PDF it again shows a fake bold style derived from the Light style.
Comment 93 Lance Haverkamp 2024-09-18 06:10:12 UTC
When Microsoft Internet Explorer was the bain of browsers, we coddled Microsoft for a while, then drove IE completely out of the marketplace.

Granted, Office has the market share in their favor, but if we are tired of having to write workarounds for their bad programs, it may be time to fix the problem here (get the type variations working properly in ODT). Then just keep telling the world that the defect is at Microsoft's end. Compatibility with a properly working program is great; compatibility with a lousy old program—not so much.