lacerto

As mentioned by @GarryP, multiple restrictions are involved as for the alleged .AI "support". The .AI file must have been saved with a PDF compatibility layer included, because that is the only part that Affinity apps can interpret. The good part of this is that basically any version of Illustrator by default saves the PDF compatibility layer, so some kind of data exchange can be expected. As per PDF, complex layer-based information cannot be included so the native .AI layer structure can only be transferred partially (very elementally). Affinity apps do not support all PDF capable features so even if e.g. some of the mesh gradients can be transferred via the PDF compatibility layer (and can be read more or less successfully by some apps, like VectorStyler or Xara Designer), Affinity apps cannot (and do not claim to try to) do any of this. Some competitive apps claiming native .AI support truly do better in some areas, but as far as I have experience of these apps, not to a degree that is meaningfully practical. In my experience, practical level of exchange of .AI information within professional context requires Adobe Illustrator (not necessarily identical versions). Affinity marketing implies that .AI exchange between Adobe and Affinity apps is a feasible option. This is gross, deliberate exaggeration, involving, at best, promise-ware with very vague substance.

I do understand the problem, but as long as you are going to have uniform formatting across the results, the column width based design does come handy, because it guarantees that as long as your basic layout is sound (can theoretically fit all desired information on a sheet that the job needs to be output), the only variable thing is the font. I mean: once you have accurate widths, there is no need to adjust column widths and positions. The font specs is something that you can adjust globally in the results (and then, if your workflow is persistent, adjust definitions / styles accordingly).

Basically yes. But at least theoretically it is possible to plan optimum widths for data columns based on calculated maximum string lengths (giving absolute column widths in e.g. millimeters, or percentages). First, doing something like this in the spreadsheet serving as the data source: Then reading the column widths from the fields and specifying them as cell widths in an underlying table, and then use this information to create the text frames that receive the data. After the merge, it would be possible to further optimize the formatting of results by selecting all frame text, adjusting font size, tracking etc. Or have them defined with text styles already when defining the merge and then just adjust the styles. Column widths however would be absolutely optimal (assuming that text formatting is uniform in each column).

Hmm, I had not noticed this: titlecaseformatting.mp4 As it is a formatting tool, overrides then also need to be made using formatting: you cannot just type over the desired letter case. And while it seems smart, it probably cannot be customized to meet specific house styles.

I tried to find anything like that in both Windows and macOS Word (latest MS 365 offering), but failed to find other functionality than the equally destructive Format > Change Case: But I might well just have failed to spot the feature. Anyway, in scriptable apps (like Word), it would be easy to create a functionality that applies a specific paragraph style AND also applies the desired case-changing operation, and assign this to a specific shortcut key.

Yes, these capital related paragraph style attributes are related to OpenType features that are available with certain fonts. "Titling" specifically relates to special titling glyphs used in place of regular capitals. This feature is available e.g. with Adobe Garamond Pro, but I am not sure if Affinity apps can apply the feature correctly [EDIT: I now checked, and it seems it can; as an example of "Unicase", it is available e.g. in Arial, and works as expected]. Capital (and other) OpenType features are documented e.g. here: https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#tag-titl https://learn.microsoft.com/en-us/typography/opentype/spec/features_uz#tag-unic It is possible to apply miscellaneous titling styles via OpenType features, but as mentioned by @GarryP, the Title Case functionality is a different thing and not something that can be attached to a paragraph style. It would be (IMO) also typographically a poor feature, since normally title case is not applied uniformly, at least in English language (e.g. articles are normally left in lower case). These are of course "just" house rules, but having this feature implemented as a "style" would make creating such exceptions a bit tiresome. Having it as a destructive feature makes overrides easier to apply.

I think this is pretty similar as in InDesign, or is it that you can now do this there without tabs (and tab alignment)? tabs_within_tables.mp4 UPDATE: Oh yes, I checked, in InDesign the decimal alignment position and character is also defined with tab functionality, but you do not need to enter a physical tab before the items to make it happen!

I had made this specific distinction in my updated post (written minutes after my initial post) but it seems it was not saved(?) Nevertheless, I was referring to these kinds of situations within Affinity apps, much discussed on this forum, behavior unique to Affinity apps, and having caused much confusion along years: graysnthtime.mp4 The post by OP is specifically related to a kind of illusory Grayscale document color space experienced when staying out of pixel layers (including raster RGB images placed as images), which is not particularly confusing, but just one manifestation of this behavior. My comment and example is more specifically related to confusion related to palette color Gray, which is basically an RGB scale in a color document, including when working in CMYK mode document, as on the video clip, or when working in Gray color modes, including in Photo, on a Pixel layer, and subsequently exporting to CMYK (which is not a thing to do, but which works perfectly well in most other software). But this is all beating a dead horse, to not say a parrot 🙂

