Aleksandar Kovač

I cannot tell exactly how or when, but Search input vanishes from Help menu in Affinity Publisher 1.7.2: After restarting Publisher it is back there... Another fishy/indicative detail to notice is that the question mark for help shortcut is using different font when search input is gone. Or this... search input is here, but shortcut is not in the menu... It might matter or not but I have noticed it vanishing when working with a document that uses table of contents. I cannot claim that there is a clear corellation. Publisher was reset fully a couple of days ago. Anyone else experiencing the same?

1.7.2 Publisher with HP OfficeJet 8100 On High sierra. Resetting Publisher (Holding Control while starting Publisher and selecting all checkboxes) helped.

Still having this problem. OfficeJet Pro 8100, but unfortunately 'playing' with print dialog settings does not help.

(oh, I posted in the wrong forum again, I do beg a pardon, this should be in Publisher Bugs) Affinity Publisher 1.7.2: In a fresh Master page create a text frame and add some text to it. Deselect text frame. Take Pen Tool and make a line on the page. Cut it (Cmnd-X) and paste it in the text frame made before. Go to regular page that uses this Master page. The text is there and the line is there. Everything is nice in the layers palette, too. Go back to Master page, select the pinned line and transform it (scale or rotate is fine) Bug (?) 1: Pinned line that was transformed in master page did not transform in regular page. Go back to Master page. Select that pinned line and cut it out from the text frame. Paste it anywhere on the page. On the regular page's Layer palette, check the Master layer: Bug (?) 2: Non-existing line is still listed in Layers palette but hidden and it cannot be un-hidden. Strangely, the curve is not there on Master page. You can continue adding and removing vector objects homemade in Affinity Publisher into the Master page's text frame like this, and they will be added as hidden entries to Master layer on your regular page.

Oh, you are absolutely right and I feel so silly for not paying attention and posting in wrong browser tab.

(Dear moderator, please move this to Publisher bugs forum... and sorry for posting here by mistake) There is, I believe, an issue regarding linked multi-artboard Designer documents in Publisher. Imagine this situation: Our designer is using Affinity Designer to create graphics for our printed presentation. In one Designer file she creates one artboard per each graphic and saves that file to a shared folder. 30 neatly named artboards in one file. I am laying out the printed presentation in Publisher. Frames are laid out on spreads and Designer file above is linked. I am using her artboard names to chose which artboard goes in which frame in my Publisher document. Everything is nice and clear. Hoity-toity. Now, I did not know that just now our designer moved one little tiny artboard in Affinity Designer's layers palette. By mistake or on purpose, the artboard is not on the top of the palette anymore. It is now at the bottom. No artboard names were touched, no content changed. She saved the file. Went out. On my side, Publisher's assistant warns me politely that linked resource changed... oh and how!... none of the frames laid out so far are right anymore! I can see that each frame in Publisher now contains some other artboard from the linked file and not the artboard I wanted... Uncomfortable. 30 frames to edit?...I realized that layer order, rather than artboard name or some universal identifier is what determines what will be displayed when Designer file is linked. ... My gut feeling is telling me that linking artboards using some UID would be a more rational approach here. That way, artboard's position in layers palette would not matter and even artboard name could change and not totally mess up Publisher document. Or not? I understand that artboard is a container. With that in mind, a user probably wants a certain container in a certain spot in her/his Publisher document and not e.g. 'container 3rd from the top in Layers palette'... or maybe my approach to this is wrong? Would not be the first time...

Thank you Dave for a detailed answer. I think you are right. After getting into this more, I can see the logic. We are using fixed paragraph based styles, and any structural and stylistic change deserves it's own paragraph style. I am quite familiar with indentation level concept from DTP/word processing/coding. Maybe out of habit, I expected that increase/decrease indentation level command (tab/delete or cntrl+shift+] and cntrl+shift+[) will always be reflected in 'bullets and numbering' as 'level' value (numerical value) and not change my first-line indent (distance) and left indent (distance). To me, personally, it should not matter whether a paragraph has a bullet/number/letter/spacing in front when modifying hierarchy/subsecting text -- indentation level was always a structural numerical marker assigned to a paragraph. Actually, in AP, indentation 'level' value will change only if paragraph has bullet type set to anything else but 'no list'. When 'no list' is set, it changes first-line indent (distance) and left indent (distance) in 'Spacing' panel and not indentation level (numerical value) in 'bullets and numbering'. Also, the first-line indent will not be changed by the user-set value for first-line indent, but by 1/2 of defined 'tab stop' value (still have to see why exactly that amount?). BTW, Apple Pages (verified) do not change First line and left indent values when changing paragraph/indentation level of a paragraph whether the paragraph has numbering/bullet set or not. They do change increase indentation level. Then again, Pages is hardly a proper layout app. Thanks again.

