Re: [patch] support for document class option leqno

2017-05-09 Thread Uwe Stöhr

El 09.05.2017 a las 22:47, Uwe Stöhr escribió:

Unfortunately I have not much spare time. I'll have a look right now and 
try to send a patch.


I needed all I had for a CMake issue and LyX 2.2.3.
Maybe I will have some time on Thursday. If you have time, please step 
in and add support for reqno.


thanks, sorry and regards
Uwe


Re: [patch] support for document class option leqno

2017-05-09 Thread Uwe Stöhr

El 05.05.2017 a las 18:38, Jean-Marc Lasgouttes escribió:


Here is the example again.


Thanks.

With this file, the numbers are on the left side in the PDF output, 
although I did not use leqno.


That is what i meant. Yes, it is possible that document classes or 
packages set the default numbering to the left by internally calling leqno.


Again, I am not opposed to reqno support. If others agree reqno can be 
supported and as Günter said her sees no problem. So fine with me for reqno.


Unfortunately I have not much spare time. I'll have a look right now and 
try to send a patch.


regards Uwe


Re: [patch] support for document class option leqno

2017-05-06 Thread Jean-Marc Lasgouttes
Is that a threat ? Am I supposed to be scared ?

JMarc

Le 5 mai 2017 23:35:16 GMT+02:00, Guillaume MM  a écrit :
>Le 05/05/2017 à 19:52, Jean-Marc Lasgouttes a écrit :
>> I can tell you that I am very grateful to Guillaume for his
>persistence.
>
>Thanks to you for listening. It is not finished...


Re: [patch] support for document class option leqno

2017-05-06 Thread Jean-Marc Lasgouttes


Le 6 mai 2017 02:03:20 GMT+02:00, Scott Kostyshak  a écrit :
>On Fri, May 05, 2017 at 11:35:16PM +0200, Guillaume MM wrote:
>> Le 05/05/2017 à 19:52, Jean-Marc Lasgouttes a écrit :
>> > > No, I am not going to "feel free" to implement it. I already
>"fell free"
>> 
>> "felt" ;)
>
>You beat me to it.

It did feel wrong when I wrote it, but I failed to come up with a better idea.

JMarc


Re: [patch] support for document class option leqno

2017-05-05 Thread Scott Kostyshak
On Fri, May 05, 2017 at 11:35:16PM +0200, Guillaume MM wrote:
> Le 05/05/2017 à 19:52, Jean-Marc Lasgouttes a écrit :
> > Le 05/05/2017 à 18:38, Jean-Marc Lasgouttes a écrit :
> > > > So please fell free to ad support reqno if others agree.
> > > 
> > > No, I am not going to "feel free" to implement it. I already "fell free"
> 
> "felt" ;)

You beat me to it.

Scott


signature.asc
Description: PGP signature


Re: [patch] support for document class option leqno

2017-05-05 Thread Guillaume MM

Le 05/05/2017 à 19:52, Jean-Marc Lasgouttes a écrit :

Le 05/05/2017 à 18:38, Jean-Marc Lasgouttes a écrit :

So please fell free to ad support reqno if others agree.


No, I am not going to "feel free" to implement it. I already "fell free"


"felt" ;)


to rewrite partly the fleqn patch and to implement the GUI drawing. I
also "fell free" to propose to help with the drawing of equation numbers
when it is ready. Here I am only doing code/feature review, these are
not issues on my TODO list.


This came out harsher than I meant, sorry. To get a feeling of what it
is like to propose a small feature and end up being whipped by Guillaume
until everything is more or less correct, please have a look at ticket
#8883 (with its 222 comments):
http://www.lyx.org/trac/ticket/8883

I can tell you that I am very grateful to Guillaume for his persistence.


Thanks to you for listening. It is not finished...

Guillaume



Re: [patch] support for document class option leqno

2017-05-05 Thread Jean-Marc Lasgouttes

Le 05/05/2017 à 18:38, Jean-Marc Lasgouttes a écrit :

So please fell free to ad support reqno if others agree.


No, I am not going to "feel free" to implement it. I already "fell free"
to rewrite partly the fleqn patch and to implement the GUI drawing. I
also "fell free" to propose to help with the drawing of equation numbers
when it is ready. Here I am only doing code/feature review, these are
not issues on my TODO list.


This came out harsher than I meant, sorry. To get a feeling of what it 
is like to propose a small feature and end up being whipped by Guillaume 
until everything is more or less correct, please have a look at ticket 
#8883 (with its 222 comments):

http://www.lyx.org/trac/ticket/8883

I can tell you that I am very grateful to Guillaume for his persistence.

JMarc


Re: [patch] support for document class option leqno

2017-05-05 Thread Jean-Marc Lasgouttes

Le 04/05/17 à 00:30, Uwe Stöhr a écrit :

