View Issue Details

IDProjectCategoryView StatusLast Update
0002683ScribusGeneralpublic2016-04-09 18:45
Reporterpessoa Assigned To 
PriorityhighSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
PlatformanyOSanyOS Versionany
Product Version1.3 
Summary0002683: Margins need to be skipped for objects spanning facing pages
DescriptionWhen using facing pages the margins must be skipped for objects spanning both pages.

This means that each object must be "split" so that each part of it lies within the allowed margins on each page. This "splitting" is only visual.

Currently the object will not be split and will invade a "forbidden" are. Thus it will cut by the machine that cuts the magazine.

(I am describing a scenario where margins have to be present and to be respected due to agreements with the printer)

TagsNo tags attached.
Patch

Relationships

related to 0000129 closedfschmid Bleed functionality 
has duplicate 0003626 closedplinnell images lose information in gutter 
has duplicate 0002878 closed Gutter Elements 
related to 0013914 closedjghali Dual-Page Layout: Full-Width items duplicated on export 
related to 0010990 confirmed Object page reference incorrect at 0.000 on facing page 

Activities

pessoa

2005-10-07 00:31

reporter   ~0006945

Correction: tested with 1.3.1

ringerc

2005-10-07 03:26

reporter   ~0006950

We're hoping to tackle this during the 1.3 development series. It's been planned for a while, but I don't know if there's an existing bug entry for it off the top of my head.

mhanski

2006-04-14 14:37

developer   ~0009957

Reminder sent to: plinnell

there is no other rfe for it. "Won't fix" or "Acknowledged"?

gustavohomem

2006-04-14 17:44

reporter   ~0009964

This issue is related to

http://bugs.scribus.net/view.php?id=129

Facing pages are a major topic, and currently the workarounds for lack of inteligent bleed on facing pages are very cumbersome.

louisdesjardins

2006-04-14 20:35

developer   ~0009975

Please see my note on bug 0000129.
I don't understand what is the issue here. Sorry.

plinnell

2006-04-16 22:18

viewer   ~0010043

on the roadmap for 1.3.5

louisdesjardins

2006-04-18 14:35

developer   ~0010099

I still don't get what is the issue here. I will document more on bug 0000129.

hhielscher

2006-11-02 12:13

reporter   ~0013234

AFAICS in Scribus (at least in 1.3.3) the margins define the print space (Satzspiegel), right? ) So is this bug about bleed margins yet to be defined?

Could someone please explain what the bug is about?

cbradney

2006-11-02 12:50

administrator   ~0013236

If you place an image frame across two pages but still want to use the margins, then the second page's item needs to render having not use the area of the margins.

hfinger

2008-01-17 01:37

reporter   ~0018615

Do I understand correctly that an object/image spans a double spread but on printing the object/image that falls within the margin area is not to print and the margin area shows the paper underneath on both screen and print?

The quick answer, is why not split the object/image into two and place half on each facing page. But presumably the intention is to preserve vertical alignment between matching details on the L and R pages.

You would need to toggle this on and off per object/image because presumably you may also want an object to continue across the margin area and that portion that falls in the bleed margin to be also duplicated in the facing bleed margin for perfect binding.

Perhaps we need a detailed example. I'm not sure I understand this bug.

louisdesjardins

2008-01-17 13:32

developer   ~0018618

I am copying my own note from bug 0000129 in the hope it can be of help here. I describe the steps needed to achieve the best possible spanning effect in a
perfect binding with cutoff and glue.

* * *

Bleed with facing pages and spanning elements.

To handle bleed, XPress actually picks up the width of the defined bleed value from all 4 sides, including the one edge that belongs to the page aside. When you get the actual print, you'll see all trim marks and bleed going outside these to the exact value bleed was set. If a spanning element is on page 2 and 3, then the bleed on the right hand side of page 2 and the one on the left hand side of page 3 will be an exact overlap of the same part of the image.

This is short of what we need when perfect binding.

The issue with the spanning element and the compensation we have to make to show a picture in its entirety when in a perfectbinding is a completely different issue.

