Re: cvs commit: xml-fop/src/java/org/apache/fop/fo FOTreeBuilder.java

[Simon Pepping]

On Fri, Jul 16, 2004 at 05:10:32AM -, [EMAIL PROTECTED] wrote:
>   Log:
>   Moved user-defined ElementMapping initialization from Driver to FOUserAgent.
>   Moved only "string" method, the version we use internally--probably sufficient
>   for others' work as well.  (Note: an additional unused FOUserAgent object will
>   be created in driver during command-line use--cp. its no-param constructor vs.
>   setUserAgent() call in apps.Fop; this will need to be ironed out at some time.)
>   

Introduce a constructor Driver(FOUserAgent foUserAgent)? It is good to
enable our own CLI and embedding apps to first construct the user
agent with all desired features and then create a driver with it.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: cvs commit: xml-fop/examples/embedding/java/embedding ExampleFO2PDF.java

[Simon Pepping]

Glen,

I can see Jeremias' argument for a single pattern to deal with all
situations, but I am pleased to see the SAX solution illustrated by an
example in this simplest case of all.

Perhaps it is a good idea to illustrate the transformer solution in
ExampleFO2PDF, and the outlying SAX parser solution in
ExampleFO2PDF-SAX.

Regards, Simon

On Thu, Jul 15, 2004 at 08:59:21PM -0700, Glen Mazza wrote:
> Thanks, Simon--I didn't think of this way of solving
> the problem--I just modified Jeremias' previous DOM
> example. However, I placed the method below
> temporarily in the example and committed it before
> returning to the Transformer version.  This way, we
> have a working example should we ever need to document
> this style (perhaps on a web page, so users are at
> least aware of it) in the future.
> 
> Glen
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

DO NOT REPLY [Bug 30156] New: - Image file opened but not closed

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30156

Image file opened but not closed

   Summary: Image file opened but not closed
   Product: Fop
   Version: 0.20.5
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: images
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using Jimi library to handle images, the code that does this open the 
stream to the image file using (url.getStream()) but did not close it. This 
prevent the deletion on the image files. 

This doesn't have much impact on on-off application but it creates a lot of 
troubles in the long-standing web application.

I have confirmed this by trying modifying the source code (JimiImage.loadImage
()) to close the stream and it worked.

RE: FOray 0.1 release

[Victor Mote]

Jeremias Maerki wrote:

> Making these parts into separate components is in line with 
> what I have in mind when can talk about a shared repository 
> between Batik and FOP. I hope I can take a good look into 

Good. I think it has potential to be useful to many applications.

> what you did later. From a quick look, however, I wasn't very 
> pleased that you propose to use a lot of statics in the 
> "FontServer". I would prefer to have the possibility to 
> define multiple configurations in a heavy server environment 
> without having to go through the pains to separate multiple 
> environments using classloader magic. The system fonts are ok 
> like this, of course, but not the user-defined. Just my opinion.

I knew this would be controversial, and I'll be glad to consider changes.
The use case that you mentioned will, I think, be handled by some of the
other planned changes to configuration that are in the works. These changes
will be more client-centered than server-centered. So, rather than having
multiple servers configured different ways, each client will tell the server
more about what it wants, and the server will react based on this. However,
I may not see all of what you are thinking about here. If you can be more
specific, I'll think through this some more. One of the main purposes of
FontServer was to share as much of the Font overhead as possible between
documents in a heavy server environment, while keeping a light footprint in
the code. I actually tried to write it in a non-static way (with you in
mind) in the beginning, but it just ended up being silly, at least for the
purposes that it is currently designed for.

> Concerning the PDF library, I suggest you start from the PDF 
> lib in CVS HEAD instead of using the maintenance branch, even 
> if it means that the API may be a bit different. I've 
> invested a considerable amount of time to make the whole 
> thing better. Things such as encryption are much more cleanly solved.

First, in relation to FOP 0.20.5 (approximately FOray's starting place), the
changes that you are talking about are improvements, and I don't want to be
introducing changes or improvements yet. The goal here is really to make
sure nothing is broken. Then we can start making improvements, releasing
them, and getting user feedback.

Second, I *know* that, while in many ways HEAD is superior to the
maintenance branch, there are many specific instances where the maintenance
branch is superior to HEAD. I also know that there is no convenient list of
such items. I have to choose between the two evils of 1) losing benefit(s)
in the old code, and 2) losing benefit(s) in the new code. Of the two, I
prefer the latter. The user is not going to be happy if I remove his wheels
while installing the new, more powerful engine. Better IMO for us to upgrade
the engine in a manner that ensures that the wheels stay on. FOP is kind of
into the chasm thing, and FOray is definitely not.

