View Issue Details

IDProjectCategoryView StatusLast Update
0013421ScribusGeneralpublic2016-11-01 10:39
ReporterJehan Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version1.5.0 
Summary0013421: Margins should be always visible
DescriptionRight now margins disappear under any opaque item placed above.

Since margins are by definition there to help the designer place items, it seems counter-productive to hide it, especially since setting a background image (or shape with a color) up to the bleed limits is common.
Steps To Reproduce- Create a document with bleeds and margins.
- Create a shape which covers the whole document and goes over the margin (likely over the bleed).
- Give the shape a fill color with no transparency.

Results: while the bleed lines are still visible, the margin lines are not visible anymore.
TagsNo tags attached.
PatchNo

Relationships

related to 0014345 new add trim lines 

Activities

ale

2015-10-15 15:23

manager   ~0036671

hi jehan...

in the preferences > guides you can set how those selement are stacked...

personally, i'm comfortable with the corrent order as the default...

is that enough, or you plead for a different default?

Jehan

2015-10-15 15:37

reporter   ~0036673

It works! :-)

> is that enough, or you plead for a different default?

Well yes, I think the default would be worth changing. Here is my rational: what is the purpose of margins if they get hidden as soon as you put something there? In particular if you also need bleeds, it often means that if you have some background (image, uniform color, pattern…), it will fill the whole image, hence go over the margin.

Now of course maybe one wants to "stick" something to the margin, hence only care about the snap feature (working even with invisible margin), but even so it's still more user friendly when you can actually see the margin.

The only good reason I can see of not showing margins is that it is "inside" the printed area. But then if you want to hide guides, margins, bleeds and other "non print" elements anyway, you'd just go to the preview mode.

But maybe I miss some other good use cases for this?

ale

2015-10-19 16:44

manager   ~0036710

i don't know, in DTP most of the time the margin of the page does not seem to be as meaningful as in word processing.

basically, you can "write" anywhere and the margins are not much more than a guide with some semantics :-)

i would say that the page border should be on top by default, but i'm not sure that by default the page margins should...

ah, and the items should snap to the bleed... :-)

Jehan

2015-10-19 22:18

reporter   ~0036718

> in DTP most of the time the margin of the page does not seem to be as meaningful as in word processing.

Well many printshops would tell you to keep (when they give you the set of "rules" for the files to provide) text and other important graphics X mm from the border (which I always imagine being kind of similar reason as for the bleed: because an inaccurate crop might eat a mm or 2 inside). That's basically a margin set by the printer.
You often also want to have a margin for design reasons.

So at the contrary, I personally feel that margin is pretty important and meaningful in the publishing world.

ale

2015-10-26 06:12

manager   ~0036940

jehan, i normally don't set the page margins to the limit of the printable area and i've not seem many people doing that...

what i have mostly see is that people set the margins to frame the part of the page containing the main content.
page numbers, headers, footers, footnotes, sidenotes and many other items are outside of it.

it might be interesting to show the printable area (and be able to define it, since the target printed is mostly not the one that is connected to the computer during the layout work).
but the margin are in most cases something else.

personally, i'm for a "no change needed":

- the current situation is the right one for most people
- your use case is well covered in 1.5 (you can already put the margins on top in the preferences and scribus will use them in that way in all your future document)

Jehan

2015-10-26 14:39

reporter   ~0036946

Last edited: 2015-10-26 14:40

> jehan, i normally don't set the page margins to the limit of the printable area and i've not seem many people doing that...

I think there is misunderstanding, this is not what I said. :-)
I mean, if margin are the limit of the printable area, that basically means there are no margins, right?! Or maybe I am the one misunderstanding here.

> what i have mostly see is that people set the margins to frame the part of the page containing the main content.
> page numbers, headers, footers, footnotes, sidenotes and many other items are outside of it.

Actually that's more what I said. So we agree. And for me, this makes the margin needing to be seen (which they won't with current default as soon as you add some background color or image for instance).

> personally, i'm for a "no change needed":

Ok. This is not a big issue, now that I indeed know how to do it in the preferences. I still feel it is a bad default though. But since it is customizable (and maybe I missed something the way other people indeed used the margin), you can just close it if you want. You are the boss. ;-)

Kunda

2015-11-25 01:07

updater   ~0037658

Reminder sent to: ale

ale

2015-11-25 07:21

manager   ~0037668

i stick to the opinion that the only margins that need to stick out are the bleed margins (or page border if bleed is 0).

for most cases, page margins should not to be treated in a different way than normal guides: they are a weak reference that does not match the printable area.

with the current setting, you will have some pain when you have a solid background, but you will be a happy camper when your visuals otherwise cross that border.
all in all, i'm feeling comfortable with the status quo: an ok default for most cases (frames are on top of everything: easy to understand) and a fine grained setting that allows you to tweak the view for the specific case.

PeterBenedek

2016-10-31 13:05

developer   ~0042243

"personally, i'm for a "no change needed""

+1

Issue History

Date Modified Username Field Change
2015-10-15 13:52 Jehan New Issue
2015-10-15 15:23 ale Note Added: 0036671
2015-10-15 15:37 Jehan Note Added: 0036673
2015-10-19 16:44 ale Note Added: 0036710
2015-10-19 22:18 Jehan Note Added: 0036718
2015-10-26 06:12 ale Note Added: 0036940
2015-10-26 14:39 Jehan Note Added: 0036946
2015-10-26 14:40 Jehan Note Edited: 0036946
2015-11-25 01:07 Kunda Note Added: 0037658
2015-11-25 07:21 ale Note Added: 0037668
2016-10-31 13:05 PeterBenedek Note Added: 0042243
2016-11-01 10:39 ale Relationship added related to 0014345