1. For this, we need the same image exactly stepped at 0,0 so you end up with 2 identical images on top of each other.

2. Then, we take the right side of the image frame and slide it to the edge of the left page.

3. We do the same with the image below but pick the left side of the frame and slide it to the edge of the right page

4. The result is you see one complete image but it is actually made of 2 image frames.

5. Then you must move those frames away from the edge of each page in order to compensate for the binding that will actually hide a zone of the image, on each page. The value that is going to be used to compensate depends on the thickness of the book and on the tightness of the binding. For the sake of this example, let's say we move away from the edge of the paper both parts of the image by a 1/4 inch.

6. Next step is to open up the image frame (image is not moving) towards the interior edge of the paper, on both pages.

7. Then, when you're going to print, with bleed, there will of course be no bleed on the interior edge. Because there are no objects that actually span on 2 pages (objects are split), the program will not invent pixels. AND nobody needs bleed there.

Again, I know no DTP program that can actually automatically do all these steps and put the right values to move away the center of the picture that would otherwise be hidden into the binding. Plus, this is no task for the imposition program. It has to be delt at object level on a case per case situation at design level. And there will always be an inherent difficulty getting the desired result because of all the other variable that cannot be controled by the designer. Nonetheless, it is possible to achieve a nice job using this technique.

I hope this long explanation is clear. :)

If anyone has come up with a better way of doing this, please say so. I must say this is how we've been doing this for many years now.

TrnsltLife

2012-03-26 23:50

reporter   ~0027866

I wrote a proof-of-concept Python script that implements louidesjardins' steps. I posted it on the Scribus wiki at: http://wiki.scribus.net/canvas/Split_Image_Across_Gutter

It would be great if something like this could be included in Scribus' main code base.

Kunda

2016-04-09 16:48

updater   ~0039973

gpittman, does that script in 0002683:0027866 work for you?

gpittman

2016-04-09 18:45

developer   ~0039981

I really don't like this solution.
What I gather from Louis is that this shouldn't be something where the Scribus user is making this kind/these kinds of decisions. The wrong approach may be worse than doing nothing from the printer's perspective.
I'll try to remember to bring this up with Louis at LGM.

Issue History

Date Modified Username Field Change
2005-10-06 23:41 pessoa New Issue
2005-10-07 00:31 pessoa Note Added: 0006945
2005-10-07 03:26 ringerc Note Added: 0006950
2006-04-14 14:31 mhanski OS Mandriva => any
2006-04-14 14:31 mhanski OS Version 2005 LE => any
2006-04-14 14:31 mhanski Platform i686 => any
2006-04-14 14:31 mhanski Product Version 1.3.2cvs => 1.3
2006-04-14 14:36 mhanski Priority normal => high
2006-04-14 14:37 mhanski Note Added: 0009957
2006-04-14 17:44 gustavohomem Note Added: 0009964
2006-04-14 17:47 mhanski Relationship added related to 0000129
2006-04-14 19:14 mhanski Relationship added related to 0002878
2006-04-14 20:35 louisdesjardins Note Added: 0009975
2006-04-16 22:18 plinnell Note Added: 0010043
2006-04-16 22:18 plinnell Status new => acknowledged
2006-04-16 22:19 plinnell Relationship added has duplicate 0003626
2006-04-18 14:35 louisdesjardins Note Added: 0010099
2006-04-29 20:34 mhanski Relationship deleted related to 0002878
2006-04-29 20:34 mhanski Relationship added has duplicate 0002878
2006-11-02 12:13 hhielscher Note Added: 0013234
2006-11-02 12:50 cbradney Note Added: 0013236
2008-01-17 01:37 hfinger Note Added: 0018615
2008-01-17 13:32 louisdesjardins Note Added: 0018618
2012-03-26 23:50 TrnsltLife Note Added: 0027866
2016-04-05 22:27 Kunda Relationship added related to 0013914
2016-04-05 22:27 Kunda Relationship added related to 0010990
2016-04-09 16:48 Kunda Note Added: 0039973
2016-04-09 18:45 gpittman Note Added: 0039981