lacerto

I am not sure what you ask... This scenario was already explained and demonstrated above: having a Gray/8 document color mode, defining colors in grayscale or RGB (virtually same) and exporting using PDF/X-1a method to produce DeviceGray output (no ICC-dependencies, but just output intent description, so nothing to be resolved), the crucial thing being ability to choose a press-specific grayscale profile (which has to be fetched and installed separately). Obviously OP did not have such a profile installed so they were not able to produce such a file, so in lack of an appropriate profile, the ICC profile field is left blank, and Affinity app will use the app default US Web Coated v2 as the target profile, resulting in all black definition becoming converted to four-color black. So OP ends up using a workaround, producing PDFX-1a in CMYK document color mode with K-only definitions, producing DeviceCMYK file on mere K plate, and converting the file afterwards to Grayscale 1-ink file. As mentioned, the printer's requirement appears to be unreasonable, but it is possible that they have been offered grayscale exports with 4-color black, and PDF/X-1a CMYK exports with 4-color black, either as a result of profile conflict (document vs. export time), or because of PDF compatibility violation (and resulting rasterization), etc. Or, because of having been offered an ICC-dependent file (even if otherwise meeting the specs). Some printshops have automated preflight checks that may discard a job for practically irrelevant reasons. So the advise given for "Grayscale" might have been a reference to need of having one ink (grayscale job), whether DeviceGray or DeviceCMYK with K plate only, and with no ICC-dependencies. PDX-1a is probably referred as for requirement of needing to have transparencies flattened. As explained in many posts on this forum, this primordial requirement is probably made in sincere belief that it is easy to achieve, and that it is a fool-proof method of guaranteeing expected results on paper (as basically what the client sees is what they get, since nothing will be left to be resolved at RIP-time). But within Affinity ecosystem, depending on complexity of publication, producing PDFs meeting these kinds of primitive specs, can become a challenging job that takes lots of knowledge and experience, or long trial-and-error workflow -- especially if a proper preflight tool is not available.

Thanks, @Hangman. For additional information, I actually managed to export using this specific file at least partially rasterized SVG files also in a situation where I had all or part of the objects selected. Clearing the selection and selecting again might have resolved the problem, so I could not determine a clear reason for the rasterization. It might be related to the structure of the document, having all transparencies specified for the group container and then objects themselves having passthrough as inherited blend mode.

You could try using the following setting to create a DeviceGray PDF. You need to define your black elements using Grayscale color model (in Colors panel). The point is to leave "Embed ICC profiles" unchecked. That messes up a job because it makes it ICC-dependent, and if your printer asks for grayscale PDF/X-1a, they basically want a job with 1 ink and no color profiles. (They additionally want it without live transparencies so if you have such things, just go on with PDF/X-1a and then optionally convert to grayscale (if you do not have grayscale print profile to be used); but you should also understand that if your design contains any PDFs placed for passthrough, they will all be rasterized if you use PDF/X-1a whether containing transparencies or not, even if the rasterized image will stay DeviceGray; using PDF 1.7 does not rasterize any of your placed PDFs, nor does it flatten transparencies).

That is odd. I cannot produce such a file in any layout app [other than Affinity based], since PDF/X-1a basically only supports CMYK (+ spot) color mode. So if grayscale is truly required, you need to force conversion of grayscale as a post-production operation anyway. I just did it for a check (post-processed PDF/X-1a to DeviceGray), and then ran the PDF/X-1a compliance check on the file, and it was passed. So obviously it does not cause problems. But it is an odd requirement, and possibly stems from RGB production environment [e.g., something like Word] not supporting CMYK, but capable of presenting RGB in grayscale (to guarantee one ink only) and tag it as PDF/X-1a [creating a non-ICC-dependent file, possibly even flattening transparencies].

I am about to install the 64-bit version, so I soon see. But I already found the following: Acrobat 2020 is originally a 32-bit app. However, it includes OS compatibility features that enable it to run on 64-bit operating systems. For more information, see System Requirements for Acrobat Pro 2020, Acrobat Standard 2020. So what this probably means is that the core of the app is still 32-bit (on both platforms), but it has those "compatibility features" (whatever they are) that let it run on 64-bit OSs... https://helpx.adobe.com/acrobat/faq-acrobat-2020.html#:~:text=Acrobat 2020 is originally a,Pro 2020%2C Acrobat Standard 2020.

