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?
