>|> I'm getting exact matches with musixflx.c output. >| >|Marvellous - and as per the subsequent emails, it looks like longer-term >|we'll be heading towards retiring musixflx.c completely.
I have a question to musixtex-ers about how to do this. It's possible to add a few lines to musixtex.tex so that *if* processed by luatex *and* musixflx.lua is accessible, the latter will be called directly by luatex. Check out http://icking-music-archive.org/software/musixtex/musixflx-lua.zip if you want to try this yourself. It's a nice party trick but I've come to the realization that this approach is mistaken. Firstly, there are disadvantages to requiring luatex. PDF output is the default and so an ugly option is needed to force DVI output when Postscript slurs are used. Also UTF-8 input and OTF fonts are expected, which will be problematical unless the traditional representations like \'{e} are used for accents. Secondly, although it's likely that musixflx.lua can re-invove luatex, and musixtex.tex can be further extended to call dvips and then ps2pdf after the second pass, this approach seems clumsy and inflexible. I now think a better approach is to use a lua wrapper script to successively call etex, musixflx[.lua], etex, dvips and ps2pdf. I'm sure most of you use a similar such script now: a bat script in Windows or a shell script on other platforms. A platform-independent *lua* script could replace these. Pmx and M-Tx packages could provide extended versions to incorporate pre-processing. Is this a good idea? Bob Tennent ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
