Bug 151095 - Writer bold rendering of Adobe OTF ex Linotype fonts fails, Linux font fallback issue
Summary: Writer bold rendering of Adobe OTF ex Linotype fonts fails, Linux font fallba...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.1.2 release
Hardware: Other other
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fonts
  Show dependency treegraph
 
Reported: 2022-09-21 02:23 UTC by PeterSergej
Modified: 2023-02-13 23:37 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Libre Writer document with screenshots (172.81 KB, application/vnd.oasis.opendocument.text)
2022-09-21 02:26 UTC, PeterSergej
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PeterSergej 2022-09-21 02:23:53 UTC
Description:
Steps
1.Install Libre Office, Adobe Garamond Pro, Helvetica LT Std, New Century Schoolbok LT Std, Impressum Std on Linux

2. Open Libre Writer, type sample text, repeat for 16 lines

3. Apply Adobe Garamond Pro typeface to first four lines, Helvetica LT Std to second four lines, New Century Schoolbook LT Std to third four lines, and Impression Std to fiianl four lines.

4. For each typeface quad, apply bold to second line, italic to third line, and underline to dourth line.

5. Save document (without font embedding).  Copy to Windows machine.

6. One Windows machine, install, or have already installed, Libre Office and the four fonts mentioned.

7. Observe that bold for the LT (stands for LinoType) Std (stands for standard) does not render in Libre Office for Linux, but does render in Libre Office for Windows.

Attached Libre Writer document includes screenshots of font rendering as per technical specs below.  The document was created in Libre Office on Linux.

Libre Office on Linux specs:
Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-GB (en_AU.UTF-8); UI: en-GB
Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded

Libre Office on Windows specs:
Version: 7.4.1.2 (x64) / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: CL

Steps to Reproduce:
1.Install Libre Office, Adobe Garamond Pro, Helvetica LT Std, New Century Schoolbok LT Std, Impressum Std on Linux

2. Open Libre Writer, type sample text, repeat for 16 lines

3. Apply Adobe Garamond Pro typeface to first four lines, Helvetica LT Std to second four lines, New Century Schoolbook LT Std to third four lines, and Impression Std to fiianl four lines.

4. For each typeface quad, apply bold to second line, italic to third line, and underline to dourth line.

5. Save document (without font embedding).  Copy to Windows machine.

6. One Windows machine, install, or have already installed, Libre Office and the four fonts mentioned.

7. Observe that bold for the LT (stands for LinoType) Std (stands for standard) does not render in Libre Office for Linux, but does render in Libre Office for Windows.


Actual Results:
Checked square boxes instead of text appear for bold font style in LO Writer on Linux.

Expected Results:
Legible characters should have appeared for all bold text in LO Writer for Linux or Windows.


Reproducible: Always


User Profile Reset: No



Additional Info:
Libre Office on Linux specs:
Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-GB (en_AU.UTF-8); UI: en-GB
Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.20.04.1~lo1
Calc: threaded

Libre Office on Windows specs:
Version: 7.4.1.2 (x64) / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-AU (en_AU); UI: en-GB
Calc: CL
Comment 1 PeterSergej 2022-09-21 02:26:07 UTC
Created attachment 182587 [details]
Libre Writer document with screenshots
Comment 2 V Stuart Foote 2022-09-21 13:18:29 UTC
The text runs "render". 

But, whatever font gets selected by the font manager for fallback does not have coverage of the glyph--that is what the placeholder/missing glyphs (the X-boxes) on the "wrong" lines of bold text indicate.
Comment 3 Rafael Lima 2022-09-21 13:21:21 UTC
Maybe a duplicate of bug 103596 ?
Comment 4 V Stuart Foote 2022-09-21 13:45:49 UTC
(In reply to Rafael Lima from comment #3)
> Maybe a duplicate of bug 103596 ?

No, those LT fonts are *not* modern OTF Variable fonts.
Comment 5 PeterSergej 2022-09-21 22:26:34 UTC
(In reply to V Stuart Foote from comment #2)
> The text runs "render". 
> 
> But, whatever font gets selected by the font manager for fallback does not
> have coverage of the glyph--that is what the placeholder/missing glyphs (the
> X-boxes) on the "wrong" lines of bold text indicate.

Thank you for the clarification.  In my Libre Writer settings no font fallback has been configured; does the program itself look for a fallback when encountering a problem?  I assume that the 'rendering' of the font either did not find the bold OTF file, or looked at the wrong glyphs.

I logged this as a bug because both GIMP and Scribus, running on the same Linux system as the 'bug' in Libre Writer, did render the font as bold, and the problem does not exist for Libre Office in Windows 10.  Have I erred?
Comment 6 Buovjaga 2023-02-13 10:59:08 UTC
Can you attach an example file that shows the problem? Your attachment just has screenshots. Normal testers would be testing this without installing any of the mentioned commercial fonts.
Comment 7 PeterSergej 2023-02-13 22:03:25 UTC
(In reply to Buovjaga from comment #6)
> Can you attach an example file that shows the problem? Your attachment just
> has screenshots. Normal testers would be testing this without installing any
> of the mentioned commercial fonts.

Thank you for your interest.  However, I have long since rejected Libre Office as a serious alternative to commercial office suites.  Quite apart from not being able to render simple fonts, the number of other deficiencies when compared to commercial contenders is too great, and a turnaround time of six months in a bug reporting thread indicates no one at your end is serious about developing a reliable and popular product.
Comment 8 ⁨خالد حسني⁩ 2023-02-13 22:11:51 UTC
No way to fix this without access to a test document and the affected fonts.
Comment 9 PeterSergej 2023-02-13 23:37:35 UTC
(In reply to خالد حسني from comment #8)
> No way to fix this without access to a test document and the affected fonts.

After six months of deafening silence, I must conclude that you (and everyone else here) never had any intention of fixing this bug.  Generations of people have been born and died in the time it took you to respond, and then, suddenly, in two days, someone takes interest enough to close the 'ticket' to make it seem like you guys actually do something every now and then?

I guess it's why Libre Office is a cobweb project.

Have a nice day.