ttl

Yes. Just simple thing as having object A and below object B and wanting to adjust A's vertical postition to have my defined distance from object B is still impossible to achieve.

@Old Bruce Yes, a (modificable) shortcut for filling of Replace with field with selected text would be fully sufficient. Adding it as a function to app/context menu as I proposed is not necessary in case, that this new feature (shortcut) would be documented in updated online help and mentioned in app update's new features list. Having ability to quick fill of Replace with selected text si very useful and I am using it (together with fill of Find) very often in InDesign. I think that adding this ability to Affinity apps shouldn't be a big problem as Ctrl + F/Apple + F (in default) already fills the Find field. And from this is clear, that it is far from ideal for intesive use/optimal work.

I have accidentaly discovered and surprised that there is not possible to set Hyphenation options in Designer. It makes no sense to exclude this part (one of fundamental) of paragraph settings in Designer and rely only on Publisher. I think that there are reasons to have it also in Designer. For example product packaging designs (boxes, bags etc.) often includes text parts (sometimes very long) where Hyphenation is needed. One-page documents people often prepare in Designer although I prefer Publisher for this kind of document.

One suggestion for a little improvement: it would be useful to have ability to quick insert of selected text also to "Replace with" field, not only to "Find". Now when any text is selected and "Find…" is selected from "Text" menu/context menu or (better and more practical/quicker) used keyboard shortcut Ctrl+F, the selected text is automaticaly inserted into "Find" field of "Find and Replace" dialog. It would be nice to have same possibility also for "Replace with" field, i.e. to have it as app function which can have keyboard shortcut assigned with, so filling of "Replace with" field could be done quickly from keyboard. The function could be named "Replace" and located: in main "Text" menu below "Find Previous" item in context menu (right click over selected text) below "Find…" item That function would actually do identical action as "Find…" with exception that it would insert selected text into "Replace with" field instead of "Find".

I also vote for adding the feature of highlighting selected letter (or first letter in case of more characters selected) in glyph browser.

Hi @stokerg, I have researched more on this (for now on Publisher 2.3.1, win 10). And found that sidenotes are corrupted in same way as footnotes. After a lot of experimenting, I have finally figured out how Publisher corrupts the notes, i.e. all foot/sidenotes after newly created endnote: after 1st action first two foot/sidenotes are "corrupted to endnotes" (as I described in initial post) and types of all other foot/sidenotes are changed to types of original foot/sidenotes sequence, i.e. just like if Publisher take all types of notes and applied them two notes further. after every next action a first foot/sidenote immediately after last endnote is corrupted to endnote and types of all other foot/sidenotes are changed to types of original foot/sidenotes sequence, i.e. just like if Publisher take all types of notes and applied them one note further. all foot/sidenotes which are before newly added endnote are untouched By 1st action I mean raising an Edit Text Style dialog by right-click on any paragraph style. By every next action I mean changing of any Text Style parameter, for example font size. My description is surely not understandable, so I attached a document to recreate the bug and see what is happening after actions: Open the document. All footnote numbers in text are styled in bold red, sidenote numbers in text are style in bold cyan and endnote numbers in text are styled in bold green. (initially there are no endnotes in the document, only a character style is prepared) Notice the sequence of types of notes below the line "PUT ENDNOTE HERE." The sequence is: red, red, cyan, cyan, red, cyan, red, cyan, i.e. types of notes are foot, foot, side, side, foot, side, foot side. Put an endnote at end of line "PUT ENDNOTE HERE." After you return to page 1, the green number appears here. All is still ok - all notes following the newly added endnote are still untouched. Now raise a dialog for editing paragraph style H1 (this is a 1st action I have mentioned above). Immediately after the window appears, original footnotes b and c are corrupted to endnotes (their numbers are green now and their text frames are hidden on their original locations) and all types of other foot/sidenotes are changed to following: red, red, cyan, cyan, red, cyan. (last two (red, cyan) from original sequence of types of notes are of course wasted). Try to change any style parameter, for example size (this is a every next action I have mentioned above). Immediately after a change (Edit Text Style window still opened) first foot/side note after last endnote (in this case after endnote 3) is corrupted to endnote (its number is green and its text frame is hidden on its original location) and all types of other foot/sidenotes are changed to following: red, red, cyan, cyan, red. (last one (cyan) from previous sequence of types of notes is of course wasted) Every next action, i.e. change of any Text Style parameter repeats same corruption as described in previous bullet until all notes are corrupted to endnotes, i.e. to green. It is interesting that even clicking Cancel in Edit Text Style dialog acts as action. Hope it helps programmers to find and correct this bug. footnotes sidenotes and endnotes.afpub

In case that document is opened (no matter if changes are saved or not), any of Affinity applications (v2.3.1, win 10) will not restart when in application Settings is changed any parameter which requires a restart (for example changing "Language" or switching "Enable Pointer Support") and user confirms to restart in a dialog box. App only closes an opened document and quit itself. No restart happens. If no document is opened, app quits and restarts as expected.

