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: Re: [office] proposal for ODF 1.2: extension of verticalrelationvalues for certain anchor types

Hi Florian,

Florian Reuter wrote:
>> Dear TC members,
>> finally after the solution of my problems to post to the mailing list
>> I can post the information I have already given in yesterday's TC
>> call.
>> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems wrote:
>>> Dear TC members,
>>> I would like to propose the following extension for ODF 1.2:
>>> Allow vertical relations "page" and "page-content" for anchor types
>>>  "paragraph" and "char" - see "Table 16 - Vertical Relation values"
>>> in ODF 1.2 specification, draft 7, second edition - file 
>>> "OpenDocument-v1.2-v7-02.odt".
>>> These vertical position combination are possible in OpenOffice.org 
>>> since version 2.0. They are needed to have objects (text frames,
>>> graphics, embedded objects and drawing objects) anchor to a certain
>>> content (paragraph or character), but be vertical positioned
>>> relative to the page areas. E.g., a graphic explaining a certain
>>> word of a paragraph always vertical positioned at the bottom of the
>>> page, on which the word is on.
>> Some word about the backward compatibility of my proposed extension:
>> There exist no backward compatibility issue regarding the ODF schema.
>>  The current restriction that certain vertical relations are only
>> allowed for certain anchor types is expressed in prose not in any XML
>> or related formal language.
>> Applications, which only support ODF 1.0 or ODF 1.1, can in general
>> not handle the new proposed combinations of vertical relation and
>> anchor type. I assume that these applications will fall back to an
>> application dependent default combination of vertical relation and
>> anchor type. From my point of view the expected impact on the
>> rendered document in an only ODF 1.0/1.1 supporting application is,
>> that the object is not at the same position as in an ODF 1.2
>> supporting application. I do not expect any data loss.
>> Best regards, Oliver.
> Hi,
> So the options I see old ODF processing entities have is
> a) Ignore the value, but preserve it -- but internally use an
> application dependent default fallback b) Change to value to an
> application dependent default value c) stop loading the document and
> say its not conformant
> Its not clear to me what the expected bahviour wrt. the ODF 1.0/1.1
> specification text is.
> Maybe we would make this clear in the specification so that we have a
> defined bahviour if we need to change the value set in the future
> again...

I think this is a valid request.

But regardless of my proposal and as you already stated, we have the
problem that the current ODF 1.0/1.1 specification does not define, how
an application should react, when a disallowed combination of vertical
relation and anchor type occurs in a document. The other problem we have
is that there exist already released ODF 1.0/1.1 supporting
applications, which based on the above mentioned undefined behavior.
Each of the Florian's above given behaviors and even more ones can
already been implemented.
Thus, I have problems in defining the behavior of an ODF 1.0/1.1
supporting application, when it imports an ODF 1.2 document containing
one of my proposed new combinations of vertical relation and anchor type.

I think we have no chance to correct our error - leaving the behavior on
disallowed vertical relation and anchor type combinations undefined -
for ODF 1.0/1.1 supporting applications, especially when these
applications are already released. That is the reason why I only made
assumptions about it.
What we can do - and at the beginning I already stated that it seems to
me a valid request - is to correct this error for ODF 1.2 supporting
applications. But, I think this is not in the scope of my proposal,
which is a feature proposal. The correction should be handled in a
different proposal - a correction proposal - in order to have the
possibility to discuss/vote on these things separately.

Best regards, Oliver.

Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 550
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

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