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] Tabulator (TAB) questions to implementors

Am 14.10.2013 16:36, schrieb C. Boemann:
> On Monday 14 October 2013 14:05:25 Svante Schubert wrote:
>> Are tabulators being inherited in ODF XML similar as style properties are?
>> Perhaps the first question should be: Are all other style properties
>> being inherited in all circumstances?
>> Regarding Tabs:
>> Within a content (or styles) XML file within a package a TAB declaration
>> may look like:
>> <style:style style:name="Heading_20_1" style:display-name="Heading 1"
>> style:family="paragraph">
>>     <style:paragraph-properties>
>>         <style:tab-stops>
>>             <style:tab-stop style:position="2cm"/>
>>             <style:tab-stop style:position="3cm"/>
>>             <style:tab-stop style:position="5.001cm"/>
>> Explained by ODF 1.2 via
>> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#el
>> ement-style_tab-stops
>> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#e
>> lement-style_tab-stop
>> and inheritance is mentioned for <style:style>
>> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#el
>> ement-style_style
>> From a simple test in one ODF application it seems TABs are NOT being
>> inherited, which seems wrong at the first sight, but when taking a look
>> OOXML, where TABs are being inherited, but can be ignored on paragraph
>> level via a 'clear' attribute, the absolute writing of TABs would
>> guarantee interoperability.
>> Please note, the inheritance within the XML, does not say anything about
>> about the inheritance during run-time. Even without inheritance, full
>> absolute TAB positioning for every paragraph there would be run-time
>> inheritance possible.
>> If we want to inherit TABS during run-time, we would on the other hand
>> require something similar to 'clear' to guarantee interoperability among
>> the ISO Office format standards.
> not quite sure what you mean with run-time, but in Calligra the tabs are 
> inherited.
To make certain if an application has run-time inheritance of tabs, I
used the following test case:
1) Added two tab positions at a parent style (e.g. Heading)
2) Added a new tab position at a child style (e.g. Heading 1), the two
from the parent should exist
3) Deleted one of the two parent tab positions, the child should only
remain two positions.
> If by run-time you mean that we keep the style-inheritance tree and are able 
> to save it back, then yes Callgra does that as well but apart from it being a 
> requirement for roundtripping i don't see how this is relevant to the standard 
> as such.
This inheritance tree can be designed in XML in various ways.
a) Without inheritance on XML level: Write out all tab positions for
each style explicitly
b) With inheritance on XML level: Write out only the tab position added
by the style in that style hierarchy

Both ways still allow to have run-time tab-stops inheritance, but only
the first allows the emulation of the 'clearance'/neglectance of certain
tab positions of ancestor styles as OOXML offers it.

In any case the spec seems unclear to me, what has to be done in general.
> As far as a clear attribute for tabs, then the standard is to have the normal 
> repeatng tabs after the last tab, so ifyou want to "clear" you would just make 
> a definition with no tabs
If the style "heading" defines two tabs and "heading1" is a style child,
but does only want to use one of the two parent tabs, it can only do so,
when we agree to save all positions explicitly, so one tab position in
"heading1" means we do not have to take care of parents or we add
inheritance in general, but add a "clear" attribute, which explicitly
tells which ancestor tab position should be ignored.

I am currently favoring the first explicit none inheritance ODF
approach, as it is easier to establish, might even be the
state-of-the-art today.
I am curious, how implementors would solve the heading/heading1 scenario.

Added a JIRA issue: https://tools.oasis-open.org/issues/browse/OFFICE-3845
>> PS: In addition we might want to define the following attribute for TABs
>> as well
>> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#at
>> tribute-text_relative-tab-stop-position as currently the position dependent
>> on the following settings.xml flag:
>> <config:config-item config:name="TabsRelativeToIndent"
>> config:type="boolean">false</config:config-item>
>> It defines, if the left-margin have to be added to the tab position.
> Yeah I agree this is something that in a perfect world needs to be closer to 
> the real standard, but not something set for each style either.
> So let's document but if we move this setting elsewhere we are just ntroducing 
> even more complexity.
I have checked in OpenOffice there is a flag in the content-table dialog
how the indent should be aligned to.
Therefore we can not remove the existing attribute and exchange it
simply by a document wide one without feature loss for some applications.
But I have written an owen JIRA issue for this:

Best regards,

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