I again missed things from you. Could you please resend the example? In
which post have you sent it? (Maybe I need to check my list reading
software that it doesn't swallow attachments).


Here is the example again. Note that it is not rcket science: I just 
tried a file with the arabic babel option.


With this file, the numbers are on the left side in the PDF output, 
although I did not use leqno.



No, this is Arabic text at least for some Arabic support packages. I
do not know the full list, I do not know Arabic. I am just pointing
out that it is wrong to assume that standard classes always have
numbering on the right.


I did not say this. I said that this is the default setting of LaTeX. I
discussed the case when classes changes the default.


Here, it is a matter of language, not class.


I still don't get your point. leqno leads to left side numbering. If the
special document class or a package already places the number on the
left side, then leqno does nothing.


So we only implement the possibility of forcing to the left, but not 
forcing to the right. And we implement a GUI output that will be wrong 
for some languages (we still do not have a complete list, actually).



This is not half-baked in my opinion. Supporting reqno requires an
explicit call of amsmath. Moreover document classes that already don't
use the default placement have a special reason to do so.


All classes have a specific reason to do something. What you propose is 
to implement a way to change the default, after all. And AFAIK, loading 
amsmath does not have lead to any adverse result, does it?



I think we
should distinguish between standard classes (all I know use right
numbering as default) that can be used for texts you can design freely,
and document classes for journals that are designed to follow publishing
guidelines. With these journal classes the user is not allowed to format
freely. Therefore I don't want to offer an option that would overwrite a
setting that was most probably set to follow a submission guideline.


I understand your point, but it is shaky. So you advise not to use reqno 
with amsart, although this class is from the people who invented the 
reqno option !



So please fell free to ad support reqno if others agree.


No, I am not going to "feel free" to implement it. I already "fell free" 
to rewrite partly the fleqn patch and to implement the GUI drawing. I 
also "fell free" to propose to help with the drawing of equation numbers 
when it is ready. Here I am only doing code/feature review, these are 
not issues on my TODO list.



If we go back to the issue at hand, adding "leqno" in a text field is 
quite trivial. Where LyX could add some actual value is

* show properly the equation number in the absence of any option
* remember to add amsmath if needed when using reqno.

Also, not that, as Günter pointed out, it is easy to add a
  Provides leqno 1
line in a textclass, and interpret that to mean that the number is 
already on the left. Or maybe it is too hackish and adding a new option 
(thus changing layout files version is the way to go).


Finally, if you decide to stand on the left-only possibility, the right 
UI in document settings would be IMO a checkbox saying something like

  [X] Force math numbering to the left

The current menu-based solution is very weird IMO.

Cheers,
JMarc

#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 508
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language arabic_arabi
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language french
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header

\begin_body

\begin_layout 

Re: [patch] support for document class option leqno

2017-05-04 Thread Guenter Milde
On 2017-05-03, Uwe Stöhr wrote:
> El 03.05.2017 a las 12:05, Jean-Marc Lasgouttes escribió:

...

>> So you are telling me that, when you use plain babel (TeX fonts) and 
>> arabic language, without any fancy leqno option, you do not see that the 
>> number is on the left without asking for it??? I am surprised.

> I don't understand. Yes, without the option leqno I always get the 
> numbers on the right side.

Also if you set the language to Arabic or Hebrew?

...

>> This is half-baked, IMO. Either it is super important to have a 
>> click-click interface instead of writing leqno in a text field in 
>> Document Settings, or it is not.

...
> Supporting reqno requires an explicit call of amsmath. 

This is IMO rather an argument pro "reqno" setting: 
It would be a benefit to the users if LyX takes care of the requirements.
We have the "requirements" framework in LyX, so this should be
(relatively) easy to implement.

> Moreover document classes that already don't use the default placement
> have a special reason to do so. I think we should distinguish between
> standard classes (all I know use right numbering as default) that can
> be used for texts you can design freely, and document classes for
> journals that are designed to follow publishing guidelines. With these
> journal classes the user is not allowed to format freely. Therefore I
> don't want to offer an option that would overwrite a setting that was
> most probably set to follow a submission guideline.

The AMS provides the "amsart" and "amsbook" classes that are (in your
above categorization) more "standard" than special "classes for
journals". Both default to left equation numbers and (via the required
"amsmath") provide the "reqno" option to override this default.

LyX has native support for both amsart and amsbook, so special GUI
support for "leqno" but not "reqno" seems inconsistent.

Günter




Re: [patch] support for document class option leqno

2017-05-03 Thread Uwe Stöhr

El 03.05.2017 a las 12:05, Jean-Marc Lasgouttes escribió:

To state it again: the number may be on the left without leqno. Do we 
want to provide a way to set it on the right in such cases?


I wrote in my last mail why I wouldn't do this. If others think 
different then fine by me if we support reqno as well.


In the 
example that I provided, the number was in Arabo-Indic.


