MikeTO

Don't use PNGs for print. While PNG is a great format for web pages it's not deal for print. TIFF is a better format for printing books. It was fine to scale the PDFs to any size in Publisher because they're a vector format. With TIFFs you need to ensure they're high enough resolution for print. I'm oversimplifying, but if you're printing at 300dpi it's nice to have a 300dpi TIFF image that you're not scaling larger in Publisher. If you were to scale it to 200% in Publisher it would be 150dpi. I recommend using picture frames in Publisher instead of just placing images directly onto the page - draw one with the Picture Frame Rectangle Tool and make it the size you want your image to be. Let's say you wanted it to be 4 inches wide by 0.5 inches tall. If you were aiming for 300dpi then you'd export your TIFFs cropped to the music itself at 1200x150 pixels. Then you'd just place that image into the picture frame and from properties choose no scaling and centre in the frame. This will ensure your images are consistently placed in the margins, not distorted by scaling, and so on. I don't draw a new picture frame each time. I copy the previous one with its image already in it, paste it where I want it, and then click Replace Image in the context bar. This makes the process very simple. I also created a paragraph text style just for my images to properly format my photos within the text frame. All of my images are inline, they float with the text.

You have a speedy M1 with 16GB RAM so in my opinion 5 minutes for Publisher to do its housekeeping tasks when opening your document seems excessive. I have an old Intel i7 MacBook Pro with 16GB RAM and I think my book is slightly more complex than yours but instead of hundreds of linked PDFs I have hundreds of linked TIFFs. But while Publisher is sluggish for me when I first open my book, it finishes the housekeeping it does when opening a document without a minute. You have much faster hardware so my best guess is that it's due to using PDFs. I don't know how Publisher is coded of course but TIFF and other raster formats are the simplest for a layout app to deal with. Vector formats like EPS are a bit more complex because they must be rendered, whether by the app or the OS. PDFs are just PostScript like EPS but PDF was originally intended for standalone documents and not for creating vector illustrations for import into other apps so it may be more complex to deal with. I think you should do a speed test using a different image format for your music illustrations. EPS is the obvious choice to try that but you could also consider using TIFF if you know the exact resolution your book will be printed at and you know you're not going to change your mind and make the illustrations larger later on. This should deliver the same quality and reduce the workload for Publisher to deal with when opening your file. The price will be larger illustration file sizes. When you open a document in a page layout app like Publisher the app tries to give you editing control as quickly as possible. It continues to do tasks related to opening the document in the background rather than locking you out until it's completely done. For example, Publisher needs to generate thumbnails for each page when you first open your document but after giving you control. Publisher is also checking all of the linked resources to see if any of them have changed. But there's a lot more going on that we can't see which is why it feels sluggish at first. My knowledge is rather dated but page layout apps typically store documents pre-paginated with markers in the text stories to indicate the start of each page which is why you can open a document to page 125 and the app already knows what text goes on that page. But apps also may re-paginate after loading linked resources, dictionaries, and so on in case anything else has changed.

What Publisher is doing matches Apple's HCI standard. Quote: "Scroll an appropriate amount when performing page-by-page scrolling [emphasis is Apple's]. Typically, a page is considered the current height or width of the view, minus at least one unit of overlap to maintain context. You define the unit of overlap so that it makes sense for the displayed content. For example, one unit might equal a line of text, a row of icons, or part of a picture." Therefore, when scrolling up by a page you should scroll up less a certain amount which is up to the developer to choose. I think the confusion is because some programs should ignore the direction about one unit of overlap. For example, a PDF viewer that offers a mode to always keep a full page in view should not use one unit over overlap. There's also confusion because programmers, even those from Apple, don't follow the rules. For example, in Apple Notes on macOS, scrolling in page increments by clicking in the empty area of the scroll box will scroll by a page with partial lines rounded off but scrolling in page increments by keyboard shortcut actually scrolls by more than a full page so you miss a line or two of text on each scroll.

I know it's too late now - I'm seeing this late - but to delete overflowed text that you can't see such as your pages and pages of filler text that was pushed down, just position the insertion point cursor near the end of the visible text and shift select to the end of the story - I believe it's Shift+Command+Down Arrow. Then hit Delete.

Oh I thought you were talking about Publisher - I've never wrapped text in Photo before, I use that app just for editing photos. I'm unable to offer advice then.

I agree with Walt that this works as described. I'm using captions on photos in two manners in my book. For most photos, I'm placing them inline so the paragraph after the photo is simply styled as the caption. The photo and caption flows with the text and it works perfectly. But I'm using a 2-column layout and I want some photos and their captions to span both columns. Since there isn't a span columns feature, I'm grouping the picture frame and caption text frame together, wrapping text around the group, and positioning the group manually which I believe is what Walt recommended. This also works perfectly but of course I have to reposition the group when I add or remove text before that point. I'm having a hard time visualizing the issue you're describing but perhaps the main text frame that you're adding the group to has text wrap turned on, too?

