[CREATE] OpenRaster clarifications

[calle at luolamies.org]

>> First, layers and nested layer stacks have coordinates which default to 0. I
>> assume these are relative to the parent element?
>
> I think this is the only definition that makes sense for a deep   
> rendering stack.
> No absolute coordinates. Someone should clarify this in the wiki.

Yes, that sounds reasonable. Relative coordinates certainly feel like  
the natural
way to do it.

>> Second question is about the size attributes. If a size has been
>> explicitly defined for a layer and it differs from the actual size of the
>> source data, should the image be resized or cropped to fit the layer or
>> should the manually defined size be ignored?  Likewise, how should a stack
>> whose size differs from the computed size of its contents be treated?
>
> I would say that, whenever a size is given, this can only mean cropping.
> Resizing might not make sense for some filters, like a filter that generates
> an infinite pattern.
>
> From the Wiki:
>> ..."width" and "height" are positive integer, their default value is set
>> to the value defined by the data source for a layer...
>
> Thinking about this, I don't see any benefit for the width/height attribute
> at all, as opposed to using an explicit crop filter when needed.  It seems
> like an unneccessary and tricky task to calculate those default values.
>
> I used to think this was a good idea to define the image frame (something I
> want to introduce soon in MyPaint), however even this does not work at all,
> at least not consistently with the position in the <image> tag.
>
> Can we just remove generic size/height attributes from the spec please? Any
> objections?

I second this. Best the size come from the actual data source, whether it is
an image or a generator.
I can still see a need for the size attributes in the <image> tag when the
desired canvas size is greater than the bounding rectangle of the layers, but
this should be clarified as well. Specifically:
1. What if the defined size is smaller than the computed one? (Perhaps the
size should be treated as a minimum size?)
2. What to do with uncovered areas? (Filled with transparent pixels is
probably the standard action)
3. Are the x & y coordinates needed? Are there any cases where it would
be needed to set these to something else than what can be computed
from the layer positions?

>
>> It would also be nice to have an attribute to mark a layer as hidden
>> independant of its opacity.
>
> Yes, probably. I guess this is quite an application specific feature. My
> suggestion would be that you set opacity=0.0 for hidden layers, and add
> extra attributes somewhat like unhidden_opacity=1.0, hidden=True.  This
> should make all applications work correctly.
>
> I think we still lack consensus how to handle such a situation. But I would
> say just go for such a backwards-compatible hackish solution, and maybe even
> add it to the standard like this.  Objections, anyone?

I think this is a fairly common feature. Most programs, including GIMP and
Krita, have it. In my opinion, the best way would be to just add a boolean
hidden attribute.

>> Finally, what's the status of the text element currently? DrawPile has
>> annotations, which are pretty much equivalent to text layers in other
>> programs (except that DP annotations always float on top of the image), so
>> naturally I'd like to be able to save those as well.
>
> I have no idea. I think the way to go is that you propose something, and
> when neither GIMP nor Krita people say something, you add it to the standard.
>

I'll see if I can write up a proposal this weekend.

	-Calle