Bug 53864 - Export ignores layer options 'printable' and 'visible'
Summary: Export ignores layer options 'printable' and 'visible'
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 72117 117257 134349 146268 149900 (view as bug list)
Depends on:
Blocks: Layers Graphics-Export SVG-Save
  Show dependency treegraph
 
Reported: 2012-08-21 05:37 UTC by Rainer Bielefeld Retired
Modified: 2024-10-21 22:53 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:


Attachments
Test Kit (119.14 KB, application/x-7z-compressed)
2012-08-21 05:37 UTC, Rainer Bielefeld Retired
Details
Improved testkit showing how layer information is ignored during export. (592.33 KB, application/zip)
2013-12-21 06:31 UTC, Owen Genat (retired)
Details
Test case (356.70 KB, application/gzip)
2016-08-12 23:40 UTC, Luc Novales
Details
Sample file where the output dimensions must never change (10.47 KB, application/vnd.oasis.opendocument.graphics)
2022-07-10 17:20 UTC, xordevoreaux
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-08-21 05:37:36 UTC
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.
Comment 1 Hashem Masoud 2012-10-11 08:18:51 UTC
(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.
Comment 2 Owen Genat (retired) 2013-12-21 06:31:02 UTC
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).
Comment 3 Owen Genat (retired) 2013-12-21 06:34:59 UTC
As per comment #2, Platform set to All/All. "SVG" removed from summary for clarity.
Comment 4 Owen Genat (retired) 2013-12-21 06:35:37 UTC
*** Bug 72117 has been marked as a duplicate of this bug. ***
Comment 5 crxssi 2014-11-28 21:49:36 UTC
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.
Comment 6 QA Administrators 2015-12-20 16:05:49 UTC Comment hidden (obsolete)
Comment 7 Luc Novales 2016-08-12 23:40:50 UTC
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.
Comment 8 Luc Novales 2016-08-12 23:44:44 UTC
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
Comment 9 Regina Henschel 2018-04-08 09:17:17 UTC
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.
Comment 10 Wolfgang Jäger 2019-03-27 11:47:55 UTC Comment hidden (no-value)
Comment 11 crxssi 2019-03-27 21:38:27 UTC Comment hidden (obsolete)
Comment 12 Wolfgang Jäger 2019-03-28 01:10:07 UTC Comment hidden (obsolete)
Comment 13 furniturescam 2019-08-07 08:39:44 UTC Comment hidden (spam)
Comment 14 Stephan van den Akker 2020-02-02 12:25:37 UTC
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
Comment 15 SEO Backlinks 2021-03-09 13:47:42 UTC Comment hidden (spam)
Comment 16 Regina Henschel 2021-12-17 00:54:15 UTC
*** Bug 146268 has been marked as a duplicate of this bug. ***
Comment 17 Regina Henschel 2022-07-10 00:11:25 UTC
*** Bug 149900 has been marked as a duplicate of this bug. ***
Comment 18 xordevoreaux 2022-07-10 14:42:39 UTC
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
Comment 19 xordevoreaux 2022-07-10 14:44:52 UTC
I can't believe this bug has been around since 2012. 
Were I a decent programmer I'd tackle it myself.
Comment 20 crxssi 2022-07-10 15:02:30 UTC
(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.
Comment 21 Regina Henschel 2022-07-10 15:28:16 UTC
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.
Comment 22 xordevoreaux 2022-07-10 16:39:44 UTC
(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.
Comment 23 xordevoreaux 2022-07-10 17:20:47 UTC
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.
Comment 24 xordevoreaux 2022-07-10 17:34:54 UTC
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.
Comment 25 Jo Saels 2022-12-09 10:13:37 UTC
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]
Comment 26 xordevoreaux 2022-12-09 17:32:22 UTC
(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
Comment 27 Stéphane Guillou (stragu) 2023-11-06 11:23:43 UTC
*** Bug 117257 has been marked as a duplicate of this bug. ***
Comment 28 Stéphane Guillou (stragu) 2023-11-06 11:24:14 UTC
*** Bug 134349 has been marked as a duplicate of this bug. ***
Comment 29 Justin L 2024-10-21 22:53:45 UTC
The key code location for this bug is svx/source/svdraw/svdpagv.cxx
    // For example, in the case of charts, there is a LayerAdmin,
    // but it has no valid values. Therefore
    // a solution like pLayerAdmin->getVisibleLayersODF(aLayerVisi)
    // is not possible. So use the generic SetAll() for now.
    m_aLayerVisi.SetAll();
which sets all the layers to visible for this SdrPageView.

A red herring (probably) was in svx/source/unodraw/UnoGraphicExporter.cxx
      ImplExportCheckVisisbilityRedirector aRedirector( mpCurrentPage );
except that mpCurrentPage is nullptr, but even if filled with the current page it didn't solve anything.
  SdrPage* pVisibilityPage = mpCurrentPage;
  if (!pVisibilityPage && mxPage.is())
      SvxDrawPage* pUnoPage = comphelper::getFromUnoTunnel<SvxDrawPage>(mxPage);
        if (pUnoPage)
            pVisibilityPage = pUnoPage->GetSdrPage();

svx/source/svdraw/sdrpagewindow.cxx RedrawAll basically does the right thing
    SdrLayerIDSet aProcessLayers
         = bPrinter ? mpImpl->mrPageView.GetPrintableLayers()
                    : mpImpl->mrPageView.GetVisibleLayers();
except that GetVisibleLayers ignores all of the stuff in parent layers which looks like a massive fundamental issue.