Re: Python compiler infects "immutable" bundle - how to avoid it?
Am 22.02.2020 um 20:13 schrieb Guenter Milde : > > On 2020-02-22, Stephan Witt wrote: >> Am 22.02.2020 um 03:35 schrieb Richard Kimberly Heck : >>> On 2/21/20 12:08 PM, Stephan Witt wrote: Am 21.02.2020 um 12:08 schrieb Stephan Witt : > Hi pythonists, > > I’m trying to make ready for code signing on Mac. > > The idea of code signing is to ship the package with a digital > signature to guarantee the integrity of the software. > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html > > The problem now is arising: the python scripts LyX is using > are compiled on the fly and the result is placed inside the > package. That way the package looses its integrity. > > Is there any suggestion how to handle this? > > Under Linux, AFAIK, the *.pyc files are not shipped with the package but > created by a post-install script. This way, the package can be checked > against the signature (before installation) but the byte-compiled files are > there once users start to use LyX. Yes, after the first run the signature is valid but the contents isn’t clean anymore. That’s not nice, IMO. ... ATM I cannot see any performance issues. > > One of the more critical cases would be opening a small but really old file > so that lyx2lyx needs most of the rather big modules. Of course, the effect > will be more visible with a HDD than with an SSD. Frankly, I think it’s more a matter of CPU power than disk performance. On my system the call "python -m py_compile configure.py“ lasts about 50 msecs real time and the whole configure process is much longer. The lyx_2_4.py compilation takes 70 msecs. >>> On Windows, we compile the Python files at installation. I don't know if >>> that could help. > >> On Mac I'd prefer to avoid that. The python executable is not part of the >> software bundle and therefore its version at runtime is unknown. > > But one compatible Python version should be installed before installing > LyX, right? Python 2.7 is part of the OS. And this is subject to change. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
On Tue, Feb 18, 2020 at 07:55:13PM +0100, Enrico Forestieri wrote: > > Still, why realPath() returns a short path name in one case and not in the > other case remains a mystery. Mystery solved. On Windows, our implementation of realPath() works only with file names but does not work with directory names. On the other hand, QFileInfo::canonicalFilePath() does not resolve junctions (directory symlinks). -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
On Thu, Feb 20, 2020 at 08:24:41AM +0100, Enrico Forestieri wrote: > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote: > > > > What I wonder: there are the Qt elements used. Why don’t we rely > > on the services of QFileInfo class? E.g. canonicalFilePath() and > > friends? Are there historical reasons only? > > Yes, at the time it was not possible using Qt in src/support. Hmmm. That does not seem to be the only reason. I now checked QFileInfo::canonicalFilePath() and it does not work on Windows. I created a junction but it is not resolved. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [ANNOUNCE] LyX 2.3.4.2 'Emergency' Release
LyX version 2.3.4.3 work well in Windows 10 (Home Version 1909) as of my tests.Slowness in saves seems to have disappeared. Thanks for the new update. H. Ben On Thursday, February 20, 2020, 07:53:39 AM GMT+1, Liviu Andronic wrote: On 2/11/20, Richard Kimberly Heck wrote: > > This is an emergency release that fixes four bugs in 2.3.4. Only the > first two really warrant an emergency release, but while we're at it... > Ubuntu packages are now available on the PPA: https://launchpad.net/~lyx-devel/+archive/ubuntu/release Liviu > The first, bug #11728, caused a five-second delay when attempting > to save files on Windows. This was a side effect of the fix for #10091 > and reminds us why it would be good to have more testing on Windows. > > The second bug is discussed in this thread > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg210294.html > and concerns a crash related to the math toolbar. This was due to an > uninitialize buffer_ member revealed by the fix for #11586. > > The third, bug #11724, affects Beamer presentations and causes bad output > when page geometry is set in certain ways. LyX should and how does ignore > such settings. > > The last, bug #11579, is an old one, but a serious one, that prevents > the use of CJKUtf8 in ERT. It's a straightforward fix for a bug that is > pretty serious for people who encounter it. > > All LyX users are encouraged to upgrade to 2.3.4.2. > > -- > lyx-users mailing list > lyx-us...@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-users > -- 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: Ctest failing on updated TL19
Am Sat, 22 Feb 2020 14:48:50 -0500 schrieb Scott Kostyshak : > On Sat, Feb 22, 2020 at 07:20:18PM -, Guenter Milde wrote: > > On 2020-02-21, Scott Kostyshak wrote: > > > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > > > The following ctest fails on an updated TeX Live 2019: > > > > > Multilingual_Typesetting_with_CJKutf8_pdf4_systemF > > > > > Kornel and I get the following errors: > > > > > LaTeX.cpp (787): Log line: Missing character: There is no χ in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no α in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ρ in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ε in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no τ in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no σ in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no μ in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ό in font > > > grmn1000! > > > LaTeX.cpp (787): Log line: Missing character: There is no ς in font > > > grmn1000! > > > > > > Strange. What is "grmn1000"? > > $ locate -i grmn1000 > /usr/local/texlive/2019/texmf-dist/doc/fonts/cbfonts/grmn1000table.pdf > /usr/local/texlive/2019/texmf-dist/fonts/source/public/cbfonts/grmn1000.mf > /usr/local/texlive/2019/texmf-dist/fonts/tfm/public/cbfonts/grmn1000.tfm > /usr/local/texlive/2019/texmf-dist/fonts/type1/public/cbfonts/grmn1000.pfb > scott:~$ > > > Here, the main (non-CJK) font is set to DejaVu, for both 8-bit and "non-TeX" > > fonts. Or did DejaVu drop the Greek support? > > I don't know, but I don't think the change in pass -> fail is due to an > update in the Ubuntu repos. I have a 19.10 installation with an updated > system (i.e., Ubuntu is updated as per apt-get) and an out-dated TeX > Live 2019, where the test passes. > > So my guess is that the failure occures because of an updated TL > package. > > Scott What's more, all these files are in TL19 + ... + TL13 unchanged. Kornel pgpmZQA0uS0Hn.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Ctest failing on updated TL19
On Sat, Feb 22, 2020 at 07:20:18PM -, Guenter Milde wrote: > On 2020-02-21, Scott Kostyshak wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > The following ctest fails on an updated TeX Live 2019: > > > Multilingual_Typesetting_with_CJKutf8_pdf4_systemF > > > Kornel and I get the following errors: > > > LaTeX.cpp (787): Log line: Missing character: There is no χ in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no α in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ρ in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ε in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no τ in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no σ in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no μ in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ό in font > > grmn1000! > > LaTeX.cpp (787): Log line: Missing character: There is no ς in font > > grmn1000! > > > Strange. What is "grmn1000"? $ locate -i grmn1000 /usr/local/texlive/2019/texmf-dist/doc/fonts/cbfonts/grmn1000table.pdf /usr/local/texlive/2019/texmf-dist/fonts/source/public/cbfonts/grmn1000.mf /usr/local/texlive/2019/texmf-dist/fonts/tfm/public/cbfonts/grmn1000.tfm /usr/local/texlive/2019/texmf-dist/fonts/type1/public/cbfonts/grmn1000.pfb scott:~$ > Here, the main (non-CJK) font is set to DejaVu, for both 8-bit and "non-TeX" > fonts. Or did DejaVu drop the Greek support? I don't know, but I don't think the change in pass -> fail is due to an update in the Ubuntu repos. I have a 19.10 installation with an updated system (i.e., Ubuntu is updated as per apt-get) and an out-dated TeX Live 2019, where the test passes. So my guess is that the failure occures because of an updated TL package. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LaTeX3 Error: Backend request inconsistent with engine: using 'pdfmode'
Am Sat, 22 Feb 2020 19:04:48 - (UTC) schrieb Guenter Milde : > On 2020-02-22, Kornel Benko wrote: > > Am Sat, 22 Feb 2020 09:44:21 - (UTC) > > schrieb Guenter Milde : > > >> On 2020-02-20, Scott Kostyshak wrote: > >> > On Mon, Feb 03, 2020 at 04:44:07PM +0100, Kornel Benko wrote: > >> >> Am Mon, 3 Feb 2020 10:42:06 -0500 > >> >> schrieb Scott Kostyshak : > >> >> > On Mon, Feb 03, 2020 at 04:29:34PM +0100, Kornel Benko wrote: > > >> ... > > >> > I tested on an updated TL. Removing the custom class option dvips fixes > >> > it. However, I'm not sure this is the right thing to do. In the inverted > >> > tests, we have the following: > > >> > # Comment by Jürgen Spitzmüller > >> > # The document requests the dvips graphics driver, > >> > # and of course this fails with any other backend. > >> > # > >> > # The document compiles if one sets the graphics driver to "Automatic" > >> > # and remove the dvips class option. But then, the output is not > >> > correct > >> > # (rotation of foils does not work). > >> > export/examples/(|fr/)Presentations/Foils_pdf[45]_systemF > > >> > The output does not seem to change with or without the option for pdf2 > >> > format, but the above comment suggests it does for other formats. > > >> Could you please test export to Postscript or PDF (ps2pdf) and check the > >> orientation of rotated pages in the output? > > > > No visible differences. > > 'diffpdf' finds some, but only some glyphs are there, see attached. > > If it is/looks right with "auto" now, then it should be save to change from > "dvips" to "auto" and remove the clause and comment from "invertedTests". > > Günter > Looks OK for examples/Presentations/Foils.lyx but not for examples/fr/Presentations/Foils.lyx PDF (xetex) (system fonts) OK PDF (luatex) (system fonts) OK PDF (luatex) (tex fonts) gives following error ... LaTeX Font Info:Checking defaults for U/cmr/m/n on input line 43. LaTeX Font Info:... okay on input line 43. LaTeX Info: Redefining \dots on input line 43. LaTeX Info: Redefining \up on input line 43. LaTeX Font Info:Font shape `T1/fcmss/b/n' in size <29.86> not available (Font) Font shape `T1/fcmss/bx/n' tried instead on input line 49. ! error: (linebreak): invalid list tail, probably missing glue ! ==> Fatal error occurred, no output PDF file produced! Kornel pgplsJagjEEss.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Ctest failing on updated TL19
On 2020-02-21, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > The following ctest fails on an updated TeX Live 2019: > Multilingual_Typesetting_with_CJKutf8_pdf4_systemF > Kornel and I get the following errors: > LaTeX.cpp (787): Log line: Missing character: There is no χ in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no α in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ρ in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ε in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no τ in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ι in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no σ in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no μ in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ό in font > grmn1000! > LaTeX.cpp (787): Log line: Missing character: There is no ς in font > grmn1000! Strange. What is "grmn1000"? Here, the main (non-CJK) font is set to DejaVu, for both 8-bit and "non-TeX" fonts. Or did DejaVu drop the Greek support? Günter -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Python compiler infects "immutable" bundle - how to avoid it?
On 2020-02-22, Stephan Witt wrote: > Am 22.02.2020 um 03:35 schrieb Richard Kimberly Heck : >> On 2/21/20 12:08 PM, Stephan Witt wrote: >>> Am 21.02.2020 um 12:08 schrieb Stephan Witt : Hi pythonists, I’m trying to make ready for code signing on Mac. The idea of code signing is to ship the package with a digital signature to guarantee the integrity of the software. https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html The problem now is arising: the python scripts LyX is using are compiled on the fly and the result is placed inside the package. That way the package looses its integrity. Is there any suggestion how to handle this? Under Linux, AFAIK, the *.pyc files are not shipped with the package but created by a post-install script. This way, the package can be checked against the signature (before installation) but the byte-compiled files are there once users start to use LyX. >>> ... ATM I cannot see any performance issues. One of the more critical cases would be opening a small but really old file so that lyx2lyx needs most of the rather big modules. Of course, the effect will be more visible with a HDD than with an SSD. >> On Windows, we compile the Python files at installation. I don't know if >> that could help. > On Mac I'd prefer to avoid that. The python executable is not part of the > software bundle and therefore its version at runtime is unknown. But one compatible Python version should be installed before installing LyX, right? ... Günter -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Standard key binding for SyncTeX forward-search?
Since compiling is "Ctrl + R" I use \bind "M-r" "forward-search" "Alt + R" for forward search. H. Ben On Friday, February 21, 2020, 11:54:41 PM GMT+1, Jean-Marc Lasgouttes wrote: Le 21/02/2020 à 07:38, Stephan Witt a écrit : > Skim uses Ctrl-Shift-Click (aka Command-Shift-Click) on Mac. > I thought about hard coding it already but had qualms about it. > > Standard X-desktop applications on Unix are able to bind actions > on mouse event too. Would it be a honorable goal to make this > with LyX possible? This is something that should have been done a long time ago. It might even be that Qt has support for doing this. But currently mouse events are very different from key events, and I do not really know why. 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: LaTeX3 Error: Backend request inconsistent with engine: using 'pdfmode'
On 2020-02-22, Kornel Benko wrote: > Am Sat, 22 Feb 2020 09:44:21 - (UTC) > schrieb Guenter Milde : >> On 2020-02-20, Scott Kostyshak wrote: >> > On Mon, Feb 03, 2020 at 04:44:07PM +0100, Kornel Benko wrote: >> >> Am Mon, 3 Feb 2020 10:42:06 -0500 >> >> schrieb Scott Kostyshak : >> >> > On Mon, Feb 03, 2020 at 04:29:34PM +0100, Kornel Benko wrote: >> ... >> > I tested on an updated TL. Removing the custom class option dvips fixes >> > it. However, I'm not sure this is the right thing to do. In the inverted >> > tests, we have the following: >> > # Comment by Jürgen Spitzmüller >> > # The document requests the dvips graphics driver, >> > # and of course this fails with any other backend. >> > # >> > # The document compiles if one sets the graphics driver to "Automatic" >> > # and remove the dvips class option. But then, the output is not correct >> > # (rotation of foils does not work). >> > export/examples/(|fr/)Presentations/Foils_pdf[45]_systemF >> > The output does not seem to change with or without the option for pdf2 >> > format, but the above comment suggests it does for other formats. >> Could you please test export to Postscript or PDF (ps2pdf) and check the >> orientation of rotated pages in the output? > No visible differences. > 'diffpdf' finds some, but only some glyphs are there, see attached. If it is/looks right with "auto" now, then it should be save to change from "dvips" to "auto" and remove the clause and comment from "invertedTests". Günter -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Python compiler infects "immutable" bundle - how to avoid it?
On Catalina (10.15.3) /usr/bin/python is symlinged to /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 Python (3 and/or 2) on the Mac is easily installed via Homebrew (i nto /usr/local) So is LyX (as what is called a Cask), and within Homebrew that could lead to a dependency being defined so that if LyX is to be installed Python must also be. greetings, el On 2020-02-22 19:46 , Stephan Witt wrote: > Am 22.02.2020 um 03:35 schrieb Richard Kimberly Heck : >> On 2/21/20 12:08 PM, Stephan Witt wrote: >>> Am 21.02.2020 um 12:08 schrieb Stephan Witt : [...] > The standard on Mac is 2.7.17 with 10.14.6 (Mojave today) and I read > somewhere with 10.15.x (Catalina) python3 is available. But Apple has > announced the removal of python from standard OS: > > "Future versions of macOS won’t include scripting language runtimes by > default, and might require you to install additional packages. If > your software depends on scripting languages, it’s recommended that > you bundle the runtime within the app." > > I’m not sure how difficult it would be to put the python universe into > the LyX app. > > Stephan > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Python compiler infects "immutable" bundle - how to avoid it?
On 2/22/20 12:46 PM, Stephan Witt wrote: > Am 22.02.2020 um 03:35 schrieb Richard Kimberly Heck : >> On 2/21/20 12:08 PM, Stephan Witt wrote: >>> Am 21.02.2020 um 12:08 schrieb Stephan Witt : Hi pythonists, I’m trying to make ready for code signing on Mac. The idea of code signing is to ship the package with a digital signature to guarantee the integrity of the software. https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html The problem now is arising: the python scripts LyX is using are compiled on the fly and the result is placed inside the package. That way the package looses its integrity. Is there any suggestion how to handle this? I thought about to compile and ship the scripts on my system. But this is probably a bad idea - python at runtime can have different version. Is it possible to suppress the on the fly compile process and what’s the price to pay? Or is it possible to direct it to some directory below the .lyx in users home? >>> I've decided to ship the application with readonly directories. >>> That way the python interpreter cannot save the compiled code >>> onto disk to cache the result. ATM I cannot see any performance >>> issues. >> Yes, sorry, I do not know any way to prevent this kind of thing from >> happening. As you >> see, it's just a matter of caching the compilation. >> >> On Windows, we compile the Python files at installation. I don't know if >> that could help. > On Mac I'd prefer to avoid that. The python executable is not part of the > software bundle and therefore its version at runtime is unknown. > > OTOH, the lyx package for Centos 7 (in EPEL) contains the precompiled > python scripts for version 2.x (e.g. configure.pyc). > > https://centos.pkgs.org/7/epel-x86_64/lyx-common-2.2.3-1.el7.noarch.rpm.html > > But Centos 7 comes with python 2.7.5 as stable standard. > > The situation for the packager is more comfortable here. > > The standard on Mac is 2.7.17 with 10.14.6 (Mojave today) and I read > somewhere with 10.15.x (Catalina) python3 is available. But Apple has > announced the removal of python from standard OS: > > "Future versions of macOS won’t include scripting language runtimes by > default, and might require you to install additional packages. If your > software depends on scripting languages, it’s recommended that you bundle the > runtime within the app." > > I’m not sure how difficult it would be to put the python universe into the > LyX app. Actually, I kind of mis-spoke. We actually install Python with LyX on Windows, so we control what version is installed and, in principle, could pre-compile everything before installation and include the pyc files in the bundle. We do this because, I gather, there's some issue about Python detection or getting the right version or something. If we install it, we know a path to it. Anyway, if we do it there, we could presumably something similar on OSX. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Python compiler infects "immutable" bundle - how to avoid it?
Am 22.02.2020 um 03:35 schrieb Richard Kimberly Heck : > > On 2/21/20 12:08 PM, Stephan Witt wrote: >> Am 21.02.2020 um 12:08 schrieb Stephan Witt : >>> Hi pythonists, >>> >>> I’m trying to make ready for code signing on Mac. >>> >>> The idea of code signing is to ship the package with a digital >>> signature to guarantee the integrity of the software. >>> >>> https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html >>> >>> The problem now is arising: the python scripts LyX is using >>> are compiled on the fly and the result is placed inside the >>> package. That way the package looses its integrity. >>> >>> Is there any suggestion how to handle this? >>> >>> I thought about to compile and ship the scripts on my system. >>> But this is probably a bad idea - python at runtime can have >>> different version. Is it possible to suppress the on the fly >>> compile process and what’s the price to pay? Or is it possible >>> to direct it to some directory below the .lyx in users home? >> I've decided to ship the application with readonly directories. >> That way the python interpreter cannot save the compiled code >> onto disk to cache the result. ATM I cannot see any performance >> issues. > > Yes, sorry, I do not know any way to prevent this kind of thing from > happening. As you > see, it's just a matter of caching the compilation. > > On Windows, we compile the Python files at installation. I don't know if > that could help. On Mac I'd prefer to avoid that. The python executable is not part of the software bundle and therefore its version at runtime is unknown. OTOH, the lyx package for Centos 7 (in EPEL) contains the precompiled python scripts for version 2.x (e.g. configure.pyc). https://centos.pkgs.org/7/epel-x86_64/lyx-common-2.2.3-1.el7.noarch.rpm.html But Centos 7 comes with python 2.7.5 as stable standard. The situation for the packager is more comfortable here. The standard on Mac is 2.7.17 with 10.14.6 (Mojave today) and I read somewhere with 10.15.x (Catalina) python3 is available. But Apple has announced the removal of python from standard OS: "Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app." I’m not sure how difficult it would be to put the python universe into the LyX app. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Perl and Indexing? [Re: Building windows installer questions]
On 2/22/20 12:28 AM, Jürgen Spitzmüller wrote: > Am Freitag, den 21.02.2020, 10:56 -0500 schrieb Richard Kimberly Heck: >> On 2/21/20 4:20 AM, Jürgen Spitzmüller wrote: >>> Am Mittwoch, den 19.02.2020, 15:11 -0500 schrieb Richard Kimberly >>> Heck: Jürgen, do you know about this? >>> I know zero about the win installer. >> I meant: Do you know whether there are LaTeX tools we use for >> multiple >> indexes that are themselves written in Perl? > Yes, there's a perl version of splitindex. The package also provides > versions written in different languages (java, C, tex, texLua). > > The manual says: "Distributors should prefer the perl version if they > also provide perl for the installation platform." OK, that sounds like what Uwe was installing Perl for. So TeX Live has a minimal version of Perl that it can install, so no problem there. MiKTeX, on the other hand, seems not to do so. Am I right that the splitindex_command LyXRC variable is not handled in the UI? Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Change to buffer lookup for given temporary files
Am 20.02.2020 um 08:24 schrieb Enrico Forestieri : > > On Wed, Feb 19, 2020 at 10:33:45PM +0100, Stephan Witt wrote: >> >>> Am 18.02.2020 um 19:55 schrieb Enrico Forestieri : >>> >>> On Tue, Feb 18, 2020 at 07:36:54PM +0100, Enrico Forestieri wrote: On Tue, Feb 18, 2020 at 09:43:07AM +0100, Stephan Witt wrote: > > Because I’m unable to test it with other PDF viewers with SyncTeX > support and/or to test it on Linux and Windows I post the patch > and it would be nice if you can test if it breaks something used > to work. It works for me on linux and cygwin, but does not on native windows. Inserting some debug statements just before file_name and realtmp are compared produces the following (I use C:/cygwin/tmp as the tempdir): file_name: C:/cygwin/tmp/LYX_TM~1.VSQ/LYX_TM~1/MANUSC~1.TEX realtmp: C:/cygwin/tmp/lyx_tmpdir.vsQUbXBjkoun Seemingly, the real path of file_name is returned in the short form, while that of realtmp is not. I don't know why. >>> >>> Replacing the following two lines: >>> >>> file_name = os::internal_path(trim(argument.substr(0, i))); >>> file_name = FileName(file_name).realPath(); >>> >>> with >>> file_name = os::internal_path(FileName(trim(argument.substr(0, >>> i))).realPath()); >>> >>> it works also on native windows. >> >> So, with this modification the patch would be acceptable? > > Yes, I think so. I’ve put it in with commit f2f861f017. Thank you for your help. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LaTeX3 Error: Backend request inconsistent with engine: using 'pdfmode'
Am Sat, 22 Feb 2020 09:44:21 - (UTC) schrieb Guenter Milde : > On 2020-02-20, Scott Kostyshak wrote: > > On Mon, Feb 03, 2020 at 04:44:07PM +0100, Kornel Benko wrote: > >> Am Mon, 3 Feb 2020 10:42:06 -0500 > >> schrieb Scott Kostyshak : > >> > On Mon, Feb 03, 2020 at 04:29:34PM +0100, Kornel Benko wrote: > > ... > > > I tested on an updated TL. Removing the custom class option dvips fixes > > it. However, I'm not sure this is the right thing to do. In the inverted > > tests, we have the following: > > > # Comment by Jürgen Spitzmüller > > # The document requests the dvips graphics driver, > > # and of course this fails with any other backend. > > # > > # The document compiles if one sets the graphics driver to "Automatic" > > # and remove the dvips class option. But then, the output is not correct > > # (rotation of foils does not work). > > export/examples/(|fr/)Presentations/Foils_pdf[45]_systemF > > > The output does not seem to change with or without the option for pdf2 > > format, but the above comment suggests it does for other formats. > > Could you please test export to Postscript or PDF (ps2pdf) and check the > orientation of rotated pages in the output? > > Günter > No visible differences. 'diffpdf' finds some, but only some glyphs are there, see attached. Kornel pgpX2OHCZ6e1J.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LaTeX3 Error: Backend request inconsistent with engine: using 'pdfmode'
On 2020-02-20, Scott Kostyshak wrote: > On Mon, Feb 03, 2020 at 04:44:07PM +0100, Kornel Benko wrote: >> Am Mon, 3 Feb 2020 10:42:06 -0500 >> schrieb Scott Kostyshak : >> > On Mon, Feb 03, 2020 at 04:29:34PM +0100, Kornel Benko wrote: ... > I tested on an updated TL. Removing the custom class option dvips fixes > it. However, I'm not sure this is the right thing to do. In the inverted > tests, we have the following: > # Comment by Jürgen Spitzmüller > # The document requests the dvips graphics driver, > # and of course this fails with any other backend. > # > # The document compiles if one sets the graphics driver to "Automatic" > # and remove the dvips class option. But then, the output is not correct > # (rotation of foils does not work). > export/examples/(|fr/)Presentations/Foils_pdf[45]_systemF > The output does not seem to change with or without the option for pdf2 > format, but the above comment suggests it does for other formats. Could you please test export to Postscript or PDF (ps2pdf) and check the orientation of rotated pages in the output? Günter -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
