Re: Storing the Locator instance in FONode.

2004-10-01 Thread Finn Bock
[Glen]
I see.  I liked Locator because I can get away with
passing in one parameter into the vCN() instead of
three.  (But I don't think we'll need to change that
portion of the code because whenever vCN() is being
called, the Locator *is* accurate--would you agree?)
Yes.
regards,
finn


DO NOT REPLY [Bug 31502] New: - UTF-8

2004-10-01 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=31502.
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=31502

UTF-8

   Summary: UTF-8
   Product: Fop
   Version: all
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: pdf renderer
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Re: cvs commit: xml-fop/src/java/org/apache/fop/render/rtf TableAttributesConverter.java

2004-10-01 Thread Jeremias Maerki
Finn, it seems to me that you probably forgot the check in all your
changes. FOP doesn't compile ATM. The method makeBorder is missing.

On 01.10.2004 11:46:36 bckfnn wrote:
 bckfnn  2004/10/01 02:46:36
 
   Modified:src/java/org/apache/fop/render/rtf
 TableAttributesConverter.java
   Log:
   Simplified the handling of length attributes.
   Attempt at setting borders correctly.
   
   Revision  ChangesPath
   1.16  +49 -140   
 xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java
   
   Index: TableAttributesConverter.java
   ===
   RCS file: 
 /home/cvs/xml-fop/src/java/org/apache/fop/render/rtf/TableAttributesConverter.java,v
   retrieving revision 1.15
   retrieving revision 1.16
   diff -u -r1.15 -r1.16
   --- TableAttributesConverter.java   23 May 2004 17:00:00 -  1.15
   +++ TableAttributesConverter.java   1 Oct 2004 09:46:36 -   1.16
snip/
   +BorderAttributesConverter.makeBorder(propList, attrib, 
 ITableAttributes.CELL_BORDER_TOP,
   +Constants.PR_BORDER_TOP_COLOR, 
   +Constants.PR_BORDER_TOP_STYLE, 
   +Constants.PR_BORDER_TOP_WIDTH);
   +BorderAttributesConverter.makeBorder(propList, attrib, 
 ITableAttributes.CELL_BORDER_BOTTOM,
   +Constants.PR_BORDER_BOTTOM_COLOR, 
   +Constants.PR_BORDER_BOTTOM_STYLE, 
   +Constants.PR_BORDER_BOTTOM_WIDTH);
   +BorderAttributesConverter.makeBorder(propList, attrib, 
 ITableAttributes.CELL_BORDER_LEFT,
   +Constants.PR_BORDER_LEFT_COLOR, 
   +Constants.PR_BORDER_LEFT_STYLE, 
   +Constants.PR_BORDER_LEFT_WIDTH);
   +BorderAttributesConverter.makeBorder(propList, attrib,  
 ITableAttributes.CELL_BORDER_RIGHT,
   +Constants.PR_BORDER_RIGHT_COLOR, 
   +Constants.PR_BORDER_RIGHT_STYLE, 
   +Constants.PR_BORDER_RIGHT_WIDTH);


Jeremias Maerki



Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Dalibor Topic
Glen Mazza wrote:
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Why are you so keen on removing stuff? I'd be more
concerned about
adding the stuff that's missing for an initial
release. 

Just cleaning up for the next release.

Jimi works fine
for some people. No reason to remove this.

OK, so it does work for the Java 2 platform.  We'll
keep it then.
I haven't been following the developments very closely, so this may 
sound like a stupid question: does that mean that FOP HEAD now works 
nicely with PNGs without JIMI? Has the code from Batik been merged in, 
or has another solution emerged?

cheers,
dalibor topic


Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Jeremias Maerki
Not a stupid question at all, but no, with FOP 0.20.5 you still need
either JIMI or JAI for PNG support. But it may well be that the next FOP
version will support PNG without an additional library. For now, you're
stuck, though.

On 01.10.2004 15:31:15 Dalibor Topic wrote:
 I haven't been following the developments very closely, so this may 
 sound like a stupid question: does that mean that FOP HEAD now works 
 nicely with PNGs without JIMI? Has the code from Batik been merged in, 
 or has another solution emerged?


