lacerto

Yes, I have not been able to reproduce the TTC specific error on macOS, either (at least using v2.6.0 of Publisher and v4.1 of Inter), I have tested Sequoia and Sonoma. I just also tested the v.1.10.6 Windows version (on 24H2), and the same error (with italics) happens there, so at least it is not a recent error in Affinity apps. The break with Bold (getting rendered in Regular) is interesting, because Affinity apps actually correctly interpret the internal styling group (inDesign, at least CS6, does not, but instead uses Semibold for emboldening regular; which is aesthetically more proper, though, skipping the Medium). The non-bold issue is reminiscent of a similar recent issue in Affinity apps with Nirmala UI, but I cannot say if the cause is totally different: Anyway, the issues with TTC are more complex, as the rendering of italic types is totally confused...

I remember to have experienced sometimes issues with .ttc collections, but cannot remember now the details but I think it was on Windows. But I think that this might well have been more an operating system related issue rather than one related to InDesign or other Adobe app. I just tested installing v.4.1 of Inter TTC on Windows 11 24H2 on both InDesign CC2025 and InDesign CS6 (on separate computers), and there were no issues. I then tried this also on macOS Sequoia and InDesign CC2025. The MacOS version of the app crashed at first when opening the .INDD file with references to Inter fonts, but on the second time opened the file without issues and displayed the fonts correctly. I exported from each version of the app a press PDF without issues. The fact that CS6 opens the TTC collection correctly does not seem to indicate that there has been an issue in InDesign -- or it may be that there has been issues only with certain .TTC fonts (or certain version of .TTC fonts). Whatever the cause, there are no issues with the 4.1 version collection of Inter when using old and new InDesign, at least on the latest Windows and macOS versions. However, when a file with references to Inter TTC is opened in Affinity Publisher, the fonts are displayed fine on canvas, but when exported to (press) PDF, the following happens (left, exported from Affinity Publisher, right, exported from InDesign CC2025): (At least there are issues in rendering italic versions of the font...) However, this only seems to happen on the Windows version of Publisher. I have only tested the 2.6.0 versions of Publisher.

Yes, it is an excellent package worth every penny, even if you'd need only one of its many features! I would not expect Affinity Designer to have any time soon natively anything that comes even close to functionality offered by this expert package. Unfortunately it also seems that there is no way Designer can have this kind of functionality from a third party, not at least by AG:

I wonder why? Isn't the native functionality enough? This is from CS6 (perpetual license, no need to pay since 2012): In modern version the functionality has further been improved, but perhaps there is a specific functionality that is only available in an external plugin?

If you are on Windows, there is a free app that can do this, with lots of adjustable parameters, and workable presets: UPDATE: Those on macOS, can use Wine and run the app. I have myself used Crossover for this, but I now learned, thanks to creator of Fotosketcher, that there is a free app, https://getwhisky.app, that can create Wine bottles easily without needing to pay extra. Here Fotosketcher is run on macOS Sequoia:

Thanks for the link! It is a lovely, ingenious and innovative app, and it's gonna revive our early interest in 2D animation! I also tested the beta on my very basic Nokia tablet and the first impressions are that it operates just "fine" there. I noticed, too, that I could get Clip Studio Paint on it, I had no idea! Anyway, I just purchased this app on our new iPad Air M3 and iPhone 16 Pro , and consider now getting myself a little more powerful (but low-cost) Android and a pencil. It will be interesting to compare the performance between these devices. Anyway, you totally proved your point with this app!

It is PS alright compared to PS Express. As Adobe characterized it, it is "mobile (and specifically mobile phone) first", and not of course meant to be compared with the desktop version. But as stated above, it shows determination, and is definitely something to consider for anyone taking photos on Android devices... EDIT: For someone on Android getting the mobile PS (the one that is now available for iOS), might well be the trigger to go for a full PS subscription (lowest price today around EUR20 while you could get the Photo plan at around EUR 10 a few months ago), and get it for all platforms (+web and cloud). That's not a bad strategy.

I think you have a point here. Photoshop (similar as recently released for iOS) has been announced for Android. I have no idea how well that would perform on Android tablets, and the full features with Firefly will be subscription only. But it is not technically impossible and not a market and an audience to ignore...

It just occurred to me that one possible cause for requiring specifically for PDF/X-1a:2001 could possibly be the kind of "incompatibility" issue shown by Affinity apps, regarding mixing PDF version numbers. This is just conjecturing, but assuming that the RIP is based on 1.3, it possibly would automatically fall back to rasterizing (disorderly, causing e.g. color changes) everything beyond 1.3, even if there is basically nothing in a later version that it could not handle. I do not know anything about image processors and how common it still is that processing is based on level 1.3 (and how ridiculously expensive upgrading RIPs is), but this could explain the requirement which seems obsolete. Or, that press personnel might need to preprocess files not meeting the preferred specs using e.g. Acrobat Pro or other prepress tool before passing it for RIP, requiring extra work and risk of changing something in the process.

