DavidRGreen

For me, It happens every time I open a document, and right-clicking on a layer is the first thing I do after opening. Otherwise, the context menu appears where expected. Since others see it, it may be something not being initialised on application start, or document load.

Hi Team, I've noticed this quite a lot (through previous and current versions and revisions); When I right-click on a layer, the first time, the context menu does not appear at the pointer, but on the left edge of my screen. I've captured the moment in a screen-shot, where you can see the location disparity between the high-lighted layer on the right, and the menu which appears on the left. I am currently on Photo 2.0.4 running on Win 10 Pro 22H2 currently using 33% of 32GB RAM. At first, I thought that the context menu hadn't appeared, so I right-click again, and it does, then I realised it was not appearing where I was expecting it on the first click. Has anyone else noticed this?

It is odd that despite all this time, and a new version no less, Assets cannot be moved between "Categories", apparently only "Subcategories". I'm surprised that there is no right-click context option called "move" or "copy". It would be all too easy to drop an asset into the wrong area, and then want to put it where it should be…

Given that there is facility to "print" in N-up layout, it was surprising that N-up was not available for the export as well. Technically, "Print" is an "export" function when you think about it. Anyway, I did try and print to PDF with N-up, but the results were poor as the render quality fell though the floor. I was hoping that N-up would solve another issue in Publisher were I have so many elements on each page, Publisher crashes quite often as a result, but the exercise is a non-starter as I have now discovered that I can't generate output.

I have pretty much finished shrinking the document down to its minimum. All repeatable elements that were transferable to the Master Page have been removed from the main body of the document. And I also discovered that all the bitmap images, including the backgrounds, were embedded, contrary to an assumed link status, but that's changed. The document size is now 4.94 MB (5,187,545 bytes). As reliability goes, for the past two days, I did notice that when I opened the document for the first time in the day, it would crash Publisher. But then if I opened the document again, without much delay, it would not crash, and in those past two days, any other time it was opened on that day, Publisher would not crash. Next day, crash on first opening of the document, and never again on that day. … that does strike me as unusual; as if opening causes something that allows it to re-open without crashing. Given that document size is not supposed to be issue, and at 5Mb, that's not unreasonable, it could be element count. I didn't count every element in the document, but there is about 800 by extrapolation in the document body overall. There are two Master pages, one contains 117 elements, the other contains 9 elements. So, all up, about 930 elements; a mix of "Artistic Text", Rounded corner boxes, Donuts, Lines, SVG pictures, and a few bitmap pictures, all are linked. I hope that the links between the document and the assets are relative. It may be a nightmare if the document moves to a new path and they are absolute. With more than 150 elements per page, that may be pushing Publisher's envelope. … Is that it?

I have been working through the large document I created. Instead of being 17.9 MB (18,782,101 bytes), it is now 15.8 MB (16,604,122 bytes) in size. Although, it is understood that the document size is not the issue, I have been reducing the number of assets in the document, which I have done by transferring them from the content body to the Master page. This process is only partially complete, but about 40 elements have been removed so far, mostly (rounded) box elements and text, and a few undisplayed SVGs. The document is a work in progress, so there have been some element additions as well, but an overall reduction. In the last two days, the document now has only crashed Publisher about 50% of the time. Obvious scope for improvement, but an improvement none the less. Better than the aforementioned 80% crash rate. So while size may not be the issue, maybe element type and count is significant.

Hi Nathan, As I mentioned in my original report, Publisher is terminating without generating a "Crash report", the aforementioned directory was devoid of any relevant entries. But while typing this, I opened a few of the split files, and they apparently opened without issue, for the time being. But, a new entry in the "Crash report" path was created. 2df7f872-503f-497c-b62d-c9774c0317fc.dmp But, I'll attach one of the split files anyway, that had caused a crash. Solo Play Card Deck - large icon - sheet1.afpub As I plan to expand this document in future, I am keen to come to terms with what is causing the issue. So while these documents contain 9 elements arranged on a single page, I am staring to create a new version using a 9-Up layout with each element on a separate "page". But that will take a while to build… I can't read that .dmp file, but I will be interested if it can throw some light on the problem. /David…

Publisher just crashed opening one of the smaller files created, as mentioned in the original post. So size - 7.00 MB (7,348,109 bytes) may not be the issue. … I'm out of possible ideas right now.

The document I created is of a reasonable size - 17.9 MB (18,782,101 bytes), 10 pages, each page containing 9 cards for a game project. The document will cause the application to crash 80%+ of the time. I have tried a few things to alleviate the issue; changing the render from "UHD Graphics 605" to "WARP" has not helped, although I thought it may, but that was just the minimal chance of opening without a crash, apparently. I changed much of the imagery within the document from .eps to .svg, when I could open the document, which were smaller, but that did not help, either. There are no logs, or error message, created by Publisher to indicate what the issue is. While typing this, I managed to open the document without crashing, and split the document into 5 parts, 2 pages per document, then closed the application and re-opened each of the smaller documents individually, without any issue; for now… Is that it? Does Publisher allow a document to be created that is too large to be re-opened? If so, then maybe some internal protection is required…