Lorox

As I used to have some issues with my PDFs for professional printing (mainly Black not being 100% K but some CMYK-mix) I just want to share my latest findings. Ah, and this applies to Publisher (only) as I haven't yet created any PDFs for print with Designer (and – neither having done so with Illustrator in the past – I don't think I will). Anyway, when fiddling around with Publisher (CMYK document) lately I noticed that some text I'd assigned „Black“ as the fill colour seemingly proved to be just 100% K (as intended) when looked up (double clicked) directly from the „Greys" (in "Swatches") panel but – strangely – being a mix of CMYK when looked (double clicked) up from the ”Colour" panel. (see screenshots) I couldn't make any sense of this and found myself completely confused after some clicking here or there just to find out what colour was actually assigned... I then decided to get rid of the default ”Greys" swatches (including "Black“) altogether as I felt I just couldn't trust them to be what I thought they should be (in a CMYK document, at least...). Instead I created a new application palette comprising of K-only Greys (including a 100K Black). Then I created the document attached here using the 100K Black from that palette and exported it to PDF with the export settings as seen in the screen shot. Checking the PDF with Acrobat Pro proved that everything was actually as it should be – on first try! I'll keep an eye on this – maybe there'll be no second and third exports needed anymore... (fingers crossed) ColourTest_AffinityPublisher_ISOcoatedv2_300.pdf ColourTest_AffinityPublisher_ISOcoatedv2_300.afpub

No, obviously (and sadly) there is no separation preview yet. I wish there was, as these "details" as you put it are quite annoying to me , too. I'm actually a bit tired to have to run my Affinity exported PDFs through Acrobat Pro (which I fortunately have, but many among us may not) several times to hunt down those spots where these separation issues occur (most of due to Black not overprinting as it should). As to your example screenshot: are you sure that "Global Colour 155" you apllied to your text is actually just 100 % K and nothing else? More often than not I find that the colour applied to text that I was quite sure I had chosen Black (from the swatches panel) for wasn't actually 100% K but some "rich" Black containing degrees of CMY. I suspect that when I convert to or assign a CMYK colour profile to my document the grayscale swatches (including Black) don't get by default converted to just 100 % K (for Black) or percentages thereof (other grayscale tints). Or maybe elements which had been made "Black“ before retain their "old" mix-of-CMYK Black as those Grayscale swatches don't seem to be global by default. This certainly is harming me an my joy of using the Affinity apps, too, as each and every time when I finally check my PDFs meant for printing there seems to be some issue of this kind – something that has been an absolute exception during 15+ years of working in InDesign...

@Jiorgos I'm actually trying not to rule out Publisher as a tool for productive use as I'm thoroughly fed up with Adobe's general policies. I do want the Affinity apps to stay on the the scene and successfully compete with the near-monopolist. That being said I think that what's happening here in the forum is important to make the Affinity team work even harder to finally and fully make the apps live up to their promises. I really hope these issues we're talking about will be resolved sooner or (rather not so much) later... I have to admit, though, that so far I tend to use Publisher productively only on small projects (the odd flyer or leaflet – completely new or maybe even migrated/converted from InDesign) where there's a good chance any glitches won't slip through unnoticed (and if they do nevertheless the actual damage will be quite limited). Right now, however, I'd in fact be very reluctant to use Publisher on any job where hundreds or thousands of euros/dollars in printing costs will be involved. But – exactly this will have to change: professional users must eventually be able to be confident straightaway that their designs for any project will be output in a correct state of the art way for commercial printing without having to worry what could have gone wrong again this time (colours, rasterization effects etc.). A truly ergonomic user experience and bulletproof reliability regarding its final output for me is what will really make a publishing app meant for professional and productive use actually "professional" in the end.

