lilypond-devel
[Top][All Lists]
Advanced

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

Re: SVG status update


From: Patrick McCarty
Subject: Re: SVG status update
Date: Tue, 14 Jul 2009 00:44:17 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Jul 14, 2009 at 04:13:12PM +0900, Maximilian Albert wrote:
> 2009/7/14 Patrick McCarty <address@hidden>:
> 
> > Unfortunately, this would be very difficult.  Elements are dumped into
> > the SVG file in the order they occur in the page stencil, and (almost)
> > every one is independently positioned as well.
> 
> Ah, okay. That's what I though. Out of interest: At the time when
> these elements get written into the SVG file, do they know about their
> mutual relationships? E.g., does a beam know which note heads it
> belongs to (or vice versa)?

No.  The closest thing the elements possess that relates to this is
their *grob cause*.  For example the NoteHead grob is often the grob
cause for the "noteheads.s2" glyph.

> > Some of the related stencils are dumped consecutively (e.g. the
> > horizontal StaffSymbol lines), but I imagine this would require some
> > postprocess optimization, which is an interesting feature request.
> >
> > I'll add this to the wiki.
> 
> Following my question above, here is another random idea: Would it be
> possible to (perhaps optionally) set the "id" attributes of the
> elements to something meaningful from which at least the function of
> this element could be deduced, like "staffline01" or "barline42" or
> something similar? This could be a first step to enable some
> postprocessing. BTW, I'm not saying that you should implement this.
> I'm just interested whether it would be possible.

That's possible, but it would be much easier to insert comments based
on the "grob cause" mentioned above.

It would look something like

  <!-- NoteHead -->
  <path transform="translate(...) scale(...)" d="..." />

Would that be reasonable?

> P.S.: What's all this about text element being rasterized or converted
> to paths? I can edit them as regular text elements in Inkscape without
> problems.

Now that I think about it, I'm not really sure what Mark was referring
to.  Possibly the low graphics quality at 100% zoom in Firefox.

Thanks,
Patrick




reply via email to

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