Re: Merging jfor into FOP - what's the plan?
Hi Bertrand, For the short term I think that (1) would be the thing to do but since there won't be a release of FOP for a while there may be no point doing anything for the short term. As for how it will eventually end up working with the rest of fop. Can you give us a quick rundown of what is involved in creating an rtf document from xsl fo. What sort of information is passed from the fo to the rtf. How layout is considered etc. The way that FOP normally converts from fo to the output is by a few steps. First the fo is turned into the formatting object tree. This is then turned into an area tree. This area tree represents the final layout with data that any renderer can handle. The renderer then uses this area tree to create the pages. This means that the renderer knows nothing about the original document and does not have a concept of lists, tables etc. I should also point out that the MIF renderer used references to the formatting object tree to determine things ike tables to create tables in the output. This sort of thing is being revisited as it causes problems. Regards, Keiron. On 2001.11.23 13:32 Bertrand Delacretaz wrote: (repost - I think the first one didn't get through) Now that the introductions are done, I'd like to initiate the discussion about how to actually merge jfor into FOP. Currently I have one major code contribution to integrate into the jfor code base. I expect to be done in a week and would like to release a last non-FOP version of jfor with these changes. Regarding the merging of jfor, I see three options: 1) inclusion of the jfor.jar in the FOP distribution, user-level integration where a -rtf switch of FOP causes jfor to run instead of FOP Makes it possible for users to generate RTF + PDF without needing a separate download. No benefits on the developer side. We might get a lot of questions like why is the RTF output so poor compared to PDF. 2) same but modify jfor to use the existing FOP infrastructure: startup, parser, configuration, logging, etc.. 3) full integration of jfor as a FOP renderer, taking advantage of the FOP analysis of the XSL-FO document. IMHO this needs to bypass the layout stage to stay quick and translate as much of the document structure as possible to RTF. Considering that I won't have much time in the next few weeks, my suggestion would be to first go ahead with 1) and simultaneously studying and discussing how to best reach 2) and 3). Any thoughts? - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] New: - problems with DOM input
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=5075. 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=5075 problems with DOM input Summary: problems with DOM input Product: Fop Version: all Platform: All OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, FOP does not work using DOM inputSource. the xsl-fo -document is valid: when i save it to disk and read it from a file (render it from a stream), everything works fine. so the problem seems to be with DOM. basically I am doing everything like is done in the demo servlet that comes with FOP (org.apache.fop.tools.servlet.FopServlet) BUT: i am reading from a DOMInputSource. the server announces a NullPointerException at FOTreeBuilder.java:191. (I try to attach the error messages (with xsl-fo source) to this bug report) I am using FOP v0.20.1. (I am using bea weblogic server and xalan and xerces that come with it (xerces based on version 1.3.1 of Apache Xerces and xalan based on version 2.0.1 of Apache Xalan, JDK 130. I tried to solve the problem building FOP again using this JDK, did not help. and anyway the problem seems to be inside FOP) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: basic-link internal-destination
the id has to be unique.. possibly ur assigning the same id at more than one location in your document.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 12:15 PM To: [EMAIL PROTECTED] Subject: fo:basic-link internal-destination Hi, I'm facing a problem in basic-link internal-destination. The problem is, when my document in first page contain internal-destination attribute then in second page contains the id attribute (which refer to internal-destination). When I run fop.0.20.1 the fop given me an error The 'id' already exists in the document. If my document contain internal-destination attribute and id attribute on same page then the fop can produce pdf file for me. So, I hope that anyone can tell how to solved the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5010] - Better error reporting needed
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=5010. 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=5010 Better error reporting needed [EMAIL PROTECTED] changed: What|Removed |Added Summary|Better error reporting |Better error reporting |needed |needed --- Additional Comments From [EMAIL PROTECTED] 2001-11-26 02:16 --- I agree with you, error reporting must become better. In most of the cases, Error: null appears, if there is a problem in xsl transformation. To work around this, let xalan first generate a .fo file: java -cp your-classpath org.apache.xalan.xslt.Process \ -in admin-faq.xml -xsl xsl/fo/docbook.xsl -out admin-faq.fo If there is a problem in your xsl, xalan will tell you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] - problems with DOM input
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=5075. 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=5075 problems with DOM input --- Additional Comments From [EMAIL PROTECTED] 2001-11-26 03:12 --- Created an attachment (id=823) the xml source used when the error occured - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5075] - problems with DOM input
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=5075. 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=5075 problems with DOM input --- Additional Comments From [EMAIL PROTECTED] 2001-11-26 03:14 --- Created an attachment (id=824) the xsl source used when the error occured - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: keep-with-next, orphans, widows
keep-with-next is implemented only for tables. Take a look at docs\html-docs\implemented.html under the FOP home directory to find out what is implemented. Regards, Mike -Original Message- From: Jörg Flotho [mailto:[EMAIL PROTECTED]] Sent: 26. november 2001 14:33 To: [EMAIL PROTECTED] Subject: keep-with-next, orphans, widows fo:block space-after=3.0pt space-before=0.0pt text-align=start text-indent=0.0pt line-height=1.2 orphans=1 widows=1 fo:inline font-family=Helvetica font-size=10pt xsl:apply-templates/ /fo:inline /fo:block what's wrong with this? there is no result, whatever which parameter is given in orphans ans widows. The next problem is keep-with-next: fo:block margin-left=0.0pt space-after=0.0pt space-before=5.0pt text-align=left text-indent=0.0pt keep-with-next=true fo:inline font-family=Helvetica font-size=11pt font-weight=bold font-style=italic xsl:apply-templates/ /fo:inline /fo:block It doesn't work either. Can anyone help please? Jörg - 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: Font embedding in PostScript?
Well, if the font is embedded in the PDF, it gets embedded in to resulting PostScript file. If it's not, no embedding is done. I don't think you can have the fonts embedded in the PostScript when they aren't embedded in the PDF. Not sure, though. Maybe Ghostscript can do that. I've never tried. On Fri, 23 Nov 2001 10:05:56 -0600 jthaemlitz wrote: Any luck printing embeded fonts on Linux via Acrobat PostScript? I believe the font needs to be on the printer. any advice is appreciated. JohnPT fop-dev-return-11702-jthaemlitz=oreillyauto.com@XML. APACHE.ORG To: [EMAIL PROTECTED] cc: 11/23/01 08:24 AM Subject: Re: Font embedding in PostScript? Please respond to fop-dev Hi Ulrich No, sorry. I haven't had the time to do that, yet. I'm still doing it the PDF-way and then converting the PDF to PostScript using Acrobat Reader 4.05. On 23.11.2001 14:04:20 Ulrich Mayring wrote: Hello, is it possible to use font embedding, when rendering to PostScript, or is this only possible with PDF? Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - 6002 Luzern Fon +41 (0)41 317 2020 - Fax +41 (0)41 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Freundliche Grüsse OUTLINE AG Jeremias Märki mailto:[EMAIL PROTECTED] Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: keep-with-next, orphans, widows
It's my understanding, that right now keep-with-next is only implemented on the table-row element. What's more, you can only use it when you know you will not have any more rows than will fit on a page. Otherwise FOP goes into an endless loop. -Original Message- From: Jörg Flotho [mailto:[EMAIL PROTECTED]] Sent: Monday, November 26, 2001 5:33 AM To: [EMAIL PROTECTED] Subject: keep-with-next, orphans, widows fo:block space-after=3.0pt space-before=0.0pt text-align=start text-indent=0.0pt line-height=1.2 orphans=1 widows=1 fo:inline font-family=Helvetica font-size=10pt xsl:apply-templates/ /fo:inline /fo:block what's wrong with this? there is no result, whatever which parameter is given in orphans ans widows. The next problem is keep-with-next: fo:block margin-left=0.0pt space-after=0.0pt space-before=5.0pt text-align=left text-indent=0.0pt keep-with-next=true fo:inline font-family=Helvetica font-size=11pt font-weight=bold font-style=italic xsl:apply-templates/ /fo:inline /fo:block It doesn't work either. Can anyone help please? Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5099] New: - fop gets stuck in infinite loop when table rows with keep-with-next that together, are larger than the current page
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=5099. 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=5099 fop gets stuck in infinite loop when table rows with keep-with-next that together, are larger than the current page Summary: fop gets stuck in infinite loop when table rows with keep-with-next that together, are larger than the current page Product: Fop Version: all Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] this may not be a bug, but this is similar the the problem of having an image that is larger than the page (a description of the infinite-loop-on-large- images bug can be found at this link: http://www.owal.co.uk:8090/asf/servlet/asf/screen/DisplayQuestionAnswer/action/S etAll/project_id/18/faq_id/276/topic_id/495/question_id/788 ) An infinite loop occurs when: you have a group of table rows that are always supposed to be kept together, but this group is larger than the page. table rows are kept together when they have their keep-with-previous or keep-with-next property set to always. you would think that if you have a group of rows that are kept together that are larger than the page, you should just remove one of the keep-with- previous properties from one of the rows. but, when fo docs are dynamically generated from a DB, this isn't always possible. it seems like fo should know to break the grouped rows itself. here is my fo document that loops infinitely when rendered: thanks in advance for any reponses to this bug, peter joh ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master font-size=8pt font-family=Helvetica margin-right=1in margin-left=1in margin-bottom=0.5in margin-top=.7in page-width=8.5in page-height=11in master- name=orderingInfo_Optional_FO_Template fo:region-body margin-bottom=.8in margin-top=.6in/ fo:region-before extent=.5in/ fo:region-after extent=.5in/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-name=orderingInfo_Optional_FO_Template fo:static-content flow-name=xsl-region-before fo:table border-color=white border-width=0.5mm fo:table-column column-width=50mm/ fo:table-column column-width=55mm/ fo:table-column column-width=60mm/ fo:table-body fo:table-row fo:table-cell background- color=#00 border-color=white border-style=solid border-width=0.6mm fo:block color=white line-height=12pt text-align=start margin-left=2mm padding-top=10pt font- weight=bold font-size=9ptC6C042 - Regular Cab/fo:block /fo:table-cell fo:table-cell background- color=#00 border-color=white border-style=solid border-width=0.6mm fo:block color=white line-height=12pt text-align=center padding-top=4pt font-weight=bold font-size=9pt OPTIONAL EQUIPMENT /fo:block /fo:table-cell fo:table-cell background- color=#00 border-color=white border-style=solid border-width=0.6mm fo:block wrap- option=no-wrap color=white line-height=12pt text-align=end margin- right=2mm padding-top=4pt font-weight=bold font-size=9pt S=Standard A=Available /fo:block fo:block wrap- option=no-wrap color=white line-height=12pt text-align=end margin- right=2mm padding-bottom=2pt font-weight=bold font-size=9pt W/A=Will Advise N/C=No Charge /fo:block /fo:table-cell /fo:table-row
DO NOT REPLY [Bug 5100] New: - Useless error message
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=5100. 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=5100 Useless error message Summary: Useless error message Product: Fop Version: all Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: pdf renderer AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] My PDF builds beautifully, but the logs have two entries with the following: [java] INFO10068 [fop ] (): [38] [java] ERROR 10068 [fop ] (): [java] INFO10068 [fop ] (): [39] [java] ERROR 10068 [fop ] (): And then the rest renders OK. How do I tell if there is an illegal construct in my XML? The two error entries do not give me any clue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fo RecursiveCharIterator.java
klease 01/11/26 13:11:06
Modified:src/org/apache/fop/fo RecursiveCharIterator.java
Log:
Fix a small bug in iterator
Revision ChangesPath
1.2 +2 -0 xml-fop/src/org/apache/fop/fo/RecursiveCharIterator.java
Index: RecursiveCharIterator.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fo/RecursiveCharIterator.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RecursiveCharIterator.java2001/11/21 22:13:36 1.1
+++ RecursiveCharIterator.java2001/11/26 21:11:06 1.2
@@ -32,6 +32,8 @@
public Object clone() {
RecursiveCharIterator ci = (RecursiveCharIterator)super.clone();
ci.childIter = fobj.getChildren(ci.curChild);
+ // Need to advance to the next child, else we get the same one!!!
+ ci.childIter.next();
ci.curCharIter = (CharIterator)curCharIter.clone();
return ci;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug in fo:basic-link
Hello, I found a bug in fo:basic-link internal-destination where it can't do internal link for fop 0.20.1. During run fop0.20.1, if the document have more then one page and the fo:basic-link internal-destination in one page and fo:block id in another page then the fop were given me an error This id already exists in document.. Any how the document just have only one internal link only. When I tried to used fop 0.19 can solved this. So, I think this is a bug in Fop 0.20.1. Do fop-dev going to solved this problem? (See attached file: sample1.fo)(the file I used to run fop 19 and fop 20) Hope to get reply from fop-dev soon Thank you. lpkhoo sample1.fo Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
HELP: PDF generation hangs
Hi, I have a problem when I try to generate a PDF file from a FOP file that contains an SVG image. It doesn't matter if the image is inline or if it's stored as a separate file. My problem is that the PDF file gets generated but for some reason the java thread hangs, i.e. even though the work is finished it doesn't stop executing. Has anyone else encountered this problem? Here's the piece of code that I'm using to render the PDF: Hierarchy hierarchy = Hierarchy.getDefaultHierarchy(); Logger log = hierarchy.getLoggerFor(fop); log.setPriority(Priority.DEBUG); Driver driver = new Driver(new InputSource(new StringReader(template.toString())), outputStream); driver.setLogger(log); driver.setRenderer(Driver.RENDER_PDF); driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.run(); This code generated this output: INFO10068 [fop ] (): building formatting object tree DEBUG 10068 [fop ] (): setting up fonts INFO10068 [fop ] (): [1] INFO10068 [fop ] (): Parsing of document complete, stopping renderer DEBUG 10068 [fop ] (): Initial heap size: 1569Kb DEBUG 10068 [fop ] (): Current heap size: 2689Kb DEBUG 10068 [fop ] (): Total memory used: 1119Kb DEBUG 10068 [fop ] (): Memory use is indicative; no GC was performed DEBUG 10068 [fop ] (): These figures should not be used comparatively DEBUG 10068 [fop ] (): Total time used: 8993ms DEBUG 10068 [fop ] (): Pages rendererd: 1 DEBUG 10068 [fop ] (): Avg render time: 8993ms/page Thanks in advance, Vladimir Sneblic Software Engineer Sytec Resources Limited Phone: +64 9 917-4264 Fax:+64 9 355-0070 Mobile: +64 21 404046 Email: [EMAIL PROTECTED] WWW: http://www.sytec.co.nz Important: This electronic mail message and attachments (if any) are confidential and may be legally privileged. If you are not the intended recipient please contact us immediately and destroy this message. You may not legally copy, disclose, disseminate or use the contents in any way. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Merging jfor into FOP - what's the plan?
Hi Keiron, If there is not going to be a FOP release in the next few weeks, I agree that a minimal integration does not make sense. Currently the jfor conversion is driven directly from SAX events, so the first thing that comes to mind is driving it from the FO tree. You're right that, contrary to print renderers, the RTF one will need to know about the structure of the original document. Does the FO tree handle things like attribute inheritance (i.e. a block inherits the font definition from an ancestor block), or is this handled while doing the layout? Such inheritance is currently missing in jfor. To summarize: -jfor needs to know about the original document structure: speaks for option (A), plugging jfor right after the FO tree stage if I understand well. -BUT jfor could probably benefit from some operations done at the layout stage (attributes inheritance, others?) : speaks for option (B), extending the renderer interface to let the renderers know (cleanly) about the original document structure. If you can give me some pointers about where to look at in the code to evaluate (A) and (B), I'll have a look. - Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
