Chris Patmore

Since upgrading to the latest version Publisher has started crashing frequently. I can't seem to see what is causing it. I'm using an M1 MacMini with 16GB memory running Ventura 13.1 This is a copy of the latest crash report, which means very little to me: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Crash-188448.txt

That is what I was suspecting, especially as there is currently a bug in Dropbox for the Mac that won't let it access or open the online-only files. I guess the Publisher file on the external drive is also trying to access those online files rather than the ones on the external. I'll try putting all the files back onto the main drive and see if that resolves it. Thanks for confirming what was floating around in the back of my mind as a possible cause.

When I try to open certain Publisher files (not all of them), that error message pops up. If I click "OK" for all the images the document will open, but I have to go through and individually replace/relink all the images, then the file works as previously. There is nothing wrong with the images. As there are over 500 images in the book, it's a pain in the proverbial to do. The file and links were originally on my main drive and Dropbox. Once the book was printed I set the files to be only stored online on Dropbox, which may have something to do with it, except I also backed up everything to an external before storing on the cloud. I get the same error messages when I try to open the backed-up version on the external. I would possibly expect to get a missing links error message, but not the wrong file type. I have figured out a workaround, but it's not a solution to the error, which seems to be a bug and not just a user error.

I am trying to open a Publisher I worked on at the end of last year to make some new text corrections. The original file was done in version 1.10.1 and I am now using 1.10.5 on a Mac Mini M1 with MacOS 12.3 When I try to open the file I get this error message: This is for every type of image file, and there are hundreds of images in the document so I haven't gone all the way to the end pressing OK. I have tried two different copies of the file (one from a back up) with the same result. Other recent similar files open without any issue. Any clues or suggestions as to what the problem could be?

That sounds like something Windows specific, as I can't find that in Mac. My suggestion might only be relevant to the way I work, as I place text by copy and pasting it into Publisher from a Word file, which shows the Chinese characters correctly, or I'm assuming it does as I don't read Chinese. It's just occasional characters that don't show up correctly.

I don't know if this has been addressed anywhere in the Forum, but I figured out a relatively easy way of getting a missing Chinese character to appear in Publisher. This was done using a Mac, I've no idea if it works with Windows. Select the character that is missing in AP in the original text file, then right-click on it and use the "search in Google" option. In Google the top find should be Wiktionary. Click on that link. In Wiktionary, on the top right of the page it will show the glyph number. Go back to Publisher, and in the Glyph Browser panel put the character number in the search bar, and it will highlight the corresponding character. Highlight the missing Chinese character (usually indicated with a box) in the Publisher text. Double-click the highlighted character in the Glyph Browser and it will replace the selected missing character in the text. It's a workaround, but it's easiest one I've used, and I've used some convoluted ones that I won't mention.

Is there a known issue with Chinese characters not displaying correctly? I was sent two short blocks of text to place in a book I am designing on Ving Tsun (Kung Fu). Very short phrases and words don't usually present any problems, but this latest batch has characters missing, and in one case incorrect characters. I don't read Chinese, I just noticed the errors when comparing it with the supplied text file. I have the correct fonts but some of the glyphs are missing or have been incorrectly mapped. See the samples below with the errors marked in Red.

None of the files have changed. The strange thing is, none of the previous editions that are on my back-up drive would open either, and they had all the image links on the back-up drive, apart from the recurring ones that are on my main drive. Even the previous one on my main drive that I will use as the base for the next issue wouldn't open even though all the image files have been removed. However, when I copied the same file from the back-up to my main drive, then unmounted the back-up, it opened without all the images linked. I have relinked the recurring images and it's still stable. It could be one of the ad files that was sent to me that I haven't relinked as I don't yet know which ads are running. The ads that I know will repeat have been linked without a problem. I'll try linking the other ads, which are also still on my main drive and see if one of those is the problem and let you know. The good thing is, at least I can start working on the next issue. And thanks to the new idml import feature I was able to open an earlier version of the mag from before the switchover, which was going to be my Plan B.

I've copied the previous version from my backup drive, unmounted the drive and the file opens without any problem if I don't link the missing files. However, if I try to open the version in my Dropbox folder, which is essentially the same file, it crashes Publisher when trying to open it. It didn't even get to the point of asking about missing resources, which would have been on the backup drive. I guess it's just a matter of using the version I just copied from the backup and a process of elimination to find out which file it doesn't like, even though it all worked fine in the previous version. The good thing is I should be able to work on the new issue now.

Done. None of the fonts or linked files have been included.

I'm having a similar issue. It crashes whenever I try to open a specific document (64pp magazine) that was created in Publisher 1.7. I've also tried a different edition from my external back up and the same thing happened. Crash report attached. It opens other documents OK, so far anyway. I've opened a PDF and an IDML file OK (top update feature). It's on a MacBook Pro 8,1 with 16Gb RAM and SSD drive running Mac OS X 10.13.6 Crash report attached. Crash Report.rtf

I had set a page range that include all the pages (i.e. 1-64). I did this because the first two times I tried to export the file without a page range I got errors, but when I put in the page range it exported the first time without any problems, apart from the extra, unwanted bleed. I have just tried to export the file again without the page range, the first time it gave the same error as before, but on the second attempt it worked fine and produced a correct PDF with no bleed on the inside edge. It was partly a user error on my part, but also a bug in the programme. It's good to know that it will work correctly and I can continue to use the software for future editions of the magazine, provided I don't use the page range setting, or at least until it is fixed. Now if that embedded fonts issue on imported PDFs can be sorted I'll be a happy bunny.

I saw on the other post about the issue, the moderator posted that it only happened when a page range was put in the export settings, which in fact is what I had done as I got an error the first two times I tried to make the PDF, but when I put in the page range, for all the pages, it made the PDF but with the extra bleed. I have just tried exporting it again without a page range, and although I did get an error on the first try, on the second attempt it came out correctly. They have acknowledged that it is a bug and will be working on fixing it. So there was a slight user error on my part, but on the upside it did uncover a bug.

I am using the latest version and the document is correctly set up. I have been using DTP (as it was called when I started) for over 30 years, so I do have a pretty good idea of what I'm doing. The issue is with pages that are spreads. Single pages, such as front and back cover export correctly. When they are spreads, the individual pages export with the bleed on the inner edge. As I pointed out in my OP, having the extra bleed on the inside edge is fine for traditional litho printing that needs crop marks and will be placed into imposition software, but for digital printing of print-on-demand it doesn't require crops. Hopefully the Affinity/Serif boffins can fix in the next update, and time-consuming workarounds don't really cut it.

It is definitely a bug with Publisher. InDesign will export a PDF with no bleed on the inside edge of spreads. Having the bleed on the inside edge is fine with traditional litho printing where the pages are all trimmed, or specific imposition is used, depending on the binding method, but with print-on-demand, which usually doesn't require crop marks but a very specific size page size that only has bleed on three outer edges, it will reject the file with the extra inner edge bleed. Even cropping the extra bleed off in Acrobat doesn't resolve the problem as that extra bleed is still in the file, just not visible, as I found out today. Workarounds are the solution to a basic fundamental error.