Exactly... For all of of us who do design for print this is so annoying. Each time when I'm finished with designing and I want to get proper PDFs for offset printing to my printers shop it gives me such a headache as from the Affinity apps' (especially Publisher) settings (document setup & export settings) I strongly feel like I've really set it all correctly but somewhere there must be some glitches in the underlying logic of the apps because more often than not I find the PDFs not to be what should have been expected considering the settings having been made (primarily "black" not turning out as just 100% K). With InDesign you just set up your general colour management once for your apps, choose the colour profile you need/want on export and everything will be fine in 99+% of the cases. You just don't have to worry about it – it's highly reliable. With my Affinity produced PDFs, however, I'm unfortunately dreading each time what Acrobat Pro will actually unveil... It doesn't feel good and doesn't match the good feeling I – admittedly – generally have when I'm still in the process of designing with Publisher (even though there are some things I wish were handled more ergonomically by or added to the app).

Yes sure, it took me a while (and a visit to the Affinity forum...) to discover that button and learn about its significance. But it's a bit of a peculiar way to do it, I find. Looking at your examples, I think it is quite strange, that you can obviously assign a fill color to an image that already has (mixed) colours in the first place. With a grayscale or 1 bit TIFF on the other hand, it seems just natural that you should be able to replace its original inherent colour (black) with another one, but when you do this with a full color image the underlying logic seems not so clear. Do you have some sort of "rationalization" to understand what might be happening here? In your examples those with just an fill color assigned look a bit like they probably would when you first convert them into grayscale and then put the fill color above them in "Overlay" mode (or when you use the "colorize" mode of the Hue/Saturation adjustment in Photoshop). Plus the "K only" they look more like grayscale images just printed with the assigned fill color instead of black (where in case of CMYK that pseudo-grayscale color image looks like just the K channel of the CMY image).

Absolutely so! I was quite baffled when I discovered that the Affinity apps are obviously still ignoring this format (meaning: 1 bit strict b/w images) – especially as there is no such export option in Photo. Also, the whole business of colouring grayscale images in layouts – which used to be so easy in the Adobe apps – is handled in an unnecessarily complicated way in Publisher. Although I generally love to use it there's still some headroom, I'd say.

Thanks a lot! This feature – while so intuitively to apply in InDesign – is certainly well hidden in Publisher... I'd never have looked there!

I'm not quite sure how this is handled in the Affinity apps but I've worked in InDesign for a long time and in InDesign's colour management settings you could/can set the rule that CMYK content preserves/keeps its "numbers" (meaning its original CMYK values) when placed/pasted into the layout document. This actually makes a lot of sense to me as this way I could/can be sure a logo's colours defined for print with certain CMYK values in fact "migrate" 1:1 from the original – say – Illustrator logo design document to the layout document (and on to the PDF for printing). This way these colours are treated exactly the same way as if they had been just assigned within – say – InDesign using its current colour profile. Accordingly they don't get changed when in exporting the PDF for printing that very colour profile is used. So the logo's CMYK colour values will be exactly the same in the PDF for printing as they have been in the original CMYK AI design file (which is what you generally want). As I said I'm unfortunately not eactly sure how this really works in Affinity Publisher and Designer... (I definitely wish I knew exactly – I'd feel quite a bit more relaxed when giving PDFs away now that I'm trying to adopt the Affinity apps as my premier go-to design apps...)