Your observation is correct. Within Affinity apps grayscale documents are composite RGBs where each channel has equal values, not one-channel (gray) images. It has many kinds of implications e.g. in PDF exports. UPDATE: The thing with "grays" is a complex issue, so to not oversimplify, a clear distinction should be made between image and pixel data, and between switching of document color mode in Publisher and Designer, and conversion of pixel data (or more generally changing the document format in Photo), on the other hand. When pixel information is converted, you experience the kind of actual color source conversion you would expect in e.g. Adobe apps. So working with Photo, you are not likely to get such "surprises", but when working with page layout, and specifically in CMYK color mode, and importing images with mixed color spaces, you start experiencing unconventional color handling and exports.

Sorry, still do not understand 🙂 Reversing the text path naturally cannot change the order of letters, but it certainly changes whether the text passage starts from the outer edge of the spiral, or from the center. But the main thing of course is that you got your problem "solved"! UPDATE: So just for the purpose of someone wanting just the inside to outside reversal (outside to inside), without visual change in relation to path, here is a version where the text is shifted by -10pt so that the visual appearance stays the same:

There is "Reverse Text" button on the context toolbar when you have selected a text object that you have aligned on a path.

Thanks, I had totally forgotten that option. Otherwise fine, but if you have italics, it tends to cut off a little bit from the corners:

I visited the forum, and can totally understand your frustration 🙂 -- their response was uninformative and arrogant. What baffles me is how and where Athelas is usable on any mac, as when I tried to install it on my other mac (also with Sonoma 14.6.1), without having first tried to add or install it from Adobe Fonts, I appeared to be successful since FontBook verified the font and did not complain anything when installing the system based Athelas. But yet the font did not become listed amongst installed fonts, nor have I been able to expose it anywhere, neither in Adobe apps, nor e.g. in Pages -- in which context and with which app is it available, then? I wonder if it could somehow be system / locale / language dependent. I initially suspected that e.g. Arabic language might trigger activation of this font but this is clearly not the case as the Apple version appears to be the same Western version that I have been installing from Adobe Fonts (and successfully on Windows, as there is of course no conflict)). But as Apple shows separately e.g. fonts available under US English and Finnish (my native language) -- which IMO is absurd as the glyphs and writing system are basically identical -- it just occurred to me that perhaps non-availablitiy of Athelas as OpenType Collection is somehow dependent on something like this? I mean: I have previously manually installed many fonts available under Supplemental (in context of previous OS versions), and do not remember to have experienced similar issues. Perhaps something has changed...

I do not recall what I had written, but probably something that had already got obsolete (had to delete everything as my attachment quota was exceeded), but here goes: 1) On Windows, copy and paste as Enhanced Windows Metafile, then edit the cramped characters so that their spacing is normal, and optionally, convert RGB 0,0,0 to K100 or grayscale. 2) On macOS, as you have certainly noticed, Affinity apps mess up the original Word equation (with Cambria Math). So far the best workaround I have found is to install LibreOffice Writer, then copy paste a Microsoft Equation into Writer, pasting it as Rich Text Format, and export the selection to PDF. For some reason it seems that the canvas will be the size of the document (e.g. A4), but this can be cropped with a PDF tool (or simply just clipped within an Affinity app into a rectangle). The contents will be text with LO specific fonts embedded, and can be further exported to PDF retaining the content as text. Or, after having installed the LibreOffice fonts on the system, the LO exported PDF can be opened directly to e.g. Affinity Publisher and edited as wished (e.g., change the color from RGB 0,0,0 to K100). wordequation_2_apub.mp4 UPDATE: The most productive method on macOS would probably be subscribing to MathType, as this app should be able to convert all Word (MathLab) equations to MathType and then convert them in one batch to PDFs (I have the old Windows version that does the same but the export format is EPS, which Affinity apps cannot handle).

If you really need to have your equations retained as text, one option would be cropping the Microsoft Print to PDF oversized output using an appropriate PDF tool, and optionally convert the output to grayscale, while having the document in CMYK color mode and include color graphics, if wanted. The tool that can do this, might cost a bit. I did it with Adobe Acrobat Pro (2020, perpetual license), but it can also be done with e.g. PDF.XChange, much cheaper non-subscription tool.