DO NOT REPLY [Bug 32338] - Rendering fails with IndexOutOfBoundsException in CompoundPropertyMaker

2004-11-22 Thread bugzilla
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?

2004-11-22 Thread Finn Bock
[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

2004-11-22 Thread Andreas L. Delmelle
 -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?

2004-11-22 Thread Glen Mazza
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

2004-11-22 Thread Victor Mote
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

2004-11-22 Thread The Web Maestro
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