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?
Steps to Reproduce:
1. Download and Install Sora Google Font
2. Create a document, using the bold fond
3. Export PDF or Print
italic works, bold doesn't
Bold parts should be bold :-)
User Profile Reset: No
CPU-Threads: 4; BS: Linux 5.3; UI-Render: Standard; VCL: gtk3;
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Created attachment 170124 [details]
Prepared document used for tests
Created attachment 170125 [details]
Created PDF (looks similar to printed output on paper)-- missing bold font style
Created attachment 170126 [details]
Used TTF: Sora
On pc Debian x86-64 with master sources updated today + gtk3 rendering, I could reproduce this.
I created a brand new doc and typed:
Then I put "bold" in bold and "italic" in italic
Finally, I exported in pdf.
"bold" isn't in bold.
Miklos: thought you might be interested in this one since you work on pdfium integration.
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.
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 ] >>
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
and "Regular" part suggests "Bold" is not used.
Actually, not reproducible if I export a pdf, using the attached odt file
Version: 18.104.22.168.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
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
>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
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.
Created attachment 170138 [details]
installed all fonts in static folder
there is 8 variants.
(misoperated and set RESOLVED FIXED. reverting to NEW)
Created attachment 170139 [details]
installed via Sora-VariableFont_wght.ttf
comment 7 shows only 7 variants.
comment 11 shows only 7 variants.
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:
This means all the styles are contained in a single file:
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.
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.
(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
IMHO, it's not a Google pb, the pb seems to be LO doesn't know how to manage variable font when exporting PDF.
*** Bug 140538 has been marked as a duplicate of this bug. ***
I had this same problem when I tried to use the variable version of the Inter font . 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 . I saw a related discussion in the harfbuzz git  and it might have some helpful info. The Inter website has a test page for browsers  and some useful information  about subsetting the variable font using two other tools  e .
Maybe this is something it could be done: detect the variable font being used, subset it, include the corresponding subset in the pdf file.
 Inter font family - https://rsms.me/inter/
 - https://bugs.documentfoundation.org/show_bug.cgi?id=137301
 Shaping and instantiating variable fonts - https://github.com/harfbuzz/harfbuzz/issues/2112
 Inter variable font test - https://rsms.me/inter/var-test.html
 subset - fontTools Documentation - https://fonttools.readthedocs.io/en/latest/subset/
 filamentgroup/glyphhanger - https://github.com/filamentgroup/glyphhanger
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
(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.
(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.
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.
(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 ***
*** This bug has been marked as a duplicate of bug 108497 ***