Re: LyX 2.4.0
On 2021-12-06 17:58, Richard Kimberly Heck wrote: Do that, and I'll plan to package beta 1 later this week after looking over Daniel's patches. Riki Can't promise to be able to do it this week but I'll certainly try... Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ar/Intro (default XeTeX) fails on updated system
On Sun, Dec 05, 2021 at 05:50:55PM +0100, Kornel Benko wrote: > Am Sun, 5 Dec 2021 11:41:52 -0500 > schrieb Scott Kostyshak : > > > On Ubuntu 21.10 with updated TL21, when compiling the Arabic Intro.lyx I > > get an error "Undefined color 'blue'". > > > > It compiles fine on an older system. > > > > Does anyone else see this error? > > > > Scott > > I see it too. Thanks for confirming, Kornel. I'm not sure if it's related but the PDF_Comments tests are failing for me also and with PDF_Comments.lyx I get: Package xcolor Error: Undefined color `note_fontcolor'. Perhaps related is: https://github.com/latex3/xcolor/issues/10 That issue mentions a pull request and a workaround (that I haven't tried). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Footnote size is larger on master (\normalsize is prepended)
On Wed, Dec 08, 2021 at 07:17:03PM +0100, Jean-Marc Lasgouttes wrote:
> Le 03/12/2021 à 17:00, Scott Kostyshak a écrit :
> > On Fri, Dec 03, 2021 at 12:46:13PM +0100, Jean-Marc Lasgouttes wrote:
> > > Le 31/10/2021 � 18:11, Scott Kostyshak a �crit�:
> > > > See the attached file. On master, \normalsize is included inside the
> > > > footnote, which is different from 2.3.x.
> > >
> > > Here is my take on how to properly fix this issue. I do not know however
> > > what it does in other situations. Scott, do you have magic scripts and
> > > tests
> > > to see the effect of this?
> >
> > No magic scripts. All I do is manually compile the 2.3.0 user documents
> > with 2.3.0 (or 2.3.x) and with master and then run 'diffpdf' on the
> > results. I'm not sure it makes sense to test that the LaTeX is
> > equivalent since often there are differences in LyX's LaTeX output that
> > are expected that do not cause a difference in the PDF output. We could
> > imagine some automated tests with e.g. 'comparepdf' (a commandline tool)
> > that I think could check whether the PDF output are the same. We'd have
> > to disable the date showing up.
>
> OK, I have done the main manuals, and found in UserGuide a place where a
> greyedout note was inserted in bold context. This shows that a \normalfont
> was missing in the lyxgreyedout definition, and the updated patch adds that.
I did some brief tests on other documents and it works fine from what I
can see. Small typo: "an non" -> "a non".
> What else could I try to be convinced that it works? Do we have font torture
> tests?
What would font torture tests do? Do you mean different font families,
or documents with things like \textbf{\textit{...{blah}}}?
We do have documents with lots of different languages (and thus
scripts). If this is what you're looking for, look at the files
autotests/export/latex/languages/supported-languages*.lyx
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Export to 2.3.x of French linguistics manual fails to compile on 2.3.x
On Wed, Dec 08, 2021 at 10:22:50AM +0100, Jürgen Spitzmüller wrote: > Am Mittwoch, dem 08.12.2021 um 09:51 +0100 schrieb Jürgen Spitzmüller: > > The other is the reversion with language switches. Might be more > > difficult, I'll check. > > I forgot that language switches in glosses do not work. In the long > run, we should probably allow language switches in LyX (for spell > checking) but output no language markup to LaTeX. Something like an > OmitLangSwitch layout tag. Thanks for the improvement, Jürgen! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0
On Sunday, 5 December 2021 17.43.30 WET Richard Kimberly Heck wrote: > > 3. LyX's configure should not assume 'python' command exists. > > (https://www.mail-archive.com/search?l=mid=20210215004347.vha7nygqpd6g5h > > 5q%40tallinn) > I've asked Pavel to create a wiki to-do list. Or you can do it. All > such things can be added. > > This last one seems very important, actually. I already had this problem more than 3 years ago but it was masked because at that time /usr/bin/python was pointing to python2. And then /usr/bin/python was removed from Fedora. Now it has returned as an optional package that points to the latest 3.x version (with x==10 in Fedora 35). python-unversioned-command In any case the proposed solutions should be implemented. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Latest self-compiled LyX versions fail to open some documents
No, always¥s the same, whether no windows is open, whether it has the standard size or any other size... Chris > Am 08.12.2021 um 22:32 schrieb Jean-Marc Lasgouttes : > > Le 08/12/2021 à 20:06, Christoph Schmitz a écrit : >> I am attaching one of the documents that can no longer be opened. Do you >> have any idea what could be the cause of the problem? > > Unfortunately, I have an idea :( I pushed big changes in document display. I > will try to see if I can reproduce tomorrow. > > Does the problem goes away if you change the default window width before > loading? > > JMarc > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Latest self-compiled LyX versions fail to open some documents
Le 08/12/2021 à 23:34, Christoph Schmitz a écrit : No, always¥s the same, whether no windows is open, whether it has the standard size or any other size... Believe it or not, this is good news. Hopefully I will be able to reproduce. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Latest self-compiled LyX versions fail to open some documents
Le 08/12/2021 à 20:06, Christoph Schmitz a écrit : I am attaching one of the documents that can no longer be opened. Do you have any idea what could be the cause of the problem? Unfortunately, I have an idea :( I pushed big changes in document display. I will try to see if I can reproduce tomorrow. Does the problem goes away if you change the default window width before loading? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Latest self-compiled LyX versions fail to open some documents
I compile LyX for macOS myself. Since yesterday my compiled versions of LyX do not open several files anymore (on both Intel and M1 Macs). I see the macOS beachball forever, but LyX does not crash. Luckily I found a copy of a previous LyX version, which still works(compiled on Dec 6). This version still works: Version 2.4.0dev (not released yet) Built from git commit hash 53ed3dc0 Qt Version (run-time): 6.2.1 on platform cocoa Qt Version (compile-time): 6.2.1 Today's (and yesterday's) )version do not work anymore: Version 2.4.0dev (not released yet) Built from git commit hash 2eaf30c5 Qt Version (run-time): 6.2.1 on platform cocoa Qt Version (compile-time): 6.2.1 I am attaching one of the documents that can no longer be opened. Do you have any idea what could be the cause of the problem? Chris AristideNo1-300-UserManual-FR.lyx Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: outline pane issues and huge note slowness
Hi Valdemaras, I move this discussion to lyx-devel since you are there too. We have used the bandwidth of this list long enough with technical issues. Le 07/12/2021 à 03:19, sovhist a écrit : Well, I don't see much difference with and without spellcheck. All "words" are with misspelling marks, so this could be a problem, but no. I remember, that earlier, maybe a year or two ago there were lags with text in Lithuanian bigger than in English. But now I can't see bigger differences. OK It is much harder to see lag differences with breakrows branch because you did very good work with large insets :). For me it's not 40% gain, but maybe four times better than without it. Good. FWIW, the patch is in master now :) In flame_1, I do not see much, except maybe the fact that a lot of time is spent accessing the cache (the part with QCache and QHash) of already computing rows. This can be good (already is already computed) or bad (the cache access are very slow), depending on the importance of this part of code in the whole picture. My computer uses ssd (nvme), so cache access shouldn't be a problem though I'm not shure about that. The cache is in memory, but building the key to access it might be expensive. In full.svg, I do not see the time spent painting the screen (what is in flame_2), so I cannot compare it to the time spend computing the position of each element (basically the redoParagraph stuff). It would be good to understand what is too slow. On which part of full.svg should I click that you could see what you need? Basically, I am surprised that I do not see a part of the work (either typesetting or drawing or something else) take a huge amount of time. This is what bothers me is that I cannot read this information from the flames. What is LyX doing that takes so much time? I opened usual file in Lyx with little insets, and scrolled up and down, Htop shows CPU usage about 40% of one core (and it spikes to 80-99% when text in Russian that is marked with spellcheck appears on screen). CPU instantly spikes to 96-98% while scrolling hugenote file with spellcheck marks. I see 86-96% whithout them. That is both in Lithuanian and Egglish, maybe there is some more CPU usage in Lithuanian (I see more 100% with that language than with English, but that could be because different speed of scroll). So it seems it is really LyX (or Qt) One more thing: I see three instances of lyx process in Htop, but only one reacts to scrolling, two other sits calmly and shows 0% of CPU usage. And I see that Lyx uses only one core, not four, only one core spikes. Is that normal? Unfortunately, LyX is not able to use several cores for this kind of work. I am not sure there ismuch to gain here. It does use other processes for running LaTeX, though (so that editing is not blocked while typesetting). I will try to prepare a small patch so that you can run with our internal profiler and we can get numbers. JMarc PS: every time you post to lyx-users, I get ~40 bounces from all our subscribers that use yahoo mail, because of some spam issues. Do you have an idea of why this would be? You are quite special in this respect ;) -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Footnote size is larger on master (\normalsize is prepended)
Le 03/12/2021 à 17:00, Scott Kostyshak a écrit :
On Fri, Dec 03, 2021 at 12:46:13PM +0100, Jean-Marc Lasgouttes wrote:
Le 31/10/2021 � 18:11, Scott Kostyshak a �crit�:
See the attached file. On master, \normalsize is included inside the footnote,
which is different from 2.3.x.
Here is my take on how to properly fix this issue. I do not know however
what it does in other situations. Scott, do you have magic scripts and tests
to see the effect of this?
No magic scripts. All I do is manually compile the 2.3.0 user documents
with 2.3.0 (or 2.3.x) and with master and then run 'diffpdf' on the
results. I'm not sure it makes sense to test that the LaTeX is
equivalent since often there are differences in LyX's LaTeX output that
are expected that do not cause a difference in the PDF output. We could
imagine some automated tests with e.g. 'comparepdf' (a commandline tool)
that I think could check whether the PDF output are the same. We'd have
to disable the date showing up.
OK, I have done the main manuals, and found in UserGuide a place where a
greyedout note was inserted in bold context. This shows that a
\normalfont was missing in the lyxgreyedout definition, and the updated
patch adds that.
What else could I try to be convinced that it works? Do we have font
torture tests?
JMarc
From d64803774ca24546c33e55dd9b22fefbb51ad4d1 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes
Date: Fri, 3 Dec 2021 12:16:40 +0100
Subject: [PATCH] Tentative patch: fix font inside footnote inset
An inset that resets its font (like Footnote) does not care at all
about enclosing font. Therefore the real starting point is the class
default font. This avoid cases where the footnote contents is forced
to \normalsize.
It turns out that the Greyedout note inset, did inherit font but was
declared as not doing it. This commmit changes the definition by
adding \normalfont so that no inheritance happens.
Note that actually \normalfont resets everything but the font size.
This does not matter for footnote (which has its own font size), but
may matter elsewhere, for example Greyedout. Also, I do not know what
the situation with HTML is.
---
src/LaTeXFeatures.cpp | 8
src/OutputParams.h| 21 -
src/Paragraph.cpp | 7 +++
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 0344202c91..abe1ca1d79 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -560,9 +560,9 @@ docstring const lyxgreyedoutDef(bool const rtl, bool const ct, bool const lua, b
ods << " \\if@rl%\n";
ods << "\\everypar{%\n";
if (lua)
- ods << " \\pardir TRT \\textdir TRT\\textcolor{note_fontcolor}\\ignorespaces%\n";
+ ods << " \\pardir TRT \\textdir TRT\\normalfont\\textcolor{note_fontcolor}\\ignorespaces%\n";
else
- ods << " \\textcolor{note_fontcolor}\\beginL\\ignorespaces%\n";
+ ods << " \\normalfont\\textcolor{note_fontcolor}\\beginL\\ignorespaces%\n";
ods << "}%\n";
if (ct)
ods << "\\colorlet{lyxadded}{lyxadded!30}\\colorlet{lyxdeleted}{lyxdeleted!30}%\n";
@@ -573,7 +573,7 @@ docstring const lyxgreyedoutDef(bool const rtl, bool const ct, bool const lua, b
ods << " \\else%\n";
if (ct)
ods << "\\colorlet{lyxadded}{lyxadded!30}\\colorlet{lyxdeleted}{lyxdeleted!30}%\n";
- ods << "\\textcolor{note_fontcolor}\\bgroup\\ignorespaces%\n"
+ ods << "\\normalfont\\textcolor{note_fontcolor}\\bgroup\\ignorespaces%\n"
<< "\\BODY\\ignorespacesafterend\\egroup%\n"
<< " \\fi%\n"
<< "}\n";
@@ -583,7 +583,7 @@ docstring const lyxgreyedoutDef(bool const rtl, bool const ct, bool const lua, b
<< "{";
if (ct)
ods << "\\colorlet{lyxadded}{lyxadded!30}\\colorlet{lyxdeleted}{lyxdeleted!30}%\n ";
- ods << "\\textcolor{note_fontcolor}\\bgroup\\ignorespaces}\n"
+ ods << "\\normalfont\\textcolor{note_fontcolor}\\bgroup\\ignorespaces}\n"
<< "{\\ignorespacesafterend\\egroup}\n";
}
diff --git a/src/OutputParams.h b/src/OutputParams.h
index 7ca5c1ff62..a909ddd925 100644
--- a/src/OutputParams.h
+++ b/src/OutputParams.h
@@ -139,7 +139,26 @@ public:
mutable int inulemcmd = 0;
/** the font at the point where the inset is
- */
+ *
+ * Note from lasgouttes: I have doubts on the semantics of this
+ * variable. Until this is sorted out, here are some notes on the
+ * history of local_font.
+ *
+ * A research that excludes test and assignment [*] shows that
+ * this is only used to remember language, which is a different
+ * story (and not changed by this patch). The only exception being
+ * in InsetMathHull::getCtObject and InsetMathNest::latex to
+ * support change tracking in insets, but I am not 100% sure that
+ * this is required. And historically [**] local_font used to be
+ * local_lang; it may be good to return to this simpler variable
+ * later.
+ *
+ * [*] git grep local_font src|grep -v 'local_font
Jenkins build is back to normal : Build branch "master" » ubuntu-xenial-qt4-autotools-extended #2274
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-xenial-qt4-autotools-extended/2274/ -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: fsanitize: member access within null pointer
Am Tue, 7 Dec 2021 22:20:02 -0500 schrieb Scott Kostyshak : > Compiling master with Clang and fsanitize, I get the following when > LyX starts up (without doing anything else): > > /home/scott/lyxbuilds/master/repo/src/support/socktools.cpp:114:56: runtime > error: > member access within null pointer of type 'struct sockaddr_un' > > Can anyone take a look? > > Scott I see it too with clang, but not with gcc. Kornel pgpnr0hlxVeE6.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Export to 2.3.x of French linguistics manual fails to compile on 2.3.x
Am Mittwoch, dem 08.12.2021 um 09:51 +0100 schrieb Jürgen Spitzmüller: > The other is the reversion with language switches. Might be more > difficult, I'll check. I forgot that language switches in glosses do not work. In the long run, we should probably allow language switches in LyX (for spell checking) but output no language markup to LaTeX. Something like an OmitLangSwitch layout tag. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Export to 2.3.x of French linguistics manual fails to compile on 2.3.x
Am Dienstag, dem 07.12.2021 um 15:01 -0500 schrieb Scott Kostyshak: > Starting with ab5e5e41, if we export the French linguistics manual to > 2.3.x, and then open that in 2.3.x and compile it fails to compile. I > think it's because of language switching. > > I have no idea if this is worth the time to look into but I am still > reporting it. > > Note also that roundtrip (i.e., opening the exported 2.3.x back in > master) also fails to compile. Two issues here: The simple one is to correct some markup in this manual. I did this and also tried to localize the examples. Jean-Pierre, please check. The example now compiles after reversion. The other is the reversion with language switches. Might be more difficult, I'll check. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