Not necessarily so. As it has been said it depends on either (most) common usage in a certain area of the world or what the printer who's gonna do the print job for you expressively asks for. There are very likely to exist established or standardised workflows in regard to specific print processes (sheet offset, roll/continous offset, newspaper print or whatever). You should possibly ask your printer(s) for information about the standards they adhere to. I personally mostly use the ISOcoated_v2 colour profile for CMYK being the one that's most commonly used by printers around here. Or ISOcoated_v2_300 which is basically the same but limits ink coverage to a maximum of 300% which is preferred by some of the bigger online print services as printed sheets dry faster when there is less ink coverage. That said, one should remember that regardless of the profile you have initially set for your (layout) document (even if that should preferably be the most common one in your area) it is actually the job of an application's internal colour management to create the final PDF for printing according to the profile you haven chosen in your output/export settings! You may have initially created our design for usage in regular sheet offset printing, but when your client then needs another PDF to be sent out to be printed on sort of "spongy" newspaper stock you will most certainly have to export your design using a CMYK profile which separates the colours accordingly (i.e. most likely with considerably less ink coverage). That's what Colour Management has been meant for in the first place. Mind, however, that all this predominantly applies to outputting final printing PDFs from a layout application like Affinity Publisher or Adobe InDesign! Colours of CMYK vector objects should – in my opinion – be preserved anyway 1:1 by the layout application they are placed or copied into, because it generally seems to be a sound assumption that the colour values defined in CMYK for these objects are actually meant to be precisely as they are (e.g. in logos etc.). On the other hand photos – and generally photo-like "pictures" – can or should be left as they are (assuming they have an assigned colour profile that's saved inside of them and that is detectable by – say – Affinity Publisher) – for purposes of correctly display on screen the layout app should be able to convert the colours according to the profile chosen for itself (the layout document). For purposes of creating a PDF for printing the export settings should take care of that.

If I may contribute something from my angle as a graphic designer working mainly for print: I personally very much prefer or suggest starting from CMYK (if not black and white only) when designing a logo. Starting from CMYK ensures that the logo will be printable by offset printing quite exactly the way it has been seen on screen before (given, of course, that the system/display is more or less calibrated). As the CMYK colour space is considerably smaller than the common RGB colour spaces, the logo begun in CMYK should be easily reproduceable on screen once it has been converted to RGB as there are almost no colours in CMYK that cannot be closely reproduced in RGB. Given that the vast majority of displays in use will not even be able to truly display any RGB colour space bigger than sRGB it seems reasonable or sufficient to me to produce an RGB-version of the initial CMYK-logo using just that sRGB colour space. There may be exceptions, however, if you consciously and decidedly design for screen only and really want to push one or the other other colour for that vibrant (if not garish, posibly...) highly saturated, almost neon colour look as it is possible in RGB with some hues. These sort of colours just cannot survive in CYMK, though. So you'll lose them and will be forced to accept considerably dulled versions of these after CMYK conversion, should the necessity arise at some time to have a print ready version nevertheless. Alternatively you might consider to create a version of your logo not using (just) CMYK but adding a suitable vibrant PANTONE spot colour (or even a fluorescent spot colour).

I guess Chris26 (and the article he'd referred to) made the topic relatively clear and understandable – at least as we're talking about RGB colour mode. This given, I'd think this will be useful predominantly for photographers whereas converting from RGB to CMYK (and possibly from one CMYK profile to another) will be important to designers doing work that is bound to be commercially printed using e.g. offset printing. In this area it might be crucial that certain colours will not be changed at all and be printed with the exact CMYK values which had initially been assigned to them (e.g. for some corporate design or house style) whereas colours in pictures (RBG and/or CMYK) placed in the design actually should be converted to fit the actual printing process/workflow and thus appear – visually – unchanged in the end (while in fact their colour numbers/values have been more or less altered in the process). It can actually get a bit complicated when a proper prepress workflow is concerned. In this respect Affinity Publisher has given me some headaches recently as black text/type – which in CMYK printing should normally be just 100% black (with no C, M or Y in it) – had turned out to be a mix of all the four components of CMYK in the PDF meant for sending to the printer's shop. It could be corrected in the end, but one has to double check and be quite careful – mistakes can happen easily as it seems.

Yeah, I think it's obvious that when you go from RGB to CMYK (or vice versa) there must be a conversion. When going from one CMYK profile (say Fogra27) to another (say ISOcoated_v2) you sort of can decide whether the colours already there in the document should maintain their given CYMK values ( > Assign) or if the colour's appearance should be encoded according to the values the new target CMYK profile considers appropriate ( > Convert). However, I've encountered some recurring difficulties regarding colour profiles myself and I'm not sure what to finally think about it...

More often than not I find myself cursing when I check the PDFs for print which I‘ve exported from Affinity Publisher: elements I thought were "Black“ (meaning just 0C/0M/0Y/100K) turn out to be some "RGB-Black“ with variable amounts of CMYK respectively, even though I chose some "real" CMYK colour profile like ISOcoated_v2 when I first set up the document. Usually I can correct this when I go back the document setup and „Assign“ (seemingly for the second time) my profile (usually ISOcoated_v2 or ISOcoated_v2_300%) that's already listed there as the document's. When I then check my blacks they appear to have changed to 0C/0M/0Y/100K as I thought them to be in the first place... Does this really mean that it isn't sufficient just to choose the said CMYK colour profile from the list when setting up the document? Do I then actually and expressively have to once more ”Assign" it by pushing that button to make it "really active"? One would think that just choosing the profile from the pop-up-list on document setup should be enough... That said, I'm really glad that I have an older version of Acrobat Pro installed on another computer so that I can reliably check the PDF exported by Publisher (and e.g. notice strange Blacks) before sending them off to the printer's. As for now I'm quite unhappy, though, that I seemingly cannot trust Publisher to immediately create correct PDFs from a document that appeared to be correctly set up (whereas InDesign actually DOES this once you've generally set your colour profiles for the whole suite of apps). Though I generally do love working with the Affinity apps I'm not happy at all about the way the apps deal with colours – be it in respect to colour profiles (as noted above) or in the way swatches can be managed in the corresponding panels. I almost hate to say it, but I think Adobe still does a better job at this...

It's like that. With the problem described AndyQ seems to back our feelings/impressions perfectly: after some time anybody working in pixel graphics will have realized that pixel masks ARE in fact just grayscale images applied in certain way to select corresponding pixels (meaning those having the same 2D position on the canvas) and allow to do certain things to them (i.e. adjusting their opacity etc.). This given it seems only natural that masks should be editable just like any other grayscale image (including copying, pasting, painting in it, filtering it etc.) once you have them as the contents of your active window. In Photoshop this is very much the case once you know how to make the mask content visible as the actual content of your active window. It doesn't take more than just going to the channels panel and clicking on the mask's channel – there you go and it's easy and intuitive. And turning the mask's content to a selection which you then can use in any pixel layer, adjustment layer, channel or other mask of your file is just one more click away... In Affinity Photo this whole "field" of channels masks, selections and pixel layers is generally organized in such a "fragmented" approach that it becomes ”cryptic" as no obvious logic becomes apparent: so it becomes hard to understand and cumbersome to use. In effect you experience exactly what AndyQ said: you spend a day on a job which you could have finished in an hour with Photoshop. And true: as the way of achieving comparatively simple thing is so unnecessary complicated you're prone to have forgotten at least half of it of it by the time you have to work on the next job needing this a month later. Please, to all you developers at Serif: I guess there are quite a number of guys here among us who REALLY WANT to work with your apps, who REALLY WANT you to succeed long term on the market. The workflow must become smoother, more unified and necessary actions for closely related goals should not be scattered over different places in the UI. I'd think in the end it just has to be at least as efficient as it is with those applications you – rightly – chose to challenge. Let's be honest: there may actually be a limit to the time professional users can afford to spend with Affinity Photo or Designer on jobs they could have finished in a fraction of the time needed if they had just reverted– however much loathingly – to Photoshop and Illustrator.

Exactly! I often find myself quite impressed with what you can do in Affinity Photo (same in Designer and Publisher BTW) but at the same time I'm often sort of turned off midway in a job by the clumsy and uncomfortable way to get these things actually done within the apps. The Affinity apps regrettably – in several aspects – still lack an "elegant" and intuitive ergonomic concept. Especially Photoshop, however, has developed and refined this approach quite convincingly over the (long) years it has been on the scene. To really compete with the Adobe apps it's not sufficient for the Affinity apps to just let the user come up finally with (about) the same results he'd get using Photoshop & Co. but he must be able to get there by a workflow that's at least as easy and convincingly ergonomic as it is with the (still) market leader. Having to go to two places in the menus and one place in the control bar and/or context menu to get something done, what the rival makes possible with just a click (OK: maybe with some additional modifier key...) won't do the trick eventually. I REALLY do want to make the transition and I'm absolutely thankful to Affinity/Serif for having taken up the challenge. I actually admire what they've achieved so far, but PLEASE keep on working on the ergonomics of the apps to make the users enjoy what they're doing in the most satisfying way!

Exactly! This is such a basic feature for the efficient management of a document's colours that still having to request it seems quite strange actually (especially for a program that's set to rival InDesign...) There isn't a feature yet for the swatches palette like "List (or add) unnamed", is it? (I hope I haven't missed it) This one has served me very well with InDesign and Illustrator in the past to gather all the colours actually used in the document... While we're at it: being able to "Select unused" in the colour palette (and then deleting them; like it's possible in ID and AI) is also a very useful means for slimming down the palette and getting rid of all those colours you don't use anyway. Last but not least: deleting a colour swatch from the palette and being given the option to replace it with another given one while doing so is another very helpful feature to efficiently deal with a document's colours. Again, in InDesign you have been able to do so for 10+ years...

