Am Sonntag, 26. April 2015 um 16:21:51, schrieb Enrico Forestieri <[email protected]> > On Sun, Apr 26, 2015 at 02:50:51PM +0200, Kornel Benko wrote: > > > Sorry for private mail, > > I didn't want to pollute the bug-tracker too much. > > I think this is better discussed on the list rather than privately. > Actually, I also think that if this kind of discussions only take place > on the bug tracker they risk to go unnoticed until their results bite you.
OK. > > The reason for 0bb378ba/lyxgit was non-working preview of some tex macros > > not known by lyx, although the file compiles with e.g. lualatex. > > Sorry, this is very vague and doesn't tell me anything. The issue raised > on the bug tracker would have been solved by the one-liner patch I posted > there. Maybe other similar issues can be solved similarly. Attached a trivial example. (Yes, I know how to insert graphics) > > I would be _very_ unhappy to get this 'behaviour' back. > > But I am _very_ unhappy with the current 'behaviour' in master. > > > But why not change the lyxpreview2bitmap.py instead? > > What do you mean? If you tell it to use pdflatex, it will use pdflatex, > thus defeating the superior dvipng route. Then, there is another aspect > to consider. Before http://www.lyx.org/trac/changeset/0bb378ba/lyxgit, > the previews were always generated using dvipng, unless non-TeX fonts > were used, in which case xelatex and the inferior legacy method was used. > The scripts also try to be clever, by detecting the presence of > postscript specials that dvipng cannot handle and using the legacy > method in those cases. > > In this way, all previews were generated in the same way for all users. > But now, if the document doesn't set a default output, the overall > default output set in the preferences is used. This means that we may get > different results for different users, leading to seemingly mysterious > behaviours (see, for example, the discussions in #7850 and #8258). IMHO it should use the same latex engine as used for the desired pdf output. > I am for reverting http://www.lyx.org/trac/changeset/0bb378ba/lyxgit > and adopting the much simpler patch attached to #9371 for solving that > specific issue. > > If this is not the opinion of the majority, then something has to be > done for solving the problem of the inferior quality of the previous > generated by the legacy method and the problem of its slowness. Yes, something should be done. > I think that the poor quality is due to the use of the T1 font encoding > that forbids the use of vector fonts for the previews. This could be solved > by using either the "lmodern" or the "ae" package. But there would still > the problem of the slowness of the legacy method (it's about 10 times > slower than the dvipng method), mainly due to the use of ghostscript. > Also in this case there could be a solution, by using alternative methods > for generating pngs. For example, pdftocairo can generate pngs and is much > faster than gs. > > Still, I would see this as a palliative and think that reverting the > offending commit is better. Let's see what others think. Maybe a preference option? Something like Latex engine used for preview creation standard (means use the same engine as the document) latex pdflatex etc. ? Kornel
signature.asc
Description: This is a digitally signed message part.
preview.lyx
Description: application/lyx
dialog-show_mathmatrix.pdf
Description: Adobe PDF document
