RE: FO 1.1 WD: missing pieces (?)

Julian,

Thank you for your interest in XSL FO.

The XSL FO SubGroup discussed your email requesting an 
enhancement about PDF links and document info.

Support of named destinations really requires no change 
to the XSL spec; it's more a question of how a given XSL FO 
implementation works, so the SG decided not to add anything 
to the XSL 1.1 spec for this.

We noticed that we could potentially write a Note on how
this might work in implementations that generate PDF, but
since this wouldn't impact the XSL 1.1 spec itself, and due
to lack of resources, we didn't get anyone to commit to do this.

We discussed document info but SG members felt this is really 
metadata, and we didn't want to use XSL FO's to represent this.
Something more like Dublin Core may be more suitable.

SG members agreed both capabilities were useful, but we decided
neither of them should result in changes to the XSL spec itself.

Paul Grosso
for the W3C XSL FO SG

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Julian Reschke
> Sent: Thursday, 20 May, 2004 5:27
> To: xsl-editors@w3.org
> Subject: FO 1.1 WD: missing pieces (?)
> 
> Hi,
> 
> I'm maintaining code that transforms RFC2629-style 
> ("xml2rfc") documents 
> to FO (<http://greenbytes.de/tech/webdav/rfc2629xslt.zip>). This code 
> historically used special cases to support various extensions 
> in Apache 
> FOP, AntennaHouse XSL Formatter and RenderX. Last week, I decided to 
> standardize on XSL 1.1 WD features, and to use 
> post-processing XSLTs to 
> generate the extensions for the various backends.
> 
> This works just fine for bookmarks and index generation 
> extensions (page 
> ranges etc.).
> 
> Two things are left that aren't covered in the current working draft; 
> maybe they should be considered.
> 
> 
> 1. Generating PDF destinations
> 
> Apache FOP has an extension for generating those 
> (<http://xml.apache.org/fop/extensions.html#named-destinations>). The 
> ability to produce them is of great importance if you want 
> identical URI 
> fragments to work for different media types with HTTP content 
> negotiation (such as 
> <http://example.com/rfc2518#rfc.section.1>, where 
> the actual mime type (HTML, PDF...) is selected based on the client's 
> accept header).
> 
> Note that this doesn't necessarily need to be any change to 
> the language 
> -- it would make perfect sense to generate a PDF destination for each 
> "id" attribute in the FO document. However, right now none of the 
> processors I'm aware of seems to do that.
> 
> 
> 2. Generating document information
> 
> RenderX supports adding document information to PDF output 
> (<http://xep.xattic.com/xep/doc/spec.html#Document_Information
> >). This 
> seems to be a both useful and trivial thing to do; it would 
> be nice if 
> there'd be a standard way to express this.
> 
> 
> Note that both features seem to be specific to PDF output. Maybe a 
> separate document for PDF output optimizations could cover this?
>

Received on Friday, 15 October 2004 20:08:23 UTC