DO NOT REPLY [Bug 32338] - Rendering fails with IndexOutOfBoundsException in CompoundPropertyMaker
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=32338. 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=32338 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-11-22 09:00 --- The property name 'space-before.minumum' is invalid. I've added a check for unknown subproperty names and a message to the error log. -- 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: Do we need an inherit enumeration constant?
[Glen] This is possibly a question for Finn, but if anyone knows: In our Constants.java [1], we don't have an property enumeration constant for inherit. (Go here [2], and search on inherit, you will see it listed in the Value: section for multiple properties.) Is there any reason why we don't need it, or did we just forget to add it to our Constants.java? It isn't needed as an enum value because the 'inherit' keyword takes precedence over the other enumeration values. See 5.9.11: The Keyword values take precedence over EnumerationToken. where Keyword is 'inherit'. The code to handle 'inherit' is at line 397 http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/properties/PropertyMaker.java?annotate=1.11 OTOH the code to deal with 'inherit' and the other enum values needs some changes to deal with optional white-space, so perhaps the parsing of enums should be passed to the PropertyParser and the 'inherit' test should be placed after the call to PropertyParser.parse(). In that case a INHERIT constant would be needed. regards, finn
RE: cvs commit: xml-fop/src/java/org/apache/fop/fo/pagination Root.java
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] 1.0's bookmarks are different from 0.20.5's, the former has fox:bookmarks as the parent element. It's been that way in 1.0 for a long time, before I came on board I believe. Yes, and it even has been discussed this summer. Silly me forgot to check the archives *before* changing and committing :-) I don't like the nomenclature we have in FOP 1.0 that much. fox:outline comes from the PDF specification's term for a bookmark, but the PDF spec calls it an outline item, and fox:bookmarks (parent level, holding all the outline items) IIRC is called a document outline in the PDF spec. I guess fox:bookmarks (top-level), and fox:bookmark(child elements) might be better, but better enough to warran switching what we currently have? I'm unsure. Well, some consistency would indeed look prettier, i.e. fox:bookmarks / fox:bookmark or fox:outlines / fox:outline or (more verbose) fox:document-outline / fox:outline-item But for now, I think I can live with it. Greetz, Andreas
Re: Do we need an inherit enumeration constant?
OK, I see, thanks. Glen - Original Message - From: Finn Bock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 22, 2004 2:22 AM Subject: Re: Do we need an inherit enumeration constant? [Glen] This is possibly a question for Finn, but if anyone knows: In our Constants.java [1], we don't have an property enumeration constant for inherit. (Go here [2], and search on inherit, you will see it listed in the Value: section for multiple properties.) Is there any reason why we don't need it, or did we just forget to add it to our Constants.java? It isn't needed as an enum value because the 'inherit' keyword takes precedence over the other enumeration values. See 5.9.11: The Keyword values take precedence over EnumerationToken. where Keyword is 'inherit'. The code to handle 'inherit' is at line 397 http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/fo/properties/PropertyMaker.java?annotate=1.11 OTOH the code to deal with 'inherit' and the other enum values needs some changes to deal with optional white-space, so perhaps the parsing of enums should be passed to the PropertyParser and the 'inherit' test should be placed after the call to PropertyParser.parse(). In that case a INHERIT constant would be needed. regards, finn
RE: Adding competing products to FOP Resources page
Clay Leeds wrote: I'm contemplating adding the following products to the FOP Resources page: - FOray - Defoe ...while I'm at it, I might as well add: - RenderX - XEP - AntennaHouse - XSL Formatter Thanks for doing that Clay. I think this will be good for FOP's users, and it should be good for FOP too. Essentially FOray can be testing and improving these modules and interfaces while FOP works on the layout. Kind of a competitive cooperation, or something like that. Victor Mote
Re: Adding competing products to FOP Resources page
On Nov 22, 2004, at 5:56 PM, Victor Mote wrote: Clay Leeds wrote: I'm contemplating adding the following products to the FOP Resources page: - FOray - Defoe ...while I'm at it, I might as well add: - RenderX - XEP - AntennaHouse - XSL Formatter Thanks for doing that Clay. I think this will be good for FOP's users, and it should be good for FOP too. Essentially FOray can be testing and improving these modules and interfaces while FOP works on the layout. Kind of a competitive cooperation, or something like that. Victor Mote I agree. I think it's good for FOP, and I believe others agreed as well. Keep up the good work! Web Maestro Clay -- [EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
