[CREATE] OpenRaster

[Boudewijn Rempt]

On Wednesday 21 June 2006 05:42, you wrote:
> At 02:42 PM 6/20/2006, Boudewijn Rempt wrote:
> >After discussion on this list, I'll update the wiki -- and I hope that we
> > can soon start to discuss detail issues, instead of the big picture.
>
>          Let me start by thanking Boudewijn for putting this together
> as a starting point for discussion...and I'll also be glad to start
> the ball rolling with a few comments.  These are not in any particular
> order.
>
> * Metadata should be stored as XMP.  It's XML-based and the current
> industry standard for metadata in images & compound documents.


Bruce D'Arcus also mentioned XMP as part of the ODF 1.2 effort, so I guess 
that's a given. I'll check out the wiki he mentioned 
(http://wiki.oasis-open.org/office/metadata_use_cases) and update the 
document.

> * All binary data should be stored as a separate file in the archive
> and referenced from an XML "manifest".  There should be NO Base64
> encoded data in any XML.

Fine with me.

> * Any hierarchical arrangements should be described in XML and not
> using the "fake directories" of ZIP/Tar. However, common naming
> conventions for files/paths should be established.

Well, I wouldn't call them fake, and I would prefer having a hierarchy inside 
the zipfile, but I am fine with making the path structure explicit in 
content.xml, manifest.xml.

> * Image data should be stored in either PNG or "raw bits" - lossless
> formats that are easy to access.  PNG should be used for any data
> that which is compatible with it, and "raw bits" for anything that is
> not (eg. CMYK or Lab data, floating point, etc.)

Oyvind Kolas proposed to make it possible to also store jpegs as read-only 
layers. I'm not sure how to make that work without, though. Are you sure it's 
a good idea to make it impossible to store non-float rgb/grayscale data in 
the same way as cmyk/lab? Oh, and by "raw bits" -- do you mean no structuring 
of the pixel layer data in tiles?

> * I would use SVG Tiny/Basic for handling both Paths and Text.  I
> think supporting the full ODF grammar for text layers is simply
> overkill for this - and will tend to keep many implementers
> away.  SVG 1.1/1.2 provide, IMO, all the text and path features you
> should need.

Probably, but don't we want OpenDocument compatibility here? Of course, paths 
and text can be viewed separately from compound documents that embed 
OpenDocument text and drawing documents. Compount documents really are 
needed.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/create/attachments/20060621/440f957c/attachment.pgp