Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Publisher: RGB 0/0/0 Black doesn't map to CMYK 0/0/0/100


Recommended Posts

According to conversion charts like this; https://www.rapidtables.com/convert/color/cmyk-to-rgb.html CMYK black should convert to RGB black, and CMYK white converts to RGB white.

For example; CMYK 0/0/0/100 = RGB 0/0/0 (Black)

However, if you open the Publisher colour chooser and play around with the sliders, you'll see it doesn't do the conversions like this. Here's what Publisher does;

Selecting CMYK 0/0/0/100 on the CMYK sliders gives you RGB 35/31/32 (Some sort of dark grey??)

Selecting RGB 0/0/0 on the RGB sliders gives you CMYK 72/68/67/88 (Some variation of rich black??)

And here's the funny thing. If you select CMYK 0/0/0/100 on the CMYK sliders, switch over to the RGB sliders (which read 35/31/32) and just *touch* one of the values without even changing it, the CMYK values suddenly flip over to CMYK 68/67/65/74 ! Where'd that number come from? This seems a bit buggy to me.

Is there any way to tell Publisher to use the normal RGB->CMYK conversions, i.e. RGB 0/0/0 -> CMYK 0/0/0/100; This would make life much easier when switching colorspace from RGB to CMYK for sending to a commercial printers, for example. As it is, I have to manually go through the document, select all the black text, and change the colour to CMYK 0/0/0/100

 

Link to comment
Share on other sites

Hi @jhonan, and welcome to the forums!

Yes, you're right, the kinds of smart basic colors like [Black] in InDesign are not supported in Publisher, so what you get when making a CMYK<->RGB color model switch in the Color Panel is a conversion between the document color profiles (the latent one initially being determined by the setting you have in Edit > Preferences > Color). 

9 hours ago, jhonan said:

And here's the funny thing. If you select CMYK 0/0/0/100 on the CMYK sliders, switch over to the RGB sliders (which read 35/31/32) and just *touch* one of the values without even changing it, the CMYK values suddenly flip over to CMYK 68/67/65/74 ! Where'd that number come from? This seems a bit buggy to me.

It is not a bug, though. Note the lock in context of the Color panel: it prevents color conversion from happening simply by the switch of the color model, so when having the lock turned on, you need to "redefine" the color value (use the arrow controls, or re-enter the existing color value) in order to make that happen. In apps like Illustrator and InDesign, you would perform similar profile based conversions just by switching the color definition models between CMYK and RGB, so the behavior is in line with these apps.

However the kinds of smart swatches and expected behavior that you mention (e.g. producing RGB and CMYK documents from the same source, where [Black] produces RGB 0,0,0 in RGB exports, and K100 in CMYK exports), are missing, which causes lots of problems to users of these apps.

[Addendum: in other respects than missing the smart basic swatches, the behavior you describe is by design in color managed apps, so the kinds of abstract, profile-less conversions done by web sites you mentioned, should generally never be carried out to get good results.]

Link to comment
Share on other sites

4 hours ago, lacerto said:

Yes, you're right, the kinds of smart basic colors like [Black] in InDesign are not supported in Publisher, so what you get when making a CMYK<->RGB conversion is a conversion between the document color profiles (the latent one initially being determined by the setting you have in Edit > Preferences > Color).

Thanks for the reply, and for welcoming me to the forums.

Even if this behaviour isn't a bug, it's certainly an inconsistency in the interface of the Colour Chooser. I tried a few more combinations using Colour Chooser, basically selecting a value using the sliders in the RGB screen, and then checking to see what corresponding CMYK values I'm getting. Here I've created an RGB/8 (sRGB) document

Let's start with the colours that give CMYK its name;

RGB 0/255/255 (Cyan) -> CMYK 52/0/13/0 - should be 100/0/0/0

RGB 255/0/255 (Magenta) -> CMYK 27/82/0/0 - should be 0/100/0/0

RGB 255/255/0 (Yellow) -> CMYK 6/0/96/0 - SO CLOSE!

RGB 0/0/0 (Black) -> CMYK 72/68/67/88 - should be 0/0/0/100

Now onto the other basic colours;

RGB 255/255/255 (White) -> CMYK 0/0/0/0 - CORRECT!

RGB 255/0/0 (Red) -> CMYK 0/100/100/0 - CORRECT!

RGB 0/255/0 (Green) -> CMYK 62/0/100/0 - should be 100/0/100/0

