On Thu, Oct 29, 2015 at 09:04:10AM +0000, Guenter Milde wrote: > * Math.lyx uses packages that either fail to compile or produce wrong output > with XeTeX/LuaTeX (with both, TeX fonts and non-TeX fonts) in any language > (e.g. mhchem) > Also, some accents (e.g. \t) in "mathematical text" are missing in the > output. > > -> invert all */Math.lyx tests with XeTeX and LuaTeX. > -> don't add partial fixes (they may be outdated once the real problem is > solved). > -> consider a safeguard in LyX against using Xe/LuaTeX with non-compatible > packages. > > * fr/UserGuide.lyx compiles but has wrong output for LuaTeX with TeX fonts: > Eg. the ToC is called "Table des matiÃĺres" (should be "Table des > matières"). > This is a bug in Babel (or frenchb.ldf), where detecting > XeTeX/LuaTeX assumes that non-TeX fonts are used and the encoding is utf8. > (It affects other Babel languages as well.) > > -> invert all doc/fr/*.lyx tests with XeTeX/LuaTeX and TeX fonts. > -> don't add partial fixes. > -> consider a safeguard in LyX against using Xe/LuaTeX with non-compatible > packages. > > * es/Customization.lyx > Same problem with LuaTeX and TeX fonts: ToC becomes "ÃŊndice general". > > -> invert all doc/es/*.lyx tests with XeTeX/LuaTeX and TeX fonts. > ...
Thanks for taking a look at these, Günter. I will follow your advice and invert the problematic files and create a bug report that we can summarize the important information in. > >> I believe it would be better to suspend testing the problematic files > >> with "non-TeX fonts" until the issues are solved. > > > Ideally code changes would not be committed before broken tests are > > fixed or the regressions caused by the commits are fixed. That should > > all be done in one commit. > > We cannot expect this for cases where there are several reasons for failure > affecting a large number of documents. (Just consider the size of a single > commit fixing all cases of "missing character".) What happened does not seem good either. Because of the commit several regressions went unnoticed because the tests were broken. I do not mean that the bugs must always be fixed, but we could for example invert the tests affected by the change. This would at least keep the testing output clean and useful. We could then create a bug report so that inverting the tests does not mean we forget about the bug. The tests are meant to notify us that there is a problem. After they do their job of notifying us, we need to make sure we don't forget about the problem (e.g. make a bug report) and move on. > -> We need a framework to handle such "generic" problems like "Xe/LuaTeX > with TeX fonts". > > Suggestion: > > * Code changes/commits that break tests with the default export method of > important documents require immediate action. > > * Problems with other export routes can be handled later (but should not > be forgotten). > > Also, not every developer should be expected to run the export tests for > every small commit - however, there should be a commitment to fix > problems introduced by ones changes. > > > >> Fixing problems in the Manuals found by automatic testing is a good thing. > >> Modifying the Manuals "somehow" just to please automatic testing is not. > > > I agree. I think that in most cases fixing the manuals to compile to > > multiple formats improves the documents and forces us to have clean > > preamble code. > > In this case, the preamble code got more complicated, not cleaner. > Also, it takes time to agree on a best praxis. Yes, good point. > For the test with non-TeX fonts, the preamble code involving lmodern.sty > must be changed, otherwise 8-bit fonts are used with wrong font encoding! > > One possibility would be to remove the special casing altogether, > possibly selecting a better font in the GUI (but this was rejected some > years ago). > > Another option is the following patch (similar in all places where this > preamble code is used): I'm fine with this change, but my opinion should not carry much weight since I really don't understand this well. Scott
