Search the Community

AFPUB 1.8.3, Mac 10.15.3. I have a number of ordinals in my document that are indexed. An example is "18th Birthday", where the "th" is a superscript. In this case, the quoted words are also indexed. I don't know if this is by design, but the index text drops the superscript down to the default baseline (as seen here in this topic). I would have expected the index to respect the superscript and have that properly shown. I'd appreciate some clarification. Thanks.

I'm working on a recipe book and would like to be able to have multiple parent topics for some topics. For example, Paella could be under chicken, prawn, chorizo, saffron, rice etc. Is this possible? Thank you in advance.

AFPUB 1.8.4.648, OSX 10.15.3 Catalina Please review this old report - @Pauls had indicated the issue had been logged, but the problem remains in the latest beta version: Text and Index Frames split numbers - have danglers By thetasig, July 9, 2019 in Pre 1.8 Publisher Bugs found on MacOS Thank you.

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.

Hi, there might be a bug with generating an index and handling with master pages -- Files are attached. On Page 3 is the Index; On Page 4 should be nothing - no Master Page applied; On Page 5 a the Right Master Page with prepared text formats for editors is applied The Master Pages have formated text on both pages -- and the unused Left Master Page shows up in the Index. This might be a problem with the master pages -- the whole content of it shows up in the layers panel. Stay healthy everybody. Publisher Index Bug - Master Titles.afpub

The ability to tag text elements and generate an index (automatically like the Table of Contents) is one thing I would use in larger projects. Likewise, the ability to build cross references that automatically update the page number (to avoid 'see page XX' errors) is something else that I use regularly, but indexing is a higher priority. This looks really good and I'm looking forward to trying it out properly.

I have a potential bug to share. I have been going through the Studio Index panel to check and see if each Topic's words are all check-marked, as needed. In several topics, the panel shows many words that are indexed under the topic. However, if you perform a right-click "Find" on the topic, the list there is empty. Normally, the same words shown under the topic will show up under the "Find" as well. It seems to be more often than not, a two-word indexing situation. Note: in the examples, the two words "cargo plane" are indexed separately from "cargo" and "plane." Attached two screen shots of the before and after the "Find". Any ideas?

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?

Thanks for changing the indexing to include topic names that begin with numbers. Numbered items, then, are all under the Index Section Heading: "1". Changing the text style for all of the Index Section Heading items changes them all - except the "1" So all section headings A-Z can be changed to have a different font size. But the "1" (that is also marked as "Index Section Heading") stays the same size. Example: "A-Z" are 5 points, "1" is 12 points. See screenshots.

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'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.

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.

Congratulations on the launch of Publisher. It looks great, and I am excited to get to learn it. I presently use InDesign, and one feature I found very helpful was a plugin script called index-direct.jsx. By using this script, you could have a full list of the index topics in a separate document, and the script would go through the list and form an index for your main document. A thousand entries were completed in a matter of seconds. I am hoping that Affinity or a script writer will be able to provide a similar piece of software. Cheers.

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 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

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.

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).

I just created an index but the page numbers are out of order (see screenshot below). I've read the Help doc and searched the forum for 'index AND page AND number" but don't see anything addressing this problem. I've certainly done something wrong but can't imagine what or how to tell Publisher to sort the page numbers. Any suggestions would be most appreciated. Thanks Doug Running Affinity Beta Publisher 1.7.0.238 on macOS Mojave

Hey affinity team, a while ago there had been existing an index of common feature requests which gave the users some ideas about which features might be expected in future releases. https://forum.affinity.serif.com/index.php?/topic/10410-common-feature-requests-index/ Could you please make such a sticky post again? Thank you very much. Benny

First of all, AP is a great app. It may well be the equal too, and in some ways, superior to Photoshop. The problem isn't the tool but in the interface. Or more precisely, learning the interface. Choosing to appeal to PS users, disaffected or otherwise, I believe the Serif team made two incorrect assumptions about those users in development, including: 1. That changing terminology from the gold standard Photoshop wouldn't be a problem. The words we call things matter. Example, if common usage (the base term) is that A is a process that uses tool B, changing the base term to C means that user has to learn that C now redefines the process, renames it and so moves it into a different indexed space, just to find, and use, tool B. That is further complicated if the assignment of A to C using tool B is changed to assign it to tool D without a reference , e.g., "if you used B in Photoshop to do A, to do the same thing in Affinity you should use D to do C." Without that guide, a digital Rosetta Stone, the learning curve becomes much more difficult. 2. That everybody who used Photoshop used the tools in the same way. This may be the greater mistaken: PS users do not use PS the same way. The many-ways approach isn't just a marketing term for PS, it was integral to how many long-term users learned and applied the program. Like many other PS users, I've been at it through several generations of the app, and learned which of the myriad PS ways to completing a task worked best for me. Not the best ways, perhaps, but my ways. In fact, these two assumptions are why I'm struggling with AP and may have to switch back to PS.

I dont't know if this feature has already been requested, but posting this wish here anyway :\ I'd like to see browse / index persona (or ui add on), that I can throw away Microsoft Photo and Corel AfterShot Pro as photo browser and indexer. So what I'm looking after; feature that I can maintain picture library/index of photos in Affinity Photo/Designer (and perhaps kind of version control of edits).