garrettm30

I made a video to explain the issue, but I think it might be sufficient to explain with a simple image. In the attached sample document, a running header based on a character style has included the end of story symbol from the source text, which then results in the fallacy of a single text frame having two end of story symbols. End of Story in Field.afpub In this case, the extra end of story symbol seems to be treated like a carriage return, which broke the “Align Bottom” vertical alignment of the frame. In my document, I was able to get around the problem by removing the relevant character style from the end of story character. I thought it was odd that the end of story symbol could have any formatting at all, but I think that is probably on purpose for technical reasons. However, from the users’ perspective, I don’t consider it to be part of the text, because I didn’t add it, I can’t delete it or copy and paste it. Every story has exactly one (I incorrectly said “every text frame” in the video). Therefore, whatever the technical reason for it to have formatting values, it should not be included in running headers, because it can cause confusion, such as here when I was trying to troubleshoot why my “Align Bottom” setting was not working for what should have been a single line of text. I wonder whether I ever would have figured it out if I didn’t use the Show Special Characters setting. If it helps anybody to see a video demo, here it is: End of Story in Field.mp4 Tested on macOS 14.3.1 with Publisher 2.4.2 End of Story in Field.afpub

I am generally excited about this feature. One specific feedback: I would like to pick for each pressure node whether it is a sharp, immediate transition or smooth transition, such as in this mockup: In this mockup, the sharp version is the current behavior, while I faked the smooth behavior by expanding the curve and then converting the nodes at the peaks to be smart curves.

I don’t know much about how symlinks and hard links are used in Windows. I have always understood (perhaps not entirely accurately?) that Mac aliases are the analog to shortcuts in Windows. Macs support both symlinks and hard links, which operate at the Unix level, as well as aliases, which work higher up at the Finder level and so come with conveniences but do not always work as expected for some, usually the more “techie,” purposes. This is definitely a tangent, so I’ll leave it here, but if anyone is curious, there are various articles explaining the difference among aliases, symlinks, and hard links on Mac, such as this: https://www.lifewire.com/aliases-symbolic-links-hard-links-mac-2260189

You’re right: that is the purpose of these forums. At this point, I believe the message has been received by Serif/Canva. I’m not sure if you noticed the post a few above your first in this thread, but it appears Serif does have in mind to add variable font support, as they recently said in their second email concerning the Canva acquisition: As a related matter, I noticed the tag “rmap-26” added to this and many other threads related to variable font support. Is that new? I ave just been overlooking it until now, but this is the first I realized it is there. What is “rmap”? Could it be some indication that Serif is publicly acknowledging something of a road map again?

These two days have felt a little like an emotional roller coaster. It’s a little embarrassing to admit that the choices a software company has made could have that effect on some of us, but I guess it goes to show how we felt about it before, and how many of us have invested a lot of time not only in using it but also in participating with the users on this forum. Today’s email from Serif/Canva has helped change my mood. Yesterday I was contemplating a wait-and-see approach with a very pessimistic feeling of keeping an eye on the emergency exits. Today I am still in a wait-and-see approach, but it has shifted to a more cautiously optimistic outlook. It seems the general mindset among the posters who have contributed to this discussion since the latest email is still rather discouraged. I admit that now we are on edge and fearing the worst, but supposing that they truly do intend to maintain Affinity as a stand-alone product always with a perpetual license option, and the future proves that to be true, I do not know how they could say anything different than what they have not said, so I am willing to give it a chance. Truly, I want it to work out since I like Affinity so well. Consider that yesterday’s statement was worded so carefully to make no promises other than that we can continue to use what we already bought with unspecific promises about updates in the version 2 cycle. There was no promise beyond that. It practically read like a promise that all would change after that. However, today, we have a promise that it will go beyond 2.0. The copy of the email says this: “We are committed to continue to offer perpetual licenses in the future.” Note that “in the future,” is there unqualified, so we could read it just as more PR to make us think they hear us all while intending “in the future” to mean for a set period of time. But in the infographic, we instead see these words: “Perpetual licenses will always be offered and we will always price Affinity fairly and affordably.” Notice the double use of “always.” That’s a big word, and remember that statements such as these are crafted very carefully. I know that we may be inclined to be skeptical even here, but at the very least, making a promise such as that means they are betting the goodwill and continued loyalty on their customers on their ability to keep that statement, because now if they ever take away perpetual license, they will have broken their word. And if they really mean it, what could they have said any different to make us feel better? I don’t know, so I think for now I will take them at their word, which is fair. And of course, we will hold them to their word, which also is fair. That being the case, I am eager to wait and see what this might mean for the promised additional development resources. For example, variable fonts were mentioned in the examples of features that they want to bring in, and unless I have forgotten, that is the first time they have ever indicated they do hope to add it to the feature list. I am excited for that. Quick question: formerly we were used to the name Serif as the company and Affinity as the product, but the current communication seems to keep referring to Affinity as the team behind the product. Does the name “Serif” as such still have any meaning or continue to exist?