I again missed things from you. Could you please resend the example? In 
which post have you sent it? (Maybe I need to check my list reading 
software that it doesn't swallow attachments).


So you are telling me that, when you use plain babel (TeX fonts) and 
arabic language, without any fancy leqno option, you do not see that the 
number is on the left without asking for it??? I am surprised.


I don't understand. Yes, without the option leqno I always get the 
numbers on the right side.


No, this is Arabic text at least for some Arabic support packages. I do 
not know the full list, I do not know Arabic. I am just pointing out 
that it is wrong to assume that standard classes always have numbering 
on the right.


I did not say this. I said that this is the default setting of LaTeX. I 
discussed the case when classes changes the default.


So either you have a look at it, or flat out admit that we do not care 
if Arabic users have a misleading UI.


But I did and reported that I always get it in the right side (using 
\documentclass article or scrartcl).
I still don't get your point. leqno leads to left side numbering. If the 
special document class or a package already places the number on the 
left side, then leqno does nothing.


This is half-baked, IMO. Either it is super important to have a 
click-click interface instead of writing leqno in a text field in 
Document Settings, or it is not.


This is not half-baked in my opinion. Supporting reqno requires an 
explicit call of amsmath. Moreover document classes that already don't 
use the default placement have a special reason to do so. I think we 
should distinguish between standard classes (all I know use right 
numbering as default) that can be used for texts you can design freely, 
and document classes for journals that are designed to follow publishing 
guidelines. With these journal classes the user is not allowed to format 
freely. Therefore I don't want to offer an option that would overwrite a 
setting that was most probably set to follow a submission guideline.


However, as I wrote above, I can understand if somebody has another 
opinion and thinks that my approach to distinguish document classes not 
suitable. If so I of course support to add also support for reqno.


So please fell free to ad support reqno if others agree.

thanks and regards
Uwe

p.s. I might not be able to code the next days.


Re: [patch] support for document class option leqno

2017-05-03 Thread Guenter Milde
On 2017-05-03, Jean-Marc Lasgouttes wrote:
> Le 02/05/2017 à 23:02, Uwe Stöhr a écrit :

...

> To state it again: the number may be on the left without leqno. Do we 
> want to provide a way to set it on the right in such cases?
...
> or flat out admit that we do not care if Arabic users have a
> misleading UI.

as well as the users of the AMS article and book document classes supported
by LyX.


>> So I would like to keep it as it is:
>> - LyX supports to switch the numbering side from the default right side
>> to the left.
>> - if a user uses a special class using as default left numbering he
>> knows if overriding this makes sense or not. LyX leaves such a very
>> special case tho the user.

> This is half-baked, IMO. Either it is super important to have a 
> click-click interface instead of writing leqno in a text field in 
> Document Settings, or it is not. But I don't care that much and I will 
> do my part of the deal when the dust settles.

Without vetoing any decision: my preference is:

a) No special support for leqno and reqno. 
   Users can easily specify this in the custom document options.

b) Support both, leqno and reqno. Properly.
   With feedback in the GUI and correct LyXHTML export.

   Document>Settings>Math Options:
   ...
   Equation numbers: [default]
 [left   ]
 [right  ]

I will not veto a half-support (leaving out reqno), but expect a bug
report for full support if half-support ends in 2.3.


Regarding the naming: 

A search for "formula number" reveals hits like
  
  Formula: Number of additionals / Article with additional quantity

  Excel Formula - Number within range..
  
  The Natural Remedy Bible 
  FORMULA NUMBER 87: Stinging Nettles Freeze Dried
  
but also  
  
  How do I number my equations? - Apache OpenOffice Wiki
  
OTOH, searching for "equation number" finds

  Equation Numbering in Office 2016 
  
  Numbering Equations (Microsoft Word)
  
  Show equation number only once in align environment - TeX - LaTeX 

Also, there are 543 results for »"formula number" stackexchange« but
93.900 results for »"equation number" stackexchange«.

In LyX, the menu entry is "numbered formula". OTOH, when tagging the
default prefix is "eq:".


Günter



Re: [patch] support for document class option leqno

2017-05-03 Thread Jean-Marc Lasgouttes

Le 02/05/2017 à 23:02, Uwe Stöhr a écrit :

I see it a bit different:
- leqno puts the formula number ALWAYS on the left side. This is clearly
stated in the AMS manuals and also in the LaTeX companion 2nd edition.
I spent some time in testing out Farsi, Arabic and Hebrew and with leqno
I get the number on the left side.


Sure, it is in its name.


So as I wrote, I don't see a problem. I trusted you that you got it at
the right side but you have not provided such a case.


To state it again: the number may be on the left without leqno. Do we 
want to provide a way to set it on the right in such cases?In the 
example that I provided, the number was in Arabo-Indic.


So you are telling me that, when you use plain babel (TeX fonts) and 
arabic language, without any fancy leqno option, you do not see that the 
number is on the left without asking for it??? I am surprised.



Concerning reqno, this is already the default. It has only an effect for
document classes using left numbering. But these are special classes for
scientific journals.


No, this is Arabic text at least for some Arabic support packages. I do 
not know the full list, I do not know Arabic. I am just pointing out 
that it is wrong to assume that standard classes always have numbering 
on the right. I tried with Farsi and Hebrew, but it looks like I am 
missing some fonts (for plain babel version). With non TeX font, it 
looks like I have to select a font, or whatever, and seriously I do not 
want to do that.


