Bug 140710 - Google-Font Sora Bold not supported for PDF export or Print
Summary: Google-Font Sora Bold not supported for PDF export or Print
Status: RESOLVED DUPLICATE of bug 103596
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.4.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2021-02-28 10:54 UTC by Peer Heinlein
Modified: 2021-07-28 14:31 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Prepared document used for tests (8.50 KB, application/vnd.oasis.opendocument.text)
2021-02-28 10:56 UTC, Peer Heinlein
Details
Created PDF (looks similar to printed output on paper)-- missing bold font style (29.12 KB, application/pdf)
2021-02-28 10:57 UTC, Peer Heinlein
Details
Used TTF: Sora (107.64 KB, application/octet-stream)
2021-02-28 10:57 UTC, Peer Heinlein
Details
the document attached by the reporter, but uncompressed with qpdf --stream-data=uncompress (32.65 KB, application/pdf)
2021-02-28 22:30 UTC, himajin100000
Details
installed all fonts in static folder (17.49 KB, image/png)
2021-03-01 07:18 UTC, himajin100000
Details
installed via Sora-VariableFont_wght.ttf (17.87 KB, image/png)
2021-03-01 07:19 UTC, himajin100000
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peer Heinlein 2021-02-28 10:54:45 UTC
Description:
We're evaluating using the Google Sora Font for our company. We can use it in LibreOffice, but bold words aren't bold when we print or export a PDF.

Any idea how to solve that problem?

https://fonts.google.com/specimen/Sora?preview.text_type=custom

Steps to Reproduce:
1. Download and Install Sora Google Font
2. Create a document, using the bold fond
3. Export PDF or Print

Actual Results:
italic works, bold doesn't

Expected Results:
Bold parts should be bold :-)


Reproducible: Always


User Profile Reset: No



Additional Info:
OpenSUSE 15.2:

Version: 6.4.5.2
Build-ID: 40(Build:2)
CPU-Threads: 4; BS: Linux 5.3; UI-Render: Standard; VCL: gtk3; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 1 Peer Heinlein 2021-02-28 10:56:17 UTC
Created attachment 170124 [details]
Prepared document used for tests
Comment 2 Peer Heinlein 2021-02-28 10:57:02 UTC
Created attachment 170125 [details]
Created PDF (looks similar to printed output on paper)-- missing bold font style
Comment 3 Peer Heinlein 2021-02-28 10:57:45 UTC
Created attachment 170126 [details]
Used TTF: Sora
Comment 4 Julien Nabet 2021-02-28 11:05:53 UTC
On pc Debian x86-64 with master sources updated today + gtk3 rendering, I could reproduce this.
I created a brand new doc and typed:
normal
bold
italic
Then I put "bold" in bold and "italic" in italic
Finally, I exported in pdf.
"bold" isn't in bold.
Comment 5 Julien Nabet 2021-02-28 11:10:08 UTC
Miklos: thought you might be interested in this one since you work on pdfium integration.
Comment 6 himajin100000 2021-02-28 22:30:30 UTC
Created attachment 170135 [details]
the document attached by the reporter, but uncompressed with qpdf --stream-data=uncompress

using this envvar for LibreOffice would be helpful too.
https://opengrok.libreoffice.org/xref/core/vcl/README.vars?r=16e93759#20

if you open this uncompressed pdf WITH A TEXT EDITOR, you will find these four sections:

14 0 obj
<< /F1 24 0 R /F2 25 0 R >>

56.8 758.389 Td /F2 12 Tf[<01>-9<02>-6<03>-14<04>-14<05>-16<06>-30<07>20<08>-10<02>-6<06>-30<09>]TJ

24 0 obj
<< /BaseFont /BAAAAA+Sora-Regular /FirstChar 0 /FontDescriptor 35 0 R /LastChar 13 /Subtype /TrueType /ToUnicode 36 0 R /Type /Font /Widths [ 859 849 676 410 968 575 286 308 426 606 628 640 689 612 ] >>
endobj
25 0 obj
<< /BaseFont /CAAAAA+Sora-Regular /FirstChar 0 /FontDescriptor 37 0 R /LastChar 12 /Subtype /TrueType /ToUnicode 38 0 R /Type /Font /Widths [ 859 640 676 410 968 575 286 228 689 689 308 426 606 ] >>

