thetasig

OK - here's a list of suggestions for the Resource Manager window: 1. Don't make the Resource Manager window disappear when another program on the Mac is highlighted (currently it disappears, but the Document stays put). Keep it present and visible on the Desktop. Currently, the list of items cannot be seen if you are trying to manually transfer (type) their names in, say, an external Text program. 2. Make it possible to do a "Find" on Resource Manager item names and or their source file paths. I have over 800 items in one list and it's hard to find partial text in their names if you are looking for a specific keyword. This has bit me on the bum many times. 3. Allow the Resource Manager list to be exported to a text file/spreadsheet/comma separated, whatever - including the item name and it's file path and other metadata about each item if available. If this is available, then #1 suggestion above becomes a moot suggestion for me. This would be particular valuable since I'm trying to make an external list that I can verify with the source of the items to a) see what's in my source file folder that isn't being used by Publisher, and b) to see what IS being used by Publisher, and c) to check if there may be a better source item for the document.

LOL - it was I who made the error...

This appears to have been a one-time glitch (previous version). in 1.7.0.305, I cannot reproduce the problem and haven't seen it since the first occurrence. I think it was probably user error.

There is one quirk. While you are in text editing mode, and delete a single wrong character in a word, the red underscore stays visible - UNTIL - you move your cursor away, and perhaps click elsewhere. Then the red line disappears. Probably just a delay in how the S/W decides to check the spelling again, after your edit. But I don't think it's worth a s/w change - optional and low priority.

I believe this is working well now. I haven't had such a crash in several days of editing with 1.7.0.305 and the previous version.

The issue is also found in standard text frames, not just in the indexing data. The other part of this is that in text/index frames, you can end up with split numbers across two lines (both types of frames), a leading, dangling comma or space starting a wrapped line (in indexes). See this issue for details/examples please: Text and Index Frames split numbers.

I can no longer reproduce this. There is a delay for the split red line to disappear - about 2-3 seconds. I think that is due to a large document, memory usage, etc. I guess it is fixed.

Walt - thanks for your help. I tried your suggestions. And it worked. Many thanks. Now if Serif will just fix the splitting of single page numbers across two lines, line-leading commas and spaces, then it will be nearly ideal. (Separate bugs have been submitted already.)

Looking at the "default" style/formatting for the index entries (inside a text frame) I would like to see the following: 1. Page numbers always starting on the same line as the indexed item. This has the advantage of saving space (extra lines) in the index. 2. Page numbers that wrap around to the second and subsequent lines, should be indented from the indexed item itself. Also helps the viewer to scan for index items easily. Example (ignore empty lines - they are an artifact of this forum's format): P Parts 11, 12, 16, 21, 22 Photo 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 100 Plano 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 200, 201, 202, 203, 204, 250, 251, 300 I could not find a way to do any of this with the existing UI. Are there some specific settings that would accomplish it?

I have noted that both text frames and index frames will wrap around entire words and will not split a word into two lines and will not put a dangling comma starting a next line (keeps the word and the comma together always) and will not allow a dangling space to start a next line. However, numbers are being split across two lines both in text frames and in index frames and a comma or a single space (such as found between index page numbers) may end up starting a next line both in text frames and index frames. I believe that these are bugs or broken features; that numbers (with commas and spaces) that wrap around to another line should be treated the same as alphabetic characters (and not split between lines ever) and commas and spaces should not be starting a line that has wrapped around. I have not found any way to control this from the UI. Here is one example that I have in an index (and confirmed that it has a similar problem when formatted separately in a text frame with the default "body" style). (Example shows the split page number "60" on the first line of page numbers, and the dangling space starting the next to last line and a dangling comma starting the last line of page numbers). Photo ii, 5, 18, 20, 21, 22, 29–31, 34, 40–42, 44, 45, 56, 6 0, 66, 67, 70, 71, 73, 78, 98, 99, 115–117, 119, 123, 126, 155, 173, 189, 190, 191, 193–195, 197, 200, 206 , 207, 212, 221 A quirk that is unusual to me: if the number of pages for an indexed item are few, then the item and the page numbers are all on the same line. If the number of pages is larger than will fit on the first line, then all of the page numbers start on the line after the indexed item (as shown above). I would think it more efficient and consistent-looking to always start the page numbers on the same line as the indexed item (as is possible if the indexed item itself is not too long) and then wrap around to the second and subsequent lines as needed. Is there a compelling reason for this inconsistency between a short page number list and a long page number list? Thanks for any information on how to control the formatting or confirm if these are bugs.

When you index words that begin with numbers, the indexing assigns the next non-numeric character to the Alphabetical character (A-Z, for example). For example, "17th ABC" comes out sorted by the "17" but lists that under the letter "T" (for "th"). I think, instead, since the index is actually sorting by the numeric value, the "alpha" character should be numeric also "1", "2", "3", etc. Happening in AFPUB 1.7.0.293, OS X 10.13.6 Screen shot and Publisher files attached. Index Sort and Display.afpub

I have last 2 pages with 6 text frames (3 each) - tall and narrow-ish. I see the full index in frame #1 on the left. It is so long that i cannot see the end. So, one by one, I link the index to each frame going left to right (only clicking the red arrows on the frames to the next frame in sequence). In the 5th frame - in the middle, the index starts all over again (starts with the first letter of alphabet). So, the index repeats itself just twice. Then it ends in the ninth frame and does not repeat again. I have tried deleting all of the text frames and updating the index, linking them again and again, and the result is consistent - always a doubling of the index list. Is this a bug - or is there some simple explanation of how to prevent the index from duplicating the A-Z words twice?

I did learn, after carefully searching, that the actual index (text frame) was nowhere to be found after I had deleted it earlier. The s/w seemed to think there was another index somewhere else. Alas, not to be found. I had to delete the index from the Studio/Index panel. Then I recreated it all over again. I still think that ("cannot insert more than one index..." message) was a bug since I had been careful to add the index text frame only to the very last (new) page (and I deleted that one).

Thanks, Walt, for you workflow advice. I had to translate from Windows to Mac for the shortcut = Shift+Option+Command+[

New suggestion and info: If you index a phrase, such as "picture perfect" and then add another index for "perfect", when you "find" the words, it will bypass all of the "picture perfect" phrases and will NOT index the second word ("perfect") of that phrase. I think the system should be able to find and index both words, however, a work-around is to index "perfect" before "picture perfect" then both the two-word phrase and the single word will be indexed. I keep running into this and having to fix the problem is much harder than using the workaround to begin with.