Re: We now include both png and svgz?
On Tue, Nov 10, 2015 at 06:42:50PM -0800, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > At the moment you cannot use LyX with Qt4 because it cannot read svgz > > > files, and the code is not correctly falling back to png files. > > > > > > So yes, we need both, otherwise we will have to require newer versions of > > > Qt. > > > > I see. Makes sense. I will set a note to myself that we should remove > > the pngs if we ever require Qt 5. > > Sounds like bug with target 2.3. P Good idea. Done at #9857. Scott
Re: We now include both png and svgz?
Scott Kostyshak wrote: > > At the moment you cannot use LyX with Qt4 because it cannot read svgz > > files, and the code is not correctly falling back to png files. > > > > So yes, we need both, otherwise we will have to require newer versions of > > Qt. > > I see. Makes sense. I will set a note to myself that we should remove > the pngs if we ever require Qt 5. Sounds like bug with target 2.3. P
[patch] RFC: better submenu for tables
Am 04.11.2015 um 10:42 schrieb Jean-Marc Lasgouttes: This is not how contextual menus are supposed to work IMO. I would propose instead to use submenus and to micmick what libreoffice (for ex.) does. I agree that submenus are better than to remove things. Attached is a patch. OK to go in? - Besides this, in general it is not good to use personal preferences as argument. (I make this mistake too.) We provide a product that should not only suit our needs but the needs of as many as possible average users out there. thanks and regards Uwe diff --git "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\std8A77.tmp\\stdcontext-9894e0b-left.inc" "b/D:\\LyXGit\\Master\\lib\\ui\\stdcontext.inc" index 630892c..3eebbc9 100644 --- "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\std8A77.tmp\\stdcontext-9894e0b-left.inc" +++ "b/D:\\LyXGit\\Master\\lib\\ui\\stdcontext.inc" @@ -405,15 +405,14 @@ Menuset # InsetTabular context menu # - Menu "context-tabular" - Item "Multicolumn|u" "inset-modify tabular multicolumn" - Item "Multirow|w" "inset-modify tabular multirow" - Separator + Menu "table-lines" Item "Top Line|n" "inset-modify tabular toggle-line-top" Item "Bottom Line|i" "inset-modify tabular toggle-line-bottom" Item "Left Line|L" "inset-modify tabular toggle-line-left" Item "Right Line|R" "inset-modify tabular toggle-line-right" - Separator + End + + Menu "table-alignment" Item "Left|f" "command-alternatives inset-modify tabular m-align-left;inset-modify tabular align-left" Item "Center|C" "command-alternatives inset-modify tabular m-align-center;inset-modify tabular align-center" Item "Right|h" "command-alternatives inset-modify tabular m-align-right;inset-modify tabular align-right" @@ -422,6 +421,11 @@ Menuset Item "Top|T" "inset-modify tabular valign-top" Item "Middle|M" "inset-modify tabular valign-middle" Item "Bottom|B" "inset-modify tabular valign-bottom" + End + + Menu "table-cols-rows" + Item "Multicolumn|u" "inset-modify tabular multicolumn" + Item "Multirow|w" "inset-modify tabular multirow" Separator Item "Append Row|A" "inset-modify tabular append-row" Item "Delete Row|D" "inset-modify tabular delete-row" @@ -434,6 +438,18 @@ Menuset Item "Copy Column|y" "inset-modify tabular copy-column" Item "Move Column Right|v" "inset-modify tabular move-column-right" Item "Move Column Left" "inset-modify tabular move-column-left" + End + + Menu "context-tabular" + Item "Formal style|F" "inset-modify tabular set-booktabs" + Item "Longtable|o" "inset-modify tabular set-longtabular" + Separator + Submenu "Lines|L" "table-lines" + Separator + Submenu "Alignment|A" "table-alignment" + Separator + Submenu "Columns/Rows|C" "table-cols-rows" + Separator Separator Item "Settings...|S" "inset-settings tabular" End
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
On Tue, Nov 10, 2015 at 04:17:36PM +, Guenter Milde wrote: > I want to be able to prepare a document that works with many output > formats (one source fits all). One more use-case: template > documents with sensible settings for the various export formats. +1 > However, the most problematic part (for me) is, that the obscure combinations > XeTeX/LuaTeX & TeX fonts are simpler to reach than the much more usefull > LuaTeX & OpenType fonts. I agree. I have not followed the #9744 discussion closely or looked at Georg's recent work, so my following suggestion might be irrelevant now, but in any case: Would it make sense to check the box "Use non-TeX fonts" by default, and then change the full string from "Use non-TeX fonts (via XeTeX/LuaTeX)" to "Use non-TeX fonts (if XeTeX/LuaTeX)" ? This would make the default to be the most advised one, and also would allow compilation with pdfTeX. Scott
Re: Plan for the current testing situation
On Tue, Nov 10, 2015 at 03:30:24PM +, Guenter Milde wrote: > On 2015-11-10, Scott Kostyshak wrote: > > On Mon, Nov 09, 2015 at 11:19:16AM +0100, Vincent van Ravesteijn wrote: > >> And yes of course there is an implicit rule that when your commit breaks > >> something or has problems whatsoever you are expected to fix it within a > >> reasonable timeframe. > > This is, what I prefer. Could we make this an explicit rule: > >When your commit breaks something or has problems whatsoever you are >expected to fix it within a reasonable timeframe. > >If it is not possible to solve the problems, revert the commit or move it >to a "feature branch" (remember, branching is dead easy with Git). > >"Reasonable" depends on the problems involved and may range from 1 day to >some weeks. This seems to be the most popular opinion. Günter, if you do not here any more comments, please feel free to put this in Development.lyx. > One problem with the current testing situation is, that many failing test > are due to fixes that correct behaviour that was wrong before (like > reporting missing characters in the output document as an error). > > Next, this led to discovery of the use of a wrong encoding with Xe/LuaTeX > and TeX fonts - solving this brought more problems to light. > > I believe such "indirect" problems must be solved "collectively" - after a > consensus whether to revert the "discovering" commit (and live with the old > hidden bugs), temporarily invert affected tests or do some hacks to get a > clean state, or have a concerted effort to solve the basic problems. Agreed. But I don't think this is a common situation. Scott
Re: No patch file for the major release, right?
On Tue, Nov 10, 2015 at 10:02:59AM +0100, Jean-Marc Lasgouttes wrote: > Le 10/11/2015 04:15, Scott Kostyshak a écrit : > >I just want to confirm that we only publish patch files for minor > >releases and not for major releases. Is that correct? > > Yes, it is correct. Thanks. Scott
Re: We now include both png and svgz?
On Tue, Nov 10, 2015 at 10:02:15AM +0100, Vincent van Ravesteijn wrote: > On Tue, Nov 10, 2015 at 4:13 AM, Scott Kostyshak wrote: > > When experimenting with building the tar balls, I noticed a significant > > difference in size between 2.2.0dev and 2.1.4. > > > > lyx-2.1.4.tar.gz is 20.8 MB > > lyx-2.2.0dev.tar.gz is 24.8 MB > > > > A quick check seems to show that most of the change comes from now > > including .svgz (in addition to .png). Why do we include both? > > > > I just wanted to check that this is expected. > > > > Scott > > At the moment you cannot use LyX with Qt4 because it cannot read svgz > files, and the code is not correctly falling back to png files. > > So yes, we need both, otherwise we will have to require newer versions of Qt. I see. Makes sense. I will set a note to myself that we should remove the pngs if we ever require Qt 5. Scott
Re: [patch] support for OpenDocument as input format for Pandoc
On Wed, Nov 11, 2015 at 12:52:53AM +0100, Uwe Stöhr wrote: > Attached is a simple patch that adds support for OpenDocument text as input > format for conversion to LaTeX via Pandoc. > > Pandoc recently made great progress: > http://pandoc.org/releases.html > > It supports now to use OpenDocument. With the attached patch it is possible > to use this feature. Especially for Windows users this would be the first > OpenDocument -> LaTeX converter. (Fixes bug #6042 completely) > > OK to go in? OK. Scott
Re: docs with \origin unavailable
On Tue, Nov 10, 2015 at 08:43:56PM +0100, Georg Baum wrote: > Hi, > > we have currently several documents with > > \origin unavailable > > instead of > > \origin /systemlyxdir/doc/ > > in master (because of bug 9815). I suggest to save all these files with > correct \origin for the alpha, even if there are still problems with 9815. > It is probably also a good idea to update all files to the latest format (so > that we do not get format updates mixed with content updates). > > If wanted, I could do both changes. Thanks for volunteering. Please go ahead. Scott
[patch] support for OpenDocument as input format for Pandoc
Attached is a simple patch that adds support for OpenDocument text as
input format for conversion to LaTeX via Pandoc.
Pandoc recently made great progress:
http://pandoc.org/releases.html
It supports now to use OpenDocument. With the attached patch it is
possible to use this feature. Especially for Windows users this would be
the first OpenDocument -> LaTeX converter. (Fixes bug #6042 completely)
OK to go in?
regards Uwe
diff --git
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\con9BF1.tmp\\configure-6dd98a8-left.py"
"b/D:\\LyXGit\\Master\\lib\\configure.py"
index 32fd278..dcf34c9 100644
---
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\con9BF1.tmp\\configure-6dd98a8-left.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -854,6 +854,9 @@ def checkConverterEntries():
checkProg('an OpenDocument -> LaTeX converter', ['w2l -clean $$i'],
rc_entry = [ r'\converter odtlatex "%%" ""' ])
#
+checkProg('an Open Document (Pandoc) -> LaTeX converter', ['pandoc -s -f
odt -o $$o -t latex $$i'],
+rc_entry = [ r'\converter odt3latex "%%" ""' ])
+#
checkProg('a MS Word Office Open XML converter -> LaTeX', ['pandoc -s -f
docx -o $$o -t latex $$i'],
rc_entry = [ r'\converter word2 latex "%%" ""' ])
# Only define a converter to pdf6, otherwise the odt format could be
Re: export test status (was: [LyX/master] Store both sets of font selections)
On 2015-11-10, Guenter Milde wrote: > On 2015-11-09, Kornel Benko wrote: > This is XeTeX with TeX fonts. > It currently always fails because the encoding after footnotes, tables, > boxes, and some other insets is set to the document language default. I > suggest to take these somehow out of calculation for now. I fixed the "wrong encoding after insets" problem, so at least some of the XeTeX with TeX fonts test should work again. Günter
docs with \origin unavailable
Hi, we have currently several documents with \origin unavailable instead of \origin /systemlyxdir/doc/ in master (because of bug 9815). I suggest to save all these files with correct \origin for the alpha, even if there are still problems with 9815. It is probably also a good idea to update all files to the latest format (so that we do not get format updates mixed with content updates). If wanted, I could do both changes. Georg
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Dienstag, 10. November 2015 um 13:36:24, schrieb Guenter Milde ... > >> For LuaTeX + TeX-fonts, only "auto" needs to be changed. Preferably to > >> the document languages default encoding, but any 8-bit encoding or > >> ascii will do. > > > This I am omitting for now. > > You could try with "latin9" instead of "ascii". Or, make it dependent on > the document language - for manuals etc. this does not require looking > into the LyX-file, as non-English documents are stored in directories with > the language tag. A language tag to encoding mapping can be extracted from > lib/languages. OK, did it. Now we have 23 failing pdf5_texF tests (it was 28 if not changing inputencoding) > >> Mind, that changing the inputencoding is only seldom tested and can > >> exhibit a number of currently hidden problems. For example, the Russian > >> documents fail with inputenc==ascii due to #9637 (textgreek and textcyr > >> depend on font-encoding, not input encoding) where the spurious \textcyr > >> commands interfere with ERT in the document. > > >> OTOH, the utf8 inputencoding fails with Greek and Russian due to > >> #9681 (textgreek and textcyr also required for encodable characters). > > >> I therefore recommend also test exporting documents with pdflatex and > >> inputenc=ascii as well as inputenc=utf8. > > > Now it starts to be complex. It means to analyse the lyx file before test. > > We are not doing it yet. > > What I have in mind here was a number of additional tests, where all > manuals (say) get "inputencoding" set to "ascii" and tested for export to > pdf2, say. > > +1 if a XeTeX-TeXF test fails, we can find out if this is due to XeTeX vs. >8-bit LaTeX or to inputenc set to "ascii". > > -1 we get a number of new failing tests. > > Similar, I would add test for manuals with "inputencoding" set to "utf8" and > export to pdf2. > Now we need a method to name all the different tests. ATM, the test-name does not specify inputencoding. > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-10, Kornel Benko wrote: > Am Dienstag, 10. November 2015 um 10:50:30, schrieb Guenter Milde > >> Mind, that changing the inputencoding is only seldom tested and can >> exhibit a number of currently hidden problems. For example, the Russian >> documents fail with inputenc==ascii due to #9637 (textgreek and textcyr >> depend on font-encoding, not input encoding) where the spurious \textcyr >> commands interfere with ERT in the document. >> OTOH, the utf8 inputencoding fails with Greek and Russian due to >> #9681 (textgreek and textcyr also required for encodable characters). >> I therefore recommend also test exporting documents with pdflatex and >> inputenc=ascii as well as inputenc=utf8. > This all starts to feel like 'Volkswagen cheating'. Somehow lyx itself > should be able to set the correct encoding. Not really: With XeTeX + TeX fonts you are testing a combination that is almost never used in real life (and never required). My proposal to restrict testing to real life cases was rejected, based on the true consideration that testing this obscure combination revealed real bugs. The problem is, that these tests give the bugs a far greater importance that they would have without test for obscure scenarios. (Just imagine we did not have the tests: the failing of LuaTeX + TeX fonts + mixed languages that require a different encoding would be treated as a minor enhancement request. Günter
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
Dear Georg, On 2015-11-08, Georg Baum wrote: Thanks for the patch with parallel config values for tex and non-tex fonts. > The next step for the tests would then be to explicitly set sensible non-TeX > fonts for those files of our documentation that have special requirements, > so that we can get rid of the heuristics in the tests. and improve the test result for others. This regards all documents using non-Latin scripts (Greek, Cyrillic, Hebrew, Arab, ...) + the ones where we get "missing character" errors when exporting with non-tex fonts. Is there an easy way to determine and list the reason for failure of tests? > Concerning the new automatic value for "use non-TeX fonts" I am not > really sure how to proceed. The current GUI design is inconsistent if you want to export to the most commen document types: 1. DVI TeX fonts for the TeX nostalgic 2. PS TeX fonts for fast preview/printing and PS-tricks 3. PDF (pdflatex) TeX fonts for traditional PDF 4. PDF (XeTeX) OpenType fonts for the traditional Unicode user 5. PDF (LuaTeX)OpenType fonts for the adventurous Unicode user 6. LyXHTML OpenType fonts for online use You can select between 1, 2, 3, and 6 from the "see other formats" toobar buttons or menu entry, without need to change the source document. However, selecting 4 and 5 requires a change to the document. Without this additional change (go to Document>Settings>Fonts and select "use non-TeX fonts"), XeTeX/LuaTeX toolbar buttons select the obscure combinations 4a. PDF (XeTeX) TeX fontsno real use at all 5a. PDF (LuaTeX)TeX fontsfor traditional adventurous users requiring more math alphabets or lua scripting Requiring a manual change to the source for a sensible XeTeX/LuaTeX export is not only cumbersome, it also fails if the document is readonly. I want to be able to prepare a document that works with many output formats (one source fits all). One more use-case: template documents with sensible settings for the various export formats. But while setting the "math output" for HTML export to MathML does not prevent export with "latex" or "lualatex", setting the font for PDF(LuaTex) to an OpenType font like "Gentium" prevents export with PDF(pdflatex). The automatic font package selection (fontenc vs. fontspec) would be similar to the automatic language package selection (babel vs. polyglossia). However, the most problematic part (for me) is, that the obscure combinations XeTeX/LuaTeX & TeX fonts are simpler to reach than the much more usefull LuaTeX & OpenType fonts. Günter
Re: Plan for the current testing situation
On 2015-11-10, Scott Kostyshak wrote: > On Mon, Nov 09, 2015 at 11:19:16AM +0100, Vincent van Ravesteijn wrote: >> >> So my preferred policy would be: >> if a >> >> commit is found to have broken a test, either the situation is resolved >> within >> >> a day (i.e. the bug is fixed or the test is fixed) or the commit is >> reverted >> >> (and perhaps pushed to a separate remote branch). >> > >> > A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have >> such rules for compilation warnings? For compilation failures? For the >> latter, I imagine that people want it solved ASAP, but this arises more out >> of social pressure, not an ad hoc rule. > Social pressure does not work with everyone. Also, some people do not > understand why certain things are so frustrating to others. ... >> Yes, the 1-day rule might lead to frustrated developers and increases the >> noise in master branch even more. > OK. How about a 1 week rule then? Or you would prefer no rule and just > deal with it case-by-case and implicit rule as you mention below and as > Guillaume refers to? >> And yes of course there is an implicit rule that when your commit breaks >> something or has problems whatsoever you are expected to fix it within a >> reasonable timeframe. This is, what I prefer. Could we make this an explicit rule: When your commit breaks something or has problems whatsoever you are expected to fix it within a reasonable timeframe. If it is not possible to solve the problems, revert the commit or move it to a "feature branch" (remember, branching is dead easy with Git). "Reasonable" depends on the problems involved and may range from 1 day to some weeks. One problem with the current testing situation is, that many failing test are due to fixes that correct behaviour that was wrong before (like reporting missing characters in the output document as an error). Next, this led to discovery of the use of a wrong encoding with Xe/LuaTeX and TeX fonts - solving this brought more problems to light. I believe such "indirect" problems must be solved "collectively" - after a consensus whether to revert the "discovering" commit (and live with the old hidden bugs), temporarily invert affected tests or do some hacks to get a clean state, or have a concerted effort to solve the basic problems. Günter
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-10, Kornel Benko wrote: > Am Dienstag, 10. November 2015 um 10:50:30, schrieb Guenter Milde > >> On 2015-11-10, Kornel Benko wrote: >> > Am Dienstag, 10. November 2015 um 07:34:42, schrieb Guenter Milde >> > >> for a safe handling of XeTeX + TeX-fonts without hacks in the LyX code, I >> recommend to allow this combination only, if "inputenc" == "ascii". > I did it. That way I got 117 less failed exports. > (Previously 260, now 143). Good. >> for a safe handling of LuaTeX + TeX-fonts without hacks in the LyX code, I >> recommend to allow this combination only, if "inputenc" != "auto". > Setting 'ascii' for '(auto|default)' leads to 53 failed pdf5_texF tests. > Without this change I have only 28. This does not feel right. Right. As I said below, "ascii" is not the best choice. Not well tested and some documents fail with it, (independent of the engine). >> For LuaTeX + TeX-fonts, only "auto" needs to be changed. Preferably to >> the document languages default encoding, but any 8-bit encoding or >> ascii will do. > This I am omitting for now. You could try with "latin9" instead of "ascii". Or, make it dependent on the document language - for manuals etc. this does not require looking into the LyX-file, as non-English documents are stored in directories with the language tag. A language tag to encoding mapping can be extracted from lib/languages. >> Mind, that changing the inputencoding is only seldom tested and can >> exhibit a number of currently hidden problems. For example, the Russian >> documents fail with inputenc==ascii due to #9637 (textgreek and textcyr >> depend on font-encoding, not input encoding) where the spurious \textcyr >> commands interfere with ERT in the document. >> OTOH, the utf8 inputencoding fails with Greek and Russian due to >> #9681 (textgreek and textcyr also required for encodable characters). >> I therefore recommend also test exporting documents with pdflatex and >> inputenc=ascii as well as inputenc=utf8. > Now it starts to be complex. It means to analyse the lyx file before test. > We are not doing it yet. What I have in mind here was a number of additional tests, where all manuals (say) get "inputencoding" set to "ascii" and tested for export to pdf2, say. +1 if a XeTeX-TeXF test fails, we can find out if this is due to XeTeX vs. 8-bit LaTeX or to inputenc set to "ascii". -1 we get a number of new failing tests. Similar, I would add test for manuals with "inputencoding" set to "utf8" and export to pdf2. Günter
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Dienstag, 10. November 2015 um 10:50:30, schrieb Guenter Milde > Mind, that changing the inputencoding is only seldom tested and can > exhibit a number of currently hidden problems. For example, the Russian > documents fail with inputenc==ascii due to #9637 (textgreek and textcyr > depend on font-encoding, not input encoding) where the spurious \textcyr > commands interfere with ERT in the document. > > OTOH, the utf8 inputencoding fails with Greek and Russian due to > #9681 (textgreek and textcyr also required for encodable characters). > > I therefore recommend also test exporting documents with pdflatex and > inputenc=ascii as well as inputenc=utf8. This all starts to feel like 'Volkswagen cheating'. Somehow lyx itself should be able to set the correct encoding. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Dienstag, 10. November 2015 um 10:50:30, schrieb Guenter Milde > On 2015-11-10, Kornel Benko wrote: > > Am Dienstag, 10. November 2015 um 07:34:42, schrieb Guenter Milde > > > > Dear Kornel, > > for a safe handling of XeTeX + TeX-fonts without hacks in the LyX code, I > recommend to allow this combination only, if "inputenc" == "ascii". I did it. That way I got 117 less failed exports. (Previously 260, now 143). > for a safe handling of LuaTeX + TeX-fonts without hacks in the LyX code, I > recommend to allow this combination only, if "inputenc" != "auto". Setting 'ascii' for '(auto|default)' leads to 53 failed pdf5_texF tests. Without this change I have only 28. This does not feel right. > >> Non-inverted XeTeX export tests would require documents with either > >> "inputenc" == "ascii" or "useNonTeXFonts" == "true". > > > I can adapt the test machinery to do it. > > Either this, or just invert the tests until the document(s) have > "automatic" TeX vs. non-TeX fonts. > > > How to proceed with "inputenc" if it is set to > > auto > > default > > iso8859-1 > > latin1 > > iso8859-2 > > iso8859-15 > iso8859-* > > koi8-r > > utf8 > > utf8x > > For export with XeTeX and TeX-fonts, all these must be set to "ascii". > > > utf8-cjk > > EUC-JP-pLaTeX OK, done. > invert XeTeX + TeX-fonts tests, or set useNonTeXFonts to true. > > utf8-plain > > Set useNonTeXFonts to true. > Done. (I.e. reverted this combination) > For LuaTeX + TeX-fonts, only "auto" needs to be changed. Preferably to the > document languages default encoding, but any 8-bit encoding or ascii will do. > This I am omitting for now. > Mind, that changing the inputencoding is only seldom tested and can > exhibit a number of currently hidden problems. For example, the Russian > documents fail with inputenc==ascii due to #9637 (textgreek and textcyr > depend on font-encoding, not input encoding) where the spurious \textcyr > commands interfere with ERT in the document. > > OTOH, the utf8 inputencoding fails with Greek and Russian due to > #9681 (textgreek and textcyr also required for encodable characters). > > I therefore recommend also test exporting documents with pdflatex and > inputenc=ascii as well as inputenc=utf8. Now it starts to be complex. It means to analyse the lyx file before test. We are not doing it yet. > BTW: Despite its name, "inputenc" == "default" is a very fragile expert > option: encode the file in (maybe several) language default > encoding(s) but don't call inputenc nor include encoding switching > code... This setting should not be part of the automated export > tests.) > > Hope this helps, Yes, thanks. > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
On 2015-11-10, Kornel Benko wrote: > Am Dienstag, 10. November 2015 um 07:34:42, schrieb Guenter Milde > Dear Kornel, for a safe handling of XeTeX + TeX-fonts without hacks in the LyX code, I recommend to allow this combination only, if "inputenc" == "ascii". for a safe handling of LuaTeX + TeX-fonts without hacks in the LyX code, I recommend to allow this combination only, if "inputenc" != "auto". >> Non-inverted XeTeX export tests would require documents with either >> "inputenc" == "ascii" or "useNonTeXFonts" == "true". > I can adapt the test machinery to do it. Either this, or just invert the tests until the document(s) have "automatic" TeX vs. non-TeX fonts. > How to proceed with "inputenc" if it is set to > auto > default > iso8859-1 > latin1 > iso8859-2 > iso8859-15 iso8859-* > koi8-r > utf8 > utf8x For export with XeTeX and TeX-fonts, all these must be set to "ascii". > utf8-cjk > EUC-JP-pLaTeX invert XeTeX + TeX-fonts tests, or set useNonTeXFonts to true. utf8-plain Set useNonTeXFonts to true. For LuaTeX + TeX-fonts, only "auto" needs to be changed. Preferably to the document languages default encoding, but any 8-bit encoding or ascii will do. Mind, that changing the inputencoding is only seldom tested and can exhibit a number of currently hidden problems. For example, the Russian documents fail with inputenc==ascii due to #9637 (textgreek and textcyr depend on font-encoding, not input encoding) where the spurious \textcyr commands interfere with ERT in the document. OTOH, the utf8 inputencoding fails with Greek and Russian due to #9681 (textgreek and textcyr also required for encodable characters). I therefore recommend also test exporting documents with pdflatex and inputenc=ascii as well as inputenc=utf8. BTW: Despite its name, "inputenc" == "default" is a very fragile expert option: encode the file in (maybe several) language default encoding(s) but don't call inputenc nor include encoding switching code... This setting should not be part of the automated export tests.) Hope this helps, Günter
beamer workflow
dear all, when i insert a new frame, add the title and hit enter the new line is set to “Frame” similarly if i am editing the contents of my frame which is an indented standard environment enter gives me a new line set to “Frame” is it possible to have the environment default to “Standard" in these two cases? i think the current default basically never makes sense, or am i missing something? thanks, ed. ps. recently made the switch from 2.0 to 2.2dev because of the font trouble, you did a great job on 2.2dev which seems already very stable!
Re: [LyX/master] Reset encoding after insets and environments also for LuaTeX with TeX fonts.
Am Dienstag, 10. November 2015 um 07:34:42, schrieb Guenter Milde
> Dear Kornel, dear LyXers,
>
> sorry, there were typos in my last post
> (On 2015-11-09, Guenter Milde wrote ...).
>
> Trying again.
>
> On 2015-11-09, Kornel Benko wrote:
> > > Am Montag, 9. November 2015 um 15:50:09, schrieb Guenter Milde
> > >> On 2015-11-09, Kornel Benko wrote:
>
> > Thanks, I searched for attachment ...
> > Applied.
> > Running export tests ...
> > Still 165 failed. Not really better.
>
> The patch should disable XeTeX & TeX-fonts unless inputenc is explicitly
> set to "ascii". Unfortunately, the patch does not work.
>
> Even if it worked, most XeTeX tests would still fail, but it would be
> better.
> Intended behaviour:
>
> * With the current default settings (use TeX-fonts, inputenc="auto"), the
> XeTeX view/export is disabled.
>
> +1 the fragile corner case with no advantage over pdflatex export is no
> longer easier to reach than the "proper" use of XeTeX (with non-TeX
> fonts).
>
> * If the user sets Document>Settings>Language>Encoding to ASCII,
> or Document>Settings>Fonts>use non-TeX fonts to True,
> XeTeX export becomes accessible.
>
> +1 the safe way to use XeTeX with TeX fonts works. So users who rely on
> this exotic combination can still use it.
>
> * Testing for XeTeX export with default document settings
> (use TeX-fonts, inputenc="auto") will always fail ("no export route
> found"), because we explicitly close this "fragile" export route.
>
> +1 no false positives, no surprises.
> We expect this combination to fail (similar to pdflatex + non-TeX fonts)
>
> +1 default XeTeX+TeXF tests can safely be inverted.
>
> Non-inverted XeTeX export tests would require documents with either
> "inputenc" == "ascii" or "useNonTeXFonts" == "true".
>
I can adapt the test machinery to do it.
How to proceed with "inputenc" if it is set to
auto
default
iso8859-1
latin1
iso8859-2
iso8859-15
koi8-r
utf8-cjk
utf8
utf8x
EUC-JP-pLaTeX
I understand, that auto, default, utf8* should be mapped to ascii, but what to
do with the rest?
(Especially iso8859-*)
> Günter
Kornel
>
signature.asc
Description: This is a digitally signed message part.
Re: No patch file for the major release, right?
Le 10/11/2015 04:15, Scott Kostyshak a écrit : I just want to confirm that we only publish patch files for minor releases and not for major releases. Is that correct? Yes, it is correct. JMarc
Re: We now include both png and svgz?
On Tue, Nov 10, 2015 at 4:13 AM, Scott Kostyshak wrote: > When experimenting with building the tar balls, I noticed a significant > difference in size between 2.2.0dev and 2.1.4. > > lyx-2.1.4.tar.gz is 20.8 MB > lyx-2.2.0dev.tar.gz is 24.8 MB > > A quick check seems to show that most of the change comes from now > including .svgz (in addition to .png). Why do we include both? > > I just wanted to check that this is expected. > > Scott At the moment you cannot use LyX with Qt4 because it cannot read svgz files, and the code is not correctly falling back to png files. So yes, we need both, otherwise we will have to require newer versions of Qt. Vincent
Re: #8077: command-alternatives doesn't work with layout Chapter
On 10/11/2015 1:35 p.m., LyX Ticket Tracker wrote: #8077: command-alternatives doesn't work with layout Chapter +- Reporter: aparsloe| Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: Component: general | Version: Severity: normal | Resolution: Keywords: infoneeded | +- Changes (by uwestoehr): * keywords: => infoneeded Comment: Is this bug still in LyX 2.1.4? I had to check to see what I had been doing at that time (4 years ago). The bug is still there in 2.1.4. However it had slipped out of mind and I don't think it is an important one. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
export test status (was: [LyX/master] Store both sets of font selections)
On 2015-11-09, Kornel Benko wrote: >> I rerun the failed export tests (265), and all of sudden now only 16 >> of them did not pass. ... > It would have been so nice. But I was mocked (probably by myself). > We have now 260 failed export tests. > *.pdf4_texF: 139 This is XeTeX with TeX fonts. It currently always fails because the encoding after footnotes, tables, boxes, and some other insets is set to the document language default. I suggest to take these somehow out of calculation for now. > *.pdf5_texF: 28 > *.dvi3_texF: 27 This is LuaTeX with TeX fonts. There is a problem with "luainputenc": it fails for more than one encoding in the source file. (see http://www.lyx.org/trac/ticket/9740, attachment xetex-wrong-encoding-after-footnote.lyx Testcase 2 for encoding reset after insets, fails also with LuaTeX, as luainputenc cannot handle more than one encoding! Invert for all documents that have more than one encoding. > *.pdf5_systemF: 25 > *.dvi3_systemF: 14 This is LuaTeX with non-TeX fonts. Reasons for failure are usually non-compatible documents: * preamble code or ERT that requires/expects Babel or inputenc * packages that require TeX fonts * use of incompatible packages While it would be good to make documents that ship with LyX more robust, this can only be done on a case-by-case basis and requires coordination and time to get it right. Test with documents explaining use of packages incompatible with Xe/LuaTeX should be inverted. It would be good to have a list of failed tests and error logs. > *.pdf4_systemF: 12 This is LuaTeX with non-TeX fonts. The same reasoning as for XeTeX. > *_pdf3: 4 > *_pdf2: 4 > *_pdf:2 > *_dvi:3 > The last 4 rows stem from > 1.) templates/IUCr-article.lyx > export/templates/IUCr-article_dvi > export/templates/IUCr-article_dvi3_texF > export/templates/IUCr-article_dvi3_systemF > export/templates/IUCr-article_pdf > export/templates/IUCr-article_pdf2 > export/templates/IUCr-article_pdf3 > export/templates/IUCr-article_pdf4_texF > export/templates/IUCr-article_pdf5_texF > export/templates/IUCr-article_pdf5_systemF I get here a Warning: Die Dokumentklasse ist nicht verfügbar Do you have the required documentclass file iucr.cls? (Not available in Debian's TeXLive, nor on CTAN. The LyX wiki http://wiki.lyx.org/Layouts/IUCr says "Download all files from ftp://ftp.iucr.org/templates/latex/ ") IMO, we can restrict testing to a (complete) standard TeX installation and this document can be ignored. > 2.) examples/fr/seminar.lyx > export/examples/fr/seminar_dvi > export/examples/fr/seminar_pdf > export/examples/fr/seminar_pdf2 > export/examples/fr/seminar_pdf3 When I open the document and click the various export-as buttons, these exports work here without error. (Although export with pdflatex as well as lualatex leads to incorrect results.) > export/examples/fr/seminar_pdf4_texF > export/examples/fr/seminar_pdf5_systemF Seminar is a quite old and unmaintained package, originally intended for Postscript output. It is not expected to work with XeTeX/LuaTeX. XeTeX and seminar fails due to some undefined command and there seems like an incompatibility with seminar and polyglossia. I suggest inversion. > 3.) examples/fa/splash.lyx > export/examples/fa/splash_dvi > export/examples/fa/splash_pdf > export/examples/fa/splash_pdf2 > export/examples/fa/splash_pdf3 I get: ! Package fontenc Error: Encoding file `lfeenc.def' not found. (I don't have texlive-lang-arabic: /usr/share/texlive/texmf-dist/tex/latex/arabi/lfeenc.def installed here. Are you sure you have it?) > export/examples/fa/splash_pdf4_texF XeTeX + TeX fonts: Export fails because there are no Arab entries in "lib/unicodesymbols". Can be safely inverted. > export/examples/fa/splash_pdf4_systemF Default non-TeX fonts don't have Arab characters. Can be safely inverted until we have "parallel setup for non-TeX fonts" and choose a suitable font here. Günter
Re: [patch] Finding the generated latex file
Le 10/11/2015 01:08, Scott Kostyshak a écrit : On Mon, Nov 09, 2015 at 08:04:29AM +, Guillaume Munch wrote: Le 06/11/2015 10:35, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 04:16, Scott Kostyshak a écrit : I also agree that it's better to replace the alert with a message on stderr. I noticed that there are already similar messages on the terminal when files cannot be removed. Attached is a patch. Shall I commit it? Although I personally like this (as I noted above), I think we should get opinions from a couple of other LyX developers. From a quick search, we have been giving a dialog for more than 10 years so there might be a good reason for it. I think that a stderr message is good enough. I do not remember a discussion about having this dialog. If you want to know, find when it was introduced, and look at lyx-devel archives from this time. JMarc I suggest that people who requested this patch decide whether they want to do this extra check, or ask me to commit already. :) I think this idea has simmered for long enough. Thanks for your patience, Guillaume. And thanks for the patch. Please commit. Done. Guillaume
