lacerto

Please post some further information on the document you have and what the printshop requires. I wrote lengthy instructions for diverse cases but accidentally lost the text before sending it, and do not want to re-create the post. The instructions depend on whether what you now have is in CMYK/8 color mode (and you have color photos in the job, and/or native shapes and other elements defined in color), or Gray/8 color mode, and whether what you need to output must be in CMYK or Grayscale mode, and whether the printer requires a transparency flattened PDF (or possibly a PDF/X based PDF).

I may have misunderstood something so if you have questions, please post comments and I try to answer. A spot color (or any other color) that serves as a master (parent) must be marked as a global color swatch to be able to serve as a parenting color. All tones that are children of a master retain this relationship so for user-defined global colors (including spot colors) if the master changes, the children change accordingly; however, the library based spot colors cannot be redefined: tints.mp4 Tints of a spot color (whether library or user defined) however show correctly as shades of parenting inks: spot.mp4 Note that unlike in InDesign (and possibly other layout apps), you cannot use a tint of a spot (or another global) color as a base and parent of sub child swatches (and still dependent of the original master) so the dependencies can only be direct master-children based within Affinity apps. Affinity apps also do not allow replacing one global color with another, and inheritance of tonal dependencies, so the ways you can benefit of master-children dependencies in Affinity apps are rather limited.

Yes, it is not clear why this changed (but is still supported when entering multiple receiver addresses) -- perhaps it is related to just requiring in actual parameter part only valid url-encoded special characters, and accordingly spaces, too, needing to be encoded (version 1 allowed space characters e.g. in at least the subject parameter).

This topic has been discussed multiple times on the forum, to some depth e.g. here: For Windows users, it is probably easiest to use G'Mic plug-in and Photo. GIMP itself can be used for this, too (both to produce palettes and reduce colors with palettes). If Affinity app alone is wished to be used, then using Gradient Map, Posterize (with exact number of colors specified) and Black and White adjustments in this specific order can produce something similar (with exact number of colors and no shades in between). An alternative is using LUTs. The result of course is not an indexed image because they are not supported in Affinity apps but the effect is similar. Searching the forum using e.g. the following keywords should result in some hits: indexed, palette, palettized, color reduction, quantization, posterization, colorization

If you export using PDF (any other than PDF/X-1a or PDF/X-3 which flatten live transparency), you should be able to export gradients containing <100 opacity values without causing rasterization. The objects will show as "Non-Native Art" in Illustrator (at least CS6) if you have only two gradient stops. But if you have three or more, they show as gradients also in Illustrator (even if the transparency is achieved with a transparency mask rather than gradient stop values with an opacity percentage).

Related, but a bit off-topic: expanding a stroke can deviate from what is seen on canvas also in diverse situations where stroke parameters are somehow extreme or untypical (e.g. abrupt smart nodes with bevel joins). In these kinds of situation rasterizations typically give what is rendered on screen while expanding gives what will happen when the stroke is exported to vectors (in OP's case the opposite is true: exporting to vectors retains the visual rendering). expanded.pdf It is also interesting to compare how different apps do expanding. E.g. in VectorStyler the resulting shape at least in auto-expanded strokes can be dependent on current zoom level (accuracy of rendering on canvas). In CorelDRAW (2023) expanding strokes often causes distorted shapes. Illustrator (CS6) appears to outline paths generally as rendered but similarly as Affinity apps struggles with untypical node type + attribute combinations and might produce three different versions (when rendered as stroke on canvas, expanded, and stroke exported as vectors).

@Dan C, I just ran another test, and if you replace the @ signs in cc and bcc with %40, all the mail fields work fine, and you can have multiple receiver addresses marked with @, so having email@address.here.com;another@mail.com;third@testing.com?subject=This%20is%20a%20test&cc=secondary%40mail.com&bcc=hidden%40mail.com&body=This%20is%20body%20text entered in the Email-type of Hyperlink box, gives you this: The screenshot above is from macOS Mail (Sonoma 14.1.2), but it works the same on Windows (Outlook in latest Office 365 on Windows Pro 11 tested). So the only difference to version 1 seems to be that in version 2 the additional parameters &cc and &bcc require the @ sign to be url coded as %40.

These kinds of problems often require manual work and some "cheating". We have done lots of books and basically always aim at "full columns" for flown (continuing) text so I get your point, while I also agree that these things can be a matter of personal preference and taste -- sometimes they can also be kinds of house rules, and then you just need to show your professionalism and try to achieve what is asked. Often problematic layouts require adjustments made to preceding pages and can be time consuming before a satisfactory result is achieved, but when working with ragged text alignment (as in your glossary example), you can often get columns evened out by forcing extra line breaks without visual distortion (it does not matter even if you occasionally have clearly shorter lines). A common cheat is also widening or narrowing columns (just make sure to keep the alignment with header and footer elements, and if necessary, change their positions spread-wise -- this can of course be easily seen when browsing pages in a PDF viewer, but this works just fine in a printed product. It is also perfectly fine (IMO) to make exceptions and add extra space before headings (like glossary capitals). I would also clean those ending "to"s -- not necessarily each and every instance, but especially when something like this repeats, it becomes a disturbing pattern. In a glossary context I would probably always tie "to" to the following verb -- splitting a clear infinitive definition seems just "wrong".

Note though that it (both versions 1 and 2) still accepts multiple email addresses separated by a semicolon (the delimiter might depend on regional settings?) so it is not just the number of addresses as parameters, but possibly a deliberate omission of cc and bcc fields (probably not very often needed, though bcc can be quite convenient sometimes).

Perhaps there is some reason for making this feature less powerful in version 2, but at least in Windows 1.x version (1.10.6), the full email url syntax was still supported and worked without any obvious issues: Note how in the body part even line break works. Perhaps there was some security concern, or possibly IDML compatibility based cause (as InDesign only supports the sender address and subject line)?

Yes, e.g. Acrobat Reader. But in case of tel: link, the link works as it is, so the link physically exists and works as it is, so there is no assistance on behalf of the app itself when it invokes the app call, it basically just passes what is given, what it recognizes as a link, so what happens, depends on the system configuration. So in Adobe Acrobat Reader, app call is invoked based on existing link, whether app based link generation is disabled (like it is below): But when clicked, Adobe Reader will require document-specific acceptance from the user before actually passing the call. In the following link are formal specs by Nokia from year 0, and also examples, so the link above is formally correct: https://datatracker.ietf.org/doc/html/rfc2806

It may be so, but e.g. in Adobe Acrobat Pro and Reader, the link works as it is, without Acrobat needing to generate a link, and where ever I have tried this, the link basically invokes something like this (this time in Firefox): ...both on Windows and macOS, so the link itself seems to be syntactically correct, and if an app is configured to make a call, this will happen. But it may of course be that some PDF viewers do not invoke an app call, or that making this to happen requires a supporting app preference, or user-confirmed system security agreement, or that the system ignores the call if there is no calling device configured. But e.g. Windows will suggest downloading Microsoft based Windows store apps that allow creating such configuration if it does not already exist. On macOS it may be that only Apple mobile devices are supported...

I seemed to have deleted it but re-created it now based on a generated PDF and the one attached below should behave similarly (it was initially a Designer 2.3.0 file but this one, created with 2.3.1, still seems to behave similarly, so [a PDF export created from ] it opens fine in Inkscape but a bit confused in Designer 2.3.1). Layers_designer_v2_threelevels.afdesign

For me a URL hyperlink using the format tel:+####### works both in PDF viewers tested (Adobe Acrobat Reader on macOS Sonoma 14.1.2 and Adobe Acrobat Pro and One Drive reader app on Windows 11 Pro), and also when selecting a hyperlink in Publisher and choosing Go to Hyperlink Target from the context menu (but not if I click the Go to Target button in the Hyperlinks panel, which seems to "clean" the tel: prefix from the address and accordingly does not invoke the system caller app linked to telephone urls). EDIT: Just checked, and "Go to Target" button does work on macOS, but not on Windows.

I think we have exchanged some thoughts earlier about degree of usefulness of IDML serving as a kind of an exchange format between different layout apps (considering how it is currently implemented e.g. in QXP and VivaDesigner), but I certainly agree with you that these kinds of "incompatibility" concerns are silly. IMO, speculations of "proprietary" or "nondisclosure" issues related to IDML are equally nonsensical. I am not sure how Adobe handles downgrading of features so that "new", post CS4-features get at some level included, but I have understood that IDML specs basically do not get upgraded because the idea is that layouts saved in IDML format, including ones saved in latest CC versions, can be opened also in CS4. If something is not "understood" by earlier versions, it is just skipped/ignored, . As for reasons of current non-availability of (over a decade old) IDML specs on Adobe dev network (while IDML tools and cookbook are still available), we can only make guesses, but anyone googling IDML File Format specs gets the needed documentation as second and third find entry on Github and CreativePro (not particularly dark internet)... IDML file format itself is nothing more than zipped XML = plain text, so anybody can see how ID features are expressed in mark up. If Serif can convert that to native Affinity objects there is nothing in the technology that stops them doing it in the other direction.

Not just allowing extended visibility of guides, but also ability to place guides off the page/canvas. Both requests are kinds of no-brainers in context of professional graphic design. Not having these features places Affinity apps in the same class of graphic design apps as Microsoft Publisher. Pretty much every other app supporting guides has them (not just ID, AI, QXP, CorelDRAW since forever, but also Inkscape, Xara, VectorStyler, even PS and Corel Photo-Paint (with less obvious off-page/canvas positioning/sizing needs) -- even obnoxiously minimalist Pages where vertical ruler is an option and where there is no pasteboard allows placing guides off the page.

You're welcome. Note that the PANTONE color representations were initially defined in Lab, but I used their CMYK conversions in Coated Fogra 39 color space, because the AI file itself was in CMYK color mode. Also, the specific PANTONE colors that were used in the file do not look noticeably brighter even if the document color mode were changed to RGB (specifically sRGB), so there is no significant loss in color fidelity. Also, if logo(type)s with brand (spot) colors are printed without using special inks, it is often meaningful to use CMYK representations of them to have as much as possible identical visual appearance in printed (CMYK) and digital outputs (PNG and SVG) (provided, though, that correct color profiles are used). Note, too, that transparency flattening done by Illustrator (when converting to PDF/X-1a) did rasterize part of the gradients that were used in the logo. Adobe apps can often flatten transparencies using pure vectors, but not necessarily in complex cases like this. I tried selective transparency flattening on the canvas (where it is possible to define to what extent rasterization is used, if at all), but results when exporting were clearly poorer than when using automated conversion (rasterizations were much coarser). It might be possible to get a pure vector design without transparencies and color rendering issues, but it would probably take pretty much time and lots of testing.

As OP's screenshot shows that a discrete video card is present, it is a good idea to check that there are no Desktop Color adjustments done in NVIDIA Control Panel: https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/mergedProjects/nvdsp/CS_Adjust_Color_Settings_Advanced.htm I am not sure if adjustments made there could be such that only show clear distortions in color managed apps, but it is worth checking (similarly as checking that monitor OSD does not force e.g. some game or office color gamut, or adjustments made to color channels or gamma).

It seems the major issue was after all related to PANTONE inks behaving unexpectedly when rendered with complex gradients (and when flattening transparencies), so I noticed that Illustrator, too, distorts the colors when the PDF/X-1a export with PANTONE inks is opened back. Converting the PANTONE inks to global CMYK colors appears to have fixed the color issue, so the attached transparency flattened and CMYK-only PDF could probably be used as an acceptable base for .afdesign conversion: Artelac_Ectoin_GR_logotype_pdfx1_fixed_ai.pdf More generally: using PANTONE inks in these kinds of designs is often problematic since rendering on screen is at best only a kind of a guess.

I tried to simplify the design by saving it as PDF/X-1a:2003 from Illustrator CS6 (the design itself was created with a later version of Illustrator). This flattens transparencies and makes sure everything is in CMYK color space (+ the two PANTONE inks included): Artelac_Ectoin_GR_logotype_pdfx1.pdf But Affinity apps do not support the full range of PDF-objects (e.g. Smooth Shaders) so this does not help. Perhaps there is some use of the produced PDF/X-1a file, even if it basically makes the design less truthful to the original (making it possibly easier to make fixes in Designer). I wonder if VectorFirstAid (by AstuteGraphics) would be able to simplify the design, but unfortunately it is quite a pricey package nowadays (and I am not sure if it even supports older CS based AI formats anymore), but if that cannot do it, I do not know what could... UPDATE: Here is a quick effort to fix this based on the above PDF/X-1a file. I applied Multiply blend mode to the logo guy to have the PANTONE tones blended with underlying blue. If exported further to a PDF format that allows live transparencies, the colors stay pretty much as viewed on the canvas (if transparencies are flattened, Affinity apps only support rasterization and the edges will get terribly jagged). There are all kinds of flaws but perhaps the design could be used (without rasterization) based on the PDF/X-1 version. Artelac_Ectoin_GR_logotype_kindoffix.afdesign

I now made a "3rd degree" test and it seems Affinity apps have an error reading in back what they write: When reading the PDF back in: That it is a reading error, can be proven if the same PDF is opened in Inkscape:

Most importantly, please note the "Layers" that will be exported to PDF layers (OCG = optional content groups), and viewable e.g. in Adobe Acrobat and other viewers supporting these layers, need to be "Layer" layers: that is, specifically containers that in Affinity apps are called as "Layers" (with capital L). Layers_designer_v2.pdf Additionally: if your intention was to share a PDF with layers with other applications, to maintain organization of the design, it is good to understand that e.g. Illustrator (at least up to CS6) does not read in OCG layers, at all (they are a different thing than native layers Illustrator uses): Illustrator: It is interesting to note that Affinity apps themselves do read in the OCG layer structure when they open PDFs, so basically PDF specs themselves appear to support sharing OCG layer structure (at least some levels deep). Illustrator itself e.g. only exports top level layers to OCG layers. But e.g. Inkscape does read in OCG layers and maintains layer names and hierarchy (at least to 2nd level):

Adobe Reader is not much of a booklet printer, at least if you need to print onto oversized papers and get print marks included. InDesign has internal Print Booklet feature that is easy to use and that can create professional CMYK booklet PDFs in a snap (especially when using Adobe PDF as the virtual printer). On macOS, the booklet print option of Affinity apps offers a kind of poor man's alternative, but at least the colors will not be converted to RGB. But as said, asking the print shop to create a booklet from a regular page-wise exported PDF would be the easiest solution.

As you are on Windows, it is good to know that Affinity apps cannot create a CMYK print job, even if the virtual printer supported it (Adobe PDF does, but e.g. Microsoft Print to PDF, PDF-XChange or PrimoPDF do not so they always create RGB output). Many print shops however accept RGB PDF but then you also need to set up your design in RGB color mode and define e.g. text black as RGB 0, 0, 0. Otherwise (using CMYK color mode), your colors will basically be doubly converted (from CMYK to RGB and back to CMYK) and the results will be less than ideal. If the print shop requires CMYK, you could convert a properly created RGB PDF to an acceptable CMYK PDF (with RGB black text converted to K100, and colors converted to desired color profile) with e.g. PDF-Tools (by Tracker Software), which is not a free tool (costing currently USD82) but comes with a perpetual license. But complex things like overprinting (e.g. black text is customarily overprinted) could not be handled with that tool. All in all, considering all the extra trouble, you should be able find a print shop that outputs a standard page-based PDF output (created by exporting) to a booklet without extra cost.

This seems to be a kind of parallel case of Wishes Pro having issues in Affinity apps (but not e.g. in Adobe apps): ....which @kenmcd explained to be related to unexposed final forms being activated without the UI offering means to turn them off. In this case turning off forms attributes appeared to work.