[CREATE] ORA fullscreen viewers

Martin Renold martinxyz at gmx.ch
Sun Sep 12 13:05:33 PDT 2010


On Fri, Sep 10, 2010 at 08:49:44PM +0100, Alastair M. Robinson wrote:
> On 10/09/10 19:28, Luka Čehovin wrote:
>
> [...] ways it could go horribly wrong:
> 
> 1. The reference library doesn't provide enough functionality, and leaves
> the application developer to implement various filters, blends and
> colourspace conversions.  As you rightly point out, this is a lot of work,
> which in this scenario has to be duplicated in each application that
> suports ORA.

Applications use their own implementations/libraries for that anyway.  I'd
say most are not willing to use libora for the main rendering except to
convert to their internal format.

> As a result, support for ORA remains patchy,

I think ORA is supposed to support patchy implementations. Instead of
forcing applications to implement each other's features.

> and those applications which do support it have incomplete or bug-ridden
> implementations.  End users find that using ORA causes them problems, so
> avoid the format.

We started talking about image viewers. Every application should be able to
render an ORA file correctly, at the very minimum, flat without layers. 

This can be ensured by defining a small set of features (possibly zero) that
is acceptable for an image viewer to implement.  If additional features are
used, enough fallbacks must be provided (eg. just a full rendering).

Simple images (layers with well-known blending modes) would stay editable. 
Text/vector layers may be displayed as pixmaps, no longer editable; parts of
the layer tree may be collapsed because an effect is not implemented.  An
advanced application may offer to remove the effect and edit its input.

I think no exchange file format could do better than this, without forcing
all applications to use the same internal model.  And the user can still
open the file in the original application for full editing.

At least that's where I see the goal of OpenRaster now.

Users should trust the file format because it /always/ renders correctly.
Applications should trust it because they can store and recover all their
private data, without need for another file format for that.

-- 
Martin Renold


More information about the CREATE mailing list