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] chart:auto-size/chart:auto-position


I have a question that may be unrelated to this topic.

In last paragraph,you said: "-) Well, and you could consider that I might have
xml:ids on all those paragraphs and be associating content for
production there. ;-)"

This let me remember ODF TC have already approved the proposal that applies "xml:id" to identify uniguely both draw:page and all shape elements. See the link: http://lists.oasis-open.org/archives/office/200710/msg00065.html.

So, does your last word mean "xml:id" can be extended to paragraphs besides draw:page and all shape elements? Or this "xml:id" can be applied to all document elements? If this is useful and feasible to be implemented, maybe we need raise another topic to discuss it.

Inactive hide details for [office] chart:auto-size/chart:auto-position[office] chart:auto-size/chart:auto-position

[office] chart:auto-size/chart:auto-position

Patrick Durusau


office TC

2008-04-28 21:57


There are a couple of issue with regard to these attributes that need

1) It is assumed from the text that either both of these attributes
appear or neither of them do, but that is not explicitly stated.

In other words, if chart:auto-size is true and chart:auto-position is
not, what is the resulting behavior? (We don't currently say. My
suggestion is that if either chart:auto-size or chart:auto-position is
true, then the other is conclusively presumed to be true (in other
words, if set to false, that would be an error).

2) Furthermore, we state that "some chart elements support an automatic
size" (same for automatic position) but these attributes appear via|
<style:chart-properties>, so what chart elements exclude the use of
automatic size and positioning?

If it fair to say that all chart elements that accept use a chart style
may be rendered using automatic size and position attributes but that
not all applications support that feature?

In which case, what happens if the static size/positioning attributes ,
svg:x and svg:y are absent?

That is I start with an application that supports automatic
size/positioning but then pass my document to an application that doesn't?

We currently say that svg:x and svg:y record the size/position of the
chart (plot area actually) but I don't read our current language to
mandate that recording.

As a matter of fact we say: "|In this case the explicit size that may be
given as |svg:width| and |svg:height| attributes is irrelevant for
rendering. |"
(see v. 6 at 16.32.5, or 7.01 at 18.12.1.) That sounds to me like we
made the recording optional, which would impair the interchange of ODF

Since fixing this problem isn't simply editorial repair but making the
svg:x and svg:y attributes mandatory on plot area as well as mandating
the interpretation of chart:auto-size/chart:auto-position in the absence
of the other, I wanted to get this on the agenda for a future meeting.

Hope everyone is at the start of a great week!


PS: I have to get the XML internal to the current version repaired but
should have the 7.02 draft posted this evening. Sorry about the delay.

Do note that it will have markers for the insertion of schema fragments,
examples, SVG renderings of content models and the like by simply
matching the marker and inserting text. That will be true for chapters
3-5 and the first 30 or so attributes. Enough to make a small test case.

Those are of the form: element-text:change and
attribute-chart:attached-axis. Since those strings should never occur in
the text proper it seemed like the easiest way to provide a convenient
hook for other material. Note that those will not be present in the
final version that we vote upon but will be converted to hidden
paragraphs that we can then locate later to add non-normative or
explanatory material to the text.

That does not mean that I have given up on using the ODF 1.2 metadata
mechanisms for that task but simply a recognition that we may also need
rough-n=ready production techniques to produce the final version(s) in a
timely fashion. ;-) Well, and you could consider that I might have
xml:ids on all those paragraphs and be associating content for
production there. ;-)

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

GIF image

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