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?
