Books

[Blair Purvis]

With every beta release of Publisher, I immediately check for File - New - Book, only to let out a sigh of disappointment.

If the app wants to be considered as a serious contender to other publishing tools, it needs to cater to more than pamphlet designers.

Come on Affinity - I believe in you. Lift your game. We are hungry for a viable replacement tool.

[walt.farrell]

Not sure what you mean. People are using Publisher to make books. 

[MikeW]

8 minutes ago, walt.farrell said:

Not sure what you mean. People are using Publisher to make books. 

A book file that one adds individual APub documents to (think chapters, sections, etc.) to that make up a book.

This keeps total file size down and can allow for concurrent user workflows. Can you imagine a 600 to 800 page book with images and/or illustrations in APub even if linked files worked?

[Jochen Bretschneider]

Completly agree, Blair. 

Hope there will be something which allows you easily to create books, drag & drop  images & video into it, build interactive items and integrate AR and animations - and exports to formats which unlock the real potential of mobile devices of the readers ... still waiting, with you.

[v_kyr]

• iBooks Author

[larsh]

No problem to make big PDF, my last one with nearly 500 pictures was very quick to do and printed well by a bookmaker (blurb). Moving the pics into the frames of one ore more masterpages... There is only very little text, accepted by the printer, but what I see it should make no problems. lars

[Jochen Bretschneider]

Nobody knows what will happen to iBooks Author in the (near) future and the export for macOS and iOS devices only makes it problematic for the client segment.

I know, export to pdf is possible, but come on .... how sexy  is pdf in terms of interactivity, which is important, not for readers, but for learners.

 

 

[PaulEC]

12 hours ago, Jochen Bretschneider said:

Hope there will be something which allows you easily to create books, drag & drop  images & video into it, build interactive items and integrate AR and animations - and exports to formats which unlock the real potential of mobile devices of the readers ... still waiting, with you.

While I wouldn't disagree about being able to create e-books as well, I do feel that the primary function of APub should be the creation of traditional books and other printed matter / PDFs.

I would be sorry if the development of layout, typography features etc. etc. was relegated to second place in order to add all singing, all dancing interactive, movie, animation features etc. for mobile/electronic devices. I realise a lot of people seem to think that "real" books are dead (or dying) but if you just look around, you'll see that there is still a huge market for all types of printed matter.

[Jochen Bretschneider]

Please, don't get me wrong, the beauty of Affinity is to put a professional and individual workflows into hands of content experts as we are, not only traditional graphic designers or publishers. Like iBooks Author does.
I completely agree that Books are not dead (even keep "yet' for myself) and have their place, however, we have so much more now to share information, growing information, for complex learning and teaching processes. We need to involve new options and Affinity is maybe one of the little companies to make that possible.

Have a look if you'd like to see what I'm talking about our Dutch iBooks Library of Medicine (108 iBooks, 10 clinical specialties, 1200+ medical conditions)
https://vimeo.com/225697805
For download of iBooks - all are free
http://mlx.amsterdam/library

Last question to challenge you
I don't use streetmaps anymore, do you?

 

[Seneca]

On 4/22/2019 at 1:12 AM, Blair Purvis said:

If the app wants to be considered as a serious contender to other publishing tools, it needs to cater to more than pamphlet designers.

If you want to design a pamphlet then use affinity Designer.

While useful, the Book option in Publisher is not essential as you seem to be implying.

Some professional use Book facility in inDesign or QuarkXpress some don't and both produce very long docs.

What I'm saying is that we should not exaggerate the importance of that feature.

[Old Bruce]

50 minutes ago, Seneca said:

What I'm saying is that we should not exaggerate the importance of that feature.

I agree, I would love to have it implemented but its lack is not by any means a deal breaker. 

[dominik]

7 hours ago, PaulEC said:

I do feel that the primary function of APub should be the creation of traditional books and other printed matter / PDFs.

There is a fundamental difference between printed publishings and electronic publishings. The one is fixed size, the other has to work on many different devices and screen sizes (and resolutions). It is very hard to serve both with one set of features.

This is why I can understand that Serif decided to focus on print for the first release of APub. The introduction of hyperlinks let's me assume that they have more up the sleeve 

d.

[garrettm30]

22 hours ago, dominik said:

This is why I can understand that Serif decided to focus on print for the first release of APub.

I agree. I think export to some sort of eBook format may be a good eventual addition. However, as Serif keeps releasing more free 1.x updates, I wonder what they can have for the eventual paid 2.0 update. As eBooks and interactive content is an entirely new direction, it seems like something that would be a candidate for a later full version update.

Edit: I see I am continuing to topic drift. Back on the original subject, I would be glad to see some sort of book feature, but it is not essential in my own work. I have used InDesign's implementation of it for only one project, but I am glad to have it for that particular project.

Edited April 29, 2019 by garrettm30

[fde101]

On 4/21/2019 at 8:32 PM, MikeW said:

Can you imagine a 600 to 800 page book with images and/or illustrations in APub even if linked files worked?

I don't think 600-800 pages in a single file is at all unreasonable if the software is architected to handle it efficiently, which Serif seems to think the Affinity suite is.  Jury is out on that one.

Consider that a file system might need to juggle hundreds of thousands of files efficiently, for maybe hundreds or thousands simultaneous clients (if it is on a server), and we would be up in arms if a file system on a modern computer (which might have terabytes of storage) started bogging down after a measly few thousand files.

The specific data that Publisher is storing might be different, but in the end you are only looking at a limited number of pages at any one time.  Other than needing to deal with text flow where frames are linked between pages, and updates to master pages that might be shared by many other pages, the overall impact of having a large number of pages in the document could be fairly limited if the underlying data structures are set up in a reasonable way to account for the complexity of the task at hand.

Whether the images, page data, etc. is separated into multiple files by the file system, leaving the software with the added complexity of needing to track all of the different pieces of data across multiple files that it does not have direct control over, or handled by one big file that the software can manage and optimize itself, having greater confidence in where each piece of data can be found, in the end the efficiency of either approach comes down to how well the underlying implementation is designed.

 

This goes for linked files too: there is no reason that the image data could not be embedded into the file once and used in multiple places within the document, in which case the storage overhead is not overly different (for that one document) than storing the images in separate files outside of the document file and linking to them.  The benefits of having "proper" linked files are not related to efficiency, but rather to the convenience of being able to more directly update them outside the software.  Storage savings would result from being able to re-use the same image in multiple documents with only one being stored, or in not having to send additional copies of images to another person when sending your original files if that person already has copies of the relevant images which could be relinked to the source document.

 

The advantage of the prescribed "book" feature is again not directly or necessarily related to the efficiency of the software, but rather to workflow convenience when aggregating chapters from multiple sources.

[MikeW]

1 hour ago, fde101 said:

I don't think 600-800 pages in a single file is at all unreasonable if the software is architected to handle it efficiently, which Serif seems to think the Affinity suite is.  Jury is out on that one.

...

The advantage of the prescribed "book" feature is again not directly or necessarily related to the efficiency of the software, but rather to workflow convenience when aggregating chapters from multiple sources.

It's not unreasonable to expect it. But I already know it is not feasible in APub. Not a heavily illustrated book. The file size gets ginormous and performance is atrocious even on this new (week old pretty decent computer). I've done two "light" books in APub and likely won't even try again until such time as there are truly performant linked images.

The last heavily illustrated book I did produces a 220+ page PDF. It uses 5.59 gigs of image assets, lots of transparency (every page, actually). The working file is 40 megs. I wouldn't even try to rebuild it in APub unless Serif paid me for my time and aggravation. Although it would demonstrate how non-performant the present concept is.

The book feature would alleviate the issue of the book mentioned above for precisely the lack of efficiency the present APub concept is.

[garrettm30]

18 minutes ago, MikeW said:

It uses 5.59 gigs of image assets, lots of transparency (every page, actually). The working file is 40 megs.

I'm sorry to go on a tangent, but that comment seems to be relevant to another discussion about there not being "true" image linking. The discussion there was that every linked image is actually fully imported into the file, and even worse, that multiple copies of the same image are duplicated in the file, with ballooning file size to be the result. However 5.59 gigs of assets with only 40 megs in the working file makes me question our assumptions in the other thread. I assume the 5.59 GB of assets include source files that were exported to flattened and smaller versions which were linked into the working file, but still, 40 megs does sound low.

[MikeW]

The comment is relevant to this thread as well.

The files are largely TIFF files with layers and therefore transparency and are composites of CAD drawing "pieces." There are some PSDs, JPGs and AI files as well. Several/many of the TIFFs span the spread of the 12" x 12" book. Some repeat on other pages. The final file is 39 megs.

This is a real scenario, one which APub cannot match. Even though the two books I did in APub as a trial, they were not my working files. Those were built in another application. Each had few illustrations (mainly chapter start and in one, add chapter start facing page illustrations). Neither publication was zippy on the laptop I used (I think that is still in my sig) and the file sizes were very large. The other application did not have the performance issue on that same laptop, though, and neither had more than a 5 meg working file.

None of the above books in their working file format would I bother with a book file. In the one I am using for this illustration of APub's failings, I would have been able to better manage it using a book file. And that's the point I am trying to make. While it isn't/wasn't necessary to use a book feature for the three books here when using the application I did use, I would have needed to use it on the ID file from 2012/2013 illustrated above.

I don't believe a book feature is an overly needed thing if the application can deal with gobs of data. I rarely use it in other applications. But I fear APub, even with truly linked files, will need it after using it for a while now. I hope I am wrong.

[garrettm30]

Thank you for your clarification. I see I had misunderstood you, thinking that your working file of 40 megs that linked to 5.59 GB of assets was a test in Affinity Publisher.

[fde101]

2 hours ago, MikeW said:

It's not unreasonable to expect it. But I already know it is not feasible in APub. Not a heavily illustrated book. The file size gets ginormous and performance is atrocious even on this new (week old pretty decent computer). I've done two "light" books in APub and likely won't even try again until such time as there are truly performant linked images.

Given that Publisher does not have "true" linked images yet, we don't know if the performance issue is related to the images being embedded or not.  The performance issue could be a general problem with the way images are being handled that would also impact images that were linked.

I haven't done anything quite that large in Publisher yet so I can't comment directly on its actual performance with large files at this point.

My explanation was that poor performance when dealing with large documents may or may not be related to images being embedded.

 

Consider that disk images can be single large files containing an entire file system.  If a hypothetical file format were in effect a disk image containing a file with the layout data and other files containing the images, the overall performance would not be significantly different if all of the images were "embedded" in that disk image (document) file than if the images were stored externally on a different file system outside of the document.

 

Maybe the poor performance that is being observed in some of these cases is related to the specific manner in which the files are currently embedded, maybe it is not.  What I am saying is that without actual linked images support being implemented, we have no way of determining right now whether or not adding that feature to Publisher would meaningfully improve performance.  We don't know how the data is actually stored in the Publisher document files.

[MikeW]

If Serif keeps a high resolution preview file embedded so Affinity applications can make use of its bazillion percent zoom and show unrealistic previews, then I doubt image linking will accomplish much.

Quark faced the same issue when it changed its rendering engine several versions ago. It's gotten far better through the versions since. But it is still a softer display than I would like. But at least it uses true linked images. And that keeps the file size down and precludes the need for a book feature for all but demanding publications or concurrent collaborations with others. 

[dominik]

49 minutes ago, fde101 said:

I haven't done anything quite that large in Publisher yet so I can't comment directly on its actual performance with large files at this point.

If I may jump in with a test I did this week with a 425 page book project I recently finished (that I cannot share here).

For a test I set up a very basic APub document with only one page in the size of the original file. I also created a master page to work with that later.

Then I copied the whole text from LibreOffice and pasted it to a text frame on page one. This took several seconds.
Then, with a SHIFT + click on the overflow icon, I envoked the automatic creation of all the pages needed.

APub took several minutes (5?) to finish, but did not crash.
After that working within the file was 'acceptable'.

My conclusion: long documents are possible but there are problems with performance and file size.
This may improve over time but we are not there, yet.

d.

[Fixx]

Modern software should handle hundreds of pages, images or no images. I hope correcting linked images bug proves Publisher to be modern software.

[Nathan Shirley]

I was curious how Publisher would handle importing and working with a PDF with hundreds of pages. I imported a PDF of 319 pages of sheet music (made up of text and music fonts). Publisher imported it in I'd guess less than 20 seconds, no issues. Once loaded I could quickly navigate to any page and edit any elements without lag. The PDF was just over 5 MB. Publisher was using about 4 GB of RAM.

I'm guessing if I tried this with InDesign performance would be worse. And of course Adobe hobbled InDesign so it can't edit PDFs.

Seems promising...

[fde101]

8 hours ago, Nathan Shirley said:

The PDF was just over 5 MB. Publisher was using about 4 GB of RAM.

Publisher is designed to use the resources that are available on the system.  The amount of RAM that is being consumed isn't nearly as interesting as how big the resulting, saved Publisher document file is, or a PDF exported from said file (as opposed to the one originally brought in).  RAM consumption is a temporary working state.

 

I think the general takeaway from this thread so far is that Publisher has performance bottlenecks related to large numbers of images (not pages) in a document.  Whether the performance bottlenecks are in its implementation of image embedding (vs. "proper" linking) or in the generic handling of the images themselves remains an open question.

[Andrew Crompton]

To return to the original post in this topic … 

Quote

With every beta release of Publisher, I immediately check for File - New - Book, only to let out a sigh of disappointment. 
If the app wants to be considered as a serious contender to other publishing tools, it needs to cater to more than pamphlet designers. 

I too am interested in producing (printed) books using Publisher. I notice in the Publisher help on Adding sections it says: "Chapter Two of a long publication might be in a separate file". So presumably it is possible to set up a long publication consisting of several sections, each in its own file.

However, I have not been able to discover how to do this. Anyone know?