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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: Open Office XML Format TC Meeting Minutes 19-May-03


MINUTES OF THE OASIS OPEN OFFICE XML FORMAT TC MEETING
MAY, THE 19TH, 2003, 3PM GMT  4:00 PM GMT

Attendees
---------
Doug Alberg <doug.alberg@boeing.com>, Boeing
Simon Davis <simond@naa.gov.au>, National Archive of Australia
Patrick Durusau <pdurusau@emory.edu>, Society of Biblical Literature
Gary Edwards <garyedwards@yahoo.com>
David Faure <faure@kde.org>
Paul Grosso <pgrosso@arbortext.com>, Arbortext
Jason Harrop <jharrop@speedlegal.com>, SpeedLegal
Paul Langille <paul.langille@corel.com>, Corel
Uche Ogbuji <uche.ogbuji@fourthought.com>
Daniel Vogelheim <daniel.vogelheim@sun.com>, Sun Microsystems


Acceptance of Minutes of the May, the 5th meeting
------------------------------------------------------
- The attending TC members unanimously accepted the minutes.


Action Items
------------
- Phil Boutros: create proposal for unifying change tracking in text and
   table documents
   - in progress

- Daniel Vogelheim: Clarify whether SVG supports user defined style
   sheets in addition to CSS and direct properties
   - done. See
     http://lists.oasis-open.org/archives/office/200305/msg00012.html
     Additionally, as reported during the meeting, Daniel has contacted
     Sun's SVG working group representative, who confirmed that the SVG
     spec is basically open to other styling models, with CSS and SVG
     style attributes being the only spec'ed methods.

- Daniel Vogelheim, Michael Brauer: Prepare comparison between
   OpenOffice.org's elements for graphical content and SVG
    - done. See
      http://lists.oasis-open.org/archives/office/200305/msg00015.html


Discussion of Work Package 6 Graphical Content
----------------------------------------------
The ongoing discussion on graphical content was continued in this 
meeting, particularly the relationship between SVG and Open Office 
graphical content. The requirements with respect to SVG were clarified as:
- there should be a reasonable translation from Open Office XML to 
current web standards. In particular, transformation into a web page 
with SVG should be possible.
- the format should not rely on 'magic' numbers or names in the format. 
All graphical content must be fully described.

The differences between SVG shapes and the OOo shapes were discussed. 
The basic shapes are similar, but there are some differences in how 
coordinates are specified. E.g., an SVG ellipse is defined by center 
(x,y) and radius (rx,ry), while an OOo ellipse is defined by its 
bounding box.

It was discussed whether the shape model should be more closely modeled 
on the SVG model. This was not accepted. The TC unanimously decided to 
adopt the base model shapes as-is.


The format of embedded graphics was discussed. The TC unanimously 
decided the specification should included recommendations, but no 
restrictions for graphic formats which can be embedded in documents. SVG 
should be a recommended vector format.


Two questions on embedded images came up, namely on keeping the aspect 
ratio when resizing an image, and using images with horizontal rules. No 
answer was found during the meeting.


The representation of embedded objects was discussed. There is a need 
for displaying embedded objects on systems and platforms which do not 
have access to the original applications. It was agreed that the format 
should provide a facility for fallback image(s) for embedded objects.

Due to problems with the teleconference service, all participants were 
dropped from the meeting, and only four people rejoined. Therefore, no 
formal decisions on fallback images were made.


A question on text wrapping for text boxes came up. It was agreed the 
base specification does not sufficiently explain this attribute. KWord 
supports a wrapping mode which flows text around either the left or 
right side, depending on where is more space. This is similar to the 
existing 'automatic' attribute, which flows text around both sides, if 
there is sufficient space.


New Action Items
----------------
None.


Daniel Vogelheim



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