bug-lilypond
[Top][All Lists]
Advanced

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

Re: Rounded beam bug


From: Han-Wen Nienhuys
Subject: Re: Rounded beam bug
Date: Tue, 19 Mar 2002 18:46:19 +0100

address@hidden writes:
> >     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?

it is for some old experimental code, that tried to prepend pfas onto
-f ps output. (I guess).

> Also, we could
> get rid of all the cache_pks_p stuff. 

ok.

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

ok.

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

yes, but seen from my point of view, you want to introduce more
potentially buggy code for what could just as well be handled by TeX.
More code means more complexity. More complex solutions are by
definition less elegant.

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

Why don't you reverse the solution, and implement user-defined
header-field-files in ly2dvi. Then we implement a separate header
output type, so you can run

  lilypond --headers-only foo.ly

and get the appropriate header files.


-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/




reply via email to

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