So either you have a look at it, or flat out admit that we do not care 
if Arabic users have a misleading UI.



So I would like to keep it as it is:
- LyX supports to switch the numbering side from the default right side
to the left.
- if a user uses a special class using as default left numbering he
knows if overriding this makes sense or not. LyX leaves such a very
special case tho the user.


This is half-baked, IMO. Either it is super important to have a 
click-click interface instead of writing leqno in a text field in 
Document Settings, or it is not. But I don't care that much and I will 
do my part of the deal when the dust settles.


JMarc



Re: [patch] support for document class option leqno

2017-05-03 Thread Guenter Milde
Dear Uwe, dear Jean-Marc, dear LyX developers,

On 2017-05-02, Uwe Stöhr wrote:
> El 02.05.2017 a las 17:02, Jean-Marc Lasgouttes escribió:

>> 1/ understand, for the various languages and packages implementing these 
>> languages what are the cases where the default is to put the number on 
>> the left. I have identified one, there are probably others.

>> 2/ see whether LyX can have this knowledge (e.g. using a new tag in the 
>> language file).

>> 3/ when the situation is clear, I can implement on-screen visualization.

It would be an enhancement if LyX "native screen rendering" (without
instant preview) made this right for RTL languages.
We can, however, implement correct "leqno"-support without this, as ...

...
> - leqno puts the formula number ALWAYS on the left side. This is clearly 
> stated in the AMS manuals and also in the LaTeX companion 2nd edition.

I think, we can safely assume that with "leqno", there is no numbering on
the right side.

OTOH, the *default* is not always right. Left numbering is the default in
"some special classes", but also for (at least some) RTL languages.


> So I would like to keep it as it is:
> - LyX supports to switch the numbering side from the default right side 
> to the left.
> - if a user uses a special class using as default left numbering he 
> knows if overriding this makes sense or not. LyX leaves such a very 
> special case tho the user.


I can live without native "reqno" support. However, I cannot live with the
current GUI interface:

The drop-down box

  Fromula numbering  [Right]
 [Left ]

is misleading (it is "default" vs. "left"). We know its wrong for RTL
languages and some classes.

Why not:
 
  [ ] Place equation numbers left.

? (Where do we toggle equation/formula numbering and how is it called?)

Günter


  




Re: [patch] support for document class option leqno

2017-05-02 Thread Uwe Stöhr

El 02.05.2017 a las 17:02, Jean-Marc Lasgouttes escribió:

1/ understand, for the various languages and packages implementing these 
languages what are the cases where the default is to put the number on 
the left. I have identified one, there are probably others.


2/ see whether LyX can have this knowledge (e.g. using a new tag in the 
language file).


3/ when the situation is clear, I can implement on-screen visualization.


I see it a bit different:
- leqno puts the formula number ALWAYS on the left side. This is clearly 
stated in the AMS manuals and also in the LaTeX companion 2nd edition.
I spent some time in testing out Farsi, Arabic and Hebrew and with leqno 
I get the number on the left side.


So as I wrote, I don't see a problem. I trusted you that you got it at 
the right side but you have not provided such a case.
If it was a misunderstanding and you have no test case for that, we 
should trust that leqno leads to left numbering and can setup the 
visualization accordingly.


Concerning reqno, this is already the default. It has only an effect for 
document classes using left numbering. But these are special classes for 
scientific journals. If the user want to override the requirements of 
special classes he can still do it. There is no need for LyX to provide 
support for this. Moreover this would be hard to investigate what 
classes are affected and why the use already left numbering.


So I would like to keep it as it is:
- LyX supports to switch the numbering side from the default right side 
to the left.
- if a user uses a special class using as default left numbering he 
knows if overriding this makes sense or not. LyX leaves such a very 
special case tho the user.


regards Uwe


Re: [patch] support for document class option leqno

2017-05-02 Thread Jean-Marc Lasgouttes

Le 29/04/2017 à 16:38, Guenter Milde a écrit :

So, it seems in arabic equation numbering does not change sides.
It still may be different with babel vs. polyglossia, with other RTL
languages and/or additional packages.


I think that it depends on the package (Hebrew shall be checked too). 
This needs to be investigated.



The safe option would be a 3-way setting:

equation numbers:
default# no option
left   # leqno
right  # reqno + require("amsmath")

? This would also fit in the scheme to name opion settings that don't insert
code "default".


I suspect we will have to do this, indeed.

JMarc



Re: [patch] support for document class option leqno

2017-05-02 Thread Jean-Marc Lasgouttes

Le 02/05/2017 à 16:42, Kornel Benko a écrit :

Am Dienstag, 2. Mai 2017 um 16:35:03, schrieb Jean-Marc Lasgouttes 


Le 02/05/2017 à 16:31, Kornel Benko a écrit :

Is this one better?


