Nathan Shirley

Alright, thanks for looking into it.

So after saving and reopening this project, the same issue has returned, except this time your "Edit Wrap Outline, followed by Reset Wrap Outline" suggestion doesn't work. This seems like a really strange bug. Selecting the invisible text and telling it to "ignore text wraps" does work, and doesn't reset after saving and reopening. But of course I have no idea why any of this is happening...and why it didn't happen in v1.

Interesting. Thanks!

At first I thought this might not be a v.2 bug, but now I'm assuming it is. I created a massive project long ago, last saved in v.1.10.5.1342 and recently opened it in v.2.1.1 (running Windows 11). This particular bug relates to a bit of text that had disappeared in v.2. If you select it and drag it around it will randomly appear and disappear way down below where the selection is. Checking 'Ignore Text Wraps' (under 'Text Frame') fixes the strange disappearing text. In v.1 There was a LOT of this exact same styled text, yet this was the only spot it did this. I started another thread about it earlier, when I couldn't figure out what was going on. That thread has a video screen recording which better shows the issue. I also uploaded a 1 page version of the (400+ page) project in the last post of that thread. Here's the link: Just a side note, in the entire rest of this project, over 400 pages, this was the only spot where this particular issue happened even though I used this style of text a good bit. I did have one other little issue that happened maybe 3 or 4 times (out of maybe 200+): boxed text would decide to do a line break at a slightly different spot, sometimes resulting in text getting cut off. A slight resizing of the text box would fix it.

Okay, found some time to do this and yes, the bug is still there. I've attached the (1 page) file. My version 1 is: 1.10.5.1342 My version 2 is: 2.1.1 Just a side note, in the entire rest of this project, over 400 pages, this was the only spot where this particular issue happened even though I used this style of text a good bit. I did have one other little issue that happened maybe 3 or 4 times (out of maybe 200+): boxed text would decide to do a line break at a slightly different spot, sometimes resulting in text getting cut off. A slight resizing of the text box would fix it. I had to check the entire project VERY carefully to make sure I didn't miss anything. It makes me a little worried to install even minor new updates... V1 to V2 Bug.afpub

So after a lot of digging I figured out a fix, but I'm not sure why it works or why it works differently in v.1 vs v.2. Under 'Text Frame', checking 'Ignore Text Wraps' fixes the strange disappearing text. In v.1 'Ignore Text Wraps' isn't checked, yet the text is there.

Does anyone know what in the world is going on here? I had been putting off moving this huge project from Publisher 1 to version 2, and now that I have this is the first glitch I've run into.

Just had a chance to check this and after a quick test it does appear to be fixed. Thanks very much.

