HenrikM

@thomaso
Thank you for taking the time to do this. However, perhaps we aren't referring to the same things. The examples you've provided demonstrate that Affinity Publisher indeed handles links or hyperlinks in a variety of ways: page, anchor, URL, file, and email. Hyperlink interactivity is indeed very useful.
I should have been a little clearer though. What I refer to as cross referencing is more old school, not involving interactivity that indeed you've demonstrated Publisher can handle.
To me, cross referencing is used (and still especially useful, even in these days of electronic publishing and document interactivity) in text to refer the reader to other sections, figures, chapters, appendices, etc. of interest. Here are some examples:
- Refer back to section 3.4 "System Operation" for more information.
- Figure 43 on the next page illustrates this concept in action.
- Full system specifications are found in Appendix B on page 343.
Not all technical documentation is always available in electronic form. Sometimes paper copies still dominate.
Cross referencing is referred to by this name in FrameMaker, InDesign, and even Microsoft Word, all of which also offer hyperlink capabilities similar to Publisher and what you've demonstrated with your two examples. 
 
Can text anchors be used to repeat, rather than link? By this, I mean, can you add an anchor to say the heading text "Appendix B" and then somewhere earlier in the document body text "call" that anchor to be repeated (the refer to "Appendix B" part of my earlier example?).
 
The Publisher workarounds I've seen proposed are similar to what is described here:
But really, this workaround isn't as simple, quick, nor intuitive as what is seen in Publisher's competition.
That is, unless I've just missed this capability as I continue to evaluate the full suite.

Many thanks for the screenshot and further information provided!
I'd recommend changing View Quality to Nearest Neighbour  and Retina Rendering to Low Quality (Fastest).
I also recommend ensuring you have the latest drivers for your GPU, as this can cause rendering issues within Affinity. You can find the latest drivers for your card here - 
https://www.nvidia.co.uk/Download/driverResults.aspx/183486/
Once installed, please restart your PC and then re-launch the Affinity app. Does this change the behaviour for you please?

SQL is a domain-specific language that does not really belong in a comparison with the others.  It is like comparing the popularity of apples, oranges and Japanese.  That alone likely skews the results to the point of being less meaningful than a proper comparison.
Ignoring that I do find it to be a sad reflection on the state of our culture that so many programmers today tend to favor some of the worst programming languages in existence that none of the more reasonable ones (except SQL which again doesn't really fit with the others) even make it into the lists.  People are in so much of a hurry to produce fast sloppy coding with cryptic syntax that no one is taking the time to produce solid, readable code.

Python please.

I would also like to know this. When I import a Portrait Mode photo from the iPhone, I get the Depth Map as a separate grayscale layer in Affinity Photo. I can then edit the Depth Map by e.g. painting on that layer. So far, so good.
However, there are two things I cannot do: First, I couldn‘t find a way to actually preview the Depth Map layer as an applied depth of field effect on the image. Second, I couldn‘t figure out how to export the image with the edited depth map so that Apple Photos would recognise it as a Portait Mode photo.
Any hint would be greatly appreciated.

We may have discrete Sections available as Fields but running footers/headers making use of specific paragraph types (i.e. Heading 1, which might have Flow break to the top of the next page). Ideally, we could configure which paragraph styles are accessible in View > Studio > Fields.
My suggestion would be to have it user-configurable from right-click the "Edit <Paragraph Style>"
Paragraph > Field Options
Available as Field? First or last available? On Page or Spread? (see relevance of first/last in previous question) This would make for some really robust footer/headers on master pages, esp. in education or technical materials with dense, structure order to their contents, allowing us to guide the read through. The Field referencing the other Paragraph style occurring in the main document could be styled by any existing paragraph style as expected.

I would like to inform you that these features missing in Affinity Publisher are a big problem for me. I started editing 18 printed books in which the cross-reference function would be of great help. There are up to 100 such references per book. Some of them are references that refer to previous volumes. So there is an example of the sentence in Vol 7 "... as I mentioned in Vol 2, Lesson 5.2, page 42, ..." This example therefore requires a reference between two different afpub files. In my opinion, this should be possible. Such a reference has been possible for years in Excel, for example. These 18 books are also published as e-books. At the moment I am still creating all e-books "by hand". That means I create xhtml, opf and ncx files manually in a text editor. Also with an index (of about 10 pages in the printed version).
Example of this printed version (created on Affinity Publisher): https://www.amazon.fr/Cerveau-son-fonctionnement-Psychosyntérèse-U-M/dp/1695360907/ref=sr_1_1?__mk_fr_FR=ÅMÅŽÕÑ&dchild=1&keywords=Le+Cerveau+et+son+fonctionnement+I&qid=1595160754&quartzVehicle=77-946&replacementKeywords=le+cerveau+et+son+fonctionnement&sr=8-1
I also have the general impression that the current version of Affinity Publisher is not suitable for long technical documents. Of the 18 books mentioned above, which represent a course in psychology and neurology, each volume has about 120 pages. If someone wants to write a technical book with several hundred pages, which contains a lot of diagrams and figures, as well as a detailed index, I have the impression that AP is too slow.
I understand that you don't want to talk publicly about your plans. But I can't wait very long because I have to edit the books mentioned. What do you think I should do? Test Adobe FramMaker?

Am evaluating the full suite of programs and thus far am impressed.
One missing feature is a killer for me though, with respect to Publisher. The program needs to support cross referencing out of the box without needing to use workarounds. Technical and scientific documentation can't live without this key feature.
I am coming from a FrameMaker/InDesign background.
Is this on the Publisher's near-term roadmap? I've seen other requests for cross referencing posted on this forum. As minor as this feature might seem to some, it is what is preventing me from making the switch away from Adobe.

I was a FrameMaker user for years, so dropping back to InDesign was a bit of wrench - like not having decent configurable running header capabilities.
I'm trying to create a user manual in Publisher and the lack of Cross-Referencing is a real pain.
I'd like to cross reference by browsing to a Heading/Section and having it auto populate and change if the destination title changes. Right now...
Write cross referenece link (and hope you get it right) Navigate to Destination Create Anchor Go back to cross reference location Hyperlink Cross reference link is a long process.

Add me to those voting for footnotes and endnotes, but with a strong stress on the later. Visit any university library and you'll find that endnotes replaced footnotes long ago, perhaps in the 1950s. In the era before computers, endnotes were far easier to typeset. In todays world, their appearance at the bottom of a page is seen as clutter by most readers. And being able to have both in the same document would be handy. Footnotes could be used at the bottom of a page to clarify ideas. Endnotes far away could be used to give references that most people don't read.
I would, however, agree with those who'd like to see footnotes handled in a more powerful way. Untangling Tolkien, my day-by-day chronology of Tolkien's The Lord of the Rings was done in Framemaker, which allowed me create the equivalent of footnotes for references to the source in LOTR in a sidebar alongside the text to which it applies. That worked far better than bottom of the page footnotes or endnotes. I can't do that in ID.

I've drawn an illustration of a crocodile for no reason except too much time. 🙂 I'am working with Designer and Photo on a windows pc with a wacom tablet attached. The original photo was taken by vaun0815 at unsplash.

We often see it mentioned that footnotes and endnotes are hard and that APub is a "new" product and that algorithms must be invented, as if footnotes and endnotes have never been done before (except by Serif in its abandoned PagePlus product). 
I have been writing long documents on computers for nearly 40 years. Every product I've ever used, from GML/Script on an IBM mainframe in the early 80s, to the shareware PC-Write under DOS in the mid-80s, to WordPerfect in the late 80s, to Word for Windows beginning in the 90s, has included footnotes and endnotes. Even the free Libre Office does footnotes and endnotes.
Surely the algorithms for doing footnotes and endnotes are by now very well-developed and widely known, not something that needs to be reinvented by a company that previously implemented footnotes and endnotes in products introduced nearly 30 years ago.

There is no good presentation program in the PC/Windows market.
Even a very basic presentation program built on the Affinity Photo/Designer/Publisher platform and licensing model could be a killer app.

I occasionally do presentations, on topics ranging from photography and digital art to management history, agile methodologies, systems thinking, and complexity thinking. I am not the best presenter around, but I am good enough, and well know enough (, in my little corner of the world), to get paid to present.

A couple of years ago I switched from using Macs to using PCs, and I more or less stopped doing presentations, except at work, where I used PowerPoint. Can't hold a candle to Keynote, but I used it because someone else paid for the licence.

Now, I have been asked to do a couple of presentations outside of work, in locations where there may not be a reliable WiFi connection, so I started looking for a decent presentation program that runs on the PC.
I could not find a single one!

First, I'll describe the showstoppers that keeps me from using the PC software I had a look at. Then, I'll write about why I think adding a presentation program to the Affinity suite would be an excellent idea.

Showstoppers:
Licensing model: Most presentation software for the PC have a pay/month licensing model. If I was a full-time professional presenter, that might be worth it, but I am not. I expect to use the software 4-8 times per year. Dependency on the Internet: I need to be able to run the presentations locally on my computer. WiFi guest networks are not always available. When they are available, they tend to be unreliable. Quality: Basic things, like doing a cross fade between pictures, tend to suck in opensource programs like LibreOffice. Don't get me started on the cluttered LibreOffice Impress user interface, designed to show off as much functionality as possible, while completely ignoring how presenters think and work.
  Each one of the three problems above is enough to stop me from using a presentation program. While a bad user interface is painful enough on its own, if the quality of transitions is bad enough, I won't even use a free one.
I believe there are many other people who feel the same way. That creates an opportunity for Serif:
The Affinity products use the licensing model I want. Affinity products are designed to work offline, while at the same time taking advantage of online features, like online picture libraries, when Internet connection is available. The quality of Affinity products is already excellent. They take advantage of fast processors, and fast graphics cards. In addition to solving the showstopper issues, Serif has several other strong advantages if the choose to make a presentation program:
Much of the functionality has already been built: Excellent drawing tools Great image processing tools Asset manager Online image libraries Page management ...and so on.
The only things missing are page transitions, simple animation features, and a presentation mode.
 Because of the very tight integration between Affinity products, I believe a presentation program would require a modest investment in terms of time and effort. At the same time, the integration would make it uniquely powerful.
It would be possible to design the program so that it focuses on graphics, not on bullet points, which would be great.
What do you think of the idea?

On the other hand, it doesn't require a well-drilling rig to simply put a screw in that piece of wood.
All that's required to provide versatile flow-, org-chart functionality is a basic connector line object and an appropriate symbols library, both of which are common in vector drawing programs, and both of which can also be used for other creative purposes. (Affinity already has a suitable Symbols feature in which one can store and organize their subject-specific box shapes.)
As far as "polluting" the program goes, this is not a narrowly "vertical" need. I dare say the majority of vector illustrators encounters at least the occasional need to create such diagrams for everything from org charts for the VP to decision trees in the troubleshooting manual. (Ever had to hack such a simple thing out in Illustrator, which provides no connector lines, even though all three of its historic competitors do? I have, many times.) When a connector lines feature is present, it can also facilitate wiring diagrams. And maps. And assembly diagrams. And extrusions.
The key to maintaining powerful elegance is careful and innovative integration of features. Just off the top, why can't a "connector" just be a path end attribute? Or why can't a Connector Line be one of the Smart Shapes with adjustable parameters? Functionality doesn't always have to be implemented in the same way as conventional wisdom assumes. Every little added function doesn't have to be presented as an Adobe-esque overblown standalone in the grab-bag interface.
I'd favor some kind of connector line functionality. It's not unduly obtrusive in Canvas or Draw or Technical Designer. But the request would probably be better received if stated as that—connector paths—instead of as something specifically for network diagrams. The basic functionality can be useful for all kinds of things.
JET

You know… connect objects with lines so that dragging objects causes connector lines to redraw appropriately as one might expect in org chart and mind mapping applications. Export network diagrams as outlines or import outlines and auto-create network diagrams. Please. Thank you!

Hello,
Forgive me if any of these are already in Designer, is it possible or are there plans to add:
1) Full screen presentation mode for presenting mockups to clients
2) Pages - I know we have artboards - but we're old school and still like pages :)
3) Add hyperlinks  so when in presentation mode we can use basic linking to click between different pages or artboards.

