kenmcd

Or, everyone else could deduce this conversation (and others similar to it) is futile and move on.

Thanks @kenmcd
After finding some different content I now know that the files were not equivalent. I suspect it is as you say, there was some manual kerning and tracking applied in the latter. I've now been given a free pass to re-do the text elements so I've no worries about the differences in horizontal alignment being flagged in the acceptance process. Thanks for the comment though. I didn't know about that and it's worth filing for future reference.

The only thing that is different in this respect is Canva has deeper pockets than Serif did, which does not change the fact that they still will not comment on if user suggestions are accepted or not. So your so-called "point of order" has been overruled & it is pointless to continue to whine about it.

This is typical of GFs own fonts.
But for most fonts the upstream repository is going to have static TTF fonts without overlaps. And OTF fonts too. OTF static fonts never have overlaps, so that is the easiest work-around.
And you can remove the overlaps yourself - I used FoundryTools-CLI (in GitHub) to remove the overlaps on the Roboto Condensed fonts above.
And you could use it to convert the TTF fonts to OTF fonts.

Here try these - the overlaps have been removed.
Roboto.Condensed.v3.008.(2023-10-19).from.GF.overlaps-removed.zip
Note: Removing the overlaps also causes the hinting to be removed (because the shapes change). This could be added back by running ttfautohint if you desire.

This is typical of GFs own fonts.
But for most fonts the upstream repository is going to have static TTF fonts without overlaps. And OTF fonts too. OTF static fonts never have overlaps, so that is the easiest work-around.
And you can remove the overlaps yourself - I used FoundryTools-CLI (in GitHub) to remove the overlaps on the Roboto Condensed fonts above.
And you could use it to convert the TTF fonts to OTF fonts.

The COLR table was added in OpenType 1.7, in 2015, (for the COLRv0 format).
The COLRv1 format was added in OpenType 1.9, in Dec. 2021 (so that part is newer).
Color fonts using either COLR format can be variable.
Color-SVG fonts cannot be variable - so they really do not belong in this discussion.
Proposed changes and updates to the OpenType spec can be followed on GitHub.
Here: https://github.com/MicrosoftDocs/typography-issues
Future font technology is also being developed on GitHub, and in an ISO group.
The code development and specs are here:
https://github.com/harfbuzz/boring-expansion-spec?tab=readme-ov-file
They have been interacting with the ISO for developing the Open Font Format specification.
There is a newsgroup set-up by the ISO where this is discussed.
Note: the Open Font Format will actually be open, unlike other ISO "public" standards which must be paid for (people made a lot of noise) so you can download the current version from the ISO "free" standards page.
No patents involved as far as I can tell.

The COLR table was added in OpenType 1.7, in 2015, (for the COLRv0 format).
The COLRv1 format was added in OpenType 1.9, in Dec. 2021 (so that part is newer).
Color fonts using either COLR format can be variable.
Color-SVG fonts cannot be variable - so they really do not belong in this discussion.
Proposed changes and updates to the OpenType spec can be followed on GitHub.
Here: https://github.com/MicrosoftDocs/typography-issues
Future font technology is also being developed on GitHub, and in an ISO group.
The code development and specs are here:
https://github.com/harfbuzz/boring-expansion-spec?tab=readme-ov-file
They have been interacting with the ISO for developing the Open Font Format specification.
There is a newsgroup set-up by the ISO where this is discussed.
Note: the Open Font Format will actually be open, unlike other ISO "public" standards which must be paid for (people made a lot of noise) so you can download the current version from the ISO "free" standards page.
No patents involved as far as I can tell.

The google font pack has a few as well if I remember correctly. I might have fudged the name of the font too. The thing with code 39 and 128 is that there's a direct relationship between ascii characters and the barcode it's not like upc where there's a calculation to be made (it's not super hard but you can't do it as a font)

My post above includes a quote from the Affinity and Canva pledge, which uses the wording "over the coming year" - this is all we have to share at this moment

<pedantry>
→→→→edited the post and changed to "side"
</pedantry>
 
P.S As a full stack dev @alfred, I would like to point out that you were not pedantic enough and forgot to use indentation for the text between the <pedantry> tag, necessarily 4 spaces.
Just kidding, have a nice day @Alfred🖐️

Only if/when Serif adds scripting and/or logic the APub's merge capabilities.
I do something akin to what the OP is looking to do via merge logic, character styles and different master pages in a different application. The working sample code is:
«fields bizcolor,biz,name,title,addy,csz,blurb «if bizcolor = "blue"»«set master of this page to "B-blue"» «word 1 to 3 of blurb» «word 4 to 40 of blurb» «biz» «name», «title» «addy», «csz»«endif» «if bizcolor = "yellow"»«set master of this page to "D-yellow"» «word 1 to 3 of blurb» «word 4 to 40 of blurb» «biz» «name», «title» «addy», «csz»«endif» «if bizcolor = "green"»«set master of this page to "C-green"» «word 1 to 3 of blurb» «word 4 to 40 of blurb» «biz» «name», «title» «addy», «csz»«endif» The screen shot below is a compilation of the tab-delimited merge file (which has a field for color), the result after the merge (separate pages), the imposed result and the above merge code.

