Tegwyn

@Pavol, see the last few comments. It seems like they quietly added this in March last year. Give it a try and see if it works for you.

@narrationsdBased on watching some of the threads about the can't-save bug, I don't think they knew about it when they released. They probably just scrambled to examine the reported files and crash logs and fix it, as I would expect for a bug that affects saving.

Interesting! No, for me it is fine for at least a few minutes if I just open it without doing anything. Perhaps it has something to do with the linked images not being available for you? A bunch of the other bug reports I see on the forum seem to have to do with images and frames. At any rate, after leaving it open for a couple minutes, if I try to add a style to a TOC via the TOC studio, it crashes immediately. Crash dmp attached from just now, just in case I accidentally attached an irrelevant one before. 1bfc02d4-75c9-47da-97ed-52bdca81ffab.dmp

@Jon PUploaded, thanks!

@jcbriarIn this case, you don't have to silence the warning. You can just edit the preflight profile to set which PDF version it checks against. However, that does mean that it's only going to work out of the box for people who plan on exporting the same version as the default preflight setting.

@DanMThere are a few threads about failed saves on version 1.10. You've already posted in one thread I saw that had a staff person trying to figure out what was going on, so they're at least aware of it. Seems like some people get the issue randomly, so reloading and trying again sometimes works. Saw someone mention being able to open it in 1.9.2, and I've been able to open mine in a 1.9.4 beta, so you might be able to use a previous version.

I'm working on a large document (445 pages), and since the 1.10 update I get a crash whenever I try to edit any table of contents (whether full document or just section) by clicking the checkbox for a paragraph style to add or remove it from the TOC. (This document started in version 1.7! But the TOC issues didn't happen on 1.9.) This doesn't happen in the last beta I downloaded, 1.9.4.1082. It also happens if I add new pages to the end of the document, insert a TOC there, and change the checked styles from the default, even though at that point there are still no entries because I haven't checked "Include entries before TOC" yet. This does not happen if I make a fresh document with default paragraph styles and nothing in it but a single page with a text frame and a TOC. I can share the document privately. attachment_Log.txt 3d0f4e8c-876a-42e8-a534-d8582b87e446.dmp

I've also hit this problem. Seemed to happen after scaling up an image that was within a frame. (But not every image does this.) It's an SVG for what it's worth, but I'm sure that cover photo earlier in thread isn't, so I doubt the file format matters.

When creating a hyperlink that goes to an anchor, and the anchor is at the top of a 2nd column on a page (presumably on any non-1st column), the link may go to the bottom of the previous column. This appears to be because it's targeting the end of the previous paragraph. I've attached a Publisher file made in 1.9.2.1035 that demonstrates the issue, along with exports of spreads and pages. I've also attached exports from the same file with the current beta 1.9.4.1082. I got similar results for each. In Publisher: You can see the issue by double-clicking on the anchors in the anchors panel and noting where the cursor goes. You can also see the same from the hyperlinks panel by clicking the button to go to the target. In PDF Readers: I tried in SumatraPDF and Adobe Reader DC and got similar (but not identical) results in each. Links A and C go to the previous column in the pages export in single page view mode, and links D and E go to an arbitrary spot in the column if you are zoomed in enough (so that it can't fit the whole page on the screen?). Link B goes to the last line of the previous paragraph, which is fine in this context but maybe not intended. Link F is correct. In the spreads export in single page view mode, only link A is clearly wrong, and that's on the starting, single-page spread. However, links C, D, and E go bad if you're zoomed in a bit. Workaround: Move anchors past the 1st character on their line. Links will no longer go to the end of the previous column or paragraph. This issue affected me strongly because I added links in my word processor before importing into Publisher, since links to headings are much easier to make there. If you make anchors within publisher, it likes to select the whole word when you right-click and puts the anchor at the end of the selection instead of the beginning. link column test beta spreads.pdf link column test pages.pdf link column test spreads.pdf link column test.afpub link column test beta pages.pdf

The closest I've had to this issue was with a multi-column table of contents. If I remember correctly, all the links in the 1st column wanted to go to the same place as the 1st link in the 2nd column. It happened if the last link in column 1 went to the same page as the first link in column 2. This was solved by splitting the TOC into 2 linked frames instead of a single 2-column frame. Your issue looks different, but it may be worth messing with the frame and column setup (ex: switch from multiple columns to multiple frames), making sure none of the links break over multiple rows, remaking the links, inserting spaces (which aren't linked) before and after the links so they don't start or end a cell, etc. It's a bit of a long shot, because it looks like yours are all external links on different table rows, but if you're desperate, you could try that sort of thing.

Are the anchors in a text frame on a master page? If so, does it work if you "edit detached" the layer before trying to click the bookmark icon in the anchors studio?

I also found that I could not toggle the bookmark button in the anchors panel on or off when the anchor was part of text in a frame on a master page. (It might have worked if I used edit detached, I forget.) This was on the regular 1.9 version, but I don't see anything about it in beta release notes.

Let us know how it goes, or if it's just my computer doing dark magic! If your TOC is crossing more than one column, be sure to check all the links when you export. I found a bug, which I'll try reporting once I get together a clean example file that has the problem, where two entries that link to the same page apparently get combined even if they are split across columns, which seems to cause the link hitbox to become huge and clobber all the previous links in the first column. I'm speculating as to the cause, but the workaround is to split a multicolumn frame into multiple frames.

I just re-exported my project using Publisher 1.8.2 to make a few minor fixes and improvements, and I noticed that all my table of contents bookmarks exported with the whole line clickable, not just the numbers! I don't remember noticing that in the release notes. I hope it's intentional and staying around. Is anyone else getting this?

PDF bookmarks are not supported either (unless they just added them). You have to insert them with another program afterward, such as pdftk.

Overall, I think you should be fine. Details about my experience: The only image-based slowdown I've run into is when I used an image directly rather than placing it in a frame, and I set its wrapping to tight. The automatic wrapping outline had a very large number of nodes, and that chapter became sluggish. (I believe they have plans to fix this.) Things improved when I deleted most of the nodes to simplify the wrap outline. When I've put the images in frames and made the wrap outline myself, it's been fine. Every once in awhile, a change will take a long time to compute, and certain things are likely to cause crashes for me, such as editing global swatches (fixed in beta) or undoing and redoing table stuff. Saving takes awhile on my large project. (Also fixed in the beta version: be careful about placing docx files with tables and changing tables between pinned and unpinned. I've had that (apparently) corrupt my files before. If you're better than I am about saving new versions of your file frequently, then you won't have to redo as much if this happens. I'll be switching to the beta to keep this from happening again.) Publisher is generally a little laggy, but workable for me. I'm on a mid-range machine, so it might just be my computer. It's worth noting that most users don't seem to be encountering the issues I've mentioned. I've got a wimpier computer and a complicated document, so I don't want to scare you off. Publisher is a very cool program.

If the paragraph style and the table are both set to ignore baseline grid, I agree they should do so. But I disagree that you shouldn't be able to disable baseline grid at the frame/table level. I think it's very nice to be able to make the exception at that point rather than to make extra child styles for each paragraph style you want to put in frames/tables that should ignore the baseline grid.

@Angalanse For what it's worth, after my post, I ended up breaking it up into a different text flow for each chapter, and it helped enough for me to turn baseline grid back on. I was worried that splitting it up would break hyperlinks, but it did not. I went to each chapter break, selected the start of that chapter plus Ctrl+Shift+End (to select from there to the end of the text flow), cut, disconnected the text frame from the previous one, then pasted again. You might find this works for you if you have any spots where there is a clean split between pages (like a chapter title).

