[CREATE] OpenRaster fallbacks (proposal/RFC)

[Cyrille Berger]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/create/attachments/20090818/d5e9444e/attachment-0001.htm