As this appears to be pure (and basically not that advanced) math – exactly what a computer should be able to do efficiently – you'd think it really couldn't be so hard to implement. For the user it eventually shouldn't be more than: Choose a point for the axis to run through, choose whether it's going to be horizontal/vertical/at-an-given-angle and let the machine compute the new coordinates...

As much as I love working with Affinity Publisher I'd wish there was a simple menu entry for this like in InDesign...

That's unfortunately true... I'd love to see that feature in Designer as soon as possible. BTW: "14,551 posts"??? How on earth is that possible?

It's on my wishlist, too. For years now, to be precise. Every time I need roughened lines/paths I'm still forced to fall back to my old version of Illustrator... Without Illustrator you can actually achieve this kind of effect with Inkscape, but it's unfortunately a bit clumsy and time consuming as the "Roughen" effect will be pixel based at first and you have then to trace the generated bitmap element (which you can, though, in Inkscape as opposed to AD) to get the actual rough vector path. Which you then can save as an SVG to open with AD... (maybe just copying will do, but I haven't actually tried to). That said, I'm really cúrious what Affinity Designer version 1.9 (or even 2.0) will bring. There are certainly features which are dearly missed at present...

Wouldn't it be a strong sign of the Affinity apps being really competitive if SVG font support – which I'd consider a "hot" feature these days – would be added as quickly as possible? This font technology has been on the market for years now and the number of available SVG fonts seems to increase by the day. Plus you see more of them in actual use ever since if you keep your eyes open. I'd think it's not a good idea to let Adobe still be several steps ahead (in a number of aspects) after the Affinity apps have – luckily and nevertheless – made such a considerable impact with designers all around the world. I understand, though, that Serif is much smaller company than Adobe and surely must direct their available resources to whatever issues and features which are considered most pressing. That said, reliability and stability of the apps on all platforms might be a premier concern. But surely the apps must still appear up-to-date (better still "cutting edge") and thus appealing to technology conscious users. In this respect apps being years behind the market leader as "hot" features are concerned might be seen as a weak and not really living up to their promises. This might ultimately be reason enough for users to ruefully return to the big A even if they initially have loved Affinity...

