Bug 72628 - Different font substitutes used for view in Writer vs. export for PDF
Summary: Different font substitutes used for view in Writer vs. export for PDF
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.0.beta2
Hardware: All Mac OS X (All)
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: NoRepro:4.2.0.1:Ubuntu Confirmed:4.3....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering mab4.2
  Show dependency treegraph
 
Reported: 2013-12-12 06:13 UTC by deepjungle.maca
Modified: 2015-12-17 07:34 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
BMC (162.63 KB, application/vnd.oasis.opendocument.text)
2013-12-12 06:13 UTC, deepjungle.maca
Details
PDF output vs editor (34.83 KB, image/png)
2013-12-17 16:11 UTC, deepjungle.maca
Details
LO 4.1 PDF output (31.24 KB, application/pdf)
2013-12-17 16:14 UTC, deepjungle.maca
Details
LO 4.2 PDF Output (31.25 KB, application/pdf)
2013-12-17 16:15 UTC, deepjungle.maca
Details
Firefox 26 PDF output (58.35 KB, application/pdf)
2013-12-17 21:42 UTC, deepjungle.maca
Details
Show similarity between ODT and PDF fonts (102.66 KB, image/png)
2013-12-19 05:25 UTC, Robinson Tryon (qubit)
Details
odt and pdf comparison for #72628 (166.76 KB, image/png)
2014-12-08 19:50 UTC, retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description deepjungle.maca 2013-12-12 06:13:30 UTC
Created attachment 90638 [details]
BMC

Steps to reproduce

1. Open the attached file (BMC.odt)
2. Export to PDF
3. Compare

Result:
Wrong font rendering in the editor

LO 4.2.0.0beta2

OS: Mac OS X 10.9
Comment 1 deepjungle.maca 2013-12-12 06:14:19 UTC
Any kind of this problem in LO 4.1. So this is a regression.
Comment 2 Robinson Tryon (qubit) 2013-12-17 09:13:53 UTC
TESTING on LO 4.2.0.0.beta2 + Ubuntu 12.04.3

Tagging as PossibleRegression per comment #1.

---

No Repro for me. The fonts in the output PDF look the same as the ones in the input ODT. Perhaps this is an OSX-only bug?

Joren: Do you have time to test this one? :-)
Comment 3 deepjungle.maca 2013-12-17 16:10:09 UTC
Ah, sorry. I made a wrong description.

The problem is in PDF output, not in the editor as described before. I attached a screenshot where it would be more obvious.

On the left side is PDF output, on the right side LO 4.2.0.0beta2

I double checked it on LO 4.1, and the output is fine.
Comment 4 deepjungle.maca 2013-12-17 16:11:28 UTC
Created attachment 90882 [details]
PDF output vs editor
Comment 5 deepjungle.maca 2013-12-17 16:14:40 UTC
Created attachment 90883 [details]
LO 4.1 PDF output
Comment 6 deepjungle.maca 2013-12-17 16:15:06 UTC
Created attachment 90884 [details]
LO 4.2 PDF Output
Comment 7 deepjungle.maca 2013-12-17 16:16:19 UTC
I attached PDF output from LO 4.1 and 4.2 for comparison.
Comment 8 deepjungle.maca 2013-12-17 16:20:37 UTC
BTW: This bug is crucial for me. I need to finish my master thesis until 9th January 2014. LO 4.2 fixes some problems with my used SVG but there have been added other ones. I'd have added more information. I hope I've done it.
Comment 9 Regina Henschel 2013-12-17 21:26:21 UTC
The embedded svg graphic refers the fonts "Adobe Caslon Pro Bold" and "Adobe Garamond Pro" and "Adobe Garamond Pro Bold". These are commercial fonts and do not belong to usually installed fonts. Do you have installed them on your PC?

I haven't got the Adobe fonts and for me the fonts in the image are already wrong in Writer, using fonts far away from a "Garamond". I see, that different font substitutes are used in LO4.1 and LO4.3 in Writer. But whereas LO4.1 uses the same font for Writer and for pdf export, LO4.3 uses different fonts for Writer and pdf export. So it seems, something changed in font substitution.

