Hi Chris/Glenn/Anyone else, You say command-line options should override the fop.xconf values, which makes sense. But should not-given command-line options override fop.xconf values too? Bare with me here, there is sense in the folly of that sentence. Ok, so let's take the example above, with strict FO validation, from the command line you have two options:
1) fop -r ... <other args> or 2) fop ... <other args> Obviously in option 1, you'd want strict FO validation to be invoked, regardless of what's in the fop conf. But how do we treat option 2? We're not explicitly telling it NOT to validate strictly, so how would a user expect FOP to behave? On 4 July 2012 17:26, Chris Bowditch <bowditch_ch...@hotmail.com> wrote: > On 04/07/2012 17:15, Glenn Adams wrote: > >> >> On Wed, Jul 4, 2012 at 9:25 AM, mehdi houshmand <med1...@gmail.com<mailto: >> med1...@gmail.com>> wrote: >> >> On 4 July 2012 12:32, Vincent Hennebert <vhenneb...@gmail.com >> <mailto:vhenneb...@gmail.com>> wrote: >> >> >> There does seem to be a regression. Before, the >> FopFactoryConfigurator >> object was getting the strict-validation element from the >> config file >> and calling FopFactory.setStrictValidation if it was set to >> true. This >> is no longer the case. >> >> I’ve just tried to render a table with table-footer after >> table-body, >> and now a validation error is thrown even if I have >> strict-validation >> set to false in my config file. No validation error was thrown >> before. >> >> >> I've fixed the underlying issue but this is an interesting one; it >> isn't obvious that settings from the fop conf override the >> settings from the command line options. (Pete probably wrote this >> part hahaha ;) ) >> >> >> They shouldn't. Command line options should override the conf file. >> >> > Agreed, but IIUC, the team just copied the existing functionality due to > time constraints. We should probably log a bug to track that as an issue. > > Thanks, > > Chris > > >
