JimWelch Posted August 2, 2019 Share Posted August 2, 2019 Bleed Inner 0 Outer 0.125 Top 0.125 Bottom 0.125 When exporting to PDF, the inner edges look all screwed up. It's taking graphics from right side inner and putting it in left side inner and graphics from left side into right side. Just place an image on right page to the inner edge and export to PDF, then look at the left page and right page. Quote Link to comment Share on other sites More sharing options...
JimWelch Posted August 2, 2019 Author Share Posted August 2, 2019 For anyone searching for a fix, I can't find a fix in Publisher. Since I urgently need this for printer, here's what I did. I bought Acrobat Pro DC. This is exactly why I wanted to buy Affinity - to avoid buying Adobe CC, but I had no choice. Export to PDF with spreads with bleed on Copy the PDF so there's 2 of the same file Open 1 PDF in Acrobat Go to Organize Pages Insert the pages of 2nd PDF after the pages of the first file Move all of the 2nd file spreads to after its corresponding 1st file spreads (so 1-1-2-2-3-3-4-4-5-5 etc) Go to Edit Select Crop In Crop window: select page range to "ALL" , select "ODD" pages, enter RIGHT "8.625" (whatever page + bleed is), click submit In Crop window: select page range to "ALL" , select "EVEN", enter LEFT "8.625" (whatever page + bleed is), click submit You'll end up with a perfect 0 inner bleed, because you're cutting the spreads in half. Quote Link to comment Share on other sites More sharing options...
kirknurse Posted August 3, 2019 Share Posted August 3, 2019 I am curious as to why you needed to do that as most printers imposition software does that automatically. Quote Link to comment Share on other sites More sharing options...
MikeW Posted August 3, 2019 Share Posted August 3, 2019 2 hours ago, kirknurse said: I am curious as to why you needed to do that as most printers imposition software does that automatically. Some POD print establishments require zero inside bleed. Some even require a blank area at the spine for perfect bound binding. These requirements are due to their automated processes. JimWelch 1 Quote Link to comment Share on other sites More sharing options...
JimWelch Posted August 3, 2019 Author Share Posted August 3, 2019 Yes. My printer requires this. https://onebookshelfpublisherservice.zendesk.com/hc/en-us/articles/360022104293-Quick-Specifications-for-Print-Books Quote BLEED: All books need a .125" bleed space on the three outside trim edges. Do NOT add bleed the the inside bind (gutter) side. Quote Link to comment Share on other sites More sharing options...
Staff Gabe Posted August 23, 2019 Staff Share Posted August 23, 2019 Hi all, Sorry for the delayed reply. Can you still reproduce this in the latest 1.7.2 build? If so, please attach a project file so we can log it with our developers. Thanks, Gabe. JimWelch 1 Quote Link to comment Share on other sites More sharing options...
JimWelch Posted August 23, 2019 Author Share Posted August 23, 2019 Same problem as before. I'll send to DropBox. Thanks Quote Link to comment Share on other sites More sharing options...
Staff Gabe Posted August 23, 2019 Staff Share Posted August 23, 2019 You can use this link: https://www.dropbox.com/request/LBUCuPiCrbQJy7a0WG1V Quote Link to comment Share on other sites More sharing options...
JimWelch Posted August 23, 2019 Author Share Posted August 23, 2019 Steps to repeat: Export to PDF Select "All Pages" Enter "2-3" (thats the only spread, I deleted all others to reduce file size) Then look at the gutter of the 2 page PDF to see the problem. I included the exported PDF, so you can look there to see the problem before jumping into testing it. Quote Link to comment Share on other sites More sharing options...
Staff Gabe Posted August 27, 2019 Staff Share Posted August 27, 2019 Thanks. I've logged it with our developers Quote Link to comment Share on other sites More sharing options...
Huub Posted August 27, 2019 Share Posted August 27, 2019 I experience exact the same problem with the latest release. Quote Link to comment Share on other sites More sharing options...
petrpastor Posted August 27, 2019 Share Posted August 27, 2019 (edited) N-up print Bleed does not account for top and left edges of the document. attached are 2 files with 45 by 25 mm lablel with 5 mm bleed. one is cteated as an 5mm oversized label and the other is normal size with 5mm bleed set in AFPUB. I have printed them to pdf with n-up print so you can compare difference. I attached as well print profiles for printing. -pp- p.s. It all boils down to math. When you set up the bleed . top left corner of the bleed area is negative value of the bleed e.g. If you bleed is 3mm top left corner of the bleed area will be -3mm, -3mm. Oversize_Label_Bleed.pdf APUB_Bleed.pdf 5mm_Bleed_Test_2.profile 5mm_Bleed_Test_1.profile Oversize_Label_Bleed.afpub APUB_Bleed.afpub Edited August 27, 2019 by petrpastor Added text Quote Link to comment Share on other sites More sharing options...
lacerto Posted August 27, 2019 Share Posted August 27, 2019 (...) Quote Link to comment Share on other sites More sharing options...
lacerto Posted August 27, 2019 Share Posted August 27, 2019 (...) Quote Link to comment Share on other sites More sharing options...
petrpastor Posted August 28, 2019 Share Posted August 28, 2019 I was confused at first with the bleed arrangement. but I think it is right. In the case of labels In the print profile for N-up you just specify top and left offset as the true value from the the label template, then you subtract twice the value of bleed from the gaps between the labels. In the case of creating bleed area by enlarging the label physical dimension by a value of the bleed your top left corner is 0,0 offset then you have to subtract the bleed offset from top and left by the value of the bleed in your print profile to get the same resulting positioning. I think using the bleed in AP is the right way to do it. I did not try the case with bleed reaching over the set printable area or set margins, but i think in may get trimmed at the margin. -pp- Quote Link to comment Share on other sites More sharing options...
Siana Posted March 10, 2021 Share Posted March 10, 2021 I had this bug too on Publisher 1.9.1 on MacOS HighSierra 10.13.6. Exporting all pages of a doublie sided document to PDF leads to incorrect filling of automatic bleeds in the inner borders. Though I must say it is not too bad since these inner borders will be glued together anyway and the possible unclean border that might happen after trimming will ot be visible. See attachment. But still, would be nice to fix this. Quote Link to comment Share on other sites More sharing options...
Felipe FM Posted May 4, 2022 Share Posted May 4, 2022 On 8/27/2019 at 5:11 AM, Gabe said: Thanks. I've logged it with our developers I still have this issue too (Affinity Publisher 1.10.5, Mac) Quote Link to comment Share on other sites More sharing options...
PixelEngineer Posted May 5, 2022 Share Posted May 5, 2022 On 3/10/2021 at 2:52 AM, Siana said: I had this bug too on Publisher 1.9.1 on MacOS HighSierra 10.13.6. Exporting all pages of a doublie sided document to PDF leads to incorrect filling of automatic bleeds in the inner borders. Though I must say it is not too bad since these inner borders will be glued together anyway and the possible unclean border that might happen after trimming will ot be visible. See attachment. But still, would be nice to fix this. Did anyone try sending the result to a print shop. I do find that sometimes it takes a while for some to understand the the many various aspects of setting bleeds on a spread vs. individual pages, it certainly took me some time initially as obvious as it may seem, there are many interesting aspects and creative methods that can be used for bleed. The following link for example shows the very same behavior in Adobe InDesign. Therefore I do not believe that this is a bug exclusive to Affinity Publisher but a feature that is working the way its supposed to despite what you are seeing as contrary to what you would expect the program to do in your mind. I would read the article perhaps the developers can chime in on this. I am finding lots of working features that are being mistaken for bugs when they are not. Perhaps you may find this useful. It certainly "reflects" no pun intended the snapshots that Siana posted. The article explains it pretty why this is so and will hopefully clarify what is happening by design. https://support.bookbaby.com/hc/en-us/articles/115012579667-InDesign-center-bleed Quote Link to comment Share on other sites More sharing options...
PixelEngineer Posted May 5, 2022 Share Posted May 5, 2022 On 8/27/2019 at 4:11 AM, Gabe said: Thanks. I've logged it with our developers Hi Gabe: I don't believe that this is a bug at all. The same behavior occurs in Adobe InDesign. Read explanation on the website. The following link for example shows the very same behavior in Adobe InDesign. Therefore I do not believe that this is a bug exclusive to Affinity Publisher but a feature that is working the way its supposed to despite what you are seeing as contrary to what you would expect the program to do in your mind. The article shows the same characteristics as Siana's snapshots. I am working on the Windows machine. Based on the article the feature exist due to the way books are bound and is the way the program is supposed to work. For spreads that is. https://support.bookbaby.com/hc/en-us/articles/115012579667-InDesign-center-bleed Quote Link to comment Share on other sites More sharing options...
Felipe FM Posted July 8, 2022 Share Posted July 8, 2022 This surely is a bug. Bleed must always follow the page artwork. Otherwise it’s useless. Just because InDesign has the same bug it doesn’t mean it isn’t a bug. It still needs to be fixed. Let’s be better than InDesign. Cheers! Quote Link to comment Share on other sites More sharing options...
PixelEngineer Posted July 12, 2022 Share Posted July 12, 2022 ... Quote Link to comment Share on other sites More sharing options...
PixelEngineer Posted July 13, 2022 Share Posted July 13, 2022 On 8/27/2019 at 4:11 AM, Gabe said: Thanks. I've logged it with our developers Observation I made regarding JimWelsh situation and the solution.The answer to the original problem enter 0 for inner bleed value in the bleed settings dialog box. Before reading below, you can read about the automated feature description in the following link, which confirms that this is a feature built into the program that works the way developers intended. Affinity Publisher and InDesign incorporate this useful undocumented feature and it is NOT a bug.https://support.bookbaby.com/hc/en-us/articles/115012579667-InDesign-center-bleed Wanted to reiterate that my findings suggest this is NOT a bug. There are several other enterprise products out there that employ techniques such as this.This is a feature built into the program that fills inner bleeds that are greater than zero for spreads on PDF output and it works. Affinity Publisher is working but the user made an error. Explanation below. The link I provided earlier should be read in its entirety. You may need to read it a couple of times to understand the mechanics of the procedure until it sinks in if you truly want to understand what it is actually doing. It looks confusing at first but it will come to you if you focus hard enough.Summary of JimWelsh situation:His project included a couple of spreads and possibly graphics that covered full single pages. The printer that he was working with requested that the job be submitted with zero inner bleed. My findings suggest: User error and that the application is working fine. Although bleed settings were posted in the beginning of this thread it was never entered in the dialog box. An important point that the person reading the problem needs to understand is that, although the user posted the bleed requirements in the begining of this thread, it doesn't mean that he actually entered zero value for the inner bleed in the dialog box. The user never set zero inner bleed in the first place, and probably thought he did. While thinking he entered a value of zero for the inner bleed, it is highly probable that the user misinterpreted the facing pages view as having a zero inner bleed simply by looking at the spread itself in the interface, which would be an incorrect assumption. If he entered zero for inner bleed, he wouldn't have gotten the result he did. He could've fixed this very quickly by going back into the document and setting the inner bleed to zero in the bleed settings dialog box. Then all he would've needed to do was export the document again and would've been good to go in no time. He didn't have to go through all of that trouble the answer was so simple. Affinity already has this capability. What he experienced is actually a clever feature built into the program that automates the fill within the inner bleed zone when value of inner bleed is greater than zero for entire document that contains a spread upon export to all pages in PDF format. It does a calculation if there is an inner bleed with a value greater than zero to ensure a smooth transition of the designer's intent of the spread. If this featue did not exist you would have an empty inner bleed throughout the document while exporting in that state. Instead this feature does the work for you. Not knowing about this feature looks like a bug when you don't understand what its doing. I believe that many printers requests inner bleed set to zero to avoid confusion for their operators when reading documents that are exported from both InDesign and Affinity Publisher that use this feature. Setting zero inner bleed results in a PDF output where you will not see the bleed regions reflecting each other within the inner bleed zone, while satisfying the requirements for bleed conditions being met. In this case zero inner bleed. It appears to be user error. User did not enter zero bleed value in the dialog box. In addition any user could've compounded the issue by assuming that inner bleed was set to zero when looking at the document in facing pages view instead of confirming the settings in the bleed dialog box. The urgency to get the document out to the printer is another factor that I am sure came into play. Also Regarding Siana's snapshot. Having this knowledge, you will now know that Siana's project was exported from facing pages view to all pages export option with an inner bleed that had a value greater than zero. And that it was exported from spread view to all pages output. An automated process filled the inner bleed according to spec generated it under the conditions I mentioned earlier. Note that Siana didn't mention any problems with the final product. If that was not Siana's design intent, the best practice would be setting up the document with facing pages unchecked adjust the artwork and the exporting the entire or partial document to pdf only from that mode while communicating desired output with the printshop. Many users get confused because they don't understand the technology and concept. This is understandable. And I do understand that it seems to go against some basic principles regarding bleeds for a spread vs a single page when exporting from a single document. There quick workarounds for this that can be incorporated to the workflow. For the programmer it is pretty challenging as you are working between automation and designers intent around the programs object model and interface where designers still need to have flexiblity to be creative while using the program. Again this should not be in the bug section because it isn't. The program does was the user thought it couldn't do. No fix or workaround was needed to begin with. Yes, future design for improved automation can be designed, but this is technically NOT a bug, it is a feature with an important purpose.The answer to the original problem enter 0 for inner bleed value in the bleed settings and check your work. As a result I am recommending that this be removed from bug status for review. Quote Link to comment Share on other sites More sharing options...
Customer Feedback Posted July 13, 2022 Share Posted July 13, 2022 On 8/27/2019 at 10:11 AM, Gabe said: Thanks. I've logged it with our developers 2019. That was years ago. It would be interesting to get a status on the time horizon for a fix. Or what stands in the way. Quote Link to comment Share on other sites More sharing options...
PixelEngineer Posted July 13, 2022 Share Posted July 13, 2022 2 hours ago, Customer Feedback said: 2019. That was years ago. It would be interesting to get a status on the time horizon for a fix. Or what stands in the way. I am recommending that this should be removed from bug status because it is a feature not a bug and there is a solution. The problem was user didn't enter the correct values. The program is able to create zero inner bleed just fine, its just that the user made a mistake by not actually entering the proper values and didn't know about the "undocumented" feature and what it meant when he forgot to enter the value. If the developers read the posted link and what my findings they will see it. Thanks. Best regards Quote Link to comment Share on other sites More sharing options...
Staff Gabe Posted July 13, 2022 Staff Share Posted July 13, 2022 Back in 2019 there was indeed a problem when inner bleed was 0, but it had been fixed a couple years ago. @Customer Feedbackhave you tried it and still have an issue when innerBleed = 0? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.