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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>>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
