Feta Font - G Clef
Hi, Did LilyPond use to use the G Clef found on the About page of www.lilypond.org? If so, is it possible to have it reinstated in future LilyPond versions under anoter name? I would quite like to use that from time to time. Aligorith _ Listen to music online with the Xtra Broadband Channel http://xtra.co.nz/broadband ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: question about a <> mark similar to a c-> notation...
Hi Han-Wen, hm, i am not sure whether i understood correctly what you mean/want, but for me it looks now very similar to the original ">" sign already being in that feta... Hope it helps... Arno On Sun, 28 Nov 2004 12:20:44 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: Okay, i hope the second attempt includes your suggestions... Better, but the anti-blobbing at the junction is still not perfect. The outside outline should be a straight line ; check what happens with > if you change its value for diminish to 1.0 -- http://www.arnowaschk.de lily-041126.patch Description: Binary data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile-gnome
On Sunday 04 July 2004 17.20, Jan Nieuwenhuizen wrote:
> Pedro Kroger writes:
> > Now it seems to be 'working' (i.e. found the modules), but I got
> >
> > /home/kroger/lilypond/install//share/lilypond/2.3.5/scm/framework-gnome.s
> >cm:129:5: While evaluating arguments to map in expression (map
> > ly:pango-add-afm-decoder (quote #)):
>
> Hmm, that's odd. --enable-gui is supposed to do just that: link
> to pango CVS and provide the ly:pango-add-afm-decoder function.
>
> Could you verify that you have
>
> /* define if you have pango CVS */
> #define HAVE_PANGO_CVS 1
>
> /* define if you have pango_fc_font_map_add_decoder_find_func */
> #define HAVE_PANGO_FC_FONT_MAP_ADD_DECODER_FIND_FUNC 1
>
> in your config.h?
I am having trouble with this.
./configure seems to ignore about config.h:
$ ls -l config.h
-rw-r--r-- 1 erik erik 2435 Jun 27 20:11 config.h
$
That file is from lily 2.3.5.
also, 'make clean' does not remove config.h. I have now removed it manually.
In any case: In config.hh, those #defines are done correctly (both defined as
1), still I get the same errors as Pedro got first:
/home/erik/lily/lilypond/ly/init.ly:32:1: error: GUILE signaled an error for
the expression beginning here:
#
(if (pair? toplevel-scores)
no code for module (gnome gtk)
/home/erik/lily/lilypond/ly/init.ly:32:5: error: syntax error, unexpected '(',
expecting '=':
#(if
(pair? toplevel-scores)
I have to go to sleep now.. but any ideas are appreciated!
Erik
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
new markup remark.
I wouldn't mind of demanding that users write
\line
explicitly inside \column to go to horizontal mode again, ie.
\markup { \column { a b \bold { c d } e f }
=>
\markup { \column { a b \bold c \bold d e f } }
I think this is more consistent. Of course, \markup should implicitly
enclose its argument in \line.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: FYI: encoding issues
Hi, On Sun, 28 Nov 2004, Han-Wen Nienhuys wrote: > [EMAIL PROTECTED] writes: > > If not, what is the motivation for continuing to invest time into both > > TeX and PostScript backends? > > Practically: TeX has more formatting capabilities. Personally, I want > to minimize the amount of time I sink into TeX, but Werner thinks it > is a valuable feature, and he has been (hopefully: will be) willing to > keep that back-end up to date. Not to forget that at the moment, lily4jedit depends on DVI files and their embedded point-and-click information... Ciao, Dscho ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond 2.5: isinf macro/function/template
On Sunday 28 November 2004 16:25, Christian Hitz wrote: > I got lilypond 2.5.2 to compile by doing the following things: > > - set _GLIBCPP_USE_C99 before #include in the files that use > isinf/isnan > - replace each occurrence of isinf/isnan with std::isinf/std::isnan > > I don't know if this breaks compilation on linux. The first step is (at least on /this/ GNU/Linux) already done, so the templated versions of the C99 functions do exist after including . Plus, gcc/g++ on GNU/Linux readily (too readily?!) puts this stuff in the "std::" namespace plus exports it to the global namespace (as shown in my C++ example code; maybe one would have to use a commandline option to force some specific behaviour). So, I don't think your approach would (in the short run) break anything for Linux. However, at least the _GLIBCPP_USE_C99 macro setting should be dealt with by the auto-configure setup and be put into some central configuration. At least, there seems to be some light at the end of the tunnel. :-) Andreas ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markups: s/<>/{}/
[EMAIL PROTECTED] writes: > Ok, I think I got it. This is not very straightforward. > no, that's why we need a guru like you to do it :-) > > > make web runs OK, except in input/regression where it fails on > ancient-fonts.ly -- I guess this is not related. ancient-font also fails over here. Please commit. > oh, maybe I should add a note in NEWS.texi, as this is a syntax > change. Yes please, and the doco in Documentation/user/* where necessary. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: markups: s/<>/{}/
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>> There is one thing I have not done yet: adding a rule in convert-ly.
>
> I'm not sure that it will be feasible to add convert-ly rules, since
> you have to deal with correctly nesting { }
I've added a rule that should catch some basic cases.
> I'm not sure if it's feasible, but one thing that I did have in mind
> is to convert
>
> { c b \bold { d e } f g }
>
> to
>
> { c b \bold d \bold e f g }
>
> ie. flattening a (markup_head_1_list + markup_list) that is inside a
> markup_list. I think that you will need some more rules, but can you
> try if you can make it work? Then, we won't have to introduce
> additional artificial line-markup commands.
Ok, I think I got it. This is not very straightforward.
348 full_markup: MARKUP_IDENTIFIER
349 @21: /* vide */
350 full_markup: MARKUP @21 markup_top
351 markup_top: markup_composed_list
352 | markup_head_1_list simple_markup
353 | simple_markup
354 | markup_braced_list
355 markup_composed_list: markup_head_1_list markup_braced_list
356 markup_braced_list: '{' markup_braced_list_body '}'
357 markup_braced_list_body: /* vide */
358| markup_braced_list_body markup
359| markup_braced_list_body markup_composed_list
360 markup_head_1_item: MARKUP_HEAD_MARKUP0
361 | MARKUP_HEAD_SCM0_MARKUP1 embedded_scm
362 | MARKUP_HEAD_SCM0_SCM1_MARKUP2 embedded_scm
embedded_scm
363 markup_head_1_list: markup_head_1_item
364 | markup_head_1_list markup_head_1_item
365 simple_markup: STRING
366 | MARKUP_IDENTIFIER
367 | STRING_IDENTIFIER
368 @22: /* vide */
369 simple_markup: SCORE @22 '{' score_body '}'
370 | MARKUP_HEAD_SCM0 embedded_scm
371 | MARKUP_HEAD_SCM0_SCM1_SCM2 embedded_scm embedded_scm
embedded_scm
372 | MARKUP_HEAD_SCM0_SCM1 embedded_scm embedded_scm
373 | MARKUP_HEAD_EMPTY
374 | MARKUP_HEAD_LIST0 markup_braced_list
375 | MARKUP_HEAD_MARKUP0_MARKUP1 markup markup
376 markup: markup_head_1_list simple_markup
377 | simple_markup
378 | markup_braced_list
make web runs OK, except in input/regression where it fails on
ancient-fonts.ly -- I guess this is not related.
Should I commit?
oh, maybe I should add a note in NEWS.texi, as this is a syntax
change.
nicolas
Index: Documentation/user/changing-defaults.itely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/changing-defaults.itely,v
retrieving revision 1.93
diff -u -r1.93 changing-defaults.itely
--- Documentation/user/changing-defaults.itely 26 Nov 2004 13:33:30 - 1.93
+++ Documentation/user/changing-defaults.itely 28 Nov 2004 17:02:10 -
@@ -1461,14 +1461,14 @@
In markup mode you can compose expressions, similar to mathematical
expressions, XML documents, and music expressions. The braces group
notes into horizontal lines. Other types of lists also exist: you can
-stack expressions grouped with @code{<} and @code{>} vertically with
+stack expressions grouped vertically with
the command @code{\column}. Similarly, @code{\center-align} aligns
texts by their center lines:
@lilypond[quote,verbatim,fragment,relative=1]
-c1^\markup { \column < a c > }
-c1^\markup { \center-align < a c > }
-c1^\markup { \line < a b c > }
+c1^\markup { \column { a c } }
+c1^\markup { \center-align { a c } }
+c1^\markup { \line { a b c } }
@end lilypond
Index: Documentation/user/music-glossary.tely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/music-glossary.tely,v
retrieving revision 1.93
diff -u -r1.93 music-glossary.tely
--- Documentation/user/music-glossary.tely 13 Nov 2004 20:46:35 - 1.93
+++ Documentation/user/music-glossary.tely 28 Nov 2004 17:02:11 -
@@ -1145,7 +1145,7 @@
d1 |
g,4^\segno a b c |
b a g2_\markup{
-\line < "d.s. " \tiny \raise #1 \musicglyph #"scripts-segno" > }
+\line { "d.s. " \tiny \raise #1 \musicglyph #"scripts-segno" } }
\bar "|."
}
@end lilypond
Index: Documentation/user/notation.itely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/notation.itely,v
retrieving revision 1.157
diff -u -r1.157 notation.itely
--- Documentation/user/notation.itely 23 Nov 2004 00:16:16 - 1.157
+++ Documentation/user/notation.itely 28 Nov 2004 17:02:14 -
@@ -5153,8 +5153,8 @@
@lilypond[quote,fragment,verbatim,raggedright]
\set Staff.instrument = \markup {
- \column < "Clarinetti"
-{ "in B" \smaller \flat } > }
+ \column { "Clarinetti"
+{ "in B" \smaller \flat } } }
c''1
@end lilypond
@@ -5922,24 +
Re: FYI: encoding issues
> > IMHO it should be included too. We have plenty of space available... > > Hmmm. We should expand the size of a single brace subfont, > otherwise, we need too many feta-braces-[a-z]-[0-9]*.mf files. Well, it has to look fine :-) > Hmm. I tried to google for sfnt, but without avail. Is SFNT just a > "container" format, like XML or RIFF ? Here is the description of the SFNT format: http://www.microsoft.com/typography/otspec/otff.htm Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: encoding issues
[EMAIL PROTECTED] writes: > > Some minor clarifications and additions. > > > - dynamics, numbers, modern notes, ancient notes should be merged > > into an OpenType font. > > > > [What about the brace font?] > > IMHO it should be included too. We have plenty of space available... Hmmm. We should expand the size of a single brace subfont, otherwise, we need too many feta-braces-[a-z]-[0-9]*.mf files. > >- Printing PS is done by embedding a CFF font. > > (CFF is a wrapper format for OpenType). > > It's rather the other way round. The SFNT format used for both > TrueType and OpenType fonts can also represent CFF fonts (such fonts > have the extension .otf); they simply contain a table called `CFF ' > which is the complete CFF font. For creating a PS document, just > extract the contents of the `CFF ' table and paste it into the output > file (with some syntactic sugar to make it a valid PS resource). Hmm. I tried to google for sfnt, but without avail. Is SFNT just a "container" format, like XML or RIFF ? > > - Input to Pango is a list of glyphs. > > Input to Pango is a Unicode encoded string of *input characters*. As > silly as it may sound, we have to convert the internally stored list > of glyph names back to input characters for that process. Yes. Urgh. > >- can we create spacing tables within an OT font? > > Not yet. I'll send a request to George. BTW, I suggest to create a Cool. > simple ASCII table for the spacing data, compress it with zlib, and > store that data in the `lily' table. Hmmm. We'd have to link zlib, and parse the data. I guess it would be easier to generate the table as binary directly, and unpack (without error checking). -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: brace mismatch in init.ly
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: >> >> Ah.. I didn't think this was allowed (or at least not recommended). Using >> \include at anything else than top level is a kind of substitute for macros, >> and macros is something we don't want.. > > I guess that creating macros with \include is sufficiently painful to > deter people from actually doing it. It seems that I like pain then :-) ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: brace mismatch in init.ly
[EMAIL PROTECTED] writes: > > Ah.. I didn't think this was allowed (or at least not recommended). Using > \include at anything else than top level is a kind of substitute for macros, > and macros is something we don't want.. I guess that creating macros with \include is sufficiently painful to deter people from actually doing it. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
request for command similar to \fatText
[EMAIL PROTECTED] writes: > > Consider the following situation: > > Allegro molto >staff 1 |... | . | > >staff 2 |... > > It happens quite often that text strings like `Allegro molto' stick > out to the right. Can you provide a command similar to \fatText, say, > \textNoBreak, which inhibits a line break for all bars which are under > the text string? I have added an allow-outside-line property for PaperColumn (and NonMusicalPaperColumn), which will allow the situation described above, and defaults to a spacing where "Allegro molto" is inside the line. Hopefully, the spacing constraints will cause line breaks to be chosen far from such texts. If this doesn't happen, can you send an example where it fails (that example does not have to super-small) -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: FYI: encoding issues
[EMAIL PROTECTED] writes: > [...] > > * good support for non-western lyrics, > > > > * usable PostScript output > > > > * better support for TeX's text formatting features. > > > > * A cleaner system for reading and processing fonts. > > Please don't answer the following questions if you feel they're > inappropriate. I'm just being curious... > > Since a few months ago, I was under the impression that the Lilypond TeX > backend would be gradually moved to maintenance mode, in favor of the > PostScript backend. Is that correct? Yup. > If not, what is the motivation for continuing to invest time into both > TeX and PostScript backends? Practically: TeX has more formatting capabilities. Personally, I want to minimize the amount of time I sink into TeX, but Werner thinks it is a valuable feature, and he has been (hopefully: will be) willing to keep that back-end up to date. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: FYI: encoding issues
Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: [...] > As you might know, the support for languages that use non-ASCII glyphs > (both european characters with accents and non-european characters) is > flaky: choices for glyphs are dependent on the -rather limited- TeX EC > font of the. The problem of font encoding also bites us in the GNOME > backend, which some trickery to make Pango display the glyphs on the > GNOME canvas. [...] > Werner Lemberg and I have determined a course of action for LilyPond font handling. [...] > * good support for non-western lyrics, > > * usable PostScript output > > * better support for TeX's text formatting features. > > * A cleaner system for reading and processing fonts. Please don't answer the following questions if you feel they're inappropriate. I'm just being curious... Since a few months ago, I was under the impression that the Lilypond TeX backend would be gradually moved to maintenance mode, in favor of the PostScript backend. Is that correct? If not, what is the motivation for continuing to invest time into both TeX and PostScript backends? Thanks for your great work on Lilypond! Mark mutopia contributor ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: question about a <> mark similar to a c-> notation...
[EMAIL PROTECTED] writes: > Okay, i hope the second attempt includes your suggestions... Better, but the anti-blobbing at the junction is still not perfect. The outside outline should be a straight line ; check what happens with > if you change its value for diminish to 1.0 -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
LilyPond 2.5: isinf macro/function/template
Hello list, I have tried to analyze the "isinf issue", resulting from my "#include cleanup" patch for LilyPond 2.5, and want to submit the following results, created with gcc/g++/libc/libstdc++ 3.3.4 on SuSE Linux 9.2. If you look at the LilyPond C++ sources you find that the issue with "isinf" seems to have been addressed before. Module looks for a /macro/ "isinf" and if such a thing does not exist /and/ if the initial configuration finds no "isinf" function in the system libraries (!HAVE_ISINF), a local version of "int isinf(double)" is defined. (I have no idea whether this situation ever arises.) Module explicitly has a "MacOS fix" (with an additional "FIXME"), because "source-file.hh" somehow pulls in , thus overriding any "isinf" macro definition. Of course, after my change in (s/// et al.), this "fix" does no longer work. The attached archive contains two source files in C and C++ calling "isinf" in various incantations. The C version uses as the interface and in one situation I can bring gcc to at least issue a warning regarding an "implicit declaration of function isinf" after the line "#undef isinf". The C++ version uses as the interface and calls "isinf" (before and after "#undef isinf"), "::isinf", and "std::isinf" without complaint. So, on this GNU/Linux system, there is no real problem with "isinf", either as a macro, a function, or a template. According to "man isinf" on my configuration, "isinf/isnan/finite" are functions (sic!) "conforming to BSD 4.3". It further states that "C99 provides additional macros (!), such as the type-independent fpclassify(), isinf(), and isnan()" (and with option "--std=c99" plus "#undef isinf" in the code, gcc 3.3.4 issues the above-mentioned warning). IIRC, MacOS X is based upon "BSD", so it is unclear to me, how this "BSD-conforming" function/macro should be unavailable for use in C++ programs. My best guess is that BSD /only/ has the "isinf" /macro/ in and no underlying "isinf" system /function/ reachable through a different interface (like said /template function/ in on Linux) /and/ "#undef"ines exactly this macro. Hopefully, some member with MacOS eXperience can find a compliant solution to the problem. Take care -- Andreas Scherer Saarstraße 76, 52062 Aachen, Germany http://people.freenet.net/andreas.scherer isinf.tar.gz Description: application/tgz ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Chordname printing looks strange in 2.2.5
[EMAIL PROTECTED] writes: > Hi, > > As a maintainer of the Mutopia site I volunteered to convert old lilypond > files to later versions (currently I am converting to version 2.2.5 on > cygwin). Lately I ran into aproblem that you can perhaps help me with. > Mutopia's TownerDB's 'Trust and Obey' contains chordnames as well as notes. > The chordname C7 is shown as C 7 (so with a lot of whitespace between the C > and the 7). Is this a bug or is this a parameter to be set somewhere. If you > need a png file with the result I can send you one privately, it's a bit big > to attach it to this request. > > Help is greatly appreciated. Remove the setting for word-space. -- Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: question about a <> mark similar to a c-> notation...
Okay, i hope the second attempt includes your suggestions... On Sun, 28 Nov 2004 00:07:28 +0100, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] writes: > If I understand you correctly, you want to add a new articulation script > (rather than patching the code for dynamic marks). That's quite easy, if > you are a little bit familiar with metafont. For that purpose, you > should > > * add the articulation sign to the feta font; see file > mf/feta-schrift.mf; > I guess the direction (up/down) does not matter for espressivo marks, > hence a single character "espressivo" should suffice; you may want to > have a look at the sforzatoaccent as an example of a similar character > that is already in the font; > > * tell lily about your articulation sign by adding it to the file > scm/script.scm (twice the same character "espressivo" for both > directions, up and down); > > * add a handy shortcut to the file ly/script-init.ly > > * for testing, add it to input/test/script-chart.ly > > * for documentation, add it to the Articulations section (currently > section 5.7.8) of the user manual; see > Documentation/user/notation.itely. > > And, whenever changing feta-schrift, don't forget to clean the font such > that all font files will be rebuilt; otherwise, you will not see any > change, or the font will be messed up (as inserting a new character > changes the numbers in the font tables). > Okay, following the above i would like to propose a first attempt of a patch. Feel free to rant about my mistakes, but please be reminded that i am just a pianist trying his best. Don't shoot! Hi, some comments regarding the glyph: * the bbox is too small horizontally (try viewing out/feta20.dvi) * narrowing of the lines near the junction point is ok in principle, but I think the lines should be thinner still (the junction has more weight than the rest of the glyph) * The glyph is quicker drawn by doing only upper right half, then doing addto currentpicture also currentpicture (yscaled -1); addto currentpicture also currentpicture (xscaled -1); If you take these comments into account, I'll gladly merge a new version of your patch. -- http://www.arnowaschk.de lily-041126.patch Description: Binary data ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FYI: encoding issues
Some minor clarifications and additions. > - dynamics, numbers, modern notes, ancient notes should be merged > into an OpenType font. > > [What about the brace font?] IMHO it should be included too. We have plenty of space available... > - font parameters (staff-space, line thickness, stem attachment > points) are stored in the OT font, since OT fonts support > arbitrary tables. Such a table could be called `lily'. >- Printing PS is done by embedding a CFF font. > (CFF is a wrapper format for OpenType). It's rather the other way round. The SFNT format used for both TrueType and OpenType fonts can also represent CFF fonts (such fonts have the extension .otf); they simply contain a table called `CFF ' which is the complete CFF font. For creating a PS document, just extract the contents of the `CFF ' table and paste it into the output file (with some syntactic sugar to make it a valid PS resource). > - Input to Pango is a list of glyphs. Input to Pango is a Unicode encoded string of *input characters*. As silly as it may sound, we have to convert the internally stored list of glyph names back to input characters for that process. >- can we write CFF? Yes, in the `Generate Fonts' menu it is called `Open Type (CFF)'. >- can we create spacing tables within an OT font? Not yet. I'll send a request to George. BTW, I suggest to create a simple ASCII table for the spacing data, compress it with zlib, and store that data in the `lily' table. > * Pango: does Pango work correctly with the PUA map in an OT font? > Can we have glyph-list + (X,Y) output (so: can we use Pango without > linking X11 in?) Please ask Owen. > * Does pango + freetype work ok on cygwin? FreeType does, since it has no other dependencies (well, it depends on zlib, but only if you activate the decompression option). Werner ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel
