Me, too. In that case, I'd prefer not to place the generated sources under the build directory since this is, for me, strictly a temporary, build-related directory.
However, a quick glance indicates that the data files are distributed under a very liberal license [1] which would allow us to put them in our codebase allowing code generation like we do for code points and fonts. Of course, we have to take a closer inspection here. [1] http://www.unicode.org/copyright.html On 21.12.2006 15:31:39 jcumps wrote: > Thank you, Manuel. > > > Also, this is not part of the normal build. The generated file will be > > in SVN and need only be regenerated by the FOP developers if the > > Unicode standard changes. > > When I received the first mail, I was thinking that this was a runtime > dependency. > > Regards, Jan > > > > ----- Original Message ----- > From: "Manuel Mall" <[EMAIL PROTECTED]> > To: <fop-dev@xmlgraphics.apache.org> > Sent: Thursday, December 21, 2006 3:19 PM > Subject: Re: Codegen directory structure > > > > On Thursday 21 December 2006 22:49, [EMAIL PROTECTED] wrote: > >> Manuel, > >> > >> > ... I changed the code generation code to accept URLs and it > >> > can read the Unicode data files directly from the Unicode site now. > >> > >> Would that work if the machine that's running fop doesn't have access > >> to the internet? > >> Or can the code also read the files from a local folder? > >> > > As it uses a URL stream reader it can read local files as well > > (file:///...). > > > > Also, this is not part of the normal build. The generated file will be > > in SVN and need only be regenerated by the FOP developers if the > > Unicode standard changes. > > > > The generator may also be used by really experienced users who need a > > modified custom line breaking pairs table (and in turn a custom FOP > > version) for their needs. > > > >> Regards, Jan > >> > > > > Manuel Jeremias Maerki
