thomaso

Appears to be easier for them to develop for Windows first; it is my impression from several forum keyboard shortcuts discussions in which Serif does not seem to be interested in very traditional Mac GUI rules. Also, the context menu partially is created by the system. For instance I have in AFPubs "Bullets and Numbering" options for the "Text" field some context menu items relating the write direction. That's no Serif creation, does not even make sense here but exists also in other applications which support these macOS feature. What is "red versions" ?

Ah, by "buried deeper" you mean "more cryptic named". However, the prefs will/must be placed either in User/Library/Prefs or in User/Library/App Support, and they probably will not loose any more or less ovbious hint in the filename to the according app. So, I am not worried not to find those prefs but more that they seem to alltogether in 1 file, which results in a complete reset of users customized settings – different to f.i. indesign, where you have workspace palettes, keyboard-shortcuts, color tables etc in seperate files. By the way: i'd say the .dat file you mentioned is not the complete prefs but kindof incremental backup only. As Mr. K. pointed out yesterday the user prefs are held in user/Library/Preferences/com.seriflabs.affinitypublisher.plist. (the .plist is ca 10x the size of the .dat)

Thank you Walt. I forgot to mention that I use Mac, where unfortunately the context menu does not have these infos.

Go through the blue door. Avoid the white door with the X.

I am shure, to make it easier for more complex projects in your future. Or, to answer with an everyday picture: You are in a cinema and go to the bathroom. There are two doors. You choose one. Now it is very simple to open the door but you need to read a bit signs to open the wanted only.

Aha. Seems you call a screnshot a print. This result looks exactly like what you have initiated. You placed a Picture Frame (NOT with the rectangle tool) and that makes appear the X. Also you have a margin on your page, that makes the greyish rectangle. This means, if you want to get rid of X and rectangle: 1. Create the rectangle with the rectangle tool. 2. Set the margin of your page to 0 (Zero) on all 4 sides.

In my experience the colored - blue or grey - rectangles are irrelevant for page moves. They do only indicate, which page is going to become selected on double-tap (blue) or which is momentarily visible in the document window (grey). When you move the view in the document window than the gray rectangle in the pages pane jumps synchronously according to the document window view. To move a page or spread in the pages palette, I do not need these rectangle markers, I can ignore them. I simply click on the desired page (regardless of the gray rectangle) and drag it directly while holding down the mouse button. The blue vertical line will indicate the new position if I release the mouse there. The delay before the scrolling could be less irritating if the scrolling speed would increase gradually but immediately.

Here is the Affinity Publisher Beta forum. You might want to have a look there again:

But what about to allow scripts, sooner or later? Such an interface could satisfy particular user needs – from tiny to big markets – without making you any trouble once the interface is available.

A visible X on a printed result on a real sheet of paper? Or a print as a screnshot? In case of a screenshot you might check the rectangle tool. The picture tool creates an X, the rectangle tool does not. "and lines" – ? Can you show us?

What makes you think so? – I still hope finally the palette issues, especially with 2 monitors, will make them allow the user to save this setting to be able to restore it in case of a crash.

To simulate a paper color you simply might place a colored rectangle on your master page. I'd rather miss an option to set an object to not printable/not exportable in general, without the need to set it invisible before print/export.

It also happens to me with copying-pasting from AfPub into Firefox, f.i. into this forums text field or a browsers search or url text field. Whereby it works with an intermediate step in a text editor. Not a big problem but unusual.

Appearently there are issues with transparency in your result with black rectangles. Did you try already a different PDF setting to avoid them? Flatten/rasterize everything might help.

You might missunderstand my approach in this sample. It is more an experiment with somehow corrupted objects than a problem to avoid or solve. I cleaned the layout from this topics origin, down to the two frames to see what might cause the text flip in AleMellos afpub. The offset in the lines is less weird than simply the vertical align setting for each text frame. Also the frame break is typed in purpose to achieve a text flow regardless of line spacing or frame size. Both settings made it easier to play around with these objects.

This appears magic. I can't find anything which might cause this. In your file I startet to check if there is another frame couple behaving like the one top left – but I could't find any. Than I deleted any object except these weird frames and one healthy couple. After that suddenly alos the healthy one turned to weird. I have two of these magic pairs in the document now (but I can't reproduce them further). I'd not name it a real bug, rather a coincidental, weird data hiccup. But worth a look inside, might be especially for developers: magic flow on copy-paste.afpub top to bottom.mov

Can you still reproduce the problem? if yes, I'd like to get your file to see whats going on. In my example it works as you want it, – correct? text flow moved.mov

One more crashing f & r document (1.4 MB with few text on 2 pages only) ...f & r _ every frame & crash.afpub And 3 related crash reports ... Affinity Publisher Beta_2018-11-24-183822_mbp1.crash Affinity Publisher Beta_2018-11-24-184511_mbp1.crash Affinity Publisher Beta_2018-11-24-184632_mbp1.crash Just noticed: it appears to do a search and find in the complete document – regardless whether a textframe is selected or not. – Can I prevent this behavior or somehow limit a "Replace All" to particular frames or pages?

Hm, I can't recognize any change of text positions in your screenshots. Can you tell which words get wrong positions? And what do you mean by "connected"? How did you connect them?

To delimit what causes the issue and/or as workaround you could try to ... a.) ... export parts of your document only b.) ... choose another PDF setting (f.i. low resolution, without image downsampling, no font embedding, with/without font curving)

Oh, sorry, I meant the double triangles at the end of each axis. With them it's possible to reduce the amount of rows/columns (– but its not possible to select a particular area to delete).

Is there any place I can recognize if an image is stretched (= out of its original proportions)? I'd expect to read this at least in the Resource Manager > DPI > horizontal/vertical dpi – but it tells only one value (the smaller one?) And, is anywhere even an info about the images placed size and its stretch values in x % , y %?

Also, furthermore, besides align and constraint, the Picture Frame Tool does sth to size and proportions (which I unfortunately did not understand yet, too). Last but not least: if you double-tap the blue dots in the middle of a picture frames edges the frame size changes. (To me always and only to square proportions – I might not have this experienced enough)

I guess it's there: in the Picture Properties > Anchor section: tap the center point to make the content jump to the center of its frame, regardless of the contents size.

Concerning the frame commands may be Align + Constrains do a workaround? (unfortunately I did not understand yet how they influence each other and/or the objects. To me they often do nothing or sth totally unexpected yet)