This! OMG! Never thought about this! This way, developers can control Affinity programs in any language flavor they want. I would use Python and Typescript. <3

Affinity products are not Adobe or Quark products.  There is no reason they need to make the same suboptimal choices their competitors are making.
 
I'm not but note that at least on the Mac this should technically be possible because there are ways to hook Python, Perl and other languages into the underlying OSA framework - even if nothing else they could use the standard command line osascript tool.
 
That is indeed a LONG AppleScript, though I've written solutions for various (unrelated) things in Perl which are many times that size.  I think by the time an AppleScript got to be that long, I would be thinking about rewriting it as a native application, particularly if it is performance-critical or gets frequent use.
 
Even if the Affinity team steps up their game and makes the programs fully scriptable via AppleScript, there is no guarantee that the specific data model would be even remotely similar to the one used by InDesign.  Even with the same language being used the scripts might need more than minor changes to work with a different application (the object model should reflect on the way that the application itself is organized and that might not match up).  There is similarly no guarantee that Adobe won't change their scripting API somewhere down the line and you may need to rewrite your scripts anyway.  Yours is somewhat of a corner case (granted an impressive one) rather than a common situation.
 
That is not what is happening here.  There have been numerous suggestions but they are all for well-established scripting languages, no one here is re-inventing the wheel.  I do agree that AppleScript should be supported on the Mac, as I find it rather irritating when Mac apps don't support it (it should almost be required to be considered a "good citizen" on the Mac environment).  JavaScript is another story, as is a kludge of a language to begin with and not a good choice for general application scripting.  The only reason it is a "good choice" for web sites is that it is the only one that web browsers universally support.  Even people creating web apps are starting to create them in other languages then run translators to convert those languages to JavaScript before deploying them...  given that JavaScript was originally designed for use on web sites, that is a fairly good hint that it's not even a good language for what it was designed for, much less for something as different as this.

Hello, 
I have tryed brushes, blanding modes an effects on paper surfaces. I think it is interesting to work free in Affinity.
This one it is done in AffinityPhoto.

Or just good old Python like every other piece of software in the world that isn't InDesign, lol.

+1 for python. See the magic that happens with drawbot or nodebox

I've run into a Publisher crash yesterday that somehow involved Apple's JavaScriptCore library – I do wonder if that's an indication of something coming up 
That being said, I'm still hoping for Python instead of or at least in addition to JavaScript. Having written extensions for different software with both languages, I found that writing extensions in Python was always quick, easy, efficient and even fun, and there are tons of great third party libraries available, whereas any kind of JavaScript extensions, particularly for Adobe programs, have consistently been a royal pain. Getting good integration into the user interface of the host applications (like adding custom menu commands or panels) has never been very robust with any JavaScript-based extensions in any application I have come in contact with. And it's so easy to learn the basics of Python that I believe anyone with JavaScript experience would be able to get started in no time.
I realize that's a rather controversial point and everybody has their own personal preference, but I do encourage everyone to have a look at a few basic Python tutorials and form their own opinion.

Well, as mistake prone creatures, we all can improve --- can't get much better than that for a first try though.

Thanks!
There is room for improvement. There are some things I'll do differently next time. Still, I am happy with the results, and more importantly, so was the model.

Even more impressed. Again, nice work!