lacerto

Unfortunately it is more complex than just "opening", or "placing" a PDF file (by default for "passthrough", or by deliberate choice, for "interpretation"). "Opening" always means "interpretation", and interpretation always requires that fonts used in the PDF are installed on the system where the file is opened ("= for editing", which typically is not allowed in embedded fonts), and additionally: correctly mapped to installed fonts. This is something that you can expect to happen (even if there exists software that CAN properly open and handle embedded fonts even in a document that is edited, and without having the used fonts installed). Dragging and dropping PDFs should basically result in using the default placement method: passthrough. So you are right in expecting that fonts embedded in a dropped PDF will be passed through, whether these fonts are installed on the system or not (and even if they are legacy PostScript fonts) But Affinity apps are unique in applying compatibility rules on placed PDFs (by default placed to be "passthrough", which means retaining of the native color values, and ability to pass through text using fonts embedded in the placed PDF). However, if these compatibility rules are violated, text using the embedded fonts will be rasterized (rather than converted to curves, which happens when importing EPS files with embedded fonts, or replaced with a "corresponding font", if you explicitly open a PDF file using Affinity apps). This basically never happens when you place PDF files in context of InDesign or QuarkXPress, so if you come from this tradition, you'll find different behavior here. "Compatibility rules" basically require that when you export to PDF, the exported PDF version number is the same or later than the PDF version number used to produce the placed PDF files (placed for "passthrough"); in addition, all non-PDF/X-based placed PDFs and PDF/X-1 based PDFs will be rasterized when exporting using any of the PDF/X-based export methods. Your best choice to make sure that fonts embedded in a placed PDF (to be exported using the default "passthrough" method) are included as fonts also in the PDF exported from an Affinity app, is to use the "PDF (press-ready)" export method. This method can export all placed PDFs, whether X-based or not, and uses PDF version 1.7, which as a side effect also means that any transparencies included in the layout will not be flattened. If transparency flattening is required by the printer, and you have a PDF compatibility issue, you are out of luck, since the work around that allows you to fix the font embedding issue, means that you cannot produce flattened transparencies. Hopefully your problem is less complicated so you can ignore my post. Since e.g. Adobe InDesign always places PDF documents to be "passed through" (= will never interpret them), the different and more complex options available in apps like Publisher (or QuarkXPress, which also allows interpretation of placed PDF to "native code") are not necessarily self-evident. But failure to pass through embedded fonts -- and fallback to rasterization -- because of breaking "compatibility rules". is unique to Affinity apps and something that is important to understand for anyone coming from Adobe or QXP culture.

Yes, this, I think is the major reason. E.g., look how the figures (only Old Style available) are created in Didot: IMO, having clearly differently sized "Old Style" (gemena) figures -- in Didot the figures 1, 2 and 0 -- is simply just bad design. See how it is done "properly" in Adobe Jenson Pro in my earlier post. "Superscript" styling in footnotes is basically done using "Superscript" character positioning and sizing (highlighted in the screenshot above) and not by picking superscript glyphs. The first three superscripts 123 in the footnote 1 show superscript glyphs in this font (only 1, 2 and 3 available), so it is clear that footnote marks both in body text and footnote marking use mechanical superscripting (regular figures made smaller and positioned higher).

Basically Adobe RGB with its stress on making a wider green and cyan spectrum, was specifically motivated to make RGB color space more predictable in evaluating how a printed work is going to look like! sRGB does not cover the whole CMYK gamut (and devices limited to sRGB cannot show many PANTONE colors, either; within Affinity choosing sRGB as the RGB profile limits the gamut to sRGB even if the device supports a larger gamut so the PANTONE spectrum is limited by that choice, too; working in CMYK document mode limits the CMYK color mode to sRGB, too, which can clearly be seen in limited green-cyan area). (UPDATE: In Adobe environment, e.g. in InDesign, proof setup can be used to limit oversaturation in red-orange-yellow areas and simulate spectrum of specific CMYK profiles, and also to simulate limitation to sRGB, but the RGB source may still be wanted to be kept in Adobe RGB specifically to not narrow the CMYK production color space.)