But I see the number to the right when editing. The pdflatex output is to the 
left, as it is the math-preview.


I thought tht the question was whether the number is on the left when
typesetting. It seemed to me that Uwe mentioned that he did not observe
that in Arabic documents.


Maybe. Citing Uwe:


Here is the citation I am referring to:

> At first I sent the patch using left/right but JMarc said that this
> would be incorrect for RTL languages. I cannot get such a case here but
> as JMarc wrote today that he gets this. Thus we need to investigate that
> further how and when leqno leads to numbering at the right side.

So here is what I propose:

1/ understand, for the various languages and packages implementing these 
languages what are the cases where the default is to put the number on 
the left. I have identified one, there are probably others.


2/ see whether LyX can have this knowledge (e.g. using a new tag in the 
language file).


3/ when the situation is clear, I can implement on-screen visualization.

To be frank, I am not really interested in trying all our RtL languages 
variants and see what they do. I did not open this particular can of 
worms. But I will do the part I know how to do.


Uwe?

JMarc




Re: [patch] support for document class option leqno

2017-05-02 Thread Kornel Benko
Am Dienstag, 2. Mai 2017 um 16:35:03, schrieb Jean-Marc Lasgouttes 

> Le 02/05/2017 à 16:31, Kornel Benko a écrit :
> >> Is this one better?
> >
> > But I see the number to the right when editing. The pdflatex output is to 
> > the left, as it is the math-preview.
> 
> I thought tht the question was whether the number is on the left when 
> typesetting. It seemed to me that Uwe mentioned that he did not observe 
> that in Arabic documents.

Maybe. Citing Uwe:
> > Hi JMarc,
> > 
> > the patch misses the visualization within LYX. I have the same problem
> > as with the visualization of mathindent. I cannot find where in the code
> > we set draw the general math inset. You said that you will do something
> > for mathindent maybe you could give me also a hint for the formula number?

Difficult to understand what 'visualization' means. Maybe, he has not 
math-preview set.

> I have promised to implement on screen support for leqno and fleqn, but 
> I have not do so yet. I am waiting to see what is actually necessary for 
> leqno.
> 
> JMarc

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: [patch] support for document class option leqno

2017-05-02 Thread Jean-Marc Lasgouttes

Le 02/05/2017 à 16:31, Kornel Benko a écrit :

Is this one better?


But I see the number to the right when editing. The pdflatex output is to the 
left, as it is the math-preview.


I thought tht the question was whether the number is on the left when 
typesetting. It seemed to me that Uwe mentioned that he did not observe 
that in Arabic documents.


I have promised to implement on screen support for leqno and fleqn, but 
I have not do so yet. I am waiting to see what is actually necessary for 
leqno.


JMarc


Re: [patch] support for document class option leqno

2017-05-02 Thread Kornel Benko
Am Dienstag, 2. Mai 2017 um 16:00:40, schrieb Jean-Marc Lasgouttes 

> Le 02/05/2017 à 15:37, Kornel Benko a écrit :
> >> I do not know anything about Arabic, so I created with LyX 2.3.3dev a
> >> document with language arabic_arabi, and I see the equation numbers on
> >> the left.
> >>
> >> I do not understand why you do not see the same, Uwe.
> >
> > Wrong file attached? The sent doc is neither arabic, nor contains any math.
> 
> Indeed ;) I have two computers on my desk and sent my email from the 
> wrong one...
> 
> Is this one better?

Yes.

But I see the number to the right when editing. The pdflatex output is to the 
left, as it is the math-preview.

> JMarc

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: [patch] support for document class option leqno

2017-05-02 Thread Jean-Marc Lasgouttes

Le 02/05/2017 à 15:37, Kornel Benko a écrit :

I do not know anything about Arabic, so I created with LyX 2.3.3dev a
document with language arabic_arabi, and I see the equation numbers on
the left.

I do not understand why you do not see the same, Uwe.


Wrong file attached? The sent doc is neither arabic, nor contains any math.


Indeed ;) I have two computers on my desk and sent my email from the 
wrong one...


Is this one better?

JMarc




nouveau1.lyx
Description: application/lyx


Re: [patch] support for document class option leqno

2017-05-02 Thread Kornel Benko
Am Dienstag, 2. Mai 2017 um 14:47:23, schrieb Jean-Marc Lasgouttes 

> Le 26/04/2017 à 00:16, Uwe Stöhr a écrit :
> > El 25.04.2017 a las 07:41, Guenter Milde escribió:
> >
> >> In this case, shouldn't it be named "right/left", as "before/after" would
> >> mean reverse placement (left/right) in RTL languages?
> >
> > At first I sent the patch using left/right but JMarc said that this
> > would be incorrect for RTL languages. I cannot get such a case here but
> > as JMarc wrote today that he gets this. Thus we need to investigate that
> > further how and when leqno leads to numbering at the right side.
> 
> I do not know anything about Arabic, so I created with LyX 2.3.3dev a 
> document with language arabic_arabi, and I see the equation numbers on 
> the left.
> 
> I do not understand why you do not see the same, Uwe.
> 
> JMarc
> 

