Bug 105298 - Incorrect handling of font families (weight, width, slope) cross-platform
Summary: Incorrect handling of font families (weight, width, slope) cross-platform
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 77830 (view as bug list)
Depends on:
Blocks: Font-List
  Show dependency treegraph
 
Reported: 2017-01-12 20:58 UTC by eric
Modified: 2024-07-05 23:14 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Linux Font Dialog (75.78 KB, image/png)
2017-01-12 20:59 UTC, eric
Details
Mac Font Dialog (86.09 KB, image/png)
2017-01-12 20:59 UTC, eric
Details
Fonts to install to demonstrate issue (deleted)
2017-01-12 21:02 UTC, eric
Details
Windows Font Dialog (21.13 KB, image/png)
2017-01-12 21:35 UTC, eric
Details
OSX Fontbook screenshot with Avenir Lt (21.48 KB, image/png)
2017-01-13 08:44 UTC, Alex Thurgood
Details
Windows Font Dialog (32.92 KB, image/png)
2017-01-13 15:43 UTC, eric
Details
Avenir LT Std font file error summary (185.66 KB, image/png)
2018-07-09 17:42 UTC, LibreTraining
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eric 2017-01-12 20:58:14 UTC
Description:
Installed Avenir OTF fonts. On Mac and Linux (screenshots attached) the font family is "Avenir LT Std 35 Light" with "Avenir LT Std 45 Book" and "Avenir LT Std 55 Roman" as separate font families.

On Mac, "Avenir LT Std" is the family, and "35 Light", "45 Book", and "55 Roman" are typefaces. See attached screenshots.

The problem this causes is that these fonts are not found in documents created on Windows or Linux when viewed on a Mac, and documents created with these fonts are not found when viewed on Windows or Linux.

Steps to Reproduce:
1. Install the attached OTF fonts on Windows, Mac, and Linux.
2. Create a document with one of those fonts on Windows, Mac, and Linux.


Actual Results:  
Documents created on Windows or Mac will not show the text in the selected font when viewed on Mac, and documents created on Mac will not show the text in the selected font when viewed on Windows or Linux.

Expected Results:
The document should render with the proper fonts on all platforms.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Comment 1 eric 2017-01-12 20:59:04 UTC
Created attachment 130377 [details]
Linux Font Dialog

This is how the font dialog looks on Linux.
Comment 2 eric 2017-01-12 20:59:41 UTC
Created attachment 130378 [details]
Mac Font Dialog

This is how the font dialog appears on a Mac.
Comment 3 eric 2017-01-12 21:02:22 UTC
Created attachment 130379 [details]
Fonts to install to demonstrate issue

These are the Avenir LT Std OTF fonts.
Comment 4 eric 2017-01-12 21:35:01 UTC
Created attachment 130380 [details]
Windows Font Dialog

Font dialog on Windows Libreoffice.
Comment 5 Alex Thurgood 2017-01-13 08:28:31 UTC
See also bug 105234, which is similar
Comment 6 Alex Thurgood 2017-01-13 08:43:46 UTC
On Mac OSX 10.12.2, the fonts 35 Light, 45 Book, 55 Roman are considered by OSX Fontbook as typefaces within the Avenir Light family.

How is this LO's fault ?
Comment 7 Alex Thurgood 2017-01-13 08:44:59 UTC
Created attachment 130382 [details]
OSX Fontbook screenshot with Avenir Lt
Comment 8 Alex Thurgood 2017-01-13 08:46:54 UTC
When those fonts are installed via the FontBook.app on OSX, a "minor" error is indicated to the user, so there is clearly something that the OSX font manager doesn't like about them.
Comment 9 Alex Thurgood 2017-01-13 08:47:53 UTC
I would be inclined to set this is NOTABUG or NOTOURBUG if the problem lies with the font itself, rather than anything to do with LO.
Comment 10 Alex Thurgood 2017-01-13 08:54:23 UTC
@eric : these are copyrighted fonts, are you authorised to post them to a public server such as this one for download ?
Comment 11 Alex Thurgood 2017-01-13 08:57:07 UTC
FWIW, when Writer is opened, I only see Avenir LT Std in the list of available fonts.


Version: 5.4.0.0.alpha0+
Build ID: b66b1e896c177df3c5de5d33037416152fc8a381
CPU Threads: 2; OS Version: Mac OS X 10.12.2; UI Render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 12 ⁨خالد حسني⁩ 2017-01-13 15:13:37 UTC
We indeed rely on the OS to identify font names, but this is brittle (as shown here).

We can do better and parse the font names ourselves for better cross-platform compatibility (we have rudimentary code for this used partially on Linux). We will likely need to do this anyway to properly support font families with more styles the R/B/I/BI (e.g. bug 35538).