Jeremias Maerki



Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Dalibor Topic
Jeremias Maerki wrote:
Not a stupid question at all, but no, with FOP 0.20.5 you still need
either JIMI or JAI for PNG support. But it may well be that the next FOP
version will support PNG without an additional library. For now, you're
stuck, though.
thanks for the quick responce, Jeremias. I'm going to be a bit involved 
with Fedora documentation project's attempt to build up their toolchain 
using FOP on GNU Classpath based runtimes[1], so I'm glad to hear that 
there is a chance of having PNG work out of the box in the next release.

My initial experiments with Kaffe  FOP a while ago have been 
encouraging. I am considering spending some time getting FOP to work on 
gcj, Kaffe and other runtimes, as I'd like to use it to generate man 
pages for kaffe using kaffe, among other things. I assume HEAD is the 
best place to start for an interested developer?

cheers,
dalibor topic
[1] And with debian's efforts to get FOP into main.


Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Jeremias Maerki
If you got a long breath, yes. We're are still a few months from a
release. The layout code is in the process of being completely rewritten,
so many features available in 0.20.5 are still missing.

On 01.10.2004 17:10:34 Dalibor Topic wrote:
 Jeremias Maerki wrote:
  Not a stupid question at all, but no, with FOP 0.20.5 you still need
  either JIMI or JAI for PNG support. But it may well be that the next FOP
  version will support PNG without an additional library. For now, you're
  stuck, though.
 
 thanks for the quick responce, Jeremias. I'm going to be a bit involved 
 with Fedora documentation project's attempt to build up their toolchain 
 using FOP on GNU Classpath based runtimes[1], so I'm glad to hear that 
 there is a chance of having PNG work out of the box in the next release.
 
 My initial experiments with Kaffe  FOP a while ago have been 
 encouraging. I am considering spending some time getting FOP to work on 
 gcj, Kaffe and other runtimes, as I'd like to use it to generate man 
 pages for kaffe using kaffe, among other things. I assume HEAD is the 
 best place to start for an interested developer?
 
 cheers,
 dalibor topic
 
 [1] And with debian's efforts to get FOP into main.



Jeremias Maerki



Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Jeremias Maerki

On 01.10.2004 18:06:13 Clay Leeds wrote:
 Please clarify:
 As the Subject implies, Glen's original message indicated he wanted to 
 remove Jimi (I understand that won't be the case now). He said nothing 
 of removing JAI, and as far as I understand, FOP-1.0 will still need 
 JAI for PNG support (please correct me if I'm wrong).

Nobody talks about removing JAI support.

 Will JAI be required by FOP-1.0 for PNG and also be required for some 
 subformats of TIFF[1]?

Yes, except that we can use the ImageIO API from JDK 1.4 and later.
But in the end ImageIO also uses JAI codecs to support the different
formats. We could also have another look at open source codecs to
support PNG and TIFF etc.

Jeremias Maerki



Re: Remove image.JimiImage from HEAD?

2004-10-01 Thread Clay Leeds
On Oct 1, 2004, at 2:30 PM, Jeremias Maerki wrote:
On 01.10.2004 18:06:13 Clay Leeds wrote:
Please clarify:
As the Subject implies, Glen's original message indicated he wanted to
remove Jimi (I understand that won't be the case now). He said nothing
of removing JAI, and as far as I understand, FOP-1.0 will still need
JAI for PNG support (please correct me if I'm wrong).
Nobody talks about removing JAI support.
Just wanted to be sure... I saw the following and was confused:
On Oct 1, 2004, at 6:39 AM, Jeremias Maerki wrote:
Not a stupid question at all, but no, with FOP 0.20.5 you still need
either JIMI or JAI for PNG support. But it may well be that the next 
FOP
version will support PNG without an additional library. For now, you're
stuck, though.
But it may well be that the next FOP will support PNG without an 
additional library.

Will JAI be required by FOP-1.0 for PNG and also be required for some
subformats of TIFF[1]?
Yes, except that we can use the ImageIO API from JDK 1.4 and later.
But in the end ImageIO also uses JAI codecs to support the different
formats. We could also have another look at open source codecs to
support PNG and TIFF etc.
Jeremias Maerki
Maybe the idea of adding open source codecs is what you were referring 
to. Thanks for the response...

Web Maestro Clay


Build broken?

2004-10-01 Thread Glen Mazza
I can't seem to compile HEAD--it may be related to
Finn's latest changes.  Javac is complaining about an
unknown BorderAttributesConverter.makeBorder(...) in
render.rtf.TableAttributesConverter.

Thanks,
Glen