If I generate a .svg graphic using fonts, which are installed on my PC, then view in Writer and .pdf export are correct in LO4.1 and LO4.3. The generated .pdf file 
contains the correct font embedding.

The pdf export reacts on the font substitutions, which are set in Tools > Options. Have you defined font substitutions there? If you got the .svg image from somewhere and have not installed the Adobe fonts, you can use the font substitutions to set proper substitutes explicitly. That might help for your master thesis.

To summarize my observations: LO 4.3 uses different font substitutes for view in Writer and for .pdf export, which I consider to be a bug.
I work on Windows 7.
Comment 10 deepjungle.maca 2013-12-17 21:41:50 UTC
No, I don't have the font installed on Mac. If I open the SVG in Firefox, everything is fine .

If I take a look at a source of the SVG so there are embedded glyphs (SVG fonts). So Firefox shows it correctly without a need installed the font on a computer. It's the same case in LO 4.1.

I attached PDF output from Firefox. You can compare it with LO 4.1's export.
Comment 11 deepjungle.maca 2013-12-17 21:42:29 UTC
Created attachment 90903 [details]
Firefox 26 PDF output
Comment 12 deepjungle.maca 2013-12-17 21:48:55 UTC
Ah, I see it now. You're right. The export from LO 4.1 is not same as from Firefox 26. My colleague who edited the image confirmed the output from Firefox is 100% right as his source.

So, if I see it right. LO doesn't have a support SVG fonts, right? Or am I wrong?
Comment 13 deepjungle.maca 2013-12-17 21:51:37 UTC
Now we have two problems here

1. different font substitutes in the editor and in the PDF export 
2. unsupported SVG fonts

?
Comment 14 Regina Henschel 2013-12-17 22:27:41 UTC
Yes, I think so too.

for 1.
Different font substitutes is a bug. I suggest to track it in this bug report.

