Codegen directory structure
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. Also I didn't get any response to the question if we could/should store the needed Unicode data files in the Apache repository. Manuel
Re: UAX#14 implementation
Nice work, Manuel! That will be a great addition to Fop. I have never studied the problem in detail, so I can only give a general opinion. But I think we should follow as closely as possible the Unicode standard, even if that leads to behaviors incompatible with the current one. It seems the Unicode standard is designed to nicely handle all sorts of high-level typographical issues. This would be great to be able to say Fop is Unicode compliant. And users can refer to a well-known, well-defined standard if they want to understand Fop's behavior or achieve special effects. So, by all means, go for it! Vincent Manuel Mall a écrit : On Wednesday 20 December 2006 20:43, Manuel Mall wrote: On Tuesday 19 December 2006 23:55, Manuel Mall wrote: snip/ Its looking OK so far and most of the layout engine tests pass. Just discovered the first instance of an existing testcase which gives a different result. Here is another one: The current FOP implementation treats spaces other than NBSP, e.g. U+2009 (Thin Space) and U+200A (Hair Space) as suppressible around line breaks. I believe that is incorrect as the spec explicitly limits whitespace handling to the normal space U+0020. The test case which shows that is block_white-space_4.xml. It tests for specific Knuth element sequences which are now different because these spaces are now treated as not suppressible. After making the appropriate adjustment to the checks in that testcase ALL testcases are now passing! snip/ 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
Re: A nit: visibility of FObj.bind()?
On Wed, Dec 20, 2006 at 07:55:26PM +0100, Andreas L Delmelle wrote: Hi all, Just bumped into this and started wondering: currently FObj.bind() has public visibility, but it seems that protected would suffice. The method is only accessed by processNode() (which is already a protected method), but since it needs to be overridden by subclasses, it cannot be made private. Simply wondering whether it would not be 'cleaner' to restrict the visibility to protected... unless it is really necessary for some reason to expose it as part of the public API of FObj? I guess it needs to be invoked after creating an FObj, so it should have the same visibility as the creator method. Simon -- Simon Pepping home page: http://www.leverkruid.eu
Re: Codegen directory structure
On Thursday 21 December 2006 18:44, Vincent Hennebert wrote: Manuel Mall a écrit : snip/ 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
On Thursday 21 December 2006 18:53, Manuel Mall wrote: On Thursday 21 December 2006 18:44, Vincent Hennebert wrote: Manuel Mall a écrit : snip/ 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
DO NOT REPLY [Bug 40798] - page-position=last doesn't work for 1 page document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40798. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40798 --- Additional Comments From [EMAIL PROTECTED] 2006-12-21 04:43 --- The problem is in ConditionalPageMasterReference.isValid(isOddPage, isFirstPage, isLastPage, isBlankPage), which says explicitly that a conditional pagemaster reference with page-position=last is not valid for a first page. I do not know at this moment if that is correct in view of the FO spec. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40695] - FO Basic link not working on line break
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40695. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40695 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2006-12-21 04:54 --- This works in FOP trunk and I am sure it works in FOP 0.92. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 40695] - FO Basic link not working on line break
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=40695. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=40695 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2006-12-21 05:04 --- Yes, the document is post-processed by Adobe Distiller. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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: fop-dev@xmlgraphics.apache.org 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 : snip/ 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 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
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
StrokeSVGText in the redesign branch
Guys, If I'm correct the StrokeSVGText is no longer available in the new codebase? Can I remove the paragraph [1] about it in the doc? [1] http://xmlgraphics.apache.org/fop/0.92/graphics.html#svg-pdf-text
Re: StrokeSVGText in the redesign branch
Vincent Hennebert wrote: Guys, If I'm correct the StrokeSVGText is no longer available in the new codebase? Can I remove the paragraph [1] about it in the doc? Hi Vincent, I believe you are correct. The code now makes the best decision about whether or not the text should be stroked in each circumstance. Of course, the code may not always make the decision the user wants but thats a different matter Chris
Barcode4J and Fop Trunk
(As you can see I'm currently checking the consistency of the documentation before releasing) On the Upgrading page [1] it is stated that The new FOP extension for Barcode4J will be available in January 2006. By quickly looking at the Barcode4J I haven't found any relevant information about that extension. What is its status? Should we simply replace 2006 with 2007 ;-) ? Vincent [1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html
Re: Barcode4J and Fop Trunk
Vincent Hennebert wrote: (As you can see I'm currently checking the consistency of the documentation before releasing) On the Upgrading page [1] it is stated that The new FOP extension for Barcode4J will be available in January 2006. By quickly looking at the Barcode4J I haven't found any relevant information about that extension. What is its status? Should we simply replace 2006 with 2007 ;-) ? Jeremias is the best person to answer this one, but the extension has been written. I believe the code for it lives in the Barcode4J respository. The JAR itself can be built from there, but I don't believe Jeremias ever got round to doing an official release of it. When I needed it he simply e-mailed it to me. Chris
DO NOT REPLY [Bug 41228] New: - Links on Compliance Page broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41228 Summary: Links on Compliance Page broken Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: documentation AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] The links on the compliance page (http://xmlgraphics.apache.org/fop/compliance.html) are broken. This happened probably on 05 December 2006, when the latest W3C Recommendation for XSL (Version 1.1) was put online. The Links need to be rewritten to point to the new destinations. Example: http://www.w3.org/TR/xsl/slice6.html#fo_root -- http://www.w3.org/TR/xsl11/#fo_root . Jan-Frederik Wilhelm -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41228] - Links on Compliance Page broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41228 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 41117] - ArrayIndexOutOfBoundsException if embed-url refers to XML file
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41117. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41117 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-12-21 11:49 --- Fixed in revision 489448. Thanks for reporting the problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Barcode4J and Fop Trunk
I've been working on a DataMatrix implementation for Barcode4J lately which is partly responsible for my lack of presence here. This work is almost finished and I plan to do an alpha release of Barcode4J 2.0 in the first week of January 2007. When I get this off my table I have more time left for FOP again. On 21.12.2006 17:09:47 Vincent Hennebert wrote: (As you can see I'm currently checking the consistency of the documentation before releasing) On the Upgrading page [1] it is stated that The new FOP extension for Barcode4J will be available in January 2006. By quickly looking at the Barcode4J I haven't found any relevant information about that extension. What is its status? Should we simply replace 2006 with 2007 ;-) ? Vincent [1] http://xmlgraphics.apache.org/fop/0.92/upgrading.html Jeremias Maerki
Re: StrokeSVGText in the redesign branch
Right. I wanted to reintroduce it one time to get back the fallback functionality. Just in case. Obviously, I didn't get to that... On 21.12.2006 17:04:24 Chris Bowditch wrote: Vincent Hennebert wrote: Guys, If I'm correct the StrokeSVGText is no longer available in the new codebase? Can I remove the paragraph [1] about it in the doc? Hi Vincent, I believe you are correct. The code now makes the best decision about whether or not the text should be stroked in each circumstance. Of course, the code may not always make the decision the user wants but thats a different matter Chris 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: 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