Next findings about behavior of inserted footnotes, sidenotes and endnotes: It seems that "Number text" of any above mentioned type of note Publisher inserts in different way from cross-references. There is no issue with breaking "Number text" to next line, i.e. that Publisher's inserted "Number text" is not a field. It seems that "Number text" behaves same as if you have typed that text, which is ok. If the "Number text" starts with a space, than it breakes, which is expected. Then when you set its "Number style" to a character style with "No break" set to on, the "Number text" don't breakes - again, expected behavior, no issue. So the issue in this topic seems to be related really only to inserted fields, not notes.

Publisher version 2.3.1 (updated from 2.3.0 via application) on win10 changes language properly. I have no beta installed.

After experimenting with this issue, here are my findings (Publisher 2.3.0 on win10): No matter what special character(s) is(are) used at beginning of cross-reference text. It seems that Publisher ignores any special behavior of all such character(s) in conjunction with previous text (in this case with text before cross referece). So it ignores non-breaking behavior of non-breaking space, it ignores non-breaking behavior of ZWJ character, etc. However when special character(s) are used somewhere after any non-space character, their behavior is as expected. I have discovered same "ignorance" also when using Fields. And it makes sense because inserted cross-reference is actually a field too (from Publisher's view, I think). And inserted Field behaves as a word (or sequence of words), not character, as I understand it. That is why it breaks after any punctuation character or space, but don't breaks immediately after a word. From this point of view this "ignorance" can't be considered as a bug. The bug is that Publisher ignores "No break" setting in character style used for "Style override" in Edit Cross-Reference dialog. It simply don't apply this setting on inserted cross-reference. (When you manually apply "No break" on cross-reference, its behavior is as expected - thas is what @Intuos5 originally reported.) But other settings of character style are applied - for example a text colour. And even consecutive modifying of "No break" setting in character style have no effect - Publisher still do not apply it on cross-reference using this style while changes of other settings in character style are reflected. It is also weird, that when user select a cross-referece on which a character style was applied (using Edit Cross-Reference dialog), this character style is not emphasized in Text Styles window. So user can't quickly determine what style is applied on selected cross-reference.

There is a bug in Affinity Publisher 2.3.0 when it spontaneously damages a footnotes. Until using footnotes only, everything seems to be OK. The problem starts after inserting an endnote. Then when user for example try to modify any paragraph style (even if it has no connection with footnotes or endnotes), Publisher damages all footnotes which are located in order after newly created endnote. It damages them in this way: footnote's references are converted into endnotes references footnote's text frames are hidden on their original locations - pages Footnotes located in order before newly created endnote are untouched. The bug can be reproducced in attached document (all footnotes are created manually, but bug appears also in text imported from Word containing foot and endnotes): Open the document. There are footnotes only. Their references are emphasized in big bold red. Go to spread 2-3 and notice that on page 3 there are two footnotes c and d. Insert an endnote on page 2 somewhere after footnote b but before footnote c. Return view on spread 2-3. You should see big bold green (character style for endnote references) number at location where you inserted an endnote. All is still OK. Now try to edit paragraph style - for example H1 - and keep your attention to bottom of page 3. Either immediately or after changing any paragraph style the problem occurs. Footnote's c and d bodies (text frames) disappear and their references in main text are replaced with numbers 2 and 3 formatted as endnotes references - big bold green. The bug can be reverted only manually - placing cursor to every broken reference and in Notes palette's menu selecting Convert selection to Footnote. It seems to me that when Publisher is doing internal refresh/update of notes and reaches first endnote, that then it processes all further notes as endnotes - as if it forget the type of note it is processing. Bug found in Publisher 2.3.0.2165 on Win10. footnotes and endnotes.afpub

Hi, I am Jan from Czech Republic. I am working for more than 20 years in advertising studio using Adobe soft for all that time. As their pricing politics after CS6 became unacceptable for me, I am still working with CS6 and because of it I have stuck on Mac OS Sierra. I have been thrilled when I heard about Serif's developing a serious alternative also to InDesign (Publisher). And I have bought Affinity V1 as well as V2. Unfortunately Affinity V2 don't support such old Mac OS version I am still forced to run on, so I am unable to run Affinity V2 simultaneously with Adobe CS6 to have good conditions for comparing and testing both apps to get know if Affinity (mainly Publisher) is on such level allowing me to leave Adobe (mainly InDesign). I had to install another HDD with Win10 where I can make my tryouts and tests in Affinity V2. From several testing works I have discovered, that full transition is still too "risky" for me (and partial transition is impossible due to OS incompatibility). However I deeply hope, that moment of my complete transition to Affinity is getting near. I wish Serif team good luck in developing such difficult piece of software (as Affinity apps are) and looking forward to the day I will start use it for serious work.

I am sorry, but the way you described is extremely and uselesly long and unintuitive. It should be natural that when you want to delete a paragraph/character style, which is used somewhere in document, the app (Publisher) should ask you for replacemet style or no style.

For serious work on many projects/documents I agree to use some font manager. But an option similar to InDesign's package – case of having specifically named directory located in same directory as afinity document from which the Publisher would "use" the fonts – would be useful (quicker and easier than whole process with a package in Publisher). Or to have some directory for all Affinity apps where user could store often used fonts for work in all Affinity apps without having to activate them in system.

It would be very useful if Spacing Vertical/Horizontal operation would work with Key Objects. As I don't see it in 2.3 Improvements, I would like to know, if Serif will work on it. And @Mr. Doodlezz, thanks for this thread!