On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert <vhenneb...@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, bugzi...@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.
>

Reply via email to