A_B_C

If the space characters are present in a font, Affinity Publisher seems to use the metrics information from the font. I just checked this with a few examples yesterday. Otherwise, Publisher turns to fallback values. As @Wosven said earlier in this thread, most fonts do not support all the spaces in General Punctuation (U+2000..206F), but some do. So to avoid making methodically misleading comparisons, one would have to check first whether the spaces in question are present in a font.

Probably related to this bug:

This is a strange bug. The selection marquee, when used across pages or spreads, doesn’t put the focus on the relevant page. Starting the drag from inside the page doesn’t change the odd behavior. Simplest possible file attached. MacBook Pro 16'' (2019), macOS Catalina 10.15.7 (19H1323), APub 1.10.1 MAS Version Selection-Across-Pages-Bug.mov Selection-Across-Pages-Bug.afpub

This is lovely. At first sight, I wouldn’t have thought that this is an existing building, but it is. 😊

Eventually, we may hope that a wider and more consistent implementation of the STAT (Style Attributes) table (OpenType 1.8, September 2016), both in font files and end-user applications, will resolve most of these issues. The information that can be gathered from this table should allow the creation of better and more unified user experiences with modern font families: https://docs.microsoft.com/en-us/typography/opentype/spec/stat

😁

Yes, please. Follow the system-wide standard on macOS. Would be lovely. 😊 I have been missing this option sorely these days. 😥

I doubt you will be lucky with that, given the current implementation of dashed lines. I fear that’s not a simple export bug, I rather suspect it’s immanent to the current approach towards handling dashed lines. I hope there will be some updates to the entire dashed-line mechanism in the future (version 2.0?). Tables with dashed borders. Difficult. 😥 Tables.mov

Thank you for researching this further. 🙂 Oh, and thanks for reminding me of the built-in calculator. Almost had forgot about this. 😀

Hi there, I searched the forum, but there are either too many or too few results for whatever combination of search terms I tried. So this may have been already be discussed, and I’d be happy to get some pointers. This is the issue: when you use Spread Setup > Scaling > Objects will: Rescale and rescale your spread, the baseline grid is not rescaled as well. See the following example. Going from A4 to A3, for instance, effectively changes the text size, but not the spacing of the baseline grid. Which makes the scaling option somewhat useless for documents that rely on baseline grids. Or I should say, you will have to do the math yourself and readjust. 🙂 Thank you for taking a look, Alex

Nice workaround, Lukáš. Thank you. And of course, I agree with your objection against the title of my initial post. 😀

Thank goodness that there are a few other users who feel the same. This is such an essential feature, and I’m just sorry that I haven’t searched the forum more extensively before posting my own feature request. 🥺 I cannot agree more. 😀

Walt, that’s why I left it to the developers to find a pleasant solution. “No break” could be indicated by opening and closing brackets of some sort, by underlines, by highlights. There are many options available. And of course, I know that soft-hyphen-trick, but why should I insert a semantically nonsensical character when we have a no-break option? I would love to do away with this unattractive workaround. Lukáš, I know that you can search for virtually all character attributes, but that doesn’t help in practice. When you manually correct long paragraphs of flush-left, ragged-right typesetting (you know, we are talking about the difference between “Rauhsatz” and true “Flattersatz” here), it doesn’t help that you can search for no-break characters, for you will have to see all the substrings of your text where “No break” is applied, at once. Otherwise, it is impossible to properly balance the line lenghts for the entire paragraph and find the best compromise. I can only speak from practical experience.

Hi there, currently, a couple of special characters, such as space, soft hyphen or various break characters, are displayed when the user selects Text > Show Special Characters. But as far as I can see, there is no indication for whether the No break property is applied to a selection of text or not. However, being able to determine whether this property is applied or not is of vital importance as soon as you try to make manual adjustments to paragraph typesetting. So please add (a) special character(s) of some sort that indicates the presence of No break in a selection of text. Furthermore, please allow us to assign a keyboard shortcut to this property. Thank you, Alex 🙂

Lovely scenes, full of atmosphere! Thank you for sharing … 😀

I vaguely remember someone had said something to that effect before. 😉

Ah, thank you. Didn’t know that. 🙂

Is that memory leak still leaking, @Gabe? It seems I can get studio presets to work through the System Preferences workaround, but they will refuse to do their duty unless I manually selected one of the studio presets at least one time from the View menu. 🤔 MacBook Pro 16'' 2019, macOS Catalina 10.15.7

