Re: Codegen directory structure
Baaah, sorry. Looks like I misunderstood you. You meant src/codegen, of course, not build/codegen. Sorry for the noise. On 21.12.2006 21:16:51 Jeremias Maerki wrote: > 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. Jeremias Maerki
Re: Codegen directory structure
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: > 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
Re: Codegen directory structure
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: 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
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
Re: Codegen directory structure
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? Regards, Jan - Original Message - From: "Manuel Mall" <[EMAIL PROTECTED]> To: Sent: Thursday, December 21, 2006 1:12 PM Subject: Re: Codegen directory structure On Thursday 21 December 2006 18:53, Manuel Mall wrote: On Thursday 21 December 2006 18:44, Vincent Hennebert wrote: > Manuel Mall a écrit : > > Also I didn't get any response to the question if we could/should > > store the needed Unicode data files in the Apache repository. > > Where do these files come from? Have they been modified? Do they > have license headers? > Also, that question might go to [EMAIL PROTECTED] See http://www.unicode.org/Public/UNIDATA/. The FOP UAX#14 implementation needs the files PropertyValueAliases.txt and LineBreak.txt for its code generation. Forget about it I changed the code generation code to accept URLs and it can read the Unicode data files directly from the Unicode site now. The license bits just looked too hard. > Vincent Manuel Manuel
Re: Codegen directory structure
On Thursday 21 December 2006 18:53, Manuel Mall wrote: > On Thursday 21 December 2006 18:44, Vincent Hennebert wrote: > > Manuel Mall a écrit : > > > > > > Also I didn't get any response to the question if we could/should > > > store the needed Unicode data files in the Apache repository. > > > > Where do these files come from? Have they been modified? Do they > > have license headers? > > Also, that question might go to [EMAIL PROTECTED] > > See http://www.unicode.org/Public/UNIDATA/. The FOP UAX#14 > implementation needs the files PropertyValueAliases.txt and > LineBreak.txt for its code generation. > Forget about it I changed the code generation code to accept URLs and it can read the Unicode data files directly from the Unicode site now. The license bits just looked too hard. > > Vincent > > Manuel Manuel
Re: Codegen directory structure
On Thursday 21 December 2006 18:44, Vincent Hennebert wrote: > Manuel Mall a écrit : > > Also I didn't get any response to the question if we could/should > > store the needed Unicode data files in the Apache repository. > > Where do these files come from? Have they been modified? Do they have > license headers? > Also, that question might go to [EMAIL PROTECTED] See http://www.unicode.org/Public/UNIDATA/. The FOP UAX#14 implementation needs the files PropertyValueAliases.txt and LineBreak.txt for its code generation. > Vincent Manuel
Re: Codegen directory structure
Manuel Mall a écrit : > I am wondering how/where I should put the UAX#14 code generation java > source and data files in our repository. > > The obvious choice is the existing codegen directory. But it contains > all the font codegen stuff at the top level which I don't want to mix > with the Unicode stuff. So what I would like to do is to move all the > font stuff one level down in the structure, e.g. to a new > codegen/fonts, and then create a codegen/unicode. Has anyone a problem > with that? May be there is another solution? I am open to suggestions. Note that the codegen directory also contains other stuff (color keywords, fo properties, etc.). But cleaning up that directory a bit by creating subdirectories wouldn't hurt, IMO. So no pb for me. > Also I didn't get any response to the question if we could/should store > the needed Unicode data files in the Apache repository. Where do these files come from? Have they been modified? Do they have license headers? Also, that question might go to [EMAIL PROTECTED] Vincent
