[CREATE] OpenRaster fallbacks (proposal/RFC)

[Martin Renold]

On Sun, Aug 02, 2009 at 01:36:35PM +0100, Øyvind Kolås wrote:
> I do not think there is many scenarios where there would be multiple
> alternatives, it would probably always be intended XML code, and possibly
> a fallback render.

Agreed. The <try> construct would add more complexity than required.

> I'd prefer some even simpler augmentation of what we already have, along
> the lines of Cyrille's projection tag,

Sounds good, but also leaves quite a few of the problems unsolved that I was
addressing with my proposal. But they can be solved independently, I hope.

> [...] 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.

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).

> 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.)

> 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?

> A file saved with maximum portability would be huge, and I also wonder
> what needed extra support in user interfaces would be needed to tune such
> detailed control over what renderings are retained when opening a file.

I don't think there is any special GUI need at load time, at least not for
applications that can save back unsupported filter elements (see above).

I imagine such an application would use the fallback/cache as long as
possible.  Take a text element as example: such a program never tries to
re-render the text fallback until the user edits the text.  At this point it
drops the fallback and replaces the text element with its own internal model
(the user can undo this step).

The other option for the user is to pixel-edit the correct rendering.  This
can be done with the same command that is used to convert a text layer into
a normal layer.  No need for any new GUI elements at all.

The concept "convert text layer to normal layer" can be extended a bit to
mean "use fallback/cache and drop extra information".  It could work on any
<render> tag, or even on a <stack> element to collapse the layers and filter
chain below it.  This command is useful independent of fallbacks.

When editing a layer that gets filtered somewhere below in the stack, the
application will be forced to render the unknown filter somehow, probably by
using a nop filter.  The GUI would then highlight the unsupported filter in
the stack, encouraging the user to replace or drop it.  If the user doesn't
do that, the unknown filter element will be saved back.

> 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.

bye,
Martin