> Le 2 déc. 2018 à 11:25, Carl Sorensen <c_soren...@byu.edu> a écrit : > > On 11/30/18, 8:40 PM, "lilypond-devel on behalf of Étienne Beaulé" > <lilypond-devel-bounces+c_sorensen=byu....@gnu.org > <mailto:lilypond-devel-bounces+c_sorensen=byu....@gnu.org> on behalf of > beauleetien...@gmail.com <mailto:beauleetien...@gmail.com>> wrote: > > Hello all! > > I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I am > also the maintainer of the MediaWiki Score extension which allows embedded > LilyPond on Wikipedia. I’m currently a bachelor student at the Université de > Montréal studying computer science and mathematics, and Google Summer of Code > caught my eye. I’d be interested in doing a project if a mentor is available. > > # Improving SVG score output > > I think this is a great idea! > > ## Summary > > Scalable Vector Graphics (SVG) is a vector graphics format designed for > use on the internet. LilyPond (LY) is a program which translates musical > notation syntax into a graphics format, such as SVG. This format is important > for web publishing, and as a vector format, is advantageous over Portable > Network Graphics (PNG) file, of which is _de facto_ used in this application. > > PNG is only used for snippets. The real _de facto_ output of LilyPond is > ps/pdf. I would hate to lose that. Of course I am not advocating to remove any functionality of LY. I am saying that when embedding LY in webpages, PNG is used (in the manuals, etc.), while SVG would be superior. > > LY already has SVG output, yet is somewhat broken in many factors. Namely > in font handling with broken sky-lining #3778 and the use of musical symbols > as text. Development in fixing these problems may offer changes in other > backends. This project will focus on the use of musical symbols in SVG files > and the positioning of text. I have previously submitted patches for > text-positioning bugs. > > I think this sounds like a great idea! > > ## Deliverables > > * Self-contained musical SVG files > * Functioning text sky-lining in SVG > * Grouping of text for better placement in SVG I should also add a line about adding a suite of tests of SVG output (like done with PS) to visualize changes. > > ## Timeline > > _This is the hard part… Non-comprehensive_ > > * Analysis of incompatibilities between PostScript (PS) and SVG output > Important to have a grip on this to not introduce bugs and to keep > commonalities between backends > * Deprecation of SVG fonts - embed font into SVG > > — — > > * Reduce size of SVG by enumerating used glyphs > * Merge glyph functions for text and symbols > > — — > > * Implement use of `<tspan>` tags and Cascading Style Sheets (CSS) for > text handling > * Will require modification of PS backends > > This causes me concern. In general, I think the PS backend works well, and I > would prefer not to have it changed to be consistent with some functionality > that only affects the SVG backend. But until I see more concrete proposals, > I don't know whether I would be in favor of or opposed to the PS backend > modifications. Changes to other backends may not be necessary, but I think it is important to keep a high level of abstraction between these various backends to keep the output generation generalizable before choosing a specific format. > > * Fix Horizontal Spacing of text > * Fix SVG text sky-lining in conjunction with character size / spacing > calculations > > This is great! > > I think that I would like to continue to have LilyPond use Pango. I don't > know how Pango would integrate with SVG, but I think that's the right > approach. I would not be in favor of creating and maintaining our own text > spacing engine. I hope Pango integrates well with SVG, don’t know (yet). Creating our own text-spacing engine would be out-of-scope and a massive undertaking… We are in agreement here. > > Thanks, > > Carl
Étienne _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel