Bug 108497 - Converting OpenType Font Variation instances before printing and exporting to PDF or EPUB
Summary: Converting OpenType Font Variation instances before printing and exporting to...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 103596
Blocks: Fonts
  Show dependency treegraph
 
Reported: 2017-06-13 03:14 UTC by Volga
Modified: 2018-04-06 18:19 UTC (History)
7 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 Khaled Hosny 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
(In reply to Miklos Vajna from comment #12)
> 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. :-)
I agree with you, I think you just create new codes or a library into a proper level to do it.
Comment 14 Volga 2018-02-08 14:37:28 UTC Comment hidden (off-topic)
Comment 15 Volga 2018-02-08 14:38:29 UTC
(In reply to Khaled Hosny from comment #11)
> 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.
I found Chrome made it works, here are some steps to reproduce:
1. Opening https://mdn.mozillademos.org/zh-CN/docs/Web/CSS/font-weight$samples/font-weight?revision=1344671
(this page availble at https://developer.mozilla.org/zh-CN/docs/Web/CSS/font-weight)
2. Replace font face as Bahnschrift at the bottom
3. Click three dots on the toolbar, then click Print
4. Select PDFCreator to print.

Then I found all font weights printed as expected. So how does Chrome made the implementation?
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.