garrettm30

When I was looking at the “style settings” readout in the “Edit Text Styles” dialog for the default character style Strong, I noticed several EPUB attributes: However, I can’t find anywhere in the Edit Text Styles dialog where these attributes may be controlled. My expectation would be that anything in that readout should be able to be controlled in the Edit Text Styles dialog. Or have I just missed it? Or is this an accidental inclusion for a feature not yet available? Because I am not aware of how to export as EPUB. Publisher 2.6.0, on Intel macOS 15.3.1

In the test file you sent, for some reason you have a local font-weight override that cancels the font-weight value of the paragraph styles: If I select all, clear overrides (Text->Reapply Text Styles), then it works as expected. Just a guess, but I suspect you did not intend to apply a font-weight override, but it quite possibly came if you had previously used a variable font on that text. Here is your file back with that one change. test-without-overrides.afpub Another way to demonstrate this bug is simple: try to apply the default "Strong" character style to text with a variable font. Nothing happens. Here is a video demonstration where I go into more detail in case anyone cares. character-styles-variable-fonts.mp4

It looks like you are thinking of something else. If I have followed what you are saying, you had to explicitly define the font family again in the child style and pick a font style. What should happen (following what works in regular, i.e. non variable, fonts) is that you set the font family in the parent, and in the child style, only alter the font weight without changing the font family or font style at all. If I understand, this is what you defined: Base: Font Family: Roboto Flex Font Style: Regular Heading 1: Parent: Base Font Family: Roboto Flex Font Style: Extra Light This is what should be possible, and indeed is how it works with non-variable fonts, but it does not work with variable fonts: Base: Font Family: Roboto Flex Font Style: Regular Heading 1: Parent: Base Font Weight: Extra Light The weakness with the approach of needing to redefine font family for every child style is that any change of font must again be changed for every style, rather than one change up the hierarchy that cascades downward. This includes character styles. In that case, I end up not only redefining font family but also needing to multiply character styles. I explain it in my video at the beginning, but no worries if you don't have to time to watch it—brevity is not my skill. It has been logged as a bug already, so now we just have the wait of typically unknown duration to endure.

To add to that, it was also possible on Intel Mac in the first 2.6 betas, but it was removed part way through the beta cycle. It is not clear why it originally worked on Intel but now cannot. Presumably, something needed fixing or some improvement was made to the feature that could not easily be made to work on Intel with the tools they had available.

The issue of font weight not being respected for text styles with variable fonts is what I was trying to report in my thread on the subject, and it is the main difficulty I have with using variable fonts in Publisher. The bug tag AF-3268 was assigned to that issue, and I think AF-4280 is a duplicate. It is still not fixed in 2.6. I would love for this bug to get attention.

That is an interesting hint. Am I wrong to infer that third-party plugins of various kinds will become a possibility?

Not to argue against allowing this to be a customizable shortcut, but I have tried this new behavior and I am looking forward to it making it into the stable release so I can make regular use of it. It seems to be a lot more helpful than the current solution of hitting escape an unknown number of times and then V, which I find a little fiddly: I have to escape enough times so that V does not type rather than change to the move tool, but not so many times that macOS takes over and takes Publisher out of full-screen mode. (When exactly escape works to take Publisher out of full-screen mode seems to me rather capricious, because most of the time I can use escape with impunity, but sometimes it just throws me out of full-screen mode when I wasn’t expecting it.) What I am saying is that I do want the new keyboard shortcut to follow its new 2.6 behavior, but I don’t know of a reason that it should be hard-coded.

Now beta 2861 is back to treating words joined by dashes as single words—back to the original problem. We may have different preferences on how to count hyphens, but I think we all agree that dashes should not cause the words on either side to be counted as a single word. In beta 2861, we have the curious behavior that word count of the same sentence will vary depending on whether the British or American convention of dashes for parenthetical expressions is chosen: The soldiers – well, most of them – defected and joined the rebels. (Publisher b2861 counts 13 words) The soldiers—well, most of them—defected and joined the rebels. (Publisher b2861 counts 9 words) (Example sentence taken from the Antidote style guide.)

And we did use the feature on Intel Mac in the previous beta, so it should be technically possible. I suspect there is some technical compatibility issue with the library they are using, probably holding them back regarding where they want to go or how it works in certain circumstances, but it is not clear what.

For one long document, I have been pinning reference notes off canvas to body text. Every time I pin a new note object, I have to reset the offset. I have prepared a basic document to reproduce the issue. The recipe is simple: just unpin and pin the off-canvas object in the attached document over and over and watch its position move farther to the right. Off-Canvas Pinned Object Creep.afpub off-canvas pinned object creep.mp4 That is the simplest way to demonstrate, but what I am actually doing is adding multiple notes. Every time I deselect a pinned object, the rolling default changes, so when I pin the next note, it is farther away, and so forth. Here is another simple demonstration to show roughy the kind of behavior I encounter when I use multiple notes. off-canvas pinned object creep 2.mov Publisher 2.5.5 on macOS 14.6.1

In the current Publisher 2.5.5 as well as the 2.6.0 beta (2805), the word count area has cut off text descenders when the UI font is large. In English, “words” has no descenders to show the problem, but “paragraphs” does: I notice that the text to the right, “Drag to marquee select…,” also has descenders and appears to be the same size, yet their descenders are not cut off. It seems to be an issue of vertical alignment: the word count text seems to be aligned a few pixels lower. Reporting from macOS 14.6.1

This bug may have already been solved before this current beta. Whenever I confirm a fix of an issue I reported, I always first check to see if I can still reproduce the issue as I originally reported. This time, I could not reproduce the issue in the current Publisher 2.5.5. I was only able to reproduce the issue when I restored from backup the version of Publisher I was using at the time of the report. In any case, it does appear the issue is fixed, both in the current version and in the 2.6 beta.

Meanwhile, my third suggestion of using the Fields panel, which I judged “hacky” back then, is not so bad now, since we can now create custom fields. Which option you might choose depends on the needs of the design. The Fields panel option works well if it is text that needs to be defined once and used multiple times as text, but where the format of the text can vary according to its current use. Symbols work for text as an object that stays the same but can be positioned in multiple places. Master pages work well as fixed page layout elements. A variation on the idea of using the Fields panel is to use a “running header,” which you might not have thought of because of the name. What Publisher calls “Running Header” in the Fields panel actually has a much broader use than simply running headers. It is basically a dynamic text variable. If the text you want to define changes throughout the document, then this might be what you want.

I am writing to confirm that the descender cutoff issue in Publisher 2.6.0 beta (2805) is resolved.

The Affinity Publisher copy appears to apply half-toning, like it is not full black, whereas the color of the text must be full black in the Pages document. I do not know whether that is the only issue, but I would start there. Try to get true black in Affinity for a like-for-like comparison. Also be aware of issues of printing a CMYK document on a home printer. Full CMYK black converts to dark gray in the RGB space that a lot of home printers work from. That being said, I do remember having some experiences of printing directly from Publisher. I do not remember the details at present, but I do remember having better luck by exporting to PDF and then printing the PDF, so there may be something more to it.