Unnecessary Word Wrap with certain fonts on Publisher 2

[Kinokame]

I've encountered a strange issue of unneccessary text wrapping when using certain fonts on Affinity Publisher.

I have a text box with some title-sized text on it as part of the design of a card game card. I recently changed the font I was using on the box, and discovered that certain words, at the end of a line, are wrapping, unhyphenated, to the next line. Hyphenation is turned off, and even when turned on, the same words seem to wrap to the next line. It is behaving as though the word is too long to fit the text box, but it is not; if you force a line break it happily sits within the text box.

This did not happen with the original font.

One point to note is that the new font appears quite small for the point size defined, so I've had to choose a much larger font size (a size that, were I to use the original font, these words would wrap because they are at that point too big for the box.

I suspect there is something to do with the programme thinking that the font is much larger than it appears, but does anyone have any suggestion how to solve this, beyond manually inserting line breaks before in the offending words?

[walt.farrell]

If you can share a sample .afpub document that shows the problem that might make diagnosis easier.

But if the font is appearing too small to you for the assigned point size, that suggests that you've scaled the Text Frame using the lower-right (detached) scaling handle. If so, rather than showing as an open circle the handle would show as a blue-filled circle. Double-clicking on it would reset the scaling and correct that font-size discrepancy.

 

[MikeTO]

What is the font and its source?

[Kinokame]

The font is called hide and seek: it's an outline only font useful for laser engraving, from an independent font designer.

Here's a screenshot, and af publisher package with the relevant fonts (hide and seek and Fjalla One, the original font, for comparison). As you can see, the letterforms are close in size, but Fjalla is 20pt and hide and seek is 48pt.

 

forum example font issue.zip

[kenmcd]

This is another example of a known bug in how Affinity handles OpenType substitutions. It does not maintain the line-breaking characteristics of the replaced character - in this case the spaces.

The font does pseudo-randomization using the OpenType Contextual Alternates (calt) feature - which replaces the spaces with alternates which have different widths.
This causes Affinity to see this as one long line of characters (without any spaces).
So then it breaks the text at odd places.
The line-breaking is broken.

Known bug. No response from Affinity thus far.

[Kinokame]

Thanks kenmcd, I suspected it was something about the spaces not registering as spaces; irritating but glad to have an answer. I guess I'll be using forced line breaks to fix it for the time being.

[lacerto]

Obsolete.

[thomaso]

3 hours ago, lacerto said:

I see something more general (and disturbing) in ways Affinity apps wrap and hyphenate text (especially in narrow columns), (…)

The behavior is remarkably different compared to one demonstrated in InDesign. (…)

Isn't this the expected behaviour in Affinity? While ID doesn't show characters but text overflow when the text frame width gets too narrow, APub simply splits words into parts that might still fit... until it breaks after each character. Hence this workaround of reduced frame width to obtain purely vertical text is recommended in the Affinity forum various times.

The lack of hyphenation in "iconic" seems to be related to the English dictionary. When I switch to another European language "iconic" gets hyphenated.

  <–>    

By the way, some German words also lack hyphenation, due to deficiencies in the German dictionary (e.g. Re·dens·art, funk·tio·niert)

[lacerto]

Obsolete.

[thomaso]

58 minutes ago, lacerto said:

Do you mean poor and incorrect hyphenation?

No. As @kenmcd pointed out there appears to be a font issue in this case.

And as mentioned, I assume this specific "iconic" hyphenation issue is related to the English dictionary, not to a general wrapping feature. Personally I don't mind how Affinity ignores correct hyphenation in such specific situations of obviously quite narrow text frames. In my general workflow I guess I am aware of a sufficient frame width in relation to a certain font size. In particular for short texts and lines with one word only (like "Make iconic objects") I'd rather use line breaks instead of narrowing the frame width. – To me it doesn't appear like an advantage that ID just hides all text in such a situation.

[MikeTO]

I think this issue is logged as afb-8237 and/or afb-1234 so perhaps this thread could be tagged.

[lacerto]

Obsolete

[thomaso]

4 minutes ago, lacerto said:

even when using US English and standard hyphenation zones (identical that were used in InDesign)

Are you sure the two apps use the same dictionary files? To me ID shows dictionaries that don't exist in Affinity, which lets me assume the apps also don't use identical hyphenation files.

There may be multiple issues in the OP's case, e.g. with language/hyphenation *AND* with font/OpenType features. (I only referred to language/hyphenation settings, while you additionally included fonts + OpenType features in your investigation.)

42 minutes ago, lacerto said:

I also prefer to use English dictionaries in context of English text (instead of trying to resolve issues by using e.g. German dictionaries).

Yes. However, switching languages may indicate whether a particular dictionary influences an issue (which seems to be the case with “iconic”, regardless of a certain font).

[MikeTO]

24 minutes ago, thomaso said:

Are you sure the two apps use the same dictionary files? To me ID shows dictionaries that don't exist in Affinity, which lets me assume the apps also don't use identical hyphenation files.

While Adobe uses Hunspell, it has its own implementation of it and uses its own proprietary spelling and hyphenation dictionaries.

[lacerto]

Obsolete.

[MikeTO]

5 minutes ago, lacerto said:

But I would not be surprised if there is a more fundamental issue in Affinity text engine that contributes to the issue.

While Adobe has their own implementation of Hunspell, the hyphenation algorithms are identical, it is only the dictionaries that are different.

