Created attachment 65863 [details]
Steps how to reproduce with "LibreOffice 22.214.171.124 German UI/Locale [Build-ID: 4db6344] on German WIN7 Home Premium (64bit):
1. download / unzip attached test kit
2. open "source.odg" from LibO Start Center file menu
3. Do some exports to svg for compete page and selection
Expected: only contents of layer "Layout" (scheme) visible
Actual: also comments on invisible / unprintable layers "BMK", "vorlagen",
In test kit you will also find some of my export results, also from Master and also for other file types.
Also a problem with AOOo 3.4 and LibO 3.3.3 (difficult to see because text suppression bug), so seems inherited from OOo
For me this bug causes some horrible chin ups to use .svg export for the job.
(In reply to comment #0)
Version 126.96.36.199 (Build ID: e29a214) Slackware Linux 13.37
Comments are visible after I export, although they should be invisible.
Created attachment 91073 [details]
Improved testkit showing how layer information is ignored during export.
The attached files were produced under Ubuntu 10.04 x86_64 using:
- v188.8.131.52 OOO330m19 Build: 6
- v184.108.40.206 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a
In each ODG (one per version) there are four additional layers with these settings:
- V+P (visible and printable)
- V+nP (visible but NOT printable)
- nV+P (NOT visible but printable)
- nV+nP (NOT visible and NOT printable)
For each ODG export to these formats was made: BMP. EMF, EPS, GIF, JPG, PBM, PDF, PNG, SVG, TIF, WMF, and XPM. I loaded the EMF under Win7HP and took a screenshot to check visibility. For both versions and in all cases (except PDF) the object on each layer is exported to the format, regardless of the visible / printable setting. For PDF, only the V+P layer object is exported.
This would seem to be a more general problem with ignoring the status of these layer settings, than just an SVG-specific issue (the original test kit and description does indicate this).
As per comment #2, Platform set to All/All. "SVG" removed from summary for clarity.
*** Bug 72117 has been marked as a duplicate of this bug. ***
This issue has been annoying me for many years. I have a complex diagram of our facility with dozens of layers and I often need to export only CERTAIN layers in to a file. Every time I want to do this, I have to actually delete each layer I don't want included in the export.
Would be something great to fix in LO. I am thinking the best way to handle it would be to suppress export of layers that are not visible, so what you see is what you get. Although a case for using the print attribute is probably almost as compelling.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later)
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Created attachment 126777 [details]
bug is present in Version: 220.127.116.11
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
Threads CPU : 8; Version de l'OS :Linux 3.16; UI Render : par défaut;
Locale : fr-FR (fr_FR.utf8)
Workaround seems to export only selection (invisible layers are not selectable).
Bug was present in - v18.104.22.168 OOO330m19 Build: 6
as said by Owen Genat in comment 2 : https://bugs.documentfoundation.org//show_bug.cgi?id=53864#c2
On Hackfest Hamburg, April 2018, we have decided to start a project for improving handling of layers and internal structure. In case you start to work on this issue get in contact with Regina (firstname.lastname@example.org) or Armin (Armin.Le.Grand@me.com). It might be, that your solution touches that project.
Just tested with LibreOffice Draw V 22.214.171.124
3 shapes, each on a different one of the default layers
Unchecked 'Visible' for one after the other of the layers
Export as Pdf, No 'General' export option checked
Exactly the layers set to 'Visible' were exported.
'Printable' was ignored.
(In reply to Wolfgang Jäger from comment #10)
> Export as Pdf, No 'General' export option checked
> Result: Exactly the layers set to 'Visible' were exported.
> 'Printable' was ignored.
> Conclusion: RESOLVED FIXED
Was it tested also with exporting to SVG, PNG or JPEG (the most common non-PDF exports)? PDF is a very different type of export. (I have no easy access to a current version right now)
Sorry. I must have been stoned.
Pdf is still the only export format regarding the visibility of layers. (This is now tested at least with one example for every type.)
Settinng the bug NEW again.
(Also somehow strange for a bug reporterd in 2012 originally.)