Dave42

Interesting. I have all my files on a locally-attached disk (C:) so network shouldn't be an issue. In my case Publisher is completely hung - task manager says process is deadlocked. As an aside - I have observed that Windows Explorer on my system (latest Windows 11) occasionally and unexpectedly switches from a view of a selected folder (on C:) to a desktop view. Research suggests that can happen when Windows loses contact with a network drive - which mine isn't. So I don't know if there is an underlying issue with Windows - although all other applications work as expected. I'll try the Event Viewer.

Publisher seems to have been better behaved last couple of days but finally hung.The dump file is 22.8 Gb. Is that really expected ? Looking at the Dropbox predicted transfer time (I don't have a very fast uplink) the upload is going to take about a week, give or take a day or so. That doesn't seem very practical. (it would be quicker to burn a blu-ray disk and put it in the post - which I can do). I'm slightly reluctant to upload the .afpub and the accompanying 300 Mb of linked jpegs as I don't have permission to redistribute the latter.

Running Publisher 2.4.2 on Windows 11. I have a reasonably large document ~600 A4 pages with ~200 linked jpeg images. The application regularly freezes/hangs (Windows reports app not responding) when document is open. The hang does not appear to occur in response to any user action. e.g. I can leave the app unattended for a few minutes - sometimes when I return it has hung, sometime not. Once the app has hung it does not recover (I've left it for extended periods) and has to be terminated. Looking at task manager when app hangs I see the Publisher application is at 0% CPU and total system CPU at ~7% or so. System memory is at 66%. This seems to be happening after last upgrade. Not sure how to diagnose further. Couldn't see a recent report of this problem

Managed to repro the problem. Looks like a TOC update issue. 1. Create a TOC (PDF bookmark set) referencing a heading. That creates an anchor for the heading (anchor name same as heading) with PDF bookmark attribute set 2. Create a cross-reference to the same heading with hyperlink attribute set That creates another anchor for heading, truncated name, no PDF bookmark attribute At this point all is as expected. 3. Update the TOC This appears to transform the cross-reference anchor into a duplicate TOC anchor. i.e. we end up with a duplicate TOC anchor for the heading (same name, PDF bookmark set) and the original cross-reference anchor has been deleted.

Mike, thanks for looking at this. Unfortunately I now can't repro the issue either. When I observed the problem, creating a cross-reference to a heading was generating an identical duplicate anchor to that created by TOC (exact same name, same PDF bookmark attribute set), resulting in duplicate bookmark in PDF. I deleted the offending cross-reference entries and noticed that the duplicate anchor entries remained. I deleted those manually. At that point I am pretty sure that I recreated a cross-reference to a heading as a sanity check and observed the same issue. So it looked like a hard problem. I have now tried to reproduce the problem on a new document and failed. Cross-reference to heading (with hyperlink set) creates a new anchor, different (truncated) name to TOC anchor, and no PDF bookmark attribute. I then went back to the original problem document and created a new cross-reference entry there. It now no longer creates an exact duplicate anchor to TOC anchor. Instead it creates an anchor with a new name (truncated from heading) and PDF bookmark attribute clear. Resulting PDF is as expected - no duplicate bookmark and clickable cross-reference.

I am adding cross-references to headings in my document. I set the hyperlink attribute in the cross-reference panel because I want the referring text in a PDF to be clickable. This generates an Anchor for the heading with PDF bookmark attribute set. That's a problem because I already have Anchors with PDF bookmark for my headings (created via TOC). The result is that if I cross-reference a heading I end up with two Anchors and two PDF bookmarks for the same heading (one from TOC, one from cross-reference). I can't see any way to globally disable the PDF bookmark attribute for Anchors created via cross-reference. I guess I can manually disable PDF bookmarks for individual Anchors created via cross-reference but that doesn't really scale. Any suggestions on how to work-around this ?

Mike & RM, Thanks very much for taking the time to look at this, and for the work-arounds. Much appreciated. I'd have thought pasting from Word was a fairly common use-case for importing endnotes and am therefore a little surprised that feature testing didn't pick up this behaviour. Hopefully it will get fixed in near future.

I'm trying to import many pages (~60) of Word text (docx) with endnotes into Publisher V2.0.3. I want to use text-autoflow rather than manual page creation and linking. My master page is A4 facing, text frame with 2 cols on each page, pages linked 1. I Paste text into first (and only) body page 2. Publisher populates first page and creates a second Endnote page. Both pages have overflow text (as expected) 3. I autoflow the first page (click <shift>flow) 4. The text flows from first page into existing second Endnote page (seems to creates a new text frame under the existing one) and then flows through into new auto-created pages. So I'm left with the both autoflowed body text and Endnote text frames on second page (one overlaid over the other). What I would expect is autoflow to insert pages in front of the Endnote page. Any hints on how to use text autoflow with large amounts of text containing endnotes ? At the moment I'm reduced to manually creating and linking pages prior to paste - works fine (Endnote page added after manually-created pages) but tedious for large amounts of text. Apologies if this has been asked before (I searched but couldn't find a topic)