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 Jonathan Levinson <Jo...@intersystems.com> on 2010/01/06 16:02:46 UTC
Adding support for Arabic to FOP
Is there a way the software team at InterSystems could work with you (the FOP team) to add support for Arabic to FOP?
We do have in-house expertise on Arabic.
We are not expert in FOP internals and would need help knowing what areas of the code need to be worked on.
I've been trying to send you an e-mail about the issues involved but it is being rejected as spam.
Best Regards,
Jonathan Levinson
Re: Adding support for Arabic to FOP
Posted by Pascal Sancho <pa...@takoma.fr>.
Hi Jonathan,
IMHO, with Arabic, BIDI must be supported by the PDF engine, not only
the PDF viewer.
What I see in Adobe Reader is correct for me when the PDF engine gives
correct PDF.
Note that default bidi is taken into account until Arabic text-node is
encountered.
For Arabic text-node, PDF engine should automatically render it in RL mode.
Since FOP doesn't support automatic BIDI, FOP render Arabic text-node in
wrong order (compare fopdev_nowritingmode.pdf with nofop_nowritingmode.pdf)
If you want to extend Arabic writing-mode to the whole page, you have to
explicitly set writing-mode property (see _test.fo file).
In addition, you can see what inner ligatures look like in nofop_*.pdf.
HTH,
Pascal
Jonathan Levinson a écrit :
> I've been playing with Arabic text in Adobe Reader 9.2 and in Foxit and see no sign that either implements BIDI.
>
> Which PDF viewers support BIDI?
>
> Best Regards,
> Jonathan Levinson
>
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>
>> And this is only half of the story. Changes also need to be made to the
>> layout engine: character re-ordering, BIDI implementation, glyph
>> shaping, etc.
>>
> On top of that, (many?) modern PDF viewers support BIDI while
> older ones usually don't. Which means, if FOP does BIDI for PDF
> output itself in order to guarantee proper rendering, each
> character has to be individually positioned, which bloats the
> file and could break search and maybe copy&paste too.
> Or could we simply ignore PDF viewers incapable of rendering
> r-l text properly?
>
> J.Pietschmann
>
RE: Adding support for Arabic to FOP
Posted by Jonathan Levinson <Jo...@intersystems.com>.
I've been playing with Arabic text in Adobe Reader 9.2 and in Foxit and see no sign that either implements BIDI.
Which PDF viewers support BIDI?
Best Regards,
Jonathan Levinson
-----Original Message-----
From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
Sent: Thursday, January 07, 2010 5:49 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: Adding support for Arabic to FOP
On 07.01.2010 12:28, Vincent Hennebert wrote:
> And this is only half of the story. Changes also need to be made to the
> layout engine: character re-ordering, BIDI implementation, glyph
> shaping, etc.
On top of that, (many?) modern PDF viewers support BIDI while
older ones usually don't. Which means, if FOP does BIDI for PDF
output itself in order to guarantee proper rendering, each
character has to be individually positioned, which bloats the
file and could break search and maybe copy&paste too.
Or could we simply ignore PDF viewers incapable of rendering
r-l text properly?
J.Pietschmann
Re: Adding support for Arabic to FOP
Posted by Chris Bowditch <bo...@hotmail.com>.
Peter B. West wrote:
> Are you on 1.5 yet? 1.5 has bidi support, doesn't it?
Not yet. In any case, relying on AWT classes for positioning text is a
poor strategy in my opinion as the AWT implementation varies wildly
between JDK Vendor, Operating/System and JDK build. Which is too many
factors to get consistent results.
Chris
>
> Peter
>
> On 08/01/2010, at 8:48 AM, J.Pietschmann wrote:
>
>> On 07.01.2010 12:28, Vincent Hennebert wrote:
>>> And this is only half of the story. Changes also need to be made to the
>>> layout engine: character re-ordering, BIDI implementation, glyph
>>> shaping, etc.
>> On top of that, (many?) modern PDF viewers support BIDI while
>> older ones usually don't. Which means, if FOP does BIDI for PDF
>> output itself in order to guarantee proper rendering, each
>> character has to be individually positioned, which bloats the
>> file and could break search and maybe copy&paste too.
>> Or could we simply ignore PDF viewers incapable of rendering
>> r-l text properly?
>>
>> J.Pietschmann
>
>
>
Re: Adding support for Arabic to FOP
Posted by "Peter B. West" <li...@pbw.id.au>.
Are you on 1.5 yet? 1.5 has bidi support, doesn't it?
Peter
On 08/01/2010, at 8:48 AM, J.Pietschmann wrote:
> On 07.01.2010 12:28, Vincent Hennebert wrote:
>> And this is only half of the story. Changes also need to be made to the
>> layout engine: character re-ordering, BIDI implementation, glyph
>> shaping, etc.
>
> On top of that, (many?) modern PDF viewers support BIDI while
> older ones usually don't. Which means, if FOP does BIDI for PDF
> output itself in order to guarantee proper rendering, each
> character has to be individually positioned, which bloats the
> file and could break search and maybe copy&paste too.
> Or could we simply ignore PDF viewers incapable of rendering
> r-l text properly?
>
> J.Pietschmann
Re: Adding support for Arabic to FOP
Posted by "J.Pietschmann" <j3...@yahoo.de>.
On 07.01.2010 12:28, Vincent Hennebert wrote:
> And this is only half of the story. Changes also need to be made to the
> layout engine: character re-ordering, BIDI implementation, glyph
> shaping, etc.
On top of that, (many?) modern PDF viewers support BIDI while
older ones usually don't. Which means, if FOP does BIDI for PDF
output itself in order to guarantee proper rendering, each
character has to be individually positioned, which bloats the
file and could break search and maybe copy&paste too.
Or could we simply ignore PDF viewers incapable of rendering
r-l text properly?
J.Pietschmann
Re: Adding support for Arabic to FOP
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi,
Adrian Cumiskey wrote:
> Hi Jonathan,
>
> I took a stab at applying a patch by Richard Wheeldon some time ago now
> but the solution was not complete (see
> https://issues.apache.org/bugzilla/show_bug.cgi?id=42307).
>
> Without spending too much time looking into this, I am of the impression
> that there is not a singular place where you could implement this in the
> current architecture as each painter and renderer provides its own
> implementation for text handling.
And this is only half of the story. Changes also need to be made to the
layout engine: character re-ordering, BIDI implementation, glyph
shaping, etc.
You will need to familiarize yourself with the Knuth approach. Some
information is available on the wiki:
http://wiki.apache.org/xmlgraphics-fop/DeveloperPages
But you will most probably also have to read Donald Knuth’s article
“Breaking Paragraphs into Lines”.
The corresponding code is in the org.apache.fop.layout package.
Using the ICU4J library will probably be necessary. Search the fop-dev
archive for ICU4J and you will already find some information on the
topic.
Also, I recently stumbled upon the following article:
http://behdad.org/text/
which might be worth reading. The whole idea being that we should avoid
re-inventing the wheel as much as possible.
> From what I can see, it would currently involve changes to :-
>
> 1. renderText(TextArea text, Graphics2D g2d, Font font) method in
> Java2DRenderer.
>
> 2. The renderText() methods in all the Renderer implementations.
>
> 3. The drawText() method in each Painter implementation.
>
> The situation appears to be far from ideal. I'm sorry but I do not have
> any time to help you with this due to other off-project development
> commitments that I have at the moment. Hope this information is of help
> to you.
>
> Best of luck,
>
> Adrian Cumiskey.
>
> Jonathan Levinson wrote:
>> Is there a way the software team at InterSystems could work with you
>> (the FOP team) to add support for Arabic to FOP?
>>
>> We do have in-house expertise on Arabic.
>>
>> We are not expert in FOP internals and would need help knowing what
>> areas of the code need to be worked on.
>>
>> I’ve been trying to send you an e-mail about the issues involved but
>> it is being rejected as spam.
Try sending your messages as plain text instead of HTML. That should
reduce the spam rating. Plain text messages on public mailing lists are
preferred anyway.
>> Best Regards,
>>
>> Jonathan Levinson
HTH,
Vincent
Re: Adding support for Arabic to FOP
Posted by Adrian Cumiskey <de...@cumiskey.com>.
Hi Jonathan,
I took a stab at applying a patch by Richard Wheeldon some time ago now
but the solution was not complete (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=42307).
Without spending too much time looking into this, I am of the impression
that there is not a singular place where you could implement this in the
current architecture as each painter and renderer provides its own
implementation for text handling.
From what I can see, it would currently involve changes to :-
1. renderText(TextArea text, Graphics2D g2d, Font font) method in
Java2DRenderer.
2. The renderText() methods in all the Renderer implementations.
3. The drawText() method in each Painter implementation.
The situation appears to be far from ideal. I'm sorry but I do not have
any time to help you with this due to other off-project development
commitments that I have at the moment. Hope this information is of help
to you.
Best of luck,
Adrian Cumiskey.
Jonathan Levinson wrote:
> Is there a way the software team at InterSystems could work with you
> (the FOP team) to add support for Arabic to FOP?
>
>
>
> We do have in-house expertise on Arabic.
>
>
>
> We are not expert in FOP internals and would need help knowing what
> areas of the code need to be worked on.
>
>
>
> I’ve been trying to send you an e-mail about the issues involved but it
> is being rejected as spam.
>
>
>
> Best Regards,
>
> Jonathan Levinson
>
>
>