Welcome to the forums @TheZBillDyl, 
Would not applying a Paragraph or Character Style to the various Data Merge Fields not work for you? Just set the Style to use the colour you want.

Another way to do this is without using a font.
Create colored rectangles. Set the path to them in Excel. In Publisher, use the following layers structure as in the video

2024-04-11 09-00-03.mp4  

The issue is in the font.
Both the Small Caps and the Petite Caps only have the long-tail version of the Q. There is no short-tail version in either - there are no such glyphs available. 
So, some more odd stuff in there. 
I like the font. Kinda amazing what he has done with the tools being used. But it really needs a lotta love.

The issue is in the font.
Both the Small Caps and the Petite Caps only have the long-tail version of the Q. There is no short-tail version in either - there are no such glyphs available. 
So, some more odd stuff in there. 
I like the font. Kinda amazing what he has done with the tools being used. But it really needs a lotta love.

I wonder whether that link to a free download is legit. Filson Pro seems to be a commercial typeface, and not exactly inexpensive!

Ah, i never knew you could get khmer fonts from Google Fonts.
I have done a quick test to with the google font, with the classical fonts that specific organizations use here in comparison to word document in what the correct way it should be showing.Affinity Khmer Font Test.afphoto
I've attached the affinity file and image for your reference.
I seem to still have problems with the Google Fonts. The test includes Khmer OS Siemreap and Muol Light as those are like Arial, Georgia and the Times New Romans Font in English, as they are old but are still the golden standard specific fonts needed to use in certain documents and designs.
The only workaround i have done so far is typing and formatting the words in a word document and screenshot a snippet of it, cutout, and paste it to the Affinity Suite and erase the white background with flood erase. It is very tedious and time consuming workflow in comparison to just being able to type and erase a single character you wish to change, basically.
This is the method i have used over the years but i am requesting this as a feature now. As i have tried the same thing on Adobe photoshop, Gimp, Krita, Inkscape, and these  applications works with the fonts well, but obviously their UI/UX and application is not unpar with what i'm already used to here in affinity.
Thanks for the response! Hoping to have a workable Khmer Font Support.Affinity Khmer Font Test.afphoto
On MacOS, Affinity Photo V2.4.2
Test text: សួស្តី ម៉ោង

Thank you! Unfortunately I'm still having the same problem after clearing the cache, removing the fonts and re-downloading.
 

Thanks for letting me know - I agree these certainly appear to be similar issues under different reports, I'll get these linked together internally now for our development team.
Unfortunately I'm not personally well-versed enough in font metrics to be certain if this is something that our team can fix, though I am sure if we can improve the way these fonts are handled in Affinity on Windows, our team will be happy to implement said improvements to the app

As @kenmcd indicated here, support for multi-mapped glyphs varies from one OS to the next.

Probably the same issue (excessive multi-mapping).
But I never did get a look at that particular font.
It is mentioned that it is "an all caps font" so it could have the same multi-mapping to the lowercase characters like these ones.
I looked at the three KC Leisure Park fonts, and many others from the same developer in a pack of their "free" fonts (61 fonts).
Wadda mess.
Does the same thing as the fonts in the other thread I linked to - when butchering his fonts to make the free versions, he multi-maps all the glyphs he has removed to the base character.
So Aacute is mapped to A, and Agrave is mapped to A, etc., etc.
Sleazy.
And dumb.
 

This issue is also tagged as AF-1541:
Default horizontal spacing on certain fonts WAY off.

@Dan C 
This appears to be the same issue as AF-1541.
See: https://forum.affinity.serif.com/index.php?/topic/195968-font-rendered-and-exported-differently/
Another case of a font created with Fontself Maker with excessive multi-mapping.
The problems with excessive multi-mapping are discussed in the above thread.
So basically the problem is in the fonts.
Yes, some other applications may handle this, but creating fonts like this is just dumb.
Which is why Adobe strongly discourages it, and Google Fonts outright prohibits it.
 

@stokerg 
The Windows 11 color emoji font recently added the COLRv1 format in addition to the existing COLRv0 format (which Affinity does support currently).
So it is only a matter of time now until an Affinity user asks why their color emojis do not look the same as in other Win11 apps (e.g. Word) which display the COLRv1 versions.
Supporting COLRv1 would solve that issue - and this one.
Please make a note to the devs in AF-2609.