View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000129 | Scribus | Printing | public | 2004-01-08 23:54 | 2006-12-10 00:49 |
| Reporter | cbradney | Assigned To | fschmid | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.3 | ||||
| Fixed in Version | 1.3.4cvs | ||||
| Summary | 0000129: Bleed functionality | ||||
| Description | Request for bleed functionality | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
| has duplicate | 0002686 | closed | QXP like bleed feature | |
| has duplicate | 0001115 | closed | Large document helper | |
| has duplicate | 0003692 | closed | Can we have margin and Bleed | |
| related to | 0002683 | acknowledged | Margins need to be skipped for objects spanning facing pages | |
| related to | 0003837 | acknowledged | Metabug: Master pages/Page templates |
|
|
moving to 1.3+ might be able to implement this via the scripter as short term solution..will ask sjc about this |
|
|
On the roadmap for 1.3.6. |
|
|
In the meantime, here are real life workarounds for bleed: (Please note crop marks are not an absolute necessity. If you can provide a dummy showing what you expect, your printer will very likely be able to achieve the same on the trimmer. Make sure the elements that are intended to "bleed" are at least fit kiss with the very edge of the page.) 1. Have your document trimmed 1/16 of an inch (or even less, if possible) shorter than its real size. 2. Enlarge at print (say 102%) and trim. 3. Make the whole layout fit into a larger page and add manual crop marks (put them on a template to save time with multiple page documents). These are workarounds. This is not to say bleed support is not important! |
|
|
Reminder sent to: louisdesjardins Please take a look at this wiki article and add more stuff, if needed: wiki.scribus.net/index.php/Bleed_workarounds |
|
|
Great! Thanks for putting this on the wiki. I think it's a better place for such information. :) |
|
|
http://bugs.scribus.net/view.php?id=2686 also requested this. |
|
|
A note: None of the workaround works if you use objects spanning facing pages. In that case the spanning objects will touch the page boundary, unless bleed is implemented (or margin skipping as requested on 0002683). |
|
|
>> In that case the spanning objects will touch the page boundary We don't need bleed on the interior margins. Bleed is for the cut-off. Interior margin actually touches the interior margin of the next page, so no bleed there. Actually, a magazine is trimmed on 3 sides. If you lay out a document as a whole lot of single pages and you don't work using spanning mode, you will get bleed on all four sides of each page. But the bleed on the interior sides will be taken away in the imposition process anyway. I am sorry but I don't understand your point. |
|
|
>We don't need bleed on the interior margins. Bleed is for the cut-off. Interior >margin actually touches the interior margin of the next page, so no bleed there. >Actually, a magazine is trimmed on 3 sides. What follows is what I was told by both the DTP people and the press guys: "If the magazine uses objects that span facing pages, before the trimming process part of the spanning object must be repeated for each of the pages. This is to compensate for cutting errors, since cutting precision is "finite"." What I understand from this is: Imagine page A and page B, are facing pages on a document for which margins are 3mm on all sides. Then place a picture spanning both pages and generate a PDF. http://people.angulosolido.pt/~gustavo/scribus/teste.pdf What happens if you cut 3mm on each side? - 6mm of the page are lost What happens if we don't use margins on the interior sides? - For page A any cutting imprecision towards the outside of the page will mean either a white strip (if pages were not imposed) or a strip made of "whatever" was imposed next to the page (page A and page B are facing pages but they will not be necessarily imposed side by side), say page C. Since page A will be facing page B, not page C, after the pages are ordered and glued, it is not OK t have it contaminated by the contents of page C. What happens if we use a 3mm margin also in the interior sides and scribus generates a PDF on which the last 3mm of page A are the first 3mm of page B, and the first 3mm of page B are the last 3mm of page A? - Then under the scenario described above page A will be slightly contaminated by the beggining of page B, whose first 3mm are the last 3mm of page A so the visual impact is lower. Quark has this feature, but to do this with scribus we must copy+paste+displace+resize+group the spanning image. http://people.angulosolido.pt/~gustavo/scribus/test-bleed.pdf If the object is not an image it gets complicated/impossible. I realise that this only makes sense for magazines on which pages are glued. For folded magazines pages should be imposed as they are folded, there should be no interior margins and page should be cut to the size of the page pairs. Anyway, on the site where we plan to roll-out scribus, this is the standard process for all magazines: deliver single page PDFs with bleed margins generated as explained above. Imposition is done on the print shop. May be good, bad, wrong, right, suboptimal (for sure), etc, but it is already hard to switch the software. Changing (even if improving) the process is impossible ATM, and people see the lack of this feature as downside of scribus. More comments on this are welcome! |
|
|
Bleed is a must. That, we know for sure. The workarounds are only workarounds and although they work we have to have bleed on board anyway. We all agree on this! I understand what you say. And the pdf files you provide are clear. What I want to mention is there is no bleed on the interior because no part of the sheet will be cut off in the trimming process in that particular case. A fold will be there instead. It doesn't matter wether it's going to be saddlestiched as a magazine or perfectbinded as a book. If it is saddlestiched, there will actually be only a fold. The one thing that can happen at this stage is a bad fold will make a part of a page appear on another... but this is folding issue, not bleed issue. If it's perfectbinding (like ordinary books, soft cover) then the press sheet are folded as well but that fold, depending on the binding machine, will be kept as it is and glued (or sewed) or it can be cut and even "crushed" so the glue will deeply penetrate the fibers of the paper. Bleed is not an issue here as well. Margins could be an issue though, if the image is too close to the fold, because the glue can easily use between 1/8 and 1/4 inch... So one must realize part of the image can disappear in the fold. If you cut 3mm it will not be on each side. It will be on the 3 sides that are not binded. There has to be a side that is not trimmed otherwise this is not binding (whatever binding it is). I understand it is clumsy to achieve what you want the way Scribus is at the moment. But imo it is perfectly feasible at the expense of a little time to set the crop marks on a larger page that can hold your finished page. Put this on a Master Page and you'll be on your way. Really, it will take a few minutes to achieve that. Spanning element, be it a picture, can be done also easily. You only have to duplicate the element at 0,0 coordinates and then resize the image frame itself to the edge of the page and do the same on the other page. If you want to make it bleed, then go ahead. What I am saying is this interior bleed will go away a imposition. >> Anyway, on the site where we plan to roll-out scribus, this is the standard process for all magazines: deliver single page PDFs with bleed margins generated as explained above. Imposition is done on the print shop. This is how we handle jobs as well. For that reason, I suggest you use the Master Page technique. HTH Louis |
|
|
On the practical side: - it is perfectly ok to use a master page with margins and crop marks instead of "bleed" if there are no spanning objects. This is really NOT a problem. The problem comes with spanning objects only! - delivering PDFs with the inner margins filled as in: http://people.angulosolido.pt/~gustavo/scribus/test-bleed.pdf is a requisite from the press. Good or bad, there's no way to change this so we must find an effective way to do it. Thus could be via "Quark like bleed" or "margin skipping". So this is the scenario we have to live with. Regarding the theoretical side: >If you want to make it bleed, then go ahead. What I am saying is this interior >bleed will go away a imposition. If you are right, then I was told wrong. I was told there would be a cut between the pages. Why would they ask it this way then? If what you say is right, it would be irrelevant whether the contents of the interior margins are black, white, pink, etc... |
|
|
At this point, I guess you could ask them to join in the discussion. I don't want to make an argument wether they are right or wrong asking this. I know how XPress handles this. And they must expect what they are used to. All I am saying is there is no need for bleed on the binding edge for all the reasons I gave! Of course, the programs don't know about this so it is by far preferable to have bleed on all sides to cover all other cases where this is very important. And this is how DTP apps handle the case. They put bleed on all sides. I agree it is clumsy to make a spanning element using the method I propose but it is nonetheless going to work, provided the right measurements are there. And there is currently no other way to do that in Scribus. And your printer should not complain because what you are going to give him is very close to exactly what he expects! Only the marks will be done by hand instead of being put automatically by the program. Bleed will have to be taken care of manually, no matter the program. (I mean, you have to offset the image from the trim marks, the program doesn't do that nor does it invent pixels or element to make them bleed off the page.) The imposition program should have no problem handling this, imo. |
|
|
Louis, I think you are right, for folding-only scenarios. For those cases the interior margins will go away with imposition (it would have to be this way, or the pages would not have the announced size, but the size + 2 * margin). However I think the demand applies for perfect binding: http://eckhartandco.com/html/HH-0402BB.html The 3mm demand is nearly 1/8 inch. Using "white margins" instead of "interior bleed" would result in visible white strips. However only one of their mags is perfectly binded. |
|
|
The perfect binding issue is something that has more to do with margins than bleed, imo. It is a matter of compensating for the tightness of the binding and thus for the amount of the page that will disappear in the binding itself. It is somehow the same problem as bleed but the way around. Instead of having to deal with part of the image that is cut-off, we have to deal with image that is "cut-in" if you allow me the expression! |
|
|
But even if margins are correctly calculated, things won't look good if they are white / bg colour. You will see more or less of the margins depending on the pressure you put on the book/mag. Having the margins filled as in: http://people.angulosolido.pt/~gustavo/scribus/test-bleed.pdf atenuates the visual impact. Doesn't matter whether or not we call it "bleed" :-) |
|
|
Again, what I mean is the perfectbinding issue of a picture (most of the cases) spanning two pages is not a "bleed" issue as such. Nonetheless, it is an issue, I agree. Would Scribus support bleed, one would still have to be cautious with the design and image position to compensate for that kind of binding (and moreover, actually any binding has its own requirements and limitations). This has to be discussed with the people that actually do the binding. And of course there will always be an "margin of error". Unless the image falls into a "true spread"(*) AND the book is sown so it can open up to the fold, and no matter how well-done is the binding there will always be a possibility that the picture misaligns, or overlaps, or is too far appart (without even showing a white gap, btw), all cases happening because we are trying to collate together 2 parts of an image on 2 pages... and these are not pixels, it's a physical world! :) The perfectbinding spanning issue is very different from the saddlestich binding, as I mentionned before. I don't know just how "intelligent" the "bleed" function could be made to handle such situations (that is, actually offsetting the spanning image on each page it spans on to compensate for the binding, thus knowing the binding "security margin" so it can be customized for any given case). AFAIK, XPress can't. The bleed function is basic. Again, this seems to me more an issue of design and, "maybe" imposition. But I am not sure wether we can deal with this in the imposition process. Actually, the margins of the page don't have to move. Only the spanning object has to. Otherwise, it's the whole page that's going to suffer, and the layout. So it's a "per object" adjustment and not a "per page" adjustement. I am not aware of any program capable of doing such a fine tuning automatically. Human input is necessary, imo. (*) A "true spread" is made of two consecutive pages that are in the middle of a signature, that is, separated by a fold. So basically, in a 8-pager, pages 4-5 are a true spread but 2-3 and 6-7 are not. I hope the explanation is clear. Would be clearer with a hard-copy example!) And again, we all agree bleed is an absolute need. :) |
|
|
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. |
|
|
Louis, please review your comments and place specific requests into a new bug or two. This one is now closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-01-08 23:54 | cbradney | New Issue | |
| 2004-01-09 00:03 | cbradney | Category | Documentation => Printing |
| 2004-01-29 14:16 |
|
Note Added: 0000379 | |
| 2004-01-29 14:16 |
|
Product Version | => 1.3 |
| 2005-06-23 07:28 |
|
Note Added: 0005099 | |
| 2005-06-23 07:28 |
|
Status | new => confirmed |
| 2005-06-23 18:36 | louisdesjardins | Note Added: 0005104 | |
| 2005-06-24 08:04 | mhanski | Note Added: 0005110 | |
| 2005-06-24 08:04 | mhanski | Note Edited: 0005110 | |
| 2005-06-24 08:06 | mhanski | Note Edited: 0005110 | |
| 2005-06-24 10:27 | louisdesjardins | Note Added: 0005112 | |
| 2005-10-07 03:24 |
|
Relationship added | has duplicate 0002686 |
| 2005-10-07 07:29 | pessoa | Note Added: 0006951 | |
| 2005-10-07 08:57 | ghomem | Note Added: 0006952 | |
| 2006-02-07 21:25 |
|
Relationship added | has duplicate 0001115 |
| 2006-04-14 17:47 | mhanski | Relationship added | related to 0002683 |
| 2006-04-14 19:29 | louisdesjardins | Note Added: 0009967 | |
| 2006-04-14 21:10 | gustavohomem | Note Added: 0009978 | |
| 2006-04-14 22:13 | louisdesjardins | Note Added: 0009985 | |
| 2006-04-14 22:14 | louisdesjardins | Note Edited: 0009985 | |
| 2006-04-14 22:54 | gustavohomem | Note Added: 0009987 | |
| 2006-04-14 23:30 | louisdesjardins | Note Added: 0009991 | |
| 2006-04-14 23:53 | gustavohomem | Note Added: 0009992 | |
| 2006-04-15 03:49 | louisdesjardins | Note Added: 0009996 | |
| 2006-04-17 10:42 | gustavohomem | Note Added: 0010054 | |
| 2006-04-17 13:36 | louisdesjardins | Note Added: 0010061 | |
| 2006-04-18 15:32 | louisdesjardins | Note Added: 0010100 | |
| 2006-04-23 08:47 | mhanski | Relationship added | has duplicate 0003692 |
| 2006-05-18 18:21 | christoph_s | Relationship added | related to 0003837 |
| 2006-11-09 12:45 | fschmid | Status | confirmed => assigned |
| 2006-11-09 12:45 | fschmid | Assigned To | => fschmid |
| 2006-11-12 09:59 | fschmid | Status | assigned => resolved |
| 2006-11-12 09:59 | fschmid | Fixed in Version | => 1.3.4cvs |
| 2006-11-12 09:59 | fschmid | Resolution | open => fixed |
| 2006-12-10 00:48 | cbradney | Status | resolved => closed |
| 2006-12-10 00:48 | cbradney | Note Added: 0013849 |
