OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Feature under evaluation at Redflag 2000

    Posted 10-14-2009 08:31
    Dear TC members,
    
    our team at Redflag 2000 is currently evaluating a feature related to 
    tables in word processors, we call 'Floating Table Positioning'. So far, 
    tables cannot be absolutely positioned in ODF text documents, except 
    they are embedded in a "draw:frame" element, please refer section 9.4.2 
    in ODF 1.2, Part 1, CD03[1]. Other document standards, namely OOXML 
    (section 17.4.60 tblPr, Part 1, ISO 29500, Page 484) and UOF support 
    absolute positioning of tables in text documents, quite similar to 
    "draw:frame" in ODF, so we would like to submit a proposal that adds 
    this feature in order to increase interoperability.
    
    Consequently, I would like to raise two questions:
    
    1) Is any TC member already working on a similar feature?
    
    2) Considering such feature seems to be quite obvious, as well it is 
    quite easy to add, hence I would like to know if there is a telling 
    argument, why it hasn't made it into ODF yet?
    
    Best regards,
    Peter
    
    [1] 
    http://www.oasis-open.org/committees/download.php/33633/OpenDocument-v1.2-part1-cd03.odt
    
    -- 
    Peter Junge
    Open Source Strategy Director
    
    Beijing Redflag Chinese 2000 Software Co., Ltd.
    Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
    Beijing Economic-Technological Development Area
    100176 Beijing - P.R.China
    
    北京红旗中文贰仟软件技术有限公司
    地址:北京经济技术开发区(亦庄)西环南路18号汇龙森A座二层
    邮编:100176
    
    电话/Tel: +86-10-51570010 ext.6183
    邮箱/e-mail: peterjunge@RedOffice.com
    http://www.RedOffice.com
    
    
    


  • 2.  Re: [office] Feature under evaluation at Redflag 2000

    Posted 10-14-2009 10:00
    On Wednesday 14. October 2009 10.31.05 ext Peter Junge wrote:
    > 2) Considering such feature seems to be quite obvious, as well it is
    > quite easy to add, hence I would like to know if there is a telling
    > argument, why it hasn't made it into ODF yet?
    
    The solution KWord always used for this is using a new draw:frame which holds 
    a text document with a table.
    I'd argue that thats a better way to solve this issue than adding a feature to 
    the tables.
    
    If you try out KWord you will notice that frames are actually more powerful 
    than you can see in implementations like OOo. There are settings like auto-
    growing of a frame and min/max sizes etc.
    
    I'd suggest perusing the placement of a frame anchored to a page with a text 
    document and a table in it. Modularity is what makes ODF great :)
    -- 
    Thomas Zander
    
    


  • 3.  Re: [office] Feature under evaluation at Redflag 2000

    Posted 10-19-2009 08:31
    Hi Thomas,
    
    Thomas Zander wrote:
    > On Wednesday 14. October 2009 10.31.05 ext Peter Junge wrote:
    >> 2) Considering such feature seems to be quite obvious, as well it is
    >> quite easy to add, hence I would like to know if there is a telling
    >> argument, why it hasn't made it into ODF yet?
    > 
    > The solution KWord always used for this is using a new draw:frame which holds 
    > a text document with a table.
    
    I have been playing around with KWord. Using draw:frame seems to be the 
    preferred method for embedding objects. Right?
    
    > I'd argue that thats a better way to solve this issue than adding a feature to 
    > the tables.
    
    Well, yes and no, we have a similar discussion at Redflag 2000. Of 
    course, using draw:frame generalizes the embedding of objects. On the 
    other hand one could argue the position of the table should be a 
    property set of the table itself, but outsourcing it to a container 
    object increases ambiguity.
    
    > 
    > If you try out KWord you will notice that frames are actually more powerful 
    > than you can see in implementations like OOo. There are settings like auto-
    > growing of a frame and min/max sizes etc.
    
    The consistent use of draw:frame eases at least the implementation of 
    embedded objects, when looking at it from the user interface 
    perspective. However, it is certainly arguable, that other use cases 
    might become more complicated when 'hiding' native objects within 
    draw:frame, for example automated processing of ODF and also 
    interoperability with file formats, that do not know this concept.
    
    > 
    > I'd suggest perusing the placement of a frame anchored to a page with a text 
    > document and a table in it. Modularity is what makes ODF great :)
    
    Yes, this would also be the main argument for me to leave things as they 
    are, to use only one method. Defining similar sets of attributes for 
    positioning of all kind of objects would certainly blow up the extent of 
    the ODF spec, as well might be hard and error-prone to maintain.
    
    Thanks a lot for commenting.
    
    Best regards,
    Peter
    
    -- 
    Peter Junge
    Open Source Strategy Director
    
    Beijing Redflag Chinese 2000 Software Co., Ltd.
    Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
    Beijing Economic-Technological Development Area
    100176 Beijing - P.R.China
    
    北京红旗中文贰仟软件技术有限公司
    地址:北京经济技术开发区(亦庄)西环南路18号汇龙森A座二层
    邮编:100176
    
    电话/Tel: +86-10-51570010 ext.6183
    邮箱/e-mail: peterjunge@RedOffice.com
    http://www.RedOffice.com
    


  • 4.  ODF Next proposal "Floating Table Positioning" - Was: [office] Featureunder evaluation at Redflag 2000

    Posted 10-26-2009 08:30
    Dear TC members,
    
    please find the "Floating Table Positioning" proposal for ODF Next 
    attached as ODF document and below in plain text, mainly drafted by my 
    colleague Hua Shuran.
    
    We will also add the document to the wiki soon.
    
    Best regards,
    Peter
    
    Summary
    =======
    
    Proposal by:
    ------------
    Shuran Hua, huashuran@redoffice.com
    
    Proposal short name:
    --------------------
    Floating Table Positioning
    
    Abstract:
    ---------
    This proposal introduces absolute positioning properties for tables, 
    strongly similar to those of 


  • 5.  Re: [office] ODF Next proposal "Floating Table Positioning" - Was:[office] Feature under evaluation at Redflag 2000

    Posted 10-26-2009 16:45
    
    
      
    
    
    Peter, Shuran,

    Just scanned through this proposal.  Assuming that the floating table behaves the same as "normal" tables, my biggest concerns from an accessibility perspective are:
    • How does a tool that exports ODF to some other format (e.g. DAISY) know where to place the table within the overall flow of the document?
    • How does someone navigate to within the table for editing it without using the mouse?
    You note below: "Accessibility should be handled in the same way as with other shapes."  I suggest that with respect to keyboard operability, that is not a good plan.  Editing shapes that are floating within a page requires a different keyboard navigation scheme, which then brings up an editor, etc. etc. (kinda like tables within a presentation file). I suggest that we could address both of the two bullet points above in the same way - that "placement within the document flow" is the same as "keyboard navigation flow", such that arrowing downward through a document text would at some point reach into the floating table, and then eventually come out of the floating table and into the document - in the same "place" for document flow purposes when exported to DAISY (or HTML for that matter, which doesn't have a "floating table" concept unless implemented with something like iframes).


    Regards,

    Peter Korn
    Accessibility Architect & Principal Engineer,
    Sun Microsystems, Inc.

    4AE55DE9.8050802@RedOffice.com" type="cite">Dear TC members,

    please find the "Floating Table Positioning" proposal for ODF Next attached as ODF document and below in plain text, mainly drafted by my colleague Hua Shuran.

    We will also add the document to the wiki soon.

    Best regards,
    Peter

    Summary
    =======

    Proposal by:
    ------------
    Shuran Hua, huashuran@redoffice.com

    Proposal short name:
    --------------------
    Floating Table Positioning

    Abstract:
    ---------
    This proposal introduces absolute positioning properties for tables, strongly similar to those of <draw:frame>, please refer ODF 1.2, CD02, section 9.4.2.
    http://www.oasis-open.org/committees/download.php/32431/OpenDocument-v1.2-cd02.odt

    Rationale
    =========

    Use cases:
    ----------
    Floating tables are tables in a document which are not part of the main text flow, rather they are absolutely positioned on a specific page allowin users increased flexibility for the layout of their documents.
    Adding the feature will also increase interoperability with both UOF and OOXML, as they already know similar features.

    Alternatives considered:
    ------------------------
    None.

    Requested changes to the ODF Standard
    =====================================

    Text changes/additions:
    -----------------------
    1) Add certain new properties to 16.7 <style:table-properties> as following (with text added in orange):

    16.7 <style:table-properties>
        …
    The <style:table-properties> element has the following attributes:
    … table:display 18.404, draw:z-index 17.235, style:horizontal-pos 18.288, style:horizontal-rel 18.289, style:vertical-pos 18.385, style:vertical-rel 18.386, svg:x 18.399, svg:y 18.400 and style:allowoverlap 18.424.
        …

    2) Update the references in sections 17.235 draw:z-index, 18.288 style:horizontal-pos, 18.289 style:horizontal-rel, 18.385 style:vertical-pos, 18.386 style:vertical-rel, 18.399 svg:x and 18.400 svg:y.
    Exemplary the changes for 17.235 draw:z-index (with text added in orange):

    17.235 draw:z-index
    The draw:z-index attribute defines a rendering order for shapes and tables in a document instance. Shapes are rendered in the order in which they appear in the document in the absence of this attribute. As the attribute of  the <style:table-properties>, draw:z-index is used to mark the layers of each table when the value of style:allowoverlap attribute is set to true
        attribute-draw:z-index
    The draw:z-index attribute is usable with the following elements: <dr3d:cube>, [...], <draw:regular-polygon>, <office:annotation> and <style:table-properties>.
    The draw:z-index attribute has the data type nonNegativeInteger.

    3) Add section 18.424  style:allowoverlap:

    18.424  style:allowoverlap
    The style:allowoverlap attribute specifies whether the current object shall allow other objects to overlap its extents when the objects are displayed in a document. This attribute can have a value of true or false.
    If true, then no adjustment shall be made to prevent objects whose properties would normally cause them to overlap from overlapping when displayed.
    If false, then the objects shall be adjusted as needed to prevent them from overlapping when displayed by adjusting the floating objects properties as needed.
    The default value for this attribute is false.
    The style:allowoverlap attribute is usable with the following element: <style:table-properties> 16.7.
    The style:allowoverlap attribute has the data type boolean.

    Note: The above given section numbers are regarding “OpenDocument-v1.2-cd02.odt”
    http://www.oasis-open.org/committees/download.php/32431/OpenDocument-v1.2-cd02.odt

    Schema changes/additions:
    -------------------------
    Add the following definitions (text added in orange) in “OpenDocument-schema-v1.2-cd02.rng”:
    http://www.oasis-open.org/committees/download.php/32433/OpenDocument-schema-v1.2-cd02.rng.zip
    17640<define name="style-table-properties-attlist" combine="interleave">
    17641<ref name="common-background-color-attlist"/>
    17642</define>
    17643<define name="style-table-properties-attlist" combine="interleave">
    17644    <optional>
    17645        <attribute name="style:horizontal-pos">
    17646            <choice>
    17647                <value>left</value>
    17648                <value>center</value>
    17649                <value>right</value>
    17650                <value>from-left</value>
    17651                <value>inside</value>
    17652                <value>outside</value>
    17653                <value>from-inside</value>
    17654            </choice>
    17655        </attribute>
    17656    </optional>
    17657    <optional>
    17658        <attribute name="svg:x">
    17659            <ref name="coordinate"/>
    17660        </attribute>
    17661    </optional>
    17662</define>
    17663<define name="style-table-properties-attlist" combine="interleave">
    17664    <optional>
    17665        <attribute name="style:horizontal-rel">
    17666            <choice>
    17667                <value>page</value>
    17668                <value>page-content</value>
    17669                <value>page-start-margin</value>
    17670                <value>page-end-margin</value>
    17671                <value>frame</value>
    17672                <value>frame-content</value>
    17673                <value>frame-start-margin</value>
    17674                <value>frame-end-margin</value>
    17675                <value>paragraph</value>
    17676                <value>paragraph-content</value>
    17677                <value>paragraph-start-margin</value>
    17678                <value>paragraph-end-margin</value>
    17679                <value>char</value>
    17680            </choice>
    17681        </attribute>
    17682    </optional>
    17683</define>
    17684<define name="style-table-properties-attlist" combine="interleave">
    17685    <ref name="common-vertical-pos-attlist"/>
    17686</define>
    17687<define name="style-table-properties-attlist" combine="interleave">
    17688    <ref name="common-vertical-rel-attlist"/>
    17689</define>
    17690<define name="style-table-properties-attlist" combine="interleave">
    17691    <ref name="common-allowoverlap-attlist"/>
    17692</define>
    17693<define name="common-allowoverlap-attlist" combine="interleave">
    17694    <optional>
    17695        <attribute name="style:allowoverlap">
    17696            <ref name="boolean"/>
    17697        </attribute>
    17698    </optional>
    17699</define>
    17700<define name="style-table-properties-attlist" combine="interleave">
    17701    <ref name="common-draw-z-index-attlist"/>
    17702</define>

    Impacts
    =======

    Conformance:
    ------------
    Does this proposal add any mandatory features or behaviors to ODF documents or applications?
    This feature should be mandatory for all products implementing 'ODF Next'.

    Backwards compatibility:
    ------------------------
    If we make this change, what will be the impact on existing ODF processors?
    Existing ODF processors are expected to ignore the floating table positioning feature.

    Accessibility impact:
    ---------------------
    Will this feature require review by the Accessibility Subcommittee? For example, does it add structure to the document that can be navigated, store a user-viewable string or associate a label with content?
    Accessibility should be handled in the same way as with other shapes.

    Workflow (to be filled in by TC Chairs)
    =======================================

    Category: CategoryNewProposal
    Date Proposal initially made:
    Dates Proposal discussed on TC calls:
    Date vote is requested:
    Date vote is held:
    Results of vote:



    Peter Junge wrote:
    Dear TC members,

    our team at Redflag 2000 is currently evaluating a feature related to tables in word processors, we call 'Floating Table Positioning'. So far, tables cannot be absolutely positioned in ODF text documents, except they are embedded in a "draw:frame" element, please refer section 9.4.2 in ODF 1.2, Part 1, CD03[1]. Other document standards, namely OOXML (section 17.4.60 tblPr, Part 1, ISO 29500, Page 484) and UOF support absolute positioning of tables in text documents, quite similar to "draw:frame" in ODF, so we would like to submit a proposal that adds this feature in order to increase interoperability.

    Consequently, I would like to raise two questions:

    1) Is any TC member already working on a similar feature?

    2) Considering such feature seems to be quite obvious, as well it is quite easy to add, hence I would like to know if there is a telling argument, why it hasn't made it into ODF yet?

    Best regards,
    Peter

    [1] http://www.oasis-open.org/committees/download.php/33633/OpenDocument-v1.2-part1-cd03.odt



    --------------------------------------------------------------------- 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



  • 6.  Re: [office] ODF Next proposal "Floating Table Positioning" - Was:[office] Feature under evaluation at Redflag 2000

    Posted 10-28-2009 04:23
    Hi Peter,
    
    sorry for not replying yesterday. I just wanted to wait until my 
    transition form corporate to individual member of the TC is finished.
    
    Peter Korn wrote:
    >   Peter, Shuran,
    > 
    > Just scanned through this proposal.  Assuming that the floating table 
    > behaves the same as "normal" tables, my biggest concerns from an 
    > accessibility perspective are:
    > 
    >     * How does a tool that exports ODF to some other format (e.g. DAISY)
    >       know where to place the table within the overall flow of the document?
    
    I think this is handled on application level, but not with ODF. 
    Applications implementing ODF should certainly manage the appropriate 
    position of absolutely positioned tables and export it to DAISY. This is 
    already possible for