I see. Yes, this still sometimes pops up. As far as I know there should not be any critical difference between PDF/X-1a:2001 and PDF/X-1a:2003. I guess sticking to 1.3 (and specifically the 2001 version) is much a residue of the 2001 version being based on v1.3 which by definition always flattens transparencies, while 1.4 (on which X-1a:2003 is based) as a mere version number does not imply this, even if PDF/X-1a always of course does. So if you get PDF/X-1a:2003 accepted, your only concern would be seeing that you do not have other than PDF/X-1a format PDF placed in (if ever needing to place 3rd party PDF content like logos, etc.) -- as that results in not just rasterization but often also inadvertent change of color values -- and that transparency flattening (= rasterization) does not cause uneven edges. And additionally, that the production file is correctly targeted (as you are producing DeviceCMYK content) -- within Affinity apps you cannot make slight retargeting and change color profile by assigning a production profile at export time ("preserving numbers") but need to do it from within File > Document Setup > Assign (or in Photo, selecting Document > Assign ICC Profile command). And whenever you convert from one CMYK profile to another, you cannot keep K100 untouched so you need to make sure that you convert black that has "inadvertently" changed from K values to rich black, back to K values. To illustrate the issues involved, here is a PDF/X-1a:2003 file (showing uneven edges because of transparency flattening done with rasterization), a PDF/X-4 file (all vectors and ICC based, transparencies unflattened) and the PDF/X-4 file placed and exported to PDF/X-1a (all rasterized, and color values recalculated). pdfx1a_2003.pdf pdfx4.pdf pdfx4_in_pdfx1.pdf

It might be useful for anyone coming from Adobe ecosystem to understand that Affinity specific PDF "rules" result in any non-PDF/X-based placed PDF to become rasterized when exported to any PDF/X-based preset, as well as later PDF version content becoming rasterized when exported to lower PDF version, so if you are going to export to PDF/X-1a:2003, not only non-PDF/X-based content but also any placed PDF/X-3 or PDF/X-4 content will be rasterized. Basically the most versatile export method within Affinity apps is the default PDF (Press ready), which is 1.7. It will accept practically all PDF versions without rasterization, but can also be problematic for many printers because it does not flatten transparencies, and can cause issues by allowing mixed color spaces with ICCs rather than producing DeviceCMYK output. Also, it is good to know that Affinity apps always flatten transparencies by rasterization, which can give inconsistent results (part of an object having been rasterized and showing jaggies, while the remaining non-flattened part has stayed in vector format). There is an important difference to InDesign that can produce whatever is requested and convert placed content as needed without compromises. Whether this difference is important or not, depends on many factors, but If you have advertizers or any need to place third-party professional PDF content, this is going to be pretty limiting.

Not really. What is not inherent, can typically be "fixed" by creating a script. These two Javascripts were created by Marc Autret already for CS4 and provided free for the community and still operate without issues with CC2025: splittextframes.mp4 UPDATE: The feature seems to be provided nowadays also as part of the package, so in that sense an internal feature: I also noticed that there have been for years also two sample scripts provided by Adobe, BreakFrame, which extracts a selected frame out of a text thread (or copies multi-frame selection as independent stories), and SplitStory, which splits a single story to multiple stories according to text frames the story is threaded into. (The startup scripts I have been using allow limited unthreading based on frame selection.) Anyway: all free utilities available for doing these kinds of tasks. UPDATE2: There seem to be free scripts for ID also for doing the opposite, stitching together separate frames as one continuing story, specifically useful in context of data merge. The forum continues to be useful in two directions.

That is self-evident. I was just using the term used by Inkscape, denoting fonts that are "missing" in the sense that they are not available on the system as installed fonts. See the screenshot attached in my previous post. Some apps, like Xara Designer, try to use the embedded font when they open a file for editing, but as far as I know this is illegal usage (especially if you use glyphs beyond what was needed to render the included text, that is, in situations the complete font was embedded, and not just a sub set). Anyway, this is very clumsy and error-prone also in Xara, and pretty much useless these times that plenty of high-quality open-source fonts are available).

As far as I know Affinity apps cannot convert missing fonts to curves at document open time. You would need to use either a PDF flattener that can do this (e.g. Adobe Acrobat Pro or Ghostscript), or an app that can do this kind of a thing, like CorelDRAW, or for free apps, like Inkscape, that can "Draw" missing fonts (convert them to curves) at opening time. UPDATE: In e.g. Illustrator you could also place a PDF or EPS file in document and then flatten missing fonts within a placed object to curves, but as far as I know, this is not possible in Affinity apps (you can rasterize an object and retain appearance but cannot keep vectors), so whenever you "Interpret" a placed PDF, you are not given an option to convert missing fonts to curves, but just get missing fonts replaced with an installed font (typically Arial). UPDATE2: Note that if you have embedded fonts in EPS files, Affinity apps do convert text to curves (even if you had the embedded fonts installed on the system), because they do not support embedded fonts (neither in opening or exporting, in which content they always convert text to curves). Most often you probably get decent rendering, but not always:

