DO NOT REPLY [Bug 32789] Arabic words are broken for rendering PDF from FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #4 from J.Pietschmann j3322...@yahoo.de 2010-02-07 05:12:27 UTC --- I'd like to have a detection whether ICU4J and possibly also whether BIDI support is available at run time, and either fail with a sensible error message or degrade output. Distributing ICU4J with FOP is a bit of a headache, but taking advantage of it if the user installed it separately is certainly ok. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] Arabic words are broken for rendering PDF from FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #5 from Jonathan Levinson levin...@intersystems.com 2010-02-07 05:44:28 UTC --- Why is distributing ICU4J with FOP a bit of a headache? Would you use Java Relection to test whether the ICU4J classes this patch uses to support Arabic are available at run-time, and would you use reflection to call the ICU4J methods if they are available? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] Arabic words are broken for rendering PDF from FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #6 from J.Pietschmann j3322...@yahoo.de 2010-02-07 07:11:11 UTC --- (In reply to comment #5) Why is distributing ICU4J with FOP a bit of a headache? The jar is somewhat largish (6MB), and only a small part will be used (although other parts are useful too, like Thai support). Anyway, bundling a dependency may be good for users which prefer a self contained installation but usually are a headache for people who want to package FOP with their products, therefore I'd like to restrict bundled jars to a minimal guaranteed feature set. Would you use Java Relection to test whether the ICU4J classes this patch uses to support Arabic are available at run-time Yes. Testing for a single, typically used class should be sufficient. and would you use reflection to call the ICU4J methods if they are available? I don't think this is necessary, although I'm no longer on top of things when it comes to know when a JVM loads classes. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] Arabic words are broken for rendering PDF from FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 --- Comment #3 from r...@intersystems.com 2010-02-05 14:33:18 UTC --- Created an attachment (id=24934) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24934) Support for Arabic PDF rendering using ICU4J This patch uses ICU4J to do form-shaping and BIDI transformation of rendered text. It is a patch for the FOP trunk. It does not change the layout manager or the area tree handler or allow a writing-mode other than “lr-tb”. For this patch to be integrated with FOP, FOP would need to distribute the ICU4J library - icu4j-4_2_1.jar. It affects both PDF and PCL rendering but has only been tested with PDF rendering. So far results of testing with PDF rendering have been positive. The PCL aspect of the patch looks correct given that the PDF aspect works. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 32789] Arabic words are broken for rendering PDF from FOP
https://issues.apache.org/bugzilla/show_bug.cgi?id=32789 Alaa ElDin Farouk alaaeldina...@gmail.com changed: What|Removed |Added CC||alaaeldina...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
