Created attachment 65863 [details] Test Kit Steps how to reproduce with "LibreOffice 3.6.1.1 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", "Anmerkung" visible 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) Confirmed here: Version 3.6.1.2 (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: - v3.3.0.4 OOO330m19 Build: 6 - v4.1.3.2 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) https://www.libreoffice.org/download/ 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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] Test case bug is present in Version: 5.2.0.4 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). Luc.
Bug was present in - v3.3.0.4 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 (rb.henschel@t-online.de) or Armin (Armin.Le.Grand@me.com). It might be, that your solution touches that project.
Just tested with LibreOffice Draw V 6.2.2.2 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 Result: Exactly the layers set to 'Visible' were exported. 'Printable' was ignored. Conclusion: RESOLVED FIXED
(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.)
Positive webpage, where did u think of the data on this posting?I have perused a couple of the articles on your site now, and I truly like your style. Much obliged and please keep up the powerful work. https://www.furniturescam.com
Bug still present while exporting to jpg in: Version: 6.4.0.3 Build ID: 40(Build:3) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded Version: 7.0.0.0.alpha0+ Build ID: 4223ff2be69f03e571464b0b09ad0d278918631b CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
SEO Backlinks LTD is a UK-based registered company and providing SEO Backlinks Services for many years and has unlimited satisfied clients. Build high-quality links, increase your visibility, and enjoy the rewards of a better ranking position and more traffic. For more info: https://seobacklinks.uk/.
*** Bug 146268 has been marked as a duplicate of this bug. ***
*** Bug 149900 has been marked as a duplicate of this bug. ***
A layer will still export even after clearing the "Printable" option on the layer. 1. Create a new Windows LO Draw document 2. Insert a layer and select it 3. Clear the "printable" option on the layer 4. Draw something on the layer 5. Export the file On step 3, clearing both the "printable" and "visible" options still exported the layer. Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f1e15482bcf6bf65dc611e19cbd2ffff479ef141 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
I can't believe this bug has been around since 2012. Were I a decent programmer I'd tackle it myself.
(In reply to xordevoreaux from comment #19) > I can't believe this bug has been around since 2012. Yeah, it is not the only one. And it has been around longer than 2012 (it was inherited from OpenOffice). What I do when I have to export is just delete each layer I don't want in the export. Can take a while when there are a dozen plus layers. But it works. Then exit without saving (or use reload). > Were I a decent programmer I'd tackle it myself. Me too. I would think it would be an easy change. But this issue doesn't affect many people, I suppose.
Another workaround is to set layer to "not visible" and "not printable" and then do not export the entire page, but make a drag-selection from top-left to bottom-right. The selection contains only visible objects. Then export with option "Selection" enabled.
(In reply to Regina Henschel from comment #21) > Another workaround is to set layer to "not visible" and "not printable" and > then do not export the entire page, but make a drag-selection from top-left > to bottom-right. The selection contains only visible objects. Then export > with option "Selection" enabled. I tried that just now, and unless I'm somehow not doing it right, won't work for me. Proportions don't remain the same when you do that. For creating and exporting textures for Sims 4 objects that I create game mods for, the export must be identical to or an exact multiple of the original texture, or they will fail to render in-game. If the page exports as 1024x2048 pixels, which is what the game expects, but I only select the objects on the page that render, which usually only encompass the bottom half of a drawing page, the resulting dimensions when exporting only that selection is smaller than what's required. Useless.
Created attachment 181207 [details] Sample file where the output dimensions must never change I've attached something like what I've been talking about, the most extreme example I could find, which is a template that I use for making body tattoos for The Sims 4. Each page represents a different location on the body for placing a tattoo (the blue squares). I don't want those blue squares to export (I always export to PNG because that's what the modding tool wants). The blue squares are for placement only, showing me the boundaries of where I can place the tattoo. They were originally on a layer that I intended not to export, but then discovered they exported even when invisible, and as I subsequently learned, also export when the layer is set not to print. Useless. The entire page exports as a 1024x2048 PNG file, dimensions which the game is expecting in order for them image to render in the game (otherwise you get a default blue-red gradient texture with a giant question mark wrapped around the object). The suggested work-around won't suffice. I can't just select the content created within the boundaries of the blue square because then the dimensions of the export would be no greater than that blue square and won't work. The entire 1024x2048 image must be exported, even if most of the image consists of nothing. So, instead of using a layer--because layers are exporting regardless--before I build a tattoo, what I do is copy and paste the desired page with the location that I want beforehand, so that I have a copy of it for the next one, then delete the square and export the page, and so I always have a spare copy to burn for the next one. I might have dozens of tattoos in a single file. I'd much rather just have the visual cue (blue square) on the page all the time, and having them all in a layer that does not export would be perfect, then I could just turn the layer on containing the blue squares to place the content of the tattoo and turn that layer off when it comes time to export, rather than copy-delete-repeat. I tried using guides, rather than squares, but that resulted in a mess of lines that wound up being more confusing than anything else.
Forgot to mention that the PNG export has transparency turned on, because only the tattoo, not a field of white surrounding it, is useful (otherwise the Sim's entire body would look like it's been dipped in white paint). I could cheese the situation and place the blue squares on the master page and export with transparency and then they won't render, but I've supplied a use-case scenario https://bugs.documentfoundation.org/show_bug.cgi?id=123973 with uploaded examples where I definitely DO want master items to show up when transparency is used (but they currently do not) rather than unnecessarily having to copy the same graphic from page to page to page to get around that.
Having struggled with this 'bug' for a while I wonder whether it not just works as designed. I clarify (in all below please assume the printing is performed through export-PDF only): If 'Visible' then if 'Printable' then PRINT else NOPRINT else NOPRINT In other words: if you see it on the screen but do not want it to be printed then you de-select 'Printable' and if you do not see it on the screen then it will not be printed. [Using LibreOffice Version: 5.1.6.2 - Build ID: 1:5.1.6~rc2-0ubuntu1~xenial10]
(In reply to Jo Saels from comment #25) > Having struggled with this 'bug' for a while I wonder whether it not just > works as designed. > > I clarify (in all below please assume the printing is performed through > export-PDF only): > > If 'Visible' > then if 'Printable' > then PRINT > else NOPRINT > else NOPRINT > > In other words: if you see it on the screen but do not want it to be printed > then you de-select 'Printable' and if you do not see it on the screen then > it will not be printed. > > [Using LibreOffice Version: 5.1.6.2 - Build ID: > 1:5.1.6~rc2-0ubuntu1~xenial10] This is not the case. With PNG, and probably other graphical formats as well, all layers export regardless of their printable/visible flag. 1. Created new Draw document. 2. Created layer "x" and drew a light-blue circle on it. 3. Created layer "y" and drew a dark-blue circle on it. 4. Cleared both the print and visible options on the Y layer. 5. Exported to PNG 6. Both layers rendered on the export. Version: 7.5.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 2b4d136b65bc79a1248876160e85fab79d52d5d6 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
*** Bug 117257 has been marked as a duplicate of this bug. ***
*** Bug 134349 has been marked as a duplicate of this bug. ***