Re: Re: [office] Tabulator (TAB) questions to implementors

["C. Boemann" <cbo@boemann.dk>]

On Monday 14 October 2013 17:13:21 Svante Schubert wrote:
> 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.
Ah in that case calligra doesn't have inheritance either. it's only 
style:tab.stops that is inherited.

There is no individual inheritance of the sub elements.

There are other style properties (eg font height related tags) that work in a 
similar way. The style inheritance should be seen as a conceptual thing, not 
strictly related to xml tags. At least that is my philosophical view on it - 
don't think it's written out anywhere in the spec.

> > 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.
i agree and luckily both calligra and OO family does it like that afaict

> 
> 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:
> http://tools.oasis-open.org/issues/browse/OFFICE-3846
> 
> 
> Best regards,
> Svante
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php