I probably could have recorded this better but I believe they were both minimum width. Here, I've recorded it again and made it more obvious. I don't personally care about this as I never keep the Text Frame studio open but I imagine it's a bigger deal for others. My prod copy has the Text Styles studio taking up the entire right column as it's the only one I consistently need. Screen Recording 2021-05-27 at 6.48.59 PM.mov

I also use no break a lot and it's an excellent suggestion to use it only as part of a character style. I just went through my document and replaced the direct character attribute with a character style.

I kind of like the size of the medium icons but it depends on your page size. You're using a very tall page. Mine is tall, too (5x10") but with facing pages on it's really 10x10 so the icons are square and at a size large enough to recognize the pages. I wouldn't want it much smaller. But I can see your point, if you're not using facing pages and are using a tall and narrow layout then you're going to have big icons.

Here's a video showing the panel width becoming larger when docked for me Screen Recording 2021-05-27 at 6.13.16 PM.mov

Confirmed that using a non-master page text frame works around the issue.

Confirmed that using a non-master page text frame solves the issue.

I think it's just a bug - the text frame panel now becomes wider when it's docked than when it's undocked. There shouldn't be a need to move the options to the left which would make them unaligned with the other options (shudder! :-)

This is such an easy bug to workaround, but I agree it's also likely an easy bug to fix. I used to have the Index title in the same frame as my index but I made it easier on myself by separating them. Now I can just select all, delete, and insert index instead of drag selecting the index content. I'm more concerned by the other two index bugs (spacing and style override) since there aren't easy workarounds for those.

More information on this - style override for an index marker can lead to just that one index entry for that topic being override (correct), all of the index entries for that topic not having the style applied (incorrect, as shown in my example), or all of the index entries for that topic having their style overridden. So you could end up with any of these results when what you want is the first outcome. This feature isn't currently functional. Clowns 1, 2, 3, 4 Clowns 1, 2, 3, 4 Clowns 1, 2, 3, 4

Here's what I'm seeing. Thanks.

Thanks, that's what I thought. It's not a big deal.

This is 100% repeatable but I don't know the true root cause. The attached video uses a very basic test document with index marks for the same topic on pages 1, 2, 3, and 4. The mark on page 2 has style override set to Strong. The video shows the index being inserted and the index is correct: 1, 2, 3, 4 with the 2 bolded. Next the video shows inserting a page break before the content on page 2, moving the index mark with the style override to page 3. The index is then deleted and reinserted (because update index doesn't work right now) and now the index is 1, 2, 3, 4, the 2 is not bolded as it should be. That's the end of the video but if you insert another page break moving the index mark with the style override to page 4, the index entry will still not be bolded. The problem can be duplicated if you turn facing pages off, too. I don't know why style override sometimes works and sometimes doesn't but for now it can't be used. I've attached the test document so you can try it out but this is easy to duplicate. Index Bug.mov Index Style Override Test.afpub

I believe Publisher is inserting a non-standard space between multiple index page numbers which is more apparent in certain fonts. In these two examples, Arial vs. Avenir Next Condensed, I've used a comma+space separator after the index topic. If you look closely at the Arial example you'll note that the spacing is greater between the 2, 3 and 4 then after the topic itself but it's not too bad and most people wouldn't complaint about it. But in the Avenue example, it's very apparent and I'm unsure how to correct this. I believe Publisher should insert a regular comma and space after each page number and not an em space or whatever it's inserting. Thanks. These screenshots were created in a blank test document with default styles.

Is there a way to have an index marker in Publisher show up on its own and as a child of a topic or do I need to insert two index markers? Before I enter a number of extra index markers I wanted to verify how this works. E.g., how do I make Apples and Banana show up on their own and as children of Fruits? Thanks for your help. Apples 5 Bananas 2 Cucumbers 7 Fruits Apples 5 Bananas 2 Onions 6 Parsley 8

If you can't fix it manually by editing the TOC text styles, you might try deleting the TOC and all related text styles and then reinserting the TOC.

Single click the picture frame. Then choose Layer > Master Page > Edit Detached.

That's odd, my book's section manager looks identical and I don't have this problem with my table of contents. It shows the correct page number and it shows it in roman numerals. There's only one difference and I don't see how it would cause this problem. Your section 2 has pages 18-233 because you chose continue page numbering for it. I restarted numbering in section 2 at page 1.

Here you go. A blank document with some dummy text. I inserted two markers before starting recoding. After starting recording I insert the text, add a few more markers, and then attempt to update the index by clicking the update button and choose the menu command, which is disabled. Am I doing something wrong? Thanks. Index.mov

I think you're right, there is no way to do this. The easiest workaround I can think of would be to put the pages from 0-9 in section 1 and then preface the page count with 00. Put the pages from 10-99 in section 2 and preface the page count with 0. Then put the pages from 100+ into section 3 and don't preface the page count.