That's possibly right. With font design software you have been able for long time now to choose the final output format (Postscript, TrueType or OpenType). So I think these formats are some kind of "envelopes" for the basic properties of the fonts and with these converters you sort of take the "basic font" out of its packaging (say "Postscript") and put it into another one (say "OpenType"). This may be overly simplified but I actually remember having a font that had an issue (which I cannot quite recall) converted by one of these online converters. It somehow worked, but I felt one can't be 100% sure to get an 1:1 conversion – there still is quite a lot of information in these font files besides the characters' vector shapes... And well it's always been some sort of welcome excuse for tech companies to cite technical reasons for some discontinuation when in reality they actually just wanted to sell you something new or a second time instead of letting you use what you already have purchased once. Especially Adobe has over the years been one of those who readily cancelled support for older OS versions when there was a new one. Affinity/Serif on the other hand (and quite a few others) have been rather more benevolent in this respect. Which seems to prove the point: it can be done if you really care your customers. I've been working with Adobe products for more than 2 decades and I initially was very happy with Photoshop, InDesign and Illustrator and the money I paid seemed well spant. Truth be told my love for their apps lasted for years until they introduced their subscription model thus forcing everybody who just wanted to use a small handful of their (up to date) apps to subsidize those users or angencies who actually embraced the whole gaint package in their work – paying the very same monthly fee. That's not fair and I just don't trust them anymore with anything... However, whereas I've seen – especially – design students taking Adobe's subscription model for the "new normal" in the past few years, I currently see these upcoming designers use other software more and more (especially the Affinity apps, but also Inkscape, Gimp etc.). Also third party suppliers of app related stuff (like brushes etc.) are increasingly adding AD and AP (and Procreate, too) to the software their products support. I'm quite happy to witness this and it gives me some hope that we designers might eventually not be slaves to the Adobe monopoly in the degree we sort of were during the last 10–15 years...

