OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Diagonal Table Headers

    Posted 05-15-2009 09:33
    Dear TC members,
    
    as announced earlier this week, Redflag 2000 would like to submit a
    proposal about Diagonal (or Kite or Asian) Table Headers. The proposal
    is quite substantial, as we have been trying to take a semantic approach
    to the feature. ISO29500 keeps very brief on it (Part I - 17.4.74
    tl2br), while UOF adds some graphical lines with text to a table cell
    (range), which means IMHO emulating the feature with a 'borrowed' object
    type. RF2000 has been proposing this feature at OOo almost two years ago
    with a similar approach to UOF, see:
    http://wiki.services.openoffice.org/wiki/Image:Diagonal_Table_Header_Specification.odt
    Todays proposal is significantly different. The basic idea is to
    overcome the concept, that a table cell has to be rectangular. Hence, we
    copied most features of a 'cell as yet known', leaving away all the
    stuff, that is only reasonable to be used in a box concept. As a result,
    it is possible to calculate the content of diagonal table header cells
    in the same way, as used in rectangular cells. A feature we have been
    avoiding so far is to go the opposite way. Contents of diagonal table
    header cells cannot be used for calculations etc. in rectangular cells.
    We have been starting to think about this feature, but this would have
    blown up the proposal by multiple times. We think this extension can be
    added in a later step.
    
    To draft our proposal, we have been basing our work on ODF 1.2 CD01rev5.
    You will also find a modified schema attached, that has about 200 lines
    added.
    
    One concern I'd like to raise here. To illustrate the use cases, we have
    been scanning samples from a reference book about corporate forms and
    tables. Our draft is citing the source in a way, that would be legal to
    use in Germany, but I do not know, how this kind of use of copyrighted
    work is handled in the US. Hence, I would like to clarify this, before I
    copy the proposal to the wiki. Can anyone give me a hint?
    
    As mentioned in an earlier posting this week, Redflag 2000 would really
    appreciate feedback about this proposal, although review of new features
    should be intermitted during the current state of ODF 1.2. We want to
    design several more features during the next couple of months and need
    some feedback to learn, as we are an unexperienced team.
    
    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
    


  • 2.  Re: [office] Diagonal Table Headers

    Posted 05-15-2009 15:41



  • 3.  Re: [office] Diagonal Table Headers

    Posted 05-22-2009 03:09
    Dear Peter,
    
    nice to get in touch with you again. To recall, we have been meeting in
    person several years ago when you were visiting Sun's OOo team in
    Hamburg, also to work on accessibility back in those days.
    
    Peter Korn wrote:
    >  Dear Peter,
    > 
    > Thank you for sharing this proposal.  This proposal poses some
    > interesting challenges for accessibility.  The existing models for
    > conveying information about tables to assistive technologies -
    > retrieving the row & column header of a given cell - do not map well to
    > these diagonal headers.
    
    Yes, I was expecting this challenge. Another approach, we have been
    considering earlier at RF2000, is to map the content of the
    non-rectangular cells to hidden rectangular cells. Scenarios in OOo
    spreadsheets have a similar concept. That might be a way to resolve an
    unknown problem to a known one.
    
    > 
    > 
    > Excerpted image from proposal: sheet with a diagonal/kite cell in
    > upper-left of a table
    > with multiple, tiered row & column headers
    > 
    > The immediate challenges I see are:
    > 
    >    1. Keyboard navigation - how does a keyboard user navigate to the
    >       portion of the cell containing a particular label?
    
    Might also be easier with mappings to hidden, rectangular cells.
    
    >    2. How does a screen reader retrieve the portion of the sell
    >       containing a specific label in order to speak / Braille it?
    
    See above.
    
    >    3. What changes do we need to make in the accessibility API in order
    >       to accommodate this kind of labeling of row/column headers &
    >       subheaders?
    
    See above.
    
    > 
    > The first challenge above could perhaps be addressed by invoking a
    > dialog box, similar to the one used to insert it:
    > 
    > 
    > Excerpted image from proposal: "Insert Diagonal Tableheader" dialog box
    > 
    > This is perhaps reasonable for insertion, since that operation is done
    > rarely.  But for viewing it, a user could easily get lost trying to
    > remember that we are in "Style 5" which means the cell is divided into
    > three ways and that "Label 1" is labeling the column headers, "Label 2"
    > the content of the cells, and "Label 3" the row headers.  As there are
    > "14 diagonal header styles", this puts a very significant cognitive
    > burden on the user.
    
    I agree with your analysis here. However, I think this is more a
    challenge for implementers, rather than on file format level.
    
    > 
    > The second challenge above could come out of the the third in some
    > senses - tell the user what this is not because they have navigated to
    > it, but because they are on a cell labeled in this fashion by simply
    > reading them the associated label.  But I'm concerned that this wouldn't
    > be sufficient.  Especially because today we don't have encoded
    > information about the span to which a label applies, if I'm on cell G10
    > in the first image above - e.g. first row but beyond the end of the
    > filled-in table - then how does my screen reader know the diagonal/kite
    > header/label no longer applies?
    
    Good question. I totally agree, that the lack of bindings between
    diagonal header cells and content is a significant issue of the
    proposal. If you (or anyone else) has a good idea how to overcome this
    issue, it will be very welcomed.
    
    > 
    > 
    > I've cc-ed the rest of the ODF Accessibility TC, to get their
    > thoughts/feedback as well.
    
    This feedback would be really appreciated.
    
    Best regards,
    Peter
    
    
    
    
    > 
    > 
    >> Dear TC members,
    >>
    >> as announced earlier this week, Redflag 2000 would like to submit a
    >> proposal about Diagonal (or Kite or Asian) Table Headers. The proposal
    >> is quite substantial, as we have been trying to take a semantic approach
    >> to the feature. ISO29500 keeps very brief on it (Part I - 17.4.74
    >> tl2br), while UOF adds some graphical lines with text to a table cell
    >> (range), which means IMHO emulating the feature with a 'borrowed' object
    >> type. RF2000 has been proposing this feature at OOo almost two years ago
    >> with a similar approach to UOF, see:
    >> http://wiki.services.openoffice.org/wiki/Image:Diagonal_Table_Header_Specification.odt
    >> Todays proposal is significantly different. The basic idea is to
    >> overcome the concept, that a table cell has to be rectangular. Hence, we
    >> copied most features of a 'cell as yet known', leaving away all the
    >> stuff, that is only reasonable to be used in a box concept. As a result,
    >> it is possible to calculate the content of diagonal table header cells
    >> in the same way, as used in rectangular cells. A feature we have been
    >> avoiding so far is to go the opposite way. Contents of diagonal table
    >> header cells cannot be used for calculations etc. in rectangular cells.
    >> We have been starting to think about this feature, but this would have
    >> blown up the proposal by multiple times. We think this extension can be
    >> added in a later step.
    >>
    >> To draft our proposal, we have been basing our work on ODF 1.2 CD01rev5.
    >> You will also find a modified schema attached, that has about 200 lines
    >> added.
    >>
    >> One concern I'd like to raise here. To illustrate the use cases, we have
    >> been scanning samples from a reference book about corporate forms and
    >> tables. Our draft is citing the source in a way, that would be legal to
    >> use in Germany, but I do not know, how this kind of use of copyrighted
    >> work is handled in the US. Hence, I would like to clarify this, before I
    >> copy the proposal to the wiki. Can anyone give me a hint?
    >>
    >> As mentioned in an earlier posting this week, Redflag 2000 would really
    >> appreciate feedback about this proposal, although review of new features
    >> should be intermitted during the current state of ODF 1.2. We want to
    >> design several more features during the next couple of months and need
    >> some feedback to learn, as we are an unexperienced team.
    >>
    >> Best regards,
    >> Peter
    >>
    >>   
    >>  
    >> ---------------------------------------------------------------------
    >> 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 
    > 
    
    -- 
    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.  Re: [office] Diagonal Table Headers

    Posted 05-22-2009 06:43
    2009/5/22 Peter Junge 


  • 5.  Re: [office] Diagonal Table Headers

    Posted 05-15-2009 15:41



  • 6.  Re: [office] Diagonal Table Headers

    Posted 05-15-2009 21:21
    Hi Peter,
    
    Thanks for that contribution.  You and your team have obviously put a lot 
    of thought into this.
    
    I'll add this to JIRA so we can track it for ODF-Next.
    
    I need to read the use cases over, but it strikes me that we need to 
    carefully define both the abstract data model that is being represented, 
    as well as how it is presented.  The abstraction is especially for how we 
    model this in programmatic API's (like ODF Toolkit) and how we enable 
    navigation for screen readers and other assistive technologies.   Also, 
    since diagonal tables are not supported in some applications and even some 
    markups (like HTML) we should probably also define a canonical fall-back 
    rendering for how these tables should render in situations where diagonal 
    tables cells are not available.
    
    To your question on copyright, we would not be able to publish a standard 
    that contains scanned images from a book unless we had the publisher's 
    permission.  However, would it be possible to recreate similar examples in 
    RF, and take screen shots of those examples?
    
    Regards,
    
    -Rob
    
    
    Peter Junge 


  • 7.  Re: [office] Diagonal Table Headers

    Posted 05-22-2009 03:52
    Hi Rob,
    
    robert_weir@us.ibm.com wrote:
    > Hi Peter,
    > 
    > Thanks for that contribution.  You and your team have obviously put a lot 
    > of thought into this.
    
    Surely, but I hope we can even make it better, as it certainly has some
    deficits, as Peter Korn pointed out, for example.
    
    > 
    > I'll add this to JIRA so we can track it for ODF-Next.
    
    Thanks a lot. I guess I do not have to take any action with JIRA for the
    near future.
    
    > 
    > I need to read the use cases over, but it strikes me that we need to 
    > carefully define both the abstract data model that is being represented, 
    > as well as how it is presented.  The abstraction is especially for how we 
    > model this in programmatic API's (like ODF Toolkit) and how we enable 
    > navigation for screen readers and other assistive technologies.   Also, 
    > since diagonal tables are not supported in some applications and even some 
    > markups (like HTML) we should probably also define a canonical fall-back 
    > rendering for how these tables should render in situations where diagonal 
    > tables cells are not available.
    
    As pointed out in my mail to Peter Korn, the data model and
    accessibility issues might get resolved by mapping the content of the
    diagonal to regular (hidden) cells. This might also apply for the
    rendering fall-back. If the hidden cells, that keep the content of the
    diagonal cells, are appropriately positioned in relation to the content
    referred by the diagonal headers, simply exposing these hidden cells
    might offer a clean alternative rendering.
    
    > 
    > To your question on copyright, we would not be able to publish a standard 
    > that contains scanned images from a book unless we had the publisher's 
    > permission.  However, would it be possible to recreate similar examples in 
    > RF, and take screen shots of those examples?
    
    That's already solved. The illustrations in the proposal are no scans,
    but Ma Jun actually recreated them, exactly as you were proposing,
    because she couldn't get access to a scanner. That was my misunderstanding.
    
    Best regards,
    Peter
    
    
    
    > 
    > 
    > Peter Junge