nwhit

Yes, the current beta (146) for 1.7.2 is noticeably faster for many things on certain computers.

Attached. sample text under graphics - upload.afpub

In playing with this, I guess I'm not understanding how to overcome this issue. I tried putting both a APh TIFF and the actual APh graphic into a Picture frame and still get the rasterization of the Artistic text around/under the graphic element when exporting with X-3. Thus I guess I am missing something important. In all the beta testing on Publisher, I never came across this since I had not tried overlaying a graphic item over text, but this is a big deal for a lot of work on print shop output work for clients. Hopefully there is a simple, satisfactory workaround. I also just tried the same thing in ID CS5 exporting with X3 and it does not raster the nearby areas of text. Sample of APub beta 422 pdf-X3 output. sample text under graphics - X3 output.pdf

Really do need this!

My Studio setup in Publisher just "disappeared" for no understandable reason -- lost 3 nested panels for some strange reason and the only way to get them back was to Reset Studio which destroyed about 15 minutes of arranging work. I agree -- this seems like a VERY simple request to be able to save/name favourite layouts.

In your sample, is the key to put graphics into a picture frame when overlaying text?

I’m also running ID and PS on High Sierra without serious issues. Get an “unexpected quit” whenever I quit the apps but no effect from that and can’t think of anything else that doesn’t work. Use both every week for numerous things. I’ve also heard from people running them on Mojave but haven’t dared try that yet. Plus I keep a VM of Sierra in order to use a couple critical apps that stopped working with High Sierra. In that VM, the adobe CS apps also work pretty well. Might be a tish slower but not enough to cause a problem.

Interesting! I looked at the other docs I have created in APub and several had the Iso grid turned on. I know I never did that, so not sure how that happens. I also checked when creating a new doc if it was a preset but the new docs created don't have Iso turned on. What would have caused that to be turned on in a doc like the one I sent you?

I wasn't aware that there was an isometric grid in the document. Completely unaware of that feature until now, so not sure at all how it might have gotten there! When the doc was created, never knew of nor set that so not sure how it came to be turned on. Strange! Need to go back and check all other docs created with APub to be sure it's not on!

I had this problem with 1.7.1 with tall, narrow picture frames. The zoom bar would appear on the middle to lower third of the frame itself rather than under it. However, in the beta 1.7.2, the problem went away both in the same file I had the issue with plus in any new ones. High Sierra, Metal.

Uploaded the file. The problematic Artistic Text item is currently floating over the main text area in this 1.7.2 version, the larger "How It Works". For the actual final pub, I had moved it off the main page and replaced it with a different text. But if I try to drag it down to the top-left or top-right of page 2, crashes the app most of the time. I just tried it now and I dragged it once down to page 2 and while still holding the mouse down, it disappeared (as per other issue), but dragging it back up it reappears, while dragging it back down a 2nd time, it crashes. Sometimes have to vary where draggin it to on page 2. In the actual pub, the images were mostly linked but I have embedded them for you.

Here is the crash log from a few minutes ago when I tried it again. Affinity Publisher Beta_2019-07-08-093556_TRAC-Main17.crash

Need a private link please.

Just tried a few HDR merges of RAW 24mp pics (3-bracket) and there is a noticeable speed improvement with this beta vs. 1.7.1. Hooray! (Both Metal on.)

Done quite a bit with 1.7.1 and 1.7.2 beta and have had no issue with text rulers. High Sierra, 2017 iMac i5.

Yes, I reported this earlier on another thread: Interestingly, the problem is (sort of) fixed in the new 1.7.2 beta FOR NEW TEXT FRAMES ONLY. Text frames created in earlier documents still have the "wandering" column adjusters. Thus, so far anyway, in the current beta 420, old text frames need to be replaced with new text frames to resolve the issue. Hopefully a newer beta will fix the problem with existing text frames already created.

Tried the original document created in 1.7.1 with the Artistic Text element, re-saved in the new beta 420. Dragging the Artistic Text element (3 words with a gradient fill and drop shadow), it still crashes the beta.

Normally if you change a file name of an open doc in the Finder, the app automatically gets the new file name for the open file. Tried it on two open files. One that did not have any changes/modifications got the updated file name. The other open file that had not been recently saved did not update the file name. Thus when closing that file, APub asked if I wanted to save it, but it saved it as a new file with the old name.

As an update, it now appears that PERHAPS if you open a doc made in 1.7.1, the bug is still there with existing text frames. If you create a new text frame in beta 1.7.2 (in a new doc or even in an older doc), the bug seems to be gone. While that is helpful, would mean a lot of work to "repair" all existing docs done in 1.7.1 by having to replace most of the existing text frames.

Just tried with the new APub beta 420 and still same problem.

Tried with new beta 420 and now in a clean new file, if I try to drag an artistic text item from one page to another, it simply disappears. Gone! But didn't crash the program.

Thanks. Just downloaded the new beta 420 and it appears from initial testing it is fixed. That wold be great! Just tried it on an an existing document and it sometimes works and other times doesn't. In some cases, can't find the adjustment point/cursor at all until the text frame is changed to different columns and widths manually. But still fairly often, the drag handles are still misplaced. Got my hopes up too quickly!

Just tried it again using APhoto beta 146 and it still does the same thing

Based on your post, I just downloaded Markzware ID Util and got the same result copying/pasting right from the ID Util Stories window. Had to export to RTF, then drag/drop into APub to get the formatting to stick. Be much nicer if, as you said, we could just copy/paste. But still may be handy in certain circumstances. Our firm has a lot of legacy ID files that we routinely use as a starter for a client's updated pubs.

Aha! Found the difference. If you try to copy/paste a text block, doesn't work. Have to copy the text, then paste into a text frame in APub.