Third, what you suggest is much easier said than done. I have made a note to
specifically check the encryption stuff when I get a chance. I suppose that
we can either diff the code (probably only useful to those who wrote it) or
use "missing feature" hunt. IOW, if we get to the place where we are
releasing code again, then, when issues come up on fop-user, hopefully you
or someone else will say "I already fixed that in HEAD", and we can
reconcile them. Ideally we want to get to the place where both branches are
using the same code. I *think* that is pretty easy for Fonts and Graphics,
but, as you say, probably not as easy for PDF, and probably PostScript too.

Victor Mote

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer





--- Additional Comments From [EMAIL PROTECTED]  2004-07-16 13:12 ---
Created an attachment (id=12127)
Slashed down version of bug.fo

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2004-07-16 13:10 ---
Thanks for your help. 
 
Unfortunately, the error persists also with the new version. I've attached a 
slashed down version of bug.fo (some 180 lines) that still produces the same 
NullPointerException.

DO NOT REPLY [Bug 30146] New: - postscript - table - border-collapse-separate

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30146

postscript - table - border-collapse-separate

   Summary: postscript - table - border-collapse-separate
   Product: Fop
   Version: 0.20.5
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the postscript renderer, the value "collapse" for the attribute "border-
collapse" doesn't produce correct output table. In this case, the borders are 
separated. They are collapsed if the value is "separate".

Note: the pdf renderer works fine.

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-07-16 10:56 ---
Marc,

I added a NPE check to the code, the error should no longer occur.  The code in
question was added 4 months, 10 days ago.

There may be other formatting problems still, however, if that is the case
please reopen the bug or create new ones as appropriate.

Glen

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID
Summary|NullPointerException in rtf-|NullPointerException in rtf-
   |renderer|renderer



--- Additional Comments From [EMAIL PROTECTED]  2004-07-16 10:43 ---
Marc

Your input FO File isn't working on my machine because it's requesting a lot of
graphics that you did not attach.  I'm getting too many other errors.

I asked you for a minimal FO file to reproduce the error.  You sent me a
910-line file that's requesting several graphics instead.  

Note:  do not attach the graphics, rather, again, reduce the FO to its minimal
size that causes this error to occur.  When you're willing to do so, please
re-open this bug--your FO file you send us should probably be under 150 lines.

Glen

DO NOT REPLY [Bug 30138] - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer 





--- Additional Comments From [EMAIL PROTECTED]  2004-07-16 07:49 ---
Created an attachment (id=12125)
fo file that causes the bug

DO NOT REPLY [Bug 30138] New: - NullPointerException in rtf-renderer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30138

NullPointerException in rtf-renderer 

   Summary: NullPointerException in rtf-renderer
   Product: Fop
   Version: 1.0dev
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When trying to convert the attached fo-file to rtf using the fop.sh shell
script, the renderer reproducingly crashes with the following NullPointerException:



Exception in thread "main" java.lang.NullPointerException
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListTable.writeListTableEntry(RtfListTable.java:191)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfListTable.writeRtfContent(RtfListTable.java:136)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfElement.writeRtf(RtfElement.java:86)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfContainer.writeRtfContent(RtfContainer.java:135)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfElement.writeRtf(RtfElement.java:86)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfContainer.writeRtfContent(RtfContainer.java:135)
at
org.apache.fop.render.rtf.rtflib.rtfdoc.RtfElement.writeRtf(RtfElement.java:86)
at org.apache.fop.render.rtf.rtflib.rtfdoc.RtfFile.flush(RtfFile.java:219)
at org.apache.fop.render.rtf.RTFHandler.endDocument(RTFHandler.java:157)
at org.apache.fop.fo.FOTreeBuilder.endDocument(FOTreeBuilder.java:224)
at org.apache.xerces.parsers.AbstractSAXParser.endDocument(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.endEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(Unknown
Source)
at
org.apache.xerces.impl.XMLEntityManager$EntityScanner.skipSpaces(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown
Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.fop.apps.Driver.render(Driver.java:230)
at org.apache.fop.apps.Driver.render(Driver.java:203)
at org.apache.fop.apps.Fop.main(Fop.java:57)

-

The code base is that of 2004-07-16 around 9.00 MEZ (head).

Commenting out the offending line 191 in RtfListTable caused the conversion to
run through, though resulting in not conformant rtf.

The same file converted OK with a fop version that was approximately three
months old (also head).

The fo is produced using the current docbook stylesheets, originating from a
docbook source.