0

In light of the explanations given in LuaTeX and em dashes

"\automatichyphenmode=1 avoids the problem by not converting the hyphen to a discretionary in a number of cases."

and the LuaTeX Reference Manual (8.2.7 disc nodes}

''The \discretionary and -, the - character but also the hyphenation mechanism produces these nodes.''

I looked at the node lists in 4 diferent cases involving the hyphen/minus sign, using both \automatichyphenmode=1 and \automatichyphenmode=0

enter image description here

The correct expected behavior (after the bug is fixed) will be that the glyph char 45 [-] nodes in the 4 cases will be produced as disc (automatic) nodes? (that is, mode=node (0) behavior will also be modified? glyph char 45 ==> disc in both columns?)

This a very very basic code. The output will match the table.

\automatichyphenmode=1

Glyph

Glyph ; Glyph

Glyph ; Glyph

Glyph ; Disc > Subtype 2 ; Glyph

\automatichyphenmode=0

Glyph

Glyph ; Glyph

Disc > Subtype 2 ; Glyph

Glyph ; Disc > Subtype 2; Glyph 

    % !TeX TS-program = lualatex

    \documentclass{minimal}
    \usepackage{fontspec}
    \directlua{
    show_dash = function(head)
    while head do
      if head.id == 0 or head.id == 1 then % hlist, vlist
             texio.write_nl(" ")
              show_dash(head.head)
      elseif head.id == 7 then             % disc
        texio.write_nl("Disc > Subtype " .. head.subtype)
      elseif head.id == 29 then             % glyph
        texio.write_nl("Glyph ")
      end
     head = head.next
    end 

   end
     luatexbase.add_to_callback("post_linebreak_filter",show_dash,"show_dash")
      }


  \begin{document}
   \begin{minipage}{20pt}
      \automatichyphenmode=1    % good for en dash and em dash      
          -

          A-

          -B

          A-B
    \end{minipage}

   \begin{minipage}{20pt}
      \automatichyphenmode=0        
             -

            A-

           -B

           A-B
   \end{minipage}

\end{document}
Improve this question
2
  • If you add some code I can test - I have the fix already locally.
    – Ulrike Fischer
    Commented Apr 1, 2019 at 21:15
  • @Mico I would like to know if the fix for the ''en'' and ''em'' dashes bug will change both the mode=base and mode=node, in order to match the Ref Manual. I started \automatichyphenmode=1 as recommend, but it looks that this setting not önly "this suppress line breaking in a number of cases" but has other effects as well. Up to now the incorrect node generation does not have any consequenses, but it could, at a later time.
    – Simon Dispa
    Commented Apr 1, 2019 at 21:26

1 Answer 1

Reset to default
2

The result of your test file is with tl19 and the next luaotfload version for automatichyphenmode=1 is:

Glyph 

Glyph 
Glyph 

Glyph 
Glyph 

Glyph 
Disk > Subtype 2
Glyph

with automatichyphenmode=0 I get:

Glyph 

Glyph 
Glyph 

Disk > Subtype 2
Glyph 

Glyph 
Disk > Subtype 2
Glyph

This is imho identical to your table, and it is also the expected result. The hyphen is only converted to a discretionary if is is between glyphs (both cases) or before a glyph (0).

The fix you mentioned doesn't change anything here. It only resolves a problem with ligatures consisting of three chars (which affected --- to).

Improve this answer
4
  • I do not see why it is "the expected result" nor why they are different. What do you make of the sentence in LuaTeX Reference Manual (8.2.7 disc nodes}? ''The \discretionary and -, the - character but also the hyphenation mechanism produces these nodes.'' I expected to get (always) Disc > Subtype 2 Glyph Disc > Subtype 2 Disc > Subtype 2 Glyph Glyph Disc > Subtype 2 Glyph By the way, the hyphenation mechanism produces Disc > Subtype 3 which is fine imho.
    – Simon Dispa
    Commented Apr 2, 2019 at 12:04
  • You don't always want the hyphen to be a discretionary. E.g. as a german I don't want a breakpoint after the hyphen in -saft. For me the behaviour is sensible, if you want something else you should make a feature request at the luatex mailing list.
    – Ulrike Fischer
    Commented Apr 2, 2019 at 12:10
  • I agree with you, this is the sensible behaviour. Perhaps the wording of the Manual is not explicit enough. I am going to accept your answer. Thank you.
    – Simon Dispa
    Commented Apr 2, 2019 at 12:32
  • 2
    The wording of the documentation is in many places unclear (and sometimes even wrong).
    – Ulrike Fischer
    Commented Apr 2, 2019 at 12:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .