Ramon56

This is fine, but the problem is a different one: I have also experienced this issue. It's no good that you can merge different documents if afterwards Publisher crashes because the resulting file is so big that it cannot handle it... PagePlus had also this issue, but the "book" feature did not physically merge the files into a big file, it was only used to perform the final publication, and that worked like a breeze... Well, I hope it does not take four years (and counting) before it is added, like footnotes.

The predecessor of Affinity Publisher (PagePlus) had the capability to build "books" by including/merging several files. This was a nice workaround to the fact that it took ages to process big files. If Publisher cannot handle a whole book, then they should consider adding this PagePlus feature.

When i use my Kindle, Footnotes are handled as a pop-up. End notes are at the end of teh ebook.

Fully agree! Look at what Will said. In any case, the functionality that is missing is exactly what all users have been screaming for over the past years (not only ePub, but for example footnotes/endnotes). If you provide similar functionality and drop the "old " version, you are "replacing" it, like it or not, even if it is not exactly the same. And then you should have the main features (not the same code!). You can add new features and drop unused or unnecessary ones. And BTW, you only inherit the bloat and bugs only if you reuse the code, but that is NOT what we are talking about - we are talking about features, not reuse of code! For your information, I have over 40 years of experience in software development (I started with punch cards!). I have developed desktop software, websites, corporate systems and even airborne software operating systems for fighter aircraft. I have also chaired two international software standardization committees, so I need to take no lessons from anybody. Having stated that, and having also developed consumer software, when you drop a product and replace (YES, replace) it by something oriented to the same purpose, the users expect something similar or better. You can develop it from scratch (no objection to that), but you should take care that you include the features that your users value. The very first thing that we did when we developed consumer software is ask the users what features they considered essential/valuable, and made sure that those were included. This is not discrediting anyone's work - but ignoring the users and what they require is simply sloppy and is unlikely to increasy user satisfaction. Anyone with a minimum of knowlege in marketing will tell you that user satisfaction is key to the success of a product. It is evident that you are NOT a software designer, because otherwise you would know that the backwards compatibility of old files is not necessarily maintained even over different versions of a same software. Plenty of examples abound. And you are insisting on code, as if code portability and code reuse was the only solution when you want to create a new product or even a new product version. Let me tell you something: I completely redesigned with my team a major application that had been initially developed in Powerbuilder to C++. Significant architectural changes had to be done, and except some very few algorithms, NOTHING was reused (zero code ported). Yet it was marketed as the new "modern" version of the SAME product! (and yes, we created it from scratch.) Backward compatibility? None. We had a way of migrating the old data (by means of a conversion program), but there was no way to run the old files/databases, nor get back to the old format. It simply made no sense to maintain backward compatibility, and still it was a new version of the same application!

That was also my understanding.

Agreed. But PagePlus did have a limited capability to do this. On one side, you had the PagePlus documents, and then you had the PagePlus books (see example from one of my books below). They were two different types of files. The PagePlus document would be equivalent to the S1000D data module, the Pageplus book would be the S1000D publication module. They need not to be mixed, as Scriverner does, but it's much easier to implement. This PagePlus feature would probably not be sufficient to handle the S1000D documents, but it certainly would cover the Scrivener equivalent. You could improve it by "linking" the individual files to the Publisher sections.

I regret to tell you that I have an university degree in Computer Sciences, and have developed desktop software, websites, corporate applications and even airborne software, so I cannot be included in the "some users" group that you mention. I am perfectly aware about what software development is, how much it costs and how long it takes, as I have been doing that for almost 40 years. (I started my CS studies with punch cards!) I have also chaired two international software standardization committees, so I do not need to take lessons from anybody on this subject. And yes, it's not just "cut and paste", most of the time you have to develop things from scratch, often even for upgrades. However, when you develop a new product that is supposed to replace an older one, you DO include in the first development all the important features of the old product. What it does not make sense is that you provide a new product that does less than the old one. If that is so, why should I buy the new one? If you have an XXX phone, would you buy a phone taunted by the manufacturer as "the new XXX" if you find out for example that it cannot play music, which your old XXX can do? Had I know that Publisher had not included some critical features that I did have with PagePlus, then I would not have bought it in the first place. When I found out that it didn't, I still hoped that they would include them in some of the minor versions. It has however been years, and those features are still not there.

Yes, I am aware of them, but ultimately these are proprietary standards developed by a single company. S1000D is an international specification which is publicly available and is developed jointly by three standarization organisations representing both US and European industries that employ together almost 3.000.000 people. It is therefore a powerhouse amongst standards. Having used Scrivener myself, I must fully agree. But I like a lot its modular capability, in order to manage separate files. PagePlus had also that capability, though more limited than Scrivener. If Publisher can add the main features of Scrivener, such as modular use, ePub export, etc, it would really become the standard for those tasks.

I have used Scrivener myself, and agree that Serif would have a good opportunity in grabbing the market for indie authors and small publishers. However, Scrivener has a couple of things that Publisher does not have, which is surprising because its predecessor (Pageplus) had them: Export to RTF and ePub Modular (combination of several files such as separate chapters and viewing/publishing them as a single book) Footnotes/Endnotes Internal cross-linking

In practice, over 90% of the ebooks distributed are actually ePub. Even Amazon is abandoning its proprietary formats (such as MOBI) and moving to ePub. Personally, I do not feel that PDF is an eBook. It's electronic, but it is page-oriented. eBooks are reflowable.

Like footnotes/endnotes, the request for ePub conversion has been going on for years... and no implementation done, much even less a response of when or even if it is going to be implemented. ePub generation was implemented in PagePlus, the predecessor of Publisher. I simply don't understand why Serif replaces a product that does NOT have important features the the predecessor had. The new product is "supposed" to be better than the old one, isn't it? Then why does it have LESS features? Honestly, I am more and more regretting buying this software, and if they make a new (paying) release, you can bet that I will NOT buy it uness it has ALL the featured that I need.

In technical documentation, there is actually an international specification for the production of technical publications: S1000D, “International specification for technical publications using a common source database”. It has been around since 1989 and is regularly updated. It is based on XML and mainly used in aerospace and major products such as ships or complex equipment. However, they have actually documented an example using a bycicle, so as to show that it should not be used "only" for complicated equipment or products. Most major defense departments in the world (MoDs) currently demand that their technical publications are delivered in S1000D format. In case that you are interested, you can get it (for free) at http://www.s1000d.org. Additionally, there are some associated guidelines on how to actually write technical documentation, namely STE-100, "Simplified Technical English". You can get this (also for free) from https://asd-ste100.org/ There are tools out there that allow to define data modules in accordance with S1000D, and the generate the publication. The interesting thing about the data module concept is that you can assemble the publication from the different data modules, and reuse a same data module (such as warnings, or how to open a panel) multiple times in a same document. This is the (b) concept that you outline. And yes, you can generate the S1000D database, an IETP (interactive electronic technical publication), the PDF or the book from the same sopurce. However, I do not see Affinity to build in this capability in Publisher, though I think it would a nice feature, as it greatly expands its flexibility. If they DO address this capability, they should certainly allow to export these kinds of "books" in S1000D and IETP formats, as that would be greatly appreciated by small and medium companies that develop S1000D information but have to pay for far more expensive tools.

I disagree, for the simple reason that for us it is far easier to implement endnotes manually (like normal text) than footnotes (where you need to create specific text boxes and adjust the text).

Nonsense. With one single engine, if it fails, you crash. With multiple engines, you continue flying. Why do you think passenger aircraft have two, three or four engines? Even with one single engine you can stay in the air. I had once a fire on the right-hand engine of my plane when returning from Munich. It looked really scary. The pilot shut it off, pulled the fire extinguishers to get rid of the fire, restarted it, and continued flying. We were not even halfway, but we landed normally on our destination airport. Most passenger didn't even notice that anything had happened, just those looking out the window at that time BTW, modern computers have multicore processors for the same reasons that aircraft have multiple engines. It's safer, quicker, and if one fails, the others continue working. They call that redundancy.

I regret to say that you are badly informed. the DA6 engines did not shut down, they WERE shut down on purpose. It was a test flight, and restart of the engines was tested. First they performed the test by shutting down one single engine, and it worked. then they tried the other engine, and it also restarted correctly. Then they shut off both engines, and it did not work because they had installed two engines of different versions, and THAT had never been requested as a requirement, so the software did not know how to handle this. It's more or less as if Publisher was supposed to work under Windows and MacOS at the SAME time. Oh, and I wish Publisher HAD ejection seats - I've lost twice my work because Publisher crashed and was not able to recover it. P.D. MY software worked perfectly!