38 0 obj
(snip)
<01> <006E>
<02> <006F>
<03> <0072>
<04> <006D>
<05> <0061>
<06> <006C>
<07> <0020>
<08> <0062>
<09> <0064>
<0A> <0069>
<0B> <0074>
<0C> <0063>

and "Regular" part suggests "Bold" is not used.
Comment 7 himajin100000 2021-03-01 06:33:45 UTC
Actually, not reproducible if I export a pdf, using the attached odt file

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: c5b911b23f45ba86100c2eadc747b27c8744a96d
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: ja-JP (ja_JP); UI: en-US
Calc: CL
--

I wonder how the pdf attached by the reporter was created.
If I search opengrok for the term "BaseFont", none of the codes gave
/FontDescriptor after /BaseFont

https://opengrok.libreoffice.org/search?project=core&full=%22BaseFont%22&defs=&refs=&path=&hist=&type=&xrd=&nn=1&si=full&si=full
Comment 8 himajin100000 2021-03-01 06:46:35 UTC
>If I search opengrok for the term "BaseFont", none of the codes gave
/FontDescriptor after /BaseFont

sorry, just a brainfurt. I meant no /FontDescriptor comes between /FirstChar and /LastChar
Comment 9 himajin100000 2021-03-01 07:08:49 UTC
Finally I understand why. I would say it's NOTOURBUG.

1. please download the font newly from the google site.
2. extract the zip file
3. you can find Sora-VariableFont_wght.ttf AND a folder named static
4. the folder contains 8 variants of the Sora family. Install them all.
5. open the odt document and export to pdf
6. uninstall the 8 fonts.
7. Install Sora-VariableFont_wght.ttf
8. open the odt document and export to pdf

I will attach some screenshots.
Comment 10 himajin100000 2021-03-01 07:18:49 UTC
Created attachment 170138 [details]
installed all fonts in static folder

there is 8 variants.


(misoperated and set RESOLVED FIXED. reverting to NEW)
Comment 11 himajin100000 2021-03-01 07:19:45 UTC
Created attachment 170139 [details]
installed via Sora-VariableFont_wght.ttf
Comment 12 himajin100000 2021-03-01 07:20:33 UTC Comment hidden (obsolete)
Comment 13 himajin100000 2021-03-01 07:21:41 UTC
comment 11 shows only 7 variants.
Comment 14 Julien Nabet 2021-03-01 19:21:19 UTC
So if the 8 fonts files are present, the bug can't be reproduced?

I also downloaded the zip file and took a look at the README and noticed this part just at the beginning:
"
This download contains Sora as both a variable font and static fonts.

Sora is a variable font with this axis:
  wght

This means all the styles are contained in a single file:
  Sora-VariableFont_wght.ttf

If your app fully supports variable fonts, you can now pick intermediate styles
that aren’t available as static fonts. Not all apps support variable fonts, and
in those cases you can use the static font files for Sora
"

So perhaps it's just the fact that pdf export implementation doesn't deal well with variable fonts.

Now I don't know what's planned in the future, but perhaps all the export pdf part will be dealt with pdfium.

Anyway, it seems for the moment the pb could be workarounded by using the 8 static fonts.
Comment 15 Peer Heinlein 2021-03-02 10:09:52 UTC
Thank you very much for your great and very fast help. I must admit, that I haven't tried the static font files and I used only the  combined file, because on screen everything looked perfect.

I have forwarded this bugticket to the font team of Google. Let's look what they will do here. Maybe there's also something they could/should do or know here.

