Re: Code Style, was Re: PDF serialization
On Tue, 17 Jul 2001 01:22:38 Arved Sandstrom wrote: At 09:26 PM 7/16/01 +1000, Mark wrote: As an aside: is there a style guide for FOP code? I must say I find the style and layout very confusing and I'm happy to clean things up as I go. At the moment I can't even work out what tab stop size people are using. (In my own work I use 8 character tabs with 2 character indenting). Yep. http://xml.apache.org/source.html references the Sun Java coding conventions, at http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html. An interesting point that comes out of the coding conventions is that while Sun instructs us that tabs must be 8 spaces, they also state that the unit of indentation is 4 spaces. Seems to me that the easiest way to avoid problems is never to leave tabs in the code - I use a text editor that is set to 4 spaces per tab and immediately translates tabs to spaces. We are well past the point where we should take a style tool to the whole codebase, strip out all tabs, and re-commit the whole thing. :-) From what I have seen so far we are never going to get a common code style. I usually format the code but that doesn't mean it will stay that way and there are a lot of files. eg. Arved committed in some of the Marker code with tabs to replace the spaces (musn't have been using the right text editor). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF serialization
Mark, I think the first step would be to change the PDF generation code so that it can write out as it goes to a stream (and also do what it does now). This would most likely be done by writing out each page after completion. It may also (I'm not sure) require different tracking of objects such as XObjects for images. From there the changes required to the PDFRenderer itself should not be too difficult. The PDF spec should give your more information (and give you a headache or two). On Mon, 16 Jul 2001 13:26:13 Mark wrote: Hi ho fops and fopettes, I have had a look at the memory use of my modified-for-streaming FOP executable and determined that the primary memory constraint is now in the PDF renderer. Basically, because the PDF renderer keeps all objects in memory until the end, this obviously limits the size of the output document. I can't say if other renderers have this issue because I haven't looked. I have had a look at the PDF renderer and I think it should be possible to serialize it with only a minimal amount of data being kept in RAM. However this will require extensive changes to the PDF renderer, because there doesn't seem to be a single point at which I can cleanly introduce the changes. Presumably these changes will be backwards-compatible with the current FOP since I don't want to actually change the code path, just make it so that the results are written earlier. So I was wondering if there was someone I should be speaking with directly about the changes that I want to make, or if I should just barge on ahead and make them, damn the torpedoes pip pip old chap? I would prefer some guidance about this because I don't actually know anything about PDF, but the code is well commented. Obviously my primary interest is in the PDF renderer at this stage, but I'm interested to know if other renderer writers are interested in my work? As an aside: is there a style guide for FOP code? I must say I find the style and layout very confusing and I'm happy to clean things up as I go. At the moment I can't even work out what tab stop size people are using. (In my own work I use 8 character tabs with 2 character indenting). Cheers Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF serialization
FWIW the PCL renderer should not be keeping much in memory. The same applies to the PostScript renderer and (I think) to the MIF renderer, which was my starting point for the PostScript renderer. Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG 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]
Rendering SVG as Image by Batik?
I'm looking at print renderers. Can this be done? Input like sample instream.fo: fo:instream-foreign-object svg:svg width=20 height=20 Generation of print renderer output is started by method renderForeignObjectArea: - The foreign SVG object has rendered itself as image by Batik. The method renderForeignObjectArea has to tell Batik o the image format 'JPG', area size, resolution, o the SVG tree passed by FOP o Batik returns the image in memory. - The rendering method inserts the image with required control info into the output stream. Sounds quite powerful - is there such an easy way? Johannes U. Anderegg mailto:Anderegg,[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Rendering SVG as Image by Batik?
Johannes, If you are going to be using this for a print renderer and you are going to have it in memory why do you want to convert it into a jpeg. In the AWTRenderer it currently renders the svg into a graphic if that would suit you needs. Otherwise you can simply use the batik transcoding interface to convert the svg into jpeg, png. I'm not sure if it can return the data in memory though. Keiron. On Tue, 17 Jul 2001 09:10:43 [EMAIL PROTECTED] wrote: I'm looking at print renderers. Can this be done? Input like sample instream.fo: fo:instream-foreign-object svg:svg width=20 height=20 Generation of print renderer output is started by method renderForeignObjectArea: - The foreign SVG object has rendered itself as image by Batik. The method renderForeignObjectArea has to tell Batik o the image format 'JPG', area size, resolution, o the SVG tree passed by FOP o Batik returns the image in memory. - The rendering method inserts the image with required control info into the output stream. Sounds quite powerful - is there such an easy way? Johannes U. Anderegg mailto:Anderegg,[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
nullPointerException
Hi all, I am trying to get an XMLReader object with XMLReader parser = inputHandler.getParser(); after having done: InputHandler inputHandler = new XSLTInputHandler(xmlInputSource,xslInputSource); and I get the following error (the files xmlInputSource and xslInputSource are where they are suppossed to be): java.lang.NullPointerException Caught exception: java.lang.NullPointerException java.lang.NullPointerException at org.apache.fop.apps.InputHandler.createParser(InputHandler.java:58) at org.apache.fop.apps.XSLTInputHandler.getParser(XSLTInputHandler.java:117) at TestXSLT.init(TestXSLT.java:29) It seems to me that I am missing some library, but I am using fop, xerces and xalan in that order, as I was told others where doing, with a program that worked for others. Does anyone have an idea of what could be wrong? Thanks really a lot, Gustavo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Java Extensions in Xalan vs Fop
I hear your pain, brother. :-) So I have enclosed a ZIP which contains all the files I used, on Windows 98, to make this work - the XML, XSL, the extension class (source and compiled classfile), a batch file to run things, even the PDF output. Father Arved, thank for you for your preaching! Ok, this initially didn't work, but the bat file made me notice something that I'd not seen before. My classpath was too long for the commandline that you included in the batch file to run. Thinking this might have something to do with it I cut it all down to just the FOP and Xalan stuff that I need right now. Lo! All worked out of the tin. All my example files, your batch file -- pretty much everything I've been playing with since Thursday. So, the evils of the CLASSPATH seem to have struck again. For the record, everything you'd included in your example I had in my classpath (bar the example java I'd written), but it just seemed to get ignored. Removing bits make all the difference. That is some weight off my shoulders, although I feel a little silly having wasted so long playing around with it! Thank you again for your help and support. Best Regards Gareth Noyce - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
I18n issue in AWT Preview
Hello FOP developers! May be this is known issue, however I didn't find any comments. There is some problems on i18n support in AWT preview. You are using your own SecureResourceBundle with LoadableProperties instead of standart ResourceBundle for loading the text labels. May be there is good reason for doing that, but this is lead to problems for languages with non-8859_1 characters. For instance, russian language does not fit there. In standart PropertyResourceBundle there is support for unicode escape (\u), but in LoadableProperties such thing does not exists. Of course I can write my own dialog, but for begginers it would be better to fix such issue. Regards, Sergey Astakhov ([EMAIL PROTECTED]) COMITA Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF serialization
Hi, On 16 Jul 2001 14:24:06 -0400, Art Welch wrote: FWIW the PCL renderer should not be keeping much in memory. It seems to keep the whole PDF document in RAM until it's closed. But I have worked out a sneaky way to pipeline the PDF without major changes, thanks mostly to the thinking time I got while spending today removing six cubic meters of debris from my house renovations instead of working :) BTW earlier you had mentioned that the buf option slowed things down. I would expect that pipelining things would improve performance, has this been the case? If so, how much? Yes, I found -bug to have a significant impact on performace after about 100 pages. Before 100 pages there did not appear to be a (subjective) impact. At this time I have not done any benchmarks but subjectively it does seem faster with pipelining, probably because it's allocating a lot less RAM (10Mb instead of 64Mb for ~200 page documents) It seems to me that with the exception of a few details (like ID References, etc) FOP would be an ideal application for pipelining. It seems pretty easy, given that I'm new to FOP I have had quite a deal of success! Tonight I intend to apply my ideas to the PDF renderer and if that works I'll look at the other renderers and then make a Plan to build a Patch. Keep up the good work, Thanks for the encouragement! Cheers Mark
Re: bit OT but..streaming PDF to browsers
Hi, I've been on holiday, but I came back yesterday, saw this last message, downloaded SP1 for IE5.5 and, hey presto, it worked. Thanks to all for your help - much appreciated. Just to confirm, IE5.5 still caused problems - only with SP1 did it work for me. Thanks again, Micheál - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 06, 2001 1:35 AM Subject: Re: bit OT but..streaming PDF to browsers Thanks so much for the help the ContentDisposition worked like a charm on ie5 5.5sp1 :) cheers Dave David Frankson [EMAIL PROTECTED] on 07/06/2001 03:47:43 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: bit OT but..streaming PDF to browsers Check the Microsoft Knowledge base for Article ID: Q293336 It explains the idiotic way IE handles MIME types. Dave - Original Message - From: Alex McLintock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 9:07 AM Subject: Re: bit OT but..streaming PDF to browsers --- Dave Frankson [EMAIL PROTECTED] wrote: PDFs from a servlet works in all broswers but you have to remember to do all of the following: 1.) Set the headers: response.setContentType(application/pdf); response.addHeader(Content-Disposition, inline; filename=report.pdf); Your other suggestions I've heard of before - but haven't noticed this one. Does it really work? What browsers support Content-Disposition ? Where can I find out more? Presumably I ought to add it to the FAQ. Cheers Alex = Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ DR WHO COMPETITION: http://www.diversebooks.com/cgi-bin/caption/captions.cgi?date=200104 Get Your XML T-Shirt t-shirt/ at http://www.inversity.co.uk/ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - 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: Keep-together (and the other keep-*'s)
At 09:36 AM 7/17/01 +0100, Alex McLintock wrote: --- Struan Judd [EMAIL PROTECTED] wrote: If so might I request a small departure from the XSL:FO spec, if it is straight-forward to implement. Please allow keep-together on fo:table-row. I don't think deviations from the XSL:FO spec are either wise or going to be popular. Can't comment on this particular request, but I'm personally pretty sure that a number of deviations from the spec _would_, in fact, be quite popular. FOP is developmental immature; the last thing we need is to deliberately add in non-conformities to the ones that are already there. For a commercial, relatively mature processor like XEP, I think arguments can be made for some careful deviations from spec, and indeed they (RenderX) have made some such here and there (borders on regions, for example). Personally I would argue against doing _anything_ like that right now, until FOP is feature-complete and production-ready. Then it could be revisited. Even then I would be normally against it, but not inflexibly so, because the XSL 1.0 spec just does not cover all the bases, and it doesn't do everything right. And who knows when XSL 2.0 will appear? As an aside, we are clearly not talking about extensions. Separate issue. I think those are fine. Regards, Arved Sandstrom Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PDF serialization
My apologies, I said: Yes, I found -bug to have a significant impact on performace after about 100 pages. Before 100 pages there did Of course, I meant -buf! Who put those two letters so close together anyway? Cheers Mark
Re: Keep-together (and the other keep-*'s)
Im XSL FO spec in article 6.7.9 fo:table-row keep-together, keep-with- previous and keep-with-next properties are listed in The following properties apply to this formatting object:. So why is keep-together on table-row considered against spec? pa On 17 Jul 2001, at 9:36 Alex McLintock wrote about Re: Keep-together (and the other ke : --- Struan Judd [EMAIL PROTECTED] wrote: If so might I request a small departure from the XSL:FO spec, if it is straight-forward to implement. Please allow keep-together on fo:table-row. I don't think deviations from the XSL:FO spec are either wise or going to be popular. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Rendering SVG as Image by Batik?
I'm looking at print renderers. Can this be done? Input like sample instream.fo: fo:instream-foreign-object svg:svg width=20 height=20 Generation of print renderer output is started by method renderForeignObjectArea: - The foreign SVG object has rendered itself as image by Batik. The method renderForeignObjectArea has to tell Batik o the image format 'JPG', area size, resolution, o the SVG tree passed by FOP o Batik returns the image in memory. - The rendering method inserts the image with required control info into the output stream. Sounds quite powerful - is there such an easy way? Johannes U. Anderegg mailto:Anderegg,[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP 0.19 with JDK1.1
On Tue, 17 Jul 2001 13:10:50 Stephen Fry wrote: Is it still possible to run the latest version of FOP with JDK1.1. Currently I am using 0.15 and I need to assess the risks in moving to a newer version. We have done a quick test and it seems that it now has a dependency on batik which requires JDK 1.2 onwards. Can someone clarify the position please. Thanks Stephen Fry You certainly need jdk1.2 to compile it now. There is a good chance that you also need jdk1.2 to run it. Personally I think that 2.5 years is enough time to migrate to a new version. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP 0.19 with JDK1.1
I'm using FOP 0.19 with JDK 1.1.8 on Windows NT/2000 and Sun Solaris with no problems. But batik does not work with JDK 1.1. That means no SVG :-( Heiko Is it still possible to run the latest version of FOP with JDK1.1. -- Mit freundlichen Gruessen / Best regards Heiko Barthel http://www.wilschdorf.de/heiko mailto:[EMAIL PROTECTED] ... und da waren ja noch die 3 großen Tragödien dieses Jahrhunderts: Hiroshima 45 - Tschernobyl 86 - Windows 95 GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net GMX Tipp: Machen Sie Ihr Hobby zu Geld bei unserem Partner 11! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a Title: FOP 0.19 with JDK1.1 Is it still possible to run the latest version of FOP with JDK1.1. Currently I am using 0.15 and I need to assess the risks in moving to a newer version. We have done a quick test and it seems that it now has a dependency on batik which requires JDK 1.2 onwards. Can someone clarify the position please. Thanks Stephen Fry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: I18n issue in AWT Preview
Hello Sergey, Tuesday, July 17, 2001, 11:17:03 AM, you wrote: SA Of course I can write my own dialog, but for begginers it would be better to SA fix such issue. Remove from org.apache.fop.viewer.LoadableProperties second parameter in line 28. before: BufferedReader in = new BufferedReader(new InputStreamReader(inStream,ISO_8859_1)); after: BufferedReader in = new BufferedReader(new InputStreamReader(inStream)); -- Best regards, Eugenemailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF streaming
Howdy foponauts Well I was able to find the PDF 1.3 reference (@ pdfzone - google is Great) and I'm just running a huge test. I was able to process 100 pages with a flat memory profile and 2Mb of heap so it's looking pretty good, but my Big Test has destroyed all pretenders to date so we'll see -- it's running now. However I now believe that the PDF I'm generating is not quite 100% of the kosher variety. I delay writing the /Pages object until the end of the document (I have a list of PDFReferences as the kids) and that's all fine and seems to work OK in xpdf. However the problem is that each /Page object is apparently supposed to refer to it's parent /Pages object. I can't see how I can have a link to a Pages object that's not written yet, with an object reference I don't know yet, but apparently /Parent is mandatory. How can I avoid writing the list of Pages until the end of the document if each page has to refer to that list? At the moment there is a /Parent but the object ID is -1. (What is the correct term for the number in an indirect reference?) The spec says that what I want to do is possible but not how (that I can find); I was wondering if someone with more experience with PDF might be able to help me. As I understand it there can be multiple /Pages objects and I was wondering if that's somehow what I'm supposed to use. But as Keiron suggested, I read the bits of the spec that seemed important and now I have a headache. :-} Cheers Mark P.S. my test document has written 11K pages of 18K so far.. looking good!
Big success; structural questions
Hi again, Firstly I have successfully tested my changes with a ~20,000 page document of moderate complexity, it is in fact one of the example documents but I forget which one (doh) - multiplied by some silly factor like 5000 or something. I have also successfully tested my changes against a 120-odd page version of 'docs/examples/svg/embedding.fo' - that three page file x forty-something. I would try it on a bigger file but I need to sleep instead; I'll set one of my machines going on a really big file tomorrow just to see where the limits are. I haven't looked at the heap size growth yet but I expect a very small linear growth since the PDF still has to maintain a list of references for each page. Still, that's quite tiny and probably can be optimized significantly if it becomes a problem. I have some questions regarding the structure of FOP and how my changes might be integrated into the main tree, assuming of course that they are desired and the PDF page parent issue can be sorted out. Firstly it could be argued that I have violated one of the secondary design principals of FOP, namely that the separation between parsing/formatting/rendering has suffered a warp core breach. In fact I think I have managed to keep the separation pretty clear, but at some point control has to move from the parser to the formatter/renderer and this is no longer done by the caller. By this I mean that the thread running SAX is now running the formatting and rendering. Does anything see this as a huge problem? (What is the plan for FOP 0.20 anyway?) At the moment I am doing this in a horrid hack in FOTreeBuilder because that's just the most obvious place to find where the fo:page-sequence element ends. I also initialize and close the renderer in FOTreeBuilder using some new methods I had to add (PDF specific atm). I am not certain that FOTreeBuilder is the right place for this code, but it might be. Any suggestions? I like the idea of a bridging class actually; ParserRenderer or something, that FOTreeBuilder uses. Secondly, because of the change in the rendering sequence I am afraid that other renderers might not work any more, especially not the AWT renderer. I was wondering if anyone would like to help me with these other renderers? The changes are fairly straightforward. I am happy to work on the AWT renderer and can probably work out the PCL renderer, but if my code might be accepted into the tree then it would probably be beneficial if someone else knew broadly what I've been up to. I don't have any PCL devices handy so I would have some difficulty testing any changes I make. And I'm not even sure what MIF is, some sort of interchange format .. ? I would also like to hear from anyone who would like to test the changes for me. I am not extensively well-versed in XML:FO, PDF, XML or anything else for that matter, and it would be good to find out if I've broken anything serious or if there are any remaining cases where references are being held too long and we have memory leaks. (Are there automated tests?) I'm also interested in some performance comparisons, we allocate a lot less memory now and GC takes much less time, so maybe someone might be interested in doing that. I can provide the source and/or .jar files for people to play with, drop me a line. (note: the source, apart from the renderer, is horrible, tomorrow I will be cleaning it up and working out the data flows properly). Anyway sorry for my verbose discussions of these things, it seems I'm a bit of a letter writer by nature. Cheers Mark
RE: Multithreading
I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Multithreading
We are planning to use FOP in our web application. The application will be hosted on a W2K box with dual PIIIs. We will use FOP in servlets to allow the user to dynamically generate formatted reports (in PDF) that can be printed off and inserted in a patients permanent medical file. Does this mean we can expect performance problems from our print servlets? Jim Urban Product Manager Netsteps Inc. Suite 505E 1 Pierce Pl. Itasca, IL 60143 Voice: (630) 250-3045 x2164 Fax: (630) 250-3046 -Original Message- From: Jim Cotugno [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: RE: Multithreading I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - 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: Spanning a table over many pages
I grabbed the latest out of CVS today and built it. FOPped everything just fine. Thanks for pointing me in the right direction. Mick -Original Message- From: Huisking, Michael [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 3:33 PM To: '[EMAIL PROTECTED]' Subject: Re: Spanning a table over many pages OK, I'm attaching a zip file containing three .fo files. They are all generated from the same data (I manually modified the title of the report). The file called threecol.fo is a three column report that generates 2 pages (correct). The file called fourcol.fo is a four column report that generates 2 pages but truncates some data. The file called fivecol.fo is a five column report that only generates 1 page, the whole 2nd page is truncated. I looked at them, but am not quite sure why the renderer treats them differently. Thanks again. Mick -Original Message- From: Karen Lease [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 1:24 PM To: [EMAIL PROTECTED] Subject: Re: Spanning a table over many pages Hi Michael, Normally this should work. Which version of FOP are you using? There is a bug fix in CVS for a problem which sometimes caused tables to overestimate the space left on the page. If it's possible for you, you may want to try using the latest CVS version of FOP. Or post the FO file which is being created by your XML and XSL so that I can check it out. HTH, Karen Lease Huisking, Michael wrote: Hi. My xsl-region-body is defined like this: fo:flow flow-name=xsl-region-body fo:table border-style=solid border-width=0.5pt xsl:copy-of select=$ColumnWidths/ fo:table-body xsl:apply-templates select=DATAPACKET/ /fo:table-body /fo:table /fo:flow The flow contains one table (about 93 rows in this case). When the 1st page of the flow fills with table rows, a new page isn't being created -- when I run FOP only 1 page is created with all of the additional rows just running off the bottom. (This should produce a 3 page report -- 1 table spanning 3 pages) Do I need to specify pagination values for the table? What am I doing wrong? Thanks in advance. Mick Huisking - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2489] - leader CID font bug
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2489 *** shadow/2489 Fri Jul 6 17:15:29 2001 --- shadow/2489.tmp.29458 Tue Jul 17 13:24:52 2001 *** *** 2,9 | leader CID font bug| ++ |Bug #: 2489Product: Fop | ! | Status: NEW Version: all | ! | Resolution:Platform: All | | Severity: MajorOS/Version: Other | | Priority: Other Component: pdf renderer| ++ --- 2,9 | leader CID font bug| ++ |Bug #: 2489Product: Fop | ! | Status: RESOLVEDVersion: all | ! | Resolution: DUPLICATE Platform: All | | Severity: MajorOS/Version: Other | | Priority: Other Component: pdf renderer| ++ *** *** 82,85 } WordArea leaderPatternArea = new WordArea(currentFontState, this.red, this.green, ! == --- 82,90 } WordArea leaderPatternArea = new WordArea(currentFontState, this.red, this.green, ! == ! ! --- Additional Comments From [EMAIL PROTECTED] 2001-07-17 13:24 --- ! ! ! *** This bug has been marked as a duplicate of 2556 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Bug 2556] - fo:leader has strange behavior when used with CID encoded Embedded TTF
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2556 *** shadow/2556 Tue Jul 17 13:24:53 2001 --- shadow/2556.tmp.29518 Tue Jul 17 13:29:01 2001 *** *** 2,9 | fo:leader has strange behavior when used with CID encoded Embedded TTF | ++ |Bug #: 2556Product: Fop | ! | Status: NEW Version: all | ! | Resolution:Platform: Other | | Severity: Normal OS/Version: Other | | Priority: Other Component: general | ++ --- 2,9 | fo:leader has strange behavior when used with CID encoded Embedded TTF | ++ |Bug #: 2556Product: Fop | ! | Status: RESOLVEDVersion: all | ! | Resolution: FIXED Platform: Other | | Severity: Normal OS/Version: Other | | Priority: Other Component: general | ++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: xml-fop/src/org/apache/fop/fonts TTFFile.java
tore01/07/17 13:57:49
Modified:src/org/apache/fop/fonts TTFFile.java
Log:
Submitted by: SASAKI Suguru ([EMAIL PROTECTED])
Some glyphs are missed when more then one glyph maps to the same data,
this patch fixes it.
Revision ChangesPath
1.5 +10 -5 xml-fop/src/org/apache/fop/fonts/TTFFile.java
Index: TTFFile.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/fonts/TTFFile.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TTFFile.java 2001/04/16 16:07:30 1.4
+++ TTFFile.java 2001/07/17 20:57:47 1.5
@@ -1,4 +1,4 @@
-/* -- $Id: TTFFile.java,v 1.4 2001/04/16 16:07:30 tore Exp $ --
+/* -- $Id: TTFFile.java,v 1.5 2001/07/17 20:57:47 tore Exp $ --
*
* Copyright (C) 2001 The Apache Software Foundation. All rights reserved.
* For details on use and redistribution please refer to the
@@ -200,14 +200,15 @@
lastChar = (short) j;
if (mtxPtr mtx_tab.length) {
+int glyphIdx;
if (cmap_rangeOffsets[i] != 0) {
int glyphOffset = glyphIdArrayOffset +
((cmap_rangeOffsets[i] / 2) +
(j - cmap_startCounts[i]) + (i) -
cmap_segCountX2 / 2) * 2;
in.seek_set(glyphOffset);
-int glyphIdx = (in.readTTFUShort() +
-cmap_deltas[i]) 0x;
+glyphIdx = (in.readTTFUShort() +
+cmap_deltas[i]) 0x;
unicodeMapping.addElement(
new UnicodeMapping(glyphIdx, j));
@@ -254,7 +255,7 @@
}
else {
-int glyphIdx = (j + cmap_deltas[i]) 0x;
+glyphIdx = (j + cmap_deltas[i]) 0x;
if (glyphIdx mtx_tab.length)
mtx_tab[glyphIdx] .unicodeIndex.addElement(
@@ -308,7 +309,11 @@
mtx_tab[(j+cmap_deltas[i]) 0x].name);
*/
}
-mtxPtr++;
+if (glyphIdx mtx_tab.length) {
+if (mtx_tab[glyphIdx].unicodeIndex.size() 2) {
+mtxPtr++;
+}
+}
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Not all glyph is loaded when two or more char aremapped to one glyph
Thanks for the patch!
I just added it to cvs.
Tore
On Thu, 12 Jul 2001, SASAKI Suguru wrote:
Hi, fop-team.
Current org.apache.fop.fonts.TTFFile dosen't load all glyph data
when two or more character is mapped to one glyph.
(In fact, Bitstream Cybetbit font has mapped many characters to
missingGlyph (glyphIndex = 0)).
Some character dosen't appear in outputs because of this.
This pacth will fix this problem.
===
SASAKI Suguru
mailto : [EMAIL PROTECTED]
--- src/org/apache/fop/fonts/TTFFile.java.origTue Apr 17 01:07:30 2001
+++ src/org/apache/fop/fonts/TTFFile.java Thu Jul 12 01:37:20 2001
@@ -200,13 +200,14 @@
lastChar = (short) j;
if (mtxPtr mtx_tab.length) {
+int glyphIdx;
if (cmap_rangeOffsets[i] != 0) {
int glyphOffset = glyphIdArrayOffset +
((cmap_rangeOffsets[i] / 2) +
(j - cmap_startCounts[i]) + (i) -
cmap_segCountX2 / 2) * 2;
in.seek_set(glyphOffset);
-int glyphIdx = (in.readTTFUShort() +
+glyphIdx = (in.readTTFUShort() +
cmap_deltas[i]) 0x;
unicodeMapping.addElement(
@@ -254,7 +255,7 @@
}
else {
-int glyphIdx = (j + cmap_deltas[i]) 0x;
+glyphIdx = (j + cmap_deltas[i]) 0x;
if (glyphIdx mtx_tab.length)
mtx_tab[glyphIdx] .unicodeIndex.addElement(
@@ -308,7 +309,11 @@
mtx_tab[(j+cmap_deltas[i]) 0x].name);
*/
}
-mtxPtr++;
+if (glyphIdx mtx_tab.length){
+if(mtx_tab[glyphIdx] .unicodeIndex.size() 2){
+mtxPtr++;
+}
+}
}
}
}
-
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: leader bug and here is a patch
Sorry for not looking at your patch until now, but I've been on vacation
(a couple of weeks with the cellular turned off and no email access can
actually be quite satisfying!).
The mapping from char to glyph is moved to the PDFRenderer, so there
should be no need to map the chars again (only for calculating widths).
However, the leaders with space patterns was still rendered wrong. That's
because actual spaces was used, I changed it to use InlineSpace. Most
fonts doesn't contain an actual space glyph, but instead maps it to the
missing glyph which usually is just a square.
Tore
On Wed, 4 Jul 2001, Hin-Tak Leung wrote:
Apply this patch to:
xml-fop/src/org/apache/fop/layout/LineArea.java
A bug was introduced between version 1.42 and 1.43 of LineArea
which uses a lot of mapChar to cope with bug 1618 (CVS log has
a typo error instead to 1681), and forgot to change the
leader calculation.
This bug should have caused FOP to crash with any XSL:FO input
that has a leader with dots or space with non-pdf-standard
fonts. I wonder why nobody spotted it in release 0.19? My
last CVS build was May 16 and it worked fine - the fatal bug
was introduced on 12 June and went into release 0.19 and
went unreported for nearly a month...
Somebody please patch this into the CVS tree?
=
*** LineArea.java-bad Tue Jun 12 12:37:42 2001
--- LineArea.java Wed Jul 4 00:44:44 2001
***
*** 751,769
* creates a leader as String out of the given char and the leader
length
* and wraps it in an InlineArea which is returned
*/
! private InlineArea buildSimpleLeader(int charNumber, int leaderLength) {
! int width = this.currentFontState.width(charNumber);
if (width == 0) {
- char c = (char) charNumber;
MessageHandler.errorln(char + c + has width
0. Using width 100 instead.);
width = 100;
}
int factor = (int) Math.floor (leaderLength /
width);
char [] leaderChars = new char [factor];
- char fillChar = (char) charNumber;
for (int i = 0; i factor; i ++) {
! leaderChars[i] = fillChar;
}
WordArea leaderPatternArea =
new WordArea(currentFontState, this.red, this.green,
--- 751,767
* creates a leader as String out of the given char and the leader
length
* and wraps it in an InlineArea which is returned
*/
! private InlineArea buildSimpleLeader(char c, int leaderLength) {
! int width =
this.currentFontState.width(currentFontState.mapChar(c));
if (width == 0) {
MessageHandler.errorln(char + c + has width
0. Using width 100 instead.);
width = 100;
}
int factor = (int) Math.floor (leaderLength /
width);
char [] leaderChars = new char [factor];
for (int i = 0; i factor; i ++) {
! leaderChars[i] = c;
}
WordArea leaderPatternArea =
new WordArea(currentFontState, this.red, this.green,
==
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
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: Keep-together (and the other keep-*'s)
Subject: Re: Keep-together (and the other keep-*'s) It's not against spec in my book either, but it's currently not implemented in FOP, for table-row or for anything else. The problem with all that keep-* stuff is that it's not that easy to do. Actually, I was kind of mulling it over for table-rows, but so far, I haven't gotten around to it. Karen And on a carefuly re-reading of the Spec I see what caused my confusion. In 6.7.9 the keep-together attribute is noted as applying to fo:table-row, whereas in 7.18.3 (where I was looking when I wrote my inital email), fo:table-row is missing from the list of objects the keep-together attribute applies to. Ooops. And as to difficult to do. I bet. But very useful. I might just have to make some home programming time and dive in. TTFN Struan Judd * And so it begins ... ICQ: 4498196 http://neongraal.sf.org.nz mailto:[EMAIL PROTECTED] Voicemail and Fax: +1 (201) 305-1011 x1006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Some sample
Hello, Is there any example or tutorial to show how to transform from xml to pdf or from xml to fo in java? Since I write a servlet to transform a xml and xsl to a fo and always a FOPException appear like at org.apache.fop.apps.XSLTInputHandler.getParser(XSLTInputHandler.java: 109), is there I use the wrong method??? Thanks for your help. Regards, Patrick Lee == ·s®ö§K¶O¹q¤l«H½c http://sinamail.sina.com.hk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Code Style, was Re: PDF serialization
At 11:25 PM 7/17/01 +0200, Tore Engvig wrote: [ SNIP ] I guess we have to use codeformatters (eg astyle) before we check in our code. I happend to grab a copy of jIndent while it still was free. jIndent does more than just codeformatting, it parses the code and is able to change a lot of things (eg bracket style, set a max linelength, etc). I could reformat the whole repository with jIndent, then we could continue with using astyle or some other free codeformatter as we go. Just pick a day. It would be best if everybody have checked in their changes before reformatting the whole source (and I guess I should tag the repository before reformatting). Hi, Tore Well, how about _you_ set the day, since you're the volunteer? :-) I tend to agree with your comments about cvswrappers, and you're right, why not try the logical first approach, which is that all committers make a point of running the code beautifier of their choice before making commits? We have not in a long time, if ever, put our foot down and said that this is the way it will be - it's been pretty lackadaisical so far. So, once you have reformatted everything, and recommitted, all committers would be on notice to adhere to code conventions. It would be useful if you can work in license long-form - short-form translation also. A tag is a good idea, I agree. Who knows what might happen? Thanks in advance for doing this. Regards, Arved Fairly Senior Software Type e-plicity (http://www.e-plicity.com) Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Multithreading
In the interim (i.e. until code improvements), did you try multiple *processes* rather than threads, i.e. to ensure multiple copies of statics, etc, so contention within a process is eliminated? It may well still be that other forms of contention limit the throughput -Original Message- From: Jim Cotugno [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 1:10 PM To: [EMAIL PROTECTED] Subject: RE: Multithreading I don't know if anyone has done any extensive testing of concurrency with FOP, so please let us know what problems you run into (the IndexOutOfBounds for example), either via this list, or better yet, via Bugzilla so we can track and fix the issues. I've fixed a few places where I found concurrency issues at one time, but I'm sure there are others I didn't find. When we attempted to use FOP in a multi-processor, multi-threaded Windows NT 4.0 environment, we found that FOP actually worked SLOWER than a single processor and/or single-threaded environment. We ran multiple threads that were responsible for rendering separate documents. We were trying to reduce the elapsed time necessary to render thousands of relatively small (10- 20 page) documents. What we found was running multiple FOP threads on a multi- processor Windows NT box reduced our total throughput. We processed more documents per hour with a single FOP thread than we did with multiple FOP threads. Note that I'm refering to total throughput, not documents per thread per hour. Some analysis pointed to VERY HIGH context switching going on when running two FOP threads on a two processor system. What this told us was that the two FOP threads were fighting over the same piece(s) of memory continuously. This context switching went away when we ran multiple FOP threads on a single processor machine or we ran a single FOP thread on a multi-processor machine. I spent some time looking at the source code, and noticed a large number of statics being declared all throughout FOP. This may be a cause, or it may have something to do in the way the Sun jvm works on Windows. I didn't have the time to dig deeper. I don't remember the exact version of FOP we used for the test. It may have been 0.18.1 or 0.19.0-CVS. Jim Cotugno Upstanding email: [EMAIL PROTECTED] home email: [EMAIL PROTECTED] phone: 949-453-2000 fax:949-453-2001 - 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: Code Style, was Re: PDF serialization
May I suggest to put up a code convention section in involved.xml? I think a short notice with the most important rules (tabs to spaces, 4 spaces for tab etc.) will suffice. That will make it easier to encourage people to follow the conventions. Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG 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]
