Re: Rounded beam bug

[Mats Bengtsson]

> > What should be solved is the fontpaths make rule when you 
> > have compile for multiple platforms, as you pointed out
> > in a previous email. I'd really prefer if someone who knows
> > more about these aspects of the building process could implement 
> > that. 
> > 
> > Also, what should be done is to clean up the environmental
> > variable settings in ly2dvi. I'm working on that.
> 
> ?
> In my ly2dvi, I have 
> 
>       environment = {
>               ## todo: prevent multiple addition.
>               'TEXMF' : "{%s,%s}" % (datadir, kpse) ,
>               'GS_FONTPATH' : datadir + '/afm:' + datadir + '/pfa',
>               'GS_LIB' : datadir + '/ps',
>       }
> 
> what do you intend to fix exactly?

I realize I hadn't looked too carefully at ly2dvi in 1.5.43.
I don't understand why you should set the GS_* variables, 
ghostscript is never run in ly2dvi, right? Also, we could
get rid of all the cache_pks_p stuff. 

According to the python manual, os.popen() is unreliable in
Windows, we should verify that it works before releasing this
solution to our poor windows users.

> > I also 
> > plan to try to get rid of these seperate files for each
> > header field. It turns out it's actually fairly simple to 
> > read the appropriate number of lines from the .tex file 
> > for each field.
> 
> You may try, but I will reject that patch. I think that it is a
> totally braindead idea to try to separate the completely arbitrary
> user input (which is allowed in the header fields) and the equally
> braindead and arbitrary TeX definition syntax with nested braces,
> escape sequences and what-have-you. The separate file approach is much
> more robust. You can still construct invalid (La)TeX, but it will not
> confuse ly2dvi.

Well, seen from another point of view, you just replace one error 
message with another one if the user TeX code is illegal. I actually
found the current solution with -H more clumsy with all the different
files. I know how to handle arbitrarily nested braces and escaped 
braces and could easily generate an error message that points out 
which setting is incorrect. What else could break?  What I 
miss from the good old days when we didn't use -H is the possibility
to specify a Lilypond generated .tex file as input to ly2dvi.
It may sound useless but I see at least two applications:

- You have run lilypond separately on a big score and don't want
  to wait another 30 minutes or 3h (depending on the slowness of
  your machine) to rerun lilypond again in ly2dvi. This happened
  to me a number of times when we had the stack size bug in 
  ly2dvi.

- You may want to combine the output of some \score sections from
  different source files into one dvi file. Example:
  lilypond a.ly -> a.tex, a-1.tex, a-2.tex
  lilypond b.ly -> b.tex b-1.tex, b-2.tex
  ly2dvi -o score.dvi a.tex b.tex
  ly2dvi -o secondmovementparts.dvi b-1.tex b-2.tex
  ly2dvi -o firstinstrumentparts.dvi a-1.tex b-1.tex

Of course, these are low priority issues, my main driving force
was to see how difficult it would be to implement this (in my view)
more elegant solution. 

   /Mats