Re: Linebreaks around e-g and i-f-o

2005-11-09 Thread Jeremias Maerki
I agree that a) is probably best. See e-g/i-f-o just like a glyph in a word, for example. At least, it could be used that way. In most situations you'll probably surround the graphic with spaces anyway, so break possibilities come from there. On 09.11.2005 05:51:03 Manuel Mall wrote: > What's the

DO NOT REPLY [Bug 37417] - Patch to support fop from partially implemented Class Loaders.

2005-11-09 Thread 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_bu

Re: Inquiry: conditional inclusion of dev-related debugging?

2005-11-09 Thread Jeremias Maerki
I agree that we should keep an eye on logging. What you propose is certainly an option. Some random thoughts: - I wonder how it would affect the source code (readbility). You'd have to write a debug() method in each class that logs to a separate logger. - Right now I don't know of any bigger compon

Re: Inquiry: conditional inclusion of dev-related debugging?

2005-11-09 Thread Finn Bock
[Andreas] Hi all, For starters: it's not really a pressing matter ATM, but it may become of relevance if we want to strive for a production-release. The matter is somewhat related to the distinction between developer- and user-directed logging. It concerns the numerous log.debug() and l

DO NOT REPLY [Bug 36480] - [PATCH] Space support in RTF rendering

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 36826] - nullpointerexc at org.apache.fop.fo.FOTreeBuilder.endElement, XSL and XML are valid

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 36952] - FopServlet.java in servlet examples

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37116] - ESC POS Renderer

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37253] - [PATCH] At present rendering to TXT is unimplemented.

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37116] - ESC POS Renderer

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 36928] - em specification on font-size broken

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37253] - [PATCH] At present rendering to TXT is unimplemented.

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37253] - [PATCH] At present rendering to TXT is unimplemented.

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37116] - ESC POS Renderer

2005-11-09 Thread 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_bu

Sandbox area for renderers

2005-11-09 Thread Jeremias Maerki
Given the recent comments concerning the ESP POS renderer, it looks like it would make sense to put certain renderers in a separate area. In Barcode4J I have a "src/sandbox" area. Self-speaking, I guess. Also taking the state that MIF, PCL and SVG output are in, it would be better to move them ther

Preparing for the first release

2005-11-09 Thread Jeremias Maerki
The time has come and we need to push FOP out to the public again, at least IMO. I'm currently seeing through the last few things (patches, docs, bugs etc.). Are there any objections on doing the first release within the next few days? Is there anything that needs to be done which is not on the re

DO NOT REPLY [Bug 37116] - ESC POS Renderer

2005-11-09 Thread 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_bu

Re: Sandbox area for renderers

2005-11-09 Thread Chris Bowditch
Jeremias Maerki wrote: Given the recent comments concerning the ESP POS renderer, it looks like it would make sense to put certain renderers in a separate area. In Barcode4J I have a "src/sandbox" area. Self-speaking, I guess. Also taking the state that MIF, PCL and SVG output are in, it would b

DO NOT REPLY [Bug 37236] - [PATCH] Fix gradients and patterns

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37305] - Added deviceDPI to PDFDocumentGraphics2D

2005-11-09 Thread 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_bu

Re: Sandbox area for renderers

2005-11-09 Thread Manuel Mall
On Wed, 9 Nov 2005 09:50 pm, Jeremias Maerki wrote: > I personally wouldn't call the area "unsupported" as Manuel > suggested. "sandbox" would send a better signal IMO. Furthermore, I > don't like an "incubator" area so much because that could be easily > confused with the Incubator project. Fine

DO NOT REPLY [Bug 37330] - [PATCH] FOP Bridges not properly registered with Batik

2005-11-09 Thread 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_bu

Re: Sandbox area for renderers

2005-11-09 Thread The Web Maestro
On Nov 9, 2005, at 5:50 AM, Jeremias Maerki wrote: So what I would suggest: - Create src/sandbox. - Move the MIF, PCL and SVG output to src/sandbox. - Adjust the build to create a fop-sandbox.jar which dynamically registers the output formats when they are in the classpath. - Add the ESC POS rend