RGB 0/0/255 (Blue) -> CMYK 88/77/0/0 - should be 100/100/0/0

Why is this issue important? - Because for commercial printing you're using some combination of four plates; Cyan, Magenta, Yellow and Black. If I'm in a CMYK colour space document, and I want to pick 'Yellow' for a block of text. I open up Colour Chooser but I'm on the RGB slider panel so I select 255/255/0 (That's yellow, right?) - My text changes to yellow, I produce my PDF and send it to the printers. But the colour separation isn't giving me a 100% yellow plate for my text, it'll give me 96% Yellow, with a 6% Cyan plate - how'd that get in there?

On the other hand, I want to change some text to Red - I quickly select 255/0/0 on the RGB slider, it maps to 0/100/100/0, and at the printers I've got a 100% Magenta and a 100% Yellow plate. Everybody's happy!

And here's the worst part. I have a load of text I want to print in Black. It's important that it only uses the Black plate at the printers, since I don't want to get blurred text by 4 plates not aligning. I know that pure Black will use only the K plate. I select my text, open up the Colour Chooser and pick RGB 0/0/0, that's black, right????....

Wrong.... It gets to the printers, my 'Black' is actually CMYK 72/68/67/88, resulting in 4 plates being used to print my text. And a blurry mess. I wouldn't want to be creating a 300 page book in Publisher and accidentally select RGB Black.

Arguably I should stay away from the RGB sliders when working in the CMYK colour space, and I can understand why this conversion between colour spaces has to happen Also, the other colours I tested aren't as important as Black. But Black is the important one; Does RGB Black really map to different CMYK values depending on the profile? How about a preferences checkbox that says something like 'Do direct RGB -> CMYK mapping in colour chooser' to at least map the 8 basic RGB colours directly to the CMYK equivalent?

Edited by jhonan
Fixed RGB value
Link to comment
Share on other sites

It's not as straightforward as you think, those online tools are simplified and mostly nonsensical. Your conversion to CMYK goes through a colour management process that uses ICC profiles and rendering intents.

Link to comment
Share on other sites

5 hours ago, jhonan said:

But the colour separation isn't giving me a 100% yellow plate for my text, it'll give me 96% Yellow, with a 6% Cyan plate - how'd that get in there?

