Peter > >You'll have to create a GUI or use OS X. :-) Well, that leads me to the > >question: What are you actually trying to do? We're talking about > >solutions here, but not what you need them for (I think). > > > There's a very useful discussion going on about logging, Avalon, etc, > which covers this territory in more general terms. Anything that > rationalises and makes consistent and readily understandable the > invovation and setup of FOP will be a very good thing. I'm just talking > about the very limited aim of unifying and making more useful the > existing maintenance branch options/configuration code.
Advertising
Right, I got that. And I appreciate your effort in this. My problem is that I haven't yet seen the benefit of what you're trying to do. I really think which we should have a least a third opinion on this. > >>>I don't get you here. What do you need the language validation for? > >>> > >>For completeness. I can specify country, language and script, and these > >>may be acted upon in respect of hyphenation. Two situations may arise. > >> 1) That particular language/country/script may have no support in this > >>version of FOP. 2) There is no such language/country/script. When I'm > >>parsing one of these attributes, I like to be able to detect the second > >>situation at the point of parsing. > >> > > > >I'm lost. Sorry, but I really can't follow you. > > > My fault. In the middle of this discussion about options processing, I > came across the references to the language file in the config file, so I > dragged them in, kicking and screaming. "I can specify country.language > and script..." should read, "The user can specify country, language and > script..." as properties in the FO file that I'm processing. See 7.9.2 > "language", 7.9.1 "country", and 7.9.3 "script" in the Recommendation. > When I was looking at the parsing of such properties, I wanted to be > able to validate the element attributes immediately after they were > parsed by the expression parser. I either had to hard-code the lists, > or provide for a way of updating them outside the code, so I went for a > configuration file, pointed to by the the general config file. I see. Are those three not rather static so it would make sense to place the resource files with the classes and hard-code the validation code. That would make it simpler. Or do you see a case where you need to use a different validation file? If you code something like this I'd apreciate if validation could be switched of for performance reasons. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