You know, Jon, that would be awesome. Think of the following use scenario. I’m currently writing a documentation for a corporate font we’ve been developing over the last year, and I decided to use Publisher for that purpose. Of course, our documentation has to include glyph tables. Before submitting the font, we got the request to insert some additional glyphs at certain places in the font, thereby getting our glyph indices shifted. You can easily imagine how difficult it is to update any index-based glyph tables in Publisher. You have to copy and paste row-wise, starting from the end of the table, until you reach the cell where to insert the new glyph. Not sure if data merge would help in this case, as there are lots of unencoded glyphs in the font that are usually substituted in by OpenType features and entered into my table from the Glyph Browser of Publisher. For all of these difficulties, I made the suggestion in the other thread. It would be great, if you could do better than most of the other DTP apps out there. Thank you! 😀

Nobody else here trying to copy and paste within tables? 🥺

Thank you for checking this out. It’s different here, but either result seems to be undesirable. To my mind, the table format should be automatically updated when you change the name of a paragraph style, not lose the connection to the style. 🙂

Thank you, Seneca! I hadn’t noticed this bug until February this year, and when @SPaceBar asked me to test, I just updated this thread. Didn’t know that this bug is already known. 🙂

I’m sorry, I don’t understand, Seneca. I am well aware that I can selectively apply paragraph styles to particular cells, but that doesn’t invalidate my observation. What you missed to test in your video is using the Text Styles Panel to rename the style you applied to certain cells of your table. Try this, and you will see that your paragraph style assignments saved with the table format are lost. I hope it’s clear what I am after. 🙂 Style-is-lost.mov

Hi there, we’ve had some discussion about unexpected behaviour when copying and pasting data from selected table cells to other selected table cells in Affinity Publisher. Please have a look at the discussion in this thread: https://forum.affinity.serif.com/index.php?/topic/141854-how-to-shift-data-within-table/ To my mind, the current behaviour of the application is unfortunate. I would suggest to change it according to the following rule: Make the tab key sequence the natural order for pasting cell contents from the clipboard to selected cells. Currently, we can step through an entire table by repeatedly pressing the tab key. After having placed the cursor in the top left cell of a table, we will never have to use a different key in order to reach each cell of the table, regardless of the ways in which cells are merged. That provides a natural linear order for any subset of cells belonging to a table. Now, suppose you select m cells c_1, …, c_m, adjacent or not, merged cells counted as a single cell, from a table and copy the cell contents to the clipboard. Then it seems natural to assume that if you select a different set of n cells p_1, …, p_n and paste the clipboard contents, the selected cells will be filled with the clipboard contents according to some natural ordering. And the most natural ordering seems to be the tab ordering mentioned earlier. That is, if < is the linear tab ordering, and m = n as well as c_1 < c_2 < … < c_m and p_1 < p_2 < … < p_n are true, you would expect that c_i gets pasted to p_i for i = 1, …, m. But that is currently not the case. Rather, we see the following behavior, which is not only unexpected, but rather useless in practice (my use of the keyboard shortcuts Cmd+C and Cmd+V is not shown in the video): Strange.mov Now, in the formal description above, there is still the possibility of m ≠ n, that is, m < n or n < m. But these cases do not really present a problem. In the first case, that is, when the copied cell sequence c_1, …, c_m is shorter than the target sequence p_1, …, p_m, …, p_n, the cells p_(m+1), …, p_n can just be left unchanged when the clipboard contents are pasted. In the second case, when the copied cell sequence c_1, …, c_n, …, c_m is longer than the target sequence p_1, …, p_n, the cells c_(n+1), …, c_m can just be left unpasted. If no cell is selected for pasting, either a new table could be created, or pasting could be declared to be impossible, depending on the developers’ preference. To sum up, I can really see no point in preserving the current behavior. If I actually wanted to achieve what is shown in the second part of my video above, I could always grow the table manually before pasting the contents of the red cells and make an appropriate target selection according to the method outlined in this post. That would be much more logical than the way things are set up at the moment. Thank you for considering. 🙂 Alex

Hi, what is the latest beta? I guess you mean the App Store version (1.9.3), correct? If so, here is a rather self-explanatory video that should demonstrate the problem. First, I create a paragraph style from cell contents. Secondly, I create a table style and apply the paragraph style to all cells of the table. You can see that no style is selected in the “Edit Table Format” dialog, because the style is not yet applied to all table cells. Which is right, in this case. After closing the dialog, I change the name of the text style in the “Text Styles” panel. Then I reapply the table style to the table. Result: All text formatting is lost, and when I reopen the “Edit Table Format” dialog, no style is selected again. Which is wrong. Rather, the created paragraph style should be selected there and appear under its new name. Hope you can reproduce that. 🙂 Alex Table-Text-Styles-Issue.mov