If only we could still know that. The way Serif carefully answered the question regarding the possibility of moving to a subscription model, I do doubt that there ever will be a version 3 for purchase. I think the point is that Serif already did weigh the choice, that is, whether to sell or not. As I now understand it, since they chose to sell, the business model is not really their choice anymore. By the way, future posters may want to consider the other thread going about this issue:

Rather than write all the things I thought I might say about my hopes for the best but my fears for the worst, let me just quote: “I have a bad feeling about this.”

And many thanks to you as well as @MikeTO for bringing this bug forward. This is one of the bugs I have encountered from time to time but didn’t have a chance to report because I just had to get my work done.

It’s been too long since I used MS Word to any significant degree, so I don’t know how much has changed (I have the impression they keep reselling basically the same thing). But as compared to how MS Word used to work, I used to get annoyed when MS Word would try to be “help” me in various ways I didn’t ask for, such as selecting, copying, and pasting something not quite what I selected and copied. I felt like I had to fight it to get what I actually wanted more often than it “fixed” what I selected that did not actually mean to select.

I would prefer something of the sort. New documents would default to export to the source folder, but they would remember the last export folder so subsequent exports of that document would default to that location.

The “proper” spacing of ellipsis is variable according to the house style. I regularly use the ellipsis character, and for all of my documents I pass them through a series of find and replace operations that includes changing three periods to an ellipsis. If our house style were to use looser ellipses, then instead of replacing the periods with ellipses, I would replace them with three periods separated by whatever special space achieves the look I am going for, such has the narrow non-breaking space or the hair space, as most of the special spaces have the non-breaking characteristic in Affinity (and a few others). If you like the spacing of three periods back to back, then I recommend adding the character called “word joiner” (U+2060) between the periods, as it will cause them to stick together and yet they will be spaced the same as though nothing were there. The approach to define a character style with the no-break attribute works fine too, but it is not my preferred option because sometimes an ellipsis might also need another character style applied, which adds additional complications. Not the end of the world, but my preference is to keep the text and the style separate, and using these explicit characters that define your intentions will work no matter what style is applied. Note that the word joiner (U+2060) is not one of the special characters available in Affinity’s insert text menu, so you will have to find it using whatever special character method is available on your system, such as the “Show Emojis & Symbols” in the keyboard layout menu on Mac. Not to patronize you as though you don’t already know how to do that, but in case you (or later readers) do not, here is an “ellipsis” of three periods separated by the word joiner so you can just copy and paste it and save it however you manage your find and replace routines: .⁠.⁠. (Just double check that the forum hasn’t done something weird with the word joiner spaces. Edited to add: now that I have posted and am able to test, here on Safari on my mac, the word joiners are in fact retained as hoped when I copy from the thread and paste into Affinity.)

Thank you for spelling it out. And obviously, since Dan C was able to find some issues, that’s all that really matters. #101D64 is not a decimal equivalent, for D is not a numeral in the decimal system. It is still some hexadecimal value of some sort, but what? Also interesting, when I tried to follow your recipe (including using #2B48FF), the value changed for me too, but rather than #101D64 as you reported, for me it changed to #111C64. There is definitely something going wrong, but now the developers have been alerted. As a fellow user, I thank you for helping make this software better.

I’m struggling to see what you mean—not that it matters whether I can see it, since this is a bug report. But it might be clearer if you give a recipe or a demo video. Maybe part of the reason I am having trouble is following what you mean by “Hex values in Base 16,” since hex (short for hexadecimal) is by very definition base 16, so hex values should always be base 16. Also, I don’t see percentages in either view, but rather either the value expressed as decimal (from 0 to 255 in 8-bit color) or as hexadecimal (from 0 to FF in hexadecimal in 8-bit color). I do notice that the wheel view does show HSL (rather than RGB) in decimal on the bottom left and of course RGB as hexadecimal on the right.

