[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC Proposal - SVG Export

From: Étienne Beaulé
Subject: Re: GSoC Proposal - SVG Export
Date: Sun, 2 Dec 2018 11:41:42 -0500

> Le 2 déc. 2018 à 11:25, Carl Sorensen <address@hidden> a écrit :
> On 11/30/18, 8:40 PM, "lilypond-devel on behalf of Étienne Beaulé" 
> <address@hidden <mailto:address@hidden> on behalf of address@hidden 
> <mailto:address@hidden>> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]