As there have been no objections, I'll press ahead with this. From those who have expressed interest in getting involved, is there anyone who would like to start by integrating my Options.java into the maintenance branch and trunk. The changes are fairly extensive.

Peter

Peter B. West wrote:

I think that the reading of the userconfig file should be an option in the system config file. The example userconfig is a null file (everything is commented out), so the system config file could be changed to refer to it without doing any damage, unless the user changes the distributed user config and does *not* want it read. From memory, the current code searches for the userconfig file in user-relative places. If this is changed to search firstly in user-relative, then in system-relative places, it would give the user the option to change the distributed user config file in place, or to copy it to user space and modify it there. This is what I've implemented in my own code, and it certainly makes my testing a lot easier. In that code, a command line option specifying a user config will override the specification in the system config. The other thing that would probably be useful in that situation is a command line switch to turn off user config altogether.

Peter

Thorsten Daum wrote:

Hi,

...


Thanks, I had seen that, but I had missed that I had to implicitely include the config file when using FOP stand-alone, e.g., ./fop.sh -c conf/userconfig.xml, so originally I didn't pursue this avenue further.



1. How do I configure this when using FOP with Cocoon2? After all, FOP just comes as a JAR file with Cocoon. I did unjar fop-0.20.3rc.jar, added the 'strokeSVG' entry to conf/userconfig.xml and re-jarred it. However, the change does not take effect. It seems I have to implicitely tell FOP to use userrconfig.xml. How do I do that when FOP is invoked by Cocoon?








Reply via email to