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.

I had the same issue today, but without using crop marks as the PDF was for Magcloud print-on-demand. Even cropping in Acrobat didn't help as the excess part that was cropped off was still in the final file, just not visible, so would still give the same error message when uploading to Magcloud. There are lots of workarounds, but workarounds aren't solutions to the inherent problem. I ended up importing the PDF (a 64 page magazine) into an InDesign document and making a new PDF from there that did work, which kind of defeated the purpose of using Publisher so I could move away from using InDesign. It seems that PDF import and export is the weakest link in an otherwise decent programme, especially for a version 1, but it is one that is going to stop professional designers from fully embracing it.

The issue with imported PDFs not rendering the embedded fonts has been well documented and complained about, so I hope it's something that can be remedied. It is definitely something that will be stopping a lot of professional designers making the swap. Although, being able to edit imported PDFs is very handy, if you have the necessary fonts. The issue I have had is with exported PDFs for print on demand, and Magcloud specifically. I just finished a 60 page magazine (plus cover) that had been done in InDesign for the previous 49 issues. I manually recreated all the master pages and style sheets rather than wait for the much rumoured IDML import. Everything went fine. The magazine was completed on deadline. When it came to exporting the PDF to upload to Magcloud for printing, that's when the fun started. Magcloud requires 3mm bleed top and bottom and 6mm on the outside edge. That was easy to set up on the document. However the print PDFs for Magcloud don't require crop marks, just the specified amount of bleed, so no bleed on the inside edge, but Publisher puts 6mm of bleed on both the inside and outside edges on spreads. Bleed on the inside edge is fine with traditional litho printing where the pages are trimmed, but not for PoD. The Front and back covers, which are single pages, do not have the extra 6mm on the inside edges. I ended up taking the PDFs into Acrobat Pro and cropping off the extra bleed, and although the PDF was now the right size, Magcloud was still detecting the unwanted bleed and giving an import error. After several different attempts and confirming the document measurements I gave up and ended up importing the PDF into InDesign and making the final PDF that way, because InDesign lets you specify "Use Document Bleed Settings" and gives you exactly that. In the end I was thinking I might as well have just stuck with InDesign, and may have to continue using it until these PDF glitches can be resolved. Exporting the PDF for our digital edition went without any problems as it doesn't require bleed. I have figured out a relatively simple workaround for the export problem for the print edition, if I decide to continue using Publisher, but it will require an extra step using Acrobat, or another PDF editor for the digital edition. But a workaround isn't a solution. If Publisher is to be taken seriously by small, independent publishers, as well as freelance designers, who use print on demand as well as digital platforms for the same document, then these PDF issues need to be sorted sooner rather than later. Otherwise, the layout and creation side of the whole suite is great, but the import and export bottlenecks are choking its functionality as a pro package.