Continuous hyphenation error

[Scythian]

APUB 2.2.0.1881 Beta, Windows 10, Hungarian language

In the paragraph, the setting is: continuous hyphenation: 3.
The program incorrectly counts consecutive end-of-line hyphens; it only takes into account the separation points defined by you, not the soft separator and the hyphen character.

The attached video shows the correct operation in InDesign.

Please Affinity, shut up, let APUB take into account all kinds of end-of-line hyphens. Thanks.

In connection with this, another error was discovered: if I want to insert a character at a specific point of the word from the menu that appears with the right mouse button, the program selects the entire word and an incorrect overwrite occurs.

[MikeTO]

I think you raise a good point - should soft and hard hyphens count toward the consecutive hyphen total? They should for readability and you've pointed out that ID does it that way which I didn't recall.

Here's a test document that shows the issue. It has 3 auto hyphens followed by a soft hyphen and a hard hyphen followed by 3 auto hyphens for a total of 8 hyphens in a row. I don't know if this is a bug or as designed but regardless it would be a nice improvement to change it.

Hyphens.afpub (saved from 2.2 beta)

Edited July 4, 2023 by MikeTO
added 2.2 beta note

[Scythian]

8 hours ago, MikeTO said:

I think you raise a good point - should soft and hard hyphens count toward the consecutive hyphen total? They should for readability and you've pointed out that ID does it that way which I didn't recall.

Here's a test document that shows the issue. It has 3 auto hyphens followed by a soft hyphen and a hard hyphen followed by 3 auto hyphens for a total of 8 hyphens in a row. I don't know if this is a bug or as designed but regardless it would be a nice improvement to change it.

Hyphens.afpub (saved from 2.2 beta)

 

Hi Mike,

thanks for the test. In Central European, such as German and Hungarian typography, it is an error if more than three hyphens appear at the end of lines in a printed book. In a printed book, it is immaterial whether the visible hyphen is a delimiter or a hard hyphen or a soft hyphen. Therefore, the program should take both hard and soft hyphens into account.

 

[stokerg]

Hi @Scythian,

Thanks for raising this.  I needed to check this with our QA team, as I also wasn't sure if this is a bug or currently working as expected.  The answer was, It's currently working as expected, however QA have advised me to log an improvement request with the Developers so these will be taken into account  

[Scythian]

13 hours ago, stokerg said:

Hi @Scythian,

Thanks for raising this. I needed to check this with our QA team, as I also wasn't sure if this is a bug or currently working as expected. The answer was, It's currently working as expected, however QA have advised me to log an improvement request with the Developers so these will be taken into account  

 

Hi stokerg,

 

thanks for the reply. I guessed that the operation was not faulty, but that the level of expectation of the function was low, that is, the definition of the goal to be achieved was not adequate.

 

It follows that, despite the 3 continuous end-of-line separation limits, several end-of-line hyphens can appear one after the other, as MikeTO clearly demonstrated in his test.

 

In the typography of Hungarian and many other languages, it is an error if there is a hyphen at the end of more than three consecutive lines in the printed product, regardless of whether the printed hyphen is generated by the program's separation algorithm, or a hard hyphen or discrete hyphen appears.

 

Therefore, I am forced to use a workaround: 1. I remove all soft hyphens from the text, 2. I replace all hard hyphens with non-breaking hyphens, 3. I manually adjust the "2." paragraphs fragmented by large spaces. It's tiring and time consuming.

 

The layout programs I've used in the past: Ventura Publisher, PageMaker, QuarkXPress, InDesign all handle this problem correctly; that is, if a limit of 3 is set, a hyphen is not allowed to appear at the end of the fourth line.

 

It is unfortunate that the already excellent Affinity Publisher is inferior to its competitors in this function.

Please raise the level of expectation! Thanks.