Jump to content
You must now use your email address to sign in [click for more info] ×

lacerto

Members
  • Posts

    5,782
  • Joined

Posts posted by lacerto

  1. 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.

  2. 15 hours ago, TypeNerd said:

    to make it grayscale again

    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).

    image.png.204be56341c7dc31060fef8c977e95d1.png

  3. 15 hours ago, TypeNerd said:

    Yes, sadly, it appears my only solution at this time is to use cmyk color profile in Affinity Publisher 2, export PDFX1a which the publisher needs, and then use Acrobat Pro to make it grayscale again.

    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]. 

  4. 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.

  5. 55 minutes ago, loukash said:

    Acrobat X was 32-bit, hence I assumed this is what you meant.

    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...

  6. 1 hour ago, loukash said:

    Not possible. :/ 

    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

    image.png.d119e611fe4389e4955387cdb5613baf.png

    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 🙂 

  7. 5 hours ago, TypeNerd said:

    You are right. If I choose a CMYK/8 color profile, I can then get a true K-only pdf with press-ready option and choose gray.

    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:

    image.png.d4fcddcf399d5ff830d6d1acfd02ce4e.png 

    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).

  8. 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. 

  9. 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

  10. 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:

     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:

    image.png.565a59ff38e1c76957c087052d8f647c.png

     

  11. 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):

     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.

  12. 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.  

  13. 9 hours ago, thomaso said:

    Strange, so it seems to be mac/Windows thing that I get the HSL values in your V1.afpub reported differently than you in Windows.

    Yes, there seems to be a difference.

    9 hours ago, thomaso said:

    Do we use the term "colour" differently?

    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".  

  14. 51 minutes ago, Dan C said:

    Alongside this I will be requesting for this to be controlled with a new Tool Preference option, allowing the user to disable the feature across all fields when using a trackpad.

    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.

  15. 5 hours ago, thomaso said:

    but there is no void of light (L), right?

    No color, no light (L = 0).

    5 hours ago, thomaso said:

    What HEX colour does the Colour Chooser window report to you for K 100

    #231F20 (RGB conversion for K100) -- I do not have macOS version 1.x installed currently but the Windows 1.x version gives the same.

    4 hours ago, NotMyFault said:

    never mix RGB/CMYK in one document (in affected versions up to v2.2)

    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).

  16. 1 hour ago, RicP said:

    Actually I started using it in affinity and always used it efficiently, but I have problems only when doing the aforementioned operation.

    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...

  17. 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?

  18. 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"). 

  19. 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

  20. 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

  21. KDP instructions can vary, but basically they accept any color space for paper cover. It is a user-choice (within the technical limits considering the media, e.g. uncoated or coated stock) how black they want the color to appear. If you design in RGB, then RGB 0, 0, 0 (pure black) will be automatically converted to maximum four color ("rich") black available.

    https://kdp.amazon.com/en_US/help/topic/G201953020#color

    As for default color well values in the Swatches panel, they depend on the document color mode and vary accordingly:

    Note the lock in the Color panel. If the lock is turned off (= not the default), then the Color panel will display the true native color values of a selected object. If you turn the lock on (= default), then switching the color mode in the Color panel will show conversion values of true object color values in selected color model, and the displayed values vary according to your currently active document color profiles.  

     

×
×
  • Create New...

Important Information

Terms of Use | 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.