View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002683 | Scribus | General | public | 2005-10-06 23:41 | 2016-04-09 18:45 |
| Reporter | pessoa | Assigned To | |||
| Priority | high | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | any | OS | any | OS Version | any |
| Product Version | 1.3 | ||||
| Summary | 0002683: Margins need to be skipped for objects spanning facing pages | ||||
| Description | When 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) | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
| related to | 0000129 | closed | fschmid | Bleed functionality |
| has duplicate | 0003626 | closed | images lose information in gutter | |
| has duplicate | 0002878 | closed | Gutter Elements | |
| related to | 0013914 | closed | jghali | Dual-Page Layout: Full-Width items duplicated on export |
| related to | 0010990 | confirmed | Object page reference incorrect at 0.000 on facing page |
|
|
Correction: tested with 1.3.1 |
|
|
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. |
|
|
Reminder sent to: there is no other rfe for it. "Won't fix" or "Acknowledged"? |
|
|
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. |
|
|
Please see my note on bug 0000129. I don't understand what is the issue here. Sorry. |
|
|
on the roadmap for 1.3.5 |
|
|
I still don't get what is the issue here. I will document more on bug 0000129. |
|
|
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? |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
gpittman, does that script in 0002683:0027866 work for you? |
|
|
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. |
| 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 |
|
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 |
|
Note Added: 0010043 | |
| 2006-04-16 22:18 |
|
Status | new => acknowledged |
| 2006-04-16 22:19 |
|
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 |
