[Top][All Lists]

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

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

From: Mats Bengtsson
Subject: Re: Why is gs-font-load set to #t in Windows package
Date: Sun, 20 Aug 2006 21:24:09 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.0.5)

Quoting Han-Wen Nienhuys <address@hidden>:

Mats Bengtsson wrote:

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

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

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.



Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation

reply via email to

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