On 2017-08-25, Enrico Forestieri wrote:
> On Thu, Aug 24, 2017 at 09:29:15PM +0000, Guenter Milde wrote:
>> On 2017-08-23, Scott Kostyshak wrote:
>> > On Fri, Jul 28, 2017 at 03:45:28PM +0200, Pavel Sanda wrote:

>> >> I tend to agree with f). It's not nice that we have such option in
>> >> the prefs, but since we screw the situation already we at least
>> >> give user some power to fix things onwards from 2.3 in his own way.

>> >> And some exclamation mark in RELEASE_NOTES.

>> > Can someone who understands the consequences please add an appropriate
>> > note to RELEASE-NOTES ?

>> Suggested patch:

>> diff --git a/lib/RELEASE-NOTES b/lib/RELEASE-NOTES
>> index 591fcae476..07f1831568 100644
>> --- a/lib/RELEASE-NOTES
>> +++ b/lib/RELEASE-NOTES
>> @@ -13,11 +13,34 @@
>>    be safely dissolved, as it will be automatically inserted at export time
>>    if needed, as usual.

>> -* LyX now outputs en- and em-dashes as -- and --- ligatures when exporting 
>> to
>> -  latex using TeX fonts, as done in version 2.1 and earlier. In version 2.2
>> -  they were instead output as the macros \textendash and \textemdash, 
>> causing
>> -  changed output with old documents and bugs. The 2.2 behavior can be 
>> restored
>> -  by don't allowing using dash ligatures in Document->Settings->Fonts.

> I find the above a concise and to the point description of the issue.

I disagree. The above is an incorrect description.
LyX exported en- and em-dashes as literal characters or
\textemdash \textendash since 10 years. See
https://www.lyx.org/trac/changeset/18802/lyxsvn

> Instead, what follows is too much verbose and confusing for the average
> user. I don't think that 50 or more lines of text are appropriate for
> release notes, especially if only 10% of users are able to comprehend it.
> If you really think that such detailed explanations are necessary, then
> they have to go somewhere into the manuals.

I agree that it may be better to put the details in the manuals, The
RELEASE_NOTES should contain a list of incompatibilities/caveats and
links to the detailled description in the manual.

The concise description could be something in the line of:

>> +  The new setting
>> +  "Document->Settings->Fonts->Output em- and en-dash as ligatures" forces
>> +  output of en- and em-dashes as -- and --- when exporting to LaTeX.
>> +  The setting is on by default, unselected when opening documents edited
>> +  with LyX 2.2, and ignored for documents using non-TeX fonts.
      See <pointer to the manual entry> for details.
>> +  See also "Caveats when upgrading from earlier versions to 2.3.x".


The list of caveats and incompatibilities may be shortened if we fix them.


>> +* If you used literal em- and en-dashes in pre-2.2 documents, you must
>> +  manually unselect
>> +  "Document->Settings->Fonts->Output em- and en-dash as ligatures" to
>> +  ensure unchanged line break behaviour.

This can be avoided when setting the setting based on document content.


>> +  It is no longer possible to differentiate dashes with/without optional
>> +  line break using --- and -- vs. literal dashes. 
>> +  Either convert one sort to ERT or insert optional line break characters.

This may go to the details in the manual page.

>> +  lyx2lyx deletes ZWSP characters following literal em- and en-dashes when
>> +  converting to 2.3 format. If you used literal ZWSP characters (u200b) as
>> +  optional line breaks after dashes, convert them to 0dd wide space insets
>> +  before opening your document with LyX 2.3 or the optional line breaks will
>> +  be lost.

This were not necessary if back-conversion used \twohyphens and \threehyphens
for en- and emdash when use-ligature-dashes is true.
Advantages: correct behaviour in versions up to 2.1
            no errors with versions older than 2.1
            
This would also allow to get rid of the caveat:

>>  * If using TeX fonts and en- and em-dashes are output as font ligatures,
>>    when exporting documents containing en- and em-dashes to the format of
>>    LyX 2.0 or earlier, the following line has to be manually added to the
...

Con:        no workaround (ZWSP) for 2.2 
            (we could even keep this workaround
            in additon to conversion to \towhyphens rsp. \threehyphens.
            but restricted to 2.2 file versions and cases without whitespace
            following the dashes)


>> I can provide a patch.

Günter


Reply via email to