Tegwyn

You'd think so, but this happens even if I make a brand new spread and insert a ToC there. It even happens if I make the new spread with no master page. Since it's not happening for you, something must've just gotten confused in my document somewhere along the line. I'm typing up another comment with how I think it should work, but chances are it already works right for most people. My project is just very unique I guess!

Just noticed this in the text styles panel (before I do the workaround). See the description section at the top of the panel: the bold is definitely being applied independently of paragraph and character styles. I'm assuming this is a default behavior of the ToC generator. It's worth noting that, in this case, none of the styles in the hierarchy (TOC Main: Heading 2, TOC Main: Entry, Base) have font traits set. So they're all just inheriting from some default. When I change Base to explicitly set font traits to Regular, the ToC styles begin to behave more like I expected. I don't even have to modify the ToC styles -- as soon as I update the ToC, all entries stop being bold unless I change a style to explicitly be bold.

Thanks for experimenting, @walt.farrell. In my case, the text did not become un-bold at all. The only way I could un-bold it was by selecting the text within the text frame and clicking the B in the toolbar. (And then it became bold again the next time I update the ToC.) Paragraph styles had no effect on boldness, even if they affected other things (like which font, whether it's italic, or spacing). However, I decided to mess around with it more, and now, if I've set the style to normal weight, it un-bolds when I update the ToC! I'm not sure what changed in the meantime. I'm pretty sure I tried that before! (It still does not show the boldness change after clicking OK in the paragraph style editor. It only shows when I update the ToC.) At any rate, it's workaround-able for me now. I just have to update the ToC after changing the style. Not sure if I just never tried updating after changing the paragraph style, or if something else I did in the document un-stuck whatever was making the ToC bold things.

@walt.farrell I think that's what I was doing, isn't it? As in the screenshot, I tried editing the paragraph style, but changes to the font traits or weight have no effect on bolding. (They can make it italic, and other style changes work. So, it's just the bold I can't turn off using styles.)

I've got a lengthy Publisher doc making use of a TOC. However, in configuring my TOC entry/heading paragraph styles, it seems it ignores any changes I make to font weight or traits except to turn italics on. I cannot make the font regular or black -- the text remains bold. There is no character style applied, but the toolbar shows bold is set, which must be automatic and overriding styles. Is anyone else getting this? If it's not readily reproduced, I can provide my file (though Affinity may already have it from other times they've helped me!). The screenshot has the cursor on one of the TOC 1: Heading 2 items. The toolbar shows bold selected (this was automatic, and if I turn it off, it resets when the TOC is updated) but no character style. The edit text style window shows regular has been selected.

I am able to save! Thanks so much, Affinity folks!

@Pauls Thanks! I'll try it out as soon as I get home. This should let me make more progress on this project this week. I appreciate that the staff monitors the forums and provides support!

@Chul Wow, that's a small document to be lagging! Have you tried messing with performance settings and turning off baseline grid (if you're using one)? I've also noticed that sometimes Publisher doesn't play nice with other programs. You could try closing non-essentials, especially if any of them seem to have high CPU usage while Publisher's open or if you're over 90% RAM usage. (For me, LibreOffice occasionally gets stuck using a bunch of CPU while Publisher is open, so I try not to leave them both open at the same time. It's weird.) For moving objects when it's being slow, you might try typing values in the transform panel directly instead of dragging. You'll still probably have to try a few numbers to find the right spot, but you may do less waiting.

@JCEyre Interesting! There's a performance option for nearest neighbor vs bilinear (I think?) rendering or previewing or some such thing. Does the pages panel affect performance differently if you switch that setting? (I'm not sure what all that setting applies to.) Edit: It's in the Publisher preferences menu under performance, if I recall correctly.

So, I probably do need a fix to the file, sorry. My redo was working ok until I changed a TOC heading paragraph style, after which it began crashing on save. (It was the only change I made between the last successful save and the crash save.) Also, somehow, both the version I sent as well as my other most recent versions have a bunch of tables right after the TOC and invisible, rather than the various places they should be in the main text flow. They appear to be copies of other tables that are in the right places. I tried deleting those layers to get rid of them, but that didn't stop it from crashing on save.

@Pauls Thanks! I've uploaded the file. I goofed in planning and wasn't able to get it to you during your working hours, so while I wait for the fix, I'll try redoing my chapter-splitting, starting from a version I saved before attempting that, then see if it gets borked again. If this is a time-consuming fix for you, feel free to wait until I've cried for help again. If it's a quick fix, I'll appreciate having a known non-corrupt version of the file. Are there any particular actions I should avoid that are likely to cause this bug in the current version of Publisher?

After breaking up my 300+ pages of flowing text frames into a separate flow for each chapter, performance improved, but now Publisher crashes every time I try to save or save as. This happens even if I made no changes, even after a reboot, and even if I try from the beta version. It shows the saving progress bar for a few seconds, but instead of starting to fill, it crashes to desktop. When I open the file, it doesn't have the changes, and it always starts with UI toggled off. When I press Tab to show the UI again, the tools (move, text frame, etc.) are all greyed out and unusable except for place image. They become usable again if I undock and redock them. The main issue for me is the crashing. Can my file be repaired? I read that it may have to do with pinned objects, and some of them did get moved around and possibly messed up as I broke the text into multiple flows by a series of cuts and pastes. However, it did save at least once after that refactor, so it might have been something I did afterward -- I did try re-placing a docx to figure out an issue with hyperlinks, and I probably made a few other changes. I can upload my file if given a secure link. I've attached two crash logs from today for the beta (309d4f51 and bda24f04). The rest are from 1.7.3. Most, if not all, are probably from this issue, though I did have some crashes on undo today as well. If this isn't one of the issues already solved for new files in the beta version, hopefully they'll be of help. d98bd4fa-52a7-476a-a907-b86826dcdb77.dmp 5d28fed1-c62a-43fe-8e59-d7d84c023d05.dmp 477d84a9-5855-479c-b860-e5a06481682e.dmp eb925895-e9ba-425a-87b3-cdc428ad0eca.dmp e9c7f580-96f7-4258-8d4d-784006afe333.dmp fb2f0022-b862-4440-95f9-5a1b0a2ab7fe.dmp ab6389af-0361-4b2e-a6ff-459f240dced1.dmp b020a5ef-a428-43c8-80fa-393def156412.dmp d5381eac-13d0-4918-8f7f-bc28f9a8183c.dmp c7aa65b1-b5bf-4221-a861-6f1d160ebfd0.dmp

Interesting. I wonder what the cause is in your case? Does your project have any place where a clean page break can be inserted? (For example, at the end of a chapter.) For mine, I'm going to try splitting my text frame flow at those points to see if having multiple sets of a few dozen linked frames performs better than having a single set of hundreds of linked frames. (But I'll have to be sure it doesn't break things like hyperlinks.) I haven't tried this yet, but if the slowness happens because it has to check if each change affects hundreds of linked frames, it might help.

I hear you. I'm doing an awkward workaround where I set the text frame to align text to the bottom (so it lines up by baseline instead of font caps) and auto-balance text between columns, then making sure all my paragraph styles have leading + spacing multiples of my body text leading. Unfortunately, it means I'll have to do manual adjustment on pages that end up with extra or uneven space at the top.

For what it's worth, the closest workaround I've found for avoiding baseline grid (if it's causing performance issues for anyone else) is to set the master page text frames to balance text in columns and bottom-align text. Then, if I've got widow and orphan control and spacing set right for my heading and body styles, I get basically the same effect without the performance hit. The only catch is that any pages with extra space will have that space at the top instead of bottom and may need have the frames manually adjusted. Example of the results on a spread with a bit more extra space than I'd like:

@LFGabelThis doesn't quite match your video, but for what it's worth, I found that turning off baseline grid fixed performance in my 400-page project. If I have baseline grid on, and flowing text frames (even empty ones) on most of the pages, the CPU hangs out in the 60-99% range forever, and the program is very sluggish to do anything. It sounds like your case didn't have high CPU, but I'm curious if turning baseline grid off changes anything for you. For me, it churns for a few seconds to make the change when I turn it off, then settles down and stays responsive.

Is this thread what you're looking for? If so, it sounds like they know it's a desired feature but haven't gotten to it yet. An alternative would be to do the mail merge in LibreOffice or MS Office. You can export to docx or pdf and place in Publisher for any advanced stuff if needed, though that might involve doing repetitive stuff to every page in Publisher, depending on what you need to add.

@Pauls I might have found the problem(s) in my case. I started rebuilding the project, copy-pasting stuff from the slow one's master pages, and I noticed that master page B, which inherited from A, had images (in frames) in its master A layer. These images were also in its own layers, resulting in several duplicate, partially-transparent images on top of each other. (I had previously moved the images out of A into B when I made B, so I don't know why B was still inheriting them from A in addition to having them itself.) Once I deleted those duplicate, overlapping images, the CPU usage dropped, and the project became more responsive. I was able to place the word doc (very similar to the one I sent) and autoflow just fine. Master B had been applied to maybe 50 out of 400 pages. I continued with the clean/rebuilt project anyway, just to be safe. When I turned the document baseline grid on, CPU usage shot up again, and the project became very sluggish, just like the old project. (I had been using document baseline grid in the old project as well.) The CPU and lag stick around; they don't just stop once it's finished aligning things (unless it's taking a very, very long time to do that). The CPU and lag persist if I delete the text from pages 5-400 so that almost every page is blank. It appears just having enough text frames and baseline grid enabled causes problems. If I turn the baseline grid back off, it becomes responsive again. (I checked this in both the new and old projects; both now behave this way.) As a side note, I tried doing baseline grid via the text frames on a master page, and that setting doesn't seem to propagate to the pages that use that master. I have to do it individually (by editing detached) or by using the document baseline grid. I'm also confused by text leading being ignored for the first line in a column. Maybe that's normal? But it makes it so I have to turn on the baseline grid to get things to line up, since I have headings that are different heights than the body text.

I've uploaded a big ol' Word doc. I've noticed that if I delete the big table of human special abilities that starts on page 70 and the big table of shapeshifter weaknesses that starts on page 81, it has fewer problems importing and flowing, though it's still extremely CPU intensive and sluggish to work with or autoflow.

@Pauls Apologies if there's a newer thread on this I didn't see, but I've also had this issue. It seems to be happier if I type the dimensions in the transform panel than if I drag; I assume it's resizing all applied pages every mouse move event, even if there are several in rapid succession. If you're still looking for files, I can submit the docx I'm using. It's an RPG rulebook, so it's over 330 pages before layout, with most images and a few tables omitted at that stage. It imports slowly, adjusts master page text frames slowly, messes up at least some of the paragraph/heading styles, seems to have real performance trouble autoflowing (especially if the pages to flow into don't exist yet), and can't autoflow at all past a certain large table (it just makes a zillion blank pages from that point on; maybe it chokes if the table would take more than one page on import).

Thanks, @stokerg. Do you know if there's a way I can edit an individual mark to change things like its override style? Adding index marks using the index panel's find tool is easy, but it doesn't let me set override styles as I do that. But once it makes the mark, I can't seem to edit it to add an override style either.

Apologies if this has already been asked, but is there a way to edit an index mark? I can delete it, but if I try to select the word or the index mark itself and add mark, it adds a new one rather than editing the existing one. (This makes sense if I want to put multiple marks by the same word but not if I want to adjust an existing mark.) The reason I need this is to edit the marks the Index panel inserts. Its find in document feature is much nicer than adding marks manually, but it doesn't let me add an override style to make one entry the primary one (bold or italic, for example). It seems like I can only use the find in document tool and still designate a main entry if I: Don't add the main entry from the index panel's find Add an index mark for the main entry manually, setting it to use an override style. That mark must be the first one for that entry on the page, or it won't use the style. (I assume it uses the style for the entry's first mark on each page.) Even if I do that, the index sometimes ends up making that page number, plus several page numbers after it for the same entry, use the style instead of just the first one. Maybe I should be reporting this as a bug? This screenshot shows a contrived example from when I was trying to figure out how to make the page number for the main entry different than the others. You can see the emphasis style got applied to several of the "enemy" entries instead of the 1 that I set to use it, and I had to insert both main entries manually instead of from the index panel.

Chiming in to agree. PDF bookmarks representing the various headings of my project are an absolute must for my use case. Adding them automatically in Publisher (based on TOC or paragraph styles or even anchors, though that would be more tedious) would be much easier than inserting them after the fact in another program.

@Jon P Actually, I take back the part about it not mattering. I'm getting consistent crashes about 15% into the export when I try to export all pages to PDF. Exporting all spreads works. I'm not sure if this is a different bug, or if it's also due to a bad table. It works if I export pages 1-20, then 21-60 as separate PDFs. Perhaps an issue with the TOC or other hyperlinks? Should I open a new thread about that? EDIT: Just for fun, I found a bonus bug that will probably be impossible to reproduce and not worth trying, but I'll note it anyway: I tried to open a large (80 MB) PDF in Publisher through file -> open to see if it would convert the bookmarks into anything (in hopes of figuring out how to creating them / if it's possible). Publisher's memory consumption shot up by about 8 GB, it started using the SSD heavily (probably because I ran low on RAM), and LibreOffice's CPU usage jumped up and stayed up for no apparent reason, spiking more whenever Publisher's went down. I don't know if it's a fluke or some bizarre interaction between the programs or if LO just freaks out when memory gets low, but thought I'd mention it. Computers are weird. The very high memory consumption on PDF open might be worth looking at, at any rate.

Thanks, Jon. Unfortunately, it is telling me that the fixed version you sent me uses features from a later version of Affinity, so it won't open. (Maybe because I'm on the Win 10 trial version still?) I'm not too worried about it though, as the color profile it's set at now works correctly. (Unless the tables introduce crashes elsewhere, too.) But I can think of a few things that might explain corrupt tables: I'm doing my writing in LibreOffice Writer, then exporting to docx so that I can place the file in Publisher and still retain paragraph and character styles. Something about this process results in all paragraphs with a heading style getting set as bulleted lists when they import into Publisher (in addition to the normal font size, etc. a heading should have). If I remember correctly, I was able to fix it per style by selecting a heading, turning off the bulleted toggle, and clicking the button to update the paragraph style. If going from Writer -> docx -> Publisher messes up paragraph styles, perhaps it also messed up the tables? The tables were all inline with the text in Writer and get set to inline pinning when the docx is placed. They all had a table format from Writer applied that affected row colors, font face/weight, and probably text alignment. I was messing around with one of the tables -- I think the Riding/Driving one on page 25 -- to figure out how pinning worked and whether I could get a table to span two columns while still moving with the text. I turned a lot of pinning stuff on and off and messed with the pin location and the table location. It looks like it's back at inline now, but who knows what might have happened in the meantime? I don't remember if I messed with table styles after placing the file in Publisher. I appreciate the prompt responses I've gotten when I've reported bugs! I do have some concerns with hyperlinking (my goal is a long PDF with internal/anchor links) -- see https://forum.affinity.serif.com/index.php?/topic/96021-automatic-heading-anchors-clickable-hyperlinks/ and https://forum.affinity.serif.com/index.php?/topic/87882-pdf-clickable-table-of-contents/ -- but it looks like it handles enough things better than Writer that I'm leaning towards purchasing. I'm still bitter that my CS bundle from before They went subscription-only came with everything but InDesign, so Publisher is pretty exciting for me.