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