Thanks Dave, I would like to think so, too. But, unless I am wrong, the following makes me doubt this is by design: - Pressing tab would add a new tab character in text which is not trivial. (Left indent and first-line indent do not add characters but control distance to the beginning of text). - New tab characters would be controlled by tab values and not indent values (that were originally defined by text style). - Adding tabs negates benefits of having document-wide text styles. (Tabs are characters at the exact position in text, they flow with the text, while indents define geometry of a paragraph form everywhere in the document where this style is applied.) - it is unclear (to me) how tabs would define left indent vs. first-line indent. - indents controlled by tabs and vice versa would be (in my opinion) incoherent from UI standpoint.

A bit old thread, but for convenience of other users: Inserting Zero-Width Space in text where you would like initial words to end and then using it as End character can be useful. You can enter '<ZWSP>' (without quotation marks) in 'end characters' input box. Not ideal, but mostly workable solution.

Set text styles's left indent and apply the style to a paragraph. Position cursor in front of the first letter of a paragraph with left indent set and hit delete. Left indent gets 'deleted' as if it was tabs. (see attached file) I believe this to be a bug since I am unable to increase the indent (which would make this a function by design), text layout is too easy to mess up, ignores text style. deleting left indent AP Beta 1.7.2.442.afpub

The same problem on High Sierra, Affinity Publisher Beta 1.7.2.442. F keys are assigned as keyboard shortcuts for Paragraph styles but the shortcuts are not working. Wired Apple keyboard, with System preferences setting 'Keyboard/Keyboard/Use F1, F2, etc. keys as standard function keys' checked. Note: This post added to this thread here rather than in beta forum, for practicality. If necessary, I will post this to beta, too. Edit: Actually there seems to be more to this. I can add shortcuts that might be counterproductive. E.g. SHIFT+D. With this style shortcut user is able to apply text style to selected text frame but when applying it to a paragraph directly it results in selected paragraph text being replaced with a humble letter D. And it would not be in paragraph style the shortcut was assigned to.

Thank you very much, @Jon p for checking this. Indeed! The problem went away after resetting the application. What I did actually (the morning you posted this suggestion) is to uninstall app support files using AppDelete. After that, application asked be for my licence again, but that was expected. Now, the checkmark works as expected. I will write down your suggestion for similar situation in the future. Thank you.

Axis editing handles are displayed opposite from what is chosen (Publisher v1.7.1). See attached images. When 'Show axis editing handles' is checked -- the handles are not there. When 'Show axis editing handles' is unchecked -- handles are visible. Expected behaviour would be the opposite, of course. Also, one can notice that the grid (gray) is off, not aligned with the handle or page corner. That is another issue, always happening here when non-uniform grids are used, but already reported elsewhere. Perhaps this issue is sorted out in the newest beta? I did not have time to check...

Short followup. This still seems to be problem on my mac on Affinity Publisher 1.7.2.422 Beta. When on OpenGL basic, the grids align properly but doubleclicking on Pages panel does not work. Doubleclicking works in Master pages panel, though. EDIT: Grids are misaligned when using Advanced mode, Standard grid, Uniform unchecked and Second axis edited. Grid misalignment looks like this. (baseline and grids have the same starting point and size, notice how grid handles are off):

Short followup. Changing stroke thickness from context toolbar/numerical input box still gets Mac stuck on Photo 1.7.2.147 Beta, and Affinity Publisher 1.7.2.422 Beta. Changing between OpenGL and OpenGL Basic rendering does not improve the problem.

I can confirm this behaviour, too. It happens whenever the 'flyout' stroke ui is used. I.e. from the context bar, when using stroke ui by clicking on stroke thickness in Appearance panel. This does not happen when stroke is defined via Stroke panel/palette user activates through Studio menu. The same in Affinity Publisher. Affinity Designer 1.7.1 on iMac late 2009, High Sierra

