Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Lagarto

  1. In this particular instance the first question would be what kind of coated and uncoated paper is used and whether generic profiles for coated and uncoated stock can give predictable results when printing on those papers. In OPs reply (in related post) the blueness that was tried to be achieved was not PMS based, after all, but the color just appeared in the palette for other reasons, so the hex value x0975D0 was probably sRGB based (the default underlying RGB profile in Affinity apps), and it translates to C84 M50 Y0 K0 in Coated Fogra 39 (Photoshop; C85 M53 Y0 K0 in Affinity apps) and C89 M51 Y0 K0 in Uncoated Fogra 29 (Photoshop; C88 M54 Y0 K0 in Affinity apps) so there is not much difference in color values between the two profiles. So if these values have really been used, and results are not acceptably close, I would check whether paper specific profiles are available and if so, see how the color values change when using them. I could also have a word with the printer and ask whether they can recommend some other profile or paper. If at all practical, I would ask good-quality proofs and then make adjustments accordingly, especially if it seems that the problem is not general but just related to some specific images or colors. Adjustments in Affinity apps could be easily reproduced in future, but in a situation the same colors or similar jobs need to be produced repeatedly, I would try to find a workflow based on correct profiles. If the alternative is to switch to RGB and be happy seeing the color as I wish it to appear on paper, both coated and uncoated, but knowing that this is impossible, and that I cannot do anything myself but just send sRGB colors and ask the printer to do their best, I’d definitely choose the former, take the blame if there is no reasonable match first time, but achieving consistent results probably already on second time. My main point was to make a note on usefulness of working with color profiles and calibrated displays, and have the publication in CMYK color mode when producing for regular CMYK offset print, rather than working in RGB and playing with soft proofing, or even more bizarrely, producing RGB exports and asking the printer to get colors to match on two kinds of papers. There was a time when graphic designers and museum curators needed to spend hours or even days beside a printing machine marking on fresh print proofs for each and every work of art how to improve the colors (too red, add cyan, etc.): giving vague instructions to printing personnel who were the only one who had the control. Good old times, but I guess very few would want to turn the wheel to get those work methods back, so I at least want to keep the current ones and be able to get predictable results in good time, with as little guesswork involved as possible, or dependence on specific expertise of a specific printer. So yes, I do welcome boring ISO profiles and thoroughly color managed, well tested standard workflows, not because I’d be some kind of “CMYK”-believer, but because that is practical and has given good results for a long time. If an offset print job needs to be produced using a CMYK target color profile, as it regularly needs to be, the color values exported in print PDFs will be virtually identical disregarding whether the job was created and colors defined in RGB or CMYK color mode. As Affinity apps simulate target color space on screen, the user with a calibrated display gets a good idea on how the colors will look on paper (without using soft proofing). Affinity Publisher does not offer the flexibility of InDesign in allowing a kind of a dual color mode and showing RGB colors using a document RGB profile, but the user can nevertheless make RGB color definitions and switch temporarily the document color mode to RGB, if they need to. But choosing and using RGB as the document color mode in a job that is required to be delivered with a CMYK target is in many ways impractical and can have catastrophic side effects, some of which are related to the way Affinity apps behave. E.g., the target CMYK profile to be used at export time needs to be picked by hand (if not, the last used CMYK profile or failback U.S.Web Coated will be used, which normally results in inadvertent conversion of color values), grayscale images with profiles (including D50 which Affinity apps use) cause conversion to CMYK typically with color casts and they cannot be used in PMS toning, etc. In a word, unpredictability is increased, and all kinds of workarounds are required for tasks that in CMYK color mode can be done directly. It is a different thing when creating original art, or reproducing photos on a photo printer. But this thread and a couple of other recent topics where RGB based production method has been vocally advocated, have been clear CMYK print jobs. In one post where a profile conflict caused problems, an advise was given to create K100 by using RGB 0,0,0, and solid magenta by using a spot color, for a simple reproduction of a company logo that was delivered as a vector based CMYK PDF. You can do that for a sake of discussion, or whatever secondary reason, but I do not think that anything even a bit more complex can be produced that way, or that there is any benefit as regards print quality or color fidelity, not to mention costs, in doing so. But most importantly, I do not think that such advises help presenters of the original questions, at all. Some of them are hobbyists who have had no experience of anything else than working with RGB-only apps so yes, CMYK and color managed workflows can be challenging, especially when they are not well documented in Affinity apps, and still also have some flaws and omittances. Production workflows at many popular printshops are also “Word-friendly” in a sense that they have no problems accepting non-color managed RGB-based input, but Affinity apps are not comparable to Word, and many users of Affinity apps want to have more control of the color. So “go for RGB” and leave everything to the printer is a lousy general instruction, and quite out of place in context of topics referred.
  2. I posted a related article in context of your other topic: The printer can give recommendations depending on their production workflow, but the whole point of color management in graphic design apps is that designers use calibrated devices and ISO-based color profiles, and do not need to depend on sending RGB and trusting on a "wise guy with a calibrator" at printshop to get what they vaguely describe in words or see in another product (digital or printed). It is different with single photo printing with 12-ink devices and alike, but demystification has worked well for a few decades in ISO-based print production within commercial offset printing. Color management is not necessarily a simple subject, but it is not rocket science, either. Things are hugely better now than a couple of decades ago when there was very little predictability and we were all dependent on factors on which we could not have any control. Having said that, it is always a good idea to discuss with the printer. If they say just send us RGB and tell us what you want, and you do so and you also get what you want, congratulations.
  3. Here is an example of how PMS 2935 C (for coated stock) and PMS 2935 U (for uncoated) are translated to CMYK when using different apps: pms2935_fogra27.pdf pms2935_fogra29.pdf When using PSO Coated v3 and PSO Uncoated V3 (Fogra 52), all these values would again be a bit different. And none of these values would take into consideration exact properties of a specific paper. You simply cannot give "correct", generic CMYK values. If color accuracy is important and you have a specific reference (like a PMS tone), you should use spot inks.
  4. For a bit awkward workaround, you could use clipped (halved) contoured outlines in open paths. They might work if you just need on effect and need not draw, and behave differently than brushes used as strokes so they might be useful in closed shapes as well.
  5. You're welcome. Also, I forgot to ask about the original images: if they use a wide-gamut RGB color space like Adobe RGB or are RAW images with bright and vivid colors like in the example image the violets, there is probably point in keeping the wide color space or develop into one (instead of sRGB) as typically these kinds of colors translate into the final CMYK color space better than images already narrowed down to sRGB.
  6. This is difficult since exact tones will be affected by paper specs (e.g. dot gain of paper) and if different stock has different paper whiteness it is even more difficult. I am not sure if it is a reasonable requirement even to try to achieve "exactness" (but just acceptable resemblance). I noticed in your other post that the blueness you are aiming at seems to be based on a PMS definition but produced in CMYK so I am not sure if your problem is not getting close enough with either or both coated or uncoated stock. Note that CMYK values for simulating spot colors are only approximations so they might work reasonably well with certain kinds of papers and print standards but less so with others, so if you are otherwise satistifed with colors, your problem might be related to using certain fixed CMYK values for PMS simulation. There are many kinds of uncoated papers so e.g. "Uncoated Fogra 29" is actually a generic profile for uncoated stock; and there are separate specs for yellowish papers. Many paper manufacturers have specific profiles for different papers for best results and color fidelity and if such are available I would use them (but negotiate first with your printer). If color accuracy is very important, good print proofs would be required to be able to make necessary adjustments. Discuss with your printshop and let them know about your wishes, the problem might be most easily resolved by choosing a bit different stock.
  7. There are multiple choices. Much depends on the CMYK profile you need to use for print production. As saturation of bright colors like violets in this particualr image will get dullened a bit in CMYK conversion, there might be point in doing the color conversion in Photo and adjusting the colors and then place a CMYK TIFF version with correct print profile embedded in Publisher. This shows a minimal benefit of pre-processing the image (in the example the paper would be uncoated stock with max total ink of 240%): On the other hand, if you also need to create an RGB (digital) version, producing separate versions for both color spaces might be a good idea, as the preprocessed CMYK image would not work well in digital version: If the print will be made on coated stock with standard profiles like ISO Coated v2 or PSO Coated v3, I would probably not bother to preprocess anything but just place RGB images in Publisher and then process the images directly using adjustments (e.g. levels/gamma, HSL, etc) when needed. Note that even if Publisher shows colors on screen simulating the printer color space (when you have a CMYK document profile), you can still produce full RGB-gamut PDFs as long as the images are in RGB color space. Preprocessing images in CMYK is typically useful only in situations where you need to limit ink usage and check that key colors are not lost in profile based color conversion. Some individual images might also need special attention and require preparing separate versions for print and digital. But as long as you are printing to offset, you should use CMYK document color mode in Publisher. Having preprocessed CMYK images in layout requires special attention as you need to use and embed the same profile with images as you use in your publication, so for this reason just placing (s)RGB images is more carefree.
  8. It is not clear from the video what has caused this problem, but it seems that your 0975d0 swatch might have actually been created in CMYK mode and just renamed using the hex notation. When you assign on the video the 0975d0 swatch to the object and then double click the fill color well on the Color panel, it can be seen that you have CMYK sliders active and the CMYK values are percentages. At least on Windows this is an indication that the color definition of the object has been given and saved as a CMYK value. If an object with an RGB definition is selected, the CMYK sliders show 8-bit values (0..255). In the example below Coated Fogra 39 is used as the CMYK color profile (and sRGB as an underlying RGB profile). First an RGB swatch is created using hex notation #0975d0 which will get a CMYK conversion value of C85 M53 Y0 K0 in this profile context. Then a CMYK swatch is created using the C85 M53 Y0 K0 definition which will get an RGB conversion value of #256db5 in this profile context. The other of the blue rectanbles has the RGB version swatch assigned, and the other the CMYK version. When the fill well of the Color panel is double clicked, the color mode of the swatch definition is reflected in the CMYK slider values: they are percentages when showing color values for a CMYK based swatch, and 8-bit values when showing color values for an RGB based swatch. I am not aware of a situation which could cause an RGB based color definition in an application palette to convert to CMYK, but I have very little experience on application palettes. Is this a palette that you have used with multiple publications? Can you check whether its saved color definition for 0975d0 is really CMYK based or RGB based (or if this could be just a document-specific problem)? Anyway, when I tested these definitions with a variety of different color profiles, both swatch definitions correctly retained their original definining color values (but were naturally converted differently to equivalent CMYK and RGB values depending on the profile).
  9. There really might be point in creating a separate topic! The problem of the original post was related to a profile conflict and the problem was fully resolved when the conflict was removed. The problem had nothing to do with different PDF production versions, nor inclusion or exclusion of color profiles at export time (four-color black is generated in this scenario disregarding whether color profiles are embedded or the color intent included, and disregarding which PDF production version is used) .
  10. Letting the user know the number of objects and nodes (points) at least lets them check that everything is transferred on file exchange (as below, between CorelDRAW and Adobe Illustrator): In addition, in Illustrator, the stats are shown as per selection, which also helps checking that correct selections have been done (especially if they have been made across multiple layers).
  11. Which document color mode do you have in Publisher? It looks as if you might have CMYK color mode, in which case colors are shown according to the print profile you are using. Here is an (extreme) example of having the same image in CMYK mode (using ISO Newspaper profile), and RGB mode (using AdobeRGB). The difference is not so clear here as the saturation of AdobeRGB based image is toned down by conversion to sRGB color space used in the forum.
  12. All these problems go away when Publisher gets the passthrough feature properly implemented. It is so far only in beta and still buggy.
  13. So, to fix this, ensure that you have "Euroscale Coated V2" as your CMYK profile in Preferences > Color. Then refresh or replace you advertisements.
  14. Here is your file exported in PDF/X1a:2003. All K100. black_pdfx1a.pdf EDIT: Explanation: your -afpub file shows the following in the Resource Manager: So there is a profile conflict. The reason is probably that you still have U.S. Web Coated v2 as your default CMYK profile in the Preferences > Color. Your 2coulours.pfd does not have embedded color profile so it will be assigned the "working" CMYK color profile. That is NOT necessarily your document color profile, but the profile that is specified in the Preferences > Color.
  15. I think that much of this information (e.g. need to tinker with system registry or manipulating the application manifest) is outdated. All Nik Collection 2 plugins actually operate fine in Windows 10 in high-res environment when started independently, without even needing to access the compatibility tab (which is in current Windows versions the easiest method of telling how apps should scale). There is clearly something that DxO can do as most of the DxO version 3 plugins now operate fine in high-resolution environment also with Affinity apps, but it does not explain it all. Photoshop CS6 and 2021, and PhotoLab4 can use all Nik Collection 2 and 3 plugins in high-resolution environment without any problems and without a need to specify any resolution or scaling exceptions.
  16. There is an app called SwitchResX (commercial) that seems to be able to apply app-specific resolution + app scaling settings but it is a kind of a hack and therefore not available from App Store, and it is unclear whether it would work as expected in plug-in environment (even if the hosting app like Photo would be forced to operate in lower resolution). The problem is clearly related to integration to the hosting app as all Google version plugins work as independent .exe files without problems with high-res screen. Affinity apps are not the only one experiencing this problem, I noticed that Corel PhotoPAINT (2017 version) has the same problem. EDIT: There might be point in trying out if DxO versions behave differently. I have PhotoLab 4 and it can use Google version of Nik Collection plugins without problems in high-res environment so it is clear that correct behavior is not a "Photoshop-only" feature. But DxO is of course also a specific case. EDIT2: I tested this now and most of the plugins in the DxO package work now ok also with Photo, but not all (e.g. Analog, Color, HDR and Silver Efex, and Sharpeners show standard size controls, but Dfine and Viveza 2.0 do not).
  17. As you are on Windows, you can easily fix this by changing the screen resolution and using one that works well with 100% app scaling. After that you get normal size controls. I think it is somehow Affinity-related problem: Affinity Photo just cannot handle plug-ins with high-res displays (like below, with 3840 x 2160 px screen) using app-scaling: ...while Photoshop CS6, about 10 years old software, can: After you change the display resolution, everything works as it should also on Photo: I suppose temporary changing of app scaling is possible on macOS, too, but it may require some trick.
  18. You mention both methods. If you use default "PDF (press ready)", it embeds the document profile which is a mistake as it causes the PDF viewer to display K100 blacks as four-color if the viewer is not using the right profile. On the other hand, if there is no profile conflict, exporting with PDF/X methods should be fool-proof and you should get blacks displayed correctly.
  19. So they mention. Perhaps something went wrong when creating the print exports (e.g., as a default the profile is included, which causes confusion even if correct color values are output). I am just describing how Publisher behaves, and it is easy enough to reproduce this to verify that this is what happens. a) PDFs placed in a document that has Euroscale Coated V2 as document color profile and the same profile as the CMYK working profile. The other PDF is without profile and the other one has Euroscale Coated V2 embedded. When exporting to PDF/X1:2003a with default setting, you get K100 for both PDFs: The same files placed in a document that has PSO Coated V3 as the document color profile, exported as PDF/X1a:2003. You get rich blacks: So, nothing else has changed than the document color profile. euroscalecoated_placed_euroscalecoateddocument_pdfx1a.pdf euroscalecoated_placed_psocoatedv3document_pdfx1a.pdf
  20. This problem will be corrected when passthrough (currently in beta) is implemented. At the moment the black (K100) in placed graphics (e.g. AI and PDF) stays what it is only if the placed file uses the same color profile as the document where you place it (and which is used when exporting the print PDF). This condition is true if the placed file has the required profile embedded, or if it is a file without a profile and your working space CMYK profile (specified under Preferences > Color) is the same as the current document color profile. Files without a profile will be assigned a profile according to the color profile settings made in the Preferences.
  21. Thanks. I need to save all these workarounds as I never manage to reproduce them otherwise (especially as I am not using Affinity apps yet much for production)! Perhaps there is a common logic on which to build but I have not managed to figure it out yet. But it is always rewarding to just reproduce your solutions and trying to understand a bit more of the inner workings of these apps.
  22. Ok, thanks, good to know. EDIT: I checked this on Windows (both CS4 and CS6, InDesign and Illustrator), and setting of appearance of black does not have any effect on this. I have both apps simulating rich black on screen but get K100 as K100 via Clipboard even when source and destination CMYK profiles mismatch. So perhaps this is a macOS issue, after all.
  23. I tested this now with CS4 Illustrator and InDesign (Windows versions), and copied a rectangle with K100 as fill and rich black (entered as RGB 0, 0, 0) as outline in a source object using Euroscale Coated and Publisher destination CMYK document using the default U.S. Web Coated and get the exact values copied across via Clipboard. The exchange format is PDF here, as well. I do not have macOS versions of Adobe apps installed but I wonder if this could be a "Paste As" issue so that for some reason Affinity apps cannot read the PDF format placed on the Clipboard? UPDATE: Just to clarify, the default paste format on Windows is PDF so I do not need to use "Paste As".
  24. Also, as mentioned, at least with CS6 Adobe apps, only color values are copied and the format used for data exchange via Clipboard is PDF. The CMYK color spaces between the source and destination can differ as mere values are transferred. I have older CS versions installed on some computers so I can check if there is a difference.
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.