lacerto

I think it means: let content pass through, as long as it does not need to be interpreted or converted in any way. If the PDF content needs to be interpreted or opened, it needs to be converted to another PDF version. Then skills like flattening transparencies without rasterizing, recomposing to a specific PDF version or standard while being able to keep embedded fonts and color values and overprint attributes, become handy. That is, you convert the "shell" and keep (pass) the intended content. This requires a lot, so I would not call it (yet) a draw 🙂

There are strict limitations within Affinity apps as regards what can actually be passed through, especially considering color information and inadvertent rasterization, so Affinity "Passthrough" may suddenly become a kind of a Pythonesque circus: "None shall pass": jagged, uneven appearance because text and transparent parts have been rasterized, color mistakes because overprint attributes have been lost, recalculated color values resulting in incorrect color rendering and e.g. K100 parts becoming rich black, etc. You would not want to explain these errors to your advertizers...

I did this just for simplifying the demonstration. As mentioned, in my calendars, I have multiple source fields accesses per record, like Week number, moon phase, holiday, color (free holidays), etc.m, so it is certainly not a limitation. Yes, there are multiple ways to "flatten" Excel data, but having the end result converted to .CSV is the simplest. I always keep the .XLSX as a source (I occasionally also use Libra Office Calc and Numbers, but mostly just for testing). I hope you manage to find the most suitable method for your purposes, for me the "vertical" alignment, as you call it, feels most natural, but the way source data is organized, and technical reasons (like limitations in using record offsets) may certainly encourage to use alternative layouts!

Yes, there are issues with refreshing of previewed record (when that is changed). The limitation with the offset seems to be a weird macOS related bug. As can be seen, it is possible to work around this issue. I personally find the offset feature pretty handy as that allows rather complex merge layouts. Please find attached my data merge layout, perhaps it helps you to spot the issue with your setup. Calendar.csv calendar2025.afpub calendar2025_merged.afpub Btw, I normally work with Excel sheets as that allows very effective processing (e.g. date calculations), including macros and scripts, e.g., to create language- and year-versions of calendars, with images, and variable data (holidays, moon phases, etc.) easily. There are still many bugs though, so e.g. results of string functions are not transferred to data merge, and therefore it is often necessary to create a .csv source (or flatten Excel files in other ways).

No, the merge would be performed only once (for the whole year), but using negative offsets to do multiple iterations within the same data table (per page, main calendar month). Offsets can be a bit tricky but you should be able to preview their working by choosing appropriate preview records. Offsets need to be equal for each month. I have months aligned in a 6 row 7 column table so that dates of successive months are aligned by weekday, so i have negative offset of -42 when iterating through month before and month after (after having fetched day data for the main calendar).

I think that you need to have data for previous and next months in the same source as the data for the main calendar. Separate sources are useful when there is a consecutive layout where you first fetch information for one part of the document, and then for another part, but when you need to fetch complex data (e.g. date information for three successive months) for each composed page, you need to use common data source. After getting data for the main calendar, you would use negative offset and go back to iterate through the previous month, and when done, again use negative offset and start iterating through the next month. You would need three data merge layout tools for this.

When you have all elements (whether linked or embedded) in an .afdesign file, export it to EPS format, then open it in Designer, set the background transparent and export to WMF. This should have everything in curves and at least in Word 365, the transparent background stays. RONALDNTAN-Letter-Head-2025-TYPE-DIRECT_from_eps.wmf

That is really odd. I have the transparency retained within WMF placed back in Designer no matter if exporting the area or the whole document. However if I open a .WMF or an .EMF file with transparency, Affinity Designer does not open the document with transparency turned on, but again, there is no difference between .EMF and .WMF. Perhaps this is related to missing font somehow. Designer always converts this font to curves even without checking the export option so I cannot export this text so that the text is retained as a font. This is a font activated from Adobe CC and installed for all applications. This could also be a Windows version difference. I have Windows Pro 11 2004.H2 installed. UPDATE: If I change the font to e.g. to Anivers Regular, Affinity Designer converts the text to an image within WMF export, and that export loses the background transparency. Strange.

I have here both .wmf and .emf exported from Designer 2.5.7, placed in Word (Microsoft® Word for Microsoft 365 MSO, Version 2412 Build 16.0.18324.20092), and both retain transparency: ...so it seems to depend on version of Word, whether transparency works or does not work.

Export it with PS v2 and it exports fine (Illustrator opens just fine the v3 EPS export, too, so this limitation seems to be specific to Affinity apps). Note though that Affinity apps always convert to curves fonts, both when exporting and importing (or opening) EPS.

You can have your images rendered with native colors by using your monitor color profile as you RGB color profile (In Preferences > Color), or using it explicitly when assigning and converting to monitor color space. (Rendering would of course then be device dependent so basically pretty much random...). Note though that Affinity color management is a bit inconsistent and you may still get sRGB factory default color space assigned to opened images without a color profile (instead of having the default working color space assigned), and get colors rendered identically even if you have placed images with multiple embedded color profiles, and have distinct color values rendered only in Export Preview (with document color profile selected), or after exporting. As sRGB is still probably the most common display color gamut, it might be a good idea to use it to approximate a typical color rendering and user experience, even if color management is not supported in the end product, and exports are created without embedding a color profile.