Re: svn commit: r332007 - /xmlgraphics/fop/trunk/test/fotree/testcases/no_namespace_prefix.fo

2005-11-09 Thread Simon Pepping
On Wed, Nov 09, 2005 at 08:58:24AM -, [EMAIL PROTECTED] wrote: > Author: jeremias > Date: Wed Nov 9 00:58:20 2005 > New Revision: 332007 > > URL: http://svn.apache.org/viewcvs?rev=332007&view=rev > Log: > Test to check FO tree building when no namespace prefix is used. Why is this necessary?

Re: svn commit: r332007 - /xmlgraphics/fop/trunk/test/fotree/testcases/no_namespace_prefix.fo

2005-11-09 Thread Jeremias Maerki
I know it's not strictly necessary. It's just there for regression testing purposes and as a demonstration that you don't have to use the fo: prefix. It doesn't hurt, does it? On 09.11.2005 21:38:32 Simon Pepping wrote: > On Wed, Nov 09, 2005 at 08:58:24AM -, [EMAIL PROTECTED] wrote: > > Autho

Re: White space handling Wiki page

2005-11-09 Thread Simon Pepping
On Tue, Nov 08, 2005 at 11:19:15AM +0800, Manuel Mall wrote: > On Tue, 8 Nov 2005 04:40 am, Simon Pepping wrote: > > > > Step 2. Refinement: white-space-collapse > > > > > > Issue 1. The spec intentionally addresses only XML white space, > > because only suc

Re: Leading/trailing space removal in LineLM

2005-11-09 Thread Simon Pepping
On Wed, Nov 09, 2005 at 09:09:55AM +0800, Manuel Mall wrote: > On Wed, 9 Nov 2005 12:47 am, Andreas L Delmelle wrote: > > >> 6. Breaking / elastic / non removable - eg. U+3000 Ideographic > > >> space => Must handle border/padding > > >> => Must handle text-align > > >> Question: XSL-FO does not

The XML Graphics project is one year old!

2005-11-09 Thread Jeremias Maerki
The subject says it all. :-) I'm personally pleased about what happened so far. I believe the creation of this project has fulfilled the board's wishes for better oversight. We've had fruitful discussions about the setup for XML Graphics Commons. I'll finally start work on it shortly after the fir

Re: Linebreaks around e-g and i-f-o

2005-11-09 Thread J.Pietschmann
Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rule LB20 the way that it also recommends b). J.Piets

DO NOT REPLY [Bug 37432] New: - Patch to support other applications embedding the TTFReader.

2005-11-09 Thread 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_bu

DO NOT REPLY [Bug 37432] - Patch to support other applications embedding the TTFReader.

2005-11-09 Thread 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_bu

Re: Inquiry: conditional inclusion of dev-related debugging?

2005-11-09 Thread Andreas L Delmelle
On Nov 9, 2005, at 09:31, Jeremias Maerki wrote: Jeremias / Finn, I agree that we should keep an eye on logging. What you propose is certainly an option. Some random thoughts: - I wonder how it would affect the source code (readbility). You'd have to write a debug() method in each class that

Re: Linebreaks around e-g and i-f-o

2005-11-09 Thread Andreas L Delmelle
On Nov 9, 2005, at 23:38, J.Pietschmann wrote: Manuel Mall wrote: What's the opinion around the group on how external-graphics / instream-foreign-objects are suppose to be handled with respect to determining linebreak opportunities. FOP 0.20.5 implemented b). I read the UAX14 catch all rul

DO NOT REPLY [Bug 37305] - Added deviceDPI to PDFDocumentGraphics2D

2005-11-09 Thread 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_bu

Re: Linebreaks around e-g and i-f-o

2005-11-09 Thread Manuel Mall
On Thu, 10 Nov 2005 09:34 am, Andreas L Delmelle wrote: > On Nov 9, 2005, at 23:38, J.Pietschmann wrote: > > Manuel Mall wrote: > Now, I have another question / remark. > > Look at InlineCharIterator: the boundary EOT characters for start and > end of the inline, are they passed on to Layout? No