benwiggy

Calibri is a Microsoft font and comes with Office. The version on that linked site is quite an old version. 
Bauhaus 93 is a specific version made by URW. The ones in the wfonts.com link look like crude imitations that aren't very accurate.
 
Do make sure that you are legally entitled to download these fonts for free. 

Editability seems to be what Affinity has gone for from day 1. PDFs in Publisher are treated as some kind of interchange format, in which the text can be fully editable, even if it's in the wrong font/glyph/position. Hence the "Favour editable text over fidelity" option. (Sadly, unchecking the box doesn't guarantee fidelity.) But this behaviour is identical in Designer, and even Photo.
While there are circumstances when this might be useful, it's a curious architectural decision to prioritize over the more 'normal' needs of accurately rasterizing; accurately placing; and accurately rendering for vector editing.

That doesn't work either. Even with the correct fonts installed, PDF imports don't use the correct ligatures and OpenType variants. Text objects also move. 
I'm going to offer you the compromise wording of "PDF import guaranteed for small minority of specially prepared PDFs!".  

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

The other threads about ligatures are about PDF import, (which is unsupported), not export. 
I'd humbly suggest that turning off all ligatures may not be desirable or viable in all circumstances.

I was invited to a pre-release showcase of InDesign, and remember being blown away by what they said it could do, compared to XPress 3.3. Text layers, improved typography, transparency handling, native PDF export -- so many things that would improve our workflow. (Foreign hyphenation at no extra cost!)  I can't remember if the release lived up to it on day 1, though. 
 
If they already have a PDF rendering library to use, I can't understand why implementing it is such a 'complex problem'. But of course code is never straightforward.
Affinity seems to import EPS and SVG vector files perfectly, outlining the fonts automatically at import. For my needs, that's a workable solution, though not for everyone.

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

Running a web server for an API (or a web browser or Flash Player for dialog boxes) is exactly the same type of bloat that we all criticize Adobe for. They, too, are running at least one local node.js web server in the background even if none of their applications are active. You may have noticed it because it occasionally hangs, crashes or blocks system shutdown.
Scripting isn't that performant in the first place, and running single command through a full-blown set of script interpreter, API in that scripting language wrapping and parsing the HTTP communication, HTTP server, system TCP/IP stack and what not is such a colossal waste of resources, not to mention it opens up the entire system to security vulnerabilities.
If you really have a compelling case why you absolutely must automate Affinity applications over an HTTP API, you could easily implement the relevant parts of such an API yourself, either via a native C++ plugin, or even easier, with a Python script and Flask (a combination which by the way could probably replace InDesign Server with a desktop version of Publisher for quite a few use cases).
This is by no means about what is trending, but what makes the moste sense in terms of providing an efficient, robust, powerful, extensible and future-proof scripting workflow. Besides, Python has been a staple of application scripting in the VFX industry (among others) for decades, and for a reason. This is by no means just a "trend" and there is no indication whatsoever that it will go away any time soon. As an established solution, there are a lot of companies invested in it so continued development is pretty much guaranteed for the foreseeable future.
Lua is indeed great for smaller quick and easy scripts and easy to integrate in a C++ program, but not that suitable for more complex solutions (hello, Adobe Lightroom Classic mess) and its object-oriented language features are lacking compared to Python. C is not even a scripting language and does not scale too well, which is why it has been replaced by C++ as the language of choice for larger native software projects decades ago. It is also not true that the complexity of implementing one solution in different languages is always the same – it is true for very, very simple code, but as solutions become more complex, some languages, and their ecosystems, are significantly more powerful than others. As someone who has worked with both Python and VBScript I can tell you that there are some things that would be a nightmare to write in VBScript and a five minute exercise in Python.
We don't need a hundred haphazardly integrated scripting solutions so everyone can avoid spending 30 minutes to learn a few basic new syntax rules, but one great scripting solution that is well thought-out, seamlessly integrated, simple and easy for basic tasks but powerful enough for the most complex requirements that arise, and interfaces well with the outside world (AppleScript/COM, network/HTTP APIs, third party libraries and applications, native code etc.).

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

See my thread here (and several others) about this. Unlike other DTP and vector artwork software, Affinity does not support importing PDFs with embedded fonts (i.e. any PDF with text). The correct glyphs will not be used, and some text elements will move.
You will need to Outline the fonts (ie. convert them to vector graphics, instead of text). You can do this in Acrobat DC's Preflight panel. Or in Illustrator you can do each page.

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

I'm seeing a few errors when opening PDFs into Publisher (and Designer)  with some text objects being positioned incorrectly. Also ligature glyphs are replaced by a ?. 
Occasionally, some other glyph substitutions. I've no reason to suspect the PDFs themselves, as they behave in all other apps.

There are two points here:
Firstly, I'm seeing errors in placed PDFs even when I have all the necessary fonts installed. 
Secondly, PDFs can be placed correctly in InDesign, Illustrator, XPress, Apple Pages, MS Word, etc etc, even if the correct fonts are not installed on your system.
 
Affinity's ability to turn PDFs into editable content is welcome, but the ability to place a PDF on a page as an 'image', accurately,  is paramount to a DTP app. 

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

At the very least, importing IDML files is a must. Scribus and VivaDesigner both do this, and it's the only way to get punters to switch, if they've got legacy documents.

There are several posts on the Designer and Photo forums requesting some sort of Automation, so I thought I'd echo the sentiment here.
It would be great to see the Affinity Suite using AppleScript, or JavaScript or Lua. Or python!   (Assuming I'm not missing something!)
There are many people who are dependent on Adobe because of the scripting capabilities.