>> I'll add a bug tracker item which suggests to split the Metafont
>> output into even smaller units, say, 16 glyphs per subfont, to
>> circumvent the problem.
>
> This is red herring. The metrics for feta are computed by parsing the
> metafont .log file. The .TFM files are unused, because of
Hi all,
Long ago I noticed that the text in our PDF manuals is fully black,
which results in rough-looking text when printed:
http://lists.gnu.org/archive/html/lilypond-devel/2008-10/msg00059.html
Attached is a patch which corrects this, and the printed output is
noticeably improved. (The on-scre
On 8/12/09 12:31 PM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>> Even better would be to define a function:
>> def command_replace(old_command, new_command, str)
>> that could then be used in a convert-ly rule
>> str = command_replace ("pad-markup", "pad-around", str)
>>
>> so that in the
On Wed, Aug 12, 2009 at 06:06:01PM -0600, Carl Sorensen wrote:
>
> On 8/12/09 5:54 PM, "Graham Percival" wrote:
>
> >convert-ly --from "2.13.3" ...
> > (where 2.13.3 is the previous downloadable version)
> >
> > to the above commands?
>
> That's what the "-f current-devel-release" part of
On 8/12/09 5:54 PM, "Graham Percival" wrote:
> On Wed, Aug 12, 2009 at 05:43:39PM -0600, Carl Sorensen wrote:
>>
>> Also, we need to recognize that the first commit after running convert-ly on
>> the docs and the snippets will result in changes to every version statement.
>
> Yes. Now, we c
On Wed, Aug 12, 2009 at 05:43:39PM -0600, Carl Sorensen wrote:
>
> Also, we need to recognize that the first commit after running convert-ly on
> the docs and the snippets will result in changes to every version statement.
Yes. Now, we could just *hope* that there's only one convert-ly
update fo
On Thu, Aug 13, 2009 at 01:31:57AM +0200, Jan Nieuwenhuizen wrote:
> Op woensdag 12-08-2009 om 15:39 uur [tijdzone -0700], schreef Graham
> Percival:
>
> > but did you check with John about this integration? He was
> > working on the Documentation build system, so this might have
> > duplicated s
On 8/12/09 4:26 PM, "Graham Percival" wrote:
> On Wed, Aug 12, 2009 at 11:31:48AM -0600, Carl Sorensen wrote:
>>
>> Does it cause problems to edit the snippet and move it to
>> Documentation/snippets/new?
>
> Yes, in that it forces somebody to look at it manually, when no
> manual attention
Op donderdag 13-08-2009 om 01:31 uur [tijdzone +0200], schreef Jan
Nieuwenhuizen:
> Anyway, I converted the original essay to texinfo, it's in
Oh, in web-gop I added a crude html-to-texi.py script that
did most of the work. This could be handy for translations/
translators.
Jan.
--
Jan Nieuwe
Op woensdag 12-08-2009 om 15:39 uur [tijdzone -0700], schreef Graham
Percival:
> Jan, I'm glad that you're very enthusiastic about the new website,
That's a nice way of putting it... I do like the new web site,
but I'd feel bad if what we now have goes life, so I put in
some effort to help this
This file was used for generating the long bibliography...
eventually this will be integrated directly into the texinfo
essay, but for now, could we just rename the file instead of
deleting it? That will remind us that we still need to add it to
the essay.
Cheers,
- Graham
_
Jan, I'm glad that you're very enthusiastic about the new website,
but did you check with John about this integration? He was
working on the Documentation build system, so this might have
duplicated some of his efforts.
Also, we'll need a @rgeneral macro sooner or later... preferably
sooner, sinc
On Wed, Aug 12, 2009 at 11:31:48AM -0600, Carl Sorensen wrote:
>
> Does it cause problems to edit the snippet and move it to
> Documentation/snippets/new?
Yes, in that it forces somebody to look at it manually, when no
manual attention is needed.
> I think it would be best to have one procedure
On Wed, Aug 12, 2009 at 09:36:57AM -0700, Mark Polesky wrote:
> Carl Sorensen wrote:
>
> > > When doing a convert-ly rule, do I update snippets/regression tests?
> >
> > The correct question is: When changing syntax, what do I do besides writing
> > a convert-ly rule?
>
> Okay, that covers the
On Wed, Aug 12, 2009 at 08:51:42PM +0100, Trevor Daniels wrote:
>
> Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM
>
>> And if we're ever going to move it to a postfix operator (which is one
>> of
>> the goals of the GLISS project), now is the time, before we get a
>> strong
>> codebase
Carl Sorensen wrote Wednesday, August 12, 2009 7:32 PM
And if we're ever going to move it to a postfix operator (which is
one of
the goals of the GLISS project), now is the time, before we get a
strong
codebase of music function applications.
I'm beginning to wonder whether this is a
desira
Neil Puttock wrote:
> LSR turns backslashes in titles into hyphens; perhaps it would be
> better if it silently ignored them (which would simplify the migration
> of new snippets to LSR when there's a version bump).
Yes, that would be better in my opinion.
Is that something that Seba would have t
2009/8/12 Carl Sorensen :
> Does it cause problems to edit the snippet and move it to
> Documentation/snippets/new?
Not really, but it's redundant. This is precisely why makelsr.py
performs a convert-ly run on all the LSR snippets.
Regards,
Neil
___
2009/8/12 Carl Sorensen :
> Not as long as you changed every occurrence in the docs and did a git-rename
> to the snippet.
You'd also need to rename the texidoc translations and remove the
`docs' tag from LSR (otherwise we'd end up with two almost identical
snippets in the docs).
LSR turns backs
On 8/12/09 9:24 AM, "Trevor Daniels" wrote:
>
>
> Carl Sorensen Friday, August 07, 2009 2:49 PM
>>
>> The generic approach has now been pushed to git
>>
>> 247f0b6d46fd8f3253a99f95a70ce14345daa5f9
>>
>> There's a generic styledNoteHeads music function that applies a
>> note style
>> to mu
Carl Sorensen wrote:
> Even better would be to define a function:
> def command_replace(old_command, new_command, str)
> that could then be used in a convert-ly rule
> str = command_replace ("pad-markup", "pad-around", str)
>
> so that in the future you'd never have to worry about dealing
> with wo
Carl Sorensen writes:
> On 8/12/09 11:15 AM, "Michael Käppler" wrote:
>
>> Sorry, that wasn't intended. It was late yesterday and I didn't
>> notice I pressed the wrong button... ;)
>
> Glad I'm not the only one who does this.
Uh oh. Did you manage to placate her again?
--
David Kastrup
_
On 8/12/09 11:15 AM, "Michael Käppler" wrote:
> Hi Carl,
>> Usually we like to keep responses to reviews on the -devel list, so I've
>> copied this there.
>>
> Sorry, that wasn't intended. It was late yesterday and I didn't notice I
> pressed the wrong button... ;)
Glad I'm not the only one
On 8/12/09 10:56 AM, "Mark Polesky" wrote:
> Also, the snippet filename is
> blanking-staff-lines-using-the--whiteout-command.ly
>
> Would anything break if I fix the double-hyphen?
> blanking-staff-lines-using-the-whiteout-command.ly
>
Not as long as you changed every occurrence in the doc
str.replace is probably preferred for this particular example. str.*
functions use less overhead. But really, at the level we're using it in
convert-ly, it doesn't matter.
But you should probably really use something like
str = re.sub (r'\b\\pad-markup\b', r'\\pad-around', str)
Note- I haven't
On 8/12/09 10:58 AM, "Neil Puttock" wrote:
> 2009/8/12 Carl Sorensen :
>
>> You copy the snippet from Documentation/snippets to
>> Documentation/snippets/new.
>
> Only if the syntax change can't be handled by convert-ly.
>
> Since the only change to
> `blanking-staff-lines-using-the--whiteo
On 8/12/09 10:36 AM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>
>>> When doing a convert-ly rule, do I update snippets/regression tests?
>>
>> The correct question is: When changing syntax, what do I do besides writing
>> a convert-ly rule?
>
> Okay, that covers the snippet, but what a
On Wed, Aug 12, 2009, Trevor Daniels said:
> function like all music functions is a prefix
> operator. Applied to a sequence of notes like
>
> \xNote { e f }
>
> it's fine, but
>
> c d\xNote e f
> < g \xNote c f >
Conventions aside (...like all music functions...), my preference would be
f
Hi Neil,
These are unsafe, since they return SCM_UNSPECIFIED instead of a Real
if the paper variables aren't defined; using robust_scm2double () here
will ensure a default is returned.
You can see the consequences of variable lookup failure by running
bookparts.ly
(http://git.savannah.gnu.org/g
Hi Carl,
Usually we like to keep responses to reviews on the -devel list, so I've
copied this there.
Sorry, that wasn't intended. It was late yesterday and I didn't notice I
pressed the wrong button... ;)
Oh -- I misunderstood the meaning of the FIXME.
I think I'd recommend changing the set
Neil Puttock wrote:
> > You copy the snippet from Documentation/snippets to
> > Documentation/snippets/new.
>
> Only if the syntax change can't be handled by convert-ly.
Okay, so I simply leave it alone? What about the regression test?
- Mark
_
2009/8/12 Carl Sorensen :
> You copy the snippet from Documentation/snippets to
> Documentation/snippets/new.
Only if the syntax change can't be handled by convert-ly.
Since the only change to
`blanking-staff-lines-using-the--whiteout-command.ly' is a simple
renaming, this represents an exceptio
Also, the snippet filename is
blanking-staff-lines-using-the--whiteout-command.ly
Would anything break if I fix the double-hyphen?
blanking-staff-lines-using-the-whiteout-command.ly
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.o
Carl Sorensen wrote:
> > When doing a convert-ly rule, do I update snippets/regression tests?
>
> The correct question is: When changing syntax, what do I do besides writing
> a convert-ly rule?
Okay, that covers the snippet, but what about the regression test?
Do I just update it manually? In
Which one of these is preferred?
str = str.replace ("pad-markup", "pad-around")
str = re.sub ('pad-markup', 'pad-around', str)
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Trevor Daniels wrote:
> Good to see you pushing again!
>
> But could you preface commits which affect
> only docs with "Docs: " please. It helps
> code developers with better things to do to
> skip uninteresting commits.
Sorry. I forgot. :(
- Mark
__
Carl Sorensen Friday, August 07, 2009 2:49 PM
The generic approach has now been pushed to git
247f0b6d46fd8f3253a99f95a70ce14345daa5f9
There's a generic styledNoteHeads music function that applies a
note style
to music whether or not it's in a chord construct.
Carl, I am part-way through
On Wed, 2009-08-12 at 09:14 -0400, Dan Eble wrote:
> On 12 Aug 2009, at 00:06, joenee...@gmail.com wrote:
>
> > In case there is rounding, it is better to check
> > if (abs (paper_width - line_width - left_margin - right_margin) >
> > 1e-6)
>
> Wouldn't it be a good idea to define a name for 1e
Han-Wen Nienhuys writes:
> On Mon, Aug 10, 2009 at 4:27 AM, Werner LEMBERG wrote:
>
>>> One has to keep in mind that Metafont does not permit more than 16
>>> different heights per font (something like that, I don't remember
>>> the exact details).
>>
>> Yes, this problem already bites us. I'll
On 12 Aug 2009, at 00:06, joenee...@gmail.com wrote:
In case there is rounding, it is better to check
if (abs (paper_width - line_width - left_margin - right_margin) >
1e-6)
Wouldn't it be a good idea to define a name for 1e-6?
--
Dan
___
lilypo
On Sun, Aug 9, 2009 at 9:44 PM, Patrick McCarty wrote:
> Are there any guidelines LilyPond adheres to for creating bounding
> boxes?
>
> For example, when I adjusted the bbox for the \eyeglasses markup
> command, I _underestimated_ the bbox. Should I have slightly
> _overestimated_ instead? Atta
On Mon, Aug 10, 2009 at 4:27 AM, Werner LEMBERG wrote:
>> One has to keep in mind that Metafont does not permit more than 16
>> different heights per font (something like that, I don't remember
>> the exact details).
>
> Yes, this problem already bites us. I'll add a bug tracker item which
> sugg
2009/8/12 Werner LEMBERG :
> As can be seen in the attached image, the text markup gets a higher
> `inside' priority than the fermata. I think this is wrong, since in
> most cases there is nothing between a rest and the fermata above it.
> BTW, this problem doesn't happen if you replace the rests
Hi Mark
Good to see you pushing again!
But could you preface commits which affect only docs with "Docs: "
please. It helps code developers with better things to do to skip
uninteresting commits.
Trevor
___
lilypond-devel mailing list
lilypond-d
2009/8/12 Johannes Schindelin :
>> Yep, verified. Many thanks once again! I think this can be very useful
>> for new contributors.
>
> I hope so.
>
> Maybe you tell me the most common operations, and I'll add the
> functionality?
Hmm, I'm probably not the right person to ask because I guess I'm n
> So, if I am understanding correctly, LilyPond currently uses the
> same dimensions for both the "metrics" box and the "bounding" box
> for each glyph. This is why the longa glyph, for example, is
> cropped in the EPS/PNG output. Is this true?
I think so. On the other hand, we need an exact bb
[git d4310174]
Consider this snippet:
\new Staff {
<< { s1^"Foobar"
s1 }
{ R1
R1^\fermataMarkup }
>>
}
As can be seen in the attached image, the text markup gets a higher
`inside' priority than the fermata. I think this is wrong, since in
most cases there i
>> However, there are still formatting problems, as given in the
>> example below. See attached image.
>
> Is your git up to date? With 38a4db2d15f4 (my last commit) and
> 16d16717f3 (current HEAD), I get the attached output.
Oops, my mistake! Sorry for the noise. Everything's fine now.
Thank
Hi,
On Wed, 12 Aug 2009, Maximilian Albert wrote:
> 2009/8/12 Johannes Schindelin :
>
> > Fixed and pushed.
>
> Yep, verified. Many thanks once again! I think this can be very useful
> for new contributors.
I hope so.
Maybe you tell me the most common operations, and I'll add the
functional
49 matches
Mail list logo
