xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Mazza <gma...@apache.org>
Subject Re: Namespaces for fop extensions
Date Mon, 08 May 2006 04:11:35 GMT
> Manuel Mall wrote:

> Extensions specific to a particular renderer and / or extensions which
> constitute a rendering hint (e.g. render this image as a grayscale)
> should be in a renderer specific namespace. 

-0.5.  I would be more comfortable with the idea of renderer-specific 
formatting objects and properties if the XSL specification had some 
itself, but so far the XSL SG has (strictly) avoided defining any.  I am 
unaware of the commercial implementations going in this direction either.

As far as the XSL specification is concerned, while some FO's/properties 
are defined for printed paper only, some for hearing only, and some for 
screen output only (fo:multi-switch for example), nothing is defined 
with respect to a specific renderer.  I would think, then, with a little 
more effort the fox extensions created could likewise be done 
generically, without respect to specific renderers but just to the type 
of output:  aural/paper/screen, etc.


> Even if the same type of rendering hint can be used by different
> renderers they still should be in separate namespaces as this allows
> the user control over behaviour on a per renderer basis without
> changing the fo file. 

I think what you're saying here defeats the purpose of XSL:  it is a 
specification for a document that is *independent* of the renderer type. 
  You may be opening up a can of worms, if for the same XSL document, 
properties exist that would result in, say, a PDF document having a red 
background and a PCL document having a blue background.  This has never 
been the goal of XSL.

[Also, I think you'll be opening up a *barrel* of worms, if, in having 
renderer-specific *extension* properties, we now need to override 
regular XSL namespace properties just for the sake of providing 
renderer-specific styling.  (E.g., instead of font-size, now we have 
pdf:font-size, pcl:font-size, etc., etc.)  After all, it would not be 
just for FOP's *extension* FO's/properties that renderer-specific 
styling might be wanted, and if the goal is allow for different styling 
based on the renderer without needing to change the fo file, eventually 
you will have to override the fo: properties in addition to the fox: ones.]

If a user has a stylesheet that needs a little bit of tweaking between 
two different renderers, I think the main solution is to have the user's 
xslt handle that, perhaps by having the user pass in an xsl:param 
holding the renderer type, and then use xsl:choose, xsl:if, 
xsl:attribute, etc. with that param value to change the formatting 
objects/properties based on the renderer.


> For example lets assume we want to support image
> conversion hints which allows tuning of the image output format.
> Instead of having <fo:external-graphic
> fox:output-conversion="grayscale" src="xyz.png" /> I would recommend to
> use render specific hints like <fo:external-graphic
> afp:output-conversion="grayscale" pcl:output-conversion="bitmap"
> pdf:output-converion="jpeg" src="xyz.png" />. 

But what if you always want grayscale, independent of formatter?  In 
your example above, you would need to duplicate this same value three 
times (afp:, pcl:, pdf:) instead of just once (fox:).

Also, what if you choose another renderer outside of afp/pcl/pdf?  The 
grayscale would not be activated with a renderer outside your explicitly 
given list.  In this way you end up losing the "future-proofing" of the 
document that is another desired aspect of XSL.

But, one way around these two concerns is to still allow a fox:property 
wherever you would allow a pcl:property, afp:property, etc.  The value 
of fox:property would be used whereever a renderer-specific value was 
not specified.

> This may not be a good
> example but I hope it illustrates what I am trying to achieve.
> 

No, it was an excellent example for discussion.

Glen

Mime
View raw message