Le 27/07/2017 à 23:27, Guenter Milde a écrit :
Dear LyX developers,

following Scotts suggestion, I prepared an overview of alternatives to
handle the problem with 2.2 breaking formatting of em- and en-dashes.
Comments and votes welcome.

Unfortunately, the topic is emotionally loaded, as we did a mistake and
there is no solution that everyone will agree with. OTOH, it is complex, but
not very important.

The Problem
===========

Up to version 2.2, LyX used 2 representations for em- and en-dashes:

"literal" dashes:
    literal Unicode or \textemdash rsp. \textendash macro,
"ligature" dashes:
    "---" and "--" converted by the TeX font ligature mechanism.

"Ligature" and "literal" dashes can coexist in <2.2-documents,
e.g., when parts were copy-pasted from different sources.


LyX 2.2 uses only one representation and converts "ligature dashes" to
"literal dashes".

This turned out to break formatting in some documents, because

"literal" dashes suppress line breaks after the dash
   and allow hyphenation in adjacent words while
"ligature dashes" allow line breaks after the dash
   and suppress hyphenation in adjacent words.

There are use cases for both, dashes with and without optional line break
**switching the representation either way can lead to broken output**
(overfull lines or unwanted line breaks).

For details and examples see http://www.lyx.org/trac/ticket/10543#comment:3
and http://www.lyx.org/trac/attachment/ticket/10543/emdash-line-breaks.lyx


Alternatives for 2.3
====================

a) convert ligature dashes to literal dash + allowbreak

    + keeps formatting in most cases
      - allows (possibly undesired) hyphenation in adjacent words
      - a redefinition of \text*dash would also affect former
        "ligature" dashes.
    + simple
    + configurable/editable (special char can easily be deleted)
    ± verbose (the "allowbreak" special-char is displayed as a small blue mark)

b) convert ligature dashes to "special character" insets

    + no change to LaTeX output.
    - requires "special character" inset for ordinary printable character
      - does not scale well
      + precedence cases: curly quotes, text ellipsis

c) keep 2.2 behaviour (convert ligature dashes to literal dashes)

    + simple
    + no change for 2.2 documents (the damage is already done)
    - breaks formatting for <2.2 documents using ligature dashes

d) convert "ligature dashes" to ERT

    + no change to LaTeX output
    + simple
    - ERT for formerly supported feature

e) re-define \textemdash

    + simple (except for LuaTeX)
    + already done by XeTeX
      
(http://tex.stackexchange.com/questions/62800/lualatex-and-line-breaks-after-em-dashes)
    + configurable
    - hidden in the user preamble

f) keep the current 2.3alpha behaviour

    + configurable
    - breaks formatting for <2.2 documents using literal dashes
      (these were not affected by the change in 2.2)
    - new document setting for LaTeX export of Unicode characters:
      - does not scale well,
      - unprecedented
    - Data loss (ZWSP following dashes are removed by lyx2lyx)
    - different line breaks of the same document with LuaTeX and non-TeX fonts

g) revert to 2.1 behaviour

    - regression on bugs  #3647 and #8561
    - no WYSIWYM: "lyx --help" in the GUI becomes "lyx –help" in the output.


Alternatives b there are two pairs of dashes
), c), d) and e) could also be applied to 2.2.x,
a) and f) require a fileformat change.



Open question:
   which representation to use with the -- and --- input conversion?

* The simplest way is to keep 2.2 behaviour (insert literal dashes).
* Maybe we can use a lyxfun with options that will be bound to the '-'-key?

* Sensible defaults would be
   allow linebreak after em-dash
   prevent linebreak after en-dash.
Rationale:
     en-dash around an ellipsis is used with spaces, no line break
     allowed in ranges.


Günter




So for each dash there are two variants, one with a line break
opportunity and one without, and all have a use. Do I understand
correctly? Then, one should first decide how/whether to (ideally)
present the various combinations to the user in 2.3. The answer to the
question of converting 2.2 to 2.3 will follow from there. Do you agree
that the real question is what dashes one wants to propose to users in
2.3 and how?

About e): redefining \textemdash is not nice, instead one could define a
new \lyxemdash. What are the caveats?

Reply via email to