rufus

I've been able to work this one to death over the last few days, and it only happens for documents in the book implicitly modified by cross references, therefore not a bug. ----- APub 2.6.2. Load a book. Double click on a document in the books document list to open the document for editing. Take no other action. At some point later, dismiss the document using the X on its tab. Sometimes a modal dialog informing you that the document has been modified and asking you if you'd like to save it first appears. And sometimes not (expected behavior). Next time this happens I am going to have to check to see if the document contains a cross reference though. If it does, then of course not a bug. Note that in and of itself this may be a minor bug. But I post it here because there are a number of complaints against this release about failure to save documents (complaints about things missing and asking if you want to Save As instead; a much more serious bug) and this may be related.

I am currently in the process of indexing a 150 page technical book. The process, using the APub indexing facilities, is essentially manual. The bigger the book, the more important the index is, and the longer it takes to manually mark out the index. I've searched through the indexing-related feature requests. All that I've read would help a bit. But some automation is sorely needed. I'll point out that primitive but useable indexing automation was provided as early as some of the early releases of the Unix operating system in the early 1980s. My request is to provide a set of regular expression-based indexing primitives, much in the same way that APhoto provides photo editing primitive functions. These functions can be scripted to provide higher level functions, and many such photo editing scripts are made available by users on the support forums. I fully understand that at the APub price point a lot of features of any kind cannot be added. My suggestion is essentially to take the same long term approach that was taken for APhoto. Give users the scripting primitives needed to build our own higher level indexing facilities.

This just happened to me again. Previously, doing a Save as, getting out of APub, rnaming the Saved as file in the filesystem, then getting back into APub was an annoying workaround that actually worked. This time I had just spent an hour on a book document, tediously adding index marks. It not only failed on the Save as reported in this thread, it also failed on the Save as, complaining about lost access to other information needed by this file, and offering to Save as. That second Save as actually worked, but all my index marks were lost in it. So basically an hour of work shot. So in this case, this particular bug is way more than just annoying.

APub 2.6.2 Windows. I use AP for books 100 - 500 pages long. Export takes some time. Export Area parameter (document and book) must always be set to pages, which is not the default. I would love my selection for the area parameter to persist across invocations of the export function like the rest of the parameter values do.

APub 2.6.2 Windows. A single very long svg image in a picture frame at the bottom of the page. The frame crops out most of the svg but a substantial amount extends (invisibly of course) down below the picture frame and the page. Preflight and export works fine. The pdf can be viewed in Acrobat 8 just fine, but Acrobat chokes on the file if you try to do anything else. The workaround is obvious but it did take a while to find this in a 150 page book. And of course AA8 provided no useful diagnostic. Picture frame cropping is useful of course. A preflight warning would be useful for sure.

Perfect - thank you Mike! -r

I just now had the same thing happen, and it has happened before. Windows, nothing in the cloud.

Here is an example of what I am looking for. Somewhere in chapter 1 is the following text: More information on this topic can be found on page number 207 where "207" is a reference to the page number on which the information can be found, and which actually points to an anchor or some such. Any suggestions how this can be done for a nontrivial number of these? Thanks.

When multiple text frames are selected for bulk editing of their parameters, all but the first selected frame will be deselected following change of a single parameter. This makes it tedious to change the value of more than a single parameter because all of the text frames must be re-selected for each parameter change. 2.5.5 Windows 10

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.

I don't know about initially placing images Walt. In my workflow I am always replacing an image, usually via the toolbar Replace Image button.