Re: [patch] support for document class option leqno
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
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
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
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
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
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
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
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 Stand
Re: [patch] support for document class option leqno
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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&ts=1493158062&use_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
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&ts=1493158062&use_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
> 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
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
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
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
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
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
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
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 437d00b700..6fdfe3ad31
