lacerto
-
Posts
5,768 -
Joined
Posts posted by lacerto
-
-
It might still be that you need to rotate the pages after exported to PDF.
See this similar question on Adobe forums:
-
I think that the PDF autoflow feature is buggy and poorly implemented, and in practice pretty useless for imposition kinds of workflows, because the centering does not seem to work (possibly because of incorrect calculation of page content, when it has print marks), and because there is no way to predetermine page box (e.g. aligning to crop marks).
It is possible to correct positioning in two steps by multiple-selecting pages, but it is not possible to determine page box option for multiple pages. In practice it is probably faster to copy paste one spread at a time correctly positioned document frames with correctly defined page boxes (because copy paste uses the source coordinates), and then use the Spread box to specify the page to be shown in each frame -- especially if you are going to do impositions where the page order is not consecutive.
I did not understand how picture frames can be useful when working with PDFs and imposition, I think they are just one element more making correct placement of desired page boxes more complex. For image placement they are of course practical, but that's another topic.
-
53 minutes ago, thomaso said:
there IS some tangent snapping with NodeTool
I do not understand: do you mean that there is some inherent tangent calculation, and not just node snapping to ones created at tangent positions?
CorelDRAW, e.g. has tangent snapping that works when drawing lines, but not when trying to snap ellipses (or ellipses converted to curves):
...and Illustrator has a tedious workaround:
...but VectorStyler collision snapping works really elegantly.
-
1 hour ago, loukash said:
Only by using third party software like this one.
Thanks, I had already checked this but I missed the collision snapping.
-
Hi @eobet,
Did you export after applying the single node fix, or some other kind of a fix?
If I try to reproduce this after the "PDF export fix", I' seem to get a clean SVG export and no such anomaly. But I might have misunderstood something.
add problem_basedon_pdfexport.svg
-
48 minutes ago, mopperle said:
Just to add my 2 cents: I'm mainly using Blurb and Whitewall. Both are providing some help on creating PDFs for their services:
Thanks for posting!
There is one point worth noting mentioned in Blurb instructions:
QuoteBlurb does not review your file before it goes to print. The content and layout of your book is entirely up to you.
Some service providers, on the other hand, might use (overly) strict preflight routines that discard a delivered print job for reasons that seem trivial. But they often are not, considering what the print personnel in such services really can do.
Many on-demand-printers targeted for general public e.g. might simply just strip any color management included and if there are transparencies, might flatten them with whatever tool is available for them. Such operations might leave visible stripes or color changes between adjacent (flattened and non-flattened) color areas, which would then become as nasty surprises in printed product if not noticed when checking the drafts (if even available).
Noting users of possible issues as regards use of live transparency, mixed color mode, etc., and recommending "legacy" press standards, are often kinds of safety measures and warnings and recommendations, and they are often given assuming that users have easy ways of applying these changes (i.e., that they do the layout with e.g. InDesign, QuarkXPress, etc.). There is typically no press-specific information available for Affinity apps, and it cannot be assumed that printshops have trained personnel knowledgeable enough to know about specific limitations and workarounds of Affinity apps to give step-by-step instructions for their customers (especially as press-specific development is going on).
-
Here is basic visual preflight that you can do in apps like Adobe Acrobat Pro that can show separations and check use of transparency, overprint and rich black, and total ink coverage.
You mention newsprint so I wonder if the default CMYK profile you are currently using (U.S. Web Coated v2), which allows up to 300% total ink usage, is appropriate, or if your printer can recommend something with lesser maximum ink usage?Related to this, please note that if another CMYK profile is recommended, you cannot simply just switch the profile at export time, since Affinity apps do not allow "keeping the color numbers", but instead will recalculate all CMYK definitions, which would result in K100 blacks being converted to rich black. So if you need to change the profile, use File > Document Setup, and Color tab, and when switching the CMYK profile, make sure that you use the "Assign" option if you just want to change the profile without causing change of color values (this would keep you K100 text as K100) -- or, if you want to have Affinity Publisher to translate all CMYK colors for lesser ink coverage, use the "Convert" option, which would cause K100 to become rich black, which you then need to change back to K100 using e.g. Search and FInd, optimally combined with text style definitions.
-
2 hours ago, Jane DK said:
Anyway, frustration goes with the territory and speaking for myself, it is part of what inspires and fuels me to learn more!
😃
2 hours ago, Jane DK said:Q: Is there any way I can discover this in the PDF after export?
If you do not have e.g. Adobe Acrobat or another tool that lets you view separations (e.g., browse through the pages while having CMY enabled and K hidden, to expose text where CMY inks are applied), you can always open the document in Affinity Publisher and check (e.g. use formatting in search to look for specific font color). If you have Photo, you could visit Pixel Persona and use the Channel panel for this purpose.
Note that if you experience conversion of K100 text to four-color text, these parts might also be rasterized, since violation of Affinity PDF compatibility rule basically always means that these parts will be rasterized. If you are going to use transparency flattening (PDF/X-1a or PDF/X-3), please notice that Affinity apps always flatten transparencies by rasterizing, so some part of text might become rasterized and four-color because of that, too.
2 hours ago, Jane DK said:This is newspaper print quality and in earlier editions, it looks like everything (logos, ruled lines etc.) is rasterised. So I will not worry about that.
Fine. As long as document DPI is high enough (300dpi is probably just fine, considering the medium), it is basically irrelevant at which point things get rasterized. If the newsletter will be in digital format, as well, exporting with different PDF method would keep these parts non-rasterized.
2 hours ago, Jane DK said:saw no options relating to transparency or flattening so I'm guessing it must be implied in the pdf file settings
It is not an explicit option anywhere, so you get it in Affinity apps only if you use PDF/X-1a or PDF/X-3 standards, which have in their specs that live transparency is not allowed. It is possible to have transparency flattening as an in-app feature, but this is not so far supported in Affinity apps. Affinity apps do not support exporting using PDF 1.3 version, which would allow transparency flattening without using PDF/X standards (if that is something that is not wanted), and which would also allow flattening of transparencies in RGB exports (which would require also an option that lets the user to choose transparency blend color mode).
You can do some transparency flattening manually, too, e.g. flatten images with a transparent background when this feature is not needed, using an image editor. It is possible to rasterize objects also on canvas but that often leaves artifacts. Using Boolean operations and Designer Persona and tools like Shape Builder you can also manually try to separate transparent parts and make certain areas solid color, but this is pretty cumbersome so probably not worth an effort.
-
@Jane DK - I'm sorry for my somewhat frustrated words above, but I'll try to be more helpful, even if what I mention here is a bit out of topic considering the original subject.
Producing using PDF/X-1a (or PDF/X-3, and making sure that you check the Convert color spaces option) gives you the closest to the preset you have used in InDesign: essentially, these two export methods are the only way to produce automatically transparency flattened PDF within Affinity apps, which is what PDF 1.3 supported in other page layout apps will do. If this is what your printer truly requires, these two are the only options you have to automatically flatten the transparency (opacities, PNG and other images with transparent backgrounds, etc.)
The bad news is that it does not work well with the kind of job you have at hand, since a newsletter is likely to contain placed PDFs on the layout. If so, you should know that if you export using PDF/X-1a, all non-PDF/X-based PDFs (e.g. logos, ads, etc.) will be rasterized and their colors recalculated, e.g. K100 black will become four-color black -- unless you let Affinity Publisher interpret their content (in which case you should have all fonts used in these files installed on your system, and check that they are correctly mapped; and check that colors are not recalculated: they most certainly will be). You mention above that this is specifically what went wrong with your job, and this is one explanation to this.
If you export using PDF/X-3, PDF/X-1 and PDF/X-3 based placed PDFs will not be forced to be rasterized, but will be passed through; everything else will be rasterized and colors re-interpreted. If you do not have this kind of placed content (or do not mind having it rasterized and colors changed), I suggest that you try either method, and let your printer have a comment on output. It should be technically pretty close to what they expect. It is true that most printers today accept live transparency so if you want to make your life easier with Affinity apps, you'll do yourself a favor if you look for a printshop that does not have a problem with it. Your job is a kind that allows such a switch, but those depending on low-cost on-demand book print services, might not have that freedom.
You mention that you will try PDF1.4 based method. That will not flatten the live transparency, and is also an export method that allows mixed color modes, which might be something that your printer does not want. Technically the most compatible export method would be the default, PDF (press-ready) that uses PDF 1.7. That will not rasterize any placed PDF content, but would of course not flatten live transparencies, either. [Non-PDF/X-based press exports in Affinity apps, on the other hand, will retain RGB colors in PDFs that are passed through, which is probably something else that your printer might comment...]
-
1 hour ago, Hangman said:
A really unhelpful printer... if there is something specifically wrong with the PDF they should be able to tell you exactly what that is
I would say that asking for 1.3 is asking the least of all troubles, in good belief that the client is using page layout software that is capable of producing high-quality clean and simple print PDF using those specs. That means: a device-CMYK, non-color-managed (= no ICC dependent), transparency flattened, yet non-rasterized PDF that has ideally been produced by using a job description and color profile provided / recommended by the printshop. This is what most of the kinds of printers mentioned in the title line of this thread ask and instruct, and it is so simple when using the expected tools. The other alternative they might offer is creating an all-RGB file, produced with something like Word or Pages -- so no CMYK, and nothing fancy.
But we have seen this so many times on this forum: printer's fault, legacy technology, please move on to 2020s. The sad thing is that asking for PDF/X-4 (or PDF 2.0, which Affinity apps now have added amongst the "supported" export standards), might cause rasterization of the whole design and totally misinterpreted colors, so the supposedly most compatible and versatile export method might actually turn out to be the most incompatible, and messy.
Might one dare to ask Serif to be helpful enough to provide step by step guides for producing PDFs for these kinds of services? Or could it be that such recipe cannot be given because there are so many reasons why "the most simple possible" press-related export job can go wrong when using Affinity apps, that in practice the old-time workflow: sending in everything involved, is the only way to truly and effectively troubleshoot these jobs.
Yet it is worth a try: sometimes the fix can be very simple, and there is always someone willing to help on the forum. Just don't be afraid of kilometer-long discussions.
-
On 1/31/2024 at 7:00 PM, toreador said:
How did you identify this as the cause of the problem?
Two standard methods for me for trying to save time in sorting out Affinity curve anomalies has been exporting to PDF and opening for editing (sometimes usable for simple designs, did not work in this case, though), and using VectorStyler for doing the same job (Expand), and pasting back: did work for this one.
@toreador -- is there any chance that the letters were at some point based on TrueType character shapes? Some of the nodes (and their positions) show traces of having been converted from quadratic segments, a segment type not supported in Affinity apps, though in this case the node that was problematic was not in any way non-standard. Also, exporting the shapes to EPS or PDF and opening them back for editing, cleaned the curves so that all nodes were "regular" kind, yet expanding the stroke still failed. Simplifying the shape in Illustrator (actually resulting over doubling the number of
strokesnodes, to be able to retain the curvature of the shape), and copying this shape into Designer, resolved the problem. It would be interesting to know if there was any history of that kind in this design. -
I noticed that the ICC profile extracted by Exiftool was corrupted (none of the Adobe apps could recognize it as a valid ICC profile, even if Affinity apps did) -- it seems that Exiftool has problems extracting correctly profiles from ZIP packed TIFFs, so I embedded it in a JPG file, and re-extracted, and this time the resulting ICC profile was accepted by Adobe apps, as well.
So here is a demonstration on applying the correct, matching simulation profile on an Affinity created default press PDF which has a document CMYK profile embedded in the created file:
And here is the corrected ICC profile packed in a zip file:
-
5 hours ago, stokerg said:
From the checks I've been able to do, I can see the image in the PDF has had the 'SWAP (coated), 30%, GCR Medium' applied, so this could very well just be an issue with how the PDF being is checked for errors.
The ICC profile would be important if it is embedded in the PDF (as it is when using the default press ready CMYK PDF export preset of Affinity apps), and when using a viewer like Adobe Acrobat Pro, which in the Output Preview dialog allows the user to pick an ICC profile to simulate when interpreting the shown (calculated) color values.
However when using a custom color profile, like the one I used in my demo, which is based on US Web Coated SWOP v2 but just has Dot Gain value increased to 30% using Photoshop, and the profile then extracted from a TIFF file where it was embedded using EXIF tool, the resulting ICC profile is not one that Adobe Acrobat Pro lists (I thought that it lists all that are placed in the system color profile folder, but obviously it does not). That means that I cannot select the correct simulation profile to match with the ICC profile embedded in the file, and would accordingly see misleading color values in the Output Preview window, as demonstrated in the video below:
The video also shows (in the PDF viewed on top right) how selection of simulation profile is irrelevant (does not have any effect) on a job that it "DeviceCMYK" (not ICC-dependent), and how PDF/X-based job has an obligatory output intent indicating the target CMYK profile of the job, and automatically selected as the simulation profile. Here the actual ICC profile used in the job can be used by Acrobat even if it cannot list it in jobs where the color intent is not included.The files used in the video also demonstrate how grayscale 0 and RGB 0, 0, 0 black (virtually identical color definitions) will result in the kinds of even builds of CMY values, and 100K when converted to a CMYK-based PDF, so one possible explanation to what OP might have experienced is having originally defined black as a grayscale value, and expecting it to be handled as K100 values, similarly as e.g. in InDesign, while in Affinity apps gray values in a CMYK color document are treated as RGB values that always result in four-color blacks. [UPDATE: Note though that grayscale images that are placed in a CMYK document have the "K-Only" option automatically applied on them, forcing the gray values being handled as K-only values; so if the unexpected color values are only related to TIFF and other placed black images, this does not explain what happened; so it might have been "view-only" kind of issue.]
blacks_pressready_icc_embedded.pdf
blacks_pressready_icc_not_embedded.pdf
Here is the ICC profile that I created, perhaps somebody can have Adobe Acrobat Pro show it in its list of simulation profiles
-
Hello @thoy,
My first question is: which version of Publisher are you using?
I have been reviewing Affinity color management related issues for a few years, and do not expect rapid changes, but it seems (and I hope I have not just made some stupid mistake) that the recent 2.x versions finally show some development and improvement -- at least in perspective of users with some experience of using other professional page layout apps. Namely: it seems that Affinity apps (at least Publisher) now, similarly as e.g. InDesign, discard embedded CMYK profiles from TIFF and JPG files, meaning that placing a raster image with an embedded CMYK profile that conflicts with document CMYK color profile, or with the CMYK profile selected at export time no longer results in conversion of CMYK values of these images. I am not sure if this is optional (e.g. is or will become a color profile policy setting, but possibly -- and hopefully -- so, since needs are different in the three apps of the suite).
Native CMYK color values (of shapes and text) will, as they basically should be (without an option available that would explicitly prevent this), as will be color values of .aphoto and .PSD files with a conflicting embedded CMYK profile, probably because of their potential complexity, as they can hold vectors/text/etc., be complex jobs.
Anyway, to keep things simple when placing CMYK images, it is advisable, if at all possible, to use TIFF or JPG images with no color profiles embedded, in which case they will be assigned with the document CMYK profile and their native colors will be passed through, also when changing the CMYK profile at export time (something that normally should not be done if CMYK definitions are used in text and other native objects). As mentioned, you can now (at least in recent 2.x versions) also place CMYK TIFF and JPG images with embedded and conflicting profiles because they will be ignored and native colors of images will be passed through. Note though that in version 1 apps JPG and TIFF CMYK images with conflicting profiles will have their native colors recalculated.
Along with this change many issues with K100 definitions becoming inadvertently converted to four-color blacks at PDF export will be avoided.
The attached PDFs demonstrate how K100 definitions are translated and retained in different situations. The first PDF is exported using the document color profile, the second is exported to a different CMYK profile.
Note that the Publisher document in these examples uses pretty much the kind of a CMYK profile you mentioned, based on SWOP Coated with max 280% TAC and 30% dot gain, as will some of the placed K100 images. As can be seen, the only problematic images are .aphoto files, which are recalculated when there is a profile conflict. RGB black and K100 and 400% black in native shapes and text, when there is conflict, will also be converted, as expected.
The second big question is: which app are you using to verify the color values of exported PDFs? The 30% 30% 30% 100% build especially sounds dubious, not something that would appear as a result of an ICC profile based conversion of CMYK values (but rather a CMYK representation of an RGB/Grayscale black). Anyway, it is good to notice that Affinity apps by default embed the document ICC profile when exporting to press-related PDFs, which is in many ways problematic, because it often makes an all CMYK (already fully resolved) file ICC-dependent, and when such a file is viewed in e.g. Adobe Acrobat Pro, the displayed color values in Output preview depend on the selected simulation profile, and the correct profile will not be automatically selected (unless in PDF/X based exports). This means that inherent values are recalculated ad-hoc on display if the correct document color profile is not activated (in Output Preview). Most PDF viewers do not support selection of a simulation profile and do not suffer from this issue, but this confusing default export method (which in other page layout apps can be done, too, in case the default and recommended settings are deliberately rejected and changed) continues to trouble both users of Affinity apps and production personnel, and may actually result in inadvertently converted (or unnecessarily changed) print jobs.
There are also other related issues -- though not relevant in your situation -- in Affinity produced PDF exports (e.g. so called PDF "version incompatibility rules" dealing basically with transparency flattening), which may cause inadvertent rasterization, which in context of K100 objects results in translation of mere black to four-color blacks.
These kinds of problems cause much insecurity, and in lack of proper preflight / prepress tool, it might be a good idea to open exported PDFs in Publisher (or another Affinity app) and examine the color values. In most situations (but not always) an opened PDF file shows colors accurately and at least helps making correct production decisions.
-
40 minutes ago, wonderings said:
would never ask for an EPS made from Photoshop
They did not ask a Photoshop EPS file, which is a specific press-specific, nowadays probably more or less legacy format allowing extended features like color management, similarly as .DCS EPS files allowing color separations, and as mentioned, things like duotones. My guess is that they might have asked an EPS file once hearing about an unspecified vector job, and might have first tried to open it in Illustrator, and when not being happy, might have taken it in Photoshop for rendering, but not getting expected results there, either. Photoshop is still a kind of a last resort for getting prepared a messy vector job that cannot be satisfactorily processed for print as vectors, and the job needs to be in press already. But OP's situation might of course have been different... A properly created PDF might nevertheless be what could work.
-
38 minutes ago, R C-R said:
As I understand it, the ON 1 color film presets are not plugins as such, just sets of filters with preset values applied, most of which can be adjusted in numerous ways.
I suppose that's the way film emulation "packages" typically work: they are essentially film grain emulators (and I suppose normally based on scans and curves built on real film data) and then apply HSL etc. adjustments to get the tones and other factors right to create a good emulation. So they are basically presets of multiple settings available in the package, whether exposing the preset values or not, and allow the user to finetune the image and combine in possible other features. E.g. FllmPack 7 is an independent app but comes also with Photoshop plugin, and can additionally be integrated with DxO PhotoLab so that it can be used in combination of everything else that is available in that app in one go.
-
-
12 minutes ago, anto said:
But when i want to place 2 photos on page with caption how to do this?
One possibility:
a) Configuration:
b) When merged:
How functional this could really be, much depends on how varying sizes the images are.
-
Do you mean placed at 100% in relation to their dimensions determined by internal PPI and document dimensions, meaning that there will be no scaling in context of placement? If so, I suppose that just creating large enough document and picture control and placing merged images with scaling property of "None" should do what you ask.
a) In configuration:
b) When merged:
-
I suppose most of the film emulation plug-ins have additional controls, certainly the two I mentioned above do. As for G'MIC, there is a short article about creation of film presets and going into the "rabbit-hole" of making endless adjustments written by the author of this plug-in, that might interest anyone using these kinds of filters, at
https://patdavid.net/2013/08/film-emulation-presets-in-gmic-gimp/
-
Of these, I can tell that DxO FilmPack v7 (both for Windows and macOS) works fine as a Photoshop plug-in with at least Photo 2.3.1:
-
For free ones, if you are on Windows, you could try G-Mic plug-in that works with Affinity Photo. It has a number of presets for b&w, negative, print, and slide films:
-
These two PDF files exported from the .aphoto file shown above, comparing pixel-selection based and vector-based simulated feathering, are related to the post above, but for some reason could not be attached to the post unpacked.
-
Here is yet another take, a bit more complex, of an attempt to simulate pixel selection kind of feathering with shapes and text, applied on a mask.
I might be wrong but I think that rasterization happens whenever trying to export this kind of an effect involving a mask to vectors. Anyway, the components involved stay editable so it is a live effect, definitely useful.
But I have not been able to produce something like this InDesign based feathering where all elements involved stay at export as vectors, and the text is still text.
But as mentioned above, this was not specifically what OP asked.
Autoflow pdf pages in Publisher
in Affinity on Desktop Questions (macOS and Windows)
Posted
Here's my experience of this feature on Windows (latest version). I have not tested this on macOS, but on Windows, placing the page using spread snapping, even when zoomed in very close, typically leaves a gap, sometimes smaller, sometimes larger, and does not place the page exactly in the middle of the sheet, so the first thing to do is to fix the positioning (drawing the trimbox is a valid workaround but kind of counter-intuitive). Positioning is not a big issue though, because multiple pages can be selected at a time. I have not tested whether the gap is caused by having additional stuff (bleed, print marks) beyond the trim box, but this is anyway a typical situation in all kinds of imposition jobs so the autoflow feature should be able to do centering right if the center of the page is clicked while having spread + middle point snapping on.
My other gripe is that the Page box cannot be set at once for all pages, but needs to be set one by one. Publisher also does not remember the last used setting so I cannot just first place one page and define the desired page box, and then delete the page and autoflow all pages since Trimbox will be the forced page box option.
IMO fiddling with Picture boxes just blurs a simple job and unnecessarily hides the linked document and requires additional clicks when needing to add page box definitions done for each of the placed document pages.
I am not saying that the job cannot be done but just demonstrating flaws of the feature as it is currently implemented.