Bug 108497 - Instantiate OpenType variable fonts when embedding in PDF
Summary: Instantiate OpenType variable fonts when embedding in PDF
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: ⁨خالد حسني⁩
URL: https://github.com/harfbuzz/harfbuzz/...
Whiteboard: target:7.5.0 inReleaseNotes:7.5
Keywords:
: 130149 137301 140538 140710 141726 145306 146355 146577 147824 149879 152563 (view as bug list)
Depends on:
Blocks: Fonts PDF-Export
  Show dependency treegraph
 
Reported: 2017-06-13 03:14 UTC by Volga
Modified: 2024-06-28 13:04 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
Bahnschrift font (34.73 KB, application/x-zip-compressed)
2017-12-26 18:14 UTC, Volga
Details
My snapshot (70.79 KB, image/png)
2017-12-26 18:15 UTC, Volga
Details
Fig 1. PDF Experting (30.02 KB, application/pdf)
2017-12-26 18:18 UTC, Volga
Details
Fig 2. Printing work (29.37 KB, application/pdf)
2017-12-26 18:20 UTC, Volga
Details
Test file. (9.70 KB, application/vnd.oasis.opendocument.text)
2017-12-27 04:31 UTC, Volga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volga 2017-06-13 03:14:55 UTC
Description:
Once we set support for OpenType Font Variation, we need to implement a converter to convert its instances into static glyphs before variable font used for printing and experting to PDF. According to OpenType Font Variations Overview:[1]

“In certain application workflows, it may be necessary to dynamically generate a static font resource for a particular instance — that is, conventional, non-variation font tables that use interpolated values for a particular instance. This may be needed in order to provide font data to legacy software or data formats that do not understand or support variable fonts, such as legacy printer drivers, or PDF or XPS files with embedded font data. ”

==Ref==
[1] https://www.microsoft.com/typography/otspec/otvaroverview.htm

Steps to Reproduce:
-

Actual Results:  
-

Expected Results:
-


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Comment 1 Buovjaga 2017-06-22 15:43:24 UTC
Yep, sounds necessary -> NEW
Comment 2 Volga 2017-12-26 18:14:37 UTC
Created attachment 138660 [details]
Bahnschrift font

In Windows 10 Fall Creators Update, Microsoft introduced a variable font "Bahnschrift", this font including 5 weights produce via font variation. In LibreOffice Writer, this font weights works as expected on screen, but not works neither PDF expert nor printing. Here is my copy of this font.
Comment 3 Volga 2017-12-26 18:15:58 UTC
Created attachment 138661 [details]
My snapshot

Here is what I have seen.

Version: 6.0.0.1 (x64)
Build ID:d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU 线程:4; 操作系统:Windows 10.0; UI 渲染:默认; 
区域语言:zh-CN (zh_CN); Calc: group
Comment 4 Volga 2017-12-26 18:18:10 UTC
Created attachment 138662 [details]
Fig 1. PDF Experting

This is what I got after clicking "Expert to PDF" button on the toolbar.
Comment 5 Volga 2017-12-26 18:20:06 UTC
Created attachment 138663 [details]
Fig 2. Printing work

This is the same ODT document "printed" via PDFcreator 3.0.
Comment 6 Volga 2017-12-27 04:31:29 UTC
Created attachment 138674 [details]
Test file.
Comment 7 V Stuart Foote 2018-01-30 17:35:17 UTC
Seems more likely the printing and export to PDF would be reworked for HB/FreeType and use of a skia back end rather than restamping as "static glyphs" and sub-setted fonts.