18 minutes ago, lacerto said:

Here is a less trivial (with a wider text frame) example of this specific issue (where non-breaking spaces prohibit regular word wrapping and where the issue with irregular and unexpected (=incorrect) word wrapping is not immediately noticeable because words are wrapped but either without a hyphen ("varsin kin"), or, additionally, at a long place ("lauser akenne"), here circled in red:

There isn't a standard Finnish hyphenation dictionary for Hunspell. Are you using this one? https://potkukelkka.com/suomenkielen-tavutus-affinity-publisheriin-mac-koneille/

If so, it's better than nothing but it's tiny.  This dictionary cannot hyphenate either "lauserakenteita" or "varsinkin" but the Adobe and Microsoft dictionaries can.

Hyphenation dictionaries aren't lists of words as you would expect but lists of rules. This one has less than 500 rules which is only a start.

BTW, don't install the hyphenation dictionary using the instructions on that page or you will have to update it each time Affinity is updated. It's better to follow Serif's installation instructions so you never have to do it again. https://forum.affinity.serif.com/index.php?/topic/190021-how-do-i-add-additional-dictionaries-to-affinity-v2/#comment-1111426

Cheers

[lacerto]

Obsolete.

[kenmcd]

2 hours ago, lacerto said:

This does not seem to be so much a font issue but rather an Affinity issue with this font (and probably with other ones using variable spaces similarly).

Duh. That's what I said. Nothing wrong with the font.

You are discussing a different issue then what this thread was originally about.

No line-breaking (or hyphenation) at all due to mishandling of OpenType substitutions.
vs.
Bad line-breaking/hyphenation due to application issues (and different dictionaries).
Two completely different causes and effects.

The Helvetica Now missing hyphens may be due to a choice made in the font and mishandling of that choice in Affinity.
Dunno.
Would require comparison with the results of a font without this choice.

But this discussion should be split.
This has nothing to do with the original issue.

[lacerto]

Obsolete.

[lacerto]

Obsolete.

[MikeTO]

8 hours ago, lacerto said:

An update for anyone interested in better hyphenation: you can override at least US-English internal dictionaries (including one that contains hyphenation rules) by using ones that come e.g. with OpenOffice, and have slightly better hyphenation:

For some reason overriding en-GB does not work so I added en-UK, which works pretty much similarly as the overridden en-US. Override might also work with other non-UK languages, like German, which is currently hyphenated inadequately.

Affinity bundles the 2016 version of the en-GB and en-US hyphenation dictionaries. The Hunspell en-GB dictionary was last updated in May 2024 and I believe the US one has been updated, too, although I don't recall when. Serif has logged this issue as APL-1737. So yes, downloading the latest dictionaries will improve your hyphenation. You can download them from this page:

https://forum.affinity.serif.com/index.php?/topic/190021-how-do-i-add-additional-dictionaries-to-affinity-v2/#comment-1111426

If you install your own dictionaries, you will want to check for new ones every so often because if Serif adds even newer ones, your computer will ignore them and continue to use the ones you've installed yourself.

You can override any dictionary including en-GB - I tested it just now.

I've previously pointed out that US users who want better hyphenation are better off switching to the English UK hyphenation dictionary while keeping spelling set to English US. I tested a long list of words that hyphenated poorly or not at all in English US and they hyphenated properly with English UK. I also tested words that were spelled differently between the countries and there was no regression. There probably are some words that will hyphenate worse but overall the improvement is incredible.

8 hours ago, lacerto said:

BTW, just as a curiosity, the same en-US hyphenation file that is used in context of LibreOffice Writer, hyphenates correctly also the last word "communicate" (the Voikko library that comes as an extension supporting Finnish, works just as well as the custom .aff file I am using, but it is an extension that cannot be used, as far as I know, with Affinity apps).

This might suggest that Affinity apps somehow apply externally defined dictionary-based rules qualitatively (and not in a good way).

Affinity isn't applying any rules all aside from the settings in Paragraph > Hyphenation. Affinity passes Hunspell a word and Hunspell tells Affinity where it can be hyphenated at. If you have min prefix set to 3 and Hunspell wants to hyphenate at 2 then Affinity ignores it. These are the only rules that Affinity applies, it doesn't interact with the dictionaries directly.

[lacerto]

Obsolete.

[MikeTO]

Affinity's implementation of Hunspell on Windows is inside the app so it's not sharing dictionaries with other apps. I don't have Windows so I can't test overriding the en-GB dictionary myself. I know Vector Styler uses Hunspell but I don't know which versions of the dictionaries.

Anyway, it doesn't matter - just use the latest Hunspell en-US hyphenation dictionary or better yet switch to the latest en-GB hyphenation dictionary for even better results.

[lacerto]

Obsolete.

[MikeTO]

In your recording, it is hyphenating at com-mu-ni-cate in US English which is what you wanted. Is there an issue I'm not seeing?

As to why it won't hyphenate ni-cate on its own (which LibreOffice and other apps using the same Hunspell dictionaries won't do either) when it will hyphenate that as part of communicate, it's because the dictionary format allows hyphenating at points except when preceded or not preceded by other characters. It's a complicated format created to run in a few kilobytes of memory. The author knew it wouldn't be perfect but perfection wouldn't have fit into the memory of his PDP-10.

Even though memory is no longer a factor, the approach to hyphenation we're using today is still constrained by decisions made long ago.