lacerto

Also make sure that each artboard is horizontally and vertically positioned on an integer value:

You can also use the "Transparent Background" setting (under File > Document Setup > Color) to have transparent document background to have the whole artboard exported via File menu without a white background. The Export Persona basically handles artboards as layers and the whole document as background and therefore exports artboards transparent disregarding the document based transparency setting.

You are probably on macOS because on Windows all color profiles are basically in the same system folder (while within Affinity apps you can -- and at least earlier, specifically when using Affinity app store versions, have to -- place profiles in user and app specific locations to have them available. For users on Windows, the easiest way to make color profiles available for any color managed app is simply to select an .ICC profile file in Windows Explorer, right click, and choose "Install Profile" from the context menu.

As you have a gray-based document color mode, I would recommend exporting using these kinds of export settings: Compatibility version [PDF version numbers supported within Affinity apps, i.e., from 1.4 to 1.7 -- and now also 2.0] could basically be anything (all they support transparent raster images, so PDF/X-4 or "higher" is no requirement; it is just that PDF/X-1 and PDF/X-3 force flattened transparency and Affinity apps only can flatten by rasterizing, causing this unwanted side effect).* Exporting explicitly to gray and using the document color profile, as well as forcing conversion of image color spaces, should allow you to keep the exported document in mono color space. Exporting to CMYK (e.g. PDF/X based formats) would just convert your RGB based 0, 0, 0 in text (basically same as Gray 0 in Affinity apps), and RGB-based gray images to four-color black, which you most probably do not want. Rasterised text example_gray.pdf * The terminology I am accustomed to use is Adobe-based where PDF version number determines the "compatibility level", and PDF/X method the "standard".

I do not remember to have added any standard sizes in v2 apps, but A2, A1 and A0 seem to exist as predefined document sizes both under Print and Press groups on Windows platform. For some reason A2 is listed last within both groups (which might indicate that it has been added manually, but as mentioned, I do not recall having done this). EDIT: On Windows, having first defined one document size (e.g. A3) and then choosing File > Document Setup, also seems to give the full set of predefined document sizes (and correctly arranged, too):

@thomaso -- your solution combined with optical alignment applied on non-breaking space actually works very well, and I think is quite versatile (it allows random breaking points while keeping readability, searchability and editability, and does not require additional PDF round which is a definite weak point if anything more complex than text is involved). [UPDATE: Conversely, using the PDF trick would allow keeping grammatically correct word breaks but just without hyphens.]

This works fine with right aligned text but spaces at the start of a wrapped line would cause visible gaps:

If you want to retain text readable to certain extent (e.g. to be searchable, readable aloud, etc.), you might consider a trick where hyphenated text exported to PDF is opened back in Publisher using the option that favors fidelity over editability: and then use Find/Replace to remove hyphens in one go. A PDF opened this way places paragraph breaks after each row so you could not reflow text anymore, so this would be the last stage in this kind of text production. By using manual hyphenation (soft hyphens, Shift+Ctrl/Cmd+dash), or possibly intentionally wrong language dictionaries you could cause seemingly random word splitting. a) When editing the text (full editability/readability/reflowability retained, words splitted seemingly randomly and partially in wrong places with soft hyphens): b) Exported PDF opened while stressing fidelity (and hyphens removed using Find/Replace): Note how the right and fully left justified paragraphs (in the middle and bottom) retain their alignment after hyphens have been removed because paragraphs use optical alignment to place hyphens off the column margin. textflow_split_no_hyphens_final.pdf [As can be seen in the final PDF, continuous text flow is/can be retained in text, while keeping text as searchable and readable English.]

I consider it as a bug judging on how these objects are rendered on screen and get rasterized to e.g. JPG, and how they are exported to e.g. PDF or PSD. a) Rendered on canvas (or rasterized as e.g. JPG): b) Rendered as PSD (IMO logically correctly, clipped and no reverse effect, defining shape still present): c) Exported to PDF (again, rendered correctly): oddcircle.pdf