Lets let the devs decide...
Comment 8 Buovjaga 2018-01-30 17:40:59 UTC
(In reply to V Stuart Foote from comment #7)
> Seems more likely the printing and export to PDF would be reworked for
> HB/FreeType and use of a skia back end rather than restamping as "static
> glyphs" and sub-setted fonts.

Do we really want to use Skia? Working with is apparently a very painful experience: https://news.ycombinator.com/item?id=16146132

> Google has essentially made it as painful as possible to use Skia outside of the google ecosystem.

> Skia isn't on any package managers

etc.
Comment 9 V Stuart Foote 2018-01-30 18:54:58 UTC
(In reply to Buovjaga from comment #8)
> (In reply to V Stuart Foote from comment #7)
> > Seems more likely the printing and export to PDF would be reworked for
> > HB/FreeType and use of a skia back end rather than restamping as "static
> > glyphs" and sub-setted fonts.
> 
> Do we really want to use Skia? Working with is apparently a very painful
> experience...

Hard to say. But Miklos was already well versed with Google's pdfium project having adopted it for the PDF insert filter. And restoring a "break" feature or replacing the import filter completely already requires doing something along these lines of implementing a skia PDF backend -- see bug 106581  

I beleive there is some consensus building that a FreeType everywhere approach is the way forward cross platform.

Again for the devs to decide, but printing and export to PDF will likely need to be refactored cross platform anyhow. Support for OTF Variable fonts comes with it.
Comment 10 Miklos Vajna 2018-01-31 11:22:13 UTC
Not necessarily skia, but long-term some kind of vector output from pdfium would be nice. pdfium currently exposes vector output via painting on a HDC (Windows-specific) or on a skia surface (experimental).

So probably best to wait till we see where that leads, we definitely want some kind of output that can be mapped to LO's idea of vector images (VCL metafile, drawinglayer primitives, whatever).
Comment 11 ⁨خالد حسني⁩ 2018-02-01 16:30:09 UTC
We currently do not support variable fonts at all, any apparent support is accidental. For PDF generation we will definitely need to generate static instances of the fonts before embedded them in PDF files. Using Skia or pdfium or not does not change much, the static instances will need to be generated regardless (either by us or by the new printing backend if we ever have a new one).

Pdfium isn’t currently a viable replacement IMO as the subsetter it uses does not handle fonts with CFF table (.otf fonts) so it will be a big regression for us. I don’t even think it does static instantiation of variable fonts.
Comment 12 Miklos Vajna 2018-02-01 16:46:43 UTC
Just to be clear, I have no plans to replace parts of our current PDF export code with pdfium, the long-term idea is to replace poppler/xpdfimport with it; but even for those what can be common language to transfer vector graphics is an open question. :-)
Comment 13 Volga 2018-02-07 10:49:39 UTC Comment hidden (no-value)
Comment 14 Volga 2018-02-08 14:37:28 UTC Comment hidden (off-topic)
Comment 15 Volga 2018-02-08 14:38:29 UTC Comment hidden (off-topic)
Comment 16 Volga 2018-02-08 14:41:30 UTC
I think this should also works for EPUB expert, because many EPUB readers does not support variable fonts, althrough they can load embedded fonts.
Comment 17 Volga 2019-06-21 06:44:22 UTC Comment hidden (no-value)
Comment 18 Volga 2019-06-28 17:04:57 UTC
This is still present in
Version: 6.4.0.0.alpha0+ (x64) 
Build ID: 11a1bdc5fa0312111ddf9c1b7779a114b97e361c 
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-19_00:00:04 
Locale: zh-CN (zh_CN); UI-Language: en-US 
Calc: threaded

As a workaround, we have to use Microsoft Print to PDF on Windows 10.
Comment 19 Volga 2019-07-11 17:51:15 UTC Comment hidden (no-value)
Comment 20 Volga 2019-07-11 17:54:40 UTC
For Windows 10, if we are really need them to present in PDF files, we can modify the preferences of some virtual printers like CutePDF and PDFCreator as following steps: 

1. Open Settings from Start Menu, then click Devices -> Printers and Scanners, then click one of these printers you want to use, and then click Manage, finally. click Printing Preferences.
2. In the Printing Preferences dialog, click Advance button, then modify these Advanced Options as below:
   TrueType Font: Download as SoftFont
   TrueType Font Download Option: Outline

Then the virtual printer would accept font variation instances, convert them, and embedded into PDF file, this can be done as another workarounds.
Comment 21 Volga 2019-11-01 19:15:32 UTC
If HarfBuzz implement this feature it's possible to fix this bug.
https://github.com/harfbuzz/harfbuzz/issues/1558
Comment 22 ⁨خالد حسني⁩ 2019-11-02 14:18:42 UTC
(In reply to Volga from comment #21)
> If HarfBuzz implement this feature it's possible to fix this bug.
> https://github.com/harfbuzz/harfbuzz/issues/1558

No, we don’t use HarfBuzz subsetter and it would require a considerable refactoring to be able to do so, and that PR does not support instantiating a variable font which is what we would need for PDF.
Comment 23 Volga 2019-11-03 12:45:53 UTC
(In reply to Khaled Hosny from comment #22)
> No, we don’t use HarfBuzz subsetter and it would require a considerable
> refactoring to be able to do so, and that PR does not support instantiating
> a variable font which is what we would need for PDF.

Oh I made misunderstand, so it's clear that HarfBuzz doesn't do this conversion.
Comment 24 Volga 2020-05-07 09:22:53 UTC Comment hidden (no-value)
Comment 25 Volga 2020-05-11 14:39:09 UTC
I have noticed that Skia is now integrated as new graphics backend, so which API would be help to work with this?
Comment 26 Miklos Vajna 2020-05-11 14:52:24 UTC
I believe skia does not change much here: you are focusing on printing, PDF export or EPUB export, none of these are affected by the GL -> skia/vulkan change.

Skia still renders the same text layout harfbuzz produces and still works with the Windows-specific APIs (directwrite, etc.) when it comes to the actual fonts. See these changes:

https://gerrit.libreoffice.org/c/core/+/90582
https://gerrit.libreoffice.org/c/core/+/91968
Comment 27 phv 2022-01-05 19:34:07 UTC
*** Bug 146577 has been marked as a duplicate of this bug. ***
Comment 28 Pablo 2022-06-13 05:35:11 UTC
Can fonttools help?
https://github.com/fonttools/fonttools

A python library to create a static instance from a variable font:
https://fonttools.readthedocs.io/en/latest/varLib/instancer.html
Comment 29 Volga 2022-07-15 15:32:44 UTC
HarfBuzz will get the implementation, so I think we can waiting for new release for fix.
Comment 30 Volga 2022-07-17 08:07:56 UTC
LibreOffice should also provide an option to turn this on or off in the Expert Configuration, as some newer printers may get support for variable fonts.
Comment 31 Volga 2022-08-09 01:10:14 UTC
(In reply to Volga from comment #29)
> HarfBuzz will get the implementation, so I think we can waiting for new
> release for fix.
It's landed as of 5.1.0 release.
Comment 32 Buovjaga 2022-08-09 06:23:52 UTC
(In reply to Volga from comment #31)
> (In reply to Volga from comment #29)
> > HarfBuzz will get the implementation, so I think we can waiting for new
> > release for fix.
> It's landed as of 5.1.0 release.

Khaled updated our HB to 5.1.0 recently: https://git.libreoffice.org/core/commit/4e72f70c796fee9b0af6a526159143b5e70dcd11
Comment 33 Volga 2022-08-19 20:16:34 UTC
It doesn't help.

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 5ac75131556b687a01517ce4520a05bb49c1d840
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: zh-CN
Calc: threaded
Comment 34 Volga 2022-08-20 06:59:46 UTC
I think you should make use of new related APIs to implement.
Comment 35 Volga 2022-09-03 06:35:52 UTC
I saw HarfBuzz repository have a PR introduced new API to work for this.
https://github.com/harfbuzz/harfbuzz/issues/2112
Comment 36 ⁨خالد حسني⁩ 2022-09-20 10:07:37 UTC
*** Bug 137301 has been marked as a duplicate of this bug. ***
Comment 37 ⁨خالد حسني⁩ 2022-09-20 10:08:51 UTC
*** Bug 130149 has been marked as a duplicate of this bug. ***
Comment 38 ⁨خالد حسني⁩ 2022-09-20 13:29:45 UTC
I pretty much doubt we have to do anything for EPUB, but either case there is not much in common between PDF and EPUB so EPUB issue should be tracked separately.
Comment 39 Commit Notification 2022-11-23 20:36:10 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/164d717530aff8d2581d0a2ff249f83aabb27502

tdf#108497: instantiate variable fonts in PDF

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 40 ⁨خالد حسني⁩ 2022-11-24 06:10:31 UTC
*** Bug 140538 has been marked as a duplicate of this bug. ***
Comment 41 ⁨خالد حسني⁩ 2022-11-24 06:12:33 UTC
*** Bug 149879 has been marked as a duplicate of this bug. ***
Comment 42 ⁨خالد حسني⁩ 2022-11-24 06:12:56 UTC
*** Bug 146355 has been marked as a duplicate of this bug. ***
Comment 43 ⁨خالد حسني⁩ 2022-11-24 06:13:19 UTC
*** Bug 145306 has been marked as a duplicate of this bug. ***
Comment 44 ⁨خالد حسني⁩ 2022-11-24 06:13:47 UTC
*** Bug 147824 has been marked as a duplicate of this bug. ***
Comment 45 ⁨خالد حسني⁩ 2022-11-24 06:14:11 UTC
*** Bug 140710 has been marked as a duplicate of this bug. ***
Comment 46 ⁨خالد حسني⁩ 2022-11-24 06:14:36 UTC
*** Bug 141726 has been marked as a duplicate of this bug. ***
Comment 47 Stéphane Guillou (stragu) 2022-12-08 17:57:02 UTC
I could not test on Ubuntu 20.04, as only the base Bahnschrift font is available in LibreOffice. It does not seem to catch the variants, even though they are listed in Font Manager and with:

fc-list | grep Bahnschrift
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiBold
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Regular
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiLight
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Light
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Bold
/home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift

Is that what is reported in Bug 152396?

For Windows, fix verified in:

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: c50cf1883af26daebdfc9d796ced3c20c222f43b
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

Thanks Khaled!
Comment 48 ⁨خالد حسني⁩ 2022-12-08 19:08:52 UTC
(In reply to Stéphane Guillou (stragu) from comment #47)
> I could not test on Ubuntu 20.04, as only the base Bahnschrift font is
> available in LibreOffice. It does not seem to catch the variants, even
> though they are listed in Font Manager and with:
> 
> fc-list | grep Bahnschrift
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiBold
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Regular
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiLight
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Light
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Bold
> /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift
> 
> Is that what is reported in Bug 152396?

No, that is a different issue. Probably the version of FontConfig or FreeType is too old for what we need to get this working. I tested on Ubuntu 22.04 and it was working there.
Comment 49 ⁨خالد حسني⁩ 2022-12-10 14:09:38 UTC
(In reply to خالد حسني from comment #48)
> (In reply to Stéphane Guillou (stragu) from comment #47)
> > I could not test on Ubuntu 20.04, as only the base Bahnschrift font is
> > available in LibreOffice. It does not seem to catch the variants, even
> > though they are listed in Font Manager and with:
> > 
> > fc-list | grep Bahnschrift
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiBold
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Regular
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=SemiLight
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Light
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift:style=Bold
> > /home/stragu/.local/share/fonts/bahnschrift.ttf: Bahnschrift
> > 
> > Is that what is reported in Bug 152396?
> 
> No, that is a different issue. Probably the version of FontConfig or
> FreeType is too old for what we need to get this working. I tested on Ubuntu
> 22.04 and it was working there.

What does the following command show for you?

fc-query --format="%{family}, %{style}: %{index}\n" /home/stragu/.local/share/fonts/bahnschrift.ttf
Comment 50 Stéphane Guillou (stragu) 2022-12-10 22:17:07 UTC
(In reply to خالد حسني from comment #49)
> What does the following command show for you?
> 
> fc-query --format="%{family}, %{style}: %{index}\n"
> /home/stragu/.local/share/fonts/bahnschrift.ttf

I get the following:

Bahnschrift, Regular: 0
Bahnschrift, Light: 65536
Bahnschrift, SemiLight: 131072
Bahnschrift, SemiBold: 262144
Bahnschrift, Bold: 327680
Bahnschrift, : 0

About fontconfig and freetype:

apt-cache policy fontconfig
fontconfig:
  Installed: 2.13.1-2ubuntu3

apt-cache policy libfreetype6
libfreetype6:
  Installed: 2.10.1-2ubuntu0.2
Comment 51 ⁨خالد حسني⁩ 2022-12-11 19:11:34 UTC
(In reply to Stéphane Guillou (stragu) from comment #50)
> (In reply to خالد حسني from comment #49)
> > What does the following command show for you?
> > 
> > fc-query --format="%{family}, %{style}: %{index}\n"
> > /home/stragu/.local/share/fonts/bahnschrift.ttf
> 
> I get the following:
> 
> Bahnschrift, Regular: 0
> Bahnschrift, Light: 65536
> Bahnschrift, SemiLight: 131072
> Bahnschrift, SemiBold: 262144
> Bahnschrift, Bold: 327680
> Bahnschrift, : 0
> 
> About fontconfig and freetype:
> 
> apt-cache policy fontconfig
> fontconfig:
>   Installed: 2.13.1-2ubuntu3
> 
> apt-cache policy libfreetype6
> libfreetype6:
>   Installed: 2.10.1-2ubuntu0.2

No obvious issue. If you want to debug this further, you might want to set SAL_LONG env var to "+INFO.vcl.fonts.detail" and examine the log for Bahnschrift entries.
Comment 52 ⁨خالد حسني⁩ 2022-12-17 14:38:08 UTC
*** Bug 152563 has been marked as a duplicate of this bug. ***