thetasig

TYVM!

TYVM!

OMG - I'm so glad to learn about that help site. Thanks!

I have a large document and a number of swatches that I use. I have the "palette" set to the document I'm working on. The palette is large with some 40+ swatches (some of which I don't recognize as having used them). I would like to know how to force AFPUB to save the swatches I have used over time on the document. I keep running into a missing swatch (where one object stroke or fill has that color, and I'd like to copy that color, but that swatch is not shown in the list of swatches). This forces me to use the HSL codes to manually re-create the swatch. However, eventually, that or another swatch won't be in the list when I need it. I suspect user knowledge is the problem, not necessarily a bug.

I wanted to add a different issue here, but related in a way. All of my photos are added to a just-created picture frame that is highlighted. So, for the most part, that photo stays "attached" to the frame and the frame governs what you see and how you can move the photo. Sometimes, though, I click the picture and try to move it (using the "compass" icon) only to realize that the photo has become somehow separated from the picture frame and is free to move over the document without the constraints of the frame. The bar above (where you would normally see frame qualities) now appears with a different set of buttons that are probably just for isolated photos that are not in frames. There are two issues here. The first is that I have no idea how that happens (is it part of the programming? how does one initiate that separation?). Then comes the trick - how to get it back "into" the frame again? I think all I had to do was to "fit" the photo into the frame again while the frame was highlighted. It happens rarely - perhaps just the way I click or move the mouse. I have only seen it happen about 4 times in several months. So I'm not sure if it is user error/ignorance or some errant piece of code. Thanks!

I have not seen the Resource Manager reporting missing images since the original post. I have a movie screen capture that shows the problem (attached). In this particular case, which I think is representative, the same zoom "appears" to be in force. That is, the photo is still zoomed "in" closer and you can see the full photo when you click and hold the "compass" icon that permits you to move the photo within the Picture Frame. But the photo is stretched vertically. Of course, the properties of the photo are set to "none" since it was manually zoomed. Zooming in and out or moving the photo does not "fix" the aspect ratio. To repair it, you have to first scale to fit and then zoom in again. It seems that the change in aspect ratio might be the only difference (squeezed in from side to side). If the s/w did not do that, the replacement might have been exactly the same appearance. I have seen this many times when I "move" photos around to different picture frames using the "replace image" button. It's repeatable - I can "fix" the replaced photo (scale to fit, then zoom in again - that zooming changes the photo properties to "none") and then replace it and the same change in aspect ratio "squeeze" happens again. However, if you change the photo outside AFPUB (it's linked to a file folder) the photo appears unchanged after the system automatically replaces the photo, except for any retouching you might have done. So replacing manually through the UI seems to be differently handled than the automatic way. Replace Photo 1.mov

Thanks, Gabe :-)

Aha - thank you Walt. I had forgotten about the "indented" index levels that are available. Plays well with "See also..." too.

I'm not following your comment. Would you please give an example or two of how that would happen/be used? Thank you.

Another type of bug on this issue. Again, we are in the View/Studio/Index Topic list. Highlight and expand a topic and double-click one of the page # items listed under that topic. AFPUB jumps to that page and text in the document. Now highlight/select another Topic somewhere else in the Topic list and perform a right-click "Find In Document." Now make any kind of edit to a word under that Index Topic (uncheck or check). When you click "Done" you will be thrown back to the very first page# item that you originally double-clicked. This only happens if you make an edit to the list of words marked under the Topic. If you make no changes, AFPUB will jump back to the same Topic where you made no changes.

I've noted that it is possible to mark the same exact word (in a single text frame) multiple times (purposely or accidentally). The page number and nearby text becomes listed "X" times in the View/Studio/Index Topic list and has "X" number of "down-arrows" in front to designate the number of index marks that are set on that word (a single word in one text frame). Even the positioning of each "flag" is marked by a black down-arrow. While I don't see any particular harm in that, I wonder how that could ever be useful since it represents true duplicate index marks. I'd be interested in knowing how that feature might be used.

A little weirdness. I indexed the word "Generator" and then went to the View/Studio/Index Topic item and performed a "Find In Document" - this is what it brought back - another word that is similar to the word "Generator" but NOT the same word at all. It brought back the word "General" and offered to index those entries under the topic "Generator" As Data said once about how to pronounce his name - "one is my name, the other is not"

I'm having to go through a large document. The indexing has been hit-or-miss since a lot of editing has been done on the document. Now I'm having to go through the View/Studio/Index list and perform a "Find in Document" for each Topic (and there are many hundreds). What would be truly wonderful is to be able to invoke a full search for ALL words in the index that are missing an index mark. It would display the same as it does now for single Topics but would show ALL of the topics that have missing index marks in the document. All you would have to do is scroll down through the automatically generated list and check any words that you want to include - or - click the 'All' box for the topic or topics. That would save so much time instead of having to perform a "Find In Document" one topic at a time.

This falls under the category of annoying and carpal tunnel issues. In the view/Studio/Index window, one may right-click a Topic and perform a "Find in Document" for all occurrences of the topic. After you make a change (add a check mark or remove one, etc.), and click "Done", the index Topic list reverts all the way back to the top of the list. If you do not make a change and then click "Done" the list stays where you were. However, if you first highlight / select the topic (rather than just right-clicking it), then the list will bring you back to the topic you highlighted. What would be more useful is to bring the user back to the same Topic that was just edited/changed or viewed and not changed (and not require that the Topic be highlighted beforehand - that's an extra 'click'). You can see that this gets worse the farther you go down the list since you have much farther to scroll to get back to where you were.

OK - seems there is still an omission in my opinion. But it is not what this issue started out to be. My error. So, the above information is bogus - my fault for not checking for "user error." See the attach AFPUB file. The index update now places the numbered Index Entries first in the index, and sorted by the numeric value. However, my mistake is that I had a hard-coded "1" as the first character in my document's Index. This became the Index Section Heading for numeric entries. Of course, it is not linked to the styles for indexes and is not part of the index update. The update just flows the indexing after that hard-coded "1" So, the missing element IMHO is that the index update does not include an "Index Section Heading" value for numeric entries - it is null. This could be viewed as suitable (no heading for numbered items is necessary) or could be viewed as an omission (numbers should have some sort of heading shown). I used a "1" in my index (hard-coded). I have also seen a "#" (meaning "number") as a heading for numbered entries in a technical manual. I checked a few "manuals of style" and most recommend a totally different way of sorting numbered entries in an index, i.e., sorting by the spelling of the sounded-out number (like placing "200th anniversary" under the "T" heading as though it were "Two hundredth anniversary" or under "F" for "1st" ("first"). To be really elegant, you might consider several standard options from which the user might choose. Although I cannot afford to purchase it and cannot see it, ISO 999 defines standards for indexing. However, you can leave AFPUB unchanged for my needs. The hard-coded heading works well. So I leave it to you to decide. Sorry about the confusion. Index Test Font Size.afpub