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
Any kind of this problem in LO 4.1. So this is a regression.
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? :-)
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.
Created attachment 90882 [details] PDF output vs editor
Created attachment 90883 [details] LO 4.1 PDF output
Created attachment 90884 [details] LO 4.2 PDF Output
I attached PDF output from LO 4.1 and 4.2 for comparison.
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.
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.
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.
Created attachment 90903 [details] Firefox 26 PDF output
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?
Now we have two problems here 1. different font substitutes in the editor and in the PDF export 2. unsupported SVG fonts ?
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.
(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.
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.
I created this file for the second bug https://bugs.freedesktop.org/show_bug.cgi?id=72861
Created attachment 90967 [details] Show similarity between ODT and PDF fonts
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.
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
(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
(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.
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
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 6eb770f9d6ded95f187d0509fb5a465868b07ad8 source 6eb770f9d6ded95f187d0509fb5a465868b07ad8 source 6644f69761c430ec8d63fd28f17704e8ece76426 source 33526481788137d959f27ae32910127d1436c1a8 source ffc782c23cf5a0b32f42ab4877062966e154cb74 source 3c38dd9bfec5752fa6486be355eca266db14bf66 :040000 040000 945116a660ad1c0c878697c8c5204c311c92b88d 2516814036e446ac52628c7339c1ae8d5262b6f6 M LibreOffice.app MacBook-Pro-van-Joren-DC:bibisect_mac_lo42 Joren$ git bisect log # bad: [6ca0dcc3cd12b5ba6b13bd8b05b59999bb2e22a9] source af00fce7c50afabf778580e842d3487650f00e96 # good: [e47ec366529846e008a4db27c8c507cdc7714c78] source 02021163dbbcc8904da0b2138c8b53684dcc8ab4 git bisect start '6ca0dcc3cd12b5ba6b13bd8b05b59999bb2e22a9' 'e47ec366529846e008a4db27c8c507cdc7714c78' # good: [8e2ab9eabfaf003def0f1e17da28c3798037b547] source af2bf3594101b66ecffbc118c0e8d5fb7fa23ba5 git bisect good 8e2ab9eabfaf003def0f1e17da28c3798037b547 # bad: [64ed493bd9434061662bea4b9ac35e88979a86b3] source b345b3b6bceddcce8966243304c9112e58a33304 git bisect bad 64ed493bd9434061662bea4b9ac35e88979a86b3 # bad: [64ed493bd9434061662bea4b9ac35e88979a86b3] source b345b3b6bceddcce8966243304c9112e58a33304 git bisect bad 64ed493bd9434061662bea4b9ac35e88979a86b3 # good: [ae5bc6812930c33e8edc457597bcd9ed96d0d920] source e85446e587704ffa31c50ee2b8fc1b21d6a16b12 git bisect good ae5bc6812930c33e8edc457597bcd9ed96d0d920 # good: [26fc9ae7a56c6926446664dae3fba18b17c5b91d] source 11f50dfa91ae382d59e751fa33c98d5478a2d52b git bisect good 26fc9ae7a56c6926446664dae3fba18b17c5b91d # skip: [772ada7e430640c9c2abb05943a60f9f1e183a5a] source 3e55e00662b50b02c289ca4a1d94d4306bd8c86b git bisect skip 772ada7e430640c9c2abb05943a60f9f1e183a5a # skip: [772ada7e430640c9c2abb05943a60f9f1e183a5a] source 3e55e00662b50b02c289ca4a1d94d4306bd8c86b git bisect skip 772ada7e430640c9c2abb05943a60f9f1e183a5a # good: [73fca9d4616320103c825190f88502851d8fc590] source 8001d9f4fed8f32410128b180d881d1131317255 git bisect good 73fca9d4616320103c825190f88502851d8fc590 # bad: [a0e65a1819840f6d1304308e06f82d82feed7576] source 856707082f2cc8dbd0476397f1c330c331cceb8e git bisect bad a0e65a1819840f6d1304308e06f82d82feed7576 # good: [a188fddae0d5da2703ade7dba178e0e38b556af4] source bad532dfd9cfd6c8a37d128c31f2916fdf290e1d git bisect good a188fddae0d5da2703ade7dba178e0e38b556af4 # good: [7ddc81541244ed1a8723e8abf02607bd82827b88] source 4f684749432a9811e9d13d34a3f44143acb0f5b1 git bisect good 7ddc81541244ed1a8723e8abf02607bd82827b88 # bad: [91e0d764221e8f11133d8027a3785d406f46f13d] source 6eb770f9d6ded95f187d0509fb5a465868b07ad8 git bisect bad 91e0d764221e8f11133d8027a3785d406f46f13d # first bad commit: [91e0d764221e8f11133d8027a3785d406f46f13d] source 6eb770f9d6ded95f187d0509fb5a465868b07ad8
(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.
(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 6eb770f9d6ded95f187d0509fb5a465868b07ad8 > > source 6eb770f9d6ded95f187d0509fb5a465868b07ad8 > source 6644f69761c430ec8d63fd28f17704e8ece76426 > source 33526481788137d959f27ae32910127d1436c1a8 > source ffc782c23cf5a0b32f42ab4877062966e154cb74 > source 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).
(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
bisecting of the bug (only looking at pdf output) resulten in this: # first bad commit: [c2c8aa000953d41aadffe29d204954aa0914c647] source 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.
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.
Setting MAB priority.
(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".
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
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.
Created attachment 110585 [details] odt and pdf comparison for #72628
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]