garrettm30

It seems this particular need could be solved if “GREP styles,” a rather common feature request, were ever implemented. In that case, it would still use custom character styles like Mike suggested, but it would be implicit in the paragraph style rather than manually applied.

I would welcome that. Sometimes I have the problem where an issue is on a master page rather than a real page. For example, in one of my documents, my master page has a text frame that uses a text field: “Leçon <Running Header>,” and the placeholder overflows the frame. This becomes, for example, “Leçon 12” on an actual page, which has no trouble fitting the space. Since I never export a master page, this suggestion could help avoid that.

That is generally true, but not always. For example, the first beta to 2.0.0 came with this official recommendation (emphasis in original, source😞 I think I have seen that a few times (I’m not sure of it), but it would mostly be true only of the sub-point updates. To best be sure, watch the official recommendation for the specific beta in question. ------------- Although I must preface what I am about to say that it may not be advised, I do want to clarify that it is not strictly true that documents saved in betas cannot be opened with previous stable versions. In my experience, there is usually (if you want to chance it) compatibility between the sub-point updates. For example, the current release Publisher 2.5.3 can open a document saved by beta 2.5.5. [Side note: I had to double-check on those numbers since it looks like 2.5.4 is missing.] I would say that the definitive answer is the big warning that comes up when you try to open a document from a release version in a beta: ------------- Ah, there’s the rub. I often open up a beta and try a few things for a few minutes, but I keep my main work on the release versions. And, yes, it does result in bugs that I could have caught in beta that instead I catch when I start doing real work. For example, a real variable fonts showstopper issue (for me) that I only discovered as soon as variable fonts hit release, leading to the comment: It’s a catch-22 situation, and I don’t have an answer for it. If I am about to work on a document that does not matter too much, then often I will try it in a beta just to have an opportunity to catch something, but how often does that really happen?

I kept pursuing this, and now I can report back that I now have the tablet functioning with pressure sensitivity in Affinity. It had to do with getting the driver properly configured, so the problem had nothing to do with Affinity. Pressure also hadn’t been working even in the Huion-supplied “PenPressureTest” app. @Nick B. I don’t know if what I did could work for you, since your tablet uses a newer driver than mine and your OS is older than mine (I am on macOS 14.5 Sonoma). I ended up uninstalling everything and then tried to follow as nearly as possible the installation instructions at the Huion support site. They didn’t match my OS, but they did point me in the right direction. For me, I think it was that I probably not have the macOS security settings configured to allow the necessary helper app. These are the places in the System Settings (for you, System Preferences) that need to be active. Login Items -> Shenzhen Huion Animation Technology Privacy & Security -> Input Monitoring -> TabletDriver Privacy & Security -> Accessibility -> TabletDriver For me, I found it helpful to test pressure with the included PenPressureTest app inside the HuionDriver folder in the Applications folder, just to remove Affinity from the equation until I could be sure that the tablet itself is working properly with pressure. Once I did that, I had no trouble going back to Affinity and activating pressure.

I am unaware of a style guide that uses en dash instead of hyphen in that case, but I don’t do my official proofreading in English, so I wouldn’t be surprised if you could find one. But I would tend to agree with Grammarly, as “well-used” in that case would be an example of a syntactic hyphen, where together the words act as a modifier, such as adjectivally, on another word. My style guide in Antidote explains it this way: Just for fun: in French, there are occasions where compound words can have both a hyphen and an en dash. These would be in a “nom propre surcomposé,” which I guess would be double compound proper nouns. This is a compound word where one of the elements itself is already a compound. For example, I studied French in the Saguenay–Lac-Saint-Jean region of Québec, which is a region around the Saint-Jean Lake and the Saguenay River that flows from it. Proper French typography is to use a dash between the two separate elements. ----- Back to the subject at hand, I don’t have a strong preference, but I would treat both hyphenated words and words separated by dashes as more than one word for the purposes of word count, because I would not normally be concerned with grammatical function of the words but rather copy length when needing a word count. Either way you slice it, it would get messy to try to get Affinity to get an accurate count of grammatical words that takes compounds into account, because English has many open compound words (high school, test tube, party dress, circuit panel, coat hanger) in addition to hyphenated compounds (fortune-teller, father-in-law, laid-back) and closed compounds (firefighter, cheesecake, healthcare). Then there is the difficulty of distinguishing, for example, between the proper noun “White House” and the common noun with an adjective “white house”; grammatically, the former is a compound word and the latter is two words.

Just out of curiosity, when you tried it with other apps, did you find that pressure sensitivity does work?

As a guess, I would say it has to do with Affinity not reading the pressure values sent by the pen. I have an old Huion 610Pro, and I don’t have any luck getting pressure to properly work in Affinity. When I turn on pressure sensitivity in Affinity, the lines paint at a near-minimum size. Maybe in your case the minimum is so small it is effectively nothing at all. Possibly when you tried it before, you were using it in a mode without pressure sensitivity. Try turning it off to see if you can at least use it without pressure.

This would personally be my preferred approach (don’t forget “non-exportable”). I already leave off-canvas notes along the text where it is needed. I don’t see a separate notes panel as necessarily bad or useless, but I think it might risk being overlooked in my way of working: I would make complex notes about a document, come back later, and forget to even open the notes panel. And I often benefit from notes sticking with the part of the document I am leaving the note about. For such cases, sometimes I even pin the off-canvas note to some relevant text. I don’t think a separate notes panel would be the best solution for such needs. And it might need to be mentioned that the terminology “Notes panel” is already taken, where it refers to the panel that manages footnotes, endnotes, and sidenotes.

That is a good suggestion, but I think one likely reason it is not supported here is the lack of a multiline text composer. Such a “prevent runt” feature would essentially cause the last full line to break earlier than it otherwise would, leading to ugly justification that the average user would complain about. InDesign can handle something like that because it uses a multiline composer (“Adobe Paragraph Composer”) that calculates justification on a paragraph level rather than line-by-line. If they did add such a feature, I may still use it, since I already tweak justification line by line to smooth out Publisher’s rough results. But you are right that “GREP styles” could be used to achieve the same thing, as well as many more. As Walt has also pointed out, for our purposes we may consider GREP and regular expressions to be the same thing, though some have argued that InDesign has misused the term GREP when it is only the RE part that is in use in this context. Publisher does use a different flavor of regular expressions, but generally I have found it to be more modern and capable compared to the regex used in InDesign’s GREP find and replace. That said, InDesign’s use of GREP styles is far more capable than Publisher’s—since it doesn’t exist!

A quick test seems to confirm that the issue as I originally reported it is resolved for me in Publisher beta build 2516.

The option “Keep with next [1] lines” is probably the main cause. If you have a large number of those paragraphs back to back, then the only possible place to break will be in the middle of a paragraph, and sometimes that means breaking earlier than necessary. I do not recommend you use that setting for body paragraphs, though it is very helpful with things such as headings that you do not want to be separated from the body paragraphs that would follow. For body paragraphs, I recommend you set it to 0.

The issue is that Affinity currently is not able to link the weight axis of variable fonts to the “Font weight” attribute in Publisher. I first noticed this in connection with the font weight attribute in text styles and reported it, but later in the thread I also realized the (apparently) same problem also means that the bold button in the contextual menu does not work. This is evidently true for all variable fonts: the bold button, its associated keyboard shortcut, and the font-weight attribute do not work for any variable fonts. It has been logged as a bug.

That appears related to keyboard input. If you arrow up, it will change which one is highlighted, and pressing return will select whatever is currently highlighted.

The slight refactoring of the Text Style Editor panel has surfaced a new issue for me, where I set the leading to a paragraph style, and then later I found out that it was not changed. It happened to me more than once, where I was sure I had changed the leading of a style and then discovered it still had the previous value. I have been able to determine what is happening: text_style_revert.mp4 This could potentially be true of other input fields as well, but I have not found any yet. For example, the other input fields on the Paragraph Spacing section, such as indents, do not have the same problem because they do not update the document view immediately, but only when they lose focus. I cannot check 2.4 without going to the trouble of reinstalling, but I still have Publisher 1.10 to compare, and there, the leading input works as the other inputs do presently: the document in the background only updates once the leading input loses focus. Ideally, all of the inputs would both update the view and make the change even without changing focus. But if that is hard to achieve or causes complications, then at the least all of the inputs should behave the same way, and certainly there should be no appearance that a change has been made if it has not actually been made. iMac 2019, macOS 14.5, Publisher 2.5.0

That does help make me feel a little better. I have Publisher 1.10 for an unrelated reason, and I notice that there all of the panels are in the “Studio” submenu, and selecting one pops up the panel outside of what I now know to be the proper studio, so that perhaps led me to believe that the Studio submenu was a list of studios.