MikeW

If you're wondering about the top two font names and effects, they are forms of Algerian & Britannic, both with white outlines and drop shadows.

As long as sanctions are in place, there legally isn't anything that Serif can do but adhere to them. Hopefully the war will end sooner than later and the sanctions lifted so sales can be resumed to the Russian people.

@Old Bruce, in other software, I use the requested functionality several times a year. And even if MS et al produced images of that resolution as grayscale, Affinity applications would convert them to rgb as well as being problematic to place 50 or hundreds of those images. If one doesn't see the point of a request, why argue with posters that would use such functionality?

Excellent detail! Very well done.

Ah, well that makes sense. Complex ltr, at least Indic ltr, will likely arrive before rtl. At least that's what I would do. There isn't a lot of additional OpenType features to add to make it work plus no bi-directional handling to suss out.

Maybe not a good idea if for no other reason of splitting the applications into yet more separate applications that require yet more development time/resources. Mainly, these are OpenType features that once added and processed by the Affinity applications present the text runs on the design surface properly. At least for complex LTR scripts. The same for RTL with the addition of handling bidi text runs. There is nothing to be gained by splitting the applications, only downsides.

Up until InDesign CS4, ID shipped with 76 main templates, but there were others available. Since CC, ID templates have grown via Adobe Stock, there are about 13k of them. Envato has about 12k of them. There are a lot more. Dunno if that is "professional" enough for you. But still, the PP templates were well integrated. They worked nicely and were the easiest to quickly modify. We'll likely never see such integration in APub because of certain differences. Oh. Both Serif's layout applications were designated (by Serif) as professional applications. One had them, one doesn't. Such is life.

Other than .eps not supporting transparency on individual objects, there is nothing wrong with them. They are generally smaller in kb and faster to generate a pdf. Despite people who advocate not using them, I do when they are appropriate.

Yes, ID does allow one to change just about every type of default style, including object styles. One just does it with no document open, make the desired changes, and close ID. When restarted, the changes are new defaults. QXP also allows this. The difference between ID/QXP and APub/AD is that once that object style is used in a document in ID/QXP and subsequently altered, the style becomes a document-only style as you mention. This is how APub/AD ought to work too.

VS didn't work for me (using the Win version). Xara P&GD nearly always works for me (and did in this case). CD did and keeps it as a vector pattern (after a fashion). PL did keep it as vector, but uneditable points as far as I can tell (as did QXP). Didn't try InkScape.

Because Affinity applications do not understand how to handle the pattern fill property in a pdf, if you Expand the pattern fill in AI, it will be editable in AD. Just make sure to do it on a copy of the AI file...

Tagged text is a plain text file with code and/or instructions that, when imported into an application that supports tagged text, can format the text as it is being imported (like my previous screen shots). However, tagged text in such an application can be far more than only formatting text. For instance, tagged text in QuarkXPress or InDesign can also create cross references, indexing, create running headers, "simple" math, choose and apply master pages during import based upon conditions, create and position text and graphic objects and more. It's a powerful capability that several of us have requested Serif to provide in Affinity Publisher.

I just fix them. There are issues at the github repository for some fonts too. Often, the same GF fonts via Font Squirrel do not have the same issues (except the feature coding errors). There are also issues with some Adobe fonts. And with many commercial fonts direct from their respective foundry websites and/or the resellers (like MyFonts but not limited to MF). I've had unexpected issues with fonts I've either wholly made or feature coded. Crap happens. This rendering issue may be up to the OS renderer or the applications or a combination of the two. Serif can only fix an issue with their applications should it exist.

No, the font is technically correct. Various rendering engines, especially those that do not support variable fonts, can render each component with artifacts, including the artifacts shown in this thread. Many Google fonts on the GF website do have various issues in many applications.

The main difference in the github and GF font versions is that the GF versions are made of the component, overlapping parts derived directly from the Variable version as can be seen here: While the github version has its static version made with overlaps removed:

Yes, the kern tag is interpreted during placing. It's a supported tag.

First, kudos to @lacerto for the wonderful perseverance in digging into how this formatting can be achieved in APub. My hat's off to you! I did want to circle back around to the following: Yep, tagged text can the issue in two ways, either by explicitly encoding a tracking value in the tagged text file (here, the <k-375> tag prior to the space character): Or via a c.style, which has a negative tracking value for the space character: However, that c.style can also be manually applied or be applied via conditional style in Q, etc. In all cases, the result is the same: It doesn't matter what the text string is. I'm pretty sure ID can have negative kerning/tracking in a c.style as can QXP, and certainly can be done via tagged text.

Thank you for letting us know. Looks great!

Here ya go...Viva Designer can. So can IDMarkz SE, its output is .idml which can then be opened in APub or anything that can open .idml:

@MattyWS, @Pšenda... This thread is a Pinned Thread. This can only be done by Serif staff. I think there is at least one good reason why it is a pinned thread--if for no other reason than to keep the discussion in single place. But MattyWS is correct, why not just avoid posting here? It is a legitimate topic.

You are most welcome. Affinity Publisher can only open .idml versions. So X number of people here will gladly convert them for others. Ingram should be using that format anyway.

Here's an .idml version of the cover template. That should open in Publisher. 9781737773306-Perfect.idml

Yes, but at least the whole can be moved onto the page and resized.

I personally would just open it up in an application that doesn't have such issues, then, if needed in an Affinity application, export to a format that Affinity applications respect.

If I recall, the templates Serif previously supplied were not made by themselves. I might be misremembering... But, that also means, if true, there was likely on-going royalties, likely based on sales which is one thing on new sales when in general the cost to the customer was $100 on average. Quite another when $50 per license. While, again if true, that means less/little taking time from development, it lessens profit. If Serif owned those templates outright, they could contract with an idiot like me to convert them for very little cost and/or simply give permission to do so for those of use that have them.