OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: interoperability issues


Regarding the custom shape draw:type attribute, the specification says:

  "The draw:type attribute contains the name of a shape type. This name
   can be used to offer specialized user interfaces for certain classes
   of shapes, like for arrows, smileys, etc.  The shape type is
   rendering engine dependent and does not influence the geometry of the
   shape."

Perhaps the "geometry of the shape" is technically unaffected, but the
value of draw:type *does* affect the rendering of the custom shape in
OpenOffice. There are a certain number of custom shapes which have
subshapes which are shaded lighter or darker. For example, the eyes of
the smiley face, or the side and top of the cube.

If you save a presentation in OpenOffice with a smiley face, manually
change the draw:type from "smiley" to "cube", and re-open the
presentation, you will see that the eyes of the face change color.

At least the following shapes are affected: cube, smiley, quad-bevel,
can, cube, paper, vertical-scroll, and horizontal-scroll. These shapes
originated in MS Office, and OpenOffice requires them to support MS
Office import.

I do not think that requiring each OpenDocument-supporting application
to have mysterious rendering hacks hardcoded to the custom shape name is
a good way to support interoperability. Furthermore, if this feature is
required in OpenOffice, presumably other applications will need it it.

I would suggest amending the enhanced-path specification to allow for
additional commands which would indicate that a particular subpath
should be lighter or darker by a certain amount. Alternatively, the
specification could define a list of custom shape names which use
shading and specify exactly how their various subshapes are shaded (by
index, presumably), although obviously that is a much less flexible
solution.

Although OpenOffice does not use it, perhaps this shading was the one of
the reasons for the draw:engine attribute:

  "The optional draw:engine attribute specifies the name of a rendering
   engine that can be used to render the custom shape. The attribute's
   value is a namespaced token, meaning an identifier prefixed by an XML
   namespace prefix, just like any attribute or element name in this
   specification. The drawing engine may get its data either from the
   draw:data attribute, or it may evaluate the <draw:enhanced-geometry>
   child element.  If the draw:engine attribute is omitted, the office
   application's default enhanced custom shape rendering engine will be
   used. This engine gets its geometry data from the
   <draw:enhancedgeometry> element only."

I don't know what to say about draw:engine, except that as someone who
is interested in OpenDocument due to its supposed interoperability,
frankly I am appalled.

Regards,
Chris



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]