Running under Windows 98, LilyPond generates .PS, not .PDF, files for
two independent reasons:
(A) Ghostscript can't find its initialization files.
(B) Once (A) has been cleared up, the long gs... command invoked
by LilyPond.exe fails.
=============
Regarding (A)
=============
On 2 July 2005 Paul Scott quoted the Ghostscript error message
> GPL Ghostscript 8.15: Can't find initialization file gs_init.ps
Jan subsequently recommended setting environment variables to cure this.
But it would not be surprising for a user to have, independent of LilyPond,
Ghostscript 8.51 also installed (which is true in my case), and so
handling this problem through the Windows registry would be safer than
setting global DOS environment variables that would affect all Ghostscripts.
I created the registry key
HKEY_LOCAL_MACHINE\Software\GPL Ghostscript\8.15
and into this key I inserted the two value-data pairs
GS_DLL C:/PROGRA~1/LilyPond/usr/bin/gsdll32.dll
GS_LIB C:/PROGRA~1/LilyPond/usr/share/gs/lib
The first of these ensures that gs.exe will find its application extension.
The second ensures that gs.exe will find its various initialization files.
gs did find this information and now stops complaining that it can't
find gs_init.ps
[Remark 1: Windows uses backslashes \ but gs wants to see the
forward slashes / indicated above.]
[Remark 2: For the reader not familiar with DLLs, that filename above
contains L's, not 1's: GSDLL32.DLL ]
[Remark 3: Since LilyPond's (huge) .PS files have the fonts embedded, it
doesn't seem likely that it would be necessary to add a third value-data
pair to cover GS_FONTPATH. And in any case, C:\WINDOWS\FONTS is probably
not needed in gs's fontpath, since this Windows 98 directory contains only
TrueType fonts (about 300 .TTF files). It would be very helpful to me to
be told what external fonts gs needs, and *why*. I don't see why it needs
any at all.]
=============
Regarding (B)
=============
On 1 July 2005 Paul Scott sent the screen-output generated by
lilypond.exe --verbose
and the final line was
> Invoking `gs -dCompatibilityLevel#1.4 -sPAPERSIZE#"a4" -dNOPAUSE -dBATCH
> -r1200 -sDEVICE#pdfwrite -sOutputFile#"simple.pdf" -c .setpdfwrite -f
> "simple.ps"'...
This fails (lilypond does not generate a .PDF file). My best guess at
this point is that since the maximum length of an individual DOS command
is 127 characters, the above gs invocation gets truncated. In particular,
gs doesn't get the information
-f "simple.ps"
so when gs asks (probably) to open a file whose name is (probably) the
empty string, Windows 98 will complain File Not Found.
Windows NT and Windows XP presumably allow a longer command line and don't
have this problem.
Fixing this for Windows 98 would involve changing the part of the source
code of lilypond.exe which generates the above gs invocation. In the
directory
C:\PROGRA~1\LilyPond\usr\share\gs\lib
the two DOS batch files
ps2pdf14.bat
ps2pdfxx.bat
demonstrate a technique using @files "to avoid overflowing the command line".
You would think that a temporary work-around would be easy: I should be
able to write a DOS batch file that uses the @files technique to generate
the equivalent of the above gs command with much fewer actual characters.
I could then apply this batch file to a .PS file generated by LilyPond.
The catch is that in the pure DOS batch language, there is no mechanism at
all for changing a substring of a string, so that given only the input
filename "simple.ps", I cannot (in DOS batch) create the name
"simple.pdf".
[Useless side remark: Windows NT and XP do have a limited
substring-replacement mechanism.]
I have never used Windows 98 VBScript for anything very intelligent, and
my VBScript is very rusty. However, I will have to scratch around and see
if I can write a script that works.
So why am I saying all this to lilypond-user and not to bug-lilypond?
Because if I'm right, Windows 98 users should know that a quick fix is
unlikely. Messing with the registry and applying a (hypothetical)
VBScript script may not appeal to a casual user.
With the massive amount of work LilyPond developers must have (and let it
be said, they have my most sincere admiration), it is not likely that
fixes will be made (A) to do automatic registry entries and (B) to modify
the gs invocation just so that W98 users can get .PDF output.
[I use W98 rather than WXP because I don't need *more* security problems
than I already have, and I also dislike the notion of running an OS that
is deliberately programmed to fail under certain circumstances (such as
when I add a couple of pieces of hardware).]
-- Tom
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
