Re: [git 17e68b85] make error in documentation
>> It's better (see attached image) but not really good -- inkscape still >> produces better results. > > What was wrong with that image? Looks fine to me, and that's what > I see from my own conversion. Attached is the inkscape rendering. Note how the green and blue box are now synchronized correctly with the text. > *sigh* we've spent way too much effort on this. Why don't we go > back to the idea of just adding a png directly? The old web > branch did this, and it's not like we're going to change the png > often. Basically, I don't oppose, but getting correct SVG->PNG conversion is something which should be available in any case, not only for lilypond, but in general. Werner <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [git 17e68b85] make error in documentation
On Wed, Aug 26, 2009 at 02:25:45AM +0200, Werner LEMBERG wrote: > > > Werner, does the conversion from SVG->PNG work for you now? I'll add > > a configure rule soon if this does solve the problem. > > It's better (see attached image) but not really good -- inkscape still > produces better results. What was wrong with that image? Looks fine to me, and that's what I see from my own conversion. *sigh* we've spent way too much effort on this. Why don't we go back to the idea of just adding a png directly? The old web branch did this, and it's not like we're going to change the png often. For the translated versions, the translator can modify the svg and then generate a new png. We don't store the translated svg; we just keep the pngs for each language. John: is it *really* worth going to all this much effort just to avoid adding 6 images (per language) that are 16K each? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
user view of website+docs
How does this look? http://kainhofer.com/~lilypond/Documentation/general/Manuals.html http://kainhofer.com/~lilypond/Documentation/general/Learning.html The second-layer TOC is obviously a work in progress. Only Learning, Essay, and All have been done so far (and All is only half-done). If we like the look of this, doing the rest in the same style will be easy. I'm not certain if we want to include info in the list of doc formats. I can't imagine people wanting to download the info files (as opposed to having them installed along with a package or from compiling the source), but OTOH, there's no harm dumping the link there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [git 17e68b85] make error in documentation
> It's better (see attached image) but not really good BTW, I've tested with ImageMagick 6.5.5-2, with librsvg version 2.22.3. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [git 17e68b85] make error in documentation
> Werner, does the conversion from SVG->PNG work for you now? I'll add > a configure rule soon if this does solve the problem. It's better (see attached image) but not really good -- inkscape still produces better results. Werner <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Breve with double lines on each side
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 24. August 2009 22:49:36 schrieb Werner LEMBERG: > > One thing I notice is that the vertical lines are usually a bit > > larger than the notehead. This would also change the default breve > > glyph, so I haven't included that in the patch. What do you think > > about this issue? > > With `larger' you mean longer (in the vertical direction)? Yes, it seems to be 1/4 to 1/2 staff space longer on each side. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKlGrFTqjEwhXvPN0RAo4dAJ9NvgMLV71PDEx5SOHkEF4zGYNV3gCgvUgi v6R16jrFafIgtiRIHlCTcjw= =epLO -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] to let \epsfile always start the eps file at (0, 0) in the stencil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch lets an included EPS file always start at the origin of the stencil:
http://codereview.appspot.com/109079
Okay to apply?
The problem so far was that lilypond used the (scaled) exact coordinates of
the bounding box as the coordinates of the object in the stencil. Now, since
hardly any EPS will have its visual lower left corner at coordinates (0,0),
this will leave all EPS file displaced quite a lot. For example, The following
code includes the CC-licence EPS and our usual context-example.eps example:
\markup\concat{ ABC \rounded-box \epsfile #Y #3 #"cc-by.eps" DEF}
\markup\concat{ ABC \rounded-box \epsfile #Y #20 #"context-example.eps" DEF}
\markup\concat{ ABC \rounded-box \epsfile #X #20 #"context-example.eps" DEF}
\markup\concat{ ABC \rounded-box \epsfile #Y #3 #"cc-by.eps" DEF}
I would expect this to be ABC[Box with EPS]DEF in all cases, right?
The output (before the patch) can be seen at:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/eps-file.old.pdf
This is clearly not what one would expect.
The result with that patch is more what one would expect:
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/eps-file.new.pdf
The image in the documentation of \epsfile
(http://kainhofer.com/~lilypond/Documentation/notation/Graphic.html#Graphic)
will of course also look a bit different (the two eps files won't overlap any
more, which is also what I would expect, anyway):
http://www.fam.tuwien.ac.at/~reinhold/LilyPond/lily-6692447e.pdf
Okay to apply?
Cheers,
Reinhold
- --
- --
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
* Financial & Actuarial Math., Vienna Univ. of Technology, Austria
* http://www.fam.tuwien.ac.at/, DVR: 0005886
* LilyPond, Music typesetting, http://www.lilypond.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKlGkfTqjEwhXvPN0RAlItAJ9MeIZd1S9dn4h0C4r/byi3CfYLFgCZAUfa
KWA9z8jaF/OfFfYoLsUvv7k=
=AIbd
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Move ambitus print callback to scheme
Hi, I've just posted a revised patchset which deals with Han-Wen's comments. http://codereview.appspot.com/110047/show Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Another `make distclean' question
Hi, I posted this to -devel a few months, but I forgot about it: http://lists.gnu.org/archive/html/lilypond-devel/2009-01/msg00404.html Does this happen for anyone else? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [git 17e68b85] make error in documentation
On 2009-08-24, Graham Percival wrote: > 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 am willing to fix this file, but only if we are actually going to > > use it somewhere. As Graham noted earlier, we're not sure why this > > example was added to master. > > Screw it. I've deleted that file. Patrick: please change the > other svg files to not use text. Since this is happening on your > local system, feel free to use whatever font(s) you want. > > The bloody translation people can take care of the bloody > translated images if they bloody well want to. Although even > then, I think they should just bloody make a new image, with > modified text, converted to non-text, or whatever it is that > you're going to do to the svg images. Hmm. I think the problem might have been solved after Werner installed librsvg and recompiled imagemagick. imagemagick will use this library for the SVG output if found at compile time. Now that I found the discussion about translating the SVG annotations in the archives, it sounds like the translation team was enthusiastic about the idea, so I'm hesitant about converting the SVG text to paths now. Werner, does the conversion from SVG->PNG work for you now? I'll add a configure rule soon if this does solve the problem. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `+repage' option for convert?
On 2009-08-24, Maximilian Albert wrote: > 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 > relevant. But I remember seeing a dependency of Inkscape mentioned in > a different thread. Have you considered using it for SVG --> PNG > conversion? Perhaps it gives better results. Inkscape used to be required to compile the regression test "backend-svg.ly", but it's been commented out for years, and I don't really want to uncomment it anytime soon. It does give better results than imagemagick, but the inherent problem in this whole situation is that we are using SVG text instead of paths; I think that using the "rsvg" application from librsvg would be a better option at this point. I'll post about it in another thread. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make distclean' buglet
Hi guys, 2009/8/25 Graham Percival : > More to the point, they shouldn't be created at all -- shouldn't > they go in out/ ? Of course they should. I'll look at this and all other issues with the build system when I'm back in France this week-end. Greetings from Pisa, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make distclean' buglet
On Tue, Aug 25, 2009 at 08:58:36AM +0200, Werner LEMBERG wrote: > > The files > >Documentation/topdocs/AUTHORS.info >Documentation/topdocs/INSTALL.info >Documentation/topdocs/README.info >Documentation/topdocs/lilypond-changes.info > > aren't removed if you say `make distclean'. More to the point, they shouldn't be created at all -- shouldn't they go in out/ ? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: horizontal offset bug of skip markups
Werner LEMBERG wrote Tuesday, August 25, 2009 6:45 AM I think you mean "added to the snippets" (via LSR). No, I mean documentation, since the difference in behaviour between full rest skips and ordinary skips must be documented properly. I'll wait for the response to the bug report before doing anything with either documentation or snippets. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: horizontal offset bug of skip markups
Werner LEMBERG wrote Tuesday, August 25, 2009 6:52 AM 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 more light on the bug. It appears this was a regression introduced between 2.11.9 and 2.11.10. I've just posted a bug report. Thanks for uncovering this! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
`make distclean' buglet
The files Documentation/topdocs/AUTHORS.info Documentation/topdocs/INSTALL.info Documentation/topdocs/README.info Documentation/topdocs/lilypond-changes.info aren't removed if you say `make distclean'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