Wrong file attached? The sent doc is neither arabic, nor contains any math.

Kornel

signature.asc
Description: This is a digitally signed message part.


Re: [patch] support for document class option leqno

2017-05-02 Thread Jean-Marc Lasgouttes

Le 26/04/2017 à 00:16, Uwe Stöhr a écrit :

El 25.04.2017 a las 07:41, Guenter Milde escribió:


In this case, shouldn't it be named "right/left", as "before/after" would
mean reverse placement (left/right) in RTL languages?


At first I sent the patch using left/right but JMarc said that this
would be incorrect for RTL languages. I cannot get such a case here but
as JMarc wrote today that he gets this. Thus we need to investigate that
further how and when leqno leads to numbering at the right side.


I do not know anything about Arabic, so I created with LyX 2.3.3dev a 
document with language arabic_arabi, and I see the equation numbers on 
the left.


I do not understand why you do not see the same, Uwe.

JMarc




nouveau1.lyx
Description: application/lyx


Re: [patch] support for document class option leqno

2017-04-30 Thread Uwe Stöhr

El 29.04.2017 a las 16:38, Guenter Milde escribió:


So, it seems in arabic equation numbering does not change sides.
It still may be different with babel vs. polyglossia, with other RTL
languages and/or additional packages.

The safe option would be a 3-way setting:


I don't understand. All my tests show that leqno works for RTL languages 
the same way as for LTR languages. So unless there is a case where leqno 
shifts the number to the right side I don't see why we should act. It 
might be that certain document classes change the default to left 
numbering but then the leqno wouldn't do anything.


Of course we could also offer reqno but I don't know what side effects 
this will have. for example some classes for scientific articles use 
their own version of amsmath. Or in case they switch the default to left 
numbering it might be that the journal doesn't allow numbering at the 
right side.

Therefore I am reluctant to add support for reqno or not.

regards uwe


Re: [patch] support for document class option leqno

2017-04-29 Thread Guenter Milde
On 2017-04-25, Uwe Stöhr wrote:
> El 25.04.2017 a las 07:41, Guenter Milde escribió:

>> In this case, shouldn't it be named "right/left", as "before/after" would
>> mean reverse placement (left/right) in RTL languages?

> At first I sent the patch using left/right but JMarc said that this 
> would be incorrect for RTL languages. I cannot get such a case here but 
> as JMarc wrote today that he gets this. Thus we need to investigate that 
> further how and when leqno leads to numbering at the right side.

> I see that in an RTL language "after" is the left side, so in fact 
> naming "before/after" is dfinitly more problematic than "left/right". 
> I'll change this now.

Thank you.

> Here is Hatim's Physics book:
> https://downloads.sourceforge.net/project/ohodquizgame/Books/physics.pdf?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fohodquizgame%2Ffiles%2FBooks%2F=1493158062_mirror=kent

> All formulas are numbered at the right side and neither the document 
> class leqno nor reqno is used according to the source:
> https://sourceforge.net/projects/ohodquizgame/files/Books/physics_source_lyx2.2.1.zip/download

So, it seems in arabic equation numbering does not change sides.
It still may be different with babel vs. polyglossia, with other RTL
languages and/or additional packages.

The safe option would be a 3-way setting:

equation numbers:  
default# no option
left   # leqno
right  # reqno + require("amsmath")
   
? This would also fit in the scheme to name opion settings that don't insert
code "default".

Günter



Re: [patch] support for document class option leqno

2017-04-25 Thread Uwe Stöhr

El 25.04.2017 a las 07:41, Guenter Milde escribió:


In this case, shouldn't it be named "right/left", as "before/after" would
mean reverse placement (left/right) in RTL languages?


At first I sent the patch using left/right but JMarc said that this 
would be incorrect for RTL languages. I cannot get such a case here but 
as JMarc wrote today that he gets this. Thus we need to investigate that 
further how and when leqno leads to numbering at the right side.


I see that in an RTL language "after" is the left side, so in fact 
naming "before/after" is dfinitly more problematic than "left/right". 
I'll change this now.

Here is Hatim's Physics book:
https://downloads.sourceforge.net/project/ohodquizgame/Books/physics.pdf?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Fohodquizgame%2Ffiles%2FBooks%2F=1493158062_mirror=kent

All formulas are numbered at the right side and neither the document 
class leqno nor reqno is used according to the source:

https://sourceforge.net/projects/ohodquizgame/files/Books/physics_source_lyx2.2.1.zip/download

regards Uwe


Re: [patch] support for document class option leqno

2017-04-25 Thread Uwe Stöhr
> Gesendet: Dienstag, 25. April 2017 um 10:56 Uhr
> Von: "Jean-Marc Lasgouttes" 
> 
> I looked a bit at it and it seems that at least Arabic documents use 
> left numbering by default and that it is right side that might have to 
> be specified (I did not have good hebrew fonts at hand, so I did not test).