It means wider range of colors (e.g. R255 G0 B0 produces brighter, more saturated red in a wide-gamut profile (like Adobe RGB), than in sRGB. To be able to perceive this, the display needs to be wide-gamut, as well, otherwise the appearance of colors will be truncated to the limits of the display device. I do not think it does. Basically sRGB is the standard color gamut of the web and wider color gamut (supported by embedding the profile) is useful mainly just when needing to save or exchange the file (for editing purposes) without needing to prematurely narrow the color space. But the final production file [when targeting to web] is normally converted to sRGB.

You can convert wide-gamut images to sRGB and then export to webp.

At least on Windows (tried Photo 2.2.0) it seems that ICC profiles are not embedded (even if the option exists; it just does not "take") in webp exports, nor are (e.g. PS saved) embedded profiles read from them. So what happens if you export e.g. to webp a wide gamut image (like one that uses Adobe RGB), it will be left without a profile and shown in most apps by assigning it with an sRGB profile, producing somewhat desaturated colors.

There are naturally practical limits where increased text size results in bad usability, but in a well-designed UI the dialogs, panels and toolbars become scrollable and resizable, text truncated but expands in popups, etc. The clip below shows how this is done in Blender (3.6, but dynamic, real-time scalability has long been available there), and shows that it can be done. It is clear that this comes highly usable on big 4K displays where there is plenty of real estate, but fully linear, real-time UI scaling factor is also practical on smaller screens to compensate issues with eyesight. It is of course not a trivial task to achieve something like this, but there is no technical excuse. UI_scalability_at_its_best.mp4

You cannot create spot color channels with Affinity apps. You would need to specify a spot color by assigning a spot color to an image or a vector object (and then export to a PDF file), but if the printer insists on having it specified as part of a TIFF file, I suppose you do not have other options than using PS. (Corel PHOTO-PAINT can, however, specify spot color channels and export them in Adobe Photoshop (PSD) format.)

Interestingly, does not work on a Silicon mac (2.1.1 on Ventura 13.5.2) even when forcing Rosetta, but does work when using Designer 1.10.6 on the same computer (native and Rosetta).

Unless I am missing your goal, you should be able to specify formatting that does what you want: TOC.afpub

There does not seem to be change in version 2. Here is Adobe Acrobat created 200% document size poster using 30 A4 sheet papers in landscape mode, with a 3 mm overlap. And the same effort by Affinity Publisher. This kind of task makes perfect sense to me but I do not understand what APub tries to do (it has the correct page count so something seems to be done right, but the result is just nonsense). The effective PPI of the result (in the demo only about 50ppi) can typically be lowered because of the intended viewing distance, and whether and how much it will be, depends on the image to be scaled. It can of course be pure vectors and text so without any practical limitations. tile_scale200_acrobatpro.pdf tile_scale200_apub.pdf

I have not currently my mac at hand but on Windows you can at least have the Color panel (and other panels, too) docked in a panel column consisting of two or three rows. There are platform based differences in dockability of panels (on Windows you can e.g. have multiple docked panel columns both on the left and right) so this may be one of those differences. On Windows the font lists are also lower so they do not cover (at least fully) panels docked at lower row(s).

Yes. Fonts activated from within e.g. Adobe Express (including the free version) only show in Adobe CC apps (e.g. installed Photoshop 24.7.0, and Adobe web apps), and are called "Added fonts". These do not show in legacy Adobe apps (e.g. InDesign CS6) or non-Adobe apps. But they can be installed to be used with any apps installed on the computer by using Creative Cloud Desktop App. I am not sure which kinds of subscriptions (if any) are limited to the "Standard" license, but possibly only the free Adobe web apps like Adobe Express. At least e.g. Photoshop, InDesign and Illustrator subscriptions come with Adobe Fonts Pro license, making it possible to install Adobe Font fonts to be used with any desktop app (as before). There have been changes in Adobe font licensing and sales policies (e.g. FontFolio 11.1 is no longer for sale), but not in basic functionality: in ability to use Adobe created and distributed fonts across all installed desktop apps and embed them in documents created with them.

Here is a demonstration of creating a column-based text flow in Publisher by placing a Word document containing table and guest names as paragraph styles. ColumnFlow.mp4 I also attached a Publisher document I created earlier to replace your Publisher example file with data merge layout controls. It has document history saved so you can use the History panel to see gradual changes I made to create a column-based layout. Wedding_textflow_with_column_breaks_with_history.afpub

It is pretty easy to create the source as it basically only needs to be a list where table names are marked with a paragraph style (the guests can just be left as "Normal" style or renamed as "Guest"). When imported, each paragraph will be tagged with a paragraph style, and you would modify the styles as you wish in Publisher (e.g., I changed the font size to 48 points and centered all paragraphs, made spacing tighter by using smaller paragraph leading, and made table names bold. TableName paragraph style has a column break Flow setting defined so that text will automatically flow from table to table (four columns of table text frames) when the text is flown across the frames.

In these kinds of situations it might be more flexible and versatile just using simple text flows with column breaks (and possibly tabs), using the text frame features of Publisher. This kind of workflow would allow easier editing after the initial flow has been done. Wedding.docx Wedding_textflow_with_column_breaks.afpub

Ok, please check if the updated files have this fixed. I just mean that I modified these two files so that what was a shade of gray (K45 in a CMYK file) was changed to K100 (solid ink), and what was white (K0 in a CMYK file), was changed to K100 (solid ink), while the transparencies were left as they were. So the actual coloring is determined by the spot ink specification, not as shades of grays. In white ink it means that solid white will be 100 black in the source. The document color profile was that, and I did not change it. But I did not embed any profiles. As this is a pure spot color job, the color profile does not matter. The spot plates are just grayscales and the source levels and transparencies are just passed through in the exported PDF. In this case, I do not think there is any difference (except for the small convenience in Publisher of being able to convert pixel layers to image layers using a menu command -- but as mentioned, if you're on macOS, this is possible also in Designer and Photo; on Windows you would need to use Clipboard, or place a bitmap from a file). Rockheim_Takboks_fixed_new.zip Rockheim_Takboks_fixed_new.pdf

Here is a version where the bitmap source of all three inks (black, gray and white) has been converted to grayscale -- which is not necessary but just does not need playing with the K Only button. I might have understood something of your goal wrongly, but as long as you are really intending to print in three different inks, you should have your grayscales solid (that is, K100 where you want the ink to have 100% shade, and then less, or using transparency, where you want it to be lighter). The problem with your sources was that you had your gray and white as shades of gray, and 0% of black (aiming to produce solid white) naturally does not produce a pixel when exported (because it creates a 0% tint of any ink). So I thresholded your gray and inverted the white bitmap and then reimported them and finally exported to PDF (in format that supports transparencies). Spotcolorjob.zip Rockheim_Takboks_fixed.pdf

Yes, it only seems to work with text and vector objects. Spot bitmaps will be converted to CMYK. Placed PDFs with spot color assigned to images will pass through their spot color state, though.

The issue might be that you have tried to apply a spot color fill on a Pixel layer. Both "K Only" and spot color fill can only be applied to an Image layer. ("K Only" additionally requires that your document is in CMYK color mode). In Publisher, you can convert a Pixel layer to an Image layer by using Layer > Convert to Image Resource. If you're on macOS, you can use the same command from within a context menu also in Designer and Photo (on Windows, you can copy a pixel object on Clipboard and then Edit > Paste Special and choose "Portable Document Format" to convert a Pixel layer to an Image layer (but the image may be resized so you might need to scale it to have its previous dimensions). You should be able to verify spot color status of an object in an exported PDF also by opening the file in your Affinity app, selecting the object and using the Color panel to see if the selected object has a spot color assigned.

Welcome to the forums, @Graphical Chris. You might have inadvertently picked you PANTONE color from one of the libraries that are NOT spot colors but process-based, e.g. PANTONE Color Bridge Coated and Uncoated, PANTONE CMYK Coated and Uncoated are process-based. The most common PANTONE libraries containing spot color definitions are PANTONE Formula Guide Solid Coated and PANTONE Formula Guide Solid Uncoated. Note that when you pick first spot color from these libraries, Affinity app will place the swatch in a new document color palette (if not already created), but will name the color something like "Global Color 58", which is the global color name. The swatch's Spot color name (that will be used when you export, and that will appear as spot plate names in PDF) is shown in the Color panel. If you wish to have global color names to show spot color names, you can manually rename them (using the context menu of the Swatches panel), or you can use the following method to use spot color names directly as the swatches are created: spotcolorswatches.mp4 Note that you need to manually make the spot color swatches global (using the context menu of the Swatches panel) to give them properties of a global swatch. You might also need to make spot color assignment twice to make sure that the assignment really takes (as shown in the video clip).

I am not sure if I got your point but I think that "K-Only" retains its effect even when document color mode is changed so the CMYK and RGB images are still handled as K-Only even when changing to Gray/8 with Black and White profile. The K-Only button is no longer available so you cannot change the handling unless switching back to CMYK mode. This can be beneficial even if the feature is not designed to be used this way. I did not quite get the point of demonstrating use of a fill color (in this case K100) in context of color images (CMYK and RGB), and have not generally given much thought of using direct fill color with images other than grayscale (either genuine, or ones with K-Only mode applied) -- probably because the way the colors get mixed when not combining just gray values is not clear to me and the effect therefore feels kind of uncontrollable (more so than using direct fill assignments with or blend mode color fill layers on top of grayscales).

Sorry, I could not follow. Do you mean by "Black and White" document a "Gray/8" document color mode? I could not see any adjustments here (to which I referred in my post). The document was in CMYK color mode and had Generic CMYK document color profile applied, yet some of the linked images had e.g. ISO Coated and sRGB profiles applied, but were actually in grayscale color mode when opened in Photoshop, so quite confusing. On the other hand, as far as there are (CMYK) profile conflicts (between placed images with embedded profiles and the target profile), I would imagine that there will be export time conversions. The top three images did additionally have RGB 0, 0, 0 fill color applied to them which I think would cause export time conversion and four-color blacks, disregarding K-Only mode applied (when trying to export to CMYK), as I'd imagine that K-Only is applied first and the RGB fill second. Also, I could not understand the color markings in the Farbkreis CMYK and Farbkreis RGB images (former being in Grayscale mode and latter in RGB mode); when K-Only is applied on these images, their color values are converted to varied gray values, as expected. v1105 grays.pdf

The "K only" button shows if you select the image layer (Verdin.png) -- which is kind of buried as you are using a Picture frame. When you have "K only" button applied, you do not need adjustments to achieve black-only behavior. I am not sure if you could achieve K-only effect (from an RGB 0, 0 , 0 value) by using adjustments, but just for information, I think it is one of the sales quirks of Affinity apps to require purchase of Photo to be able to use adjustment presets created in Publisher (by using the "Add preset" button on various adjustment panels), as the Adjustment panel is only available in Photo Persona, as shown in the screenshot below (the screenshot also shows availability of the "K only" button: