[reportlab-users] RTL Patch Committed

[Robin Becker]

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