Barry Dalby Posted April 7, 2020 Posted April 7, 2020 New to Publisher, been using InDesign for years. Not sure if this is a bug or an omission but how can I set Publisher to not rasterise certain elements of the PDF export. So I'm combining two pdf files in Publisher. Both are vector files and can be enlarged up without any pixelation/ loss of resolution. When I export this combined file from Publisher, I find that certain elements of one pdf are being rasterised and losing resolution when enlarged. It seems to be 'corrupting' the integrity of the original pdf. Why is this happening and can/ how do I prevent it? Thanks Quote
Joachim_L Posted April 7, 2020 Posted April 7, 2020 You can force APublisher to rasterise nothing on export to PDF. Hit the More button in the export dialogue. At the top you'll find a dropdown. BUT if there is nothing to rasterise in a document APu won't do this. Means that there is something in your document like an effect or similar, that needs rasterising. Without the APu document it is hard to tell. If this is not confident work, you can post the .afpub file here, so others can have a look. Jon P and Barry Dalby 2 Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 Thanks Joachim, I didn't see the More option but even setting that so nothing is rasterised, I'm still seeing loss of resolution in final export file. I'll attach the APu document here, I've embedded the two pdfs so it should open correctly. The map detail is in one pdf and is all vector data: points, lines, text and patterns. The Center Parcs logo is in separate pdf file generated from an eps. So when I export these from APublisher as a pdf, I see that the point symbols, line symbols, text is all sharp. But the background pattern for trees in this instance seems to be rasterised or approximated in some way, the tree symbols have lost their sharpness. I'd like to find a way around this as typically this graphic would be enlarged for use on signage. Thanks for any advice you can give. newcastle_2020_embeddedimages.afpub newcastle_2020_embeddedimages.pdf Quote
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 Just to be clear - the tree symbol/ pattern is not a raster image in original pdf. It's created in vector based software and exported correctly from that to pdf. Quote
Joachim_L Posted April 7, 2020 Posted April 7, 2020 8 minutes ago, Barry Dalby said: Just to be clear - the tree symbol/ pattern is not a raster image in original pdf. When I break the file apart the pattern "seems" to be a bitmap fill. To get closer to the problem we need the original PDF. Even more strange, when I try to export with preset X-4 I get the warning that an error occurred. Other preset like press-ready works. 😲 Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 Hi Joachim, here's the pdf export file from the cartography software (which is vector based). Open in a pdf reader and you can see that the tree patterns retain their resolution when enlarged. If I were to combine this pdf file with other elements in say InDesign and export a pdf, it would retain these patterns as vector data. Perhaps it's something in the APub export filter that is treating patterns or fills as raster data?? Thanks newcastle_2020.pdf Quote
Joachim_L Posted April 7, 2020 Posted April 7, 2020 I guess it is not an export problem, but an import problem. As soon as you place or import the PDF there are raster fills. I even stripped down the PDF to just the pattern and it still imports as raster data. At this point I have no idea anymore and leave the field to the Professionals. Sorry Barry. Barry Dalby 1 Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 Thanks Joachim, hopefully the publishers of the software can have a look. I don't know how it imports or renders images but I do note that when you zoom in on the imported pdf that the tree/ pattern fills seems to be resolution independent and displays correctly along with the other elements? If it was an import issue, would that not show up in the working file? It's just when you export, that it appears to be rasterised. Quote
Joachim_L Posted April 7, 2020 Posted April 7, 2020 Just an idea after I looked at the export options of OCAD. Try to export as AI or SVG or EPS. Although the patterns look "pretty sharp" (I can't zoom more than 6400% in Illustrator), try to set the Raster Resolution to lets say 2400dpi (just to make sure) and do not use the compress option when exporting as PDF. NOW I am really running out of options. Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
Joachim_L Posted April 7, 2020 Posted April 7, 2020 18 minutes ago, Barry Dalby said: If it was an import issue, would that not show up in the working file? It is already raster data on import. See attached image. Is it possible, that the patterns are indeed raster? And you can't see it with a small zoom and exporting again won't make it any better. Attached a PDF, where I exported without compression and downsampling. newcastle_2020-no-downsample.pdf Barry Dalby 1 Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
MikeW Posted April 7, 2020 Posted April 7, 2020 It's probably because the areas that get rasterized are clipped vector fills--each area with trees, for instance, even if only a single tree is showing, is a clipped object comprised of 51 tree objects. Affinity applications are evidently rasterizing those pattern fills (which is what they are) upon import when they could use the clip area (it's just a vector object with no color fill nor outline) to either clip those 51 vector tree objects or throw away the area outside the vector clip. One vector editor I tried imports the pdf correctly. Joachim_L and Barry Dalby 1 1 Quote
Joachim_L Posted April 7, 2020 Posted April 7, 2020 6 minutes ago, MikeW said: It's probably because the areas that get rasterized are clipped vector fills--each area with trees, for instance, even if only a single tree is showing, is a clipped object comprised of 51 tree objects. Affinity applications are evidently rasterizing those pattern fills (which is what they are) upon import when they could use the clip area (it's just a vector object with no color fill nor outline) to either clip those 51 vector tree objects or throw away the area outside the vector clip. One vector editor I tried imports the pdf correctly. As said, I better leave it to the Professionals to explain ... Quote ------ Windows 10 | i5-8500 CPU | Intel UHD 630 Graphics | 32 GB RAM | Latest Retail and Beta versions of complete Affinity range installed
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 Ah I see that raster render now Joachim, when I zoom right in using APub. Tried the .ai and .eps export filters from OCAD, nothing imported with .ai and the .eps import crashes APub. Does this import rendering in APub apply to all pdf files I wonder? I've tried importing a pdf created through Illustrator and see the same effect. Will experiment with a pattern created directly in Illust and see what happens.. Quote
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 (edited) 23 minutes ago, MikeW said: It's probably because the areas that get rasterized are clipped vector fills--each area with trees, for instance, even if only a single tree is showing, is a clipped object comprised of 51 tree objects. Affinity applications are evidently rasterizing those pattern fills (which is what they are) upon import when they could use the clip area (it's just a vector object with no color fill nor outline) to either clip those 51 vector tree objects or throw away the area outside the vector clip. One vector editor I tried imports the pdf correctly. Thanks, you're likely correct as whilst the pattern is defined geometrically, when applied to a small area of say forest in this case only a portion of that pattern is rendered. Here though attached is a similar file combined with a defibrillator symbol using InDesign and exported as pdf. No rasterising evident at all in the tree symbols even at max zoom. So looks like it's the APub Import filter then?? Doesn't appear to any options that control import settings that I can see. Unless I just haven't spotted. Thanks ticknock_2_aed.pdf Edited April 7, 2020 by Barry Dalby Quote
MikeW Posted April 7, 2020 Posted April 7, 2020 Yes, it may be a limitation of Serif's library (PDFLib) used for import/export. Any solution has to be programatic...if the library is capable. Importing the same pdf into an older, Serif Plus application that uses an older version of the same library results in the same rasterization. For what its worth, here are two screen shots of what I was talking about as regards the tree pattern. Here is a selection of a couple trees still contained in their clip group: And if I release the clip group: Barry Dalby 1 Quote
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 (edited) Thanks Mike, yes I can see how that would be the case above. To check, I've created a small test file in Illustrator containing one of their predefined patterns, some text and a line. Exported as Illustrator pdf file and saved here as testtesttest.pdf Imported this into APub and same/ similar issue. See attached file. Text and line are fine but pattern is pixelated. So figure this is not an OCAD pdf export filter issue but rather how APublisher is importing. So I guess message to Serif, can this be addressed please? Bit of a shortcoming in what looks like useful software Thanks testtesttest.pdf testtesttest.afpub Edited April 7, 2020 by Barry Dalby Quote
MikeW Posted April 7, 2020 Posted April 7, 2020 You're welcome, Barry. Yep, nothing wrong about your pdfs from either OCAD or AI. Quote
Barry Dalby Posted April 7, 2020 Author Posted April 7, 2020 (edited) Cheers Mike. Not quite sure how this help forum works but hopefully Serif staff monitor it? Is there a specific report routine? I've changed the thread name to better reflect the issue. Page layout publishing software and pdf go pretty much hand in hand these days, so kinda important that the inherent integrity of vector pdf files are not compromised by import filters. Thanks for looking and kind regards Edited April 7, 2020 by Barry Dalby Quote
MikeW Posted April 7, 2020 Posted April 7, 2020 Hi Barry--it's posted in the bugs section, so Serif will see it. They do not often respond unless they concur it's a bug versus as designed or need additional info/files. Barry Dalby 1 Quote
Wosven Posted April 7, 2020 Posted April 7, 2020 It's not easy to get back those pattern. I was able to do it playing with the XML in Inkscpae, but there should be an eaisier way. For now, perhaps you can correct the PDF inserting those patterns in the clipping curves: dessin04.pdf dessin04.afpub Quote
Barry Dalby Posted April 8, 2020 Author Posted April 8, 2020 Thanks Wosven for looking at issue - might work here but I guess not very practical on an ongoing basis or for far more complex map graphics where there'd be several hundred such patterns!! Quote
Wosven Posted April 8, 2020 Posted April 8, 2020 Yes, it's just a temporary solution while hoping the Team log it as a bug so this type of vector patterns are correctly opened and manageable, and later include in the apps Fill tool. Barry Dalby 1 Quote
Staff Jon P Posted May 13, 2020 Staff Posted May 13, 2020 Apologies for the delay, but this is logged with us. Barry Dalby 1 Quote Serif Europe Ltd. - www.serif.com
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.