[Top][All Lists]
[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
Re: SVG status update, Mark Polesky, 2009/07/14