You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/02/08 13:13:15 UTC

DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP

https://issues.apache.org/bugzilla/show_bug.cgi?id=32789

Vincent Hennebert <vh...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|pdf                         |page-master/layout
           Platform|PC                          |All
            Version|0.20.5                      |all
            Summary|Arabic words are broken for |[PATCH] Arabic Shaping not
                   |rendering PDF from FOP      |Supported by FOP
         OS/Version|Windows 2000                |All
           Severity|critical                    |normal

--- Comment #7 from Vincent Hennebert <vh...@gmail.com> 2010-02-08 04:13:10 UTC ---
Hi,

Thanks for your patch. Do you have an example FO file that could be used for
testing purpose (even better, with an English translation)?

IIUC, Arabic shaping is about replacing glyphs for standalone letters with
suitable ligature glyphs for building words. Surely that affects character
widths, so line breaking decisions? In the patch, shaping is performed at the
rendering stage, so isn't there a danger of getting inconsistent results?

Also, IIC Arabic shaping affects glyphs selection. How do you make sure that
the right glyphs are being embedded in the PDF file?

The same piece of code is duplicated in the PCL and PDF painters. The same
would probably also need to be done for other painters. This is not desirable.

Finally, what is the impact on performance? It looks like shaping will be
applied to just any text, even non-arabic one.

Thanks,
Vincent


(In reply to comment #3)
> Created an attachment (id=24934)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24934) [details]
> 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.

Re: DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP

Posted by Chris Bowditch <bo...@hotmail.com>.
On 09/11/2011 10:01, Vinesh Kumar wrote:
> Hi,
>
> Please let me how to implement the arabic character support in FOP 0.20.5. I
> am able to view the arabic characters by giving the arabic unicode in the
> input FO. But still the way displaying content is not right to left. Please
> help me how to implement the writing direction in FOP0.20.5

Hi Vinesh,

0.20.5 is ancient, released 8 years ago. The best way forward is to 
upgrade to FOP v1.0. Glenn Adams has developed a branch based on FOP 
v1.0 that fully supports Arabic script output. Once your stylesheets are 
converted for use with FOP v1.0 you can use the Complex Script branch 
build. As far as I know there is no solution with FOP v0.20.5.

Thanks

Chris

> Regards,
> Vinesh Kumar. D
>
>
>
> Bugzilla from bugzilla@apache.org wrote:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=32789
>>
>> Vincent Hennebert<vh...@gmail.com>  changed:
>>
>>             What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>            Component|pdf                         |page-master/layout
>>             Platform|PC                          |All
>>              Version|0.20.5                      |all
>>              Summary|Arabic words are broken for |[PATCH] Arabic Shaping
>> not
>>                     |rendering PDF from FOP      |Supported by FOP
>>           OS/Version|Windows 2000                |All
>>             Severity|critical                    |normal
>>
>> --- Comment #7 from Vincent Hennebert<vh...@gmail.com>  2010-02-08
>> 04:13:10 UTC ---
>> Hi,
>>
>> Thanks for your patch. Do you have an example FO file that could be used
>> for
>> testing purpose (even better, with an English translation)?
>>
>> IIUC, Arabic shaping is about replacing glyphs for standalone letters with
>> suitable ligature glyphs for building words. Surely that affects character
>> widths, so line breaking decisions? In the patch, shaping is performed at
>> the
>> rendering stage, so isn't there a danger of getting inconsistent results?
>>
>> Also, IIC Arabic shaping affects glyphs selection. How do you make sure
>> that
>> the right glyphs are being embedded in the PDF file?
>>
>> The same piece of code is duplicated in the PCL and PDF painters. The same
>> would probably also need to be done for other painters. This is not
>> desirable.
>>
>> Finally, what is the impact on performance? It looks like shaping will be
>> applied to just any text, even non-arabic one.
>>
>> Thanks,
>> Vincent
>>
>>
>> (In reply to comment #3)
>>> Created an attachment (id=24934)
>>   -->  (https://issues.apache.org/bugzilla/attachment.cgi?id=24934)
>> [details]
>>> 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.
>>


Re: DO NOT REPLY [Bug 32789] [PATCH] Arabic Shaping not Supported by FOP

Posted by Vinesh Kumar <dv...@gmail.com>.
Hi,

Please let me how to implement the arabic character support in FOP 0.20.5. I
am able to view the arabic characters by giving the arabic unicode in the
input FO. But still the way displaying content is not right to left. Please
help me how to implement the writing direction in FOP0.20.5

Regards,
Vinesh Kumar. D 



Bugzilla from bugzilla@apache.org wrote:
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=32789
> 
> Vincent Hennebert <vh...@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Component|pdf                         |page-master/layout
>            Platform|PC                          |All
>             Version|0.20.5                      |all
>             Summary|Arabic words are broken for |[PATCH] Arabic Shaping
> not
>                    |rendering PDF from FOP      |Supported by FOP
>          OS/Version|Windows 2000                |All
>            Severity|critical                    |normal
> 
> --- Comment #7 from Vincent Hennebert <vh...@gmail.com> 2010-02-08
> 04:13:10 UTC ---
> Hi,
> 
> Thanks for your patch. Do you have an example FO file that could be used
> for
> testing purpose (even better, with an English translation)?
> 
> IIUC, Arabic shaping is about replacing glyphs for standalone letters with
> suitable ligature glyphs for building words. Surely that affects character
> widths, so line breaking decisions? In the patch, shaping is performed at
> the
> rendering stage, so isn't there a danger of getting inconsistent results?
> 
> Also, IIC Arabic shaping affects glyphs selection. How do you make sure
> that
> the right glyphs are being embedded in the PDF file?
> 
> The same piece of code is duplicated in the PCL and PDF painters. The same
> would probably also need to be done for other painters. This is not
> desirable.
> 
> Finally, what is the impact on performance? It looks like shaping will be
> applied to just any text, even non-arabic one.
> 
> Thanks,
> Vincent
> 
> 
> (In reply to comment #3)
>> Created an attachment (id=24934)
>  --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24934)
> [details]
>> 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.
> 

-- 
View this message in context: http://old.nabble.com/DO-NOT-REPLY--Bug-32789---PATCH--Arabic-Shaping-not-Supported-by-FOP-tp27498975p32809772.html
Sent from the FOP - Dev mailing list archive at Nabble.com.