OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

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


Subject: Re: [oic] Advisory 00007 - Table Rows / Table Columns


On Thu, 2011-10-06 at 22:29 -0600, Dennis E. Hamilton wrote:
> I went back to ODF 1.0 to find out what this is about.  I didn't
> figure out how it works for <table:table-columns> but when I looked at
> <table:table-rows> I notice that these groups can have their own
> headers, and they are definitely considered "grouped."

How do you get that these groups can have their own headers?

In ODF 1.0 in 8.2.4 you have: 

A table must not contain more than one
<table:table-header-rows> element, and a <table:table-rows> must not
follow another <table:table-rows> element. The only exception are tables
that contain grouped rows (see 8.2.5). Such tables contain more than one
<table:table-header-rows> element, provided that they are contained in
different row groups and the rows contained in the elements are
adjacent.

Note that the "grouping" of rows does not happen with table:table-rows
but with table:table-row-group.

> 
> Now, in many arrangements with nested groups, it is desirable to
> repeat the group headers for any group that is split across pages.


Which group headers?

Andreas

> 
> I suspect that there is some sort of intended control over how group
> headings are repeated or not.  There is also an interesting situation
> where most of a group is hidden (leaving a heading and a summary line
> for example).  There could also be a widows-orphans control desired in
> such cases too (i.e., whether to do a page break to keep the rows of a
> group together, or not).
> 
> These are all user-related observations.  Whether and how this sort of
> thing was meant to be incorporated in how groups are paginated is not
> evident in an initial pass on the material -- too much tacit
> knowledge, not enough specification.  
> 
> I don't know if there is any way to check against an implementation
> for confirmation of any of this.
> 
>  - Dennis E. Hamilton

-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta



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