Hi all,
In the essay, we'd like to use high-quality pdf images for the pdf
backend, and (relatively) low-quality pngs for info and html
backends.
According to the texinfo manual,
http://www.gnu.org/software/hello/manual/texinfo/Image-Syntax.html
the pdfTeX backend reads .png, .jpg, .jpeg, and .
> 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 sh
>> > 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 documentat
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 full
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 thi
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 01:07:51PM -0700, Patrick McCarty wrote:
> On Sun, Aug 23, 2009 at 9:08 AM, Werner LEMBERG 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...
>
> I
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
git.sv.gnu.org/lilypond.git/maste
> 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 do
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, than
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 jus
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 l
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. double
> 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 bu
> 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 '
From: Patrick McCarty
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 LEMBERG wrote:
>>
>>> Additionally, it seems that some `convert' versions are buggy.
>>> Look, for example, at the attached image, created
-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 said:
> > Regarding the single- vs. double-line breve: I have not yet found a
> > reference to the single-line breve. Only the double-line
On Sun, Aug 23, 2009 at 9:08 AM, Werner LEMBERG 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:
>> http:
On Mon, Aug 24, 2009 at 7:12 AM, Werner LEMBERG 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 \
>>
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:
> http://codereview
-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 said:
> > Regarding the single- vs. double-line breve: I have not yet found a
> > reference to the single-line breve. Only the double-line
On Mon, Aug 24, 2009, Reinhold Kainhofer 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
> http://en.wikipedia.org/wiki/D
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 si
-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
Thi
> 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
> 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 \
> -la
> 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
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, http://r
>> 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-priorit
>> 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 conver
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 h
2009/8/24 Patrick McCarty :
> 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 is not
rele
32 matches
Mail list logo