PDFs have "group"-like capabilities and behavior but terminologically they are "ContentStreams" and "Optional Content Groups" (the latter also called as "PDF Layers", which can be global within a PDF document). It is possible to create page-wide ContentStreams, select them individually, change their Z-order, combine and delete them, set OCG visibility, printability, etc. Perhaps this extract from Foxit Quick PDF Library SDK documentation clarifies somewhat the terminological confusion (which is further complicated by the functional difference "layers" have in Affinity vs. Adobe apps): UPDATE: As an example of group-alike behavior of content streams, here is how Adobe Express opens a PDF page containing two of them (initially groups within Adobe Illustrator but saved as PDF without AI content), which show as two "groups" already when edited in Adobe Acrobat Pro, but here also terminologically "grouped" (and ungroupable/regroupable objects, which can be edited much as any regular group objects in any design app), and which can subsequently be saved back as a PDF once "edited and enhanced" in Adobe Express (but losing again the conceptual grouping information and meta data when saved back): In Adobe Acrobat (CC2025), when editing the content: ...and in Adobe Express, when choosing "Use design tools" in Adobe Acrobat: groups_in_pdf.mp4 UPDATE: Affinity apps actually utilize OCG (optional content groups) specifically as page-specific groups. This is achieved by adding a "Layer" layer in the document, and then exporting to PDF so that layers are included. In Adobe Acrobat, the user can then show and hide page-wise these individual "groups" as Adobe layers. Serif has also implemented a feature where these optional content groups are read back in Affinity apps as "Layer" layers, thus utilizing a PDF feature as a way to smuggle in proprietary document information and hierarchy. Other apps reading PDFs do not support this Affinity implementation, which in a way converts a limitation (lack of global layers) into a beneficial feature (page-specific grouping). layer_based_pdf_grouping.afpub affinity_layer_layers_as_page_specific_groups.pdf

If you have Adobe Acrobat Pro, you should be able to convert to PDF/X-1a. The standard conversion applies version 2001: You may need to modify the factory preset preflight converter routine if you need to assign some other color profile, but as this is just color intent, the values are not changed even if the default Coated Fogra 39 is retained. Note that whenever you export from Affinity apps, transparency flattening is done by rasterization so if you initially export from Affinity apps using a method that does not allow transparencies (like PDF/X-1 or PDF/X-3), you will end up having rasterized transparencies. Also, please note Affinity specific "compatibility rules" so if your document has PDFs placed, their PDF version needs to be the same or lower than that of the PDF produced, otherwise you will get rasterized content with distorted color values. Distorted color values may also result if you have any PDFs containing transparencies placed within the document, even if version compatibility is retained. Anyway, you might want to try as the first option a workflow where you export from an Affinity app using the default PDF 1.7 ("Press ready") preset, and then take this to Adobe Acrobat and convert to PDF/X-1a (to retain flattened transparencies as vectors). I tested this is, and the result was PDF/X-1a:2001 verified file which should be fine with your printer. Note that the default PDF/X1a verified in Adobe Acrobat verifies for PDF/X-1a:2003 (and also approves PDF/X-1a:2001), so to verify specifically for PDF/X-1a:2001, you need to modify the default preflight verifier routine.

You cannot browse through the content of a multipage document, but you can have any page of a multipage document previewed by specifying the (starting) page.

