Bug 93703 - SVG imported does not show in presentation, but in editor
Summary: SVG imported does not show in presentation, but in editor
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: highest major
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.2.0 target:5.1.0.2 target:5...
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2015-08-27 09:17 UTC by Uwe Dippel
Modified: 2016-10-25 19:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
SVG visible in edit, not visible in presentation mode (572.02 KB, application/vnd.oasis.opendocument.presentation)
2015-08-27 09:17 UTC, Uwe Dippel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Uwe Dippel 2015-08-27 09:17:24 UTC
Created attachment 118217 [details]
SVG visible in edit, not visible in presentation mode

I still have a problem with an SVG imported using 5.0.0.5: it shows in edit mode, but not in presentation mode.

If necessary, I'd be prepared to file an RFE as generalisation: We have seen some bug reports stating that edit mode shows this and that, but in presentation mode respectively PDF export, nothing was visible. 
While the test cases until now might have been 'resolved', it is unforgivable, so to say, that PDF export or presentation(s) do not show elements visible in edit. In a nutshell: The rendering engines ought better be unified, to either. Nothing worse than a presentation well done and looking good, but being empty when shown. It must not be necessary to double-check each and every slide, addition and modification in presentation mode to make sure.
Comment 1 raal 2015-09-07 20:00:39 UTC
Reproducible with Version: 5.1.0.0.alpha1+
Build ID: 50f2c712c46c66264279ab3b61888e491a4d8dca
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-09-04_06:07:29


