On 12.05.2006 09:50:01 mm wrote:
> > Simon Pepping wrote:
> >
> <snip/>
> >>
> >> 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.

Agreed.

> 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.

Agreed.

> 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.

Uhm, actually we could have a standard XSL-FO API (if I understand you
correctly), at least for Java, if we took my JAXG proposal, gathered
support from other FO processors and started a JSR to standardize it.
However, you will only be able to define a subset of all features as a
standard in such a wrapper API. The functionality offered by the various
tools vary enormously. I have neglected this thing a little lately. I
guess I should do some cleanup and publish an updated version because
I've made quite some detail improvements compared to the published
version.

> 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.

Agreed.

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

Agreed.

> 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
> OK.

Here's where I'm uneasy about a detail. fox:media-type suggest an
abstract name for a media type which needs to be mapped later on. I
believe it's simpler to just use the master-name which is already
available and easily fits the requirements to serve as an abstract media
type name.

I'd like to try to sum up what we get out of this thread in addition to
your summary:
- My mapping idea is probably overkill. We should try to keep things at
a minimum and only expand if there's real need. AFAIK, the PostScript
infrastructure is good enough for now and a simple extension attribute
for PCL should be enough to select the paper source using the effective
integer value for the device-specific tray. What this means for AFP, I
cannot tell, yet. Such a simple way of controlling the media selection
is certainly within the scope of FOP IMO.
- My idea with having the engine configuration in the FO file in
addition to the programmatically supplied one is probably overkill, too.

Derived from the above, here's what I'm going to do:
- I'll implement the extension attribute on simple-page-master for PCL
so the user can specify the effective paper tray which he has to figure
out himself. The attribute will be optional, of course.
- Nothing else in this area for the moment. If additional requirements
come up I'll deal with that when it's time.


Jeremias Maerki

Reply via email to