Re: Why is gs-font-load set to #t in Windows package

[Mats Bengtsson]

Quoting Han-Wen Nienhuys <address@hidden>:

> Mats Bengtsson wrote:
> > Hi,
> >
> > In CVS for both stable and development, the property gs-font-load is 
> > set to false
> > in scm/lily.scm. I just happened to notice that it's set to true for 
> > the Windows
> > package (and maybe also in all other GUB versions). Why is this?
> >
> > On Windows, this seems to be the reason that GSView won't display LilyPond
> > generated .ps files by default (which also explains why ugly workarounds as
> > described in 
> > http://lists.gnu.org/archive/html/lilypond-user/2006-07/msg00033.html
> > help).
>
> This is because there were issues normal font loading, but I can't 
> really remember what they were -- I've reverted, and we'll see what 
> happens.

Hold the horses! I have done some more experiments and partly changed
my conclusions. I could manage to produce PDF output using lilypond-book
on LaTeX documents in Windows with version 2.8.0-5, but the same 
procedure failed with 2.8.6-1. Since the LilyPond package just contains
UNIX shell script versions of ps2pdf, I use a native Windows Ghostscript.
I happened to have both version AFPL 8.51 and AFPL 7.04 installed.

What happens is:

- With gs-font-load = #t (which is the default in both the 2.8.0 and  
2.8.6 packages)
 * AFPL 8.51 doesn't understand the path separator / but works if I    
replace every / with \ in the paths in the .psfonts file and
   call ps2pdf with the extra flag -dNOSAFER.
 * AFPL 7.04 can handle / as path separator but doesn't understand
   "../". LilyPond 2.8.0 generated file paths of the form
(C:/Program 
Files/LilyPond/usr/share/lilypond/current/fonts/otf/CenturySchL-Roma.ttf)
   whereas 2.8.6 includes a ../ in the paths:
(C:/Program 
Files/LilyPond/usr/bin/../share/lilypond/current/fonts/otf/CenturySchL-Roma.otf)
   This explains why I had problems with 2.8.6 but not with 2.8.0.

- With gs-font-load = #f, lilypond-book ends with Failed to extract 
Emmentaler-18 from lily-422787386.eps
Failed to extract CenturySchL-Roma, Emmentaler-20 from lily-1252802637.eps
Failed to extract Emmentaler-11 from lily-208503745.eps
Writing fonts to a.psfonts
 and the resulting a.psfonts doesn't contain anything but the top
 lines with comments. I haven't investigated why fontextract.py
 fails.


I also tried LilyPond 2.9.14 some days ago, which had more problems
since it tried to convert all the -1.eps to -1.pdf. I noticed that this 
should be fixed in 2.9.15 but haven't tried that one yet.

Conclusions: - fontextract.py has some problems on Windows if the full fonts
 are embedded in .psfonts.
- Unless you include dos versions of ps2pdf, the font paths in
 .psfonts (when fs-font-load=#t) should use windows style separators.
 Of course, you could claim that users of lilypond-book should use
cygwin, but in my opinion, that's just a good way to scare Windows
users from even trying LilyPond.

  /Mats



> --
>
> Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
>
> LilyPond Software Design
>  -- Code for Music Notation
> http://www.lilypond-design.com