Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-15, rgheck wrote:


 Before we have any more of this discussion, let me just emphasize that 
 my original concern was with the use of the Unicode emdash in the User's 
 Guide and Tutorial, where it gives bad results, according to the 
 standards of English typography. That is what I was proposing to change. 
 The issue about unicodesymbols was raised by someone else and is quite 
 orthogonal. 

 Nonetheless, we can discuss it. There is another issue about 
 how these things are rendered on-screen, and yet another about output, 
 again all orthogonal. But they too can be discussed.

In my view, the issues are:

a) What to use in the tutorial, --- or em-dash?

b) How to export the em-dash Unicode char to LaTeX?

c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
   breaks the WYSIWYM principle?

In my view, 

* a) and b) are related, as if the Unicode glyph (correctly applied)
  results in proper typography, it can be used in the Guide and Tutorial
  without adverse effects.

* a) and c) are related too: we should not use --- if this results in
  three hyphens in the printout.

 On 01/14/2010 05:06 PM, Guenter Milde wrote:
 On 2010-01-14, rgheck wrote:
 On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
 rgheckrgh...@bobjweil.com   writes:

 The input ligature can have unwanted side-effects.
...
 # ls --help

 Look at the PDF. 
...

 But if you put it in listings, or in a LyXCode environment, you get
 what you would expect to get in those cases. In the LyXCode case,
 that's because we find this:

 ls~-{}-help

 in the source. So LyX just handles this for you. I don't see anything 
 confusing about it.

 Why does LyX handle this differently from ~ and \?

--- Typing three hyphens to get an em-dash is a TeX typing convention.
(TeX realises it with a font feature called input ligature.)

 ~  Typing a tilde to get a non-break space is another TeX typing
convention realised at the font level.

   The quotation mark is an active character in some document languages
(e.g. German).

LyX handles this input in a way that 

 ~  results in what I see (converted to \textasciitilde{}).
- confusing for TeXperts.

   is handled by the smart-quotes feature (converted to typographically
correct quotes which I see in the LyX window).

If  is copied from somewhere else or if the -key is unbound, it is
(at least in German documents) converted to \textquotedbl{}. To
access the special features for German typography that babel provides
via something, I have to use ERT.

--- is passed to LaTeX as-is also outside ERT and **without any visible
feedback**! 
- confusing for non-TeXers


 As Jürgen said, do you have an example?

 Now, change the command to typewriter font and try again. This time it
 helps, as typewriter is one example of a font without this input
 ligature. But you also don't get an em-dash even if you mean one.

 This makes perfect sense: Typewriters don't have em-dash keys. So the 
 em-dash is rendered as ---. Which is pretty much how people used to 
 type it.

I agree that this TeX feature in many cases gets it right. But nowadays
typewriter fonts have more characters than there are keys on a
typewriter, I would not like rendering of ä as a just because this is
how people used to type it in a (German) LaTeX source.

Another, more relevant example is XeTeX: If (like in the default LyX-svn
setup) system fonts are used, --- is rendered as three hyphens.

- Even if we decide to keep this TeX feature accessible without ERT, we
must not use it for the em-dash Unicode char.


 And, as I've said, the Unicode version gives the wrong spacing.

 In the GUI window or in the output?

 Output. If you enter text[emdash]text, you do not get a line break 
 after the emdash. To get it, you have to mess around in ways you 
 shouldn't have to mess around. I'm not worried about spacing around the 
 em-dash. 

Well, so I was misled by the wording wrong spacing to denote wrong line
breaks.

So my suggestion for issue b) boils down to:

  EM DASH (U+2014) - \textemdash\textzerowidthspace
  
with \textzerowidthspace == ZERO WIDTH SPACE (U+200B)::

  \providecommand*{\textzerowidthspace}{\hski...@skip}

also accessible as InsertFormattingZero Width Hyphenation Point


 Though...
...
 ...it seems to me that this is *exactly* the kind of thing writers 
 should not have to worry about, i.e., that ought to be handled 
 automatically by the typesetting engine. If LaTeX doesn't do that, then 
 there should be a package that does it, if there isn't one already. If 
 there's no such package, then I'd be happy to consider special, 
 language-specific handling of spacing around --- and --, if you 
 wanted to propose that. But I would not want to have special spacing 
 around the Unicode glyph, since it is just a character, and maybe I 
 don't want special spacing around it: I meant to be able to use it as a 
 normal character, if I want to do so.

OK, this makes 

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Guenter Milde wrote:
 Another, more relevant example is XeTeX: If (like in the default LyX-svn
 setup) system fonts are used, --- is rendered as three hyphens.

Not here.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/15/2010 05:24 AM, Guenter Milde wrote:


In my view, the issues are:

   

So, just to be clear what my views are:


a) What to use in the tutorial, --- or em-dash?

   
---, on the ground that em-dash as currently handled breaks lines wrong. 
One could change the handling of em-dash, but I see no generally 
acceptable way to do it, though see below.



b) How to export the em-dash Unicode char to LaTeX?

   

As we do it is fine with me.


c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
breaks the WYSIWYM principle?

   
Yes, on the ground that it doesn't actually break that principle in any 
very significant way, though apparently we disagree about this.



d) Do we want a em-dash (Gedankenstrich) macro choosing the
typographically correct dash depending on the language?
At the LaTeX or LyX level?

(An implementation on the LyX level would be something similar to the
smart-quotes feature.)

   
I thought about this. One could add the dashes to InsetSpecialChar, or 
give them their own inset. But this seems like overkill to me, and the 
proper solution is surely at the LaTeX level, anyway.


The other possibility is to display --- as an em-dash, when we're in 
text, not in ERT, and not in a typewriter font.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck rgh...@bobjweil.com writes:
 a) What to use in the tutorial, --- or em-dash?

 ---, on the ground that em-dash as currently handled breaks lines
 wrong. One could change the handling of em-dash, but I see no
 generally acceptable way to do it, though see below.

+1

 b) How to export the em-dash Unicode char to LaTeX?

 As we do it is fine with me.

If something has to be changed to handling of emdash, it has to be done
in latex packages. This is out of the scope of LyX IMO. 

 c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
 breaks the WYSIWYM principle?

 Yes, on the ground that it doesn't actually break that principle in
 any very significant way, though apparently we disagree about this.

I think we should continue to pass --- unchanged. I do not think we ever
had a bug report about that.

 d) Do we want a em-dash (Gedankenstrich) macro choosing the
 typographically correct dash depending on the language?
 At the LaTeX or LyX level?

In French, it is up to the editor to choose between --- and --.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 I think we should continue to pass --- unchanged.

+1

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-15, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 Another, more relevant example is XeTeX: If (like in the default LyX-svn
 setup) system fonts are used, --- is rendered as three hyphens.

 Not here.

But definitely here with LMRoman10-Regular.

What fonts do you use?
 Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Guenter Milde wrote:
 But definitely here with LMRoman10-Regular.

Not here.

 What fonts do you use?

I tested with default (LMRoman-10), MinionPro, Garamond and Times New Roman.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-15, rgheck wrote:


> Before we have any more of this discussion, let me just emphasize that 
> my original concern was with the use of the Unicode emdash in the User's 
> Guide and Tutorial, where it gives bad results, according to the 
> standards of English typography. That is what I was proposing to change. 
> The issue about unicodesymbols was raised by someone else and is quite 
> orthogonal. 

> Nonetheless, we can discuss it. There is another issue about 
> how these things are rendered on-screen, and yet another about output, 
> again all orthogonal. But they too can be discussed.

In my view, the issues are:

a) What to use in the tutorial, --- or em-dash?

b) How to export the em-dash Unicode char to LaTeX?

c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
   breaks the WYSIWYM principle?

In my view, 

* a) and b) are related, as if the Unicode glyph (correctly applied)
  results in proper typography, it can be used in the Guide and Tutorial
  without adverse effects.

* a) and c) are related too: we should not use --- if this results in
  three hyphens in the printout.

> On 01/14/2010 05:06 PM, Guenter Milde wrote:
>> On 2010-01-14, rgheck wrote:
>>> On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
 rgheck   writes:

>> The input ligature can have unwanted side-effects.
...
>> # ls --help

>> Look at the PDF. 
...

> But if you put it in listings, or in a LyXCode environment, you get
> what you would expect to get in those cases. In the LyXCode case,
> that's because we find this:

> ls~-{}-help

