Daniel Taupin wrote: > > Christof Biebricher wrote: > > > > On Thu, 2 Jan 2003, Daniel Taupin wrote: > > > > > > > > Therefore, if somebody gives me a checked introduction and manual to > > > preprocessors, I will be glad to include this as an additional chapter > > > in musixdoc.tex. > > This is a good proposal; however, I think it suffices in the beginning that > > a reference is given. Don also does probably not use M-Tx, but he made a > > remark in his documentation. > > JUST give me the text which should be included in a new chapter > dedicated to preprocessors (maybe between the introduction and the > global reference manual), and I include it (with obvious corrections > needed for better understanding, since what anybody write is always > clear for him, not for the reader :-)) > > > > > > Concerning musixflx, there is a plain C source of it. And I provide in > > > musixtex.tex (unless error...) the executable for DOS/MSDOS un der > > > Windows. Starting from this C source, a set of "makefile's" could be > > > include to compile it. > > I know. The Icking archive contains everything necessary, but not all > > distributions. > > Just privide me with the makefile's you have. Users knowing the > existence of "make" are always clever, provided that get a reasonable > makefile which they are able to adapt (one can add comments inside). > > > > > > What I would like would be, either a Makefile or a script for Linux and > > > Unix users, > > > and another for the TeXLive distribution, which would make the whole of > > > the needed installation. > > In my opinion, it is the job of the distributors to make rpm's for automatic > > installation. All major distributors of linux systems have a musixtex rpm > > which makes it quite simple to install, including the executable of > > musixflx. > > The TeXLive contains system dependent programs, but a good part of it > is symbolic (sources). > Anyway, what we should do is not (not only) including it in a > distribution, but giving people a stand alone installator for musixtex. > Including those who already installed TeXLive, but not MusiXTeX, of with > an obsolete MusiXTeX as provided in the CDROM. > > > MikTeX also has a MusixTeX package, but it is pretty old and lacks > > musixflx.exe. Of course, one has to give to the distributors a tarball of > > zip-file that contains > > everything required. We would have to decide who should do that, once we > > have the permission of all the authors (You, Don Simons, Dirk Laurie, Rainer > > Dunker etc.). > > No problem for me, I have set all my things as GPL. > > > Then I will try this installation on my Linux system. It is noted that > > > the TeXLive 7 provides a correct installation of MusiXTeX (maybe a bit > > > out of date, but not too much), but id does n,ot provide with the > > > preprocessors. > > > > > > > 1) the musixtex packages of the distributors whould contain also the >preprocessors > > > > and their documentation and particularly the executables for Windows OSs, > > > > > > The problem is that musixtex.zip is an all-system package, since it only > > > contains symbolic texts or portable binaries like TFMs. > > Anyway, what is distribution dependent is the structure. TeXLive has a > supposedly standard TDS, but all sistribs choose arbitrary subdirectory > names to put musixtex: sometimes "misc" sometimes "musixtex", sometimes > "public/musixtex", etc. Look for example of the position of the EC and > CM fonts. > > d:/emtex/mfinput/ec/ecrm1000.mf > d:/emtex/tfm/ec/ecrm1000.tfm > e:/home-texmf/fonts/pk/cx/jknappen/ec/ecrm1000.300pk > e:/home-texmf/fonts/pk/cx/jknappen/ec/ecrm1000.600pk > e:/home-texmf/fonts/pk/ljfour/jknappen/ec/ecrm1000.600pk > e:/tl72/texmf/fonts/source/jknappen/ec/ecrm1000.mf > e:/tl72/texmf/fonts/tfm/jknappen/ec/ecrm1000.tfm > > c:/c/share/texmf/fonts/afm/cmr10.afm > c:/c/share/texmf/fonts/type1/pfb/cmr10.pfb > d:/emtex/mfinput/cm/cmr10.mf > d:/emtex/tfm/cm/cmr10.tfm > e:/home-texmf/fonts/pk/cx/public/cm/cmr10.300pk > e:/home-texmf/fonts/pk/ljfour/public/cm/cmr10.600pk > e:/home-texmf/fonts/pk/ljfour/public/cm/cmr10.657pk > e:/home-texmf/fonts/pk/modeless/public/cm/cmr10.329pk > e:/home-texmf/fonts/pk/modeless/public/cm/cmr10.600pk > > e:/tl72/texmf/fonts/afm/bluesky/cm/cmr10.afm > e:/tl72/texmf/fonts/pfm/bakoma/cm/cmr10.pfm > e:/tl72/texmf/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk > e:/tl72/texmf/fonts/source/public/cm/cmr10.mf > e:/tl72/texmf/fonts/tfm/public/ai/aicmr10.tfm > e:/tl72/texmf/fonts/tfm/public/cm/cmr10.tfm > e:/tl72/texmf/fonts/type1/bluesky/cm/cmr10.pfb > > Thus, a musixtex installer has to find whether each file already exists, > then replace it in place, or install it in a place where the new release > will duly overwrite it. Otherwise, nobody knows which version will be > taken at run time! > > > Correct, but that also applies for the preprocessors that have TeX macros > > that belong into $TEXMF/tex/generic/musixtex. Furthermore, the source > > files of the preprocessors are also available: the FORTRAN source for pmx, > > and Pascal for M-Tx. In Linux this is not a problem, > > because the compilers are free and good translation programs of Fortran or Pascal > > to C exist. Both preprocessor packages contain also executables for > > DOS/Windows. It is still possible to keep musixtex.zip separate in CTAN > > as it is now, but to put the zip files of pmx and M-Tx into the CTAN > > musixtex subdirectory. > > Anyway, my intention is to have in the ZIP file a directory structure > which distinguishes: > - TeX sources (*.tex, *.sty, *.cls, etc) > - Metafont sources > - TFM files > - PK files > - executable files for various systems. > > Then, in the worst cas, people unzipping it with subdir conservation > (warning for pkunzip...) could move each set in a reasonable place... > not forgetting "mktexlsr" is most cases. > > > > > > There should be an installation package for: > > > a) emTeX > > emTeX is pretty old. I had to abandon emTeX about a decade ago, > > because it was difficult to operate it in our Windows LAN. > > MikTeX is the present standard. > > > b) fpTeX (the Win32 distrib of TeXLive) > > > c) Mac (but which systems, I have no knowledge) > > > c) Linux > > We have to find out who is responsible for maintaining the packages and > > to submit the sources. If it is clarified how the CTAN subdirectory > > looks like, then it suffices to anounce to the package maintainers > > to download their sources from the CTAN subdirectory. > > Uhhhh... the directory structure of the CTANs is not conform to local > TDS structures. > > > > > > However, the big problem (usually overlooked by people making a > > > distribution) is to have a installation package which not only installs > > > froim nil, but also updates existing obsolete installations, and also > > > respect distinct installations without destroying them. The reason for > > > that last statement is that NOBODY can be sure that the new release > > > willk work (possible bugs of conflicts) so that [s]he obviously want to > > > have the New and the Old working in parallel, in cas of. > > This is indeed a problem because many installations overwrite an earlier > > one regardless of the version munber. On the other hand, all installations of > > TeX I know contain > > a global TEXMF directory and one or even more local ones which override > > the global directory. Furthermore, it is easy enough to include a shell-script > > for TeX macro updates which are by far the most important updates. > > Nope! Many people, including me at part time, still have emTeX, with no > TEXMF and no need for mktexlsr and other tricks. And many other people > have put their ancient version of musixtex at a definite place whose > name is "somewhere". > > > > > > But, considering PMX, please give me the whole of what has to be > > > distributed, and I shall do something. > > Excellent, thank you. As I said, we should decide whether to keep pmx.zip > > separate from musixtex.zip, but put them into the same subdirectory, or > > wether the contents of both should be fused. > > I think it should be separate, since updates of musixtex should not > require PMX updates, and conversely. > > > > > > There is one in English in musixdoc.tex, but it concerns only MusiXTeX. > > > Any changes in this chapter (which is NOT the technical chapter) is > > > welcome. > > Sure, I know and use musixdoc. It is excellent in its present form, but > > you have to admit that for the average choir conductor it is quite difficult > > This is a "reference manual", not and educational manual. > > > to start with. If he then reads that it is `an awesome job which gobbles up > > a lot of your time', then he stops right away if he just wants to edit > > quickly a music piece to his needs. But many people like Joel, Andre or > > me do just that week for week and it works very quickly and is certainly > > not an awesome job anymore. Furthermore, you may consider to replace that > > deterring statement by something more encouraging. > > Please make me a proposal. > > > > Thank you for your cooperation. I hope that all people from the mutex list > > also give their opinion. I am sure it would help many musicians who want > > to do professional type-setting of music without the tremendous costs of > > the commercial type-setting programs. > > > > Regards, Christof > > -- > > ------------------------------------------------------------------------ > Daniel Taupin, 91400 ORSAY - France > E-mail= mailto:[EMAIL PROTECTED] > Home/fax: (33)1.60.10.26.44. Rep.: (33)1.60.10.04.13, fax (work) > (33)1.69.15.60.86
-- ------------------------------------------------------------------------ Daniel Taupin, 91400 ORSAY - France E-mail= mailto:[EMAIL PROTECTED] Home/fax: (33)1.60.10.26.44. Rep.: (33)1.60.10.04.13, fax (work) (33)1.69.15.60.86 _______________________________________________ TeX-music mailing list [EMAIL PROTECTED] http://sunsite.dk/mailman/listinfo/tex-music
