Namespaces for fop extensions

[Manuel Mall <ma...@apache.org>]

I wonder if we should agree on some guidelines for the use of namespaces 
(namespace prefixes) for extensions. I am thinking along the following 
lines:

The namespace "http://xmlgraphics.apache.org/fop/extensions" (common 
prefix "fox") is reserved for generic extensions to FOP supported 
across all (e.g. if handled by layout) or most renderers.

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. That namespace name is 
formed by appending the common renderer acronym to the above generic 
extension namespace, e.g. 
http://xmlgraphics.apache.org/fop/extensions/pdf or 
http://xmlgraphics.apache.org/fop/extensions/pcl or 
http://xmlgraphics.apache.org/fop/extensions/afp. At the same time the 
usual prefix for those extensions would be just the renderer acronym.

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. 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" />. This may not be a good 
example but I hope it illustrates what I am trying to achieve.

Manuel

Re: Namespaces for fop extensions

[Jeremias Maerki <de...@jeremias-maerki.ch>]

On 06.05.2006 22:17:37 Simon Pepping wrote:
> On Sat, May 06, 2006 at 11:31:38PM +0800, Manuel Mall wrote:
> > I wonder if we should agree on some guidelines for the use of namespaces 
> > (namespace prefixes) for extensions. I am thinking along the following 
> > lines:
> > 
> > The namespace "http://xmlgraphics.apache.org/fop/extensions" (common 
> > prefix "fox") is reserved for generic extensions to FOP supported 
> > across all (e.g. if handled by layout) or most renderers.
> > 
> > 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. That namespace name is 
> > formed by appending the common renderer acronym to the above generic 
> > extension namespace, e.g. 
> > http://xmlgraphics.apache.org/fop/extensions/pdf or 
> > http://xmlgraphics.apache.org/fop/extensions/pcl or 
> > http://xmlgraphics.apache.org/fop/extensions/afp. At the same time the 
> > usual prefix for those extensions would be just the renderer acronym.
> 
> This sounds fine to me.

+1

> > 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. 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" />. This may not be a good 
> > example but I hope it illustrates what I am trying to achieve.
> 
> I see what you are trying to achieve. Wouldn't users find this
> overdone, and wonder why they cannot do with a single hint for all
> renderers? Or would a single hint just not work?

From a power-user's perspective the flexibility is welcome, especially
since not every renderer provides the same kind of conversion methods
and the same quality for each kind. For normal users, it may be overkill
and may only produce confusion, but on the other side, they may never
need that. Maybe we need both: fox and output-format-specific. The
renderers first inspect the fox hint and then look for a
renderer-specific hint.


Jeremias Maerki

Re: Namespaces for fop extensions

[Simon Pepping <sp...@leverkruid.eu>]

On Sat, May 06, 2006 at 11:31:38PM +0800, Manuel Mall wrote:
> I wonder if we should agree on some guidelines for the use of namespaces 
> (namespace prefixes) for extensions. I am thinking along the following 
> lines:
> 
> The namespace "http://xmlgraphics.apache.org/fop/extensions" (common 
> prefix "fox") is reserved for generic extensions to FOP supported 
> across all (e.g. if handled by layout) or most renderers.
> 
> 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. That namespace name is 
> formed by appending the common renderer acronym to the above generic 
> extension namespace, e.g. 
> http://xmlgraphics.apache.org/fop/extensions/pdf or 
> http://xmlgraphics.apache.org/fop/extensions/pcl or 
> http://xmlgraphics.apache.org/fop/extensions/afp. At the same time the 
> usual prefix for those extensions would be just the renderer acronym.

This sounds fine to me.

> 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. 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" />. This may not be a good 
> example but I hope it illustrates what I am trying to achieve.

I see what you are trying to achieve. Wouldn't users find this
overdone, and wonder why they cannot do with a single hint for all
renderers? Or would a single hint just not work?

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: Namespaces for fop extensions

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Glen, you're almost suggesting we have an evil agenda which we use to
make certain things red or blue depending on the renderer. ;-) That's
certainly not the idea behing the extension properties. They are
suggested as a means to tweak the renderer's behaviour, sometimes to
work around a limitation of an implementation. I'll give you a concrete
example:

The PCL Renderer has a rudimentary Graphics2D implementation. It's not
possible without massive effort to paint a complex SVG graphic natively
in HP GL/2 which is used by PCL for graphical elements. Barcodes
generated by Barcode4J, however, are easily painted correctly using the
Graphics2D implementation.

If you use the fox: prefix to tell FOP to render the SVG graphic as a
bitmap it applies to every renderer and if you only activate that by an
XSLT parameter you make the XSL-FO renderer-specific, while the
renderer-specific extension property would still leave the whole XSL-FO
file as such independant of the FO processor or renderer that it is
ultimatively processed with.

Anyway, your post made Manuel and I discuss over IM about the whole
thing and we agree that the extension properties may not be the best
solution for the problems we're trying to solve here. Configuring the
renderers and XMLHandlers accordingly to specify the expected behaviour
would probably be better. We're going to look into this and will try to
make it better. Still, I can imagine that the extension properties will
come handy for certain situations. Especially for power-users, this
might still offer certain benefits. BTW, if you look into the
documentation of commercial implementations you will actually find
references to renderer-specific extensions (sometimes as processing
instructions, sometimes as extension elements or attributes). So that
argument against extension attributes is not quite valid. Look at it
this way: They don't change the behaviour of the document, they give
hints to the processor so the document is produced as expected in every
environment without compromising the portability. And portability is
probably one of the major problems of XSL-FO in the first place.

Thanks for your input!

On 08.05.2006 06:11:35 Glen Mazza wrote:
> > 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



Jeremias Maerki