Re: SVG Icon going to fallback plaintext in Windows
On Mon, May 23, 2016 at 03:07:04AM +0200, Enrico Forestieri wrote: > On Sun, May 22, 2016 at 05:32:05PM -0400, Scott Kostyshak wrote: > > > On Sat, May 07, 2016 at 11:26:33AM +0200, Georg Baum wrote: > > > Shankar Giri wrote: > > > > > > > Bug 2: Specifically for MinGW-W64 pacman repository built Qt libs, the > > > > pixmap.load(path); will fail for SVGs and SVGZs (built without SVG > > > > support). So icons all go blank and instead show fall-back text. My > > > > patch was aiming to only temporarily address Bug 2 not Bug 1. > > > > > > IIRC Enrico stated that SVG support in qt is now a requirement for LyX, > > > due > > > to the change to svg icons. If my memory is correct, then we should > > > mention > > > that in the release notes, and unfortunately the precompiled mingw64 qt > > > is > > > not suitable then. > > > > Enrico can you add a note to the release notes? Or if easier provide > > some text and I will add it. > > Done at 63153b89. Thanks, Scott signature.asc Description: PGP signature
Re: SVG Icon going to fallback plaintext in Windows
On Sun, May 22, 2016 at 05:32:05PM -0400, Scott Kostyshak wrote: > On Sat, May 07, 2016 at 11:26:33AM +0200, Georg Baum wrote: > > Shankar Giri wrote: > > > > > Bug 2: Specifically for MinGW-W64 pacman repository built Qt libs, the > > > pixmap.load(path); will fail for SVGs and SVGZs (built without SVG > > > support). So icons all go blank and instead show fall-back text. My > > > patch was aiming to only temporarily address Bug 2 not Bug 1. > > > > IIRC Enrico stated that SVG support in qt is now a requirement for LyX, due > > to the change to svg icons. If my memory is correct, then we should mention > > that in the release notes, and unfortunately the precompiled mingw64 qt is > > not suitable then. > > Enrico can you add a note to the release notes? Or if easier provide > some text and I will add it. Done at 63153b89. -- Enrico
Re: Fix for using system icons
On Sat, May 21, 2016 at 05:58:11PM -0400, Scott Kostyshak wrote: > There is a patch for > http://www.lyx.org/trac/ticket/10052 > at > http://www.lyx.org/trac/attachment/ticket/10052/10052_alternative.diff > > I'm planning to commit the patch before rc2 unless someone objects. The > patch is simple and has been tested. It's in at 59474837. Scott signature.asc Description: PGP signature
Re: LyX doesn't work with ImageMagick 7
On Mon, May 23, 2016 at 01:57:33AM +0200, Uwe Stöhr wrote: > Am 12.05.2016 um 08:01 schrieb Richard Heck: > > > Uwe, did you reconfigure after this patch? > > Yes. But the problem persists. I'll postpone this to LyX 2.2.1 since I have > not that much time and are busy to fix third-party program bugs to be able > to provide a well-working installer for LyX 2.2.0. I'll therefore sty with > IM 6.9 for LyX 2.2.0. Will you need to make any more commits to master before the release? Scott signature.asc Description: PGP signature
Re: Plan to tag and tar 2.2.0rc2 on Monday
Am 22.05.2016 um 19:44 schrieb Scott Kostyshak: I'm fine either way though, so let's have a vote. Currently the vote count is 2-1 in favor of doing the final release tomorrow instead of RC2. +1 to release directly. regards Uwe
Re: LyX does work with ImageMagick 7
Am 21.05.2016 um 11:27 schrieb Georg Baum: now I found some time to test and it turned out that some information in this thread is wrong. Therefore I removed the warning from release notes again. I would keep it there until we got reports that it really works on all 3 platforms, MacOS, Linux and Windows. 1) Imagemagick 7 does still contain the 'convert' utility. If you install from source on unix, it is simply a symlink to 'magick'. If you use the binary installer on windows, you need to tick the "Install legacy utilities" option in order to install a convert.exe along magick.exe (but for LyX this is no longer needed since we prefer 'magick' if it is available). Interesting. 2) LyX works perfectly with Imagemagick 7. I tested that without the convert symlink. I could not see any difference to IM 6 (and I made sure I deleted the image cache and reconfigured). I guess what might have lead to the assumption that IM 7 does not work is the fact that the info inset produces text output for .svgz images, but an image link for .png images. This should be changed, modern browsers support svg (but may need uncompressing, I don't know). Yes, the latest Firefox can display SVG but not SVGZ. Googling around it turns out that this is the same for IE and Safari. I only found this as solution: http://graphicdesign.stackexchange.com/questions/24797/when-should-i-use-svg-or-svgz-for-my-web-graphics regards Uwe
Re: LyX doesn't work with ImageMagick 7
Am 12.05.2016 um 07:28 schrieb Georg Baum:
$ grep -rw convert development/Win32/packaging/
Thanks Georg,
development/Win32/packaging/installer/include/filelist.nsh:
${FILE}rsvg-convert.exe"
rsvg-convert.exe is a completely different program and not part of IM.
development/Win32/packaging/installer/setup/install.nsh: WriteRegStr
SHCTX "SOFTWARE\Classes\Applications" "AutoRun"
"$INSTDIR\imagemagick\convert.exe $$"
This is the registry entry to install IM. When installing IM7 this line
has to be
WriteRegStr SHCTX "SOFTWARE\Classes\Applications" "AutoRun"
"$INSTDIR\imagemagick\magick.exe $$"
When reporting the IM7 problems I had the standalone version of IM7
installed and LyX correctly recognized it.
development/Win32/packaging/installer/setup/configure.nsh: # if
Inkscape is not available Imagemagick will be used to convert WMF/EMF files
development/Win32/packaging/installer/setup/configure.nsh: FileWrite $R1
'\converter "wmf" "eps" "convert -density 300 i o" ""$\r$\n\
development/Win32/packaging/installer/setup/configure.nsh: \converter
"emf" "eps" "convert -density 300 i o" ""$\r$\n'
Thanks for the pointer, this is indeed incorrect when switching to IM7.
I put this on my todo list. However, this cannot explain the image
conversion problems with e.g. LyXHTML.
regards Uwe
Re: LyX doesn't work with ImageMagick 7
Am 12.05.2016 um 08:01 schrieb Richard Heck: Uwe, did you reconfigure after this patch? Yes. But the problem persists. I'll postpone this to LyX 2.2.1 since I have not that much time and are busy to fix third-party program bugs to be able to provide a well-working installer for LyX 2.2.0. I'll therefore sty with IM 6.9 for LyX 2.2.0. regards Uwe
Re: We will have to change our output for newest LuaTeX
On Fri, May 20, 2016 at 01:26:30PM -0700, Pavel Sanda wrote: > Scott Kostyshak wrote: > > There have been some changes in the luatex engine that will be shipped > > with TeX Live 2016 that cause many of our tests to fail (500 something > > instead of 100 something on TL 2015). The root issue is discussed on the > > LuaTeX mailing list at [1]. > > > > There is a transitional package available, luatex85, that should make > > our current LuaTeX code work. A reasonable approach for now would be to > > use the package if it is available and to not use it if not, keeping the > > rest of our LuaTeX export code the same. This would make sense if we > > think that most users who use the newer LuaTeX also have the package > > installed. > > > > > A more robust solution would be to make the behavior dependent on the > > version of LuaTeX that the user has. > > > > I'm not worried about this for 2.2.0 for the following reasons: > > Agreed. We should note whatever we know about the problem into RELEASE-NOTES, > known issues section; it might help packagers to setup proper dependencies > against 2016 luatex. Done at e16018af. Scott signature.asc Description: PGP signature
Re: SVG Icon going to fallback plaintext in Windows
On Sat, May 07, 2016 at 11:26:33AM +0200, Georg Baum wrote: > Shankar Giri wrote: > > > Bug 2: Specifically for MinGW-W64 pacman repository built Qt libs, the > > pixmap.load(path); will fail for SVGs and SVGZs (built without SVG > > support). So icons all go blank and instead show fall-back text. My > > patch was aiming to only temporarily address Bug 2 not Bug 1. > > IIRC Enrico stated that SVG support in qt is now a requirement for LyX, due > to the change to svg icons. If my memory is correct, then we should mention > that in the release notes, and unfortunately the precompiled mingw64 qt is > not suitable then. Enrico can you add a note to the release notes? Or if easier provide some text and I will add it. Scott signature.asc Description: PGP signature
Re: [LyX/2.3-staging] Correct path names were to look for RPM based dictionaries for hunspell on Linux.
Am 10.05.2016 um 18:08 schrieb Stephan Witt :
>
> commit 5c1a9063cfe95b5b4b31734d6a38ec69a142d5e6
> Author: Stephan Witt
> Date: Tue May 10 18:06:48 2016 +0200
>
>Correct path names were to look for RPM based dictionaries for hunspell on
> Linux.
>
> diff --git a/src/HunspellChecker.cpp b/src/HunspellChecker.cpp
> index 67c7e27..24a25f2 100644
> --- a/src/HunspellChecker.cpp
> +++ b/src/HunspellChecker.cpp
> @@ -154,9 +154,9 @@ const string HunspellChecker::Private::dictPath(int
> selector)
> {
> switch (selector) {
> case 4:
> - return addName(hunspellPackageDictDirectory(),dictDirectory());
> + return hunspellPackageDictDirectory();
> case 3:
> - return addName(myspellPackageDictDirectory(),dictDirectory());
> + return myspellPackageDictDirectory();
> case 2:
> return
> addName(package().system_support().absFileName(),dictDirectory());
> case 1:
Richard, I’d like to backport this to 2.2.1-staging. Ok?
Stephan
Re: We will have to change our output for newest LuaTeX
On Sun, May 22, 2016 at 03:35:57PM -0400, Scott Kostyshak wrote:
> On Sun, May 22, 2016 at 07:22:12PM +, Guenter Milde wrote:
> > On 2016-05-22, Scott Kostyshak wrote:
> > > On Sat, May 21, 2016 at 05:32:07PM -0400, Scott Kostyshak wrote:
> > >> On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote:
> > >> > On 2016-05-20, Guillaume Munch wrote:
> > >> > > Le 20/05/2016 19:26, Scott Kostyshak a écrit :
> > >> > >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
> > >> > >>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
> > >> > Le 20/05/2016 à 13:17, Guenter Milde a écrit :
> > >> > > On 2016-05-20, Scott Kostyshak wrote:
> > >> >
> > >> > >> There have been some changes in the luatex engine that will be
> > >> > >> shipped with TeX Live 2016 that cause many of our tests to fail
> > >> > >> (500 something instead of 100 something on TL 2015). The root
> > >> > >> issue is discussed on the LuaTeX mailing list at [1].
> >
> > >> > >> There is a transitional package available, luatex85, that should
> > >> > >> make our current LuaTeX code work. A reasonable approach for now
> > >> > >> would be to use the package if it is available and to not use it
> > >> > >> if not, keeping the rest of our LuaTeX export code the same.
> > >> > ...
> > >> > > We could just add
> > >> > ...
> > >> > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> > >> > ...
> > >> >
> > >> > >> Should we do this only when we use code that we think needs it? Or
> > >> > >> should we just add it to all of our LuaTeX exports?
> > >> >
> > >> > I propose to do this with every LuaTeX export
> >
> > After reading the luatex85 documentation I changed my mind.
> >
> > Unless LyX uses the offending commands directly, this is a LaTeX issue.
> >
> > It can be expected, that most packages will be updated to either load
> > luatex85 or use the new commands.
> > http://mirrors.ctan.org/macros/generic/luatex85/luatex85.pdf
> >
> > ...
> >
> >
> > >> The most controversial change is putting something before
> > >> \documentclass.
> >
> > ...
> >
> > > Apparently the \usepackage command is not even allowed before
> > > \documentclass. I must have misunderstood the recommendation in the
> > > package documentation. It was probably written assuming that any
> > > sensible LaTeX user would not dare to put anything actually before
> > > \documentclass.
> >
> > It is written for package and class authors, not end users.
> > This is why it uses \RequirePackage{luatex85} instead of \usepackage.
> >
> > (Still, this should be put after the package/class declaration but before
> > code loading other packages...)
>
> Ah that makes sense.
>
> > Can you specify which tests fail?
>
> I think the root issue for the failing tests is the following:
>
> 1. Start a new document.
1.5 Type "hello"
> 2. Go to Document > Settings > Page Layout and select A4 format. Save
> settings.
> 3. Compile with LuaTeX
>
> An undefined control sequence error is given.
>
> Would you prefer the list of tests that fail or is the above MWE good
> enough?
>
> Scott
signature.asc
Description: PGP signature
Re: We will have to change our output for newest LuaTeX
On Sun, May 22, 2016 at 07:22:12PM +, Guenter Milde wrote:
> On 2016-05-22, Scott Kostyshak wrote:
> > On Sat, May 21, 2016 at 05:32:07PM -0400, Scott Kostyshak wrote:
> >> On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote:
> >> > On 2016-05-20, Guillaume Munch wrote:
> >> > > Le 20/05/2016 19:26, Scott Kostyshak a écrit :
> >> > >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
> >> > >>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
> >> > Le 20/05/2016 à 13:17, Guenter Milde a écrit :
> >> > > On 2016-05-20, Scott Kostyshak wrote:
> >> >
> >> > >> There have been some changes in the luatex engine that will be
> >> > >> shipped with TeX Live 2016 that cause many of our tests to fail
> >> > >> (500 something instead of 100 something on TL 2015). The root
> >> > >> issue is discussed on the LuaTeX mailing list at [1].
>
> >> > >> There is a transitional package available, luatex85, that should
> >> > >> make our current LuaTeX code work. A reasonable approach for now
> >> > >> would be to use the package if it is available and to not use it
> >> > >> if not, keeping the rest of our LuaTeX export code the same.
> >> > ...
> >> > > We could just add
> >> > ...
> >> > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> >> > ...
> >> >
> >> > >> Should we do this only when we use code that we think needs it? Or
> >> > >> should we just add it to all of our LuaTeX exports?
> >> >
> >> > I propose to do this with every LuaTeX export
>
> After reading the luatex85 documentation I changed my mind.
>
> Unless LyX uses the offending commands directly, this is a LaTeX issue.
>
> It can be expected, that most packages will be updated to either load
> luatex85 or use the new commands.
> http://mirrors.ctan.org/macros/generic/luatex85/luatex85.pdf
>
> ...
>
>
> >> The most controversial change is putting something before
> >> \documentclass.
>
> ...
>
> > Apparently the \usepackage command is not even allowed before
> > \documentclass. I must have misunderstood the recommendation in the
> > package documentation. It was probably written assuming that any
> > sensible LaTeX user would not dare to put anything actually before
> > \documentclass.
>
> It is written for package and class authors, not end users.
> This is why it uses \RequirePackage{luatex85} instead of \usepackage.
>
> (Still, this should be put after the package/class declaration but before
> code loading other packages...)
Ah that makes sense.
> Can you specify which tests fail?
I think the root issue for the failing tests is the following:
1. Start a new document.
2. Go to Document > Settings > Page Layout and select A4 format. Save
settings.
3. Compile with LuaTeX
An undefined control sequence error is given.
Would you prefer the list of tests that fail or is the above MWE good
enough?
Scott
signature.asc
Description: PGP signature
Using xmllint to test our LyXHTML export
Uwe and Georg have recently found and fixed a bug in our internal XHTML export. Why not test the export automatically? These tests would be fast (compared to the LaTeX compilation tests we have). I think our current XHTML tests just check that the exit code is zero. We can extend these tests to work as follows: 1. Export to .xhtml and check the exit code. 2. Check the terminal output from LyX (I think we do this for other tests, such as the lyx2lyx tests). 3. Use xmllint or something similar and check exit code. I know nothing about XHTML. Does anyone have experience with xmllint or any other tool? The only other tool I saw mentioned when searching is XMLStarlet. If someone does have experience, which tool do you recommend? Also, I'd be curious which options you think should be used. It seems to me that we would not want a very strict validation, and basically want to check whether the file is expected to open in a webbrowser without parser errors. Scott signature.asc Description: PGP signature
Re: We will have to change our output for newest LuaTeX
On 2016-05-22, Scott Kostyshak wrote:
> On Sat, May 21, 2016 at 05:32:07PM -0400, Scott Kostyshak wrote:
>> On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote:
>> > On 2016-05-20, Guillaume Munch wrote:
>> > > Le 20/05/2016 19:26, Scott Kostyshak a écrit :
>> > >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
>> > >>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
>> > Le 20/05/2016 à 13:17, Guenter Milde a écrit :
>> > > On 2016-05-20, Scott Kostyshak wrote:
>> >
>> > >> There have been some changes in the luatex engine that will be
>> > >> shipped with TeX Live 2016 that cause many of our tests to fail
>> > >> (500 something instead of 100 something on TL 2015). The root
>> > >> issue is discussed on the LuaTeX mailing list at [1].
>> > >> There is a transitional package available, luatex85, that should
>> > >> make our current LuaTeX code work. A reasonable approach for now
>> > >> would be to use the package if it is available and to not use it
>> > >> if not, keeping the rest of our LuaTeX export code the same.
>> > ...
>> > > We could just add
>> > ...
>> > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
>> > ...
>> >
>> > >> Should we do this only when we use code that we think needs it? Or
>> > >> should we just add it to all of our LuaTeX exports?
>> >
>> > I propose to do this with every LuaTeX export
After reading the luatex85 documentation I changed my mind.
Unless LyX uses the offending commands directly, this is a LaTeX issue.
It can be expected, that most packages will be updated to either load
luatex85 or use the new commands.
http://mirrors.ctan.org/macros/generic/luatex85/luatex85.pdf
...
>> The most controversial change is putting something before
>> \documentclass.
...
> Apparently the \usepackage command is not even allowed before
> \documentclass. I must have misunderstood the recommendation in the
> package documentation. It was probably written assuming that any
> sensible LaTeX user would not dare to put anything actually before
> \documentclass.
It is written for package and class authors, not end users.
This is why it uses \RequirePackage{luatex85} instead of \usepackage.
(Still, this should be put after the package/class declaration but before
code loading other packages...)
Can you specify which tests fail?
Günter
Re: Plan to tag and tar 2.2.0rc2 on Monday
On Sun, May 22, 2016 at 08:20:57PM +0200, Jean-Marc Lasgouttes wrote: > Me too! > > JMarc > > Le 22 mai 2016 19:49:03 GMT+02:00, Kornel Benko a écrit : > >Am Sonntag, 22. Mai 2016 um 13:44:37, schrieb Scott Kostyshak > > > >> Currently the vote count is 2-1 in favor of doing the final release > >> tomorrow insted of RC2. > >> > >> Scott > > > >+1 to release directly. Well the results already seem pretty clear. It's a go for tomorrow! Scott signature.asc Description: PGP signature
Re: Plan to tag and tar 2.2.0rc2 on Monday
Me too! JMarc Le 22 mai 2016 19:49:03 GMT+02:00, Kornel Benko a écrit : >Am Sonntag, 22. Mai 2016 um 13:44:37, schrieb Scott Kostyshak > >> Currently the vote count is 2-1 in favor of doing the final release >> tomorrow insted of RC2. >> >> Scott > >+1 to release directly. > > Kornel
Re: Plan to tag and tar 2.2.0rc2 on Monday
Am Sonntag, 22. Mai 2016 um 13:44:37, schrieb Scott Kostyshak > On Sun, May 22, 2016 at 05:52:15PM +0100, Guillaume Munch wrote: > > Le 22/05/2016 16:38, Georg Baum a écrit : > > > Scott Kostyshak wrote: > > > > > > > Dear all, > > > > > > > > Unless something comes up, I'm planning to tag and tar rc2 on Monday. At > > > > that point I'll put the tar balls on the FTP and whenever Mac and Win > > > > binaries are uploaded we will announce the release. > > > > > > Great! I wonder whether we need RC2 at all, or whether we should go > > > directly > > > to the release. RC1 has been tested a lot, to my knowledge the critical > > > issues are fixed, so why not release 2.2.0 directly without another RC? > > > > > > > +1 > > I have a preference for releasing RC2 and then releasing final 2.2.0 a > few days later, giving users that only test binary pre-releases a chance > to test. > > I'm fine either way though, so let's have a vote. > > Currently the vote count is 2-1 in favor of doing the final release > tomorrow insted of RC2. > > Scott +1 to release directly. Kornel signature.asc Description: This is a digitally signed message part.
Re: Plan to tag and tar 2.2.0rc2 on Monday
On Sun, May 22, 2016 at 05:52:15PM +0100, Guillaume Munch wrote: > Le 22/05/2016 16:38, Georg Baum a écrit : > > Scott Kostyshak wrote: > > > > > Dear all, > > > > > > Unless something comes up, I'm planning to tag and tar rc2 on Monday. At > > > that point I'll put the tar balls on the FTP and whenever Mac and Win > > > binaries are uploaded we will announce the release. > > > > Great! I wonder whether we need RC2 at all, or whether we should go directly > > to the release. RC1 has been tested a lot, to my knowledge the critical > > issues are fixed, so why not release 2.2.0 directly without another RC? > > > > +1 I have a preference for releasing RC2 and then releasing final 2.2.0 a few days later, giving users that only test binary pre-releases a chance to test. I'm fine either way though, so let's have a vote. Currently the vote count is 2-1 in favor of doing the final release tomorrow insted of RC2. Scott signature.asc Description: PGP signature
Re: Plan to tag and tar 2.2.0rc2 on Monday
Le 22/05/2016 16:38, Georg Baum a écrit : Scott Kostyshak wrote: Dear all, Unless something comes up, I'm planning to tag and tar rc2 on Monday. At that point I'll put the tar balls on the FTP and whenever Mac and Win binaries are uploaded we will announce the release. Great! I wonder whether we need RC2 at all, or whether we should go directly to the release. RC1 has been tested a lot, to my knowledge the critical issues are fixed, so why not release 2.2.0 directly without another RC? +1
Re: Plan to tag and tar 2.2.0rc2 on Monday
Scott Kostyshak wrote: > Dear all, > > Unless something comes up, I'm planning to tag and tar rc2 on Monday. At > that point I'll put the tar balls on the FTP and whenever Mac and Win > binaries are uploaded we will announce the release. Great! I wonder whether we need RC2 at all, or whether we should go directly to the release. RC1 has been tested a lot, to my knowledge the critical issues are fixed, so why not release 2.2.0 directly without another RC? Georg
Re: [patch] fix bug 10124 (XHTML export of some symbols)
Scott Kostyshak wrote: > On Sat, May 21, 2016 at 09:56:07AM -0400, Richard Heck wrote: >> On 05/21/2016 05:11 AM, Georg Baum wrote: >> > While testing imagemagick 7 (more on that later) I stumbled upon bug >> > 10124 as well. It is a simple typo where LyX outputs / instead of >> > . OK for 2.2.0? >> >> Scott's call, of course, but it certainly looks safe to me. > > Go ahead for master. Done at ff4668621b0e2. Georg
Re: We will have to change our output for newest LuaTeX
On Sat, May 21, 2016 at 05:32:07PM -0400, Scott Kostyshak wrote:
> On Sat, May 21, 2016 at 04:23:24PM +, Guenter Milde wrote:
> > On 2016-05-20, Guillaume Munch wrote:
> > > Le 20/05/2016 19:26, Scott Kostyshak a écrit :
> > >> On Fri, May 20, 2016 at 04:06:22PM +, Guenter Milde wrote:
> > >>> On 2016-05-20, Jean-Marc Lasgouttes wrote:
> > Le 20/05/2016 à 13:17, Guenter Milde a écrit :
> > > On 2016-05-20, Scott Kostyshak wrote:
> >
> > >> There have been some changes in the luatex engine that will be
> > >> shipped with TeX Live 2016 that cause many of our tests to fail
> > >> (500 something instead of 100 something on TL 2015). The root
> > >> issue is discussed on the LuaTeX mailing list at [1].
> >
> > >> There is a transitional package available, luatex85, that should
> > >> make our current LuaTeX code work. A reasonable approach for now
> > >> would be to use the package if it is available and to not use it
> > >> if not, keeping the rest of our LuaTeX export code the same.
> > ...
> > > We could just add
> > ...
> > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> > ...
> >
> > >> Should we do this only when we use code that we think needs it? Or
> > >> should we just add it to all of our LuaTeX exports?
> >
> > I propose to do this with every LuaTeX export
> >
> > +3 simple (no LyX-logic required)
> > +1 no risk of LyX getting it wrong
> > -1 eventually spurious package loading
>
> I agree.
>
> > > For 2.2 this could be shipped as a module, to be deprecated and updated
> > > into an empty module once LyX decides to adopt the new luatex syntax.
> >
> > I'd rather keep this simple as well: insert
> >
> > \IfFileExists{luatex85.sty}{\usepackage{luatex85}}{}
> >
> > with every LuaTeX export for the next years to come untill we can be safe
> > every user has the new version and can start using the new syntax in our
> > export.
>
> Makes sense. And because LuaTeX is still beta, I don't think we should feel
> too much pressure an old LuaTeX version for a long time.
>
> What about the attached patch? The most controversial change is putting
> something before \documentclass. In BufferParams::writeLaTeX() we have
> the following warning:
>
> // Do not try to load any other package before the document class, unless you
> // have a thorough understanding of the LATEX internals and know exactly what
> you
> // are doing!
>
> I do not have a thorough understanding of the LATEX internals and I very
> rarely know exactly what I'm doing. The package documentation of
> luatex85 does suggest that it should be the first line of the document.
>
> Any thoughts?
>
> Jürgen, since you've done a lot of work on the LuaTeX code, do you have
> an opinion?
>
> Scott
Apparently the \usepackage command is not even allowed before
\documentclass. I must have misunderstood the recommendation in the
package documentation. It was probably written assuming that any
sensible LaTeX user would not dare to put anything actually before
\documentclass.
Attached is my next attempt.
Scott
From 4e1dc719a4f8830db60d379594e633c08dfebe58 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Sat, 21 May 2016 17:04:42 -0400
Subject: [PATCH] Fix LuaTeX export for TL >= 2016
If the transitional package luatex85 is available we use it.
Otherwise, we assume that an older luatex engine is being used. For
more information, see the following lyx-devel thread:
https://www.mail-archive.com/search?l=mid&q=20160520075810.yi3uspufehev5aln%40cotopaxi
The luatex85 manual suggests to users to load the package "as the
first line of their document", which perhaps means immediately after
\documentclass{}.
---
src/BufferParams.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 9d121cb..1ee847e 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1572,6 +1572,16 @@ bool BufferParams::writeLaTeX(otexstream & os,
LaTeXFeatures & features,
os << '{' << from_ascii(tclass.latexname()) << "}\n";
// end of \documentclass defs
+ // our LuaTeX export is broken with TL >= 2016. If the transitional
+ // package luatex85 is available we use it. Otherwise, we assume that
+ // an older luatex engine is being used.
+ //
https://www.mail-archive.com/search?l=mid&q=20160520075810.yi3uspufehev5aln%40cotopaxi
+ // The luatex85 manual suggests to users to load the package "as the
+ // first line of their document", which perhaps means immediately after
\documentclass{}
+ if (features.runparams().flavor == OutputParams::LUATEX ||
+ features.runparams().flavor == OutputParams::DVILUATEX)
+ os <<
"\\IfFileExists{luatex85.sty}{\\usepackage{luatex85}}{}\n";
+
// if we use fontspec or newtxmath, we have to load the AMS packages
here
string const ams = features.loadAMSPackages();
bool const ot1 =
