You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2012/09/19 13:22:20 UTC
[Bug 53902] New: Add scope to header table cell
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
Priority: P2
Bug ID: 53902
Assignee: fop-dev@xmlgraphics.apache.org
Summary: Add scope to header table cell
Severity: normal
Classification: Unclassified
OS: All
Reporter: vhennebert@gmail.com
Hardware: All
Status: NEW
Version: all
Component: pdf
Product: Fop
In XSL-FO, header table cells (fo:table-cell elements that descend from an
fo:table-header/footer object) inherently encompass a column of the table. This
is due to the way tables are broken down into fo:table-header, fo:table-body
and fo:table-footer.
There is no XSL-FO construct to say that a table-cell is a header cell
encompassing a /row/ of the table. It can be achieved graphically by e.g.,
using a bold font for the first cell of a row, but the structure won't reflect
that.
This becomes a problem when creating accessible PDF documents, where it is
desirable to store the scope of a header in the logical structure. PDF defines
the standard Scope attribute for that (see Section 10.7.5 of the PDF 1.5
Reference).
I propose to add an extension property to fo:table-cell in order to convey that
information. Along with setting the 'role' property to 'TH', it would become
possible to define a cell as being a header cell with a scope of Row. Something
like this:
<fo:table-cell role="TH" fox:scope="Row">
...
</fo:table-cell>
The fox:scope property would have an enumerated value of 'Column' (default),
'Row' or 'Both'.
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [Bug 53902] New: Add scope to header table cell
Posted by Glenn Adams <gl...@skynav.com>.
On Tue, Oct 2, 2012 at 6:21 PM, Chris Bowditch
<bo...@hotmail.com>wrote:
> On 29/09/2012 08:07, Glenn Adams wrote:
>
> My issue is our assigning a standard semantics to an XSL-FO property that
>> is absent of standard semantics. I would prefer we use a new, fox namespace
>> attribute.
>>
>
> I believe Vincent did decide to use fox:header attribute in the end as
> suggested by Pascal. Use role and an fox attribute seemed overcomplicated
> and Pascal's suggestion was a good one.
>
In that case (not using role attribute), please proceed, and thanks for the
good work Vincent!
Re: [Bug 53902] New: Add scope to header table cell
Posted by Chris Bowditch <bo...@hotmail.com>.
On 29/09/2012 08:07, Glenn Adams wrote:
Hi Glenn,
> My issue is our assigning a standard semantics to an XSL-FO property
> that is absent of standard semantics. I would prefer we use a new, fox
> namespace attribute.
I believe Vincent did decide to use fox:header attribute in the end as
suggested by Pascal. Use role and an fox attribute seemed
overcomplicated and Pascal's suggestion was a good one.
Thanks,
Chris
>
> On Sat, Sep 29, 2012 at 12:37 AM, Vincent Hennebert
> <vhennebert@gmail.com <ma...@gmail.com>> wrote:
>
> Sorry for the delay.
>
> On 20/09/12 19:36, Glenn Adams wrote:
> > On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert
> <vhennebert@gmail.com <ma...@gmail.com>>wrote:
> >
> >> On 20/09/12 02:05, Glenn Adams wrote:
> >>> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
> >>>
> <snip/>
> >>>>> In XSL-FO, header table cells (fo:table-cell elements that
> descend from
> >>>> an
> >>>>> fo:table-header/footer object) inherently encompass a column
> of the
> >>>> table. This
> >>>>> is due to the way tables are broken down into fo:table-header,
> >>>> fo:table-body
> >>>>> and fo:table-footer.
> >>>>>
> >>>>> There is no XSL-FO construct to say that a table-cell is a
> header cell
> >>>>> encompassing a /row/ of the table. It can be achieved
> graphically by
> >>>> e.g.,
> >>>>> using a bold font for the first cell of a row, but the
> structure won't
> >>>> reflect
> >>>>> that.
> >>>>>
> >>>>> This becomes a problem when creating accessible PDF
> documents, where it
> >>>> is
> >>>>> desirable to store the scope of a header in the logical
> structure. PDF
> >>>> defines
> >>>>> the standard Scope attribute for that (see Section 10.7.5 of
> the PDF
> >> 1.5
> >>>>> Reference).
> >>>>>
> >>>>> I propose to add an extension property to fo:table-cell in
> order to
> >>>> convey that
> >>>>> information. Along with setting the 'role' property to 'TH',
> it would
> >>>> become
> >>>>> possible to define a cell as being a header cell with a
> scope of Row.
> >>>> Something
> >>>>> like this:
> >>>>> <fo:table-cell role="TH" fox:scope="Row">
> >>>>> ...
> >>>>> </fo:table-cell>
> >>>>>
> >>>>> The fox:scope property would have an enumerated value of
> 'Column'
> >>>> (default),
> >>>>> 'Row' or 'Both'.
> >>>>
> >>>>
> >>> my only suggestion would be to use lower case only when
> specifying values
> >>> for these attributes, and also 'TH' should be expanded to an
> english
> >> word,
> >>> like 'head' or 'header'; also, i'm not sure why two attributes are
> >> needed,
> >>> when one fox attribute could do the job
> >>
> >> The ‘role’ property can be used not just by fo:table-cell, but
> also for
> >> any other element in order to override the default mapping to a PDF
> >> structure type. Its value should be a standard structure type
> as listed
> >> in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use
> >> plain English words instead but I prefer to leave things this
> way to
> >> avoid confusion and keep the code simple.
> >>
> >
> > I don't like using the XSL-FO 'role' property for this special
> purpose
> > (i.e., a mapping to a PDF structure type). XSL-FO suggests that
> the value
> > of role be a QName or RDF URI about "the role of the [pre-XSLT]
> element[s]
> > that were used to construct [the] formatting object".
>
> All of the standard structure types listed in the PDF Reference appear
> to be QNames, so this remains within the scope defined by the XSL-FO
> spec.
>
> Maybe there is a slight abuse of the property in the sense that its
> value might not actually match the name of the element from which the
> formatting object is derived. But it is a semantic value anyway,
> providing valuable information to alternate renderers. So I reckon
> that
> the spirit of the law has been followed.
>
> We could instead use RDF resources and define a mapping of those RDF
> resources to a PDF structure type, but that seems completely
> overkill to
> me.
>
>
> > This property provides a hint for alternate renderers (aural
> readers, etc.)
> > as to the role of the XML element or elements that were used to
> construct
> > this formatting object, if one could be identified during XSLT tree
> > construction. This information can be used to prepare alternate
> renderings
> > when the normal rendering of a formatting object is not
> appropriate or
> > satisfactory; for example, the role information can be used to
> provide
> > better aural renderings of visually formatted material.
> >
> > To aid alternate renderers, the <string> value should be the
> qualified name
> > (QName [XML Names]
> <http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES>
> > or [XML Names
> 1.1]<http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES11>)
> > of the element from which this formatting object is constructed.
> If a QName
> > does not provide sufficient context, the <uri-specification> can
> be used to
> > identify an RDF resource that describes the role in more detail.
> This RDF
> > resource may be embedded in the result tree and referenced with
> a relative
> > URI or fragment identifier, or the RDF resource may be external
> to the
> > result tree. This specification does not define any standard
> QName or RDF
> > vocabularies; these are frequently application area dependent. Other
> > groups, for example the Dublin Core, have defined such vocabularies.
> > It does not say anything about using this to specify a mapping
> to a PDF
> > Structure.
> >
> > I guess the scope could be coded in the ‘role’ property,
> something like
> >> ‘TH-Row’, but again, I’d like to keep the code simple. Also, it
> seems
> >> more XSL-FO idiomatic to me to define the scope in a separate
> property.
> >>
>
> Vincent
>
>
Re: [Bug 53902] New: Add scope to header table cell
Posted by Glenn Adams <gl...@skynav.com>.
My issue is our assigning a standard semantics to an XSL-FO property that
is absent of standard semantics. I would prefer we use a new, fox namespace
attribute.
On Sat, Sep 29, 2012 at 12:37 AM, Vincent Hennebert <vh...@gmail.com>wrote:
> Sorry for the delay.
>
> On 20/09/12 19:36, Glenn Adams wrote:
> > On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert <
> vhennebert@gmail.com>wrote:
> >
> >> On 20/09/12 02:05, Glenn Adams wrote:
> >>> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
> >>>
> <snip/>
> >>>>> In XSL-FO, header table cells (fo:table-cell elements that descend
> from
> >>>> an
> >>>>> fo:table-header/footer object) inherently encompass a column of the
> >>>> table. This
> >>>>> is due to the way tables are broken down into fo:table-header,
> >>>> fo:table-body
> >>>>> and fo:table-footer.
> >>>>>
> >>>>> There is no XSL-FO construct to say that a table-cell is a header
> cell
> >>>>> encompassing a /row/ of the table. It can be achieved graphically by
> >>>> e.g.,
> >>>>> using a bold font for the first cell of a row, but the structure
> won't
> >>>> reflect
> >>>>> that.
> >>>>>
> >>>>> This becomes a problem when creating accessible PDF documents, where
> it
> >>>> is
> >>>>> desirable to store the scope of a header in the logical structure.
> PDF
> >>>> defines
> >>>>> the standard Scope attribute for that (see Section 10.7.5 of the PDF
> >> 1.5
> >>>>> Reference).
> >>>>>
> >>>>> I propose to add an extension property to fo:table-cell in order to
> >>>> convey that
> >>>>> information. Along with setting the 'role' property to 'TH', it would
> >>>> become
> >>>>> possible to define a cell as being a header cell with a scope of Row.
> >>>> Something
> >>>>> like this:
> >>>>> <fo:table-cell role="TH" fox:scope="Row">
> >>>>> ...
> >>>>> </fo:table-cell>
> >>>>>
> >>>>> The fox:scope property would have an enumerated value of 'Column'
> >>>> (default),
> >>>>> 'Row' or 'Both'.
> >>>>
> >>>>
> >>> my only suggestion would be to use lower case only when specifying
> values
> >>> for these attributes, and also 'TH' should be expanded to an english
> >> word,
> >>> like 'head' or 'header'; also, i'm not sure why two attributes are
> >> needed,
> >>> when one fox attribute could do the job
> >>
> >> The ‘role’ property can be used not just by fo:table-cell, but also for
> >> any other element in order to override the default mapping to a PDF
> >> structure type. Its value should be a standard structure type as listed
> >> in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use
> >> plain English words instead but I prefer to leave things this way to
> >> avoid confusion and keep the code simple.
> >>
> >
> > I don't like using the XSL-FO 'role' property for this special purpose
> > (i.e., a mapping to a PDF structure type). XSL-FO suggests that the value
> > of role be a QName or RDF URI about "the role of the [pre-XSLT]
> element[s]
> > that were used to construct [the] formatting object".
>
> All of the standard structure types listed in the PDF Reference appear
> to be QNames, so this remains within the scope defined by the XSL-FO
> spec.
>
> Maybe there is a slight abuse of the property in the sense that its
> value might not actually match the name of the element from which the
> formatting object is derived. But it is a semantic value anyway,
> providing valuable information to alternate renderers. So I reckon that
> the spirit of the law has been followed.
>
> We could instead use RDF resources and define a mapping of those RDF
> resources to a PDF structure type, but that seems completely overkill to
> me.
>
>
> > This property provides a hint for alternate renderers (aural readers,
> etc.)
> > as to the role of the XML element or elements that were used to construct
> > this formatting object, if one could be identified during XSLT tree
> > construction. This information can be used to prepare alternate
> renderings
> > when the normal rendering of a formatting object is not appropriate or
> > satisfactory; for example, the role information can be used to provide
> > better aural renderings of visually formatted material.
> >
> > To aid alternate renderers, the <string> value should be the qualified
> name
> > (QName [XML Names] <
> http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES>
> > or [XML Names 1.1]<
> http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES11>)
> > of the element from which this formatting object is constructed. If a
> QName
> > does not provide sufficient context, the <uri-specification> can be used
> to
> > identify an RDF resource that describes the role in more detail. This RDF
> > resource may be embedded in the result tree and referenced with a
> relative
> > URI or fragment identifier, or the RDF resource may be external to the
> > result tree. This specification does not define any standard QName or RDF
> > vocabularies; these are frequently application area dependent. Other
> > groups, for example the Dublin Core, have defined such vocabularies.
> > It does not say anything about using this to specify a mapping to a PDF
> > Structure.
> >
> > I guess the scope could be coded in the ‘role’ property, something like
> >> ‘TH-Row’, but again, I’d like to keep the code simple. Also, it seems
> >> more XSL-FO idiomatic to me to define the scope in a separate property.
> >>
>
> Vincent
>
Re: [Bug 53902] New: Add scope to header table cell
Posted by Vincent Hennebert <vh...@gmail.com>.
Sorry for the delay.
On 20/09/12 19:36, Glenn Adams wrote:
> On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert <vh...@gmail.com>wrote:
>
>> On 20/09/12 02:05, Glenn Adams wrote:
>>> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
>>>
<snip/>
>>>>> In XSL-FO, header table cells (fo:table-cell elements that descend from
>>>> an
>>>>> fo:table-header/footer object) inherently encompass a column of the
>>>> table. This
>>>>> is due to the way tables are broken down into fo:table-header,
>>>> fo:table-body
>>>>> and fo:table-footer.
>>>>>
>>>>> There is no XSL-FO construct to say that a table-cell is a header cell
>>>>> encompassing a /row/ of the table. It can be achieved graphically by
>>>> e.g.,
>>>>> using a bold font for the first cell of a row, but the structure won't
>>>> reflect
>>>>> that.
>>>>>
>>>>> This becomes a problem when creating accessible PDF documents, where it
>>>> is
>>>>> desirable to store the scope of a header in the logical structure. PDF
>>>> defines
>>>>> the standard Scope attribute for that (see Section 10.7.5 of the PDF
>> 1.5
>>>>> Reference).
>>>>>
>>>>> I propose to add an extension property to fo:table-cell in order to
>>>> convey that
>>>>> information. Along with setting the 'role' property to 'TH', it would
>>>> become
>>>>> possible to define a cell as being a header cell with a scope of Row.
>>>> Something
>>>>> like this:
>>>>> <fo:table-cell role="TH" fox:scope="Row">
>>>>> ...
>>>>> </fo:table-cell>
>>>>>
>>>>> The fox:scope property would have an enumerated value of 'Column'
>>>> (default),
>>>>> 'Row' or 'Both'.
>>>>
>>>>
>>> my only suggestion would be to use lower case only when specifying values
>>> for these attributes, and also 'TH' should be expanded to an english
>> word,
>>> like 'head' or 'header'; also, i'm not sure why two attributes are
>> needed,
>>> when one fox attribute could do the job
>>
>> The ‘role’ property can be used not just by fo:table-cell, but also for
>> any other element in order to override the default mapping to a PDF
>> structure type. Its value should be a standard structure type as listed
>> in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use
>> plain English words instead but I prefer to leave things this way to
>> avoid confusion and keep the code simple.
>>
>
> I don't like using the XSL-FO 'role' property for this special purpose
> (i.e., a mapping to a PDF structure type). XSL-FO suggests that the value
> of role be a QName or RDF URI about "the role of the [pre-XSLT] element[s]
> that were used to construct [the] formatting object".
All of the standard structure types listed in the PDF Reference appear
to be QNames, so this remains within the scope defined by the XSL-FO
spec.
Maybe there is a slight abuse of the property in the sense that its
value might not actually match the name of the element from which the
formatting object is derived. But it is a semantic value anyway,
providing valuable information to alternate renderers. So I reckon that
the spirit of the law has been followed.
We could instead use RDF resources and define a mapping of those RDF
resources to a PDF structure type, but that seems completely overkill to
me.
> This property provides a hint for alternate renderers (aural readers, etc.)
> as to the role of the XML element or elements that were used to construct
> this formatting object, if one could be identified during XSLT tree
> construction. This information can be used to prepare alternate renderings
> when the normal rendering of a formatting object is not appropriate or
> satisfactory; for example, the role information can be used to provide
> better aural renderings of visually formatted material.
>
> To aid alternate renderers, the <string> value should be the qualified name
> (QName [XML Names] <http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES>
> or [XML Names 1.1]<http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES11>)
> of the element from which this formatting object is constructed. If a QName
> does not provide sufficient context, the <uri-specification> can be used to
> identify an RDF resource that describes the role in more detail. This RDF
> resource may be embedded in the result tree and referenced with a relative
> URI or fragment identifier, or the RDF resource may be external to the
> result tree. This specification does not define any standard QName or RDF
> vocabularies; these are frequently application area dependent. Other
> groups, for example the Dublin Core, have defined such vocabularies.
> It does not say anything about using this to specify a mapping to a PDF
> Structure.
>
> I guess the scope could be coded in the ‘role’ property, something like
>> ‘TH-Row’, but again, I’d like to keep the code simple. Also, it seems
>> more XSL-FO idiomatic to me to define the scope in a separate property.
>>
Vincent
Re: [Bug 53902] New: Add scope to header table cell
Posted by Glenn Adams <gl...@skynav.com>.
On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert <vh...@gmail.com>wrote:
> On 20/09/12 02:05, Glenn Adams wrote:
> > On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
> >
> >> I’ve started to work on this. Any feedback about the proposed extension
> >> from any interested party will be most welcome.
> >>
> >> Thanks,
> >> Vincent
> >>
> >> On 19/09/12 12:22, bugzilla@apache.org wrote:
> >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
> >>>
> >>> Priority: P2
> >>> Bug ID: 53902
> >>> Summary: Add scope to header table cell
> >>>
> >>> In XSL-FO, header table cells (fo:table-cell elements that descend from
> >> an
> >>> fo:table-header/footer object) inherently encompass a column of the
> >> table. This
> >>> is due to the way tables are broken down into fo:table-header,
> >> fo:table-body
> >>> and fo:table-footer.
> >>>
> >>> There is no XSL-FO construct to say that a table-cell is a header cell
> >>> encompassing a /row/ of the table. It can be achieved graphically by
> >> e.g.,
> >>> using a bold font for the first cell of a row, but the structure won't
> >> reflect
> >>> that.
> >>>
> >>> This becomes a problem when creating accessible PDF documents, where it
> >> is
> >>> desirable to store the scope of a header in the logical structure. PDF
> >> defines
> >>> the standard Scope attribute for that (see Section 10.7.5 of the PDF
> 1.5
> >>> Reference).
> >>>
> >>> I propose to add an extension property to fo:table-cell in order to
> >> convey that
> >>> information. Along with setting the 'role' property to 'TH', it would
> >> become
> >>> possible to define a cell as being a header cell with a scope of Row.
> >> Something
> >>> like this:
> >>> <fo:table-cell role="TH" fox:scope="Row">
> >>> ...
> >>> </fo:table-cell>
> >>>
> >>> The fox:scope property would have an enumerated value of 'Column'
> >> (default),
> >>> 'Row' or 'Both'.
> >>
> >>
> > my only suggestion would be to use lower case only when specifying values
> > for these attributes, and also 'TH' should be expanded to an english
> word,
> > like 'head' or 'header'; also, i'm not sure why two attributes are
> needed,
> > when one fox attribute could do the job
>
> The ‘role’ property can be used not just by fo:table-cell, but also for
> any other element in order to override the default mapping to a PDF
> structure type. Its value should be a standard structure type as listed
> in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use
> plain English words instead but I prefer to leave things this way to
> avoid confusion and keep the code simple.
>
I don't like using the XSL-FO 'role' property for this special purpose
(i.e., a mapping to a PDF structure type). XSL-FO suggests that the value
of role be a QName or RDF URI about "the role of the [pre-XSLT] element[s]
that were used to construct [the] formatting object".
This property provides a hint for alternate renderers (aural readers, etc.)
as to the role of the XML element or elements that were used to construct
this formatting object, if one could be identified during XSLT tree
construction. This information can be used to prepare alternate renderings
when the normal rendering of a formatting object is not appropriate or
satisfactory; for example, the role information can be used to provide
better aural renderings of visually formatted material.
To aid alternate renderers, the <string> value should be the qualified name
(QName [XML Names] <http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES>
or [XML Names 1.1]<http://www.w3.org/TR/2006/REC-xsl11-20061205/#XMLNAMES11>)
of the element from which this formatting object is constructed. If a QName
does not provide sufficient context, the <uri-specification> can be used to
identify an RDF resource that describes the role in more detail. This RDF
resource may be embedded in the result tree and referenced with a relative
URI or fragment identifier, or the RDF resource may be external to the
result tree. This specification does not define any standard QName or RDF
vocabularies; these are frequently application area dependent. Other
groups, for example the Dublin Core, have defined such vocabularies.
It does not say anything about using this to specify a mapping to a PDF
Structure.
I guess the scope could be coded in the ‘role’ property, something like
> ‘TH-Row’, but again, I’d like to keep the code simple. Also, it seems
> more XSL-FO idiomatic to me to define the scope in a separate property.
>
Re: [Bug 53902] New: Add scope to header table cell
Posted by Vincent Hennebert <vh...@gmail.com>.
On 20/09/12 02:05, Glenn Adams wrote:
> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
>
>> I’ve started to work on this. Any feedback about the proposed extension
>> from any interested party will be most welcome.
>>
>> Thanks,
>> Vincent
>>
>> On 19/09/12 12:22, bugzilla@apache.org wrote:
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
>>>
>>> Priority: P2
>>> Bug ID: 53902
>>> Summary: Add scope to header table cell
>>>
>>> In XSL-FO, header table cells (fo:table-cell elements that descend from
>> an
>>> fo:table-header/footer object) inherently encompass a column of the
>> table. This
>>> is due to the way tables are broken down into fo:table-header,
>> fo:table-body
>>> and fo:table-footer.
>>>
>>> There is no XSL-FO construct to say that a table-cell is a header cell
>>> encompassing a /row/ of the table. It can be achieved graphically by
>> e.g.,
>>> using a bold font for the first cell of a row, but the structure won't
>> reflect
>>> that.
>>>
>>> This becomes a problem when creating accessible PDF documents, where it
>> is
>>> desirable to store the scope of a header in the logical structure. PDF
>> defines
>>> the standard Scope attribute for that (see Section 10.7.5 of the PDF 1.5
>>> Reference).
>>>
>>> I propose to add an extension property to fo:table-cell in order to
>> convey that
>>> information. Along with setting the 'role' property to 'TH', it would
>> become
>>> possible to define a cell as being a header cell with a scope of Row.
>> Something
>>> like this:
>>> <fo:table-cell role="TH" fox:scope="Row">
>>> ...
>>> </fo:table-cell>
>>>
>>> The fox:scope property would have an enumerated value of 'Column'
>> (default),
>>> 'Row' or 'Both'.
>>
>>
> my only suggestion would be to use lower case only when specifying values
> for these attributes, and also 'TH' should be expanded to an english word,
> like 'head' or 'header'; also, i'm not sure why two attributes are needed,
> when one fox attribute could do the job
The ‘role’ property can be used not just by fo:table-cell, but also for
any other element in order to override the default mapping to a PDF
structure type. Its value should be a standard structure type as listed
in Section 10.7.5 of the PDF 1.5 Reference. We could imagine to use
plain English words instead but I prefer to leave things this way to
avoid confusion and keep the code simple.
I guess the scope could be coded in the ‘role’ property, something like
‘TH-Row’, but again, I’d like to keep the code simple. Also, it seems
more XSL-FO idiomatic to me to define the scope in a separate property.
Thanks,
Vincent
Re: [Bug 53902] New: Add scope to header table cell
Posted by Glenn Adams <gl...@skynav.com>.
On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert <vh...@gmail.com>wrote:
> I’ve started to work on this. Any feedback about the proposed extension
> from any interested party will be most welcome.
>
> Thanks,
> Vincent
>
> On 19/09/12 12:22, bugzilla@apache.org wrote:
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
> >
> > Priority: P2
> > Bug ID: 53902
> > Summary: Add scope to header table cell
> >
> > In XSL-FO, header table cells (fo:table-cell elements that descend from
> an
> > fo:table-header/footer object) inherently encompass a column of the
> table. This
> > is due to the way tables are broken down into fo:table-header,
> fo:table-body
> > and fo:table-footer.
> >
> > There is no XSL-FO construct to say that a table-cell is a header cell
> > encompassing a /row/ of the table. It can be achieved graphically by
> e.g.,
> > using a bold font for the first cell of a row, but the structure won't
> reflect
> > that.
> >
> > This becomes a problem when creating accessible PDF documents, where it
> is
> > desirable to store the scope of a header in the logical structure. PDF
> defines
> > the standard Scope attribute for that (see Section 10.7.5 of the PDF 1.5
> > Reference).
> >
> > I propose to add an extension property to fo:table-cell in order to
> convey that
> > information. Along with setting the 'role' property to 'TH', it would
> become
> > possible to define a cell as being a header cell with a scope of Row.
> Something
> > like this:
> > <fo:table-cell role="TH" fox:scope="Row">
> > ...
> > </fo:table-cell>
> >
> > The fox:scope property would have an enumerated value of 'Column'
> (default),
> > 'Row' or 'Both'.
>
>
my only suggestion would be to use lower case only when specifying values
for these attributes, and also 'TH' should be expanded to an english word,
like 'head' or 'header'; also, i'm not sure why two attributes are needed,
when one fox attribute could do the job
Re: [Bug 53902] New: Add scope to header table cell
Posted by Vincent Hennebert <vh...@gmail.com>.
I’ve started to work on this. Any feedback about the proposed extension
from any interested party will be most welcome.
Thanks,
Vincent
On 19/09/12 12:22, bugzilla@apache.org wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
>
> Priority: P2
> Bug ID: 53902
> Summary: Add scope to header table cell
>
> In XSL-FO, header table cells (fo:table-cell elements that descend from an
> fo:table-header/footer object) inherently encompass a column of the table. This
> is due to the way tables are broken down into fo:table-header, fo:table-body
> and fo:table-footer.
>
> There is no XSL-FO construct to say that a table-cell is a header cell
> encompassing a /row/ of the table. It can be achieved graphically by e.g.,
> using a bold font for the first cell of a row, but the structure won't reflect
> that.
>
> This becomes a problem when creating accessible PDF documents, where it is
> desirable to store the scope of a header in the logical structure. PDF defines
> the standard Scope attribute for that (see Section 10.7.5 of the PDF 1.5
> Reference).
>
> I propose to add an extension property to fo:table-cell in order to convey that
> information. Along with setting the 'role' property to 'TH', it would become
> possible to define a cell as being a header cell with a scope of Row. Something
> like this:
> <fo:table-cell role="TH" fox:scope="Row">
> ...
> </fo:table-cell>
>
> The fox:scope property would have an enumerated value of 'Column' (default),
> 'Row' or 'Both'.
>
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #1 from Pascal Sancho <ps...@gmail.com> ---
IIUC, that feature aims to have a pseudo-table-header laterally rather than
above/below.
If this is the case, so IMHO a such extension should apply on column (or
better, on column-group).
For that, I can imagine 2 options:
- add a new fox:xxx attribute to column-group, with possible values like
"header-start" or "footer-end".
- add new extensions elements like
fox:column-group-header/fox:column-group-footer/fox:column-group-body
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
Vincent Hennebert <vh...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Vincent Hennebert <vh...@gmail.com> ---
Documentation updated on the CMS website.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #7 from Pascal Sancho <ps...@gmail.com> ---
(In reply to comment #6)
> I was able to implement the modified design within the allocated time frame:
> http://svn.apache.org/viewvc?rev=1390412&view=rev
>
> Thanks for your excellent suggestion!
>
> Will close the bug once I've updated the documentation on the website.
>
> Vincent
Good job, Vincent.
Such extension could be usefull too if one would implement i-p-d splitting for
tables, as repeating column header over pages would become feasible.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #3 from Pascal Sancho <ps...@gmail.com> ---
Hmm,
In PDF 1.5 spec, TH seems exist as a workaround to the limitation of the html
table model, from witch the tagged PDF table-model seems to be inspired.
As I said, such table model describe a stacked rows structure, and there is no
mechanism to describe alternative structure, where 1st column can be handled as
header.
Note that the "TH" scope value could be determined from the "grandfather" of
the fo:table-cell (table-header), and/or, if implemented, the nature of the
corresponding column or column group (header/footer column-group).
IMHO, there is no need to use a table-cell role attribute for that.
Personally, I don't use tagged PDF, but sometimes I'm facing to the lake of
"vertical" headers in FO table model, and I think that here, the End-user need
is having such feature, rather than an html/TH-like tweak, breaking the table
structure.
And your schema illustrates perfectly what I say ;)
*all* "row headers" are in the same column...
And you have a cell header for each row, so with a cell implementation, you
have to repeat the action on each row, while with a column implementation, you
repeat it only once.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #5 from Pascal Sancho <ps...@gmail.com> ---
(In reply to comment #4)
> (In reply to comment #3)
> I like this idea a lot, however the time I have allocated on this is running
> low. I'll see if I can modify my current implementation to do this.
> So fo:table-column would take an extension property fox:header being either
> true or false (the default).
Well, I'm happy with this table-column extension.
I would prefer a table-column-group, but that FO doesn't exist in current
XSL-FO 1.1 REC, and it is not planned in 2.0 working draft.
So, if nobody else objects, I follow you to add table-column/@fox:header
extension.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #6 from Vincent Hennebert <vh...@gmail.com> ---
I was able to implement the modified design within the allocated time frame:
http://svn.apache.org/viewvc?rev=1390412&view=rev
Thanks for your excellent suggestion!
Will close the bug once I've updated the documentation on the website.
Vincent
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #2 from Vincent Hennebert <vh...@gmail.com> ---
(In reply to comment #1)
> IIUC, that feature aims to have a pseudo-table-header laterally rather than
> above/below.
> If this is the case, so IMHO a such extension should apply on column (or
> better, on column-group).
> For that, I can imagine 2 options:
> - add a new fox:xxx attribute to column-group, with possible values like
> "header-start" or "footer-end".
> - add new extensions elements like
> fox:column-group-header/fox:column-group-footer/fox:column-group-body
It is true that header cells having a row scope are usually all in the same
column (typically the leftmost column). Something like this:
__________________________________________________
| | | |
| Table Header | Column Header 1 | Column Header 2 |
|______________|_________________|_________________|
| | | |
| Row Header 1 | body | body |
|______________|_________________|_________________|
| | | |
| Row Header 2 | body | body |
|______________|_________________|_________________|
| | | |
| Row Header 3 | body | body |
|______________|_________________|_________________|
I guess you mean that the first column should have a status of header. While
this may be interesting information, what I'm trying to achieve is a bit
different: just have a way to say that 'Row Header 1' should be a TH cell
encompassing the row it is in. While 'Column Header 1' is a TH cell
encompassing its column. There is a standard way to record that in PDF by
associating a Scope structure attribute to the corresponding structure type.
That information can then be transmitted in some way by a screen reader, to
help the user to build a mental representation of the table. However, there is
no standard way in PDF to record the fact that a column is made of header cells
(while this is possible for a (group of) row(s), using the THead structure
type). So it's probably not worth implementing that in FOP.
Does that make sense?
Vincent
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53902] Add scope to header table cell
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53902
--- Comment #4 from Vincent Hennebert <vh...@gmail.com> ---
(In reply to comment #3)
> Hmm,
> In PDF 1.5 spec, TH seems exist as a workaround to the limitation of the
> html table model, from witch the tagged PDF table-model seems to be inspired.
> As I said, such table model describe a stacked rows structure, and there is
> no mechanism to describe alternative structure, where 1st column can be
> handled as header.
> Note that the "TH" scope value could be determined from the "grandfather" of
> the fo:table-cell (table-header), and/or, if implemented, the nature of the
> corresponding column or column group (header/footer column-group).
Hmmm. That makes a lot of sense. Actually the structure type of cells that
descend from a table-header is already automatically determined this way. We
could extend that mechanism to 'header' columns. A cell that is in such a
column would be given a structure type of TH with a scope or Row; A cell that
is also inside an fo:table-header would be given a scope of Both. That would
avoid manually setting role and fox:scope on every cell of the header column.
I like this idea a lot, however the time I have allocated on this is running
low. I'll see if I can modify my current implementation to do this.
So fo:table-column would take an extension property fox:header being either
true or false (the default).
WDYT?
> IMHO, there is no need to use a table-cell role attribute for that.
> Personally, I don't use tagged PDF, but sometimes I'm facing to the lake of
> "vertical" headers in FO table model, and I think that here, the End-user
> need is having such feature, rather than an html/TH-like tweak, breaking the
> table structure.
> And your schema illustrates perfectly what I say ;)
> *all* "row headers" are in the same column...
> And you have a cell header for each row, so with a cell implementation, you
> have to repeat the action on each row, while with a column implementation,
> you repeat it only once.
Thanks for your feedback!
Vincent
--
You are receiving this mail because:
You are the assignee for the bug.