The conversion is based on your document CMYK target profile. If you start with an RGB document (let's assume sRGB), then the default CMYK target is determined by the CMYK color profile you have defined under Edit > Preferences > Color (default being US Web Coated v2). You can change that later as per document if you choose Edit > Document Setup > Color and switch from RGB to CMYK (but should note that Pixel layer objects will be converted when you do so). You can switch back to RGB if you wish but now your latent, underlying CMYK profile would be different. This profile will determine how your (s)RGB based color definitions will be translated when you create CMYK exports. Conversely, if you create your document initially in CMYK color mode (and specify a CMYK target profile), the latent RGB profile will be determined by the setting in the Preferences (default being sRGB).

In a nutshell: all color conversions always happen based on the underlying color profile pair (RGB and CMYK), and that's how it should be (and is in all color managed, professional design apps). That means that e.g. the kinds of abstract (mathematical) conversions you mention rarely ever happen. Instead, the color values are adjusted so that appearance of the converted color is as close to the source color as possible, considering the specs, e.g., when converting to CMYK, taking into consideration print conditions (sheet fed/web, US/European/Japan press, the kind of stock you are printing on e.g. glossy / lightly coated / matte / uncoated / newsprint / yellowish etc.).

The kinds of mappings you are missing (between RGB pure black and K100), are not colorimetric but practical conversions especially for body text, and sadly these kinds of mappings or standard swatches are not available in Affinity apps. But for anything else (e.g. big black color areas), you would typically want an RGB 0, 0, 0 black to be converted to four-color rich black (based on profile, if not using a direct CMYK blend for specific kind of rich black). In the other way around K100 to RGB 0, 0, 0 would still be useful, though, but you would get dark gray.

Link to comment
Share on other sites

33 minutes ago, jhonan said:

And here's the worst part. I have a load of text I want to print in Black. It's important that it only uses the Black plate at the printers, since I don't want to get blurred text by 4 plates not aligning. I know that pure Black will use only the K plate. I select my text, open up the Colour Chooser and pick RGB 0/0/0, that's black, right????....

No, RGB 0/0/0 is visually black but doesn't mean CMYK 0/0/0/100. Since RGB and CMYK are different color spaces it needs conversion, that is where the color profile matters and rules. (compare: 1 litre = 1 kg only for some liquids, e.g. water (at a certain temperature))

Aside the required conversion, note that a visual black (≠ 100 K) in CMYK can get achieved with several settings, for instance you can use more K and less CMY or do it vice versa and use more CMY and less K. This is what is called UCR vs GCR, an option which is not available yet in Affinity. Additionally the printing ink K is not a neutral, "colorless" ink but for instance in Europe ("Euroscale" DIN 12647-2) may appear yellowish while K ink in Japan looks rather blueish. That is why a so called "Rich Black" in Europe often gets set with more Cyan than Yellow, to compensate the brown tint of the black ink.

53 minutes ago, jhonan said:

Does RGB Black really map to different CMYK values depending on the profile? How about a preferences checkbox that says something like 'Do direct RGB -> CMYK mapping in colour chooser' to at least map the 8 basic RGB colours directly to the CMYK equivalent?

Correct, colour profiles influence colours, accordingly changing a profile, too. So if you started a CMYK document in profile A and then your printer requires profile B you better don't simply choose this profile in the export dialog window but switch before in your Affinity document: There you have the option to press the "Assign" button before confirming with "Okay". That way you can avoid conversion of colour numbers in your palette – but accordingly may get a different appearance on screen.

Unfortunately Affinity still lacks in the export option to maintain colour swatch numbers, for instance as used in a logo of a corporate design to get printed in 100 Cyan instead of a converted mixture. This article describes the problem and a possible solution for InDesign with its option to "preserve numbers".

In Affinity it is confusing quite a few users and did cause several related topics in the Affinity forums, for instance …

macOS 10.14.6, MacBookPro Retina 15" + Eizo 27"

Link to comment
Share on other sites

15 hours ago, thomaso said:

That way you can avoid conversion of colour numbers in your palette

To be precise, Affinity apps cannot do this when they convert from one CMYK profile to another (or from one RGB profile to another), which is a sad omission since it means that you lose all swatch assignments. So they instead of redefining the values of the swatches of the color palettes (which InDesign does), simply just convert the color values of objects themselves, causing quite a mess in a project that has all colors assigned with swatches. Therefore in Affinity apps conversion can be a highly destructive process (but can happily be easily undone if noticed immediately). Conversion would nevertheless be what you'd often want to do, especially when converting between clearly different profiles (e.g. from coated to uncoated stock), to get best results, but when the switch is small [or when there is no need for massive immediate conversions, like when having mostly just placed images that get converted or tagged for conversion at export time], assignment works just fine.

In all conversions (and especially in context of export time conversions where color numbers will always be converted in Affinity apps), the InDesign kind of [Black] definitions are invaluable. As mentioned, they also guarantee that K100 definitions will be pure RGB 0, 0, 0 black when creating RGB based exports.

Link to comment
Share on other sites

17 minutes ago, lacerto said:

To be precise, Affinity apps cannot do this when they convert from one CMYK profile to another

To me the "Assign" button appears to work that way: Swatch numbers of CMYK swatches are maintained + stay assigned to objects, while raster image colours do change with the conversion.

– Compare also:

 

macOS 10.14.6, MacBookPro Retina 15" + Eizo 27"

Link to comment
Share on other sites

Thanks for all the replies, they're very helpful.

I'd like to narrow this down to one simple issue; If I'm sending body text to a commercial printer, I want it to appear as 100%K 0/0/0/100 even if I switch profiles.

When I create a CMYK document from scratch, everything works as it should.

"File / New / Press Ready / A5" Gives me a CMYK/8 US Web Coated SWOP v2 document.

If I create a Frame Text Tool or Artistic Text Tool it defaults to 100%K, great!

But, I realise I've selected the wrong colour profile so I click on 'Document Setup' and pick Color Profile 'Coated FOGRA27 with 'Convert' selected, and click OK

Oh no! - My nice 100%K text has now been converted over to some 71/71/65/77 'Rich Black' value! :(

I'm fine with illustrations or blocks of black converting over, since black in that context might appear better as a rich black. But I certainly don't want my text going to the printers as anything other than 100%K - I want my printers to use the K plate only.

And now, I can't revert that change! - If I change back to the US Web Coated SWOP v2 profile, what was originally 100%K text now becomes 67/68/66/75

Which means that if I pick a CMYK profile when I create a document, I need to remember not to change the profile at any point or I'll lose my 100%K text. I'm not sure what I'd do if the printer comes back to me and asks for a different profile? - Do I click 'assign' instead of 'convert' in that case?

Link to comment
Share on other sites

7 minutes ago, jhonan said:

But, I realise I've selected the wrong colour profile so I click on 'Document Setup' and pick Color Profile 'Coated FOGRA27 with 'Convert' selected, and click OK

So, why not pick Assign instead?

-- Walt

Desktop:  Windows 11 Home, version 21H2 (22000.613) 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 
Laptop:  Windows 10 Home, version 21H2 (19044.1706) 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
        Affinity Photo 1.10.6 (.1665) and 2.0..3  and 2.0.3.1670 beta/ Affinity Designer 1.10.6 (.1665)  and 2.0.3 and 2.0.3.1670 beta / Affinity Publisher 1.10.6 (.1665)  and 2.0.3 and 2.0.3.1670 beta
iPad Pro M1, 12.9", iPadOS 16.3, Apple Pencil 2, Magic Keyboard

      Affinity Photo 1.10.6 and 2.0.3 / Affinity Designer 1.10.6 and 2.0.3 / Affinity Publisher 2.0.3

Link to comment
Share on other sites

49 minutes ago, walt.farrell said:

So, why not pick Assign instead?

Yes, I think that's what I need to do.

I must admit to not fully understanding how Colour Profiles are used by the printers and why they're important during document creation. But that's the subject of another investigation!

Edited by jhonan
Link to comment
Share on other sites

1 hour ago, jhonan said:

And now, I can't revert that change!

By the way: if you use saved text styles, it may be easy to update and re-define their text colour to 0/0/0/100 at any time.

Also, the Find and Replace Panel gives you the option to let it search for a certain text colour and replace with the desired colour it in all text in your entire document without the need to use the 'find' / 'replace' fields. (regardless of saved text styles)

476422602_FindReplaceformat.jpg.9c1ddc632eae895c26f95932f7d96949.jpg

360812030_FindReplacecolour.jpg.4f2aeb07cd78ddf1c512ceea28538c47.jpg

macOS 10.14.6, MacBookPro Retina 15" + Eizo 27"

Link to comment
Share on other sites

2 hours ago, thomaso said:

To me the "Assign" button appears to work that way: Swatch numbers of CMYK swatches are maintained + stay assigned to objects, while raster image colours do change with the conversion.

Yes, "assign" certainly does work without changing color values neither on objects or the swatches, but the problem is that "convert" does not change color values of the swatches, so when you convert and you have swatch assignments, their links are broken because the objects no longer have color values of the swatches. Perhaps you just used the word "palette" unconventionally to refer to object colors, but I wanted to point out that Affinity apps do not convert color values of palettes (swatches within a palette), but only the color values of objects.

However, as the video clip below shows, if the assignment is global, the assignment is still there (and the original color value), but it is broken (as can be seen if you inspect the color values or export to PDF):

So it appears that there is a clear bug in handling post-conversion swatch assignments.
Link to comment
Share on other sites

11 minutes ago, lacerto said:

(...) when you convert and you have swatch assignments, their links are broken (...)

So it appears that there is a clear bug in handling post-conversion swatch assignments.

Yes. But swatch handling in Affinity is special anyway. I'd say it is worth a separate topic. I am sure, it was reported several times before, – last but not least with the swatch ignorance issue when objects get copied between documents, even if they are global swatches in documents which have the same colour profile assigned. In various situations palette swatches in Affinity are forced by the app to be kind of useless – aside colour conversion issues.

macOS 10.14.6, MacBookPro Retina 15" + Eizo 27"

Link to comment
Share on other sites

14 hours ago, walt.farrell said:

So, why not pick Assign instead?

In context of changing from U.S. Web Coated v2 to Coated Fogra 27 (both allowing pretty high total ink coverage values) this is a valid question, but assignment cannot [always] be used if profiles differ significantly from each other. To avoid simplistic instructions, let's see what happens when reassign is used when changing from Fogra 27 to newsprint stock, e.g. ISOnewspaper26v4, which allows max ink coverage of about 240% (many newspaper profiles might have max TIC below 200%):

So simply just reassigning would in this case produce a print file that has over 100% too much ink and would be rejected by the printer (and if not, produce catastrophically dark mid and shadow tones).

I used a newspaper profile just to accentuate the importance of making right selections when changing profiles, but the choice becomes relevant already when changing from standard coated profiles to e.g. ISO Coated v2 300% (ECI) -- a very common profile used for coated stock in European press, which allows about 45% less ink than e.g. Coated Fogra 27. You cannot [necessarily] just reassign the profile in situations like this, but [might] have to convert [-- whether this is needed depends much on how much control is needed and how massive immediate conversions need to be done and how much can be left for the export time conversion]. And then change "inadvertently" converted K100 back from rich black to K100. You can often facilitate that with styles, or Find / Replace formatting, but just supporting [Black] in the style of InDesign would make such operations unnecessary.

Link to comment
Share on other sites

34 minutes ago, lacerto said:

You cannot just reassign the profile in situations like this, but must convert. And then change "inadvertently" converted K100 back from rich black to K100. You can often facilitate that with styles, or Find / Replace formatting, but just supporting [Black] in the style of InDesign would make such operations unnecessary.

Even a 'Retain K100 text' checkbox in the assign/convert dialog would be a big help. Basically convert all the colours except any Frame Text or Artistic Text objects set to K100

Link to comment
Share on other sites

Yet another point worth a note is that if there is an image with adjustments (even when the image is an sRGB bitmap), changing a color profile [whether by assign or convert; and disregarding if conversion is done by using File > Document Setup, or at export time] will not cause a resolved image color values to be recalculated to fit into the max TIC of the destination CMYK profile, not even when using export methods like PDF/X-1a, which causes all color values to be flattened and converted to final target CMYK values. To achieve TIC of the target profile, the image needs to be rasterized with its adjustments before exporting.

It is difficult to say if using PDF methods (e.g. PDF/X-4) that cause rasterization only when ripping the final image, would be rendered correctly within the max TIC value of the embedded target profile, but I would not dare to leave unresolved adjustments in jobs that have unregular ink coverage requirements.

Link to comment
Share on other sites

1 hour ago, lacerto said:

Yet another point worth a note is that if there is an image with adjustments (even when the image is an sRGB bitmap), changing a color profile [whether by assign or convert; and disregarding if conversion is done by using File > Document Setup, or at export time] will not cause a resolved image color values to be recalculated to fit into the max TIC of the destination CMYK profile, not even when using export methods like PDF/X-1a, which causes all color values to be flattened and converted to final target CMYK values. To achieve TIC of the target profile, the image needs to be rasterized with its adjustments before exporting.

Who is the colour profile benefiting, as in, who uses it? - My understanding is that you set it during document production to make sure that your ink coverage % is within the correct limits for the selected stock, and that your on-screen colors match the final output as closely as possible (i.e. you're working in the same gamut range as the final printed output) - The reason we select CMYK profiles is because professional printers use a 4-colour process.

A PDF can be a mixture of CMYK and RGB elements for example (I don't even think the selected profile is stored in the PDF file) - Does the printing company read the profile or even care about it, or do they just take the PDF file as-is and work with it from there, creating the separations etc?

Theoretically, if I'm happy with a RGB colourspace document, I could output to PDF, send it to the printers and say 'print this' - The colour matching might be all over the place and out of gamut, and I might end up with holes in the page, but me telling the printing company what RGB profile I used won't stop that from happening! (Please correct me if I'm wrong about this)

Link to comment
Share on other sites

Just to give you some context, an introductory level of book on this topic will run to at least a hundred+ pages. You aren't going to learn it from a few forum posts (although lacerto's posts are very good!).

Link to comment
Share on other sites

4 minutes ago, BofG said:

Just to give you some context, an introductory level of book on this topic will run to at least a hundred+ pages. You aren't going to learn it from a few forum posts (although lacerto's posts are very good!).

Yeah, I thought I'd take advantage and try to learn a few things. Unfortunately I have very little experience in this area, as you can probably tell. But feel free to ask me any questions about Data Analytics, I've got about 30 years experience in that! 🤣

Link to comment
Share on other sites

In that case you might actually have a head start.

Colour management is mostly data manipulation. A colour profile is just a set of modifications needed so that the input colour is matched on the output side. So for example if a monitor has a particularly strong green component, the profile for that monitor would reduce the green from each input, so that it results in a correct colour, rather than everything looking a bit green.

There's a lot more to it of course, but it does all boil down to tweaking the colour data to hit the correct colour on the output.

Link to comment
Share on other sites

To look color management from the graphic designer's point of view, I think that the most important thing is that it makes it possible to use one source document to produce to multiple targets, most typically RGB (digital version) and CMYK (offset print), and for the latter, to get predictable results (when working with calibrated devices that can simulate reasonably accurately the print target color space, typically including PANTONE colors, so a wide-gamut display).

In modern ISO-color managed workflows one seldom needs to be disappointed with the results, they match pretty much what was seen on screen (including on modern laptops), no matter how the print PDFs were produced, or whether the colors were initially defined in RGB or CMYK. But that may require in certain situations checking the results with prepress tools like Adobe Acrobat Pro or equivalent (callas software pdfToolbox, and Packzview, to name two alternatives). And one must be well aware of how placed graphics (especially PDF, AI/EPS) is handled. Photos (bitmaps) are most often placed in RGB color space to not lose richness of colors; vector graphics, logos, ads etc. often in CMYK to guarantee proper handling of K-ink and brand colors. Embedded CMYK profiles are most often discarded (as the production files are already asked to be produced to correct color space and print specs) -- which however does not happen when placing such files in Affinity apps so they should be placed without a profile or with the correct target profile. Getting placed PDFs passed through is also not a trivial task in current state of Affinity apps (the PDF/X export methods are particularly problematic in this respect).

As for color mode of production PDFs, they can contain ICC (profile-based) colors either with mere profile intent or embedded profiles for all color spaces involved, and the later the PDF version the more versatile the possibilities. Basically the development has allowed more freedom for designers and more predictable results, but unfortunately that does not yet fully apply to Affinity apps. First because there are many pitfalls, e.g., one must be better educated when working with Affinity apps than when working with the competition (much because of inadequate documentation and practically no help available from printshops), and the (print) production features are not fully implemented to the level of the competition. The second reason is (IMO) that the versatility built into the Affinity apps themselves, aiming at non-destructive workflows, has made production of predictable high-quality PDF exports (that would avoid premature lower than device resolution rasterization) difficult, and aiming at comparable results requires many kinds of work arounds. So a bit frustratingly aiming at simplicity in work methods has resulted in more complexity (problems) in production.

Meanwhile, much of the print production (especially targeted to general public, hobbyists / self-publishers, and semiprofessionals) has changed to offer RGB based workflows with good results (with little money) with simpler tools like Word and Pages, and can handle things like conversion of RGB text to K100 without needing to bother the content creators with "technicalities" (they actually often do, with many that seem quite obsolete, but the point is that the printshops can provide clear step-by-step instructions that the users can follow with the supported tools and with the help of the community).

But the field is pretty large and complex and needs are highly varied so the views mentioned above might be quite irrelevant to many that use Affinity apps to get their ideas and creations produced.

Link to comment
Share on other sites

3 hours ago, jhonan said:

Yeah, I thought I'd take advantage and try to learn a few things. Unfortunately I have very little experience in this area, as you can probably tell.

As a start you might take a look on this Affinity article: https://affinityspotlight.com/article/display-colour-management-in-the-affinity-apps/

Or a view from the other, the printer's end: https://www.heidelberg.com/global/media/en/global_media/products___prinect/products___prinect_topics/pdf_1/color_quality.pdf

macOS 10.14.6, MacBookPro Retina 15" + Eizo 27"

Link to comment
Share on other sites

3 hours ago, lacerto said:

But the field is pretty large and complex and needs are highly varied so the views mentioned above might be quite irrelevant to many that use Affinity apps to get their ideas and creations produced.

That's a pretty impressive reply, thanks for taking the time to explain all that.

There are some attempts at pre-press functionality in Publisher (like the pre-flight section) which are fine for basic checks before sending to pre-press, but not powerful enough to provide all the checking and processing that a dedicated pre-press application provides. I took a look at the Packzview videos and it's insane! - So that seems like a grey area; where does the responsibility of the graphic designer end, and the pre-press person begin?

The graphic designer should at least send a 'printable' document to pre-press, but they might not necessarily have checked every single aspect of it. But on the other hand, you don't want the document going backwards and forwards between pre-press and the designer ad nauseum.

Affinity offers simplicity and guides you in a way that prevents errors (which I prefer, personally). But any errors that do creep in are then left to pre-press to discover and sort out.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.