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

lacerto

Members
  • Posts

    5,729
  • Joined

Posts posted by lacerto

  1. I think the defaults are "single page continuous" and "fit width". Those are the defaults in Adobe apps when exporting using "interactive" mode, and generally used in apps that do not support user-defined (document-specific) initial view settings. In addition to that, apps typically create page-wise layouts for facing-pages documents, not spread-wise, like Affinity apps.

    EDIT: Having had a look on PDF specs since version 1.0, it seems that there are no defaults or standards (recommendations) for page layout and zoom values to be used when opening a PDF document with or without document-specific initials. Different viewers use different preferences and defaults so there is basically no way to really have true control on these settings.  

  2. PDFs do support setting the initial view (the way pages are switched and how they are zoomed, and in which kind of a window they are shown, with what controls, and whether full-screen, etc.), but Affinity apps do not support setting these options when creating PDFs.

    PDF viewer apps can also choose to ignore document-defined initial views, or may allow the user to override them, e.g. browser plugins often ignore internal view and zoom settings, but may offer preferences of their own.

    If you are on PC, e.g. PDF/X-Change (if I remember correctly, also the free version) allows you to specify Initial View settings in an already produced PDF file, which is useful if your audience will use PDF viewers that honor internal settings. But as mentioned, in many cases you cannot control the way the users will view PDFs you have created.

  3. 1 hour ago, loukash said:

    Hm… I'll have to double check whether this was already possible in CS5, but I don't think so.

    I checked online documentation for CS4 and these features were already there, and very probably already earlier. Illustrator has the setting under Preferences > General, and in the context menu of the Align panel. InDesign has them in the context menu of the Transform panel. The alignment behavior is different in the apps, Illustrator as a technical drawing software allowing more choices.

  4. 2 hours ago, loukash said:

    I just checked InDesign CS5.5, and it behaves exactly the same as Affinity. 

    Then it must have changed in CS6. InDesign seems to align to visual bounding boxes (rather than the stroke alignment point), but allows the user to specify whether strokes are included in the dimensions, while Illustrator (similarly as Affinity apps) aligns -- when doing manual aligning with mouse -- to stroke alignment point, but similarly as InDesign, allows the user to specify whether strokes are included in the dimensions or not. If preview bounds are NOT used, aligning done in the Align panel will be done according to stroke alignment point, otherwise according to preview bounds. I think that ID and AI use identical object model but just have a bit different UI implementations, but both apps allow the user to decide how objects with strokes are dimensioned, and how they are aligned. There are no such options in Affinity apps.

  5. It appears that Affinity apps cannot apply the default of the Swash feature (turned off) of this font.

    As a workaround, you could use an app that behaves as expected, and export text from there as e.g. PDF. E.g. LibreOffice Writer can do it.

    Uppermost, Affinity apps when Swash feature is manually set to "Default", resulting in random swashes all over the place; middle: Swash feature turned on (identical in all apps but Affinity apps just automatically turn the feature on; bottom: Swash turned off (to "None") in apps that can handle the font correctly (here achieved in Affinity Publisher by placing a PDF created in LibreOffice to be passed through so that the font is embedded):

    image.png.a705f5d8a60a62bbc4149cb3982b9cf7.png

    [The version of the font i used was Wishes Display from Adobe Fonts.]

  6. 3 hours ago, thomaso said:

    with export as PDF v1.4 (and thus with PDF/X-3, X-1, too).

    Yes, but version number is not the key factor here, but PDF/X (1 or 3). You can export to plain PDF 1.4 without upscaling.

    As for the masked [vector cropped] image case, it is a different scenario (and I forgot that upsampling will be done at document DPI without export time DPI setting affecting resampling resolution, while PDF/X-related upsampling happens at the DPI setting specified at the export time), and happens whenever exporting to other "document" formats, as well, not just any PDF, but also EPS, SVG and PSD. So it is basically not a "PDF" thing.

  7. 16 hours ago, thomaso said:

    So there might indeed be a difference between Windows and mac at least in V1 since I do get the upsampling in V1 with a non-X-PDF version 1.7

     

    I did not have v1 apps any longer but installed now the latest 1.x Publisher available (1.10.8), but could not reproduce upsampling with non-PDF/X-based export methods (any version from 1.4 to 1.7, and no matter if exporting using with Print and retaining RGB, or Press and converting to CMYK). So I get it identically on 1.x versions on macOS and Windows, meaning that PDF/X-1a and PDF/X-3 upsample, and PDF/X-4 and non-PDF/X-based do not (no matter which PDF version number).

     

    upsampling_v01.afpub

    upsampling_v01.pdf

  8. 16 hours ago, thomaso said:

    Do you have an idea what exactly may be causing this? … Why for the ellipse in particular … but not for the rounded rectangle or the entire page size?

    A placed Designer document (logo) will cause all objects of the parent document become non-knockout transparency groups, when exporting without transparency flattening (e.g. using PDF/X-4). Hiding the Designer object, or exporting to PDF/X-3 removes the ambiguous transparency groups. A transparency group is introduced also when placing a PDF logo, but it may be limited to just the placed logo and does not necessarily contaminate all objects in the document.

    There are no issues with verification routines so the files seem to be technically valid. But I suppose they are similarly confusing as mixed mode transparency blending spaces are, and can potentially cause flawed print outs. 

    So there's that "who's to blame" thing that does not much help. As said, printshops might use routines that assume that print PDFs have been produced in certain ways. Just for a comparison, here is how Publisher and InDesign handle the same job, placing a PDF logo produced using PDF 1.7 and exporting it using PDF/X-4.
    I know that I exaggerated this, just to make a point, as having a non-PDF/X based PDF placed in Publisher for pass through, and exporting it using a PDF/X based export method will rasterize the logo. But as for ambiguous transparency groups, they are there all over the place. Even when exporting using PDF 1.7, the logo itself constitutes a transparency group. InDesign does the same thing very clean, without any transparency groups, and there are no "compatibility" rules.

     pdfx4_from_apub.pdf

    pdf17_from_apub.pdf

    pdfx4_from_id.pdf

    stickers_logo_test.pdf

  9. On 12/2/2023 at 4:46 AM, thomaso said:

    Good advice to keep things simple … while users (or even Serif) might not expect to add in-compatibility to their layouts if they place 'native' Affinity documents, e.g. for a 'simple workflow' with linked layouts … instead of copy-paste or extra exports which may be recommended but appear 'less simple' in various aspects.

    Yes, it is a bit paradoxical that techniques that are meant to make our lives easier (like developing PDF/X-3 that allows mixed color modes and does transparency flattening, or PDF/X-4 which allows both mixed color modes and live transparencies) actually often make it harder. I suppose part of this can be explained by the fact that transparency flattening is often done manually, or using routines that assume certain workflows and production tools.

    On 12/2/2023 at 4:46 AM, thomaso said:

    For a possible "blaming" question between the OP and Flyeralarm: It seems harmful misleading if the print provider recommends or requires PDF/X-4 in their communication … but uses X-3 for preflight and production … while/if the latter leads to print issues.

    Yes, I suppose they suggested PDF/X-3 because their transparency flattening failed (however done). I assume that exporting using PDF/X-3 would remove the ambiguous "non-knocking" transparency group thing without rasterizing anything -- at least it did so when opening the PDF (with placed Designer object) that OP posted in Publisher and exporting it using PDF/X-3. 

  10. 58 minutes ago, thomaso said:

    I understand that you experienced in V2 that the upsampling does not happen with a non-PDF-X export:

    Yes, and the same is true with version 1 (1.10.6.665, Windows version tested). So versions 1 and 2 seem to behave otherwise identically but v1 apps also upsample when using PDF/X-3 (whether forcing conversion or not). Version 2 apps only upsample if color space conversion is forced (which is kind of silly because RGB images will be converted to CMYK within PDF/X-3 whether having this setting on or off).

  11. 1 hour ago, thomaso said:

    Oh, this would be a change in V2 towards V1, below a V1 example with PDF 1.7.

    What do you mean? I now compared this with v1 (1.06.1665), and the only difference seems to be that version 1 apps upscale in PDF/X-3 also when NOT forcing the image color  spaces to CMYK. I first thought that this happens because Affinity apps convert images to CMYK when using PDF/X-3, no matter whether using the "Convert image color spaces" option or not (even if the images could stay in RGB color mode). This happens both in v1 and v2, and probably because PDF/X-3 does not allow live transparencies, and as Affinity apps do transparency flattening by rasterizing, Serif has obviously chosen to do CMYK conversion anyway (also for objects that do not contain transparencies). 

    As for inadvertent upscaling of vector cropped (masked) images, version 1 and 2 apps seem to behave identically. 

    EDIT: Note that I have so far tested this only on Windows versions, so there might be differences between platforms.

  12. The most likely cause for having -- inadvertently, but by (bad) design) -- upscaled placed images is using the Crop tool to crop images, since a masked image will be upscaled to document DPI (or to specified export DPI) when exported. To fix this, use a clipping mask, instead (clip the image to its desired size by enclosing it within a rectangle with no attributes).

    To demonstrate this, the camera on the left has been cropped by using the Vector Crop Tool (creating a mask), while the camera on the right has been cropped by using a clipping rectangle:

    image.png.b519803f14f5fa20c8533176cf073dd9.png

    When exported to PDF, the right side has kept its initial size and 39PPI placed resolution, while the left side has been blown out, and has accordingly become blurred. 

    upsampling.pdf

    I have sometimes noticed that Affinity apps might inadvertently upsample placed images simply by having chosen a PDF/X-1a-based export method, but have not been able to reproduce this consistently, so there is a specific situation that triggers this behavior.

    EDIT: Wrong, it does it consistently when using PDF/X-1a export method, which forces conversion of RGB placed images to CMYK. It does it also when using PDF/X-3 and manually forcing conversion of image color spaces (using PDF export settings). Oddly (but luckily), it does not do it when using PDF/X-4, or any non-PDF/X-based export method, even if forcing CMYK conversion. 

    It is clear that upsampling should never happen automatically so I consider this a serious error in a page layout app.

    UPDATE: To answer your question: make sure that you do not have placed images that have been cropped by Vector Crop tool (or masked), and make sure that you export using a non PDF/X-based method, or if using a PDF/X based export method, use PDF/X-3 without forcing conversion of color spaces, or use PDF/X-4 (with which you can force conversion of color spaces). If you are forced to use PDF/X-1, or PDF/X-3 and have all CMYK color space (and do not want to have increased file size), and do not have anything in the design that is rasterized at export time, force using a low DPI setting (matching the PPI of the image that gets inadvertently upsampled) when exporting to PDF [EDIT: Note that if vector cropped image is the issue, export time DPI does not affect this; instead upscaling will always happen at document DPI resolution, so to use this trick, the document DPI needs to be changed before exporting]. If that is not possible and the file size does not matter, enlarge the image using an algorithm that does not cause blurring so that Affinity app does not upsample the image at export time. If nothing else helps, create a smaller design and ask the printer to enlarge it.

  13. The way Designer document is embedded does technically create a transparency group that the preflight software detects as a possible issue (and obviously also a factual one, if it results in an erroneous flattening and knockout, even if it is nominally marked as a non-knockout, i.e. overprinting, group):

    image.png.6c85a1138e15a14df875ac467b6f1ae2.png

    My experience is that Affinity documents should never be embedded in print jobs, they have complexities that do not show in PDF previews but can cause problems at print time when the job gets processed and flattened (rasterized). It is kind of a theoretical question "who's to blame" (whether a document is correctly created and just erroneously interpreted and processed), so to avoid problems, it is a good idea to keep things simple and avoid embedding of documents that can cause confusion, or more generally, anything that requires print-time resolutions (at least if ripped proofs are not available). 

  14. I am not sure if I understand what you are trying to achieve, but true duo/tri/quadtones with special inks by applying different inks as defined e.g. by a tone curve cannot be done within Affinity apps. You could simulate something like that by e.g. applying one ink for a grayscale image and then using shapes with e.g. Multiply Blend mode on top, using different inks, and getting their intensity values from the underlying image. I have no idea why non-PANTONE-based special inks are required but technically you could specify and use inks from different spot color systems.

     

  15. I do not know which of alternative spot color palettes are really in public domain and/or freely distributable, but technically it is possible to "borrow" complete spot color libraries from e.g. Adobe and CorelDRAW, the latter of which coming with mostly Lab based representation color definitions in 53 spot color palettes for e.g. the following spot color systems: DIC, Dupont (Spectra Master), Focoltone, Toyo, HKS, Onyx, PANTONE (legacy and current 11 different) and Roland. Munsell and Natural Color System should be available if not free, then at a nominal fee. 

    It is possible to manually create any spot color palette within Affinity apps and pick official color names and their (typically sRGB based) representation colors directly from manufacturers, and digitized palettes are available for some color systems, e.g. in .ASE format. For some reason it appears that at the moment only macOS versions of Affinity apps can import .ASE palettes containing spot color definitions. On Windows, spot .ASE palettes are imported as process color swatches. If spot color palettes are needed on Windows, they can be ported from macOS by exporting them as .afpalettes and then importing to Windows.

    VectorStyler can open multiple palette file formats, including Corel .XML, Adobe .ACO, .ASE and .ACB, and export them to .ASE (which can be opened in Affinity apps). Anyone doing palette-based color definitions a lot, or depending on spot color production, would do well getting VectorStyler.

     

  16. 7 hours ago, SpotColour said:

    @thomaso mentioned that the white rectangle’s corner radius differs from the cut contour line radius. That is correct, and I have been looking for a stray element in my design, but it’s not there.

    Perhaps there is one, but without an attribute. The cutting line might have been created by using a defining line with an outside aligning stroke, as the kind of shape that got clipped out (the white rounded rectangle), when using certain rounded corner angle, creates pretty closely a shape where the outer edge defines the cutting line.

    What actually happened, is not clear, but knowing that Affinity apps will auto-expand non-center-aligned strokes could easily result in multiple cutting lines, once merged shapes get separated. Perhaps something like this happened during processing, even if visual appearance of the design seemed to be ok.

     

     

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