Affinity apps are very elementary with indexed (paletted) images, and can only export some limited formats; they do not support opening / editing indexed images but open them as RGB images. Color reduction without dithering is not supported, either, so you would need to do this using other software, like Photoshop. As for free image editors, at least GIMP can do this, including using user-defined palettes.

Grouping and retaining layers is not regular PDF or EPS feature. Illustrator can embed native file within a PDF or EPS file, but this information is basically available only for Adobe Illustrator (and some apps that to some extent try to interpret native Ai format within these files). Affinity apps can optionally (and by default do) maintain Layer layers withing a PDF export: ...and they can also read back this information when they open a PDF file for editing. This is because Affinity has chosen to use so called OCG layers (optical content group layers) this way, instead of using them as document-wide global layers. This means that they are shown as page-specific layers within PDF viewers supporting showing and hiding layers (e.g., Adobe Acrobat), and could also be used to replace grouping, to maintain some of the document structure (even hierarchic structures with sub layers). But as far as I know, none other than Affinity apps support this, when a PDF is opened for editing, so the feature could not be used e.g. to transfer structured design for other apps. See attached modified files where grouping has been replaced with "Layer" layers (objects that are specifically "Layers" within Affinity apps, not just any "layers", as regular objects are, but added as "Layers" from within the control bar in the Layers panel). Note that capability of Affinity apps to read back "Layer" layers from within PDF apps was not initially supported (e.g. in v1 apps), but the feature appeared at some point within v2 apps. I am not sure but I think that ability to read hierarchic structures was not also initially supported but the feature has evolved, and can be quite useful within Affinity ecosystem. 4_structured.afdesign 4_structured.pdf

I think it is a bug. When the code is tried to be read e.g. with iPhone Code Reader, the generated QR code is either not read at all, or gets "decoded" but actually just showing the results of the last read valid QR code. The fact that the preview leaves blank data non-generated (as "Data Merge Placeholder") implies an error in the data merge operation. The mere idea of generating a QR code for blank data is strange, leaving people in a situation where their code readers either do not scan the code, at all (resulting in people wasting time trying and trying), or giving false decoding. At least there should be an option to just have blank space, instead of a generated QR code or placeholder (this is how this operates e.g. in InDesign).

I am not sure if there is a "logical" place for this kind of information. Implementing this in context of Fields is probably related to ability to add custom fields to be included as meta data, somewhat similarly as e.g. in Word, where you need to choose File > Info to access the Title field of the document, and then use Advanced Properties > Custom to add user-defined meta data -- not very intuitive. Having all meta data accessible from one point is not a bad idea, though the feature is not necessarily easily accessible

Window > References > Fields:

Confirming that happens on macOS, as well.

This thread has been a good example of value of learned, well working (but possibly pricey) workflows, and also of value of learning alternative ways (even if painful ones and appearing as kinds of hacks). Personally, these kinds of tasks are not typically needed in my projects, but it was quite interesting and potentially useful to notice the way GIMP handles PNG transparencies, and learn about the complexities involved in exporting from PS and Photo alpha (transparency) while retaining full underlying RGB data, disregarding values of the alpha channel. Anyway, thanks for taking me to a tour: alpharoute.mp4

Strange. The only situation where I have this control (the whole Character Panel, including the Optical Alignment section) grayed out and not accessible is when there is no document window open. But if there is, it is possible to enter characters in existing fields by choosing "Manual" from the control, and clicking the Add button to add new fields (though I am not sure for what purpose, since doing so does not make the definition a default for new text frames; but just mentioning this to describe the behavior, which is quite different to what you are experiencing).

Can you give an example? I tried this by adding question marks in the 100% category for Spanish text, and it worked just fine. I tried this with 2.6.0 on macOS Sequoia 15.3.1. I could both edit an existing field, and add a new one (e.g. 99% offsets), and enter characters in these fields. This works identically also on Windows. I mean that I can see no change in functionality compared to earlier versions. Perhaps there is a specific situation where the feature fails?

I tested Nirmala UI and UI Bold on Windows 11 Pro 2024H2, and could reproduce the issue using Publisher 2.6.0. Other apps that I tested on the same computer, Word, InDesign CC 2025, CorelDRAW 2023 and VectorStyler did not have have any issues producing properly formatted PDFs from the file and the version of both Nirmala UI and UI Bold was 1.46 (and the vendor Microsoft). UPDATE: The PDF properties shows that Affinity created PDF has the regular version of the font embedded twice, so it somehow fails to embed the bold version:

See if this post helps: