INDEXING CRASHES

[Marty N.]

I'm getting constant crashes in Publisher on Windows when marking text as an index item.  I select the text, hit Alt-I, then Alt-O, and sometimes that works.  Many other times the program crashes.  Seems to happen particularly but not always when the index item is the last one on that page. 

May have something to do with the size of the AFPUB file; it's 6.67GB.  But there's plenty of room on the disk and saving is fast.  Saving constantly after each page to avoid crash damage really slows down the work.

On the index topic, it would be helpful if text bits that are already marked for indexing were shown in highlight.  The current system showing a flag in front is (a) hard to see and more importantly, (b) does not show whether just the first word after the flag or a longer passage are indexed.  A highlight would be stronger. 

[Marty N.]

The crashes happen most often when the index item is short, like a three-letter abbreviation:  Y2K,  FBI, NAB 

Use of Alt-O is particularly likely to bring a crash.  Mousing to the OK button on the dialog is safer but not always.  

This is with Publisher 1.8.5.703 in Win10. 

 

[Marty N.]

Further on these crashes:  The bug seems to be in the Alt-O operation that activates the OK button in the dialog box.  The crashes are not happening if I mouse over to the OK button and click on it.  Needless to say, this takes a bunch longer; it requires taking a hand off the keyboard, onto the mouse, mousing over, etc. etc.  For a long index that's a lot of extra effort.   Something in the Alt-O keystroke is causing intermittent program shutdowns.

On the index, further, it would be quite helpful and labor-saving if the flags that indicate whether a text string is marked as an index item were activated whenever that text string has been marked for index previously somewhere else in the body of the text.  Currently the flag only appears if the string has been marked for index at that location (on that page).  As a result, one ends up needlessly marking a string for index when it has been previously marked on another page.  If there are only a few index items one can remember what one has already marked, but in a large index that's not realistic.  Another way to approach this would be to make an index marker automatically mark all occurrences of the string in the body of the text.  I would actually prefer that.  Then if one wanted to delete some index markers one could do that manually later.  the current setup is very laborious. 

Generally, the index apparatus in Publisher has a lot of promise and a capable foundation but still needs a lot of work to be a top notch tool.  

[Marty N.]

Bug is solved -- well, not solved, but identified.

After marking a text string as an index item with Alt-I, if the dialog box that comes up has a blank in the "Parent Topic" field, then hitting Alt-O to close the dialog works without problems.  But if the "Parent Topic" field has an entry, then hitting Alt-O crashes Publisher.  You have to mouse over to the OK button and click on it.  

Why this should be I have no clue.  But it should be fixed, please.  

[Marty N.]

ANOTHER KIND OF INDEX CRASH

When going through the Index panel (View|Studio|Index) and right-clicking to "Find in Document" an item that contains another item that is indexed separately, the program crashes.  Example:

The index item is "Americans With Disabilies Act (ADA)" and there is a separate index item "ADA" then clicking on "Find in Document" crashes Publisher, every time.  

Of course, tidy index housekeeping would avoid separately indexing the long form and the abbreviated form of a name to begin with.  But that housekeeping should be doable after marking the index items how they occur.  Can't tidy it up if the program crashes.  I'm forced to exit the index panel and go into the text and brute-force find and replace the index string entries.  

 

[Marty N.]

A related but comparatively minor bug:

After deleting the troublesome index item "Affordable Healthcare Act (Obamacare)" [because it crashed Publisher due to the existence of the separate index item "Obamacare"), the index listing in the Index panel remains and is not deleted, even though it no longer exists in the text.  It does not appear in the actual index when regenerated, but persists in the Index panel.  Not a Big Deal but something to fix. 

Deleting it manually should not be necessary once it has lost any root in the document.

Similarly, once all index markers under an index topic have been deleted from the document, the index topic should vanish.  I should not have to manually delete it.

[Marty N.]

After editing an item in the Index Panel, the listing in the panel refreshes but the highlight on the edited item is gone, so it takes hunting to find out where I was working.  Relatively minor, but it adds to the time and effort required to build an index.  

 

[Marty N.]

And another index annoyance.  The program allows the same occurrence of a string in the text to be marked as an index item more than once, so that in the Index Panel you end up with two, three, or many references to the same index item on the same page (even though it occurs there only once).  

Tis becomes a nuisance when I am paring a list of hits for a single index marker.  I want to uncheck the box for a certain marker, but if this page is marked more than once, unchecking the box in one instance checks the box in the  other instance, and since the page numbers are not given in the "Find"" list, I'm playing whack a mole trying to prune my list. Duplicat entries for the same page should be purged from the database the instant they're entered.  Or, more awkward but still an improvement, list the page numbers in the "Find" list so that you can easily spot the duplicate index marks.

[Marty N.]

The Index Panel needs a Find field.  

[Marty N.]

And another Index crash.  Index items that end with a period, such as "Anthony, Susan B."  cause Publisher to crash when I click on "Find in Document."  

Or "Bechtel Corp."  or "IBM inc."  "Martin Luther King Jr.  -- they all crash.

None of the index bugs has caused me more frustration, lost time, and document corruption than this one. 

[Marty N.]

Yet another headache.  Once defined as a subtopic of a parent topic, you can't change your mind and promote the subtopic to a main topic.  If you try to delete the no longer wanted parent topic, your child topic ends up at the top of the index under a blank parent topic.  I hope I find a way to fix that -- the subtopic has a ton of entries.  -- Found a way.  Delete the child topic.  Delete all the other child topics under that master topic.  Then delete master topic.  Then rebuild.  It's awkward but it works.

[Marty N.]

And one more.  For reasons I can't yet trace, the index marker "Human Welfare and Community Action Commission" causes a Publisher crash when in the Index Panel I right-click and then click on "Find in document."  The string occurs in the document.  Each of the words in the marked string also occurs in other places in the document, some of them dozens of times, but none of the words taken individually is a marked index item (which would fit under one of the previously cited crash causes, see above).  I'm just going to leave this index item in the table and hope it doesn't crash the index.

[Marty N.]

And still another Index bug.  In the Index Panel, when I double click on an index topic, index items from the alphabetically previous index topic now appear under the double-clicked topic.  These index entries don't belong under this topic, and getting rid of them requires deleting the index topic and rebuilding it from the document level.  This is so weird that I'm attaching a screen shot.  "Missing Link Bicycle Cooperative" is the alphabetically preceding index topic.  "Mitchell, Horace" is the following topic.  After double-clicking "Mitchell, Horace" I get entries for "Missing Link ..." under "Mitchell, Horace."  Mitchell Horace has no relation whatever to Missing Link.  The fake entries repeat every time I double-click on Mitchell, Horace.   

[Marty N.]

And another index bug.

In the final index output, Publisher formats the page numbers badly.  Two problems:  

(1)  When there is a range of pages, such as nnn...nnn, Publisher inserts a line break, usually wrongly, after the dots.  No reason to put a line break there.

(2)  When there is more than one line of page numbers, Publisher breaks multi-digit page numbers at the end of a line and puts in a line break where none belongs.  So for example if the page number at the end of a line is nnn, Publisher will write nn|n  or n|nn, where the vertical line represents a line break.  Here is a screen shot.  This looks shabby and badly needs a fix.  Please.

[Marty N.]

Mystery bug:  For some unknown reason, the index entry "Nye, Parnell & Emerson Capital Management, Inc" -- even with the deadly terminal period deleted, causes Publisher to crash and sometimes to freeze, bringing up the Windows message that the program is not responding.  WTF??  Again, some of the words in the string also occur elsewhere in the document, some of them occur several times, but none of them is a separate index entry.  Maybe the string has too many commas?  Nope -- deleted the commas, still crashes.  Or the ampersand?  Nope, still crashes without the ampersand.  Totally baffling.  

[Marty N.]