> in the source. So LyX just handles this for you. I don't see anything 
> confusing about it.

>> Why does LyX handle this differently from "~" and "\"?

--- Typing three hyphens to get an em-dash is a "TeX typing convention".
(TeX realises it with a font feature called "input ligature".)

 ~  Typing a tilde to get a non-break space is another "TeX typing
convention" realised at the font level.

 "  The quotation mark is an active character in some document languages
(e.g. German).

LyX handles this input in a way that 

 ~  results in what I see (converted to \textasciitilde{}).
-> confusing for TeXperts.

 "  is handled by the smart-quotes feature (converted to typographically
correct quotes which I see in the LyX window).

If " is copied from somewhere else or if the "-key is unbound, it is
(at least in German documents) converted to \textquotedbl{}. To
access the special features for German typography that babel provides
via ", I have to use ERT.

--- is passed to LaTeX as-is also outside ERT and **without any visible
feedback**! 
-> confusing for non-TeXers


 As Jürgen said, do you have an example?

>> Now, change the command to typewriter font and try again. This time it
>> helps, as typewriter is one example of a font without this input
>> ligature. But you also don't get an em-dash even if you mean one.

> This makes perfect sense: Typewriters don't have em-dash keys. So the 
> em-dash is rendered as "---". Which is pretty much how people used to 
> type it.

I agree that this TeX feature in many cases gets it right. But nowadays
typewriter fonts have more characters than there are keys on a
typewriter, I would not like rendering of ä as "a just because this is
how people used to type it in a (German) LaTeX source.

Another, more relevant example is XeTeX: If (like in the default LyX-svn
setup) system fonts are used, --- is rendered as three hyphens.

-> Even if we decide to keep this TeX feature accessible without ERT, we
must not use it for the em-dash Unicode char.


> And, as I've said, the Unicode version gives the wrong spacing.

>> In the GUI window or in the output?

> Output. If you enter "text[emdash]text", you do not get a line break 
> after the emdash. To get it, you have to mess around in ways you 
> shouldn't have to mess around. I'm not worried about spacing around the 
> em-dash. 

Well, so I was misled by the wording "wrong spacing" to denote wrong line
breaks.

So my suggestion for issue b) boils down to:

  EM DASH (U+2014) -> \textemdash\textzerowidthspace
  
with \textzerowidthspace == ZERO WIDTH SPACE (U+200B)::

  \providecommand*{\textzerowidthspace}{\hski...@skip}

also accessible as Insert>Formatting>Zero Width Hyphenation Point


> Though...
...
> ...it seems to me that this is *exactly* the kind of thing writers 
> should not have to worry about, i.e., that ought to be handled 
> automatically by the typesetting engine. If LaTeX doesn't do that, then 
> there should be a package that does it, if there isn't one already. If 
> there's no such package, then I'd be happy to consider special, 
> language-specific handling of spacing around "---" and "--", if you 
> wanted to propose that. But I would not want to have special spacing 
> around the Unicode glyph, since it is just a character, and maybe I 
> don't want special spacing around it: 

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Guenter Milde wrote:
> Another, more relevant example is XeTeX: If (like in the default LyX-svn
> setup) system fonts are used, --- is rendered as three hyphens.

Not here.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/15/2010 05:24 AM, Guenter Milde wrote:


In my view, the issues are:

   

So, just to be clear what my views are:


a) What to use in the tutorial, --- or em-dash?

   
---, on the ground that em-dash as currently handled breaks lines wrong. 
One could change the handling of em-dash, but I see no generally 
acceptable way to do it, though see below.



b) How to export the em-dash Unicode char to LaTeX?

   

As we do it is fine with me.


c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
breaks the WYSIWYM principle?

   
Yes, on the ground that it doesn't actually break that principle in any 
very significant way, though apparently we disagree about this.



d) Do we want a em-dash ("Gedankenstrich") macro choosing the
typographically correct dash depending on the language?
At the LaTeX or LyX level?

(An implementation on the LyX level would be something similar to the
smart-quotes feature.)

   
I thought about this. One could add the dashes to InsetSpecialChar, or 
give them their own inset. But this seems like overkill to me, and the 
proper solution is surely at the LaTeX level, anyway.


The other possibility is to display "---" as an em-dash, when we're in 
text, not in ERT, and not in a typewriter font.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck  writes:
>> a) What to use in the tutorial, --- or em-dash?
>>
> ---, on the ground that em-dash as currently handled breaks lines
> wrong. One could change the handling of em-dash, but I see no
> generally acceptable way to do it, though see below.

+1

>> b) How to export the em-dash Unicode char to LaTeX?
>>
> As we do it is fine with me.

If something has to be changed to handling of emdash, it has to be done
in latex packages. This is out of the scope of LyX IMO. 

>> c) Shall we pass --- directly to LaTeX even if it is not ERT also if this
>> breaks the WYSIWYM principle?
>>
> Yes, on the ground that it doesn't actually break that principle in
> any very significant way, though apparently we disagree about this.

I think we should continue to pass --- unchanged. I do not think we ever
had a bug report about that.

>> d) Do we want a em-dash ("Gedankenstrich") macro choosing the
>> typographically correct dash depending on the language?
>> At the LaTeX or LyX level?

In French, it is up to the editor to choose between --- and --.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> I think we should continue to pass --- unchanged.

+1

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-15, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> Another, more relevant example is XeTeX: If (like in the default LyX-svn
>> setup) system fonts are used, --- is rendered as three hyphens.

> Not here.

But definitely here with LMRoman10-Regular.

What fonts do you use?
> Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Guenter Milde wrote:
> But definitely here with LMRoman10-Regular.

Not here.

> What fonts do you use?

I tested with default (LMRoman-10), MinionPro, Garamond and Times New Roman.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Le 14 janv. 10 à 01:54, Uwe Stöhr a écrit :
This is an interesting issue. I wasn't aware of that problem. So the  
best is to leave it as it is. The UserGuide already explains the  
different types of dashes and tells the user that there are two  
different ways of inserting them (as --- and as —).
I have nevertheless still the opinion that the documentation files  
should use the Unicode glyphs directly. The vast majority of the LyX  
users I know are coming from the WYSIWYG world and expect to enter a  
single character to get a glyph.


I think this is a case where we can just say : do like that now, this  
is the LyX philosophy...


JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-13, rgheck wrote:
 On 01/13/2010 06:34 AM, Jean-Marc Lasgouttes wrote:

 Of course, a better UI could be to
 transform a - into a -- (I do not have the unicode codepoint handy,
 sorry) when typing - after it (like spaces in math).

 A better UI *might* (and I do mean *might*) be to display it as a 
 unicode em-dash. But you do not want that character, since LaTeX does 
 not know it can break after, but not before, it.

 I offer the attached LyX file as proof.

Then the unicodesymbols replacement definition 

  0x2014 \\textemdash   # EM DASH

is wrong. 

We could consider

  0x2013 --   # EN DASH
  0x2014 ---   # EM DASH

but I did not check for negative side effects.

File a bug report?

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:

Le 14 janv. 10 à 01:54, Uwe Stöhr a écrit :
This is an interesting issue. I wasn't aware of that problem. So the 
best is to leave it as it is. The UserGuide already explains the 
different types of dashes and tells the user that there are two 
different ways of inserting them (as --- and as —).
I have nevertheless still the opinion that the documentation files 
should use the Unicode glyphs directly. The vast majority of the LyX 
users I know are coming from the WYSIWYG world and expect to enter a 
single character to get a glyph.


I think this is a case where we can just say : do like that now, this 
is the LyX philosophy...


Yes, and because it is the right way to do it, if we do say so 
ourselves. The way it is done now leads to bad spacing and related 
problems. You see them all the time in Word-produced documents.


I propose to replace all the Unicode glyphs with proper LaTeX dashes and 
to update the User's Guide to explain why --- and the Unicode version 
are NOT equivalent, even if they print the same character.


Richard

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck rgh...@bobjweil.com writes:
 I offer the attached LyX file as proof.

Trying to open this 2.0.0svn file under 1.6.x made me remember this rather
unintuitive behaviour
  Warning: 376: Format not supported.
  Warning: Quiting.
  Error: Conversion script failed
  
  /afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different version 
of LyX, but the lyx2lyx script failed to convert it.

The last sentence is what I get in a dialog box. Could I get LyX to tell
me that it is a _too_new_ version of the file format?

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 08:26 AM, Jean-Marc Lasgouttes wrote:

