Re: ctest seminar
On Mon, Oct 10, 2016 at 07:43:36AM +, Guenter Milde wrote: > (However, IMO this description is too elaborated to be written down in the > documentation.) OK. Scott signature.asc Description: PGP signature
Re: ctest seminar
Le 09/10/2016 à 17:24, Guenter Milde a écrit : On 2016-10-08, Scott Kostyshak wrote: [-- Type: text/plain, Encoding: quoted-printable --] On Sat, Oct 08, 2016 at 06:37:53PM +0100, Jean-Pierre Chrétien wrote: Hello, I've setup the test machinery on my Debian Jessie, TeXLive 2016: * ran automake in /ext/lyx/master * ran cmake on Debian Jessie in /ext/lyx/cbuildmaster as /ext/lyx/cbuildmaster$ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON -DLYX_PROGRAM_SUFFIX=ON -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 -DLYX_INSTALL_PREFIX="git-" ../master * ran make For a first try, I ran cmake -R 'seminar*' to check recent improvements with the seminar example file, and I get the attached result. What surprises me is that - the English version of seminar.lyx is not tested for all output formats; - the French one fails for dvi3, pdf4 and pdf5, that is for dvi (LuaTeX), pdf (XeTeX) and pdf (LuaTeX), for both fonts. This has to do with whether the "Default output format" is set. If I set it back to "default", and rerun cmake and then rerun the tests, then all of the tests pass. This makes me think we should change the format back to default. Günter do you have an opinion on this? The default output format setting is intended. Seminar does not work sensibly with DVI (except for landscape slides) and requires different settings for different output formats, thus * it is advisable to set an output format in the document (and therefore a good to do this in the example). * it does not make sense to test for formats we know to result in wrong output. Running exports manually, I find that - there is no failure for the texF tests (TeX fonts) - the compilation with systemF tests fails with message: Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! The manual export of the original English seminar.lyx file (not tested by ctest, as said) fails also with the same message, so this looks like a missing font in my installation. This is expected: with TeX fonts, the ✗ is taken from a symbols package loaded by request from "unicodesymbols". With Unicode fonts, we would need to change the font to e.g. FreeSerif etc. Works OK with Free fonts. -- Jean-Pierre
Re: ctest seminar
On 2016-10-10, Jean-Pierre Chrétien wrote: > Le 09/10/2016 à 17:45, Guenter Milde a écrit : >> I would like it very much if the Xe/LuaTeX buttons would also >> select Unicode fonts by default. There is already a track issue for this >> (parallel configuration of tex and non-tex fonts) but I don't remember the >> number. > http://www.lyx.org/trac/ticket/9744 ? yes, thank you I also configured an Unicode font with all required characters and enabled testing for all exports (no export fails but some have wrong output). In the long run, we may move this document to the "special guides" and provide short templates for "seminar_printing", "seminar_on_screen" with recommended default settings and default output. Günter
Re: ctest seminar
Le 09/10/2016 à 17:45, Guenter Milde a écrit : I would like it very much if the Xe/LuaTeX buttons would also select Unicode fonts by default. There is already a track issue for this (parallel configuration of tex and non-tex fonts) but I don't remember the number. http://www.lyx.org/trac/ticket/9744 ? -- Jean-Pierre
Re: ctest seminar
On 2016-10-09, Scott Kostyshak wrote: > On Sun, Oct 09, 2016 at 09:33:42PM +, Guenter Milde wrote: > I see what you mean now. I think we both would agree with the following: > "if by using ERT that works with pdflatex, xelatex, and luatex we > achieve the same level of clarity in the document, then that should be > preferred over ERT that works for only pdflatex. Otherwise (if we cannot > achieve the same level of clarity), the clarity of the document is most > important and thus the ERT that works only with pdflatex should be > preferred." Yes, this is the detailed version of the comment in invertedTests: Sublabel: ert # # Export failures due to "raw" LaTeX use in ERT or preamble code. # "Wontfix" if demonstrating correct use and OK in the default output format. (However, IMO this description is too elaborated to be written down in the documentation.) Günter
Re: ctest seminar
On Sun, Oct 09, 2016 at 09:33:42PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > > On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: > >> On 2016-10-09, Scott Kostyshak wrote: > > ... > > >> Yes. It is good to make the documents "robust", but not if this stands in > >> the way with the main purpose: documentation. > > > +1 > > >> Example: > >> * ERT that only works with pdflatex is OK, if it explains ERT, its > >> limits and benefits. > > > In this case, I would think that we could use ERT that works more > > generally than only with pdflatex and I think that would be a better > > lesson to the user. Teaching general LaTeX knowledge I think is better > > than knowledge specific to one engine. > > The use case for ERT is special tricks to get things done. > Normally, one output format suffices to get things done. > The best ERT code in this case is a simple one, that works with this format, > not a generic with \ifpfd \ifxetex ... tests for engines and variants. > > Changing existing documents (giving other examples) just to have ERT that > works also in other engines is "stands in the way" in my view -- I'd rather > keep the pattern in the inverted:ERT. I see what you mean now. I think we both would agree with the following: "if by using ERT that works with pdflatex, xelatex, and luatex we achieve the same level of clarity in the document, then that should be preferred over ERT that works for only pdflatex. Otherwise (if we cannot achieve the same level of clarity), the clarity of the document is most important and thus the ERT that works only with pdflatex should be preferred." Scott signature.asc Description: PGP signature
Re: ctest seminar
On 2016-10-09, Scott Kostyshak wrote: > On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: >> On 2016-10-09, Scott Kostyshak wrote: ... >> Yes. It is good to make the documents "robust", but not if this stands in >> the way with the main purpose: documentation. > +1 >> Example: >> * ERT that only works with pdflatex is OK, if it explains ERT, its >> limits and benefits. > In this case, I would think that we could use ERT that works more > generally than only with pdflatex and I think that would be a better > lesson to the user. Teaching general LaTeX knowledge I think is better > than knowledge specific to one engine. The use case for ERT is special tricks to get things done. Normally, one output format suffices to get things done. The best ERT code in this case is a simple one, that works with this format, not a generic with \ifpfd \ifxetex ... tests for engines and variants. Changing existing documents (giving other examples) just to have ERT that works also in other engines is "stands in the way" in my view -- I'd rather keep the pattern in the inverted:ERT. Günter
Re: ctest seminar
On Sun, Oct 09, 2016 at 04:45:11PM +, Guenter Milde wrote: > On 2016-10-09, Scott Kostyshak wrote: > Two points that were agreed with Uwe: > > * The manuals in lib/doc are designed for output with pdflatex and TeX > fonts and only this export is secure. > > To make this clear, the default output format is set to pdf2. > > * The manuals in lib/doc/ are c-tested with other exports despite the > default output format setting. > > For this, the ctest scripts were modified to respect the default format > *except for documents in lib/doc/*. Thanks for this reminder. > > But we shouldn't modify the documents for the purpose of > > the ctests. We should only do that if it makes sense for the documents. > > Yes. It is good to make the documents "robust", but not if this stands in > the way with the main purpose: documentation. +1 > Example: > * ERT that only works with pdflatex is OK, if it explains ERT, its > limits and benefits. In this case, I would think that we could use ERT that works more generally than only with pdflatex and I think that would be a better lesson to the user. Teaching general LaTeX knowledge I think is better than knowledge specific to one engine. > * ERT for other purposes is bad, if it can be replaced with a better > working LyX construct. > > e.g.: ERT for accents in Russian should be replaced by composite Unicode > characters. > > > > And in my opinion it makes sense for the documents if pdflatex, xelatex, > > and lualatex all work on the document. I'm not sure what others think > > though. > > Xe/LuaTeX with TeX fonts are not usefull and we should not make much effort > to support them. > > I would like it very much if the Xe/LuaTeX buttons would also > select Unicode fonts by default. There is already a track issue for this > (parallel configuration of tex and non-tex fonts) but I don't remember the > number. +1 Scott signature.asc Description: PGP signature
Re: ctest seminar
On 2016-10-09, Scott Kostyshak wrote: > On Sun, Oct 09, 2016 at 04:36:47PM +0100, Jean-Pierre Chrétien wrote: >> Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : >> Right, now I get onle the three systemF failures due to the >> Missing character: There is no ✗ in font >> [lmroman10-regular]:mapping=tex-text! > I'm not sure why. Because this document is not fit for export with Unicode fonts and it tells so by setting the default output. (LatinModern is the default for fonspec but a quite limited font with many missing characters.) We can change this by defining other Unicodefonts (I recommend DejaVu) in the LyX-source. >> BTW, the text of the manuals (which have all pdf2 as default output) are >> never tested again other exports ? > Unfortunately I think that is correct. It would be nice to improve > this and test more exports. One way to do this would be to remove the > default output. Two points that were agreed with Uwe: * The manuals in lib/doc are designed for output with pdflatex and TeX fonts and only this export is secure. To make this clear, the default output format is set to pdf2. * The manuals in lib/doc/ are c-tested with other exports despite the default output format setting. For this, the ctest scripts were modified to respect the default format *except for documents in lib/doc/*. > But we shouldn't modify the documents for the purpose of > the ctests. We should only do that if it makes sense for the documents. Yes. It is good to make the documents "robust", but not if this stands in the way with the main purpose: documentation. Example: * ERT that only works with pdflatex is OK, if it explains ERT, its limits and benefits. * ERT for other purposes is bad, if it can be replaced with a better working LyX construct. e.g.: ERT for accents in Russian should be replaced by composite Unicode characters. > And in my opinion it makes sense for the documents if pdflatex, xelatex, > and lualatex all work on the document. I'm not sure what others think > though. Xe/LuaTeX with TeX fonts are not usefull and we should not make much effort to support them. I would like it very much if the Xe/LuaTeX buttons would also select Unicode fonts by default. There is already a track issue for this (parallel configuration of tex and non-tex fonts) but I don't remember the number. > The other way to add tests would be to remove the ctest mechanism that > tests only the default format if it is set. We had a discussion on this > but I forgot why we decided to do this. See above. Günter
Re: ctest seminar
On 2016-10-08, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Sat, Oct 08, 2016 at 06:37:53PM +0100, Jean-Pierre Chrétien wrote: >> Hello, >> I've setup the test machinery on my Debian Jessie, TeXLive 2016: >> * ran automake in /ext/lyx/master >> * ran cmake on Debian Jessie in /ext/lyx/cbuildmaster as >> /ext/lyx/cbuildmaster$ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON >> -DLYX_PROGRAM_SUFFIX=ON -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 >> -DLYX_INSTALL_PREFIX="git-" ../master >> * ran make >> For a first try, I ran cmake -R 'seminar*' to check recent improvements with >> the seminar example file, and I get the attached result. >> What surprises me is that >> - the English version of seminar.lyx is not tested for all output formats; >> - the French one fails for dvi3, pdf4 and pdf5, that is for dvi (LuaTeX), >> pdf (XeTeX) and pdf (LuaTeX), for both fonts. > This has to do with whether the "Default output format" is set. > If I set it back to "default", and rerun cmake and then rerun the tests, > then all of the tests pass. This makes me think we should change the > format back to default. Günter do you have an opinion on this? The default output format setting is intended. Seminar does not work sensibly with DVI (except for landscape slides) and requires different settings for different output formats, thus * it is advisable to set an output format in the document (and therefore a good to do this in the example). * it does not make sense to test for formats we know to result in wrong output. >> Running exports manually, I find that >> - there is no failure for the texF tests (TeX fonts) >> - the compilation with systemF tests fails with message: >> Missing character: There is no ✗ in font >> [lmroman10-regular]:mapping=tex-text! >> The manual export of the original English seminar.lyx file (not tested by >> ctest, as said) fails also with the same message, so this looks like a >> missing font in my installation. This is expected: with TeX fonts, the ✗ is taken from a symbols package loaded by request from "unicodesymbols". With Unicode fonts, we would need to change the font to e.g. FreeSerif etc. >> So manually there are 3 false alarms, but I must say also that the texF >> tests did fail once in a weird manner which I cannot reproduce: I got and >> error looking like polyglossia language change error, but with no error >> showing in the log window. (however, there cannot be a polyglossia error with texF, as polyglossia requires fontspec (i.e. Unicode fonts)). >> This is a bit mysterious but could explain the ctest failures. Is >> there somwhere a log of the test compilation (or an option to activate >> it?). Unfortunately not (yet). Günter
Re: ctest seminar
On Sun, Oct 09, 2016 at 04:36:47PM +0100, Jean-Pierre Chrétien wrote: > Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : > > > > > This has to do with whether the "Default output format" is set. > > If I set it back to "default", and rerun cmake and then rerun the tests, > > then all of the tests pass. This makes me think we should change the > > format back to default. Günter do you have an opinion on this? > > Right, now I get onle the three systemF failures due to the > > Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! I'm not sure why. > BTW, the text of the manuals (which have all pdf2 as default output) are > never tested again other exports ? Unfortunately I think that is correct. It would be nice to improve this and test more exports. One way to do this would be to remove the default output. But we shouldn't modify the documents for the purpose of the ctests. We should only do that if it makes sense for the documents. And in my opinion it makes sense for the documents if pdflatex, xelatex, and lualatex all work on the document. I'm not sure what others think though. The other way to add tests would be to remove the ctest mechanism that tests only the default format if it is set. We had a discussion on this but I forgot why we decided to do this. Scott signature.asc Description: PGP signature
Re: ctest seminar
Le 08/10/2016 à 19:10, Scott Kostyshak a écrit : This has to do with whether the "Default output format" is set. If I set it back to "default", and rerun cmake and then rerun the tests, then all of the tests pass. This makes me think we should change the format back to default. Günter do you have an opinion on this? Right, now I get onle the three systemF failures due to the Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! BTW, the text of the manuals (which have all pdf2 as default output) are never tested again other exports ? -- Jean-Pierre
Re: ctest seminar
On Sat, Oct 08, 2016 at 06:37:53PM +0100, Jean-Pierre Chrétien wrote: > Hello, > > I've setup the test machinery on my Debian Jessie, TeXLive 2016: > * ran automake in /ext/lyx/master > * ran cmake on Debian Jessie in /ext/lyx/cbuildmaster as > > /ext/lyx/cbuildmaster$ cmake -DLYX_ENABLE_EXPORT_TESTS=ON -DLYX_RELEASE=ON > -DLYX_PROGRAM_SUFFIX=ON -DLYX_ENABLE_CXX11=AUTO -DLYX_USE_QT=QT5 > -DLYX_INSTALL_PREFIX="git-" ../master > > * ran make > > For a first try, I ran cmake -R 'seminar*' to check recent improvements with > the seminar example file, and I get the attached result. > > What surprises me is that > - the English version of seminar.lyx is not tested for all output formats; > - the French one fails for dvi3, pdf4 and pdf5, that is for dvi (LuaTeX), > pdf (XeTeX) and pdf (LuaTeX), for both fonts. This has to do with whether the "Default output format" is set. If I set it back to "default", and rerun cmake and then rerun the tests, then all of the tests pass. This makes me think we should change the format back to default. Günter do you have an opinion on this? > Running exports manually, I find that > - there is no failure for the texF tests (TeX fonts) > - the compilation with systemF tests fails with message: > > Missing character: There is no ✗ in font [lmroman10-regular]:mapping=tex-text! > > The manual export of the original English seminar.lyx file (not tested by > ctest, as said) fails also with the same message, so this looks like a > missing font in my installation. > > So manually there are 3 false alarms, but I must say also that the texF > tests did fail once in a weird manner which I cannot reproduce: I got and > error looking like polyglossia language change error, but with no error > showing in the log window. This is a bit mysterious but could explain the > ctest failures. Is there somwhere a log of the test compilation (or an > option to activate it?). There is also a pending issue where LyX produces varying LaTeX code. I tried to figure it out here: https://www.mail-archive.com/search?l=mid=20160925230226.2nr2lpgrmuwz5voo%40steph but I could not get to the root of the problem. Scott signature.asc Description: PGP signature