To confirm, in part, @lowerider experience. (AD 1.7.0.12) Attached are 2 pdfs. The same preset is chosen (PDF/X-1a:2003) and then 'Include printer marks' checked. No other options touched. PDF from Designer persona export includes bleed, while one from Export persona does not. Artboard1 export persona.pdf Artboard1 designer persona.pdf EDIT: Pardon! This is Windows beta thread while I am experiencing the problem on Mac beta. I do not have Win machine to ascertain whether this happens on Win, too.

@MEB, @>|< Exactly! Dragged object should stay in the group - that is my feeling, too. Thank you for replies.

Designer v1.7.0.12 Interesting conundrum... Not entirely sure if this is a bug in Designer or in my brain. Let's eliminate one out of two possibilities this way: Make a new file with an artboard. Add 2 objects onto the artboard. E.g. Two squares. Group them. Select one object of that group via layers palette, or by clicking through to the object. Drag the object off the artboard. Take a look at the layers palette. The object that is outside artboard is not in the group anymore. Leaving artboard = leaving group. OK? Now try this: Undo the drag above and drag your objects far apart in the group but make sure that both objects are still on the artboard. Now select the group and position it so that one object is off the artboard. Now, the group is intact. Leaving artboard honours grouping. There is inconsistence, right? To be honest, I am not sure which behavior is 'right' but I think that explicit groups should be honoured. Surely, dragging one object off the artboard can be interpreted as user's intent to take it out of the group but that would not be right since groups are not artboard-dependent entities and this behaviour could introduce some pain to well structured work files.

I am not sure what to attribute this peculiarity to... Let me explain. Please, see attached images. Notice that when tabular figures are chosen in 'Typography' panel, line breaks occur in the middle of a word. While, when figures are set to 'default', line breaks are as expected. This is true even when text does not contain numbers/figures. The same occurs in Affinity Designer but it does not occur in other layout software. Based on the fonts I have, I can see this behavior only with 'Work Sans' font (https://github.com/weiweihuanghuang/Work-Sans). Work Sans font has been behaving reliably so far. So, I don't know where this behavior is coming from. The font or the software? Affinity Publisher Beta 1.7.0.238 on iMac late 2009, High Sierra.

Hi Sean P, Thank You It is High Sierra. I am sending you some examples attached. On 'Dropcaps' you can see both sizes. Again, I do not consider this to be a problem, rather an observation to be shared with you girls & guys on the code/magic-weaving side that might be indicative (or not) of some coding inconsistency (or not). Let me know if I should provide further info.

Open 'Text Edit Style' dialog. On its righthand side, click down the setting groups list: Flow, Baseline Grid, Hyphenation, Drop Caps, Initial Words, Decorations. While doing the above, on the righthand side pay attention to checkboxes being displayed bigger, smaller, bigger... Not a big deal, really... But since the perfection is in details, worth noting. Thank you for your hard work. Affinity Publisher Beta 1.7.0.227. on Mac

Thank You Chris_K.

Consider this scenario: Make a file with several, not-facing pages e.g. 100*100mm. Change the first page dimensions: Select the first page, click on 'Spread Setup...' select 'current spread' radio-button and enter e.g. 120*100mm. Press OK. The spread is resized as expected. Now, 'remember' you actually wanted to resize all of the spreads in this publication. Not just the first one. No problem. Back to 'Spread Setup...', select 'All spreads' radio-button, glance at the dimension input... alright... it says 120*100mm. Press 'OK' button and expect all spreads to be resized to 120*100mm. Scratch your head. They did not. Now, if user explicitly reenters the same dimensions that are already set in input boxes, the spreads will get resized. Therefore, it seems that Publisher is waiting for dimension input box edit in order to apply the change, but ignores the user input user commited on radio boxes. Perhaps an improvement would consider change/edit in radio boxes as user input/intent, too. Affinity Publisher Beta 1.7.0.206. on Mac

Switching OpenGL display modes in Preferences.../Performance/Display results in inconsistent behaviour, depending on the mode selected. When 'OpenGL' is selected: - Grid display is unreliable. Grid origin seemingly moves depending on zoom level. Grid snapping is working well. (bug?) - Doubleclicking a page in pages palette 'moves' user to that page. (as expected) When 'OpenGL (basic)' is selected: - Grid display is proper. (as expected) - 'Go to spread' contextual menu command does not work. (bug?) - Doubleclicking a page in page palette doesn't do anything. (bug?) Affinity Publisher Beta 1.7.0.206 iMac (27-inch, Late 2009), macOS High Sierra, ATI Radeon HD 4850