Sorry for the delay.

On 20/09/12 19:36, Glenn Adams wrote:
> On Thu, Sep 20, 2012 at 11:02 PM, Vincent Hennebert 
> <>wrote:
>> On 20/09/12 02:05, Glenn Adams wrote:
>>> On Thu, Sep 20, 2012 at 3:15 AM, Vincent Hennebert wrote:
>>>>> 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

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

> 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] <>
>  or [XML Names 1.1]<>)
> 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