[CREATE] OpenRaster fallbacks (proposal/RFC)
cberger at cberger.net
Tue Aug 18 09:06:10 PDT 2009
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
> > 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.
> - 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" />.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CREATE