Le 16/07/2022 à 12:54, Kornel Benko a écrit :
We would not need to convert _all_ ERT's, only '\\*'.
But OK,
You mean, only when there is no ERT with sole contents "\" just before? :-p
JMarc
PS: tipa does define \*.
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailma
On Sat, 2022-07-16 at 12:54 +0200, Kornel Benko wrote:
> We would not need to convert _all_ ERT's, only '\\*'.
> But OK,
>
> Kornel
FWIW I understand the merit of your suggestion.
What I am saying is that it can be tricky to get it right without
getting into data loss scenarios(our bane in
Am Sat, 16 Jul 2022 11:39:29 +0100
schrieb José Matos :
> On Sat, 2022-07-16 at 12:05 +0200, Kornel Benko wrote:
> > This implies the forward conversion of such ERT's too IMHO.
>
> We never do that in lyx2lyx. We always leave that to tex2lyx.
We do it in the preamble though (for some fonts). F
On Sat, 2022-07-16 at 12:05 +0200, Kornel Benko wrote:
> This implies the forward conversion of such ERT's too IMHO.
We never do that in lyx2lyx. We always leave that to tex2lyx.
The reason is that in order to that minimally we would need to have a
better parsing. Because we would need to parse t
Am Sat, 16 Jul 2022 10:06:38 +0100
schrieb José Matos :
> On Fri, 2022-07-15 at 19:32 +0200, Pavel Sanda wrote:
> > Also it would need to conversion routine in lyx2lyx for conversion
> > between different LyX versions (see e.g. commit 0ea9df7467a9b).
>
> This should be a very simple conversion
On Fri, 2022-07-15 at 19:32 +0200, Pavel Sanda wrote:
> Also it would need to conversion routine in lyx2lyx for conversion
> between different LyX versions (see e.g. commit 0ea9df7467a9b).
This should be a very simple conversion since the forward conversion
will be empty and the backward conversio
On Fri, Jul 15, 2022 at 08:17:35PM +0200, Jean-Marc Lasgouttes wrote:
> >>My specific use case for this is for short stanzas in a verse
> >>environment: \\* will prevent a page break in the middle of a stanza.
> >>
> >>For lack of a better term I've called this "Starred line break" though
> >>I'm s
Le 15/07/2022 à 19:32, Pavel Sanda a écrit :
Dear Chris,
welcome here and sorry for the late reply.
Hello Chris,
I can only agree with Pavel that we should have answered faster.
My specific use case for this is for short stanzas in a verse
environment: \\* will prevent a page break in the m
Dear Chris,
welcome here and sorry for the late reply.
On Mon, Jun 06, 2022 at 05:46:32PM -0700, Chris Spiegel wrote:
> I'm attaching two patches, one against git master, the other against
> the 2.3.x branch. These patches add a starred new line break
> formatting option (\\*) to complement "Ragg
I'm attaching two patches, one against git master, the other against
the 2.3.x branch. These patches add a starred new line break
formatting option (\\*) to complement "Ragged line break", i.e. the \\
macro.
My specific use case for this is for short stanzas in a verse
environment: \\* will preven
Am Di., 15. Dez. 2020 um 05:34 Uhr schrieb Richard Kimberly Heck <
rikih...@lyx.org>:
> Fixed. Not sure what I was thinking.
>
Thank you.
Jürgen
>
> Riki
>
>
>
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 12/12/20 12:08 PM, Richard Kimberly Heck wrote:
On 12/12/20 4:02 AM, Jürgen Spitzmüller wrote:
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
Closing ERT inset produces thin box with no text visible.
This one's not caused by this patch. I suspect it has been introduced
by 16
Am Sonntag, dem 13.12.2020 um 13:38 +0100 schrieb Stephan Witt:
> With the attached patch I’m seeing this:
>
> frontends/qt/GuiApplication.cpp (2836): application palette change
> frontends/qt/GuiView.cpp (1433): application palette change
> frontends/qt/GuiView.cpp (1436): main window palette ch
> Am 13.12.2020 um 12:57 schrieb Jürgen Spitzmüller :
>
> Am Sonntag, dem 13.12.2020 um 11:01 +0100 schrieb Stephan Witt:
>> I’ll do some investigation how to detect the switch from or to dark
>> mode at runtime.
>> I think it’s worth to afford - see the effect below. (Switch from
>> dark mode
Am Sonntag, dem 13.12.2020 um 11:01 +0100 schrieb Stephan Witt:
> I’ll do some investigation how to detect the switch from or to dark
> mode at runtime.
> I think it’s worth to afford - see the effect below. (Switch from
> dark mode back to normal.)
I agree. It's probably not hard if we know whic
Am Samstag, dem 12.12.2020 um 15:05 +0100 schrieb Jean-Marc Lasgouttes:
> Le 12/12/2020 à 11:02, Jürgen Spitzmüller a écrit :
> > One issue I see is that the IconInfo inset does not use the adapted
> > icons; it loads the icon files directly via graphic inset.
> >
> > This could be fixed by using
On Friday, December 11, 2020 6:50:49 PM WET Jürgen Spitzmüller wrote:
> Dear all
>
> The attached patch addresses #8325 and adds support for dark mode in
> the workarea.
I tried the committed version. The improvement is striking, in some cases the
difference is between not to be able to read the
On 12/12/20 4:02 AM, Jürgen Spitzmüller wrote:
> Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
>> Closing ERT inset produces thin box with no text visible.
> This one's not caused by this patch. I suspect it has been introduced
> by 16834a32ad (Use LOCK symbol with Minimalistic dec
Am Samstag, dem 12.12.2020 um 14:54 +0100 schrieb Pavel Sanda:
> I can change those few cases mentioned if you don't mind.
Go ahead. Note, though, that I already tried to address those, so
please re-check with master before changing.
Jürgen
signature.asc
Description: This is a digitally signed
Le 12/12/2020 à 11:02, Jürgen Spitzmüller a écrit :
One issue I see is that the IconInfo inset does not use the adapted
icons; it loads the icon files directly via graphic inset.
This could be fixed by using a QPixmap (or QImage) via QPainter
instead. Then we can just do the same overlay we do f
On Sat, Dec 12, 2020 at 09:23:23AM +0100, Jürgen Spitzmüller wrote:
> Thanks. As I said, colors are just tentative now. They should be
> adapted by someone who uses dark mode once this is committed.
I can change those few cases mentioned if you don't mind. Pavel
--
lyx-devel mailing list
lyx-deve
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> The icons inserted via insetinfo in manual are invisible (completely
> black), eg. section 13 in math manual.
One issue I see is that the IconInfo inset does not use the adapted
icons; it loads the icon files directly via graphic ins
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> Closing ERT inset produces thin box with no text visible.
This one's not caused by this patch. I suspect it has been introduced
by 16834a32ad (Use LOCK symbol with Minimalistic decoration, too.).
Riki?
Jürgen
signature.asc
Descr
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> I needed to override isDarkMode() to true to
> see the dark mode at all. All my toolbar stay in light mode, not sure
> how to turn them to dark mode here).
You need to manually select a dark qt theme via (e.g.
QT_STYLE_OVERRIDE=adwai
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> I am somewhat confused that that content of greyed out is (too) dark
> blue in math manual, but when I create greyedout inset in completely
> new file the color is (correctly) grey.
The reason is that a custom color for greyedout tex
Am Freitag, dem 11.12.2020 um 15:17 -0500 schrieb Richard Kimberly
Heck:
> I also don't use dark mode, but the approach seems right. One
> question I
> had, though, is whether it is better to adapt the icons on the fly
> (which needs processing power) or to write some script that would
> convert th
Am Freitag, dem 11.12.2020 um 22:49 +0100 schrieb Pavel Sanda:
> On Fri, Dec 11, 2020 at 07:50:49PM +0100, Jürgen Spitzmüller wrote:
> > Thoughts?
>
> I gave it a try. The labels on (foot/lyx/comment/margin)notes are
> hard to read
> because the text is too light or not enough intense (margin) IMH
On Fri, Dec 11, 2020 at 07:50:49PM +0100, Jürgen Spitzmüller wrote:
> Thoughts?
I gave it a try. The labels on (foot/lyx/comment/margin)notes are hard to read
because the text is too light or not enough intense (margin) IMHO.
I am somewhat confused that that content of greyed out is (too) dark bl
On 12/11/20 1:50 PM, Jürgen Spitzmüller wrote:
> Dear all
>
> The attached patch addresses #8325 and adds support for dark mode in
> the workarea.
>
> This adds another color to the ColorSet, x11darkhexname, and adds
> colors that work well with dark background for the semantic (not the
> static) c
On 12/16/2017 07:40 PM, Uwe Stöhr wrote:
> El 16.12.2017 a las 23:45, Richard Heck escribió:
>
>> I know it's late for a format change, but what about including this in
>> 2.3.0?
>
> I am opposed to this because this would change strings. I mean the
> user can simply add \usepackage{paratype} to th
El 16.12.2017 a las 23:45, Richard Heck escribió:
I know it's late for a format change, but what about including this in
2.3.0?
I am opposed to this because this would change strings. I mean the user
can simply add \usepackage{paratype} to the preamble to use it for all
fonts. I can also cre
On 12/14/2017 06:15 PM, Uwe Stöhr wrote:
> Yuriy asked if LyX could support the paratype fonts
> https://ctan.org/pkg/paratype
> to offer an outline font alternative for the computer modern fonts for
> Cyrillic.
>
> This is in my opinion a good idea and so I created the applied patch.
> This is a f
On Sat, Dec 16, 2017 at 05:06:41PM +, Uwe Stöhr wrote:
> El 16.12.2017 a las 06:27, Pavel Sanda escribió:
>
> > I was about to ask the same, please don't break portability of files
> > until 2.3 is out if possible.
>
> OK.
>
> By the way, why don't we release RC1 right now? Did I miss someth
El 16.12.2017 a las 06:27, Pavel Sanda escribió:
I was about to ask the same, please don't break portability of files
until 2.3 is out if possible.
OK.
By the way, why don't we release RC1 right now? Did I miss something?
thanks and regards
Uwe
Richard Heck wrote:
> So I guess I'd suggest we wait to commit any format changes to master
> until 2.3 is released. Any other thoughts?
I was about to ask the same, please don't break portability of files
until 2.3 is out if possible.
Pavel
On 12/14/2017 06:15 PM, Uwe Stöhr wrote:
> Yuriy asked if LyX could support the paratype fonts
> https://ctan.org/pkg/paratype
> to offer an outline font alternative for the computer modern fonts for
> Cyrillic.
>
> This is in my opinion a good idea and so I created the applied patch.
> This is a f
Yuriy asked if LyX could support the paratype fonts
https://ctan.org/pkg/paratype
to offer an outline font alternative for the computer modern fonts for
Cyrillic.
This is in my opinion a good idea and so I created the applied patch.
This is a fileformat change. As it is the first fileformat cha
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.
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 number
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...
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
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 implemen
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 i
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
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 jus
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
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 r
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
> m
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 n
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
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 thi
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
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.
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 w
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 mentio
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 n
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 neithe
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
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
wou
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 t
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
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
> 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 no
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
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 t
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 "m
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
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
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 somet
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 th
On 2017-04-12, Richard Heck wrote:
> On 04/12/2017 06:10 AM, Guenter Milde wrote:
...
... if there is no added value in a LyX-specific interface, it's
better to keep the "advanced" and "exotic" settings for the user
preamble. Then, users can drag-and-drop LaTeX solutions from
On 04/12/2017 06:10 AM, Guenter Milde wrote:
> On 2017-04-11, Richard Heck wrote:
>> On 04/11/2017 04:20 PM, Guenter Milde wrote:
>>> On 2017-04-11, PhilipPirrip wrote:
On 04/11/2017 11:23 AM, Stephan Witt wrote:
My proposal of having "a general sheet where one could send options to
On 2017-04-11, Richard Heck wrote:
> On 04/11/2017 04:20 PM, Guenter Milde wrote:
>> On 2017-04-11, PhilipPirrip wrote:
>>> On 04/11/2017 11:23 AM, Stephan Witt wrote:
>>> My proposal of having "a general sheet where one could send options to
>>> (the calls of) this and that package would be a go
Am Mittwoch, den 12.04.2017, 00:09 +0200 schrieb Uwe Stöhr:
> El 11.04.2017 a las 08:30, Jürgen Spitzmüller escribió:
>
> > And I tried to argue that I think these line edits are not a
> > suitable
> > UI.
>
> Hi Jürgen,
>
> now I get your point. Then I retract my patch.
>
> Scott announced yes
El 11.04.2017 a las 08:30, Jürgen Spitzmüller escribió:
And I tried to argue that I think these line edits are not a suitable
UI.
Hi Jürgen,
now I get your point. Then I retract my patch.
Scott announced yesterday a plan for LyX 2.3.0 so it is indeed too late
for LyX 2.3.0 to do something.
On 04/11/2017 04:20 PM, Guenter Milde wrote:
> On 2017-04-11, PhilipPirrip wrote:
>> On 04/11/2017 11:23 AM, Stephan Witt wrote:
>> My proposal of having "a general sheet where one could send options to
>> (the calls of) this and that package would be a good way to go - that
>> means, not by just
On 2017-04-11, PhilipPirrip wrote:
> On 04/11/2017 11:23 AM, Stephan Witt wrote:
> My proposal of having "a general sheet where one could send options to
> (the calls of) this and that package would be a good way to go - that
> means, not by just using \SendOptionsToPackage" will be a freestyle
Am Dienstag, den 11.04.2017, 11:52 -0400 schrieb PhilipPirrip:
> What I understood Juergen said is: one should have clickable buttons
> for
> every possible option, and no other way of passing options to the
> packages.
Where did I state this?
> What I'm saying, agreeing with Uwe, is that having
On 04/11/2017 11:23 AM, Stephan Witt wrote:
> In fact you agree with Jürgen, IMO. He said it’s not enough to add a
line edit to add the options.
What I understood Juergen said is: one should have clickable buttons for
every possible option, and no other way of passing options to the packages.
Am 11.04.2017 um 16:25 schrieb PhilipPirrip :
>
> On 04/11/2017 02:30 AM, Jürgen Spitzmüller wrote:
>> And I tried to argue that I think these line edits are not a suitable
>> UI.
>> It is much more different, since the line edit are supposed complex
>> key-value pairs.
>
> Let me disagree with y
On 04/11/2017 02:30 AM, Jürgen Spitzmüller wrote:
And I tried to argue that I think these line edits are not a suitable
UI.
It is much more different, since the line edit are supposed complex
key-value pairs.
Let me disagree with you on this, Juergen. As a long-time user, I too
often missed be
Am Dienstag, den 11.04.2017, 08:30 +0200 schrieb Jürgen Spitzmüller:
> Am Montag, den 10.04.2017, 00:44 +0200 schrieb Uwe Stöhr:
> > I don't understand. We are talking about 3 simple line edits.
>
> And I tried to argue that I think these line edits are not a suitable
> UI.
>
> > As you can
> >
Am Montag, den 10.04.2017, 01:47 +0200 schrieb Uwe Stöhr:
> It is like with bug
> http://www.lyx.org/trac/ticket/8034
> , we wait for years now and I don't see a reason why we don't start
> to
> implement the possibilities to add options to fontspec and also to
> polyglossia now.
Yes, but puttin
Am Montag, den 10.04.2017, 00:44 +0200 schrieb Uwe Stöhr:
> I don't understand. We are talking about 3 simple line edits.
And I tried to argue that I think these line edits are not a suitable
UI.
> As you can
> see in the patch, this not a massive change in anything. It is just
> to
> provide
Le 08/04/2017 à 04:58, Uwe Stöhr a écrit :
El 07.04.2017 a las 10:51, Jean-Marc Lasgouttes escribió:
Maybe more like:...
Thanks.
The patch is now in including this hint and the new BLS unit is
available for all lengths.
Thanks.
JMarc
El 10.04.2017 a las 00:44, Uwe Stöhr escribió:
And that way I googled around. Googling brings you quickly to the
"Script=Devanagari option. So one doesn't need to be a TeXpert to find
this. One now only needs an input field for that option. When this is
implemented I can update our Wiki pages
El 09.04.2017 a las 10:27, Jürgen Spitzmüller escribió:
In any case, such features need to be implemented at the beginning of
new development cycles, since they need testing and improvement, not at
the end of cycles.
I don't understand. We are talking about 3 simple line edits. As you can
see
Am Freitag, den 07.04.2017, 00:44 +0200 schrieb Uwe Stöhr:
> Since many years LyX misses the feature to input options to the font
> loading commands \setmainfont etc. We did not act for 5 years
> because
> you said exactly the same as today that it is not the right time:
> http://www.lyx.org/trac
El 07.04.2017 a las 13:30, Helge Hafting escribió:
Do you want to have the BLS unit for all lengths,
no matter if for vertical or horizontal?
Yes, please.
To be consistent with existing lengths/heights, and because it is useful
sometimes. No need for artifical limitations.
I put it in that
El 07.04.2017 a las 10:51, Jean-Marc Lasgouttes escribió:
Maybe more like:...
Thanks.
The patch is now in including this hint and the new BLS unit is
available for all lengths.
regards Uwe
Le 07/04/2017 à 02:03, Uwe Stöhr a écrit :
OK, what about this?:
Maybe more like:
// baselineskip is approx. 1.2 times the font size for the cmr fonts
// The value actually depends on the current paragraph (see
TextMetrics::setRowHeight), but we do not have this information here.
result = va
El 06.04.2017 a las 10:50, Jean-Marc Lasgouttes escribió:
Concerning the code in Length::inInch: the value normally needs to take
into account the line spacing setting of the document. I understand that
it is difficult to obtain here, but a minimal action would be to
document this shortcoming in
El 06.04.2017 a las 09:41, Jean-Marc Lasgouttes escribió:
Le 06/04/2017 à 08:08, Pavel Sanda a écrit :
I don't have strong opinion whether BLS should or shouldn't be available
for both horizontal and vertical. I however dislike the code you posted.
The easy way how to 'fix' it is to drop all th
El 06.04.2017 a las 12:01, Jürgen Spitzmüller escribió:
I mean we need to think about a sensible UI instead of cluttering the
dialog with three more line widgets. And I think we should not attempt to
push in one feature after the other at this point, but rather focus on
stabilizing and finishing
2017-04-06 9:31 GMT+02:00 Uwe Stöhr :
>
> *From: *Jürgen Spitzmüller
> *Sent: *Donnerstag, 6. April 2017 08:53
>
> > This looks rather ugly. I think we should integrate this properly for
> 2.4 and not hectically push something into 2.3.
>
> What do you mean? This is what I always wanted to do sin
Le 02/04/2017 à 14:52, Uwe Stöhr a écrit :
After only 7 years ;-) I found time to finish a patch to support
\baselineskip, see attached. The patch is a fileformat change.
\baselineskip is the distance between the baseline of 2 subsequent text
lines in a paragraph. Therefore \vspace{\baselineskip
Le 06/04/2017 à 08:08, Pavel Sanda a écrit :
I don't have strong opinion whether BLS should or shouldn't be available
for both horizontal and vertical. I however dislike the code you posted.
The easy way how to 'fix' it is to drop all these removeUnits on various
places and thus effectively allow
This looks rather ugly. I think we should integrate this properly for 2.4
and not hectically push something into 2.3.
Jürgen
2017-04-06 3:26 GMT+02:00 Uwe Stöhr :
> El 06.04.2017 a las 03:24, Uwe Stöhr escribió:
>
> Attached is the screenshot of the simple UI.
>>
>
> Now it is attached.
>
> rega
Uwe Stöhr wrote:
>>> + // remove baselineskip from width units
>>> + columnWidthUnitLC->removeUnit(Length::BLS);
>>> + tabularWidthUnitLC->removeUnit(Length::BLS);
>>
>> This is ugly.
>>
>> Unless you want to be consistent and do it for all 'senseless' combinations
>> of vert/horiz spacing u
1 - 100 of 691 matches
Mail list logo
