Re: FOP Bug - 42307
On Jun 19, 2008, at 18:37, [EMAIL PROTECTED] wrote: Hi I am from FirstApex Technologies, Bangalore and into Insurance Product Development. We are facing a similar issue in our product implementation in the Middle East, as reported in the bug report below - Bug Number 42307. We are using JFO to convert RTF documents in Arabic to PDF. I suspect you are referring to JFOR, which is a currently inactive Sourceforge project. The code has been donated to and merged into Apache FOP, and as of versions 0.9x, FOP also provides RTF output. However after conversion, the character ordering gets reversed as mentioned in the bug report. I understand that JFO uses FOP Technology to render PDF. Is this bug resolved? If not kindly provide us an alternative solution, since we will have to move our product to Live in less than 3 weeks time and we are running out of options. https://issues.apache.org/bugzilla/show_bug.cgi?id=42307 AFAIK, the problem still exists in the current FOP version (0.95), simply because up to now, no one has really needed Arabic text badly enough. The only viable alternatives are either: - use a commercial FO implementation - help us improve FOP by submitting a patch to fix the problem KR Andreas
Re: Check: use of 'short' in TextLayoutManager?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas, The JVM converts all shorts to ints before doing any arithmetic, so shorts are actually a little bit slower than ints. As for the size: If you have primitive values, an int takes up 4 byte, whereas a short takes 2 bytes (+java overhead), meaning 100.000 * 3 int rather than shorts should take up 600kbyte of memory more - hardly noticeable compared to fops overall memory usage. When you use the non-primitive types, java = 1.5 uses the flyweight pattern, meaning there is one instance for every number used, you would only store a pointer, which has the same size for Integer and Short. So +1 for making this change. Max Andreas Delmelle schrieb: Hi all Just checking if anyone would mind terribly if the AreaInfo inner class in TextLayoutManager were changed to use 'int' indices rather than 'short'. AFAIK, this is the only reason we currently need to split up FOText instances larger than 32K characters. At the time I introduced this fix, I opted to split the FOText instances, since I was a bit concerned about a rise in memory consumption. Upon closer inspection, and some browsing around, this seems to have far less of an impact than I thought... I did a quick test, allocating space for an array of 100.000 instances of: - a wrapper around three short values (values Short.MAX_VALUE) - a wrapper around three int values (values Integer.MAX_VALUE) The results: - 3 shorts - 100.000 instances = (2200K - 800K) = 1600K - 3 ints - 100.000 instances = (2980K - 800K) = 2180K The 800K is subtracted to account for the instance size (8 bytes * 100K). So three ints do not take up 100% as much space (as I initially expected), but only roughly between 30% and 50%... Opinions? Cheers Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIW12e+Gr+4pk71JwRAgWoAJwOIDLdgcYEBZQ4Tx0gPZaJe4KAXQCfc+Cs u2CYsAOxh6HnzLzu81iOH7c= =WlBi -END PGP SIGNATURE-
Re: Border and padding on page regions
On Thu, Jun 19, 2008 at 3:45 PM, Jeremias Maerki [EMAIL PROTECTED] wrote: There's both in FOP. block-container has the border on the viewport. table-cell has it on the reference area (table-cell doesn't generate a viewport). But I fear we might actually be wrong about having the border and padding on the viewport area. Ok, so the region reference is the right place for borders and padding; a posteriori it seems reasonable: the viewport defines the window, the reference area starts defining what we see ... (but I could easily convince myself of the other option too :-) ) It's interesting that we treat background and borders together in the renderers although 4.9.4 http://www.w3.org/TR/xsl11/#rend-border makes a distinction where the background is to be applied. But we don't support background-attachment so that didn't get noticed that way. I could split the matod AbstractPathOrientedRenderer.drawBackAndBorders() in two drawBackground() / drawBorders() methods, as the background trait is still in the viewport while borders and padding will be in the reference area. Thanks for the feedback (to Andreas too) Regards Luca
AUTO: Bradley Harrington/Austin/IBM is out of the office. (returning 06/24/2008)
I am out of the office until 06/24/2008. Please work with John Oustalett and Phil Hardy for Insight for SAP issues in my absense. I will respond to TPC Reporter issues when I return. If you have any questions, please contact my manager Jim Dilley. Thanks very much, Brad Note: This is an automated response to your message [EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed sent on 6/18/08 23:08:35. This is the only notification you will receive while this person is away.