@Pauls (or anyone who can help), I'm getting crashes on save again. I can open the file but not save or save as. I tried lowering max RAM usage from the performance menu, using beta 502 instead, rebooting, uninstalling both 1.7.3 and the beta and reinstalling just 1.7.3, switching render engine from video card to WARP, and opening a previous version of the file. Unfortunately, trying to save the previous version broke that file, too. Making a copy of a file 2 versions old and opening and saving that worked. The last issue before the crash on save began was a full-computer crash, probably from running out of memory. I noticed RAM was getting close to 100%, and I believe I was trying to save at the time. After I rebooted, the crash on save problem started. It crashes on save even if it's nowhere near full RAM now. Possibly worth noting: I know I've had crash issues associated with table pinning, and this file did have a change where a table went from floated to unpinned. (So did the previous version after I reopened it and tried to resume from there, though it didn't successfully save and does not show that change on load.) I've attached the most up-to-date broken file and the first (aaa1b) and last (dfe7f) crash reports from this issue. Could you see if the file can be fixed, please? I'd be very grateful (again). dfe7fa1f-882a-4920-b767-5103d810bf9e.dmp aaa1b854-f67e-477b-b154-9b688da45870.dmp layout_v45.afpub

Fwiw, PDF export with hyperlinks is still broken for me in Windows beta 502. I just found out reading this thread that this was why I couldn't export as pages, so I tried it in both production and beta versions and, sure enough, it starts working only if I turn off hyperlinks . I'd been working away under the assumption that there's just some messed up table I'd need to rebuild at some point to get it to export. Fortunately, Changing my document to not use facing pages fixes this for me (after a long wait for it to change all 400 pages, plus some tweaks to master pages that got a little messed up). It's just a little inconvenient, because now I can't see the pages side by side, but I'm designing it to look good if the user turns on facing pages in their PDF reader.

That's really interesting. After you said this, I experimented again. When I make a new spread using a master page, the text frames do not show bold applied in the context toolbar (even if I switch to edit detached). But, when I insert a TOC, it's all bold, and selecting the text frame now shows bold applied in the toolbar. If I make a new spread with no master page, then select the text frame tool, the context toolbar shows bold applied. Sure enough, if I make a frame and put in a TOC, it's bold. If I deselect bold in the toolbar, then make a frame and put in a TOC, it's normal. If I select the bold frame, then deselect bold, the TOC is no longer bold and remains so when I update the TOC. I didn't even realize the text frame tool had text formatting settings for the frame itself because they don't show in the text frame studio -- just the context toolbar. But I guess somewhere along the line, the tool got set to bold and was remembering it. Bug(?): When the text frame tool is set to bold, creating a spread from a master page will cause the text frames it inherits from the master page to be set to bold even if they aren't bold on the master page itself. At least, this happens to me in this one file. I wouldn't think the current state of the tool should affect inherited frames -- only frames you create with the tool.

@Seneca Are you experiencing this on one of your files, too?

@Jon P , if you still have the last file I uploaded / you fixed for me via dropbox, I believe that will exhibit the problem. (I was working on an updated version of that file when I ran into this issue.) If not, I can re-upload later if you want a sample to investigate. Either way, editing the Base style to explicitly set font traits to Regular got around the issue for me, so I'm not in urgent need of a fix.

Yeah, as I mentioned in that comment, they aren't bold by default for me in a new document. This surprised me, as I had only really been working in the other one, but it makes sense.

I think what the behavior should be if ToCs are supposed to be bold by default is that... 0. Instead of generating/updating a ToC applying direct "Font weight: Bold" to all entries when the Base style doesn't specify "Font traits"... 1. Generating a ToC should create a "TOC Main: Entry" style with "Font traits" or "Font weight" set to Bold. 2. This allows users to manage ToC boldness more intuitively, as they do with regular text flow. However, I find that if I make a new document, newly generated ToCs do not bold by default. In a new document, it's not even possible for me to set Base > Font traits > [No change] without changing the font family from the default. And when I do, newly generated ToCs still do not bold by default. So, I think this is just something that got weird in my doc, probably from importing a bunch of text from a Word docx. I noticed that did all kinds of weird stuff to formatting and styles until I cleaned it up. Thanks for trying things on your end, walt.