On 28 January 2014 09:33, Boudewijn Rempt <[email protected]> wrote: > On Monday 27 January 2014 Jan 19:32:57 Andrew Chadwick wrote: > Hm... I can't say I'm very enamoured of a construct like > > <layer composite-op="svg:normal svg:src-atop" ... />
Yeah. It's just a thought, to try and achieve some limited backwards compatibility. I'll confess I don't much like properties in XML dialects that you have to parse to any degree beyond looking up values in a table or conversion to a single basic type. I'm happy to go ahead with separate @blend and @composite, as in the proposal. I just wanted to bat around the idea of expressing it via @composite-op. I suppose though if you want to attempt to be backwards compatible, you'd write a composite-op if the blend+composite mode of the layer can be expressed as one of the old "svg:" names. (TBH I sort of hate the svg: prefixes, primarily because SVG1.1 doesn't do interesting blending and never did, and http://www.w3.org/TR/SVG12/ and its modules have kinda languished since 2005 and been superseded by efforts like Compositing-1. The OpenRaster spec seems to have been written off an earlier draft, which we had to supplement anyway for colour/luminosity/hue/saturation modes, so those "svg:" prefixes seem to refer to an SVG that never was quite official. Time to make a clean break, I think; the Compositing-1 spec just seems fuller and better to me.) > That said, I'm going to have to spend some serious time on krita to actually > make krita compatible with all the possible permutations of the original > proposal. Maybe we'll have time in Leipzig to go through it? That would be good - I'll certainly make time. It's worth noting that there are probably only a small number of the compositing modes that make sense for a painting app: - source-over for general work - destination-in for making masks where you draw the void - destination-out for making masks where you trim off the unwanted edges (unusual, but it's more efficient to render ☺) - source-atop for making coloured textures over the tops of things Of the others, {destination, copy, clear} are pointless for getting things done. As for source-{in, out} for making masks, sure they can be used, but using their destination-{in, out} equivalents over the top in an isolated <stack/> makes for a simpler stacking structure when you find yourself wanting a group of layers you want to mask as a whole. I can't really think of an use for xor in any artistic workflow, and lighten (plus) looks like it really wants to be a blend mode, though the Porter-Duff paper says it's handy for crossfades. > On the topic of openraster, I want to bring something up that was discussed > before, but I don't remember the resolution: > > I'd like to add a png of the rendered image to the zip file. For Qt, I > created a qimagio plugin that can show ora files, but it actually uses all of > Krita to render the file -- and that is both dangerous and takes a lot of > time. Isn't that the idea behind mergedimage.png? http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft/FileLayout/ We could bump it up to a MUST, but that might need a new spec version. -- Andrew Chadwick _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