Another mystery crash.   In the Index Panel, the index topic "Student Nonviolent Coordinating Committee" when right-clicked and asked to "Find in document" causes Publisher to crash, repeatedly, reliably.  I've deleted the string from the document, deleted the index topic, retyped it in the document, remarked it as an index item, and tried it again, with the same result.  Total weirdness.  

 

[Marty N.]

Another weird Index issue.  

The string "U.S. Fish and Wildlife Service" exists in the document at p. 283 and is marked as an index item.   The Index Panel correctly shows the topic "U.S. Fish and Wildlife Service" with one instance at p. 283.  See first screen clip below.  But when asked to "Find in document," Publisher shows a blank, no instances of that string found, see second screen clip below. WTF??  

[Marty N.]

And another strange one.

The document contains the text string "University Professional and Technical Employees Union" at p. 674.  It is marked for index.  The Index Panel correctly shows the topic, "University Professional and Technical Employees Union."  But listed beneath that is "674   University Professional and Technical Employees"  with the last word, "Union," missing.  And a right click on the topic, followed by "Find in document," crashes Publisher.  

I've tried deleting the string, the index entry, and the topic, and rebuilding from scratch, always with the same result.  Publisher won't write the word "Union" and crashes if asked to find the topic in the document.  WTF???

 

[Marty N.]

And another one.

The document contains the string "West Berkeley Neighborhood Development Corporation" at p. 243.  It is marked as an index entry.  The Index Panel shows "West Berkeley Neighborhood Development Corporation" as the index topic.  But the listing underneath says "243 West Berkeley Neighborhood Development" -- leaving out the last word, "Corporation."  And asking Publisher to find the index topic in the document crashes Publisher.  

What is going on???

[Marty N.]

It's the parentheses!  

Asking Publisher Index Panel to Find in document the index topic "Works Progress Administration (WPA)" crashes Publisher even though there is no separate "WPA" index item, see bug reports above.  Same result with brackets instead of parentheses.  But "Works Progress Administration -- WPA" works.  Index Panel Find in document can't handle parentheses in the topic string.  That's pathetic.

Sorry.

 

[Marty N.]

 

Also note that the page listing inserts a line break at every hyphen, so that a page listing such as 612-614 which could very well run on the same line gets broken like 612-|614 where the vertical bar represents a line break.  Sad. 

 

 

[Marty N.]

In the final Index output, I can get rid of the bad line breaks at the hyphens by unchecking "Group page ranges" in the Index Panel Options dialog.  But I can't seem to get rid of the bad line breaks in the middle of a three-digit number.  And I can't prevent a page number listing from breaking across pages.  The "Flow" options in the Paragraph panel for the Index Entry style doesn't have any effect that I can see on page number listings.  

This book is scheduled to go to press in ten days.  It would be lovely to have a solution to these formatting issues for the final index output before then.  The rest of the index bugs I've worked around as best as possible and can wait.  

[Marty N.]

One more.

The "Go to Page" dialog under the Document menu item goes to the absolute page, disregarding page numbering by sections.  So in my book the first two pages have no numbers on them, the next 8 pages have Roman numerals, and the book body pages have Arabic numerals beginning with 1.  So if I want to use "Go to Page" in the Document menu to go to the numbered page 10 of my book, I have to tell "Go to Page" to go to page 20.  That needs improvement.  For example, "Go to Page" could have a dropdown showing the different sections.  

[walt.farrell]

1 hour ago, Marty N. said:

One more.

The "Go to Page" dialog under the Document menu item goes to the absolute page, disregarding page numbering by sections.  So in my book the first two pages have no numbers on them, the next 8 pages have Roman numerals, and the book body pages have Arabic numerals beginning with 1.  So if I want to use "Go to Page" in the Document menu to go to the numbered page 10 of my book, I have to tell "Go to Page" to go to page 20.  That needs improvement.  For example, "Go to Page" could have a dropdown showing the different sections.  

That's not related to Indexing, and does not seem like a bug. It's a legitimate feature request, but I suggest posting it separately in the Feature Request forum, where the developers look for suggestions.

[Marty N.]

Right you are. Will repost.