On Sun, Nov 01, 2015 at 10:31:32PM +0000, Guenter Milde wrote: > On 2015-11-01, Scott Kostyshak wrote: > > On Sun, Nov 01, 2015 at 07:37:41PM +0000, Guenter Milde wrote: > >> On 2015-10-30, Kornel Benko wrote: > >> > Am Freitag, 30. Oktober 2015 um 19:23:02, schrieb Scott Kostyshak > >> > <skost...@lyx.org> > > >> > Besides we have ATM about 200 failing export test cases. > > >> Too many to be helpfull. > > > I don't understand this logic. > > For me, the tests are meant to find problems with LyX code. > Also, they should ensure that commits do not break anything important. > > With 200 failing test cases, the test suite starts to resemble the issue > tracker: we can not ensure there is no known bug in LyX, nor can we > ensure that the test suite runs without failure. > > We are classifying bug reports and start with the important ones. > > The same should be done for failing export tests. In order to concentrate > on the important stuff, we need a way to filter less important tests > (maybe just do not run them.) But like the less important bug reports, we > should not remove them altogether without convincing reason.
I see what you mean. Thanks for explaining this. I agree. > >> How many of these are for the obscure combination of XeTeX and TeX fonts? > >> While there is a use case for LuaTeX and TeX fonts, I can't see a reason to > >> use XeTeX instead of pdflatex with TeX fonts! > > > The use case that I have in mind is simply that I expect our users might > > use such a combination. If we don't want to support the combination, we > > should output a useful error message explaining why, or just disable the > > combination. If not, users will use it. > > Or treat the combination XeTeX + TeX fonts as a non-standard use case > that we do not prevent but discourage. OK but how do we discourage? In the documentation? What about one of those warning boxes that has the checkbox "don't show this warning again". So the first time a user tries to compile with XeTeX and TeX fonts it warns them "It is not useful to use XeTeX and TeX fonts. You might prefer to use PDF (pdfTeX) or use PDF (XeTeX) but use system fonts by going to Document > Settings > Fonts. > This is similar to, e.g. the "language default (without inputenc)" option > for the inputencoding: this option fails inevitably without additional user > input in the LaTeX preamble. OK but I think it is a stranger case that a user goes into the settings and changes that than just click on the button for PDF (XeTeX). > > Many LyX users do not have the understanding that you do. They do not > > even understand what it means to use non-TeX fonts. They might just > > read something about XeTeX and start using it by clicking on our button > > that says PDF (XeTeX). > > The "inviting" toolbar button starting this obscure and bad-supported > export route is the real problem. Ah yes I agree with this. > This is, basically, what I want in Ticket #9744: the toolbar button would > call XeTeX with Unicode fonts by default. I see. That does seem like a good idea then. > > The purpose of the tests is just to prevent regressions. Sure, maybe it > > is true that something was working by luck before, but I still think it > > is reasonable to try to preserve it. > > Restoring behaviour that was half-broken before and will be of no use > later (except for ill guided one) should not be a precondition for > getting the test suite in a usable shape again. > > The follow-up fixes led to even more "regressions" (or to surfacing of > hidden problems). I see. I did not know it was a similar situation. > >> Solving all issues that arise from this combination is diverting > >> attention and resources from more important tasks. > > > Agreed. > > >> Also, we identified some generic problems with this combination that are > >> not solvable in the short term: third party packages well as documents > >> not prepared for this use case. > > >> Just reverting failing XeTeX export tests for the moment would allow us to > >> concentrate on the remaining failing test and get the test suite in a > >> usable state again. > > > Fine with me. Kornel, OK with you? We could create a bug report so that > > we do not forget about the tests. Then we could just invert all of the > > pdf4_texF tests that are failing. I have in mind just pasting the long > > list of individual tests, rather than using regexes. > > Actually, I'd rather suspend than revert - whether they fail or pass has > currently no predictive value regarding regression or progress in solving > the underlying problems. I see your reasoning now. I will start a new thread about testing where we can discuss this. > I am all for the additon of special test cases. > We should find a way to specify the to-be-tested export route(s) (special > naming or sub-directories, say) for these test documents. I think we all like these special test cases. Hopefully we can implement more of them to avoid many of the fragile tests we have. Scott
