Jump to content

thetasig

Members
  • Content count

    71
  • Joined

  • Last visited

About thetasig

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.)
  2. 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?
  3. 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.
  4. 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
  5. 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?
  6. 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).
  7. Thanks, Walt, for you workflow advice. I had to translate from Windows to Mac for the shortcut = Shift+Option+Command+[
  8. 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.
  9. Suggestion: When you have the Studio/Index panel open, and when you use it to add an indexed word(s), it would save a lot of clicking/dragging the Studio/Index panel list up and down IF the software would immediately "jump" to the newly added item in the Studio/Index panel. The next step, usually, is to find the word(s) and check-mark each one you wish to include in the index. I find that I'm constantly scrolling back and forth to find the newly added word(s).
  10. I think this is a bug, at least unexpected. I have these words (and others) in a document: 23rd Regiment 19th Mercantile The index lists 23rd Regiment under the alphabetical letter "R" taken from the "rd" ordinal ending. I would expect it to be listed alphabetically under the characters "23". The index lists 19th Mercantile under the alphabetical letter "T" taken from the "th" ordinal ending. I would expect it to be listed alphabetically under the characters "19". The indexed words are, however, sorted before the alphabetical letter "A" - so it's sorting by the two numbers "19" and "23" but listing them under the ordinal's first letter instead of the numbers. copied from index: T 19th Mercantile 225 R 23rd Regiment 225 A Air 225 B Bird 225
  11. Thanks, Walt. However, I think my problem is a little bit deeper. I already had the "Include Section Headings" checked. I note that when it IS checked, there is a small unprintable character (tiny box) in grey at the upper left-hand corner of the index. I suspect that I have messed up the Text Styles through my ignorance of which one to change for font, color, etc. I see the one marked "Index Section Heading - and that one sounds like the one that displays the alphabetical character for the index. It is normally based on the "Index" style. However, no matter what I change in any of these index text styles, that unprintable character is either visible or not, but no actual, visible text (and there is only one unprintable character, not a string of them going down the alphabet. So, the index was the last page - I've deleted the text frame and the page. Then recreated that page and opened a text frame with cursor inside. It won't let me insert the index - see screen shot. So now my task is "finding" the invisible index (and, really, I never actually inserted another index in the document purposely). Any ideas how to find and delete this phantom index? Could it be a bug? Thanks very much.
  12. When I first created a two-word index, there was a single letter of the alphabet in the left-hand column followed on the next line by the indented word: A Apple 10, 20, 42 ... P Plastic 31, 38, 52, 64 Now that I've added some 40 words, the alphabetical letters are gone and all the words are on the left with no indent: Apple 10, 20, 42 How do I get the alphabetical letters to show up with the indented words? Also, I tried to insert a "tab" of periods (like I did in the TOC) but they don't show up when I select that paragraph feature, the "." Honestly, not sure I want that feature, but would just like to know how it should work. A Apple..............................10, 20, 42 Aqua...........................8, 11, 24, 51 Lastly, some words cause the page numbers to wrap around to the next line or two lines. Is there a way to indent the second and subsequent lines of page numbers so that they are not sitting on the left margin? Apple 10, 11, 12, 13, 14, 15, 16, 17, 17, 18, 19, 20, 21, 22, 23, 24 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42 43, 44, 45 ----------> Apple 10, 11, 12, 13, 14, 15, 16, 17, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45 Many thanks.
  13. Yes, I'm in the same situation with regards to the text in AP. In an ideal situation, the application itself would "dump" all the text into the concordance file and then let you edit that for the personal touch. Then the application would read that file back into the document to create the index. even MS Word does not offer that "dump" feature. It gets tricky though - phrases and parent/child (topic/sub-topic) relationships would need to be handled manually during the editing regardless.
  14. Sorry to be so scattered, but just wanted to point out that the background image that migrated from 'back' to "front" is a single picture frame with a single photo that spans the entire 2-page spread(s). Maybe adding only a single page caused an internal mis-alignment (how could AFPUB handle a frame that spans two different spreads?)
  15. Somewhat expected, but still not great, this move also caused the applied Master page section names and page numbers to "flip" so that instead of names and pages being at the outside edges of the spread, they moved inside to the middle of the spread - happened on, apparently, just the single section I was working with but not all subsequent pages. I had to re-apply the master to those affected pages.
×