Yeah, that's how I see it. In my case – like I said – it seems like the complete font family is problematic. Oh, that'll sure make folks happy who are in the trade for more than 2 decades and who have possibly purchased extensive libraries of PS Type 1 fonts before OpenType set out to become the new standard... This seems to me like another proof of Adobe's arrogance towards longtime users who used to be able to work perfectly well with their old but legitimately purchased assets. Just like taking away the possibility for getting the various "in-version-patches" for CS5 (which you'll certainly miss should you be forced to re-install your legacy software on an old machine). "Oh, you cannot use your(!) fonts anymore in PS? Too bad.. But never mind, just go for the subscription and use ours – at least as long as you keep paying..."

As it turns out, the sort of giant point sizes of the font used don't really matter – the problem persists even if it's only 36pt... In fact, it seems like that whole font family (Postscript from 1998) somehow causes Affinity Publisher to not export a PDF. Once I assign a different font to the text the problem's gone. So you obviously don't need to delete these font (files) from your machine (as some users seem to have been thinking) or deactivate them with your font manager, just don't use them in your document (or convert to curves before or while doing the export [via the settings]).

Absolut – selbst wenn man es nicht dauernd braucht, ist es doch bei problematischen Dokumenten eine super-hilfreiche Sache um eventuell „schwierigen Stellen“ auf die Schliche zu kommen, z.B. auch um zu große Farbdeckungen aufzuspüren. Das hat InDesign immerhin seit Jahren sehr richtig gemacht. Auch dass man das Überdrucken auf Elementbasis einstellen kann und nicht nur auf globaler Farbenene. Wie du hoffe ich, dass man bei Serif genau hinschaut, was im professionellen Bereich durch Adobes Vorbild inzwischen üblicher Standard ist und was von den entsprechenden Usern auch bei einem Programm erwarten das die Herausforderung hier in Konkurrenz zu treten anscheinend angenommen hat. Und klar: das dauert (leider) auch... ==== Absolutely so – even when you don't actually need it all the time print preview is a super helpful feature with problematic files/documents when you want to single out potentially problematic spots therein (like e.g. too much ink coverage). InDesign has been doing this right for years by now, as well as letting you set overprinting on an object level (and not just globally for certain colours). Just like you I do hope that the guys at Serif will look closely at what has become a common standard in professional design and pre-press usage (due to Adobe – in this respect – good example). Professional users will most likely expect thes features in an application that has seemingly taken up the challenge to make its stand against the champion still ruling the market. And yes: this might take a while (unfortunately)...