I played yesterday with Arabic documents and with the default settings I get 
with pdflatex, and XeTeX the number at the right side. Only if one uses leqno 
as document class option I get it in the left side. Could you please send me 
your Arabic testfile to check?

> To this end, ams* packages support the reqno option. So it seems that 
> there are 3 states: force left, auto and force right. You should take 
> this in account in the UI.

Interesting. I never heard from reqno before. But this requires the amsmath 
package to be loaded while leqno is available for all document classes. So this 
needs some more investigation.

I cannot find Hatim's physics book that he recently published. I want to see 
how the numbering is in his book because is a native speaker and teacher so I 
assume he will use the default numbering.

thanks and regards
Uwe


Re: [patch] support for document class option leqno

2017-04-25 Thread Jean-Marc Lasgouttes

Le 25/04/2017 à 03:03, Uwe Stöhr a écrit :

El 23.04.2017 a las 01:25, Uwe Stöhr escribió:


Thanks for having a look. That is a good point. I will rename it
according to your proposal.


This was not necessary because leqno numbers also in Arabic documents at
the left side because the default is the right side.
I chase anyway the name "math_number_before".


I looked a bit at it and it seems that at least Arabic documents use 
left numbering by default and that it is right side that might have to 
be specified (I did not have good hebrew fonts at hand, so I did not test).


To this end, ams* packages support the reqno option. So it seems that 
there are 3 states: force left, auto and force right. You should take 
this in account in the UI.


Another solution is to keep the before/after naming and to output
* after: nothing, this is the default
* before : output leqno for RtL language and  reqno for RtL language. 
The latter might require amsmath, though.


JMarc



Re: [patch] support for document class option leqno

2017-04-24 Thread Guenter Milde
On 2017-04-25, Uwe Stöhr wrote:
> El 23.04.2017 a las 01:25, Uwe Stöhr escribió:

>> Thanks for having a look. That is a good point. I will rename it 
>> according to your proposal.

> This was not necessary because leqno numbers also in Arabic documents at 
> the left side because the default is the right side.
> I chase anyway the name "math_number_before".

In this case, shouldn't it be named "right/left", as "before/after" would
mean reverse placement (left/right) in RTL languages?

Günter



Re: [patch] support for document class option leqno

2017-04-24 Thread Uwe Stöhr

El 23.04.2017 a las 01:25, Uwe Stöhr escribió:

Thanks for having a look. That is a good point. I will rename it 
according to your proposal.


This was not necessary because leqno numbers also in Arabic documents at 
the left side because the default is the right side.

I chase anyway the name "math_number_before".

OK, so I will put it in after alpha 1 and move the mathindent fields to 
the math panel in another commit (I hope there is enough space).


Done.

regards Uwe


Re: [patch] support for document class option leqno

2017-04-22 Thread Uwe Stöhr

El 19.04.2017 a las 14:55, Jean-Marc Lasgouttes escribió:

I did not try it, but the structure looks OK to me. Still, I have a 
problem with left/right, which will be wrong in RtL documents. What 
about "number before/after equation"?


Thanks for having a look. That is a good point. I will rename it 
according to your proposal.


If this gets in, I can have a look at the visualization stuff, although 
previews may make things more difficult.


OK, so I will put it in after alpha 1 and move the mathindent fields to 
the math panel in another commit (I hope there is enough space).


Concerning the preview, you mean instant preview? I have indeed not 
thought about it. It looks often different. For example the formula 
number is already incorrectly drawn. Just input a displayed "A=B" with a 
formula number. As result the formula number is drawn short behind the 
"B" while Instant preview does it better. Nevertheless, both is 
incorrect because it has to be drawn at the right border of the text.


So maybe the drawing of formula numbers can be improved by support for 
leqno.


regards Uwe


Re: [patch] support for document class option leqno

2017-04-19 Thread Jean-Marc Lasgouttes

Le 19/04/2017 à 00:27, Uwe Stöhr a écrit :

LyX 2.3 will support the document class option fleqn so I thin the other
generic math document class option "leqno" should be supported as well.

Attached is the patch.

There shouldn't be controversies except of the place of the combobox (an
the name of its label of course ;-) ). I put it in the document settings
math panel because i thinks it belongs there together with the fleqn
setting (that is currently in the text layout panel).


I did not try it, but the structure looks OK to me. Still, I have a 
problem with left/right, which will be wrong in RtL documents. What 
about "number before/after equation"?


If this gets in, I can have a look at the visualization stuff, although 
previews may make things more difficult.


JMarc



Re: [patch] support for document class option leqno

2017-04-18 Thread Uwe Stöhr

El 19.04.2017 a las 00:27, Uwe Stöhr escribió:


Attached is the patch.


Hi JMarc,

the patch misses the visualization within LYX. I have the same problem 
as with the visualization of mathindent. I cannot find where in the code 
we set draw the general math inset. You said that you will do something 
for mathindent maybe you could give me also a hint for the formula number?


thanks and regards
Uwe


[patch] support for document class option leqno

2017-04-18 Thread Uwe Stöhr
LyX 2.3 will support the document class option fleqn so I thin the other 
generic math document class option "leqno" should be supported as well.


Attached is the patch.

There shouldn't be controversies except of the place of the combobox (an 
the name of its label of course ;-) ). I put it in the document settings 
math panel because i thinks it belongs there together with the fleqn 
setting (that is currently in the text layout panel).


regards Uwe
 lib/lyx2lyx/lyx_2_3.py| 43 ++-
 src/BufferParams.cpp  |  7 +++
 src/BufferParams.h|  3 ++
 src/frontends/qt4/GuiDocument.cpp | 24 ++-
 src/frontends/qt4/ui/MathsUi.ui   | 90 +++
 src/tex2lyx/Preamble.cpp  |  9 
 src/tex2lyx/Preamble.h|  1 +
 src/version.h |  4 +-
 8 files changed, 150 insertions(+), 31 deletions(-)

diff --git a/lib/lyx2lyx/lyx_2_3.py b/lib/lyx2lyx/lyx_2_3.py
index e03b2b9ee6..f89f73c4a5 100644
--- a/lib/lyx2lyx/lyx_2_3.py
+++ b/lib/lyx2lyx/lyx_2_3.py
@@ -2123,6 +2123,45 @@ def revert_rotfloat(document):
 i = i + 1
 
 
+def convert_mathnumberside(document):
+" add the \\math_number_left tag "
+# check if the document uses the class option "leqno"
+k = find_token(document.header, "\\quotes_style", 0)
+regexp = re.compile(r'^.*leqno.*')
+i = find_re(document.header, regexp, 0)
+if i != -1:
+document.header.insert(k, "\\math_number_left 1")
+# delete the found option
+document.header[i] = document.header[i].replace(",leqno", "")
+document.header[i] = document.header[i].replace(", leqno", "")
+document.header[i] = document.header[i].replace("leqno,", "")
+j = find_re(document.header, regexp, 0)
+if i == j:
+# then we have fleqn as the only option
+del document.header[i]
+else:
+document.header.insert(k, "\\math_number_left 0")
+
+
+def revert_mathnumberside(document):
+" add the document class option leqno"
+regexp = re.compile(r'(\\math_number_left 1)')
+i = find_re(document.header, regexp, 0)
+if i == -1:
+regexp = re.compile(r'(\\math_number_left)')
+j = find_re(document.header, regexp, 0)
+del document.header[j]
+else:
+k = find_token(document.header, "\\options", 0)
+if k != -1:
+   document.header[k] = document.header[k].replace("\\options", 
"\\options leqno,")
+   del document.header[i]
+else:
+l = find_token(document.header, "\\use_default_options", 0)
+document.header.insert(l, "\\options leqno")
+del document.header[i + 1]
+
+
 ##
 # Conversion hub
 #
@@ -2160,10 +2199,12 @@ convert = [
[537, []],
[538, [convert_mathindent]],
[539, []],
-   [540, []]
+   [540, []],
+   [541, [convert_mathnumberside]]
   ]
 
 revert =  [
+   [540, [revert_mathnumberside]],
[539, [revert_rotfloat]],
[538, [revert_baselineskip]],
[537, [revert_mathindent]],
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 9f05fe8156..305f6a8b6b 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -385,6 +385,7 @@ BufferParams::BufferParams()
paragraph_separation = ParagraphIndentSeparation;
is_math_indent = false;
math_indentation = "default";
+   math_number_left = false;
quotes_style = InsetQuotesParams::EnglishQuotes;
dynamic_quotes = false;
fontsize = "default";
@@ -839,6 +840,8 @@ string BufferParams::readToken(Lexer & lex, string const & 
token,
lex >> is_math_indent;
} else if (token == "\\math_indentation") {
lex >> math_indentation;
+   } else if (token == "\\math_number_left") {
+   lex >> math_number_left;
} else if (token == "\\quotes_style") {
string qstyle;
lex >> qstyle;
@@ -1339,6 +1342,7 @@ void BufferParams::writeFile(ostream & os, Buffer const * 
buf) const
os << "\n\\is_math_indent " << is_math_indent;
if (is_math_indent && math_indentation != "default")
os << "\n\\math_indentation " << math_indentation;
+   os << "\n\\math_number_left " << math_number_left;
os << "\n\\quotes_style "
   << string_quotes_style[quotes_style]
   << "\n\\dynamic_quotes " << dynamic_quotes
@@ -1623,6 +1627,9 @@ bool BufferParams::writeLaTeX(otexstream & os, 
LaTeXFeatures & features,
if (is_math_indent)
clsoptions << "fleqn,";
 
+   if (math_number_left)
+   clsoptions << "leqno,";
+
// language should be a parameter to \documentclass
if (language->babel() == "hebrew"
&& default_language->babel() != "hebrew")
diff --git a/src/BufferParams.h b/src/BufferParams.h
index