IMO this appears to be more a kind of accidentally available feature, considering that there is no such prerequisite for using the same keys for zooming when viewing raster images (you can have text cursor left in a text box that has keyboard focus). The vector preview also gets rasterized (becoming jagged) at some zoom stage. Considering that in v1 apps preview was available only for raster images, it seems that preview of vector formats is simply just left in a kind of an alpha stage. [UPDATE: I tried now and zoom is not similarly available on Windows. Additionally, it seems the limitation applies to all "document" formats, including PSD, which in version 1 of Photo did not have preview, either.]

You could use something like autonumbering list with a flow setting applied in paragraph style that starts in a new frame after each paragraph break, like attached below: Page_Numbering_Hard_Way.afpub This would allow you to restart numbering on any page you like. Doing it with sections and page number marker on a master page would be much easier but obviously you have some specific reason to not use sections for this (e.g. in context of multiple master pages). I am not sure but I think that InDesign automatically applies section page numbering when exporting to PDFs but it seems that Publisher won't do this [EDIT: both assumptions confirmed, so ID created PDFs honor section page number labels while Publisher created PDFs do not], so if you want the PDF to reflect your custom page numbering, you would need to use some PDF editor (like Adobe Acrobat Pro or DC, or PDF-XChange) to apply sections and custom page labels [so that users can see and e.g. go to specified page using the document's custom page numbering], like in the PDF below: Page_Numbering_Hard_Way.pdf

Ok, for me (on Sonoma and 2.3) the only zoom that would work like this within Affinity apps (and with PDF export) is this accessibility feature (which below is just temporarily enabled; the feature IS enabled by default on Mac, and I spent some time to find out how to disable it):

Do you mean system zoom (basically an accessibility feature)? If so, then on Windows invoking Magnifier does the same thing. I have disabled the feature on both operating systems so I cannot have any kind of zoom in preview for PDF exports (or then just cannot access the feature 🙂.

There also seems to be (at least on Windows) either a bug, or oddly behaving feature, related to preview of PDF exports, where the above mentioned keys (e.g. for zooming) do not work. The preview image is basically always scaled to fit the preview window width (though there seems to be max width), and cannot be changed while the window is opened (so the preview image does not rescale if the window is made wider or narrower). The last used window width however is remembered so the next time the preview image will be scale up to the same width.

I did a quick reality check and opened AI CS6 sample art "Modern Day Venus.ai", "Looking for adventure.ai" and "Nature's Journey.ai", 38MB, 2.8MB and 11MB files showcasing some of the then new CS6 features, in VectorStyler, CorelDRAW and Pixelmator. VectorStyler did now mostly pretty good job (something that it previously did only with very old AI and Illustrator EPS files), and also could export decent printable PDFs. CorelDRAW did pretty much similarly, both having their own strong and weak spots. Neither could render the tested designs fully, but opened the files quickly, retained very much of the editability, and could export reasonably well-working PDF right out of the box. Pixelmator did mostly fine in rendering, but was extremely sluggish both when opening and exporting (though it must be noted that I tried this on an 8GB MacBook Air using M1), and exported really poorly (bulky files causing all kinds of rendering errors and warnings in Adobe Acrobat Pro and even crashes in Packzview) -- but might still be a useful tool on macOS for at least simple jobs that need to get converted from AI (especially considering the price -- now 50% off -- and versatility). But yes, basically one still needs the real McCoy to open these kinds of files properly. AI_support_reality_check.mp4

Note that if you have the font available already within Adobe (CC) apps, then you have "added" it, and you can use the CC Desktop app to install the font to be used with non-Adobe and non-CC based apps. If you need to add new fonts, go to Adobe Fonts, and "add" the fonts required: After having "added" a font, and you need to have it available universally, use the CC Desktop app, as advised. I think Adobe has changed this a bit recently so it has become more cumbersome to directly install Adobe CC-based fonts for general use. I think that "added" fonts used to be installed previously, even if they might have required re-activation after a while if not used frequently. Adobe also recently stopped selling FontFolio 11.1 so now they basically only have CC-based font service.

Please note the difference between "added" and "installed" fonts. You need to use the Adobe CC Desktop app to manage fonts so that they become installed and available to non-Adobe apps:

In context of this singular case (though without having seen the source document structure), it seems as if SVG export/import had weakened, but if objects are actually given names in Affinity apps (shown non-grayed in the Layers palette), they do get exported with ids, including additional serif-ids, even if typically buried in (at least seemingly) superfluous containers. a) Original Designer source with auto-names, explicit text layer names, explicit Layer containers, and named Group containers: b) Exported to SVG and opened back: c) In SVG Code (viewed in Notepad ++) In light of this example, it seems that the most effective way to organize a complex design is to simply just give Affinity objects (regular layers) names, instead of grouping and organizing them in Layer layers. At least if exchanging data via SVG.

I understand these in terms of rasterization. F/X Gradient Overlay will always be rasterized when exported to PDF, but (with live transparency retained) can have edge colors with transparency smoothly (probably including some feathering) blended into whatever background color, and Fill Opacity box of the F/X panel that allows controlling to what extent object's own background color will be blended in (if at all). It can also be applied on raster objects, retaining its editability. Gradients applied on vector shapes by using the Gradient Tool, however, are rendered as Radial Shadings and are retained as vector objects when exported to PDF. Basically they are useful only when applied to vector shapes; also, when rasterized on canvas (or as a result of transparency flattening forced at export time), they have antialiasing applied at document DPI resulting in narrower (but often also jaggier, depending on the resolution) transition to background colors compared to F/X gradients, being a bit blurred because of the feathering effect. The following clip and the PDF try to demonstrate the difference: gradients.mp4 gradients.pdf

I think you were correct, though:

Within Affinity apps, if you let a placed PDF to pass through (the default), the color mode of the source file will be retained (which is odd, and something you would not expect if you have experience of this functionality in other software). If you cannot edit the source, you have basically two options to have these images in grayscale: a) Change the placing mode from "Passthrough" to "Interpret" and then export using e.g. PDF (for press), using the document color space (Gray) and the document color profile (D50). (If you additionally have RGB raster images, check "Convert image color spaces".) The shortcoming is that when you let Affinity app interpret the image (it would be basically the same as if you opened the PDF in an Affinity app), the embedded fonts might get replaced if not installed, and with complex drawings miscellaneous rendering errors may also occur [some printer settings like overprint attribute will be lost, too]. In CMYK images K100 text and line elements would typically get converted to dark gray (via RGB interpretation of grays), but in RGB images RGB blacks and grays (like text and lines in the graph above) would be interpreted correctly as gray values. Note, too, that the way the colors are converted (e.g., the blues in the graph) depends on the target color profile. It may well be that you do not have alternative gray color profiles installed, in which case you would typically get Gamma 2.2 interpretation of colors (which normally works ok), but to have more control, you would ideally open the source PDF and define the exact gray values. b) Use Black and White Adjustment layer on the images that appear colored. This, however, will rasterize the affected images when exporting.

I do not know what translation tools and specific workflows professional translation services use (certainly ones I have worked with use both translation memory of sort, and native translators), but the initial step I have performed has been delivering an IDML file saved from InDesign, and the final step has been receiving either a translated IDML (for simpler layouts not requiring visual/structural changes), or translated RTF documents initially exported by translators from InDesign (including formatting), to be placed back (still including formatting) in layout by me. So I do not think that they typically translate anything "in place". Another scenario where IDML has been requested are situations where a client wants to have a chance to make minor edits like change of name or address in the layout, and in these situations their "editor" has typically been InDesign. I have not seen it necessary to advise them to use (and learn to use) something more cost-effective. Whenever professional collaboration is needed for a specific project, the tool required has always been CC, which I have then rented for the time needed (typically just for a month or two). This has worked well. IMO their dominance is primarily based on trusted workflows. The cost and longevity of Adobe-based tools for the designer has much been a question on whether one operates primarily on Windows or mac; and if subscribing, whether one app is enough, and whether what is needed can be hired just for short time periods. I started my school with Affinity apps in order to learn a backup suite. They can mostly be used as such once one has learned enough, but as there has not arisen any cause for making a "switch" and abandon trusted workflows, I only use them for isolated tasks in areas where they are at their strongest. I don't much think about companies in my work but I do not feel that I have been supporting villains whilst using software by Adobe or Microsoft. I try to stay practical and co-operative, but also economical.

I referred to collaboration that involves working with the same file using compatible (= common, same) tools. I do not think that exchanging IDML files back and forth between two different apps can be productive as there are several things that do not fully translate. See e.g. notes related to QuarkXP 2024 IDML Export. As a workflow example you mention giving a finished layout for translation. Personally I would not be happy to hand over a finished layout that has any degree of complexity to translators that would first import the document to e.g. Affinity Publisher, edit it there native, and then send it back converted to IDML using proprietary export method (which I'd need to check and most probably spend considerable amount of time making fixes and get back features that were lost in translation). I have done these kinds of tasks a few times when all involved have been using InDesign, even if different versions, and it was ok then. Today the files involved could also reside on cloud so there is no need to send lots of files back and forth. This is one issue more when working with Affinity or other 3rd party apps. The most recent file format specs that I have are version 8 and I think it came with the Master Suite CS6 (2012). I have also an IDML Cookbook that came with CS6. I am not sure if there are any later versions but perhaps not because I have understood that the point is that IDML files can be opened in different versions of InDesign from the most recent one down to CS4. I have not tried to look for newer versions of these files on Adobe developer sites -- the ones I have might still exist there in context of legacy CS5/6 documentation, or perhaps as part of XML documentation. The plugins SDK I referred to has a reference manual for IDML (server based) tools. I think that if someone is determined to develop IDML export support, they can find the required documentation. One prerequisite for developing such a tool is that multiple versions of InDesign are accessible (for testing alone), so that would at least be a guaranteed source. I responded because you seemed to imply that Adobe has hidden IDML related documentation to make it more difficult for other software developers to create full-fledged competitive software with equally rich feature set. If so, they are a bit late, since tools supporting IDML in both directions already exist, and they have not been game changers (e,g,, there are 5 comments in about 4 years for Q2ID Markzware introduction on YouTube). Who knows if it is the other way around: making an agreement with developers of existing export plug-ins that availability of IDML documentation is screened to reward efforts of early-birds. On the other hand, I think that support for IDML export is a double-edged sword: it makes it easy also to come back if it turns out that the competition was less competitive than was hoped. Adobe has also taken big steps in creating new development environments and tools (e.g. UXP) for CC-based apps, and server based plugins, on the other hand, so the focus of development has changed a lot in recent years.

If you mean that the documentation is "hidden" amongst 81,960 files within the ID Plug-in SDK so that a possible competitor gets exhausted and will give up already when extracting the about 3.5GB package (a task that takes about an hour), then perhaps so. But seriously, being afraid of competition and someone developing interchange support for Adobe created things is not the first thing that comes in mind when visiting developer.adobe.com and seeing the sheer amount of open and free as per version targeted documentation, SDKs and tools available for anyone interested. Even with full IDML export support, true co-operation between diverse professionals already happens in the cloud and using common tools. I suppose IDML export is more a kind of a one-off tool for the purpose of providing a client with an editable document they wished to have (and many clients do nowadays, in addition to getting a production file as a PDF). If it is required, why not pick a tool that can already do it, there are multiple available, including ones that are not (necessarily) subscription-based (and not developed by Adobe, if that is important).

If you mean a trick where Affinity Publisher is fooled to replace images in one go by using a renamed folder, note that when you get a warning about missing images, you need to select "Yes" from the dialog. Using Resource Manager does not allow you to actually replace images but just locate the saved but missing ones in a different folder (which I think that Walt does above). Replace_trick.mp4 UPDATE: So what you assume, that there is something extra that Publisher uses to match an image must be true, mere filename is not enough.