Presentation fonts look OK In LO4.1.1, but when the saved file is opened in AO or older versions of LO 4.0.x or older default to Times New Roman. This is a major issue for corporate use.
Hi, I can't reproduce this. Could you please attach a test document? Thanks.
Created attachment 84497 [details] test.odp Test prez. Fonts display as DejaVu Sans in LO4.1.1.1, Times New Roman in LO4.0.5.1 and AO4.0.0
Created attachment 84581 [details] screenshot of 4.1.1.1 on Windows 7 (32-bit) @Theo: The presentation you attached opens with 'Times New Roman' also with 4.1.1.1 (see screenshot). Verified on Windows 7 (32-bit). Are you sure that 'Dejavu Sans' was used? Could you please attach a screenshot of the presentation in 4.1.1.1?
Created attachment 84583 [details] screenshot of test.odp in LO4.1.1.2 on OSX 10.8.4 Screenshot of test.odp in LO4.1.1.2 on MacOS. On Win 8 with LO4.1.1.1 I was getting the same result. It may have something to do with whether or not the template on which this presentation is based is installed.
The problem manifests itself also in a different way: old presentations with DejaVu Sans font that have been edited in LO4.1.1.1 display Times Roman in older versions of LO and in AO4.0.
@Theo: Could you please take a look at Bug 67665? I think it's the same issue you have. If this is the case, please mark this bug as a duplicate. thanks. (The fix for Bug 67665 is part of LO 4.1.1.2, so you can test it.)
Bug 67665 looks to be related, but this problem is different. The problem is that the file looks fine in LO4.1.1.x, but not in older versions, nor in AO4.0. Also existing presentations, updated in saved in LO4.1.1.2 show the problem: styles do not seem to be applied anymore when opening the doc in LO4.0.x or AO4.0. Second point is that I have already checked LO4.1.1.2, but the problem is still there.
OK, I've managed to reproduce the bug. Here is how: 1) Open Impress\Draw 4.1.1.2 2) Add a textbox or a shape, and enter some text into it. 3) Edit the style of the text, by choosing other font 4) Save 5) Close the file & reopen. The file will open correctly (because Bug 67665 is fixed). 5) Open in LO 4.0.x, the font resets to default. @Theo: test.odp isn't a valid test-case, since it was saved in 4.0.5 (You can see it if you unzip it and look into meta.xml), so marking it as obsolete.
Created attachment 84763 [details] test-case
Created attachment 84764 [details] screenshot of 4.1.1.2 (correct)
Created attachment 84766 [details] screenshot of 4.0.5.2 (wrong)
It appears that older versions don't understand style:font-name in non-automatic styles, only the deprecated fo:font-family
Well, https://gerrit.libreoffice.org/#/c/5810/ works for me, i.e. default continue to filter out the fo:family-name in preference to style:font-name except for exporting non auto styles where we would now add both.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d87cb77b42b591b1333aacd60e107514d6e20864 Resolves: fdo#68431 style:font-name unknown in non autostyles in impress/draw The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc46c86f56e0573d13d6b8140ef1aaf6f0db7895&h=libreoffice-4-1 Resolves: fdo#68431 style:font-name unknown in non autostyles in impress/draw It will be available in LibreOffice 4.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed by all this I hope. Also proposed for 4.1.2 in gerrit
*** Bug 70855 has been marked as a duplicate of this bug. ***