Adobe Acrobat Pro 2020 on Windows is still a 32-bit-only app -- it is clearly a kind of a deliberate annoyance in order to urge Windows users to go for the subscription based DC version. That's why I was interested in knowing what kind of solution Adobe has to be able to sell the app for 64-bit macOS, including Sonoma. It definitely requires Rosetta, as it is Intel only, but whether they have a genuine 64-bit build for macOS for the actual app, or just some kind of a front end, was my main interest (as that would avoid 2GB RAM barrier and errors that I sometimes experience when opening huge PDFs on Windows). EDIT: Just checked, and happily it seems I am wrong, since I just found a download link for a 64-bit Windows version of Adobe Acrobat Pro 2020 -- it was that on my logged in Adobe downloads site, for some odd reason only 32-bit version was offered...

Have you tested, or is this just based on assumptions? I ask because Adobe still sells Adobe Acrobat Pro 2020 stating that it is compatible with macOS post-Mojave, including Sonoma. https://helpx.adobe.com/acrobat/system-requirements-acrobat-2020.html This is so clearly stated in system requirements for macOS that I suppose it is true (but I can understand if they do not advertise this). This of course means that the macOS version must at least have some kind of a 64-bit front end that is capable of running a 32-bit Intel module, since I do not believe that they have created a 64-bit Intel build just for macOS (but this is of course possible, considering that 64-bit Safari browser plug-in is mentioned) -- which would kind of suck considering Windows users; needing to run a 32-bit module is sometimes an annoyance when opening large files that break the 2GB RAM barrier. But this forum is probably not the best place to find out how Adobe Acrobat Pro 2020 runs on modern macs and M3 processors on latest Sonoma 🙂

Note that you could export PDF/X-3 or PDF/X-4 based Grayscale PDF also from Affinity apps, but you need to have a true grayscale print profile installed on the system (I am not sure but on macOS you might have Generic Gray inherently available [UPDATE: Checked, and Generic Gray Profile is inherent on macOS, but is not available whenever using PDF/X-based method]; on Windows [UPDATE: and on macOS, too] you would need to fetch one from the Internet, or have one that comes with QuarkXP or Adobe available), since the only grayscale profile that comes with Affinity apps (Greyscale D50) is basically a display (Gamma) color profile and not selectable when you have a CMYK or Gray/8 document color mode and convert to Grayscale, and use PDF/X-based export method: If you leave the profile empty (or do not have anything available), all the blacks defined above would be converted to four-color black and have Affinity app default U.S. Web Coated v2 marked as the output intent profile. If you do define a true grayscale color profile as output intent, RGB 0,0,0 and B:0 (Grayscale 0) will be output in ICC-dependent 100% Gray (CalGray/ICCBasedGray), but K100 will have something like a 92% value. See below a PDF/X-3 with no explicit press-specific grayscale output intent (U.S. Web Coated v2 auto-assigned): pdfx3_gray_from_cmyk_noexplicit_output_intent.pdf ...and a version where a true grayscale output intent is defined: pdfx3_gray_from_cmyk_quark_genericgray_output_intent.pdf UPDATE: The same applies to PDF/X-4 production (and in PDF/X-1a only CMYK color mode is available). If you do not have to use PDF/X-based export method, but force the Grey color space, the default Greyscale D50 would be available, but then, too, K100 values would have non-100% gray values. So whenever forcing grayscale output, you need to have native color values (text and shapes) defined either in RGB or Grayscale, not CMYK. There might be point in checking whether the printer truly needs PDF/X-based output in grayscale, or whether they just meant K-only output (but accept any regular non-PDF/X based CMYK-based output, as long as CMY plates are empty). UPDATE: And if they just meant K-only, then the correct method to produce such PDFs is to choose CMYK document color mode and export to CMYK, and make sure that all native objects have K-only color definitions. There are plenty of other considerations that need to be checked when producing press PDFs from within Affinity apps, so the issues related to grayscale are only one of the concerns (but one of the most frequently experienced, and confusing, probably much because the very different K/Grayscale approach/policy used in Adobe apps within CMYK/press-related production). In this context, paying Adobe for Acrobat Pro -- still also available as a 32-bit app on a perpetual license, though I am not sure how it is made to be operable on modern macs -- is not money wasted. pdfToolbox by callas software would be an alternative (still more expensive than Acrobat Pro). Free Packzview is not a prepress tool but is useful for decent preflight (it appears to be generally available only for professional use, though).

