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
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: normal bold italic 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. 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.
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
>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: 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.
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 > 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.
*** Bug 140538 has been marked as a duplicate of this bug. ***
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
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 ***