As far as I know there is no way to apply camera profiles within RAW processing in Affinity Photo. RAW camera profiles can be either .DCP files, which are recognized in addition to Photoshop at least by Exposure X7, or .ICC files, which e.g. Capture One can use. There are utilities like Lumariver (https://lumariver.com/) that can do the conversion, but version 2 of ColorChecker Passport can also natively create ICC camera profiles. The problem is that Affinity Photo only supports output profiles [and lens profiles] so it is not clear how settings and adjustments made within RAW processing combine when applied at output (probably not making sense, at all). Affinity Photo has also problems in opening certain kinds of .DNG files. To learn how to use ColorChecker Passport created camera profiles in Exposure or Capture One, see e.g. https://www.youtube.com/watch?v=qiji-r6BFg0 https://www.youtube.com/watch?v=-zMHJtAUq90

This is odd, because I cannot reproduce this in v. 1.10.6(.1665) -- any of the three apps -- and also, the shortcut definitions do not make a distinction between Ctrl + numpad +/- keys and Ctrl + regular +/- keys. I wonder if this could somehow be system/machine specific? I tested the v1 behavior on Windows 11 Pro 23H2 both on a computer that has a separate numeric keypad (and using NumPad +/- keys both NumLock on and off), and one that does not (using regular Ctrl + +/- key combinations). As for Adobe apps, zooming in and out incrementally to selection with Ctrl+regular/numpad plus and minus keys works e.g. in InDesign and Illustrator but not in Photoshop (CC2025 versions tested). [UPDATE: What I meant is that zooming in and out has always worked similarly for me in 1.x and 2.x release version apps no matter whether using NumPad keys (NumLock on or off) or regular plus and minus (dash) keys, and have never featured a capability of zooming in/out in relation of a selection.]

Ok. I was curious to find out if this could have anything to do with HDR settings, because I have been using Affinity apps for years but had not experienced earlier the kind of behavior you described. The other "new thing" for me was having just upgraded to 24H2, but as you have Windows 10, that does not explain it, either. But otherwise a kind of a similar issue, and becoming effective as if by itself (for me without having been using Affinity apps for a while).

Hello, @Ian Cooper. This may be a totally separate issue, but I just experienced similar app crashes (exactly at same point) for all 2.5.7 Affinity apps on Windows 11 Pro (2024.H2 installed). I have recently played a lot with HDR photo editing (not involving Affinity apps themselves, though) and e.g. turning on and off HDR mode a lot, changing nVidia settings, etc., and noticed that at some point I could not have any of the Affinity apps loaded. I did not have any issues with other apps, though, and the system seemed to work correctly. The apps crashed so that they were not listed in Windows Task Manager, either (many apps that crash may still be visible in Task Manager). I did not examine any logs but simply just restarted the computer (in SDR mode), and the problem was fixed. I wanted to report this wondering if you might also have been experimenting with HDR (and possibly switching between HDR and SDR modes) when experiencing this error?

If you want to have predictable stacked transparency calculation (addition and subtraction), you can use appropriate blend modes, below demonstrated both in CMYK and RGB: transparency_adding_subtracting.mp4

The file is in UTF-8 encoding but wrongly marked as being ascii (all other apps that I tried ignore this erroneous marking and successfully open the file). So change the first line of the file to read: <?xml version='1.0' encoding='utf-8'?>

Vectors within placed PDFs getting partially rasterized is typically a symptom of exporting objects that have transparency values in PDF format (like PDF/X-1a or PDF/X-3) that do not accept transparency. Affinity apps cannot flatten transparency any other way than rasterization, and this often shows so that a vector object has those parts rasterized where a transparency has been flattened. Another reason (inadvertent) rasterization of vector objects within a placed PDF happens at PDF export is when the placed PDF uses PDF version that is incompatible with the version of exported PDF. E.g., all non-PDF/X PDFs will be rasterized when exporting to PDF/X-based versions, and all placed PDFs using lower PDF version than the export PDF uses, will be rasterized. But this kind of rasterization is applied for the whole file, not just some parts of it, and it does not necessarily involve transparency flattening.

In what context are you trying to use a non-system defined decimal? At least in context of tables, you can specify a custom decimal separator (one that deviates from the system defined decimal): If you want to use custom (non-regional) decimal system-wide, you would need to specify the decimal symbol in Advanced regional settings accessed withing Region panel of Control Panel.

Thanks for all for useful tips and information. This has always been, and is still, to some extent, the bonus of having bugs and opaque operations, having skilled people working around them and shedding their light 🙂 I subsequently tested Apple created TIFFs (mostly 16-bit per channel), either created by Photos when editing a HEIC file (and applying some kind of analysis as per image so that the resulting TIFF in an editing app, also other than Affinity Photo, varies a bit), or when opening in Preview and exporting from there with user-defined options, and it seems that TIFF images, no matter how they are saved by these Apple apps, are somehow problematic to Affinity apps. I can reproduce the bloating issues with any "regular" image so it does not need to be HEIC, but the bloat is most remarkable when using 16-bit per channel images, and the effective compression of HEIC naturally puts the bug well on display, especially as HEIC images produced by default by iPhone are supposed to be an Apple "cool and easy" high-tech thing.

I was certain that it takes just a second of some Affinity aficionado to find a nice workaround and explanation so that this bug, too, can safely be ignored for years

Here. Basically the .heic file alone (which is shot by iPhone 16 Pro of a linear gradient on MacBook Air screen) would be enough. It would be placed (imported) to Apple Photos, then either opened for editing in Affinity Photos, and it should be opened as a 16-bit per channel TIFF image (converted by Apple Photos), or, it can be opened for editing with Preview and exported from there as a 16-bit per channel RGB TIFF (which is the way I saved the TIFF file in the ZIP archive). The remaining steps are: 1) Save immediately as an Affinity Photo file -- increase from 73MB TIFF (which is the size pixels take when saved uncompressed) to 95MB. 2) Add an adjustment layer (I applied Vibrance). Save. File size does not change. 3) Merge. Then save as an Affinity Photo file using a new filename. File size is now 158,7MB. So, from 2MB to 158,7MB in three small steps. Bloat.zip I ran the same test with an 8-bit TIFF and the increase is smaller then, but still remarkable and similarly without any obvious cause. I have done similar tests with these kinds of files (HEIC and TIFF exports from them) in other apps but cannot reproduce the bloat anywhere else.