SVG backend
From LilyPond Wiki
LilyPond's SVG output has been improved recently.
To take advantage of these improvements, download and install LilyPond 2.13.4 [1] (or a later version).
Run the following command to create SVG output, where myfile.ly is the name of your LY file.
lilypond -dbackend=svg myfile.ly
This page attempts to provide all details related to LilyPond's SVG backend, including a comprehensive list of bugfixes, bug reports, enhancement requests, etc.
Note: Please post bug reports here [2], or edit this wiki page.
Contents |
[edit] Software support
Note: If you do not have the Century Schoolbook fonts installed on your system, <text> elements might not render correctly; if you want correct rendering, install them. You can find these fonts in your LilyPond installation. Their names are:
- CenturySchL-Bold.otf
- CenturySchL-BoldItal.otf
- CenturySchL-Ital.otf
- CenturySchL-Roma.otf
Directions for installing the fonts:
- UNIX (MacOSX, GNU/Linux, etc.)
- Copy the Century Schoolbook fonts to ~/.fonts
- Run fc-cache -fv
- Windows
- Copy the Century Schoolbook fonts to C:\WINDOWS\Fonts
That's it!
| User agent or Editor | Status |
|---|---|
| Inkscape |
|
| Batik Squiggle |
|
| Firefox |
|
| Safari |
|
| Opera |
|
| Adobe SVG viewer |
|
| Google Chrome / Chromium |
|
[edit] Closed bugs
These are issues that have been resolved and are part of LilyPond.
- Grouping tags <g>...</g> are no longer used to move grobs and text to the correct position on the page. The transformations now apply to each element directly. This makes the SVG output easier to read, and it simplifies the task of "ungrouping" elements within Inkscape, should the user want to ungroup one or more individual items.
- All text elements a "west" value for the text-anchor attribute have been replaced with the correct value of "start".
- The style attribute has been replaced with the following attributes: font-family, font-weight, font-style, and font-variant. This corresponds to the SVG Tiny 1.2 recommendation.
- The regular expressions for matching PangoFontDescription strings have been corrected. If LilyPond's interface for PangoFontDescription string output becomes more comprehensive in the future, either the regular expressions would need to become more elaborate, or new infrastructure for parsing a PangoFontDescription would need to be implemented. But this isn't a problem right now.
- The dimensions for a page of SVG output has been corrected; millimeters are now used instead of pixels.
- A viewBox attribute for the <svg> tag has been added; it serves to scale the output to LilyPond's coordinate system (staff-space units). Grouping tags were used to accomplish this before, so these have been removed.
- The additional grouping tags to enclose a single page have been removed; they are unnecessary.
- The "round-filled-box" stencil routine was missing a fill attribute, so this has been added.
- All decimal numbers now have a maximum precision of 4, following the SVG recommendation.
- The <pageSet> and <page> elements have been abandoned in favor of one SVG output file per page.
- Landscape support is now implemented without using <pageSet> or <page> elements.
- All of the Emmentaler and Aybabtu font glyphs are now converted from <glyph>s to <path>s on-the-fly.
- Benefits:
- In general, it lowers file sizes. Only when a page of music contains a lot of data will the file size become large. This is an improvement over the current implementation, which produces large files no matter what.
- LilyPond's music fonts (Emmentaler and Aybabtu) no longer need to be installed.
- Kerning information and X/Y offsets for "glyph strings" are handled automatically by Pango. The SVG backend now manipulates this information to achieve the correct layout. Note: This does not apply for the non-music fonts (everything besides Emmentaler and Aybabtu).
- SVG files are easier to manipulate in Inkscape.
- Greater cross compability, since SVG fonts are still not widely supported.
- More accurate rendering of glyphs, since path data is unambiguous.
- Benefits:
[edit] Bugs with solutions
These are issues that have solutions but are awaiting further testing or approval to become part of LilyPond. If I have one, my latest patchset will be available here: SVG branch at repo.or.cz
[edit] Open issues
The items in this category have the potential of (a) creating invalid SVG output, (b) creating output that is not widely supported, or (c) causing some type of performance issue that is unresolved. Please report bugs here.
- The hash table used for caching the glyph contents grows continuously for multiple-page SVG output (one file per page). Of course, using the hash table does improve compile times, but I've noticed it can use up to 1.5GB of memory just for a 15-page score. In contrast, if a hash table is not used, memory usage tops out at 750MB but takes about 20 more seconds to finish compiling. A happy medium needs to be found.
- Some decimal values are not rounded to 4 decimal places because the default values contain 4 or fewer decimal places; ideally, we should round these values too, just to be safe.
[edit] Ideas for Enhancement
These items have the potential to improve interaction with SVG, but may require substantial coding. It is a wishlist. Please add feature requests here.
- Add a new option, --svg, to the LilyPond binary to simplify the process of creating SVG output.
- Find a command-line tool to convert SVG to PNG. This will provide an opportunity to have SVG regression tests.
- Inkscape works the best for this task. Would be nice to have something more lightweight...
- The Batik SVG Rasterizer works great too, and therefore depends on JRE (or OpenJDK). But we don't want to add another 60MB dependency to LilyPond.
- The "rsvg" tool from librsvg works fine, too. "convert" from Imagemagick uses the librsvg library as well. It does have issues with embedding SVG text, but in general the alignment is okay.
- Ideally, related grobs should be grouped (with <g> tags). For example, if a notehead has a stem, these two items should be grouped together. Unfortunately, this is not easily achievable because (a) the stencil implementation doesn't cater to it, and (b) related grobs are often not close to each other in the SVG output. One idea is to add postprocessing that can detect related grobs (maybe via grob-cause) and group them appropriately.
- Note: All glyph strings (Fingering, DynamicText, etc.) are grouped when they contain more than one glyph. See "Closed bugs". This makes sense logically, and it also makes the coding easier.
- Glyphs could be stored in the toplevel "defs" section and referenced from within the SVG document with the "use" element. This would help further minimize file sizes, and in a way, emulate the SVG font mechanism. But it's unclear how to achieve this, since it seems orthogonal to the stencil implementation. Preprocessing might be needed for this to happen.
- There should be support for converting all font glyphs to paths. This should not be the default option, since users will expect SVG text elements to be editable, but for purposes of beautiful presentation, the precise appearance of all text should be preserved. Thus, a command-line switch could be added (-dsvg-glyphs-to-paths).
- Requirements:
- Shipping every default font in SVG font format. The only fonts that don't satisfy this requirement are the Century Schoolbook fonts.
- On-the-fly conversion from (font format)->SVG fonts, via FontForge, for all other fonts. It is unclear what performance impact this would have.
- Use the "glyph-string" stencil expression in the SVG backend. This simplifies everything, because Pango preprocesses *all* kerning adjustments, combining characters, X and Y offsets, etc. The SVG framework may need to be generalized more to handle any font, but most of the structure is in place.
- Requirements:
- Ideally, we should use an XML library to parse SVG font files and cache glyphs in hash tables. Options include expat, which LilyPond already depends on, or the GNOME XML library, libxml.
- Another option is to use a nested hash-table approach in Scheme, similar to the GOOPS font tree in scm/font.scm.
- We might eventually consider using @font-face for fonts that are not converted to paths. The latest web browsers are helping to popularize this idea, so we'll see how things unfold.
- Once <pageSet> and <page> are supported by Inkscape and other SVG user agents, add a -d option (-dsvg-multiple-page) that will create a single SVG file containing all pages of output. This option should not be enabled by default.
