Bug 95207 - LibreOffice cannot unify differently-named fonts into a single family
Summary: LibreOffice cannot unify differently-named fonts into a single family
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-20 20:51 UTC by Linus Drumbler
Modified: 2023-08-03 16:41 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
All styles of Sinkin Sans displayed in LibreOffice (273.42 KB, image/png)
2015-10-20 20:51 UTC, Linus Drumbler
Details
Inkscape correctly grouping Sinkin Sans into a single family (198.53 KB, image/png)
2015-10-20 20:52 UTC, Linus Drumbler
Details
Bug still present in 6.0.2.1 (115.77 KB, image/png)
2018-03-29 16:20 UTC, Linus Drumbler
Details
libreoffice 7.3.1.3 showing the issue with fira sans (64.11 KB, image/png)
2022-03-11 04:59 UTC, Adam Fontenot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linus Drumbler 2015-10-20 20:51:39 UTC
Created attachment 119803 [details]
All styles of Sinkin Sans displayed in LibreOffice

Steps to reproduce:

1. Install the font "Sinkin Sans" by K-Type. It is licensed under the Apache License and can be downloaded free of charge here: http://www.fontsquirrel.com/fonts/sinkin-sans
2. Open any component of LibreOffice that allows you to select a font.
3. Scroll down to the s's to find Sinkin Sans.

Expected behaviour:

In the font selection menu, LibreOffice displays the Sinkin Sans font as a single selectable font family.

Actual behaviour:

LibreOffice displays each individual style of Sinkin Sans as its own font family.

Platform: Ubuntu 14.04 with xfwm4 4.11.1.

This is because Sinkin Sans names each style with a number, rather than setting the "family name" PostScript property to a consistent string as is typical, and LibreOffice interprets them as different families. I have seen many other fonts that do this. Inkscape, however, can group Sinkin Sans into one family.
Comment 1 Linus Drumbler 2015-10-20 20:52:52 UTC
Created attachment 119804 [details]
Inkscape correctly grouping Sinkin Sans into a single family
Comment 2 Buovjaga 2015-10-21 15:28:09 UTC
Confirmed.

Win 7 Pro 64-bit, Version: 5.0.2.2 (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)
Comment 3 Linus Drumbler 2015-10-21 18:18:38 UTC
Some other fonts with similar behaviour include Cooper Hewitt (http://www.fontsquirrel.com/fonts/cooper-hewitt) and Biryani (https://www.google.com/fonts/specimen/Biryani).
Comment 4 QA Administrators 2016-11-08 11:04:53 UTC Comment hidden (obsolete)
Comment 5 Linus Drumbler 2018-03-29 16:20:03 UTC
Created attachment 140953 [details]
Bug still present in 6.0.2.1

Bug is still present in 6.0.2.1.
Comment 6 QA Administrators 2019-03-30 06:13:13 UTC Comment hidden (obsolete)
Comment 7 Timur 2021-02-19 15:52:52 UTC
*** Bug 140519 has been marked as a duplicate of this bug. ***
Comment 8 Adam Fontenot 2022-03-11 04:59:54 UTC
Created attachment 178797 [details]
libreoffice 7.3.1.3 showing the issue with fira sans

This is a *major* pain for users with large font families, see e.g. the example given by the user of the marked-duplicate bug 140519.

I'm adding to this to point out that this bug is not, as far as I can tell, limited to unusual or broken font families. It applies to every font family I've ever tried that has more than four styles or weights.

In fact, you can test it yourself with an open source font, Fira Sans: https://github.com/bBoxType/FiraSans

I've attached a screenshot showing what my fonts menu in the LibreOffice UI looks like with this font installed. Other applications that I've tried, including Inkscape, KDE's Font Management tool, and fontmanager.github.io, all show 3 font families for Fira Sans: Fira Sans, FS Compressed, and FS Condensed. Underlying libraries also have support for this: pango-list shows the same three families.

The especially annoying thing is that LibreOffice interpolates an italic, bold, and bold-italic font for most of these "families", so the Fira Sans Light "family" has a simulated bold option - instead of switching to Fira Sans Bold!

This all *feels* like something that might at one point have been a conscious design decision, to work around the fact that styles aren't exposed very well in the LibreOffice UI (as far as I know, nowhere but the character format window), so perhaps this was originally thought to be a workaround to allow users to more easily choose variant font styles?

I think the correct UI solution to this would be to make a style / weight drop down that's separate from the font family selector. Then the font name selector can be used exclusively to present different font families.
Comment 9 Coburn Ingram 2022-03-13 02:37:39 UTC
An ideal fix would allow configuring the font list from the GUI.

Ubuntu-desktop installs international fonts by default, and the dropdown is cluttered by tons and tons of Indic and Asian fonts, even when the system language is set to English. It would be more or less trivial to put a list with checkboxes in the config menu.
Comment 10 Adam Fontenot 2022-03-13 10:42:28 UTC
(In reply to Coburn Ingram from comment #9)
> An ideal fix would allow configuring the font list from the GUI.
> 
> Ubuntu-desktop installs international fonts by default, and the dropdown is
> cluttered by tons and tons of Indic and Asian fonts, even when the system
> language is set to English. It would be more or less trivial to put a list
> with checkboxes in the config menu.

I think that's not a bad idea, though there's already a separate bug report for it: https://bugs.documentfoundation.org/show_bug.cgi?id=91130

In cases like the one this bug is about, the issue is that we *do* want to be able to access all the stylistic variants, but LibreOffice is treating them as if they were separate families.
Comment 11 ⁨خالد حسني⁩ 2023-08-03 16:26:11 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.