I'll examine it, thanks. Meanwhile, I don't know if it is the right case, but it comes to my mind a hack, which I applied on some similar code:
Before the SVG bytestream is emitted by the write_func, I would set a temporary, special and different _color_ for each grob that is associated with output-attributes. This color is automatically generated and must obviously be different from any other color that will be included in the output SVG. Then you can create a map with key = specialcolor, value = pair (original color, output-attributes) and when you parse the generated bytestream, if you find any set of objects with a color included in the map, you can group them, set output attributes on the group and restore the original color. I repeat: this is a hack, it's a bit imaginative and I don't know if it's really suitable for the present case. But the unique color mechanism is much safer than you might think. On Sat, Dec 31, 2022 at 12:41 AM Jean Abou Samra <j...@abou-samra.fr> wrote: > Le 31/12/2022 à 00:29, Paolo Prete a écrit : > > Hi Jean, > > > > Do you have a test snippet for cairo_svg_create_for_stream() ? > > > > I would like to make some tests and I googled a bit but could not find > > anything useful for it. > > > Fortunately, my deleted branch for this was still around in my Git > repository. I ressuscitated it and uploaded it to my fork, so you should > be able to check it out with > > git fetch "g...@gitlab.com:jeanas/lilypond.git" cairo-output-attributes > git checkout -b cairo-output-attributes FETCH_HEAD > > You can see that the <g> tags are properly output, but before all the > rest of the SVG output. > > >