for 2.
Not using the contained paths is a missing feature. AOO too has not implemented it, see https://issues.apache.org/ooo/show_bug.cgi?id=122324
I suggest to write a new bug report for it.
Comment 15 Robinson Tryon (qubit) 2013-12-18 09:50:54 UTC
(In reply to comment #14)
> Yes, I think so too.
> 
> for 1.
> Different font substitutes is a bug. I suggest to track it in this bug
> report.

Updated summary to reflect this particular issue.

(In reply to comment #9)
> different font substitutes are used in LO4.1 and LO4.3 in Writer. But
> whereas LO4.1 uses the same font for Writer and for pdf export, LO4.3 uses
> different fonts for Writer and pdf export. So it seems, something changed in
> font substitution.

Keywords: Per this note, marking as 'regression'.
Version: Keeping 4.2 beta2 (we can do some quick testing to narrow the time in which this regression was introduced after 4.1
Status: NEW
Whiteboard: Removing 'norepro' as the bug has changed.

DeepJungle/Regina - Could one of you provide quick repro steps for the font substitution regression?

> for 2.
> Not using the contained paths is a missing feature. AOO too has not
> implemented it, see https://issues.apache.org/ooo/show_bug.cgi?id=122324
> I suggest to write a new bug report for it.

+1

I don't see any filed bugs about lack of support for SVG font embedding, so please do file one.
Comment 16 deepjungle.maca 2013-12-19 02:50:58 UTC
Qubit:
I hope it is clear from the below description

Steps to reproduce

1. Open the attached file (BMC.odt)
2. Export to PDF
3. Compare

Result:
The image in PDF has different font substitutes than in LO 4.2's editor.
Comment 17 deepjungle.maca 2013-12-19 03:04:59 UTC
I created this file for the second bug

https://bugs.freedesktop.org/show_bug.cgi?id=72861
Comment 18 Robinson Tryon (qubit) 2013-12-19 05:25:01 UTC
Created attachment 90967 [details]
Show similarity between ODT and PDF fonts
Comment 19 Robinson Tryon (qubit) 2013-12-19 05:31:32 UTC
TESTING on LO 4.2.0.1 + Ubuntu 12.04.3

(In reply to comment #16)
> Qubit:
> I hope it is clear from the below description
> 
> Steps to reproduce
> 
> 1. Open the attached file (BMC.odt)
> 2. Export to PDF
> 3. Compare
> 
> Result:
> The image in PDF has different font substitutes than in LO 4.2's editor.

NoRepro again. Font appears the same in Writer as it does in exported PDF.

See attachment 90967 [details] for a side-by-side comparison.
Comment 20 deepjungle.maca 2013-12-19 06:39:44 UTC
But I use Mac OS X 10.9. So it seems it is Mac specific problem.

I was able to replicate it. Please, check the below screenshot

https://dl.dropboxusercontent.com/u/9411508/Screen%20Shot%202013-12-19%20at%2007.23.14.png
https://dl.dropboxusercontent.com/u/9411508/Screen%20Shot%202013-12-19%20at%2007.31.06.png
Comment 21 Robinson Tryon (qubit) 2013-12-19 06:50:34 UTC
(In reply to comment #20)
> But I use Mac OS X 10.9. So it seems it is Mac specific problem.

Roger. Updating OS field now.

OS: Mac OS X
Comment 22 Robinson Tryon (qubit) 2013-12-19 06:53:02 UTC
(In reply to comment #20)
> But I use Mac OS X 10.9. So it seems it is Mac specific problem.

Roger. Updating OS and Whiteboard fields now.
Comment 23 Michael Stahl (CIB) 2014-01-14 20:27:41 UTC
happens on Windows too with current master (but not on Linux)

would be great to have a bibisect result on the Mac
git://dev-downloads.libreoffice.org/bibisect_mac_lo42.git
Comment 24 Jorendc 2014-01-14 22:20:05 UTC
MacBook-Pro-van-Joren-DC:bibisect_mac_lo42 Joren$ git bisect bad
91e0d764221e8f11133d8027a3785d406f46f13d is the first bad commit
commit 91e0d764221e8f11133d8027a3785d406f46f13d
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Sun Nov 24 19:18:06 2013 -0600

    source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
    
    source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
    source sha:6644f69761c430ec8d63fd28f17704e8ece76426
    source sha:33526481788137d959f27ae32910127d1436c1a8
    source sha:ffc782c23cf5a0b32f42ab4877062966e154cb74
    source sha:3c38dd9bfec5752fa6486be355eca266db14bf66

:040000 040000 945116a660ad1c0c878697c8c5204c311c92b88d 2516814036e446ac52628c7339c1ae8d5262b6f6 M	LibreOffice.app

MacBook-Pro-van-Joren-DC:bibisect_mac_lo42 Joren$ git bisect log
# bad: [6ca0dcc3cd12b5ba6b13bd8b05b59999bb2e22a9] source sha:af00fce7c50afabf778580e842d3487650f00e96
# good: [e47ec366529846e008a4db27c8c507cdc7714c78] source sha:02021163dbbcc8904da0b2138c8b53684dcc8ab4
git bisect start '6ca0dcc3cd12b5ba6b13bd8b05b59999bb2e22a9' 'e47ec366529846e008a4db27c8c507cdc7714c78'
# good: [8e2ab9eabfaf003def0f1e17da28c3798037b547] source sha:af2bf3594101b66ecffbc118c0e8d5fb7fa23ba5
git bisect good 8e2ab9eabfaf003def0f1e17da28c3798037b547
# bad: [64ed493bd9434061662bea4b9ac35e88979a86b3] source sha:b345b3b6bceddcce8966243304c9112e58a33304
git bisect bad 64ed493bd9434061662bea4b9ac35e88979a86b3
# bad: [64ed493bd9434061662bea4b9ac35e88979a86b3] source sha:b345b3b6bceddcce8966243304c9112e58a33304
git bisect bad 64ed493bd9434061662bea4b9ac35e88979a86b3
# good: [ae5bc6812930c33e8edc457597bcd9ed96d0d920] source sha:e85446e587704ffa31c50ee2b8fc1b21d6a16b12
git bisect good ae5bc6812930c33e8edc457597bcd9ed96d0d920
# good: [26fc9ae7a56c6926446664dae3fba18b17c5b91d] source sha:11f50dfa91ae382d59e751fa33c98d5478a2d52b
git bisect good 26fc9ae7a56c6926446664dae3fba18b17c5b91d
# skip: [772ada7e430640c9c2abb05943a60f9f1e183a5a] source sha:3e55e00662b50b02c289ca4a1d94d4306bd8c86b
git bisect skip 772ada7e430640c9c2abb05943a60f9f1e183a5a
# skip: [772ada7e430640c9c2abb05943a60f9f1e183a5a] source sha:3e55e00662b50b02c289ca4a1d94d4306bd8c86b
git bisect skip 772ada7e430640c9c2abb05943a60f9f1e183a5a
# good: [73fca9d4616320103c825190f88502851d8fc590] source sha:8001d9f4fed8f32410128b180d881d1131317255
git bisect good 73fca9d4616320103c825190f88502851d8fc590
# bad: [a0e65a1819840f6d1304308e06f82d82feed7576] source sha:856707082f2cc8dbd0476397f1c330c331cceb8e
git bisect bad a0e65a1819840f6d1304308e06f82d82feed7576
# good: [a188fddae0d5da2703ade7dba178e0e38b556af4] source sha:bad532dfd9cfd6c8a37d128c31f2916fdf290e1d
git bisect good a188fddae0d5da2703ade7dba178e0e38b556af4
# good: [7ddc81541244ed1a8723e8abf02607bd82827b88] source sha:4f684749432a9811e9d13d34a3f44143acb0f5b1
git bisect good 7ddc81541244ed1a8723e8abf02607bd82827b88
# bad: [91e0d764221e8f11133d8027a3785d406f46f13d] source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
git bisect bad 91e0d764221e8f11133d8027a3785d406f46f13d
# first bad commit: [91e0d764221e8f11133d8027a3785d406f46f13d] source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
Comment 25 Björn Michaelsen 2014-01-17 09:40:31 UTC
(This is an automated message.)

Setting priority to highest as this is a 4.2 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 26 Khaled Hosny 2014-01-17 18:06:36 UTC
(In reply to comment #24)
> MacBook-Pro-van-Joren-DC:bibisect_mac_lo42 Joren$ git bisect bad
> 91e0d764221e8f11133d8027a3785d406f46f13d is the first bad commit
> commit 91e0d764221e8f11133d8027a3785d406f46f13d
> Author: Norbert Thiebaud <nthiebaud@gmail.com>
> Date:   Sun Nov 24 19:18:06 2013 -0600
> 
>     source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
>     
>     source sha:6eb770f9d6ded95f187d0509fb5a465868b07ad8
>     source sha:6644f69761c430ec8d63fd28f17704e8ece76426
>     source sha:33526481788137d959f27ae32910127d1436c1a8
>     source sha:ffc782c23cf5a0b32f42ab4877062966e154cb74
>     source sha:3c38dd9bfec5752fa6486be355eca266db14bf66

I never understood the bibisect output, but I assume those are the suspected source tree commits, right? (they all seem to be OUString conversion commits).
Comment 27 Jorendc 2014-01-17 19:19:55 UTC
(In reply to comment #26)
> I never understood the bibisect output, but I assume those are the suspected
> source tree commits, right? (they all seem to be OUString conversion
> commits).

Indeed. I spoke with Norbert and Michael S. today on IRC, related to this bibisect. Looks like I bibisected the turnover in behavior. The oldest possible LibreOffice-version in the Mac OSX bibisect package doesn't export _any_ text, so I made the assumption the behavior was 'good', to bibisect further.

The next bibisection 'good' and 'bad' is made on the fact the export is exporting the font as in version 4.1 (see attachment 'LO 4.1 PDF output'). During the whole bibisect there was no correct behavior (same exported font, as font in editor/Writer).
The 'good' behavior I bibisected was: 
"Wrong in editor, correct in pdf export"
'bad':
"correct in editor, wrong in pdf export".

So, my bibisection is incorrect and just shows the turn-over point from 'good' and 'bad' behavior as described above.

I'm sorry for the confusion
Comment 28 Christian Lohmaier 2014-01-19 00:06:57 UTC
bisecting of the bug (only looking at pdf output) resulten in this:

# first bad commit: [c2c8aa000953d41aadffe29d204954aa0914c647] source sha:8efbafaf8681d39c8c3674368e02ddd572ba5d32

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8efbafaf8681d39c8c3674368e02ddd572ba5d32

"Related: fdo#68192 register bundled fonts"

             pdf                          LibreOffice
before: Arial BoldItalicMT                serif-font
after:  LiberationSerif BoldItalic        non-serif font

So that commit swaps around the two. you swap serif-font in LO and non-serif in PDF by non-serif-font in LO and serif-font in PDF.

Apart from that: This issues is impossible to bibisect on Mac (10.9). What the result is on older builds depends on some random race condition or Mac does some weird caching or whatever.

doing 

rm -rf ~/Library/Application\ Support/LibreOffice* *.pdf ; ( ./LibreOffice.app/Contents/MacOS/soffice 72628_BCM.odt || ./LibreOffice.app/Contents/MacOS/soffice 72628_BCM.odt ) && open 72628_BCM.pdf

(LO likes to crash without user-dir it seems, so running it twice in this case, when LO is up, use "Export to PDF" button from toolbar, accept default name and quit using command+Q, compare rendering result of PDF in preview app and quit that with command+Q as well, then repeat a couple of times and grow some grey hair...)

running the above command multiple times gives all kind of results on 0052712:
From no text in PDF, to same style in both LO and PDF (some time serif, some time non-serif) to different fontstyle in LO and PDF.
Comment 29 Michael Stahl (CIB) 2014-01-28 13:24:19 UTC
reading previous comment it's plausible that this commit would change it
for Windows, and reverting it does change the font used in the PDF file,
but just from one serif font to a different one, i.e. before that commit
the fonts in PDF and LO were different already:

commit c91f7082180d1ca90467891f3b7ca9a3e845d9e7
Author:     Michael Stahl <mstahl@redhat.com>
AuthorDate: Tue Sep 3 17:27:44 2013 +0200

    fdo#68731: vcl: fix path for bundled fonts on Windows
    
    WinSalGraphics::GetDevFontList(): remove the obsolete "Basis" from
    the search path to find the bundled fonts.
Comment 30 Björn Michaelsen 2014-02-12 11:41:49 UTC
Setting MAB priority.
Comment 31 Björn Michaelsen 2014-10-16 14:59:07 UTC
(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".
Comment 32 tommy27 2014-12-08 10:10:17 UTC
I don't reproduce this bug under Win81. x64 using LibO 4.3.4.1

please Mac users, retest with 4.3.4.1 or 4.4.0.0 beta
if bug is still present please move this from mab4.2 list to mab4.3 list since 4.2.x reached the end of life
Comment 33 retired 2014-12-08 19:49:28 UTC
I'll go ahead and put this WORKSFORME.

OS X 10.10.1 LO Version: 4.5.0.0.alpha0+
Build ID: a26222f5af55e8ffe9784dd411485d3c5c72e983
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2014-12-07_00:14:47
Locale: de_

adding screenshot right now.
Comment 34 retired 2014-12-08 19:50:07 UTC
Created attachment 110585 [details]
odt and pdf comparison for #72628
Comment 35 Robinson Tryon (qubit) 2015-12-17 07:34:43 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]