Re: include file in XSL
Athalye, Rishi wrote: I do think this was the right forum for such a question. Sorry, Rishi, but XSL include questions are really offopic in the mail list devoted to FOP development. Please ask your question in xsl-list, see http://www.mulberrytech.com/xsl/xsl-list/index.html. -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: source for hz algorithm
Victor Mote wrote: FYI, I now have the Knuth books Digital Typography and the 5-volume Computers Typesetting, and have perused the relevant sections. The h j For any who are interested in line-breaking, I highly recommend at least reading through this material. The book has a lot of other interesting things as well, including a chapter (4) on bidi. I've got this book too, good one, but too TeX-oriented IMO. Funny enough, the book was lying on my desk for ages and only now I noted it has a very interesting chpater about line breaking ;) -- Oleg Tkachenko Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: source for hz algorithm
Oleg Tkachenko wrote: I've got this book too, good one, but too TeX-oriented IMO. True enough that the book in general is TeX- Metafont-oriented. However, I thought the chapter on line-breaking was general enough to be very useful to us. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/render AbstractRenderer.java
On 11.02.2003 19:10:16 J.Pietschmann wrote: [EMAIL PROTECTED] wrote: Fixes a cause for a NPE. Doesn't fix the obvious bug, though. + final String pageNumber = (area.getPage() != null Dammit, does this mean the page can be already null? Sounds like it. :-) In this case the following: log.error(Areas pending, text probably lost. Check Page + + pageNumber + is basically useless. Check Page unknown..., this would drive me crazy for certain. Are there cases where a page number was actually shown? Not in the example I've examined today. The dropped text could be retrieved from the pending area, however, I think a page number to check would be really useful too. When I tracked down the bug, I tought a function on LineArea would be nice that constructs a String from its children so you get some context in your FO file. Also, why does this problem get so much attention recently? It was mentioned only three or four times in two years! Does it? Well, bugs are bugs, but it bugs me that they still distract us so much from the redesign. Wouldn't life be beautiful if we didn't have to provide support? Just kidding. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 2106] - broken justification with numeric umlaut entities
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2106 broken justification with numeric umlaut entities [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-02-11 19:46 --- *** Bug 16955 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6094] - 0.20.3rc hangs in endless loop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6094. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6094 0.20.3rc hangs in endless loop --- Additional Comments From [EMAIL PROTECTED] 2003-02-11 19:46 --- Could someone confirm that the endless loop terminator in 0.20.5 does not catch this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo/expr LabelEndFunction.java
pietsch 2003/02/11 11:47:25 Modified:src/documentation/content/xdocs Tag: fop-0_20_2-maintain relnotes.xml src/org/apache/fop/fo/expr Tag: fop-0_20_2-maintain LabelEndFunction.java Log: Fixed JAI URL. PR:16957 Submitted by: ole.kvarno Revision ChangesPath No revision No revision 1.3.2.3 +1 -1 xml-fop/src/documentation/content/xdocs/relnotes.xml Index: relnotes.xml === RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/relnotes.xml,v retrieving revision 1.3.2.2 retrieving revision 1.3.2.3 diff -u -r1.3.2.2 -r1.3.2.3 --- relnotes.xml 10 Dec 2002 10:06:36 - 1.3.2.2 +++ relnotes.xml 11 Feb 2003 19:47:25 - 1.3.2.3 @@ -26,7 +26,7 @@ copy JimiProClasses.zip to FOP's lib dir and rename it to jimi-1.0.jar. /li liFop has been compiled with -link href=http://java.sun.com/products/java-media/jai/JAI;JAI/link +link href=http://java.sun.com/products/java-media/jai;JAI/link support. For using JAI you just need to install it. /li liLinks in PDF won't generate multiple link rectangles anymore. If this causes No revision No revision 1.2.2.2 +4 -7 xml-fop/src/org/apache/fop/fo/expr/LabelEndFunction.java Index: LabelEndFunction.java === RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/expr/LabelEndFunction.java,v retrieving revision 1.2.2.1 retrieving revision 1.2.2.2 diff -u -r1.2.2.1 -r1.2.2.2 --- LabelEndFunction.java 17 Feb 2002 19:53:36 - 1.2.2.1 +++ LabelEndFunction.java 11 Feb 2003 19:47:25 - 1.2.2.2 @@ -1,8 +1,8 @@ /* * $Id$ - * Copyright (C) 2001 The Apache Software Foundation. All rights reserved. - * For details on use and redistribution please refer to the - * LICENSE file included with these sources. + * Copyright (C) 2001-2003 The Apache Software Foundation. All rights + * reserved. For details on use and redistribution please refer to + * the LICENSE file included with these sources. */ package org.apache.fop.fo.expr; @@ -47,9 +47,6 @@ labelEnd.addTerm(-1.0, distance); labelEnd.addTerm(-1.0, startIndent); labelEnd.addTerm(1.0, separation); - -// make sure value gets calculated -labelEnd.computeValue(); return new LengthProperty(labelEnd); } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Throwing away code was: Re: cvs commit:
Jeremias Maerki wrote: Dammit, does this mean the page can be already null? Sounds like it. :-) Where the hell is it nulled? I can't find it! When I tracked down the bug, I tought a function on LineArea would be nice that constructs a String from its children so you get some context in your FO file. Hmhm. Does it? Well, bugs are bugs, but it bugs me that they still distract us so much from the redesign. Wouldn't life be beautiful if we didn't have to provide support? Just kidding. Actually, the way the redesign was attempted was probably a bad idea. See http://www.joelonsoftware.com/articles/fog69.html Seems we have now the worst of all, with a reasonably working but outdated code in the maintenace branch and a huge investment, but still not fully working code in HEAD :-( J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 6094] - 0.20.3rc hangs in endless loop
[EMAIL PROTECTED] wrote: Could someone confirm that the endless loop terminator in 0.20.5 does not catch this? Yes. The loop seems to be in FOText.addRealText, where empty, zero height lines are added generated. This could be a bug in LineArea around line 667, where text is added to the line because the first word on the line overfolws and couln't be hyphenated. Shouldn't text added only after a break opportunity was encountered? This code is ghoulish! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: xml-fop/src/org/apache/fop/fo/expr LabelEndFunction.java
[EMAIL PROTECTED] wrote: Modified:src/documentation/content/xdocs Tag: fop-0_20_2-maintain relnotes.xml src/org/apache/fop/fo/expr Tag: fop-0_20_2-maintain LabelEndFunction.java Log: Fixed JAI URL. Oops, sorry for screwing the committ message. The LabelEndFunction fix undoes the 6094 fix and makes label-end() work again. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Throwing away code was: Re: cvs commit:
On 11.02.2003 20:55:40 J.Pietschmann wrote: Jeremias Maerki wrote: Dammit, does this mean the page can be already null? Sounds like it. :-) Where the hell is it nulled? I can't find it! It is never set. Area.setPage() is never called for LineAreas or so Eclipse tries to tell me. When I tracked down the bug, I tought a function on LineArea would be nice that constructs a String from its children so you get some context in your FO file. Hmhm. :-) Does it? Well, bugs are bugs, but it bugs me that they still distract us so much from the redesign. Wouldn't life be beautiful if we didn't have to provide support? Just kidding. Actually, the way the redesign was attempted was probably a bad idea. See http://www.joelonsoftware.com/articles/fog69.html Seems we have now the worst of all, with a reasonably working but outdated code in the maintenace branch and a huge investment, but still not fully working code in HEAD :-( We took a decision and I can still live with it. Nobody said it would be easy. Of course, it would be nice if we got some more resources in form of people working on the redesign or even funding to developers or committers... The biggest problem is probably that we lost a lot of knowledge (and possble workpower) when important committers left. At least you can say that the redesign holds some promising prespectives (IMO). Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FopServlet example!
Write your own InputHandler to do what you need. Then do the usual driver.render() call: Driver driver = new Driver(); InputHandler inputHandler = new MyCustomInputHandler(..whatever your InputHandler needs..); driver.setOutputStream(..wherever you want the output to go..); driver.render(inputHandler.getParser(), inputHandler.getInputSource()); -- Mark C. Allman -- Allman Professional Consulting, Inc. -- www.allmanpc.com, 617-947-4263 -Original Message- From: Ken Masters [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 4:16 PM To: [EMAIL PROTECTED] Subject: FopServlet example! Hi everyone, I am new to Apache FOP, and am finding a little problem with what I'm doing. The XSLTInputHandler class has two parameters, the XML and XSL File's. Basically what I would like to do is pass an XML as a Java String (since it is dynamically created) and the XSL can be passed as a File. How would I go about doing something like this, where the XML is created dynamically by a Servlet (from an XML database,Apache-Xindice), and passing this onto the XSLTInputHandler class (or any other class). Thanking you in advance! Ken _ Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmailpgmarket=en-gbXAPID=32DI=1 059 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FopServlet example!
Ken Masters wrote: I am new to Apache FOP, and am finding a little problem with what I'm doing. The XSLTInputHandler class has two parameters, the XML and XSL File's. Basically what I would like to do is pass an XML as a Java String (since it is dynamically created) and the XSL can be passed as a File. FAQ: http://xml.apache.org/fop/faq.html#faq-N102B3 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Throwing away code was: Re: cvs commit:
Jeremias Maerki wrote: On 11.02.2003 20:55:40 J.Pietschmann wrote: ... Actually, the way the redesign was attempted was probably a bad idea. See http://www.joelonsoftware.com/articles/fog69.html Seems we have now the worst of all, with a reasonably working but outdated code in the maintenace branch and a huge investment, but still not fully working code in HEAD :-( We took a decision and I can still live with it. Nobody said it would be easy. Of course, it would be nice if we got some more resources in form of people working on the redesign or even funding to developers or committers... The biggest problem is probably that we lost a lot of knowledge (and possble workpower) when important committers left. At least you can say that the redesign holds some promising prespectives (IMO). Sorry, I have to agree with Joerg here, although I have no desire to reopen the issue. I would rather have done a million refactorings to get us where we want to go than to maintain two sets of code. I think that the reason resources are not forthcoming is because of the barriers to entry that we have raised, the largest being that, if you want to work on the code, you really only get to work on the code that doesn't run. For most people, that is a no starter. I think when the trunk works reasonably well, resources will appear again. Caution: Blatant pontification follows The sine qua non of open source software is that the code works. Any experimental code that doesn't work but needs to get checked in should go onto a branch until it works. Commercial software developers might be able to get away with a different approach, if they hold enough cash in their hand to buy the resources to get them across the hump. The transitory nature of open source resources dictates that every incremental change (on the trunk anyway) be pretty much logically complete, and (by intention anyway) better /even in the short term/ than what was there before. All of that said, I am committed to the redesign, and frankly can't wait to get back to it. This is not only an extraordinary project, but it has an extraordinary crew (but let's don't ever do it this way again ... please). Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
