Hi.
I wrote that was seemed LilyPond
could not find some bigcheese-fonts.
Processing with no "--format" option,
LilyPond cannot find bigcheese-fonts on my PC.
There was not any serious warning on installing
the latest CVS.
But with "--format=tex", this problem
does not h
The current midi2ly.py contains the follwing todo items which are of
interest to me:
1 test on weird and unquantised midi input (lily-devel) -- is there a
file or files that can be used?
2 do not ever quant skips -- don't understand what is meant
3 drop c++ midi2ly -- replace with Python co
[EMAIL PROTECTED] writes:
> by Pango. Even if they use TeX fonts, the information is based on
> the PS outlines. I fully support your idea to replace
> ec-fonts-mftraced with cmsuper or something similar, converted to
> OpenType so that the TFM files are no longer needed. Ideally
[EMAIL PROTECTED] writes:
>
> > * LilyPond needs to determine a font both in TeX and PS.
> > * LilyPond needs to load those metrics to get a rough estimate of
> > sizes.
>
> Why do you need a rough estimate of sizes for the TeX backend? I
> thought this is done by `-f texstr'.
Because -f texs
[EMAIL PROTECTED] writes:
>
> > > We need a new command to select the backend -- I propose
> > > \TeXformat and \PSformat so that the `-f ps' and `-f tex' switches
> > > become obsolete.
> >
> > And SVG/Gnome/whatever-we-come-up-with-next? I disagree with this
> > idea.
>
> See my other mail to
[EMAIL PROTECTED] writes:
> Hello,
>
> While trying to write a protocol for parsing portions of LilyPond text,
> typically for more interactive editing (a quick insert mode that
> really works), I encoutered few problems wrt input locations. For
> instance:
>
> [snip]
>
> I would like to (try to)
> Is this a new feature, or has the layout/location of the PostScript
> header path changed?
The search path has changed. The old path was
TEXPSHEADERS = .;$TEXMF/{dvips,pdftex,tex,fonts/type1}//
and it *did* have the complete $TEXMF/tex// in it.
> How do we get this to work with tetex-2.0 and
Hello,
While trying to write a protocol for parsing portions of LilyPond text,
typically for more interactive editing (a quick insert mode that
really works), I encoutered few problems wrt input locations. For
instance:
guile> (lyp:print-parse-tree (lyp:parse-line "c8.\\f d16 e8 f g2"))
[0-17
> > I believe that `-f tex' and `-f ps' are fundamentally different,
> > and that we shouldn't invest time to `unify' both interfaces.
>
> I disagree. We want both to look equal or as similar as possible.
> For example, we can have people develop a score using GNOME point
> and click, then print s
> > We need a new command to select the backend -- I propose
> > \TeXformat and \PSformat so that the `-f ps' and `-f tex' switches
> > become obsolete.
>
> And SVG/Gnome/whatever-we-come-up-with-next? I disagree with this
> idea.
See my other mail too. We must make a distinction between backe
> > > * How do we deal with kerning in Pango? AFAIK, Pango does not
> > > read AFM/TFM files, so how can it compute kernings?
> >
> > IIRC Owen has mentioned that he plans to support reading of AFM
> > files for Type 1 fonts to get kerning. Kerning from OpenType
> > should be supported alread
Jan Nieuwenhuizen writes:
> Hadden we niet al over gehad?
[sorry, please ignore]
--
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing
Han-Wen Nienhuys writes:
> * To provide backend routines for Pango_font::text_stencil, which is
> suitable for the SVG and GNOME backends.
>
> My current idea is to wrap PangoFontDescription as SCM and dump that
> into the backend. I hope for some input by Jan on this, since I
> guess th
Thomas Esser writes:
> The search path has changed. The old path was
> TEXPSHEADERS = .;$TEXMF/{dvips,pdftex,tex,fonts/type1}//
> and it *did* have the complete $TEXMF/tex// in it.
I see.
> If it is only used as a header file for dvips, just put it somewhere
> into $TEXMF/dvips. That works wit
Hi.
When I'm processing a .ly file,
LilyPond (latest cvs) prints this warning:
(...)
Preprocessing graphical objects...
Calculating line breaks...
[3][6][9][12][15][18][21][24][27][30][33][36][39][42][45][48][51][54][55]
Layout output to `score.ps'...
warning: cannot f
Graham Percival wrote:
In input/regression/:
volta-chord-names.ly
Not necessary; covered by volta-multi-staff.ly
Well, yes, but only for those of us who are very fluent on LilyPond.
Since it's a question that keeps popping up on the mailing list every
now and then, I don't think it hurts to inclu
Akira Kakuto writes:
>>
>> /home/janneke/cvs/savannah/lilypond/lilypond/share/lilypond/tex/source/out/music-drawing-routines.ps
>
> The directory is wrong.
So how come this works with 2.0? Btw, it is also in TEXMF/ps:
$ find ./share -follow -name music-drawing-routines.ps
./share/lilypond/
Thomas Esser writes:
> On Mon, Jan 03, 2005 at 11:37:22AM +0100, Jan Nieuwenhuizen wrote:
>> dvips: ! Couldn't find header file music-drawing-routines.ps
>
> dvips uses the 'PostScript header' path for it (TEXPSHEADERS variable,
> kpse_tex_ps_header_format from the "C" API of the kpathsea libr
Han-Wen Nienhuys writes:
>> We need a new command to select the backend -- I propose \TeXformat
>> and \PSformat so that the `-f ps' and `-f tex' switches become
>> obsolete.
>
> And SVG/Gnome/whatever-we-come-up-with-next? I disagree with this
> idea.
In fact, I would like to remove as much non-
19 matches
Mail list logo