Okay, done. This video shows the two consistent bugs I mentioned in my April 14th post. Summary: After 4 RAW photos are dragged into Affinity Photo, each are adjusted a bit (it doesn't matter how) and are then developed, right to left. The right most photo screws up, the next two are fine, and the left most also screws up. Then when closing them, they all prompt to save, but not the right most one. And just my two cents: I really think Affinity 2 was very premature, especially considering the upgrade wasn't free. My experience on ver. 2 has been considerably worse so far; glaring old bugs not fixed, new worse bugs added, and while some nice new features appeared, they seemed thin for a major/paid release, especially considering many of the most popular basic feature requests weren't added. Still great software, but v. 2 has been very disappointing.

Any update on these bugs?

I found a few things that seem to consistently trigger this bug, although I think there might be more too it. You might want to read the last post here:

I experimented for a while with the 4 RAW files I just uploaded and I think I figured out some things that are actually consistent: If I load all 4 of these files, adjust them (I used the same preset on all), then develop them one by one from left to right, it seems to work. If I do the exact same thing, except I develop them one by one from right to left, the right most one will screw up, the middle two will be okay, and the left most one will screw up. This seems to be consistent. Also found another little bug in this process: If you develop right to left and then close each file after developing, the right most document won't prompt you to save before closing, all the others will. If you develop left to right they will all prompt. I'd probably have to spend a lot more time to see if there's more to all these bugs, but at this point it seems like at least for these developing bugs, the order of developing makes a difference. Of course I know I've developed a single RAW file before and had it screw up (once, and then the next time it didn't), so maybe there's more to it.

Just found this thread. This seems to still be a problem in 2.0.4. Developing randomly screws up changes or throws them out completely (roughly 25% and 75% respectively). Windows 11 here. Also using Sony RAW files.

This doesn't seem to have anything to do with applying presets as it will also sometimes do this without using them. It appears to be completely random. By the way, these are Sony RAW files (from an a6300) and running Windows 11.

I've added presets under "basic" and "tones." When I apply these to RAW photos in "Develop" and then try to develop them, it often seems to reset or screw up some of the settings, resulting in a bad develop. Everything looks good, then the development goes bad. It seems like it's more likely to get messed up if I apply the presets and then make further adjustments. Also, sometimes, but less often, the develop button just doesn't work...requiring me to cancel the development and start over. Also, when saving a "basic" preset that includes a white balance adjustment, the slider will look like it was remembered correctly, but the white balance of the photo will be unchanged. If I type in the same white balance number, or move the slider a little and back again, the white balance then takes effect. This was also a bug in ver. 1, but the other two are new. This all combines to be quite a mess...

Anyone know if this is possible (without a workaround) in v2?

Some people are printing themselves.

Those look promising, but do they support adding creep? I couldn't find anything about that from either.

Sometimes when right clicking a hyperlink to remove that hyperlink (through the popup menu), part of the hyperlink will be deleted, but not all of it. I've noticed this when two or more words are together made into a single hyperlink. Sometimes the middle of the hyperlink will be deleted (deleted from one word, or from a space only), resulting in the two sides of the hyperlink splitting, creating two new hyperlinks. This can be a little annoying to delete all the little bits.

Thanks.

That is the only workaround I've found to this problem. Publisher simply can't handle a large number of linked PDFs, but it can if they're embedded.

This is a known issue (at least it should be since I reported it right around when Publisher came out). I had what I believe is the exact same problem. My project was about 450 pages, also with linked sheet music PDFs on most pages. The more PDFs I added the more unusable Publisher was, with frequent crashes and using huge amounts of memory. The workaround was to simply embed all the linked files (I believe you can do it all at once in 'Resource Manager'). It still takes a little while to load up the project, but it's not that bad, and once loaded, it works great (I also currently have a similar Ryzen CPU). Of course having the files linked would still be more handy, but it's not difficult to update embedded files as needed.

This bug seems to only happen when hyperlinks point to PDFs and SVGs. JPGs and PNGs work fine. Also, there's another smaller bug I found: sometimes when right clicking a hyperlink to remove that hyperlink (through the popup menu), part of the hyperlink will be deleted, but not all of it. Sometimes the middle of the hyperlink will be deleted, resulting in the two sides of the hyperlink splitting, creating two hyperlinks. This can be a little annoying to delete all the little bits. See attached publisher file for an example with embedded SVGs, PDF, JPG, and PNG. hyperlink bug test.afpub

Well it was almost exactly like I guessed. Like PDFs, it doesn't matter if the SVG is sized (rather than vector cropped) to stay within the page; linking to it will still result in failure to export to PDF. Bringing in a smaller SVG, that easily fits on the page without any resizing also fails when linked to. And it doesn't matter if they are linked to or embedded. What I didn't guess right is that this seems to ONLY apply to PDFs and SVGs. I also tested a JPG and a PNG, and links to them work fine. See attached publisher file. hyperlink bug test.afpub

I haven't tested it specifically, though all these SVGs were at least vector cropped to be well within page boundaries. However, I suspect that even if they were both uncropped and fully within page boundaries the problem would be the same as with PDFs. See this on PDFs: My guess is hyperlinks don't work at all if they point to any embedded object, and probably any linked object for that matter.