I typically go for 72dpi out of tradition, but just to be clear, the formal definition of CSS is 96 pixels equals 1 inch (see MDN here for a good reference on units). To see it in practice, I whipped up this very simple demo on CodePen where I have four boxes where the width for each is defined according to different units. You see that on the web, browsers treat 1 inch and 96 pixels to be equivalent. https://codepen.io/garrettm30/pen/GRLjEJb

Thanks for looking into it. I am fine with considering it a feature request. But as to the question of representing non-marking glyphs, I would point out that the soft hyphen is also visible and yet it currently is distinguished in this way. Also, some software calls the equivalent feature “Show invisible characters,” and in that case perhaps one could argue that the non-breaking aspect of the non-breaking hyphen is not visibly distinguished, but as Serif wisely named the feature “Show Special Characters,” it seems like distinguishing a special-case hyphen from the regular variety would not be any stretch to the paradigm. My suggestion would be to follow the same symbol used spacesa regular space is indicated with a dot and a non-breaking space adds to the dot a circumflex accent above it, and several of the other non-breaking spaces also use some variant on the circumflex. Therefore, my first thought would be to apply the circumflex above the visible hyphen. That seems to be consistent, but my preference here is not strong: any symbol at all would be enough for me.

Thank you for that information, and by the way, I also appreciated the chart you made here: I haven’t gone to the great trouble to document all that you did, but if it is accurate and I am not mistaken, then non-breaking hyphen is the only special character available from the insert submenu that is not indicated with Show Special Characters. That would argue that perhaps this is just a simple oversight and hopefully easy to fix.

I would like to request that the non-breaking hyphen (U+2011, the character inserted by that name in the Text->Insert->Hyphens and dashes menu) be indicated as a special character when “Show Special Characters” is enabled. It is not every document that I use them, but I think it is the majority of them. For example, as my work is in French, I use them: In the French versions of B.C. and A.D. for eras: av. J.‑C. and apr. J.‑C., where the abbreviation should not be broken. In conjugations involving the “T euphonique” such as fera-t-il where the possible break should be preferred after the first hyphen rather than the second. As a personal preference, since I deal with Christian texts, in verse range references when they fall at the end of a paragraph, for example, (Matthieu 19.6-9). where I want to assure that -9). is not alone on a line by itself at the end of a paragraph. Since the difference with the regular hyphen and non-breaking hyphen is not visible, I keep second-guessing myself as to whether I have already fixed a given text, and the only way I know to check is to copy and paste into the app UnicodeChecker or just to reinsert it to make sure even if it was already done. I always keep Show Special Characters turned on, so I can quickly confirm what type of space I have, and it would be nice if I could do the same with hyphens (in addition to soft hyphens, which are already indicated this way).

If you mean something like kerning tables, those things have been in fonts for a long time. I don’t know much about the inner working of fonts, so I am probably missing something, but I don’t think OpenType gives us anything new in terms of justification.

I’m trying to think how OpenType fonts can have any bearing on justification quality. Could you help me understand? In your recent comparison that you posted, those were examples of healthy characters per line count that is close to the ideal, such as you would see in a single column novel layout. In those cases, justification has more space to work out and tends to be better even on a line composer. There are still occasions where a paragraph composer would be advantageous, such as certain no-break sequences that have to be worked around, either automatically or manually, but yes, generally, a paragraph composer is of lesser importance in those contexts. In narrower column contexts, such as various multi-column layouts, acceptable justification is a greater challenge, and that is where a multiline composer could be a time saver.

Agreed. I accidentally misspelled the name of one of my query states and now it bugs me. I tried to figure out how to rename it, but it appears it is not currently possible, without just recreating it. That’s probably what I’ll do since this one was not very complex.

As stated, that is still to come in a future update:

I have been asking for this for a long time (by which I mean to say that I eagerly desire this feature; I do not mean to disparage the other progress Serif has made in many other welcome areas). On smaller projects (those of fewer pages), I have taken to manually managing line breaks on a line-by-line basis in Publisher, and I am starting to feel that the end results are better than the paragraph composer in InDesign. But that can take hours for something like a short novel, and for the larger projects, I still go back to InDesign—and I complain about it the whole way. It is amazing how archaic InDesign feels now.

I am writing to confirm that the issue I originally reported (clipped text at large UI) seems to be resolved in 2256.

In this context, it is mostly just a page load issue: one 46KB file for five faces. Font loading really does affect page load speed, and page load speed unfortunately does affect the number of visitors, especially as it is one of the weighted factors in Google search ranks. This point does not have much to do with why it should be in Publisher.

I am on Safari, and I did download the font file that it grabbed to test it out. It is indeed the variable version.