[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rounded beam bug

From: Mats Bengtsson
Subject: Re: Rounded beam bug
Date: Tue, 19 Mar 2002 17:53:45 +0100

> > 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 

- 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. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]