So though this is not our bug per se, it is a valid enhancement at least.
Comment 13 eric 2017-01-13 15:41:11 UTC
(In reply to Alex Thurgood from comment #10)
> @eric : these are copyrighted fonts, are you authorised to post them to a
> public server such as this one for download ?

@Alex I got the fonts from http://www.designsrock.com/avenir-font-family/ and there was no indication on copyright. Could they be incorrectly offering this font?
Comment 14 eric 2017-01-13 15:43:11 UTC
Created attachment 130395 [details]
Windows Font Dialog

Previous screenshot was from a different program.
Comment 15 Alex Thurgood 2017-01-13 16:52:18 UTC
I see no mention of the licensing or copyright authorisations that the site might have with regard to distribution and re-distribution of the fonts. Additionally, the More Info link points to yet another site (elegantfonts.net) which just appears to be a blog.

In the absence of a clear statement re licensing of these fonts, and considering that the copyright notice within the font files indicates that they are proprietary, it is probably better to delete them from our BZ. I don't think that I can do this though as it requires admin privileges.
Comment 16 Buovjaga 2017-01-13 16:56:29 UTC
The content of attachment 130379 [details] has been deleted for the following reason:

Proprietary fonts
Comment 17 Thomas Linard 2018-01-05 10:06:20 UTC

*** This bug has been marked as a duplicate of bug 35538 ***
Comment 18 LibreTraining 2018-07-09 17:42:53 UTC Comment hidden (off-topic)
Comment 19 Thomas Linard 2018-07-09 18:05:57 UTC
(In reply to LibreTraining from comment #18)
> Created attachment 143401 [details]
> Avenir LT Std font file error summary
> 
> If these are the Avenir LT Std font files from the old Adobe Font Folio 11,
> there are errors in the font files.
> 
> I fixed mine and they now work properly in LibreOffice.
> 
> See attached screenshot of spreadsheet I used to figure-out what was wrong.

Hi,

Please post your results in bug 72944. Thanks!
Comment 20 LibreTraining 2018-07-11 02:13:08 UTC Comment hidden (off-topic)
Comment 21 Thomas Linard 2018-07-11 07:14:06 UTC
(In reply to LibreTraining from comment #20)
> (In reply to Thomas Linard from comment #19)
> > (In reply to LibreTraining from comment #18)
> > > Created attachment 143401 [details]
> > > Avenir LT Std font file error summary
> > > 
> > > If these are the Avenir LT Std font files from the old Adobe Font Folio 11,
> > > there are errors in the font files.
> > > 
> > > I fixed mine and they now work properly in LibreOffice.
> > > 
> > > See attached screenshot of spreadsheet I used to figure-out what was wrong.
> > 
> > Hi,
> > 
> > Please post your results in bug 72944. Thanks!
> 
> Hi Thomas
> 
> What would you like to see posted there?
> It looks like most everything posted there gets marked as a duplicate.
> 
> I have been testing various font families the last few days.
> Some have bugs in the font files (like above).
> But many families (almost all tested) have issues with the Thin and
> ExtraLight fonts not displaying or printing correctly.
> But they do Export to PDF correctly.
> 
> I have been documenting it all, but do not want to waste my time posting
> multiple font lists, images, PDFs, etc. just to have things marked as
> duplicate and ignored.
> 
> Cheers.

Hi,

This is a  a cross-platform-specific bug report, like the title says so.

And don't worry, a comment that a bug is a duplicate doesn't mean that your comment will be rejected *if it is posted in the right place*.

Btw, please read some background information about nameIDs in font tables, like :
https://glyphsapp.com/tutorials/naming

The "bugs" you found around nameID 2 are common tricks, thousands of fonts use them. If LibreOffice doesn't handle correctly such fonts, LibreOffice has a bug (not the fonts!).
Comment 22 LibreTraining 2018-07-11 19:52:40 UTC Comment hidden (off-topic)
Comment 23 Thomas Linard 2018-07-11 20:49:50 UTC
(In reply to LibreTraining from comment #22)
> I think it would help to have you testing on the Mac 
> the same fonts I am testing on Windows.

In this case, please use open source fonts. In doing so, you enable everybody to test the same fonts.
Comment 24 LibreTraining 2018-07-15 19:11:26 UTC Comment hidden (off-topic)
Comment 25 V Stuart Foote 2019-07-04 04:23:57 UTC
*** Bug 77830 has been marked as a duplicate of this bug. ***
Comment 26 ⁨خالد حسني⁩ 2023-08-03 19:24:19 UTC
Windows and Linux are consistent here, macOS is the odd one since system APIs do not give us enough information to implement it the way it is done on the other two platforms.
Comment 27 ⁨خالد حسني⁩ 2023-08-21 20:27:37 UTC
The tricky part here is that we want to use name IDs 1 and 2 from the font’s name table (https://learn.microsoft.com/en-us/typography/opentype/spec/name#nid1), but Core Text does not have an API to get these.

In https://gerrit.libreoffice.org/c/core/+/155455 I tried to use HarfBuzz to get the names and it works in some sense, but have to blocking issues:

1. The names we get now don’t match the names we get from Core Text, which can happen when we ask it for a font (e.g. fallback font, UI font, etc.), this does not only affect families with more than R/B/I/BI styles, but it affects fonts with localized names too (Core Text seems to use the system locale for getting the localized name, my new code more appropriately uses the app language, but even if I switched to system locale, there is no guarantee we get exactly the same name). I think the way to fix this is to store the additional names in the font attributes, as a list of vector of (family, style) pairs and use these to match the fonts. This should also fix the issue of documents using localized fonts names not working on systems using different localization (we should also always save the English name in ODF, but I didn’t check what we do now).

2. The other blocker is variable fonts. They have named instances but they don’t have equivalent of name IDs 1 and 2 for them, the solution is to build these names on the fly, but HarfBuzz does not have an API for that right now, so we would need to fix that first (https://github.com/harfbuzz/harfbuzz/issues/3923).