For me: I'm fine using the static font files and everything's working well.
Comment 16 Julien Nabet 2021-03-02 11:45:15 UTC
(In reply to Peer Heinlein from comment #15)
> ...
> I have forwarded this bugticket to the font team of Google. Let's look what
> they will do here. Maybe there's also something they could/should do or know
> here.
>...

IMHO, it's not a Google pb, the pb seems to be LO doesn't know how to manage variable font when exporting PDF.
Comment 17 Julien Nabet 2021-03-16 07:42:56 UTC
*** Bug 140538 has been marked as a duplicate of this bug. ***
Comment 18 liqsquid 2021-06-09 04:25:14 UTC
Hi!

I had this same problem when I tried to use the variable version of the Inter font [1]. It displayed ok on writer, but as I saved a pdf version of the document, the text lost its bold formatting.

This problem seems to be related to 'variable fonts' or OpenType CFF2 fonts as in bug 137301 [2]. I saw a related discussion in the harfbuzz git [3] and it might have some helpful info. The Inter website has a test page for browsers [4] and some useful information [1] about subsetting the variable font using two other tools [5] e [6].

Maybe this is something it could be done: detect the variable font being used, subset it, include the corresponding subset in the pdf file.


[1] Inter font family - https://rsms.me/inter/

[2] - https://bugs.documentfoundation.org/show_bug.cgi?id=137301

[3] Shaping and instantiating variable fonts - https://github.com/harfbuzz/harfbuzz/issues/2112

[4] Inter variable font test - https://rsms.me/inter/var-test.html

[5] subset - fontTools Documentation - https://fonttools.readthedocs.io/en/latest/subset/

[6]  filamentgroup/glyphhanger - https://github.com/filamentgroup/glyphhanger
Comment 19 V Stuart Foote 2021-07-28 13:07:03 UTC
In reply to Julien Nabet from comment #16)
> IMHO, it's not a Google pb, the pb seems to be LO doesn't know how to manage
> variable font when exporting PDF.

There is no LibreOffice support for OTF variable fonts -- see also bug 103596

And, seems the static otf for Sora work fine when installed and used, don't know about Inter font of comment 8.

So, IMHO => NAB
Comment 20 V Stuart Foote 2021-07-28 13:09:40 UTC
(In reply to V Stuart Foote from comment #19)
> And, seems the static otf for Sora work fine when installed and used, don't
> know about Inter font of comment 8.

Inter is listed with both variable and "traditional constant" builds. So like Sora don't expect to use the variable font file.
Comment 21 Rafael Lima 2021-07-28 14:07:56 UTC
(In reply to V Stuart Foote from comment #19)
> There is no LibreOffice support for OTF variable fonts -- see also bug 103596

I see your point, but shouldn't this be at least an enhancement proposal? I believe at some point this support will have to be implemented.

Most users will expect native support for variable fonts. Or else we will keep receiving bug reports about this issue of not exporting PDF correctly for some fonts.

In truth, most average users don't even know what a "variable font" is and will not know the reason to the problem, leading them to think it is LibreOffice's fault.
Comment 22 Julien Nabet 2021-07-28 14:20:23 UTC
I agree(In reply to Rafael Lima from comment #21)
> (In reply to V Stuart Foote from comment #19)
> > There is no LibreOffice support for OTF variable fonts -- see also bug 103596
> 
> I see your point, but shouldn't this be at least an enhancement proposal? I
> believe at some point this support will have to be implemented.
> ...

If I understand well, tdf#103596 is the enhancement bug about this.
At the time it's been created, Harfbuzz 1.4 which provides variable font support (see https://www.phoronix.com/scan.php?page=news_item&px=HarfBuzz-1.4-Released) hadn't been released. Then, after it's been released there's been a first support with https://cgit.freedesktop.org/libreoffice/core/commit/?id=cb54bb89494218589227246f1923d8a24ab1676a. I don't know if there have been others but I suppose it's better to keep on the discussion about it on tdf#103596.
Comment 23 V Stuart Foote 2021-07-28 14:31:54 UTC
(In reply to Rafael Lima from comment #21)

Sure, but the see also is for the enhancement of supporting variable font, assume that would include work on the PDF and printing export filters.

Setting this a duplicate...

*** This bug has been marked as a duplicate of bug 103596 ***