On Nov 24, 2014, at 04:11 , Urs Liska wrote:
>
> I don't know how to properly review this, but I checked against a current
> score I'm working on, and I see it removes one of the most annoying issues I
> had so far.
I’m glad to hear that. I still need to check my own scores.
> When the partc
>> > >> With the latest release of the UFW fonts, they've dropped the
>> > >> Cyrillic glyphs due to poor quality. I see that both 2.18.x
>> > >> and 2.19.x still need ufw's ru fonts, and so lilypond fails to
>> > >> build in rawhide. Is there another font set, preferably one
>> > >> in Fedora al
Thanks, I'll post to both.
On Mon, Nov 24, 2014 at 9:33 AM, Federico Bruni wrote:
> I think that the best place is lilypond-devel.
> Werner may also help you
> Il 24/nov/2014 16:25 "Knute Snortum" ha scritto:
>
>> Try posting your question here:
>>
>> lilypond-u...@gnu.org
>>
>>
>> Knute Snortu
I think that the best place is lilypond-devel.
Werner may also help you
Il 24/nov/2014 16:25 "Knute Snortum" ha scritto:
> Try posting your question here:
>
> lilypond-u...@gnu.org
>
>
> Knute Snortum
> (via Gmail)
>
> On Mon, Nov 24, 2014 at 5:09 AM, Jon Ciesla wrote:
>
> > On Fri, Nov 14, 2014
Try posting your question here:
lilypond-u...@gnu.org
Knute Snortum
(via Gmail)
On Mon, Nov 24, 2014 at 5:09 AM, Jon Ciesla wrote:
> On Fri, Nov 14, 2014 at 6:55 AM, Jon Ciesla wrote:
>
> >
> >
> > On Mon, Nov 10, 2014 at 10:05 AM, Jon Ciesla
> wrote:
> >
> >> With the latest release of the
There seems to be a problem with the 'lilypond’ searchpaths for file arguments
given to it:
When trying to compile a local file named ‘makam.ly’, it reinterprets it as
being the one in the distribution [1]. The local file compiles if given another
name, and does not call the distribution one (o
On Fri, Nov 14, 2014 at 6:55 AM, Jon Ciesla wrote:
>
>
> On Mon, Nov 10, 2014 at 10:05 AM, Jon Ciesla wrote:
>
>> With the latest release of the UFW fonts, they've dropped the Cyrillic
>> glyphs due to poor quality. I see that both 2.18.x and 2.19.x still need
>> ufw's ru fonts, and so lilypond
Am 24.11.2014 10:40, schrieb David Kastrup:
David Kastrup writes:
Urs Liska writes:
With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)
I don't see this effect either with current master
commit 2f6c938f9897f6106e0673a6bf16d4e570395a3e
Author: Keith OHara
Date:
David Kastrup writes:
> Urs Liska writes:
>
>> With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)
>>
>> compiling
>>
>> \version "2.19.16"
>>
>> {
>> c'1
>> }
>>
>> results in the attached output. This is not related to the concrete
>> example but a general issue: The
I don't know how to properly review this, but I checked against a
current score I'm working on, and I see it removes one of the most
annoying issues I had so far.
Consider this snippet:
\version "2.19.16"
one = \relative c'' {
c2 c
\voiceOne
r8 c b a g f e d
c1
}
two = \relative c' {
Urs Liska writes:
> With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)
>
> compiling
>
> \version "2.19.16"
>
> {
> c'1
> }
>
> results in the attached output. This is not related to the concrete
> example but a general issue: The time signature is printed completely
>
With a build from current master (151120c3240601fd29bbb20a315decbde681fcdb)
compiling
\version "2.19.16"
{
c'1
}
results in the attached output. This is not related to the concrete
example but a general issue: The time signature is printed completely at
the left edge of the staff. I suspec
12 matches
Mail list logo