You cannot produce grayscale (8-bit) PDF/X-based PDFs using Affinity apps. All forms of color definitions (RGB, Grayscale, CMYK) will be converted to CMYK disregarding the target color mode selected at export time, whenever PDF/X-based export method is used. Technically PDF/X-3 and PDF/X-4 would allow ICC-based gray to be exported, and this is what happens if you do this from e.g. InDesign. But when done in Affinity apps, your definitions of gray and black will always be converted to rich black (four-color black). You can produce grayscale PDFs based on Gray/8 document, but then you need to use non-PDF/X-based export method and explicitly export to Grayscale (and define your black/gray either using Grayscale or RGB color model; K100 will basically be converted to RGB and then presented as a converted CMYK value). If your printer requires a PDF/X-based print PDF, you need to switch the document color mode to CMYK and then specify your blacks and grays using CMYK color model, and K-only values. The PDF output will be basically CMYK, with CMY 0 and with K-only values. Grayscale images that you place, will by default have "K-Only" button (available in context toolbar) applied, and will be exported as grayscale images.

There is additionally a more fundamental issue with Affinity SVG export where objects with transparency that can basically be exported without issues, are more or less randomly exported as images, instead of objects with an opacity attribute. So for the attached .afdesign file, you would get two kinds of SVG exports without obvious cause for the behavior: transparency.afdesign transparency_ad_selection_rasterized.svg transparency_ad_selection_objects.svg

You can apply a desired F/X (like on the clip below, drop shadow and decrease of saturation) on an image and then apply that style in one go by selecting all images in the publication: copy_paste_style.mp4 Note that you can similarly remove F/X in one go from all images by removing them from one image, then selecting all image, and copy pasting the F/X. Here's the result when exported to press PDF:

Hi @Ben in Texas, In lack of GREP styles in Publisher, you can manually use RegEx in Find Replace and either of these two search criteria: \<(\s?(\S+)){2}$ or .\S+?$ and then have "No break" as formatting in Replace field, to force at least two words in the last line. There was once a longish discussion on the forum of usefulness of this kind of feature (if it could be applied automatically). as there is no paragraph composer in Affinity Publisher that could balance problems resulted from automatically applying this kind of a rule. Here is a clip that demonstrates the difference of the two RegEx clauses (the latter accepts a hyphenated word as a word on the next line, the former requires two complete words; there was a mistake in the original post). The clip also demonstrates the benefit of having a paragraph composer calculating dynamically changed word wrapping (as far as I know, only available in Adobe apps): Single_vs_paragraph_composer.mp4 As mentioned, the feature cannot be applied as a paragraph style (in Affinity Publisher), but with the improved Find Change it can be applied selectively to specific scope and confirmed one-by-one, so potentially useful, and at least as an exposer of runts.

Ok, thanks for the update. Everything being native, it is strange that you have experienced such issues. Having some kinds of issues with highly complex constructions with lots of layers with live adjustments, effects, blend modes, opacity etc. would not surprise, and it would be interesting to here someone's experiences on how PDF/X-4 has worked for them, whether what was sawn non-flattened when designed and exported, was flattened and printed without surprises.

Yes, there seems to be a difference. Personally I see this HSL conversion irrelevant (meaningless). Basically having C, M and Y as zero, and only black component, there is no color, only "lightness", or in terms of media, decreasing amount of reflected light, absorbed of all color, perceived as a "shade". As long as L = 0, H and S can have any values, the appearance does not change, and you cannot have meaningless conversions to a color of any color model. But I am no scientist and only have experience in different color models and behavior of colors in pragmatic applications, so my terminology is undoubtedly vague (e.g., I struggle to make difference of lightness/luminosity/luminance kinds of components L(ightness), B(rightness), V(alue), I(ntensity) or L* in systems like HSL, HLS, HSV/HSB/HSI, and L*a*b*), but I suppose they all separate light from color. CMYK as a subtractive system on a computer display is of course a kind of an abstraction anyway (as all CMYK values must be created in RGB), but also on print, mixed with other pigments, K assists in creating appearance of a color and is an important component in creation of color in printing process, but technically not itself a "color".

I once wished an option that would either require input focus before performing mouse-wheel based value adjustment, or alternatively, e.g. 500ms delay within a certain hover delta tolerance that would be enough to indicate that wheel was scrolled to adjust a value. I have learned to beware of inadvertent value adjustments but it still happens occasionally. It is fine to have it operating as it does now, but this kind of an option would be welcome.

If you refer to the screenshot, it is the opacity value.

It is an ad-hoc grayscale value B14 (Photoshop G86) of K100 that has been converted to R35, G31, B32 and presented as rounded intensity of its light value (14), based on your currently active color profile environment.

No color, no light (L = 0). #231F20 (RGB conversion for K100) -- I do not have macOS version 1.x installed currently but the Windows 1.x version gives the same. I see no point in this kind of a categorical warning. It is the strong point of Affinity apps (similarly as that of InDesign) that mixed color definitions can be given (e.g. certain values given in RGB to get them in full color spectrum when exporting to RGB, and conversely, making a CMYK definition in an RGB document when there is point in keeping colors consistent in visual appearance in both targets). But it of course easily confuses people because it is pretty easy in Affinity apps to perform inadvertent color conversions simply by forgetting the lock off and switching the color model in the Colors panel. UPDATE: Actually there seems to be more fundamental difference in color conversions between macOS and Windows, which can at least potentially have some bearing when taking a design from one platform to another. E.g., in a CMYK document, K50 will be converted to H0 S0 L50 on Windows, while on macOS the HLS conversion will be done after first converting CMYK to RGB. On Windows, this will only happen if the document is in RGB color mode. I see the Windows behavior more appropriate, and it actually matches the Illustrator handles gray values in CMYK and RGB color mode (Illustrator is not a dual color mode app, but basically converts input colors to target color mode based on color profiles, but handles gray values differently in either color mode).

It is probably much dependent on use case. I was referring to things like this: Personally I have found refine tools unpractical for cleaning a poor edge selection, they basically appear to work only "outwards", as if feathering the selection. But because it does not work as I expect, I probably have not learned to use it for the purpose it was created...

The refine operation does not operate similarly as in PS, if you are accustomed to use it there. I think that there are several posts on the forum that deal with users struggling with this feature.

I have posted several articles related to PDF export related issues, and the causes can be complex so examples would be very useful. First of all, you should be fully aware of the Affinity specific PDF compatibility rules, violation of which will result in rasterization and recalculation of all (CMYK) color values affected. Also, you should always export using the document color profile (changing the color profile at export time causes recalculation of color values). PDFX-4 is basically incompatible with any non-PDF/X-based placed PDF content (that is intended to be passed through). Rendering issues can be related to faults in getting live transparency properly encoded in PDF so that print-time rendering fails (whether on RIP by because someone having done transparency flattening manually in some preprocessing software, sometimes just e.g. in Photoshop). Affinity based PDFs also have mixed color mode states in transparency blend color modes which might e.g. be sRGB based but are combined with Device-CMYK objects. I have no idea if these kinds of issues could result in the kinds issues you describe when handed over to RIP. Do you get RIP processed PDF drafts for preview so that you could spot these errors before they get on paper?

Basically I cannot, because there is no light 🙂 I think that HSL 0, 0, 0 for C0M0Y0K100 just describes the situation of void of color. The wheel position however reflects the CMYK to RGB conversion (when using the default US Coated Web 2 and sRGB as the profile reference), R35 G31 B32. blacks_v01.afpub

Hello @JTorres, and welcome to the forums1 At least you should make sure that both the Designer and the Publisher document use the same CMYK document color profile, since if they do not, the K100 color of the placed (linked or embedded) Designer file will be converted to four-color black. What exactly are you experiencing? I assume that the the PANTONE color is correctly exporting, and if not, have you tested if it (and K100) export correctly when exported directly from Designer (using the same PDF export method)? I mean that have you ensured that this is an error clearly related to having Designer file placed in a Publisher file? EDIT: Re-reading your post, and if it is really the other way around, placing K100 text exported as PDF/X-4 from Publisher in a Designer document containing 2-color (K100 + PMS) art, and then exporting to PDF/X-4, you should be good. Just remember to export to PDF/X-4, otherwise your placed K100 text will be rasterized and become four-color black (because of Affinity PDF passthrough "compatibility rules").

Aphoto v1 selection tools are mostly poor, and the suggested Selection Brush tool with optional soft edges [and for the object instead of the bg, as below in the comparison] is the best for most purposes. Aphoto2 is a worthy upgrade even if it did not have any other improvements than adding antialiasing options in e.g. Flood Selection tool and Sampled Color feature. Attached is a comparison of APhoto1 and APhoto2 selections (very quickly drawn), and PS one-click object selection (.aphoto2 and .psd files), the point being primarily in time spent to achieved quality. bugs_compared.afphoto bugs_compared.psd

It is perfectly fine to use rich black on colored background. Even if you'd produce the document in CMYK color mode and specify text black in K100, by default the K100 color values would be overprinted, and would accordingly mix with underlying colors. Here is a demonstration on using RGB 0, 0, 0 and K100 blacks on colored background, and when exporting the same document in CMYK and RGB: blacktext_rgb.pdf blacktext_cmyk.pdf