<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:9pt; font-weight:400; font-style:normal;">On Sunday 09 August 2009, Martin Renold wrote: > On Sun, Aug 02, 2009 at 01:36:35PM +0100, Øyvind Kolås wrote: > > [...] or perhaps even make the projection/ fallback/cache rendering > > reference just an attribute of the filter/stack/layer. > > I think the fallback/cache will need own attributes, like x/y position and > maybe the possibility to provide both a float and an 8bpc variant. I am not sure if I see the point of this, I would suggest to limit fallback to RGB8bit (eventually to grayscale 8bit). > And we might have to distinguish between fallbacks/caches for filters > (which provide a replacement image for everything below them) and > fallbacks/caches for <render> tags (which are composited OVER whatever is > below them). Why the need of a distinction, if you see <render><fallback /></render> and <filter><fallback /></filter> then you know what kind of replacement you need to do. > > We should permit fallbacks as a subelement of all possible OpenRaster XML > > elements, > > With this solution, if we want the applications that need the fallbacks > also to actually use them, then we should quickly define a small, permanent > and sealed list of possible OpenRaster XML elements. > > (Assuming we don't want an un-XML'ish solution after all, by asking > implementations to check every unrecognized tag for fallbacks.) that would plead for doing the other way around <fallback> <render /> </fallback>, I am unsure of what I prefer. > > and that it would be encouraged to make this information survive > > an load/edit/save cycle. > > Do you mean unrecognized filters and tags? In order for this to work, > unrecognized datafiles also have to survive the load/edit/save cycle. > > Examples: > - SVG datafiles used by an SVG render tag > - color profiles (for apps that don't know about them) > - app-specific extensions: > - vectorized strokes (tablet input data) for some layers > - avatar pictures of users who have edited the image > > To be sure you would have to preserve the whole ZIP content. Do you think > such a thing would actually get implemented in GIMP or Krita? I hope so. > > There is currently no "render" element in OpenRaster. > > Wouldn't it be appropriate to use the <render> element also for text and > for SVG data? Applications that don't handle SVG or text could just > support it with the same code. This also helps reducing the number of tags. For SVG, I would simply use <layer src="myfile.svg" />. -- Cyrille Berger</body></html>