lacerto

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

Yes, it can be complex (and can support pretty complex configurations). That is often the cost of powerful features. Yes, a badly missed and much asked feature.

Seems so. On Windows (at least the latest version of Publisher) the check box is available. Note that within Affinity apps the native objects (shapes and text) are always converted to CMYK when exporting to PDF (in contrast of e.g. InDesign, where you can leave them as RGB as per relaxed specs of PDF/X-4). So if you do not have the color conversion option checked, you will get this (placed RGB images are left unconverted): ...and if you do, you will get this (placed images converted to CMYK, as well): As you mention that you typically have material from multiple sources, it is good to know that Affinity apps have serious issues with all PDF/X-based standard export methods, since they do not support passing through non-PDF/X-based PDFs, at all, disregarding their PDF version number, so what happens is that these files will be rasterized [You would need to let Affinity app interpret these kinds of files to avoid that, but then you take risks of having replaced fonts, ignored print settings, and misinterpreted/inaccurately rendered objects.]. In this sense, using the default export method (PDF (press-ready)) with PDF 1.7 compatibility level would be most compatible as it has no problems passing through any PDFs. All PDF levels starting from 1.4 allow mixed color spaces and live transparencies so PDF/X-4 is not anything special in this respect. But if you do not mind rasterizing (especially if you can afford exporting at e.g. at 600 DPI), then PDF/X-4 is basically "problem-free". You should also be aware of the fact that Affinity apps do not convert the color space of PDF content that is defined to be passed through (the default setting), so if you have RGB based PDFs, they will be left in RGB color mode when you export to press-targeted PDF even if you explicitly export to CMYK color space and force conversion of image color spaces (unless being rasterized, in which case they will be converted). This, too, is something you (or printshops) would not expect in light of having experience with other page layout apps (so instructions you get from printshops related to color conversions do not necessarily produce what is expected). [Note: In the screenshot above the color definition RGB 255, 255, 255 is of course wrong; the actual definition for the rectangle is obviously RGB 255, 0, 0, while the text is RGB 255, 255, 255.]

Ah, thanks! It is good to be able to copy the mere filenames or the full paths so there is no need to do separation or combination in Excel. You're welcome. Data Merge is easily one of the most powerful features of Affinity Publisher and worth learning!

In the Search box on the top right of this page, enter your search key word, e.g. KDP Bleed, and you'll get a URL showing results: e.g. https://forum.affinity.serif.com/index.php?/search/&q=KDP Bleed&quick=1 To be able to resolve the issue, it may be necessary to have a closer look on the file itself (considering that there can be multiple reasons that can cause this error). If you cannot post your file publicly, you can send it to private address so that Serif personnel can have a look on it.

Basically it seems to be supported similarly on macOS (though it probably is not possible to add data columns in the file system itself, similarly as on Windows). If you do not have Excel, you can use Numbers. Here's a video demo on how you could do it (Full Path could be used if the image files are not in the same folder as the Publisher file where the TOC is to be created): gettingimagefiles.mp4 After having copy pasted each image group into the actual layout, you can create a TOC that uses ImageName paragraph style to fetch TOC page numbers for image locations in the publication. You could easily use the same method to additionally autocreate e.g. square or ellipsoid miniature images to be used in context of TOC.

Of course, similarly as trimming is possible without crop marks! Separating marks are useful especially if ink is not printed globally / coherently on edges to clearly delineate the actual print job. No worries. I just wanted to be a bit sarcastic towards David 🙂