works correct in Verze: 4.4.2.2,ID sestavení: 40m0(Build:2) -> regression
Comment 2 Regina Henschel 2015-09-08 17:48:50 UTC
Please have a lock at the settings "Use hardware acceleration" and "Use OpenGL for all rendering" in Tools > Options > LibreOffice > View, and at the setting "Allow use of OpenCL" in Tools > Options > LibreOffice > OpenCL. Disable them all. Is the picture shown then? If yes, enable each of the settings alone. Does rendering fail then? If yes in which case?
Comment 3 raal 2015-09-08 18:27:49 UTC
(In reply to Regina Henschel from comment #2)
> Please have a lock at the settings "Use hardware acceleration" and "Use
> OpenGL for all rendering" in Tools > Options > LibreOffice > View, and at
> the setting "Allow use of OpenCL" in Tools > Options > LibreOffice > OpenCL.
> Disable them all. Is the picture shown then? 

Yes, I can see the picture with these settings off.

If yes, enable each of the
> settings alone. Does rendering fail then? If yes in which case?

"Use hardware acceleration" is a culprit
Comment 4 Uwe Dippel 2015-09-08 19:49:08 UTC
I tried on another machine, at home.
There it works perfectly well, with hardware acceleration enabled. Which is even worse, once I bring my slides to be used on another machine, giving a presentation, and - all empty, or having to show from the editor. 
Anyone falling into this trap would have a good reason to curse this software, I am afraid.
Comment 5 Uwe Dippel 2015-09-09 12:01:27 UTC
Exactly the same here. 
(I tried on the machine on which I had initially reported the bug.)
Anti-Alias makes no difference, but hardware acceleration does.

Modification of 'Allow usage of OpenCL' makes no difference. The picture is still invisible.
Comment 6 Robinson Tryon (qubit) 2015-12-14 05:32:42 UTC Comment hidden (obsolete)
Comment 7 Joel Madero 2015-12-20 06:49:56 UTC
Setting to:
Major - major functionality for presentation - objects at least in some context simply disappear when actually viewing the presentation

Highest - regression. Despite there being a workaround (to disable hardware acceleration) many users would simply not know to do this.
 27ad5a66dc10c8c9a47cd9a4f7d290c65493c7de is the first bad commit
commit 27ad5a66dc10c8c9a47cd9a4f7d290c65493c7de
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 17:01:13 2015 +0800

    source-hash-4ac876084bb89b6460b31e090a666b395f66b1e8
    
    commit 4ac876084bb89b6460b31e090a666b395f66b1e8
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Sun Dec 7 11:52:14 2014 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Sun Dec 7 14:17:00 2014 +0000
    
        mpSurface->getCairo() == mpCairo
    
        so make that clearer, and we only need to pass a Cairo context
        not a surface here
    
        Change-Id: If385dbd4e8a546fa18c2f93650428fe0ed0c76fc

:040000 040000 037291a556c5cdf605a57b8e88f177c1568644af aa1127926bcf1dcd0adeb50d100c84ca5bb9c8a5 M	opt


# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557
# bad: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03
git bisect bad 770ff0d1a74d2450c2decb349b62c5087e12c46b
# bad: [227af65db5e34efcf8dcb0b53333efecd30f37f8] source-hash-193c7ba9be48f00b46f9e789f233db577e7b3303
git bisect bad 227af65db5e34efcf8dcb0b53333efecd30f37f8
# good: [579722ff16592be24bae52c4fea90bbef0609601] source-hash-509e54df095712a91ff9ab3c6b885998936f79a0
git bisect good 579722ff16592be24bae52c4fea90bbef0609601
# good: [ae5a8b5aab2136349fc9ce4e96754215d679a511] source-hash-3c1b9b89caddeff71afd3d97f52dd93df5c529af
git bisect good ae5a8b5aab2136349fc9ce4e96754215d679a511
# good: [15752a13f7af38fa82a6daa97ea0d399596b1c96] source-hash-0cb6a92f86e02f6342be5e8f931dc1849114230c
git bisect good 15752a13f7af38fa82a6daa97ea0d399596b1c96
# good: [8972e1d61a579afb76fb43bf07be39ea5819176a] source-hash-aafcbb3e1e70642983152f79843b2f0cd15eb79c
git bisect good 8972e1d61a579afb76fb43bf07be39ea5819176a
# good: [f4401cd99760ceca38f48baec44f50090ef7e3e9] source-hash-4c6a30d53d9039066c368b9e9f6819e8594461cc
git bisect good f4401cd99760ceca38f48baec44f50090ef7e3e9
# bad: [2d922f91d1fb9dc1bd5705dfeb5b70734883e9ce] source-hash-46593a05b28f93831da925aa7092b72be2209685
git bisect bad 2d922f91d1fb9dc1bd5705dfeb5b70734883e9ce
# bad: [a3db88adb8e4bce96f3cb2905be1574569a2d132] source-hash-6fe664f24bf086520248b8fd606b6696c63ed3f4
git bisect bad a3db88adb8e4bce96f3cb2905be1574569a2d132
# bad: [03e0e8d72142e9b89a66205172a1a6b663e2d902] source-hash-674e4b0c73dbef81d966e9193ec4b84df2d843b6
git bisect bad 03e0e8d72142e9b89a66205172a1a6b663e2d902
# bad: [27ad5a66dc10c8c9a47cd9a4f7d290c65493c7de] source-hash-4ac876084bb89b6460b31e090a666b395f66b1e8
git bisect bad 27ad5a66dc10c8c9a47cd9a4f7d290c65493c7de
# good: [3563ecfdb7c1120478b4eac2cde6318bf1228fcf] source-hash-5e59fe98ce4b29dd75e9d484a7f0d43b575709e8
git bisect good 3563ecfdb7c1120478b4eac2cde6318bf1228fcf
# first bad commit: [27ad5a66dc10c8c9a47cd9a4f7d290c65493c7de] source-hash-4ac876084bb89b6460b31e090a666b395f66b1e8
Comment 8 Commit Notification 2015-12-21 21:25:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#93703 0 scaling is CAIRO_STATUS_INVALID_MATRIX

It will be available in 5.2.0.

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.
Comment 9 Caolán McNamara 2015-12-21 21:27:26 UTC
divide by zero essentially
Comment 10 Caolán McNamara 2015-12-21 21:27:47 UTC
https://gerrit.libreoffice.org/20852
Comment 11 Commit Notification 2015-12-21 21:27:53 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a56a28b89810783f069200fedf6fc307a314e69&h=libreoffice-5-1

Resolves: tdf#93703 0 scaling is CAIRO_STATUS_INVALID_MATRIX

It will be available in 5.1.0.2.

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.
Comment 12 Commit Notification 2016-01-12 16:17:26 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfaf07f88332dfe0476d559787c508a1688b5956&h=libreoffice-5-0

Resolves: tdf#93703 0 scaling is CAIRO_STATUS_INVALID_MATRIX

It will be available in 5.0.5.

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.