Created attachment 134029 [details] Zipped folder with sample Mac and Windows SVG My client downloaded LibreOffice last week. They are opening PPT or PPTX files in LibreOffice then exporting them as SVG files. No changes are made to the documents in LibreOffice. The image is not behaving the same in a browser as the image I create with an older version of LibreOffice on a Mac. It's not appearing when created on a Windows machine. Where as if I create the file on my older version on a Mac it does. I'm looking to find out what is different between the two images and am hoping this can be fixed. The Client Version Details: Ver: 5.3.3.2 Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group My Version Details: Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
The entire SVG export has been changed. Former it was a static export of a single slide. Now you get a dynamic slideshow including slide transitions. Mark all slides in the slide sorter and check "Selection" in the export dialog to test the new behavior. The transitions in the exported file are done by JavaScript, which is included in the file. Therefore you need to enable JavaScript in the browser. One way might be, to use an administrative installation or a portable version, which has a working SVG export of the old kind. Another way might be, to provide a script to your client, that extracts the single slides from the file, which was generated by the export. There exists no option to get the old kind of export. I currently do not find a bug report for a request to provide the old kind, without JavaScript, but it likely exists.
(In reply to Bonnie from comment #0) > My client downloaded LibreOffice last week. They are opening PPT or PPTX > files in LibreOffice then exporting them as SVG files. No changes are made > to the documents in LibreOffice. The image is not behaving the same in a > browser as the image I create with an older version of LibreOffice on a Mac. > It's not appearing when created on a Windows machine. Where as if I create > the file on my older version on a Mac it does. It is appearing just fine for me in Firefox 54 on Linux. The only difference is that the Windows version is centered and scaled to fit the browser window size. The old Mac version is a fixed size and aligned top left. So you are really seeing a blank screen, if you open it in a browser? Which browser?
We are referencing the image in two locations within our pages. When using the older version of LibreOffice the image appears in both locations correctly. When using the newer windows version One works and the other does not. I've had three clients all experience the same issue. When we replace the SVG with one made using the older copy of LibreOffice it works. The reference that does not display an image is: <img alt="seat map" class="img-thumbnail visible-lg visible-md" src="<field>F_HTML_FIREWALL</field>seatmap?map=<field>PB_TM_SEQ</field>&performance=<field>PB_SEQ</field>&selected_only=no&format=svg"/> The reference that does display the image is: <img class="img-responsive" src="<field>F_HTML_SEATMAP</field>&reserved_colour=007700&reserved_boundary=true&reserved_seat_border=5&format=svg"/> Thank you for looking into this for me. If it's not something that can be fixed moving forward would it be possible to get a link to the older version to share with our clients? Bonnie
(In reply to Bonnie from comment #3) > We are referencing the image in two locations within our pages. When using > the older version of LibreOffice the image appears in both locations > correctly. When using the newer windows version One works and the other does > not. I've had three clients all experience the same issue. When we replace > the SVG with one made using the older copy of LibreOffice it works. > > The reference that does not display an image is: > > <img alt="seat map" class="img-thumbnail visible-lg visible-md" > src="<field>F_HTML_FIREWALL</field>seatmap?map=<field>PB_TM_SEQ</ > field>&performance=<field>PB_SEQ</field>&selected_only=no&format=svg"/> > > > The reference that does display the image is: > > <img class="img-responsive" > src="<field>F_HTML_SEATMAP</ > field>&reserved_colour=007700&reserved_boundary=true&reserved_seat_border=5&f > ormat=svg"/> You have to open up the case a bit more as I don't understand what is going on in your system. What is the relevance of your custom markup <field> elements? What do the contents of the elements mean? I feel the markup you pasted is something that is not the final output, but needs processing. It seems the problem is in your own system as the files display just fine in the browser. Of course the JavaScript in the file is useless in this case and you could create some script to get rid of it in the file, deleting the element <script type="text/ecmascript">. You can get old versions here: https://downloadarchive.documentfoundation.org/libreoffice/old/ https://wiki.documentfoundation.org/Installing_in_parallel I could not find any existing report about creating SVGs in the old style. I searched for all Impress reports with svg in the summary.
Created attachment 134386 [details] Preview of images from Mac desktop Attached is an image that displays the issue we are experiencing. The Mac SVG has content. The Windows SVG is white. The same image should appear in both. The Quick View show the Windows SVG as white without the content. The extra Java added to the Windows file seems to brake the view. We need a way to either have the SVG export provide an option to only focus of a single slide or to not contain the extra Java.
Bonnie: I asked for an explanation for this: (In reply to Bonnie from comment #3) > The reference that does not display an image is: > > <img alt="seat map" class="img-thumbnail visible-lg visible-md" > src="<field>F_HTML_FIREWALL</field>seatmap?map=<field>PB_TM_SEQ</ > field>&performance=<field>PB_SEQ</field>&selected_only=no&format=svg"/> > > > The reference that does display the image is: > > <img class="img-responsive" > src="<field>F_HTML_SEATMAP</ > field>&reserved_colour=007700&reserved_boundary=true&reserved_seat_border=5&f > ormat=svg"/> Preferably attach your full HTML. The Javascript cannot be simply removed. I tried it with sed '/<script/,/<\/script>/d' inputfile > outputfile which works on Mac as well, but after that, the file does not display in Firefox anymore. Now I tried opening your Window5332t.svg in Safari and it displays fine, so I don't get what the problem is. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Hello Buovjaga, The link I previously sent is not relevant. It contains our internal software references to the svg file and do not impact the image. Ultimately the new version contains details in the image that break the image. If you need an example showing how the image does not work online please let me know and I'll prepare one for you. Ultimately we can both agree the details in the format of the SVG has changed. Bonnie (In reply to Buovjaga from comment #6) > Bonnie: I asked for an explanation for this: > > (In reply to Bonnie from comment #3) > > The reference that does not display an image is: > > > > <img alt="seat map" class="img-thumbnail visible-lg visible-md" > > src="<field>F_HTML_FIREWALL</field>seatmap?map=<field>PB_TM_SEQ</ > > field>&performance=<field>PB_SEQ</field>&selected_only=no&format=svg"/> > > > > > > The reference that does display the image is: > > > > <img class="img-responsive" > > src="<field>F_HTML_SEATMAP</ > > field>&reserved_colour=007700&reserved_boundary=true&reserved_seat_border=5&f > > ormat=svg"/> > > Preferably attach your full HTML. > > The Javascript cannot be simply removed. I tried it with > > sed '/<script/,/<\/script>/d' inputfile > outputfile > > which works on Mac as well, but after that, the file does not display in > Firefox anymore. > > Now I tried opening your Window5332t.svg in Safari and it displays fine, so > I don't get what the problem is. > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the information.
If you remove the JavaScript you have to set the visibility to "visible" in addition, because that would be done by the script. In the example you have attached it is in line #166.
(In reply to Regina Henschel from comment #8) > If you remove the JavaScript you have to set the visibility to "visible" in > addition, because that would be done by the script. In the example you have > attached it is in line #166. Hi Bonnie, Did Regina's comment help you? Should this issue be closed?
No, it did not. The SVG file created on the Windows application is no longer a true SVG. We have decided to stop upgrading the product to prevent further issue on our part and look for alternative software to create the file type.
(In reply to Bonnie from comment #10) > No, it did not. The SVG file created on the Windows application is no longer > a true SVG. We have decided to stop upgrading the product to prevent further > issue on our part and look for alternative software to create the file type. It is also possible to contract professional support: https://www.documentfoundation.org/gethelp/developers/
*** Bug 115264 has been marked as a duplicate of this bug. ***
Marco: are these sorts of bugs basically WONTFIX?
Hello Bonnie, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Bonnie, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Bonnie, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp