[reportlab-users] RTL Patch Committed

[Muayyad AlSadi]

at last someone interested to help!

I'm very happy


> There is still the issue of connecting letters, but that's more related to Complex Text Layout (CTL)


I can make a transformation that takes a unicode object and shape it
to connect the letters if this is the

the algorithm is called mu [it can be called either before of after fribidi]

an old python implementation is attached

c implementation for wine
http://bugs.winehq.org/show_bug.cgi?id=7150

so would this solve some of the problems

and allow me to ask
when would be able to have full opentype support (as in harfbuzz)
instead of those hacks ?

http://www.freedesktop.org/wiki/Software/HarfBuzz

On Thu, Nov 19, 2009 at 3:46 PM, Robin Becker <robin at reportlab.com> wrote:

> Hosam Aly wrote:

> ..........

>>

>> I have committed a patch to the "rtl-support" branch, adding partial RTL

>> support in "src/reportlab/pdfgen/textobject.py" and

>> "src/reportlab/platypus/paragraph", based on pyfribidi.

>

> ........

>

>>

>> Out of 15 test cases, 15 succeeded and 1 failed, which is the sixth one

>> (line 6 in the generated PDF). The Arabic words should have appeared at the

>> beginning of the line, but instead they appear at the end. This issue needs

>> more investigation.

>>

>

> thanks and great work.

>

>>

>> There is still the issue of connecting letters, but that's more related to

>> Complex Text Layout (CTL) than it is to supporting BiDirectional rendering.

>> I'll try to tackle that issue next. I am thinking of using PyICU instead of

>> PyFriBiDi, but I still have to read more about it.

>>

>>

>> Meanwhile, I read in the PDF standard (version 1.7 from Adobe) that the

>> PDF text object supports receiving UTF-16BE text, provided that it starts

>> with the Unicode Byte Order Mark (BOM, U+FEFF). I wonder what would be the

>> results if we wrote text in UTF-16 instead of writing the code points in the

>> font? I didn't know how to test this, so I hope someone can help me.

>

> ..........

> We have used UTF16 in some places in pdfdoc.py. I believe that was related

> to using CJK standard fonts in places where Acrobat Reader would normally

> use pdfdoc encoding ie various comments and document description sections.

>

> In principle there's nothing that's better about using a 16bit unicode

> representation for text. I do see that for cmaps there are a lot of

> predefined mappings which correspond to various utf16 subsets.

>

> When the font is a builtin font I can see that using a standard encoding

> makes sense. That is certainly the case for the standard AR cjk fonts where

> the fonts are large and don't have to be embedded. However, we are often

> making up subset fonts for embedding purposes and there I don't think it

> makes sense to use 16bit entries.

> --

> Robin Becker

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users

>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mu.py
Type: application/octet-stream
Size: 10467 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091119/59a81a99/attachment.obj>