On Tue, Aug 18, 2009 at 01:04:13PM +0200, John Mandereau wrote:
Le lundi 17 août 2009 à 21:31 -0700, Graham Percival a écrit :
1. I have jpg files in Documentation/pictures/out-www/, but they
don't get copied to out-www/offline-root/Documentation/pictures/.
All the pngs are copied, though.
2009/8/24 Patrick McCarty pnor...@gmail.com:
BTW, if anyone can find a better set of options for convert, please
let me know. imagemagick has major problems with SVG-PNG conversion,
which is why I added all of these other flags.
I haven't followed this discussion so I apologize if my comment
Carl Sorensen wrote Monday, August 24, 2009 1:25 AM
From: Trevor Daniels [t.dani...@treda.co.uk]
Not sure these rebases are necessary if
you are going to use cherrypick rather
than merge.
Yes, your method works OK.
I use the rebase to get all of my work into
a single commit, instead of
Basically, I agree, but the case of SVG is quite problematic since it
relies on external fonts at certain locations. In particular,
`annotated-demo.svg'
We don't use annotated-demo.svg.
Well, but due to the generic SVG-PNG rule in GNUmakefile it is
converted anyway, and this conversion
Hmm. I currently can't imagine a situation where a value 0 is
needed, so I vote to remove the setting of #'outside-staff-priority
for MultiMeasureRestText -- however, I'm not sure whether this has any
influence to issue #495 (this looks rather unrelated to
#'outside-staff-priority to me)
This patch adds scripts.lvide and scripts.rvide glyphs to the parmesan font:
http://codereview.appspot.com/110073
An example is attached.
Okay to apply?
Cheers,
Reinhold
--
--
Reinhold Kainhofer, reinh...@kainhofer.com,
This effect seems to be a consequence of ragged-right = ##f together
with a second bar containing a single note (or space). When the
second bar is stretched to fill the line the note gets displaced
almost to the centre of the bar. This simpler example shows the
same effect:
\paper {
Additionally, it seems that some `convert' versions are buggy.
Look, for example, at the attached image, created with version
6.4.3. For testing, I've manually issued the current Makefile rule
convert -depth 8 \
-alpha Off \
-background white \
-layers
This patch adds scripts.lvide and scripts.rvide glyphs to the
parmesan font:
http://codereview.appspot.com/110073
An example is attached.
Okay to apply?
I've never seen these symbols, and I've seen a lot of scores...
What's your source?
Werner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A while ago we had that discussion about a user wanting two vertical lines on
each side of the breve instead of one. I have now prepared a patch for our
font, which adds such a noteheads.sM1double glyph:
http://codereview.appspot.com/109075
This
Werner LEMBERG wrote Monday, August 24, 2009 3:08 PM
This effect seems to be a consequence of ragged-right = ##f
together
with a second bar containing a single note (or space). When the
second bar is stretched to fill the line the note gets displaced
almost to the centre of the bar. This
On Mon, Aug 24, 2009, Reinhold Kainhofer reinh...@kainhofer.com said:
Regarding the single- vs. double-line breve: I have not yet found a reference
to the single-line breve. Only the double-lined breve can be found
practically
everywhere:
http://de.wikipedia.org/wiki/Brevis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 24. August 2009 21:25:10 schrieb dem...@suffolk.lib.ny.us:
On Mon, Aug 24, 2009, Reinhold Kainhofer reinh...@kainhofer.com said:
Regarding the single- vs. double-line breve: I have not yet found a
reference to the single-line breve.
Am Montag, 24. August 2009 20:23:01 schrieb Reinhold Kainhofer:
A while ago we had that discussion about a user wanting two vertical lines
on each side of the breve instead of one. I have now prepared a patch for
our font, which adds such a noteheads.sM1double glyph:
On Mon, Aug 24, 2009 at 7:12 AM, Werner LEMBERGw...@gnu.org wrote:
Additionally, it seems that some `convert' versions are buggy.
Look, for example, at the attached image, created with version
6.4.3. For testing, I've manually issued the current Makefile rule
convert -depth 8 \
On Sun, Aug 23, 2009 at 9:08 AM, Werner LEMBERGw...@gnu.org wrote:
It seems that (a) either `convert' or the file has some problems
(but inkscape loads it without problems) and (b) that it has been
forgotten to add a PNG version of this file.
As for (b), I wanted to add png versions:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Montag, 24. August 2009 21:25:10 schrieb dem...@suffolk.lib.ny.us:
On Mon, Aug 24, 2009, Reinhold Kainhofer reinh...@kainhofer.com said:
Regarding the single- vs. double-line breve: I have not yet found a
reference to the single-line breve.
From: Patrick McCarty pnor...@gmail.com
Subject: Re: [git 17e68b85] make error in documentation
Date: Mon, 24 Aug 2009 13:02:11 -0700
On Mon, Aug 24, 2009 at 7:12 AM, Werner LEMBERGw...@gnu.org wrote:
Additionally, it seems that some `convert' versions are buggy.
Look, for example, at the
A while ago we had that discussion about a user wanting two vertical
lines on each side of the breve instead of one. I have now prepared
a patch for our font, which adds such a noteheads.sM1double glyph:
http://codereview.appspot.com/109075
This patch also defines a notehead style
I would argue against introducing this complication. Positioning
spacer rests differently to notes of the same duration does not seem
a good idea.
Well, my example shows that it actually uses a *different* position
compared to the full rest -- if we follow your suggestion, this is a
real bug
Reinhold Kainhofer wrote:
A while ago we had that discussion about a user wanting two vertical lines on
each side of the breve instead of one. I have now prepared a patch for our
font, which adds such a noteheads.sM1double glyph:
Woah, great! Praise you! :-)
Regarding the single- vs.
On Sat, 2009-08-22 at 07:22 +0200, Werner LEMBERG wrote:
[git dd442f49]
This simple input
\relative {
\repeat unfold 31 { c'1 r r r r r r r }
}
makes the vertical layout overflow instead of properly filling two
pages. If you slightly increase the repeat factor, the lowest
On Mon, 2009-08-17 at 14:44 +0200, Michael Käppler wrote:
There's no top-level paper block, so default-paper will only contain
what's stored in paper-defaults-init.ly.
The ps output engine in framework-ps.scm:92, however, looks for a
global line-width. Currently, this line-width is just the
On Mon, Aug 24, 2009 at 10:52:20PM +0200, Werner LEMBERG wrote:
After all, it is very easy to place the markup where you want it by
simply using two spacer notes:
foo = {
s1
\time 7/8 s8^foobar s8*6
\time 10/8
}
OK, I haven't thought of that solution, thanks. This should
Am Montag, 24. August 2009 20:23:01 schrieb Reinhold Kainhofer:
Oh, I also wanted to attach a sample including this breve style, but
forgot.
It's attached now.
The semibreve and minim note heads for the neomensural seem too small,
compared to the breve and long. Were they reduced, or does
I'm getting build errors in freetype.
pipe /home/lilypond/gub/target/tools/root/usr/bin/freetype-config
--cflags
pipe /home/lilypond/gub/target/tools/root/usr/bin/freetype-config
--libs
Running read_pipe
('cd /home/lilypond/gub/downloads/lilypond/git git show
On Mon, Aug 24, 2009 at 01:07:51PM -0700, Patrick McCarty wrote:
On Sun, Aug 23, 2009 at 9:08 AM, Werner LEMBERGw...@gnu.org wrote:
Can (b) be fixed at all? This is, does the SVG format support glyph
access by name? Sinve SVG fonts themselves have glyph names I suspect
it can be fixed...
It seems there has been a change in the splitting of manuals on
kainhofer. They no longer split at numbered sections but only at
the second level. So the whole of Pitches, for example, comes as a
single html page. Is this deliberate or an error?
Trevor
On Mon, Aug 24, 2009 at 11:47:13PM +0100, Trevor Daniels wrote:
It seems there has been a change in the splitting of manuals on
kainhofer. They no longer split at numbered sections but only at the
second level. So the whole of Pitches, for example, comes as a single
html page. Is this
Werner LEMBERG wrote Monday, August 24, 2009 9:52 PM
I would argue against introducing this complication. Positioning
spacer rests differently to notes of the same duration does not
seem
a good idea.
Well, my example shows that it actually uses a *different*
position
compared to the
After all, it is very easy to place the markup where you want it by
simply using two spacer notes:
foo = {
s1
\time 7/8 s8^foobar s8*6
\time 10/8
}
OK, I haven't thought of that solution, thanks. This should perhaps
be added to the documentation.
I think you mean added
Both the note and the spacer in the second bar are positioned in
roughly the centre of the bar, although interestingly not quite in
identical positions. I don't know why they differ slightly, but you
see my point.
Here's another example -- it's yours slightly extended -- which
probably sheds
32 matches
Mail list logo
