xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From m.@arcus.com.au
Subject Re: Media or paper tray selection in FOP
Date Fri, 12 May 2006 07:50:01 GMT
> Simon Pepping wrote:
>> Regarding a configuration file per printing run, recently a similar
>> possibility was put forward for the user preferences for
>> printer-specific image handling and other options. In a recent
>> fop-user post I suggested the idea of hyphenation exceptions in a
>> configuration file.
> I agree hyphenation exceptions should belong in a configuration file. I
> would imagine that once the exceptions have been worked out they will
> remain constant for a long time and will not change between documents,
> like media selection can.

Although I had some offline IM discussions with Jeremias on this topic I
have kept quiet so far just observing how things are moving.

However, I now feel the need to comment from a developers point of view,
i.e. a developer who uses fop in high volume backend business processes.

If I would have to deal with creating per document config files that would
simply be a nightmare. IMO anything that is likely to need configuration
on a per document basis need to be either with the document (e.g. fo
extensions) or settable via an API but it should not be required to be in
a config file.

Regarding the dislike of extensions voiced here I am not so concerned with
XSL-FO purity. In my observations XSL-FO is very rarely used as the raw
data interchange format. Most enviroments use a combination of custom XML
inputs and custom XSL stylesheets and the actual fo file is hardly ever
seen. Just look in the fop-user list - most people submit XML/XSL snippets
and only after explicit prompting do we get the actual fo.

Therefore as a developer if I need to use a feature outside of XSL-FO,
e.g. media selection, I have to use what ever the actual fo processor
provides. This means I have to make changes when I switch between XEP /
RenderX / FOP for example. My first preference here would be to just have
to adapt the XSL and leave the rest unchanged. Obviously because we don't
have a standard XSL-FO API I have to change code as well. However, once I
have a wrapper in place which allows me to plug-in different FO processors
there should not be a need to even change that.

So a simplified summary of my view:

1. Put into the config file everything that is expected to be fixed within
a typical XSL-FO processing environment and yes, having a small number of
different config files is fine as well.

2. Put into extensions anything that is typically managed per document and
likely to be different between documents.

And yes there will be grey areas and yes having some abstraction / mapping
between generic values in an fo extension and specific values in a config
file is fine with me. For example if we have <simple-page-master ...
fox:media-type="xxx" /> and then in the config file entries which map
"xxx" to some media selection specific data per renderer that should be

> Chris


View raw message