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 Chris Bowditch <bo...@hotmail.com> on 2012/10/02 12:21:02 UTC
Re: [Bug 53902] New: Add scope to header table cell
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>.
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!