rgheckrgh...@bobjweil.com  writes:
   

I offer the attached LyX file as proof.
 

Trying to open this 2.0.0svn file under 1.6.x made me remember this rather
unintuitive behaviour
   Warning: 376: Format not supported.
   Warning: Quiting.
   Error: Conversion script failed
   
   /afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different version 
of LyX, but the lyx2lyx script failed to convert it.

The last sentence is what I get in a dialog box. Could I get LyX to tell
me that it is a _too_new_ version of the file format?

   


if (ret.first != 0) {

Alert::error(_(Conversion script failed),

bformat(_(%1$s is from a different version

 of LyX, but the lyx2lyx script

 failed to convert it.),

from_utf8(filename.absFilename(;

return failure;


So yes, I suppose, if lyx2lyx were to return different error codes 
depending upon what the problem was.


rh

RE: r33007 - lyx-devel/trunk/lib/doc

[Vincent van Ravesteijn - TNW]

 
/afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different
version of LyX, but the lyx2lyx script failed to convert it.

 The last sentence is what I get in a dialog box. Could I get LyX to 
 tell me that it is a _too_new_ version of the file format?



Alert::error(_(Conversion script failed),
 bformat(_(%1$s is from a different version
  of LyX, but the lyx2lyx script
  failed to convert it.),
 from_utf8(filename.absFilename(;

 return failure;


So yes, I suppose, if lyx2lyx were to return different error codes
depending upon what the problem was.

if (file_format != LYX_FORMAT) {
[.. Try to convert ..]

if (file_format  LYX_FORMAT)
Alert::error(_(File is newer, and LyX couldn't convert
it.),
else
Alert::error(_(File is older, and LyX couldn't convert
it.),
}

Vincent

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 08:38 AM, Vincent van Ravesteijn - TNW wrote:


   

/afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different
 

version of LyX, but the lyx2lyx script failed to convert it.
   

The last sentence is what I get in a dialog box. Could I get LyX to
tell me that it is a _too_new_ version of the file format?


 
   

Alert::error(_(Conversion script failed),
bformat(_(%1$s is from a different version
 of LyX, but the lyx2lyx script
 failed to convert it.),
from_utf8(filename.absFilename(;

return failure;


So yes, I suppose, if lyx2lyx were to return different error codes
depending upon what the problem was.
 

if (file_format != LYX_FORMAT) {
[.. Try to convert ..]

if (file_format  LYX_FORMAT)
Alert::error(_(File is newer, and LyX couldn't convert
it.),
else
Alert::error(_(File is older, and LyX couldn't convert
it.),
}

   

Doh

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-14, rgheck wrote:
 On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:

 I think this is a case where we can just say : do like that now, this 
 is the LyX philosophy...

But there is no need to push this on the readers of the tutorial...

 Yes, and because it is the right way to do it, if we do say so 
 ourselves. 

... which I daubt.

 The way it is done now leads to bad spacing and related 
 problems. You see them all the time in Word-produced documents.

???

 I propose to replace all the Unicode glyphs with proper LaTeX dashes and 
 to update the User's Guide to explain why --- and the Unicode version 
 are NOT equivalent, even if they print the same character.

I am against this. The Unicode version is more generic. Not all fonts
will replace --- by an em-dash.

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[Juergen Spitzmueller]

Guenter Milde wrote:

 Not all fonts will replace --- by an em-dash.

Can you name an example?

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 10:45 AM, Guenter Milde wrote:

On 2010-01-14, rgheck wrote:
   

On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:
 

I think this is a case where we can just say : do like that now, this
is the LyX philosophy...
   

But there is no need to push this on the readers of the tutorial...

   
We do this all the time. People coming from Word-type backgrounds often 
have habits they need to unlearn if they are going to use LyX effectively.



Yes, and because it is the right way to do it, if we do say so
ourselves.
 

... which I daubt.

   

See below.


The way it is done now leads to bad spacing and related
problems. You see them all the time in Word-produced documents.
 

???

   
I think I have explained this several times now. The Unicode glyph does 
not give proper spacing. This leads people to type  [glyph] , with 
spaces around it, in an effort to correct for that, and then you get the 
glyph on a new line. I see it all the time in things my students write.



I propose to replace all the Unicode glyphs with proper LaTeX dashes and
to update the User's Guide to explain why --- and the Unicode version
are NOT equivalent, even if they print the same character.
 

I am against this. The Unicode version is more generic. Not all fonts
will replace --- by an em-dash.

   
As Jurgen said, do you have an example? And, as I've said, the Unicode 
version gives the wrong spacing.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck rgh...@bobjweil.com writes:
 As Jurgen said, do you have an example? And, as I've said, the Unicode
 version gives the wrong spacing.

I think Guenter advocates the use of the unicode character on screen, and
--- in latex, using the unicodesymbols file (am I right?).

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:

rgheckrgh...@bobjweil.com  writes:
   

As Jurgen said, do you have an example? And, as I've said, the Unicode
version gives the wrong spacing.
 

I think Guenter advocates the use of the unicode character on screen, and
--- in latex, using the unicodesymbols file (am I right?).

   
If so, then I don't have any major objection, though, as someone said, 
it is harder to distinguish the two glyphs visually than it is to 
distinguish -- from ---.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-14, rgheck wrote:
 On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
 rgheckrgh...@bobjweil.com  writes:

The input ligature can have unwanted side-effects.

Copy the following into a LyX window:

   To get help, use
   
   # ls --help

Look at the PDF. I copied the text back from xpdf and got:

To get help, use
# ls –help

Trying this out, I get 

ls: Ungültige Option -- e
„ls --help“ gibt weitere Informationen.

 As Jurgen said, do you have an example? 

Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also dont get an em-dash even if you mean one.

This is why e.g. Docutils exports -- as -{}-.

Why does LyX handle this differently from ~ and \?

 And, as I've said, the Unicode
 version gives the wrong spacing.

In the GUI window or in the output?

Spacing around an em-dash is both a font issue and a typographic one:

In German typography you put spaces around the Gedankenstrich (and
use an en-dash): 

  Halbgeviertstrich, länger als das Divis, steht zwischen zwei
  Leerzeichen, außer in Verbindung mit Satzzeichen.
  
  -- typokurz – Einige wichtige typografische Regeln
  
I don't think people writing 

  He came — and went.
  
will use correct spacing when told to use three hypens:

  He came---and went.

spacing is the same.

And if the output is affected, the unicodesymbols file could replace
the em-dash with \tiny-space\textemdash\tiny-space{}

 I think Guenter advocates the use of the unicode character on screen, and
 --- in latex, using the unicodesymbols file (am I right?).

No. I'd prefer \textemdash\invisible breakpoint where 
\invisible breakpoint is a generic version of the '' command 

   like -, but producing no hyphen sign (for compund
 words with hyphen, e.g. x-y).

provided by e.g. the german babel option::

  \decl...@shorthand{german}{}{\hski...@skip}

or (as suggested above) a tiny space (but again, this could interfere
with the fonts), hence my preference is no space.

 If so, then I don't have any major objection, though, as someone said, 
 it is harder to distinguish the two glyphs visually than it is to 
 distinguish -- from ---.

True. But if I mean an em-dash, see --- and sometimes get this and
sometimes that, this is not WYSIWYM.

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

Before we have any more of this discussion, let me just emphasize that 
my original concern was with the use of the Unicode emdash in the User's 
Guide and Tutorial, where it gives bad results, according to the 
standards of English typography. That is what I was proposing to change. 
The issue about unicodesymbols was raised by someone else and is quite 
orthogonal. Nonetheless, we can discuss it. There is another issue about 
how these things are rendered on-screen, and yet another about output, 
again all orthogonal. But they too can be discussed.



On 01/14/2010 05:06 PM, Guenter Milde wrote:

On 2010-01-14, rgheck wrote:
   

On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
 

rgheckrgh...@bobjweil.com   writes:
   

The input ligature can have unwanted side-effects.

Copy the following into a LyX window:

To get help, use
# ls --help

Look at the PDF. I copied the text back from xpdf and got:

   
Of course you do, because it is an endash. But if you put it in 
listings, or in a LyXCode environment, you get what you would expect to 
get in those cases. In the LyXCode case, that's because we find this:


ls~-{}-help

in the source. So LyX just handles this for you. I don't see anything 
confusing about it.



As Jurgen said, do you have an example?
   

Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also don't get an em-dash even if you mean one.

   
This makes perfect sense: Typewriters don't have em-dash keys. So the 
em-dash is rendered as ---. Which is pretty much how people used to 
type it.



Why does LyX handle this differently from ~ and \?

   

I'm not sure I understand this question.


And, as I've said, the Unicode version gives the wrong spacing.
 

In the GUI window or in the output?

   
Output. If you enter text[emdash]text, you do not get a line break 
after the emdash. To get it, you have to mess around in ways you 
shouldn't have to mess around. I'm not worried about spacing around the 
em-dash. Though...



Spacing around an em-dash is both a font issue and a typographic one:

In German typography you put spaces around the Gedankenstrich (and
use an en-dash):

   Halbgeviertstrich, länger als das Divis, steht zwischen zwei
   Leerzeichen, außer in Verbindung mit Satzzeichen.

   -- typokurz – Einige wichtige typografische Regeln

I don't think people writing

   He came — and went.

will use correct spacing when told to use three hypens:

   He came---and went.

spacing is the same.

   
...it seems to me that this is *exactly* the kind of thing writers 
should not have to worry about, i.e., that ought to be handled 
automatically by the typesetting engine. If LaTeX doesn't do that, then 
there should be a package that does it, if there isn't one already. If 
there's no such package, then I'd be happy to consider special, 
language-specific handling of spacing around --- and --, if you 
wanted to propose that. But I would not want to have special spacing 
around the Unicode glyph, since it is just a character, and maybe I 
don't want special spacing around it: I meant to be able to use it as a 
normal character, if I want to do so.



And if the output is affected, the unicodesymbols file could replace
the em-dash with \tiny-space\textemdash\tiny-space{}

   
It definitely should not do that, since that is completely wrong for 
English typography. In English, there are no spaces, but you can break 
after the emdash, though not before it. More importantly, the Unicode 
emdash should translate as an emdash and nothing else. Which is a reason 
to keep it as it is, since the translation as --- can be wrong, as you 
have pointed out.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Le 14 janv. 10 à 01:54, Uwe Stöhr a écrit :
This is an interesting issue. I wasn't aware of that problem. So the  
best is to leave it as it is. The UserGuide already explains the  
different types of dashes and tells the user that there are two  
different ways of inserting them (as "---" and as "—").
I have nevertheless still the opinion that the documentation files  
should use the Unicode glyphs directly. The vast majority of the LyX  
users I know are coming from the WYSIWYG world and expect to enter a  
single character to get a glyph.


I think this is a case where we can just say : "do like that now, this  
is the LyX philosophy"...


JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-13, rgheck wrote:
> On 01/13/2010 06:34 AM, Jean-Marc Lasgouttes wrote:

>> Of course, a better UI could be to
>> transform a - into a -- (I do not have the unicode codepoint handy,
>> sorry) when typing - after it (like spaces in math).

> A better UI *might* (and I do mean *might*) be to display it as a 
> unicode em-dash. But you do not want that character, since LaTeX does 
> not know it can break after, but not before, it.

> I offer the attached LyX file as proof.

Then the unicodesymbols replacement definition 

  0x2014 "\\textemdash" "" "" # EM DASH

is wrong. 

We could consider

  0x2013 "--" "" "" # EN DASH
  0x2014 "---" "" "" # EM DASH

but I did not check for negative side effects.

File a bug report?

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:

Le 14 janv. 10 à 01:54, Uwe Stöhr a écrit :
This is an interesting issue. I wasn't aware of that problem. So the 
best is to leave it as it is. The UserGuide already explains the 
different types of dashes and tells the user that there are two 
different ways of inserting them (as "---" and as "—").
I have nevertheless still the opinion that the documentation files 
should use the Unicode glyphs directly. The vast majority of the LyX 
users I know are coming from the WYSIWYG world and expect to enter a 
single character to get a glyph.


I think this is a case where we can just say : "do like that now, this 
is the LyX philosophy"...


Yes, and because it is the right way to do it, if we do say so 
ourselves. The way it is done now leads to bad spacing and related 
problems. You see them all the time in Word-produced documents.


I propose to replace all the Unicode glyphs with proper LaTeX dashes and 
to update the User's Guide to explain why "---" and the Unicode version 
are NOT equivalent, even if they print the same character.


Richard

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck  writes:
> I offer the attached LyX file as proof.

Trying to open this 2.0.0svn file under 1.6.x made me remember this rather
unintuitive behaviour
  Warning: 376: Format not supported.
  Warning: Quiting.
  Error: Conversion script failed
  
  /afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different version 
of LyX, but the lyx2lyx script failed to convert it.

The last sentence is what I get in a dialog box. Could I get LyX to tell
me that it is a _too_new_ version of the file format?

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 08:26 AM, Jean-Marc Lasgouttes wrote:

rgheck  writes:
   

I offer the attached LyX file as proof.
 

Trying to open this 2.0.0svn file under 1.6.x made me remember this rather
unintuitive behaviour
   Warning: 376: Format not supported.
   Warning: Quiting.
   Error: Conversion script failed
   
   /afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different version 
of LyX, but the lyx2lyx script failed to convert it.

The last sentence is what I get in a dialog box. Could I get LyX to tell
me that it is a _too_new_ version of the file format?

   


if (ret.first != 0) {

Alert::error(_("Conversion script failed"),

bformat(_("%1$s is from a different version"

" of LyX, but the lyx2lyx script"

" failed to convert it."),

from_utf8(filename.absFilename(;

return failure;


So yes, I suppose, if lyx2lyx were to return different error codes 
depending upon what the problem was.


rh

RE: r33007 - lyx-devel/trunk/lib/doc

[Vincent van Ravesteijn - TNW]

 
>/afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different
version of LyX, but the lyx2lyx script failed to convert it.
>
> The last sentence is what I get in a dialog box. Could I get LyX to 
> tell me that it is a _too_new_ version of the file format?
>
>

>Alert::error(_("Conversion script failed"),
> bformat(_("%1$s is from a different version"
> " of LyX, but the lyx2lyx script"
> " failed to convert it."),
> from_utf8(filename.absFilename(;
>
> return failure;
>
>
>So yes, I suppose, if lyx2lyx were to return different error codes
>depending upon what the problem was.

if (file_format != LYX_FORMAT) {
[.. Try to convert ..]

if (file_format > LYX_FORMAT)
Alert::error(_("File is newer, and LyX couldn't convert
it."),
else
Alert::error(_("File is older, and LyX couldn't convert
it."),
}

Vincent

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 08:38 AM, Vincent van Ravesteijn - TNW wrote:


   

/afs/inria.fr/rocq/home/imara/lasgoutt/dash.lyx is from a different
 

version of LyX, but the lyx2lyx script failed to convert it.
   

The last sentence is what I get in a dialog box. Could I get LyX to
tell me that it is a _too_new_ version of the file format?


 
   

Alert::error(_("Conversion script failed"),
bformat(_("%1$s is from a different version"
" of LyX, but the lyx2lyx script"
" failed to convert it."),
from_utf8(filename.absFilename(;

return failure;


So yes, I suppose, if lyx2lyx were to return different error codes
depending upon what the problem was.
 

if (file_format != LYX_FORMAT) {
[.. Try to convert ..]

if (file_format>  LYX_FORMAT)
Alert::error(_("File is newer, and LyX couldn't convert
it."),
else
Alert::error(_("File is older, and LyX couldn't convert
it."),
}

   

Doh

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-14, rgheck wrote:
> On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:

>> I think this is a case where we can just say : "do like that now, this 
>> is the LyX philosophy"...

But there is no need to push this on the readers of the tutorial...

> Yes, and because it is the right way to do it, if we do say so 
> ourselves. 

... which I daubt.

> The way it is done now leads to bad spacing and related 
> problems. You see them all the time in Word-produced documents.

???

> I propose to replace all the Unicode glyphs with proper LaTeX dashes and 
> to update the User's Guide to explain why "---" and the Unicode version 
> are NOT equivalent, even if they print the same character.

I am against this. The Unicode version is more generic. Not all fonts
will replace --- by an em-dash.

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[Juergen Spitzmueller]

Guenter Milde wrote:

> Not all fonts will replace --- by an em-dash.

Can you name an example?

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 10:45 AM, Guenter Milde wrote:

On 2010-01-14, rgheck wrote:
   

On 01/14/2010 03:24 AM, Jean-Marc Lasgouttes wrote:
 

I think this is a case where we can just say : "do like that now, this
is the LyX philosophy"...
   

But there is no need to push this on the readers of the tutorial...

   
We do this all the time. People coming from Word-type backgrounds often 
have habits they need to unlearn if they are going to use LyX effectively.



Yes, and because it is the right way to do it, if we do say so
ourselves.
 

... which I daubt.

   

See below.


The way it is done now leads to bad spacing and related
problems. You see them all the time in Word-produced documents.
 

???

   
I think I have explained this several times now. The Unicode glyph does 
not give proper spacing. This leads people to type " [glyph] ", with 
spaces around it, in an effort to correct for that, and then you get the 
glyph on a new line. I see it all the time in things my students write.



I propose to replace all the Unicode glyphs with proper LaTeX dashes and
to update the User's Guide to explain why "---" and the Unicode version
are NOT equivalent, even if they print the same character.
 

I am against this. The Unicode version is more generic. Not all fonts
will replace --- by an em-dash.

   
As Jurgen said, do you have an example? And, as I've said, the Unicode 
version gives the wrong spacing.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

rgheck  writes:
> As Jurgen said, do you have an example? And, as I've said, the Unicode
> version gives the wrong spacing.

I think Guenter advocates the use of the unicode character on screen, and
--- in latex, using the unicodesymbols file (am I right?).

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:

rgheck  writes:
   

As Jurgen said, do you have an example? And, as I've said, the Unicode
version gives the wrong spacing.
 

I think Guenter advocates the use of the unicode character on screen, and
--- in latex, using the unicodesymbols file (am I right?).

   
If so, then I don't have any major objection, though, as someone said, 
it is harder to distinguish the two glyphs visually than it is to 
distinguish -- from ---.


rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Guenter Milde]

On 2010-01-14, rgheck wrote:
> On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
>> rgheck  writes:

The input ligature can have unwanted side-effects.

Copy the following into a LyX window:

   To get help, use
   
   # ls --help

Look at the PDF. I copied the text back from xpdf and got:

To get help, use
# ls –help

Trying this out, I get 

ls: Ungültige Option -- e
„ls --help“ gibt weitere Informationen.

>>> As Jurgen said, do you have an example? 

Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also dont get an em-dash even if you mean one.

This is why e.g. Docutils exports "--" as "-{}-".

Why does LyX handle this differently from "~" and "\"?

>>> And, as I've said, the Unicode
>>> version gives the wrong spacing.

In the GUI window or in the output?

Spacing around an em-dash is both a font issue and a typographic one:

In German typography you put spaces around the "Gedankenstrich" (and
use an en-dash): 

  Halbgeviertstrich, länger als das Divis, steht zwischen zwei
  Leerzeichen, außer in Verbindung mit Satzzeichen.
  
  -- typokurz – Einige wichtige typografische Regeln
  
I don't think people writing 

  He came — and went.
  
will use correct spacing when told to use three hypens:

  He came---and went.

spacing is the same.

And if the output is affected, the unicodesymbols file could replace
the em-dash with "\\textemdash\> I think Guenter advocates the use of the unicode character on screen, and
>> --- in latex, using the unicodesymbols file (am I right?).

No. I'd prefer "\textemdash\" where 
\ is a generic version of the '""' command 

  "" like "-, but producing no hyphen sign (for compund
 words with hyphen, e.g. x-""y).

provided by e.g. the "german" babel option::

  \decl...@shorthand{german}{""}{\hski...@skip}

or (as suggested above) a tiny space (but again, this could interfere
with the fonts), hence my preference is no space.

> If so, then I don't have any major objection, though, as someone said, 
> it is harder to distinguish the two glyphs visually than it is to 
> distinguish -- from ---.

True. But if I mean an em-dash, see "---" and sometimes get this and
sometimes that, this is not WYSIWYM.

Günter

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

Before we have any more of this discussion, let me just emphasize that 
my original concern was with the use of the Unicode emdash in the User's 
Guide and Tutorial, where it gives bad results, according to the 
standards of English typography. That is what I was proposing to change. 
The issue about unicodesymbols was raised by someone else and is quite 
orthogonal. Nonetheless, we can discuss it. There is another issue about 
how these things are rendered on-screen, and yet another about output, 
again all orthogonal. But they too can be discussed.



On 01/14/2010 05:06 PM, Guenter Milde wrote:

On 2010-01-14, rgheck wrote:
   

On 01/14/2010 11:39 AM, Jean-Marc Lasgouttes wrote:
 

rgheck   writes:
   

The input ligature can have unwanted side-effects.

Copy the following into a LyX window:

To get help, use
# ls --help

Look at the PDF. I copied the text back from xpdf and got:

   
Of course you do, because it is an endash. But if you put it in 
listings, or in a LyXCode environment, you get what you would expect to 
get in those cases. In the LyXCode case, that's because we find this:


ls~-{}-help

in the source. So LyX just handles this for you. I don't see anything 
confusing about it.



As Jurgen said, do you have an example?
   

Now, change the command to typewriter font and try again. This time it
helps, as typewriter is one example of a font without this input
ligature. But you also don't get an em-dash even if you mean one.

   
This makes perfect sense: Typewriters don't have em-dash keys. So the 
em-dash is rendered as "---". Which is pretty much how people used to 
type it.



Why does LyX handle this differently from "~" and "\"?

   

I'm not sure I understand this question.


And, as I've said, the Unicode version gives the wrong spacing.
 

In the GUI window or in the output?

   
Output. If you enter "text[emdash]text", you do not get a line break 
after the emdash. To get it, you have to mess around in ways you 
shouldn't have to mess around. I'm not worried about spacing around the 
em-dash. Though...



Spacing around an em-dash is both a font issue and a typographic one:

In German typography you put spaces around the "Gedankenstrich" (and
use an en-dash):

   Halbgeviertstrich, länger als das Divis, steht zwischen zwei
   Leerzeichen, außer in Verbindung mit Satzzeichen.

   -- typokurz – Einige wichtige typografische Regeln

I don't think people writing

   He came — and went.

will use correct spacing when told to use three hypens:

   He came---and went.

spacing is the same.

   
...it seems to me that this is *exactly* the kind of thing writers 
should not have to worry about, i.e., that ought to be handled 
automatically by the typesetting engine. If LaTeX doesn't do that, then 
there should be a package that does it, if there isn't one already. If 
there's no such package, then I'd be happy to consider special, 
language-specific handling of spacing around "---" and "--", if you 
wanted to propose that. But I would not want to have special spacing 
around the Unicode glyph, since it is just a character, and maybe I 
don't want special spacing around it: I meant to be able to use it as a 
normal character, if I want to do so.



And if the output is affected, the unicodesymbols file could replace
the em-dash with "\\textemdash\

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr uwesto...@web.de writes:
 Am 13.01.2010 01:51, schrieb rgheck:

 Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)

 Yes, sorry.

 You did similar changes in the past. Why did you remove long dashes by
 ---? Using three characters to get one in the output is unintuitive
 and confuses newbies. Thanks to our Unicode support we can directly
 use all types of dashes.

Huh? You mean searching in the Sybol dialog for something that matches?
Is that the 'intuitive' solution for newbies?

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
  Besides this, please do all changes that are not specific to trunk in
  the versions in branch!
 
  I thought I should ask Jurgen?
 
 We agreed some time ago that changes are made in the files using change
  tracking, except of the  files that you maintain. Changes to doc files can
  be committed to branch immediately.

Yes, Uwe is the one to ask when it comes to the docs.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Jean-Marc Lasgouttes schrieb:


You did similar changes in the past. Why did you remove long dashes by
---? Using three characters to get one in the output is unintuitive
and confuses newbies. Thanks to our Unicode support we can directly
use all types of dashes.


You mean searching in the Symbol dialog for something that matches?
Is that the 'intuitive' solution for newbies?


Sure, because you do the same in all other text editors and Word-like applications. I was often 
asked in the past why there are two or three subsequent dashes and it is hard to explain that they 
become one in the output but not within LyX.
At least our documentation files should therefore contain the correct characters. People can 
copy/paste them to their documents.
Another point is that --- is a command and the only case where you enter LaTeX commands in LyX 
outside of math and TeX mode (ERT).


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
 Sure, because you do the same in all other text editors and Word-like
  applications. I was often  asked in the past why there are two or three
  subsequent dashes and it is hard to explain that they become one in the
  output but not within LyX.
 At least our documentation files should therefore contain the correct
  characters. People can  copy/paste them to their documents.
 Another point is that --- is a command and the only case where you enter
  LaTeX commands in LyX  outside of math and TeX mode (ERT).

But inserting -- and --- is much easier and less error-prone. And it's easier 
to recognize.

Also, AFAIU, word users usually do not insert dashes via the Symbols dialog, 
but they rely on Word's automatic dash recognition, which incredibly often 
goes wrong. My experience is that wrong dashes is the most recurrent 
typographic error in Word and OOo documents (next to wrong closing single 
quotation marks). 

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr uwesto...@web.de writes:
 Sure, because you do the same in all other text editors and Word-like
 applications. I was often asked in the past why there are two or three
 subsequent dashes and it is hard to explain that they become one in
 the output but not within LyX.

Because it is an easy way to get it?

 At least our documentation files should therefore contain the correct
 characters. People can copy/paste them to their documents.
 Another point is that --- is a command and the only case where you
 enter LaTeX commands in LyX outside of math and TeX mode (ERT).

--- is not a command in TeX, it is a ligature. People do not ask how to
get the 'fi' ligature, they find it normal to type f and then i. This
strikes me as a reasonable way to explain why -- and --- make sense.

The fact that word does not do that (I am not sure it does any ligature,
anyway) is not really relevant. Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:
 My experience is that wrong dashes is the most recurrent typographic
 error in Word and OOo documents (next to wrong closing single
 quotation marks).

You forgot repeated spaces between words.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
 Of course, a better UI could be to
 transform a - into a -- (I do not have the unicode codepoint handy,
 sorry) when typing - after it (like spaces in math).

But this should be customizable, then.
Personally, I find -- much easier to identify and to distinguish from - and 
--- than the ndash and emdash glyph.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller sp...@lyx.org writes:

 Jean-Marc Lasgouttes wrote:
 Of course, a better UI could be to
 transform a - into a -- (I do not have the unicode codepoint handy,
 sorry) when typing - after it (like spaces in math).

 But this should be customizable, then.
 Personally, I find -- much easier to identify and to distinguish from - and 
 --- than the ndash and emdash glyph.

100% agreed.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Jean-Marc Lasgouttes schrieb:


Because it is an easy way to get it?


But an unintuitive way, otherwise I wouldn't have been asked.


At least our documentation files should therefore contain the correct
characters. People can copy/paste them to their documents.
Another point is that --- is a command and the only case where you
enter LaTeX commands in LyX outside of math and TeX mode (ERT).


--- is not a command in TeX, it is a ligature.


This is not correct, neither the Unicode standard nor typographic books know a ligature of dashes, 
see also

http://en.wikipedia.org/wiki/Typographic_ligature

mdash and ndash are characters of its own. --- and -- are LaTeX commands creating these 
characters. Other programming languages than TeX use different commands, see e.g. 
http://en.wikipedia.org/wiki/Dash



The fact that word does not do that (I am not sure it does any ligature,
anyway) is not really relevant. Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).


This might be a solution, but this would nevertheless be an UI for a TeX command and thus a bit 
confusing.


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[Pavel Sanda]

Uwe Stöhr wrote:
 Because it is an easy way to get it?

 But an unintuitive way, otherwise I wouldn't have been asked.

it depends from which background do the newbie comes. if its the tex one
then --- is pretty intuitive. if they are office descendands then i suspect
they have never heard about the typographical differences between en/em 
dashes and are used to put simple - everywhere.

so for them lerning those -/--/--- is the same as learning (not) doing
multiple spaces or linebreaks (also being unintuitive in lyx).

imho not too much to ask them to learn. using symbols dialog is uneasy to use
and easy to overlook, moreover when we are speaking about newbies.

pavel

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 13.59, Pavel Sanda wrote:

 Uwe Stöhr wrote:
 Because it is an easy way to get it?
 
 But an unintuitive way, otherwise I wouldn't have been asked.
 
 it depends from which background do the newbie comes. if its the tex one
 then --- is pretty intuitive. if they are office descendands then i suspect
 they have never heard about the typographical differences between en/em 
 dashes and are used to put simple - everywhere.
 
 so for them lerning those -/--/--- is the same as learning (not) doing
 multiple spaces or linebreaks (also being unintuitive in lyx).
 
 imho not too much to ask them to learn. using symbols dialog is uneasy to use
 and easy to overlook, moreover when we are speaking about newbies.

The main problem for me (latest version on Mac OSX 10.6) is that inserting an 
en-dash (which is alt - on  my Swedish keyboard) zooms out the window
-- is fine (if I can suppress the alt - reflex), but causes problems when 
pasting in Word (which I am frequently forced to). 

/Anders

Re: r33007 - lyx-devel/trunk/lib/doc

[Pavel Sanda]

Anders Ekberg wrote:
 The main problem for me (latest version on Mac OSX 10.6) is that inserting an 
 en-dash (which is alt - on  my Swedish keyboard) zooms out the window
 -- is fine (if I can suppress the alt - reflex), but causes problems when 
 pasting in Word (which I am frequently forced to). 

thats simply configurable through keybindings editor.
pavel

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr uwesto...@web.de writes:

 --- is not a command in TeX, it is a ligature.

 This is not correct, neither the Unicode standard nor typographic
 books know a ligature of dashes, see also
 http://en.wikipedia.org/wiki/Typographic_ligature

-- and -- are implemented in TeX as ligatures in the font, as are ?`,
!`, `` and ''.

 mdash and ndash are characters of its own. --- and -- are LaTeX
 commands creating these characters. 

If by command, you mean 'macros' this is wrong. The - character is not
active and thus it cannot trigger a macro. The actual coding is done in
the font itself. 

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/13/2010 06:34 AM, Jean-Marc Lasgouttes wrote:


Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).

   
A better UI *might* (and I do mean *might*) be to display it as a 
unicode em-dash. But you do not want that character, since LaTeX does 
not know it can break after, but not before, it.


I offer the attached LyX file as proof.

rh

#LyX 2.0.0svn created this file. For more info see http://www.lyx.org/
\lyxformat 376
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\use_xetex false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\default_output_format default
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_amsmath 1
\use_esint 1
\use_mhchem 1
\cite_engine basic
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_use_mathml true
\html_be_strict true
\end_header

\begin_body

\begin_layout Standard
this—is—a—line.—this—is—a—line.—this—is—a—line.—this—is—a—line.—this—is—a—line.—this—
is—a—line.—
\end_layout

\begin_layout Standard
this---is---a---line.---this---is---a---line.---this---is---a---line.---this---is--
-a---line.---this---is---a---line.---this---is---a---line.---
\end_layout

\end_body
\end_document

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/13/2010 06:21 AM, Jürgen Spitzmüller wrote:

Uwe Stöhr wrote:
   

Sure, because you do the same in all other text editors and Word-like
  applications. I was often  asked in the past why there are two or three
  subsequent dashes and it is hard to explain that they become one in the
  output but not within LyX.
At least our documentation files should therefore contain the correct
  characters. People can  copy/paste them to their documents.
Another point is that --- is a command and the only case where you enter
  LaTeX commands in LyX  outside of math and TeX mode (ERT).
 

But inserting -- and --- is much easier and less error-prone. And it's easier
to recognize.

   
Moreover, using the Unicode em-dash produces the wrong spacing, since it 
has to be surrounded by spaces, lest LaTeX break lines incorrectly. And 
then you can get lines where the dash is at the beginning of the line, 
unless you do:

text[protected space][em-dash][space]more text
See the file dash.lyx that I attached to a different message.

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 14.23, Pavel Sanda wrote:

 Anders Ekberg wrote:
 The main problem for me (latest version on Mac OSX 10.6) is that inserting 
 an en-dash (which is alt - on  my Swedish keyboard) zooms out the 
 window
 -- is fine (if I can suppress the alt - reflex), but causes problems 
 when pasting in Word (which I am frequently forced to). 
 
 thats simply configurable through keybindings editor.
 pavel

Thanks!
But this should be rather annoying for a beginner. Maybe it would be good to go 
through the Mac keybindings and make them more Mac-like? 
(I'll put on my todo-list to make a suggestion unless someone jumps to it, but 
it is a lot now, so don't expect anything soon...)

/Anders

RE: r33007 - lyx-devel/trunk/lib/doc

[Vincent van Ravesteijn - TNW]

 
 thats simply configurable through keybindings editor.
 pavel

Thanks!
But this should be rather annoying for a beginner. Maybe it would
be good to go through the Mac keybindings and make them more Mac-like? 
(I'll put on my todo-list to make a suggestion unless someone jumps
to it, but it is a lot now, so don't expect anything soon...)


What key-combo would you propose for zoom-in and out then ?

Vincent

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 17.30, Vincent van Ravesteijn - TNW wrote:

 
 thats simply configurable through keybindings editor.
 pavel
 
 Thanks!
 But this should be rather annoying for a beginner. Maybe it would
 be good to go through the Mac keybindings and make them more Mac-like? 
 (I'll put on my todo-list to make a suggestion unless someone jumps
 to it, but it is a lot now, so don't expect anything soon...)
 
 
 What key-combo would you propose for zoom-in and out then ?
 
 Vincent
 
Cmd + and Cmd - respectively.

/Anders

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Am 13.01.2010 15:54, schrieb Jean-Marc Lasgouttes:


This is not correct, neither the Unicode standard nor typographic
books know a ligature of dashes, see also
http://en.wikipedia.org/wiki/Typographic_ligature


-- and -- are implemented in TeX as ligatures in the font, as are ?`,
!`, `` and ''.


I see now. Some fonts like the latin modern fonts translate -- to the endash 
glyph.

 A better UI *might* (and I do mean *might*) be to display it as a unicode 
em-dash.
 But you do not want that character, since LaTeX does not know it can break 
after,
 but not before, it.

This is an interesting issue. I wasn't aware of that problem. So the best is to leave it as it is. 
The UserGuide already explains the different types of dashes and tells the user that there are two 
different ways of inserting them (as --- and as —).
I have nevertheless still the opinion that the documentation files should use the Unicode glyphs 
directly. The vast majority of the LyX users I know are coming from the WYSIWYG world and expect to 
enter a single character to get a glyph.


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr  writes:
> Am 13.01.2010 01:51, schrieb rgheck:
>
>>> Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)
>>>
>> Yes, sorry.
>
> You did similar changes in the past. Why did you remove long dashes by
> "---"? Using three characters to get one in the output is unintuitive
> and confuses newbies. Thanks to our Unicode support we can directly
> use all types of dashes.

Huh? You mean searching in the Sybol dialog for something that matches?
Is that the 'intuitive' solution for newbies?

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
> >> Besides this, please do all changes that are not specific to trunk in
> >> the versions in branch!
> >
> > I thought I should ask Jurgen?
> 
> We agreed some time ago that changes are made in the files using change
>  tracking, except of the  files that you maintain. Changes to doc files can
>  be committed to branch immediately.

Yes, Uwe is the one to ask when it comes to the docs.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Jean-Marc Lasgouttes schrieb:


You did similar changes in the past. Why did you remove long dashes by
"---"? Using three characters to get one in the output is unintuitive
and confuses newbies. Thanks to our Unicode support we can directly
use all types of dashes.


You mean searching in the Symbol dialog for something that matches?
Is that the 'intuitive' solution for newbies?


Sure, because you do the same in all other text editors and Word-like applications. I was often 
asked in the past why there are two or three subsequent dashes and it is hard to explain that they 
become one in the output but not within LyX.
At least our documentation files should therefore contain the correct characters. People can 
copy/paste them to their documents.
Another point is that "---" is a command and the only case where you enter LaTeX commands in LyX 
outside of math and TeX mode (ERT).


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Uwe Stöhr wrote:
> Sure, because you do the same in all other text editors and Word-like
>  applications. I was often  asked in the past why there are two or three
>  subsequent dashes and it is hard to explain that they become one in the
>  output but not within LyX.
> At least our documentation files should therefore contain the correct
>  characters. People can  copy/paste them to their documents.
> Another point is that "---" is a command and the only case where you enter
>  LaTeX commands in LyX  outside of math and TeX mode (ERT).

But inserting -- and --- is much easier and less error-prone. And it's easier 
to recognize.

Also, AFAIU, word users usually do not insert dashes via the Symbols dialog, 
but they rely on Word's "automatic" dash recognition, which incredibly often 
goes wrong. My experience is that wrong dashes is the most recurrent 
typographic error in Word and OOo documents (next to wrong closing single 
quotation marks). 

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr  writes:
> Sure, because you do the same in all other text editors and Word-like
> applications. I was often asked in the past why there are two or three
> subsequent dashes and it is hard to explain that they become one in
> the output but not within LyX.

Because it is an easy way to get it?

> At least our documentation files should therefore contain the correct
> characters. People can copy/paste them to their documents.
> Another point is that "---" is a command and the only case where you
> enter LaTeX commands in LyX outside of math and TeX mode (ERT).

--- is not a command in TeX, it is a ligature. People do not ask how to
get the 'fi' ligature, they find it normal to type f and then i. This
strikes me as a reasonable way to explain why -- and --- make sense.

The fact that word does not do that (I am not sure it does any ligature,
anyway) is not really relevant. Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:
> My experience is that wrong dashes is the most recurrent typographic
> error in Word and OOo documents (next to wrong closing single
> quotation marks).

You forgot repeated spaces between words.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Jürgen Spitzmüller]

Jean-Marc Lasgouttes wrote:
> Of course, a better UI could be to
> transform a - into a -- (I do not have the unicode codepoint handy,
> sorry) when typing - after it (like spaces in math).

But this should be customizable, then.
Personally, I find -- much easier to identify and to distinguish from - and 
--- than the ndash and emdash glyph.

Jürgen

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Jürgen Spitzmüller  writes:

> Jean-Marc Lasgouttes wrote:
>> Of course, a better UI could be to
>> transform a - into a -- (I do not have the unicode codepoint handy,
>> sorry) when typing - after it (like spaces in math).
>
> But this should be customizable, then.
> Personally, I find -- much easier to identify and to distinguish from - and 
> --- than the ndash and emdash glyph.

100% agreed.

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Jean-Marc Lasgouttes schrieb:


Because it is an easy way to get it?


But an unintuitive way, otherwise I wouldn't have been asked.


At least our documentation files should therefore contain the correct
characters. People can copy/paste them to their documents.
Another point is that "---" is a command and the only case where you
enter LaTeX commands in LyX outside of math and TeX mode (ERT).


--- is not a command in TeX, it is a ligature.


This is not correct, neither the Unicode standard nor typographic books know a ligature of dashes, 
see also

http://en.wikipedia.org/wiki/Typographic_ligature

mdash and ndash are characters of its own. "---" and "--" are LaTeX commands creating these 
characters. Other programming languages than TeX use different commands, see e.g. 
http://en.wikipedia.org/wiki/Dash



The fact that word does not do that (I am not sure it does any ligature,
anyway) is not really relevant. Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).


This might be a solution, but this would nevertheless be an UI for a TeX command and thus a bit 
confusing.


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[Pavel Sanda]

Uwe Stöhr wrote:
>> Because it is an easy way to get it?
>
> But an unintuitive way, otherwise I wouldn't have been asked.

it depends from which background do the newbie comes. if its the tex one
then --- is pretty intuitive. if they are office descendands then i suspect
they have never heard about the typographical differences between en/em 
dashes and are used to put simple "-" everywhere.

so for them lerning those "-/--/---" is the same as learning (not) doing
multiple spaces or linebreaks (also being "unintuitive" in lyx).

imho not too much to ask them to learn. using symbols dialog is uneasy to use
and easy to overlook, moreover when we are speaking about newbies.

pavel

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 13.59, Pavel Sanda wrote:

> Uwe Stöhr wrote:
>>> Because it is an easy way to get it?
>> 
>> But an unintuitive way, otherwise I wouldn't have been asked.
> 
> it depends from which background do the newbie comes. if its the tex one
> then --- is pretty intuitive. if they are office descendands then i suspect
> they have never heard about the typographical differences between en/em 
> dashes and are used to put simple "-" everywhere.
> 
> so for them lerning those "-/--/---" is the same as learning (not) doing
> multiple spaces or linebreaks (also being "unintuitive" in lyx).
> 
> imho not too much to ask them to learn. using symbols dialog is uneasy to use
> and easy to overlook, moreover when we are speaking about newbies.

The main problem for me (latest version on Mac OSX 10.6) is that inserting an 
en-dash (which is "alt -" on  my Swedish keyboard) zooms out the window
"--" is fine (if I can suppress the "alt -" reflex), but causes problems when 
pasting in Word (which I am frequently forced to). 

/Anders

Re: r33007 - lyx-devel/trunk/lib/doc

[Pavel Sanda]

Anders Ekberg wrote:
> The main problem for me (latest version on Mac OSX 10.6) is that inserting an 
> en-dash (which is "alt -" on  my Swedish keyboard) zooms out the window
> "--" is fine (if I can suppress the "alt -" reflex), but causes problems when 
> pasting in Word (which I am frequently forced to). 

thats simply configurable through keybindings editor.
pavel

Re: r33007 - lyx-devel/trunk/lib/doc

[Jean-Marc Lasgouttes]

Uwe Stöhr  writes:

>> --- is not a command in TeX, it is a ligature.
>
> This is not correct, neither the Unicode standard nor typographic
> books know a ligature of dashes, see also
> http://en.wikipedia.org/wiki/Typographic_ligature

-- and -- are implemented in TeX as ligatures in the font, as are ?`,
!`, `` and ''.

> mdash and ndash are characters of its own. "---" and "--" are LaTeX
> commands creating these characters. 

If by command, you mean 'macros' this is wrong. The - character is not
active and thus it cannot trigger a macro. The actual coding is done in
the font itself. 

JMarc

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/13/2010 06:34 AM, Jean-Marc Lasgouttes wrote:


Of course, a better UI could be to
transform a - into a -- (I do not have the unicode codepoint handy,
sorry) when typing - after it (like spaces in math).

   
A better UI *might* (and I do mean *might*) be to display it as a 
unicode em-dash. But you do not want that character, since LaTeX does 
not know it can break after, but not before, it.


I offer the attached LyX file as proof.

rh

#LyX 2.0.0svn created this file. For more info see http://www.lyx.org/
\lyxformat 376
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\use_xetex false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\default_output_format default
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_amsmath 1
\use_esint 1
\use_mhchem 1
\cite_engine basic
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_use_mathml true
\html_be_strict true
\end_header

\begin_body

\begin_layout Standard
this—is—a—line.—this—is—a—line.—this—is—a—line.—this—is—a—line.—this—is—a—line.—this—
is—a—line.—
\end_layout

\begin_layout Standard
this---is---a---line.---this---is---a---line.---this---is---a---line.---this---is--
-a---line.---this---is---a---line.---this---is---a---line.---
\end_layout

\end_body
\end_document

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/13/2010 06:21 AM, Jürgen Spitzmüller wrote:

Uwe Stöhr wrote:
   

Sure, because you do the same in all other text editors and Word-like
  applications. I was often  asked in the past why there are two or three
  subsequent dashes and it is hard to explain that they become one in the
  output but not within LyX.
At least our documentation files should therefore contain the correct
  characters. People can  copy/paste them to their documents.
Another point is that "---" is a command and the only case where you enter
  LaTeX commands in LyX  outside of math and TeX mode (ERT).
 

But inserting -- and --- is much easier and less error-prone. And it's easier
to recognize.

   
Moreover, using the Unicode em-dash produces the wrong spacing, since it 
has to be surrounded by spaces, lest LaTeX break lines incorrectly. And 
then you can get lines where the dash is at the beginning of the line, 
unless you do:

text[protected space][em-dash][space]more text
See the file dash.lyx that I attached to a different message.

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 14.23, Pavel Sanda wrote:

> Anders Ekberg wrote:
>> The main problem for me (latest version on Mac OSX 10.6) is that inserting 
>> an en-dash (which is "alt -" on  my Swedish keyboard) zooms out the 
>> window
>> "--" is fine (if I can suppress the "alt -" reflex), but causes problems 
>> when pasting in Word (which I am frequently forced to). 
> 
> thats simply configurable through keybindings editor.
> pavel

Thanks!
But this should be rather annoying for a beginner. Maybe it would be good to go 
through the Mac keybindings and make them more Mac-like? 
(I'll put on my todo-list to make a suggestion unless someone jumps to it, but 
it is a lot now, so don't expect anything soon...)

/Anders

RE: r33007 - lyx-devel/trunk/lib/doc

[Vincent van Ravesteijn - TNW]

 
>> thats simply configurable through keybindings editor.
>> pavel
>
>Thanks!
>But this should be rather annoying for a beginner. Maybe it would
>be good to go through the Mac keybindings and make them more Mac-like? 
>(I'll put on my todo-list to make a suggestion unless someone jumps
>to it, but it is a lot now, so don't expect anything soon...)
>

What key-combo would you propose for zoom-in and out then ?

Vincent

Re: r33007 - lyx-devel/trunk/lib/doc

[Anders Ekberg]

On 13 jan 2010, at 17.30, Vincent van Ravesteijn - TNW wrote:

> 
>>> thats simply configurable through keybindings editor.
>>> pavel
>> 
>> Thanks!
>> But this should be rather annoying for a beginner. Maybe it would
>> be good to go through the Mac keybindings and make them more Mac-like? 
>> (I'll put on my todo-list to make a suggestion unless someone jumps
>> to it, but it is a lot now, so don't expect anything soon...)
>> 
> 
> What key-combo would you propose for zoom-in and out then ?
> 
> Vincent
> 
Cmd + and Cmd - respectively.

/Anders

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Am 13.01.2010 15:54, schrieb Jean-Marc Lasgouttes:


This is not correct, neither the Unicode standard nor typographic
books know a ligature of dashes, see also
http://en.wikipedia.org/wiki/Typographic_ligature


-- and -- are implemented in TeX as ligatures in the font, as are ?`,
!`, `` and ''.


I see now. Some fonts like the latin modern fonts translate "--" to the endash 
glyph.

> A better UI *might* (and I do mean *might*) be to display it as a unicode 
em-dash.
> But you do not want that character, since LaTeX does not know it can break 
after,
> but not before, it.

This is an interesting issue. I wasn't aware of that problem. So the best is to leave it as it is. 
The UserGuide already explains the different types of dashes and tells the user that there are two 
different ways of inserting them (as "---" and as "—").
I have nevertheless still the opinion that the documentation files should use the Unicode glyphs 
directly. The vast majority of the LyX users I know are coming from the WYSIWYG world and expect to 
enter a single character to get a glyph.


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/12/2010 07:26 PM, uwesto...@lyx.org wrote:

Author: uwestoehr
Date: Wed Jan 13 01:26:03 2010
New Revision: 33007
URL: http://www.lyx.org/trac/changeset/33007

Log:
Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)

   

Yes, sorry.


Besides this, please do all changes that are not specific to trunk in the 
versions in branch!

   

I thought I should ask Jurgen?

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Am 13.01.2010 01:51, schrieb rgheck:


Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)


Yes, sorry.


You did similar changes in the past. Why did you remove long dashes by ---? Using three characters 
to get one in the output is unintuitive and confuses newbies. Thanks to our Unicode support we can 
directly use all types of dashes.



Besides this, please do all changes that are not specific to trunk in
the versions in branch!


I thought I should ask Jurgen?


We agreed some time ago that changes are made in the files using change tracking, except of the 
files that you maintain. Changes to doc files can be committed to branch immediately.


regards Uwe

Re: r33007 - lyx-devel/trunk/lib/doc

[rgheck]

On 01/12/2010 07:26 PM, uwesto...@lyx.org wrote:

Author: uwestoehr
Date: Wed Jan 13 01:26:03 2010
New Revision: 33007
URL: http://www.lyx.org/trac/changeset/33007

Log:
Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)

   

Yes, sorry.


Besides this, please do all changes that are not specific to trunk in the 
versions in branch!

   

I thought I should ask Jurgen?

rh

Re: r33007 - lyx-devel/trunk/lib/doc

[Uwe Stöhr]

Am 13.01.2010 01:51, schrieb rgheck:


Tutorial.lyx: revert r33004 (I guess this was accidentally committed.)


Yes, sorry.


You did similar changes in the past. Why did you remove long dashes by "---"? Using three characters 
to get one in the output is unintuitive and confuses newbies. Thanks to our Unicode support we can 
directly use all types of dashes.



Besides this, please do all changes that are not specific to trunk in
the versions in branch!


I thought I should ask Jurgen?


We agreed some time ago that changes are made in the files using change tracking, except of the 
files that you maintain. Changes to doc files can be committed to branch immediately.


regards Uwe