rufus

Publisher does not have the facilities to construct a book in separate chapters, in the style of PagePlus. I just completed a book that contains over 500 pages and over 1000 images. Being a little nervous about running into capacity limits, I originally constructed it as 25 separate files, one per chapter. The original intent was to assemble the whole thing into a single file using Add Pages From File at the last minute, and generate the TOC and index. If that failed, I intended to generate TOC and index by hand, export each chapter to individual PDFs, and then combine the PDFs with Acrobat. It turned out that combining the chapter files using Add Pages From File worked fine, except for a bug that rendered some cells of some tables empty after their files were added. The resulting single file was quite manageable, to the extent that if I were to start another similarly-sized book project I would not bother using separate files. General performance of the software was very responsive, not at all sluggish. The only real issue with dealing with a file that big is that the scroll bars are too tiny to offer fine control. Just for the record as far as software performance goes, my book contained all linked images, and my machine is a PC with i5 quad processor and 16G of RAM. Overall I was very pleased with the software. It performed very well for this project. If the software had facilities to efficiently deal with a multi-file project I would definitely use them, but I did not find dealing with a single file to be much of an issue at all.

Additional information: To be clear, the problem does not always show itself, but seems to mostly happen with top level topics and less often with sub topics. I was in the middle of indexing when I made the original posting here, and hoped to have additional information, but unfortunately I have finished indexing this book and don't have anything else to report on this bug. The workaround is a pain in the butt, but it is basically to add two topics of the forms "topic" and "topics", find all instances of each in the document, drag the latter into the former and then delete the latter topic.

The following sequence is followed: - select and copy text in document, where the bound of the selected text does not fall on a word boundary ( like "high priority bug" selected out of "high priority bugs". - add topic (+), or select existing topic in topic list. - paste into topic name, OK. - select topic, find in document. It is generally the case that, if the topic is top level, that find in document will not locate the text. But sometimes it does, and I have no idea under what conditions. However, if the topic is a sub topic at any level, the text seems to be reliably located. Note that the text example given is a common indexing case - you generally want to index the singular form of a word or phrase, and expect that the plural form (with trailing 's') will be found as well.

Publisher crashes regularly during indexing of a large (500p) book. It appears that most of these occur as a result of the following sequence: - select text in the document - click on add topic (+) - past text into topic name field and click on OK - right click on topic in topic list and select find in document It seems to crash with more regularity when the selected text string is longer than a couple of words. I can upload crash dumps.

Correct. Oh, I did say "re-type" in my original post, sorry. Scrap that part. The current facility requires two clicks each to retrieve the last used search and replace strings. Just leaving those strings in place in their respective fields would require no clicks to retrieve them.

I have 10 files loaded and need to do the same search and replace in all of them. As I go from loaded file to loaded file I have to re-type both the search and replace strings. Please retain search and replace strings. Also it would be very nice to be able to search and replace in all loaded files, without having to do each one individually.

This is a minor annoyance, but when I export I am doing more than 20 files at a time. file->export->pdf->Area: always defaults to All spreads. Since I always want All pages, this has to be set for each invocation.

Figure captions in my book make use of the field <Section Name> to identify the chapter number: "Figure 2-57" is really "Figure <Section Name>-57" There is no to search for this string. Using either: Figure 2 Figure <Section Name> yields no search results.

Oops. Important detail, maybe. These are two page spreads, not single pages. So here are four pages total. otherwise all is as I originally posted.

You have a three page document. Each page contains a single page size text frame. All text frames are linked in page order. Add a picture frame to page 2 and text will flow around it as expected. Add two picture frames to page 2 big enough to take up the whole page, and text will not flow around them.

I work at higher magnification. A number of operations of the software reset magnification to base level as a side effect. Please fix this. The operations include: - adding or removing pages from the document; - navigating to a page in the document via double clicking on a page in the left hand pages display.

I tend to work with the software running for weeks at a time, loading and unloading files as I work on them. After some amount of time, performance gets sluggish to the point where the software really can't be used. I close the program and invoke it again, and all is fine for a while but this will happen again in some number of days. it does not appear to be related to any particular file(s).

I have independently verified everything h_d has written here. This is exactly what causes the problem and also the fix.

OK, some more on this ... 1. If the image frame is selected (single click) the toolbar button Replace Image invokes a modal file selection dialog, which contains a radio button group {Embed Picture, Link Picture}. The selection always defaults to Embed Picture, even though File/Document Setup/Image Placement Policy is set to Prefer Linked. 2. If instead the image itself is selected (double click) the toolbar button Replace Image invokes the selection dialog with the radio button default selection set to whatever is the placement of the current image, ignoring File/Document Setup/Image Placement Policy. So, because Placement honors File/Document Setup/Image Placement Policy, I believe I am seeing in 1 an outright bug; and in 2 the manifestation of different placement and REplacement semantics. The bug of course should be fixed. If different placement and replacement semantics is intentional, that fact should probably be documented because it appears to be a source of confusion.

Correct as far as I can tell. If I delete the image first and then place the new image it works fine. The file selection dialog associated with the place doesn't even have the {link, embed} menu. And when replacing the image, for me it does not *may* default incorrectly, it always defaults incorrectly. To your question. 1. Limitations of the asset library. The project is technical documentation. There are three standard photo sizes, three standard figure widths, each with their associated caption frames and credit frames. There are two standard placements for each of these, each with their text wrap settings. Prototypes for all of this are in the assets library. Finding what asset I'm looking for in a hierarchical text list it too tedious and time consuming. Asset location is quicker when an icon display is used, but the automatic icon generation facility is, simplistic. An icon of an empty image frame is invisible. So my image frames have color coded dummy images in them, which makes acquisition fast. But now I have an image which must be replaced for each asset dragged in. 2. Frame arrays. The smaller size photos are regularly grouped into frame arrays. All the permutations specified above in terms of caption and credit frames, placements, and text wrap settings apply, but in addition the arrays are of varying numbers of rows and columns. It is far quicker to copy an entire array from somewhere in the book and reuse it than it is to construct a new one from its component elements. Of course all possible permutations of the prototype arrays could be placed in the asset library, but persistent bugs that cause the product to crash and burn when (maybe) big things are dragged out of the asset library have shaped my usage as specified here. So the upshot is, I always end up replacing an existing image. Even with the Replace Image link/embed defaulting bug, it is quicker to work this way.