Mantis Issue Tracking for Scribus
· Hosting provided by / Øverby Consulting ·

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002683ScribusGeneralpublic2005-10-07 01:412012-03-27 10:35
Assigned To 
PlatformanyOSanyOS Versionany
Product Version1.3 
Target VersionFixed in Version 
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.
Attached Files

- Relationships
related to 0000129closedfschmid Bleed functionality 
has duplicate 0003626closedplinnell images lose information in gutter 
has duplicate 0002878closed Gutter Elements 

-  Notes
pessoa (reporter)
2005-10-07 02:31

Correction: tested with 1.3.1
ringerc (administrator)
2005-10-07 05:26

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 (developer)
2006-04-14 16:37

Reminder sent to: plinnell

there is no other rfe for it. "Won't fix" or "Acknowledged"?
gustavohomem (reporter)
2006-04-14 19:44

This issue is related to [^]

Facing pages are a major topic, and currently the workarounds for lack of inteligent bleed on facing pages are very cumbersome.
louisdesjardins (developer)
2006-04-14 22:35

Please see my note on bug 0000129.
I don't understand what is the issue here. Sorry.
plinnell (administrator)
2006-04-17 00:18

on the roadmap for 1.3.5
louisdesjardins (developer)
2006-04-18 16:35

I still don't get what is the issue here. I will document more on bug 0000129.
hhielscher (reporter)
2006-11-02 13:13

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 (administrator)
2006-11-02 13:50

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 (reporter)
2008-01-17 02:37

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 (developer)
2008-01-17 14:32

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 (reporter)
2012-03-27 01:50

I wrote a proof-of-concept Python script that implements louidesjardins' steps. I posted it on the Scribus wiki at: [^]

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

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

Copyright © 2000 - 2015 MantisBT Team
Powered by Mantis Bugtracker