On Tue, Mar 11, 2014 at 4:10 AM, Roy Xia <[email protected]> wrote: > Hi everyone, > > So I've been studying the converter scheme in pursuit of the aforementioned > project suggestion. I've been mostly focusing on the particular changes > mentioned in the explanation on the wiki page; that is, to consolidate > output formats under one extension type but use qualifiers to distinguish > output format variants from one another, and to also refactor the converter > code to handle latex flavors more elegantly. I suppose my first question to > you all is whether there are any alternative suggestions or additional goals > out there for overhauling the converter scheme. > > I've also been studying the source code, gathering ideas on how the overhaul > might be implemented. As far as consolidating "variant" output formats, I > suspect that for the most part the actual conversion code will remain the > same, but a.) functionality for parsing and recognizing qualifiers will need > to be added, and b.) the path-finding algorithm for finding the shortest > chain will probably need to be somewhat modified to first search for output > formats with the desired qualifier and then search for the generalized > output format. I also suspect that the path-finding algorithm will be > further complicated by the presence of multiple flags; for example, I have > noticed that pdf7 (PDF cropped) is not labeled as a vector graphics format > whereas other pdf variants are, so if the pdf extension is to be > consolidated I suspect that vector graphics format will also have to become > a qualifier of some sort. In that sense, there may need to be some judgement > on which converter chain to use if, for example, the search only results in > two valid paths, one with qualifier A but not B, and another with qualifier > B but not A. All said and done though I'm not an expert on the converters, > so perhaps someone could shed some light on other considerations or critique > my analysis of the task at hand. > > As for dealing with the latex flavors, within the context of the converter > it seems they aren't used for much aside from generating log and aux > files--in fact, unless I missed something, the different flavors only differ > from one another by which program they use to generate those files, and the > current code seems to determine that program solely from the command > associated with the converter anyway. My gut instinct says to just have a > general "latex" flag set for each of these formats and automatically > determine the proper program to call from there without knowing what > specific type of latex it is, but since I'm not that experienced with latex > or any of its flavors I'm not sure if that's the right approach. Again > perhaps someone could shed more light on this subject for me, or make sure > my thinking isn't totally off track.
Keep in mind that the three major TeX engines (pdftex, xetex, luatex) have some substantial differences that sometimes (indeed, often) make it impossible to compile the same Lyx file on some of them. Example: if a LyX file uses system-wide fonts instead of LaTeX font, then only XeTeX and LuaTex can be used. Viceversa, if a file contains figures/diagrams produces with pstrick commands, then Luatex (and possibly Xetex, I am not sure) cannot be used. Theses are just two examples, there are others. The bottom line is that often the choice of the TeX engine is constrained by the Latex commands and packages used in the Lyx document. Cheers, Stefano -- __________________________________________________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA [email protected] http://stefano.cleinias.org
