CiviCRM Community Forums (archive)

I now have the Hebrew correctly displaying in the browser in my V1.8 install.

Now we are trying to print labels and in the PDF the Hebrew comes out as garbage once again.

Any ideas? If not I will try to recreate what I did for our v1.4: Since none of the labels matched our physical labels, I added an option to the Contact Search Results dropdown which created an RTF file for downloading, custom built to match our labels. Even there, however, I had to figure out the RTF symbols for the Hebrew characters and use a character mapping to convert them.

Thanks.

Thanks for your help. So either we move the NPO to Poland or we must find a solution for the Hebrew, eh?

Can I ask:

1. What sort of time frame do you think is involved for this ticket fix? I know you don't know, but from experience is this a matter of a week or 3 months?

2. Would it be feasible for me to experiment myself with other fonts? If so, could you give me a clue where to begin muddling with this? I would be happy to try.

Thanks.

It works perfectly AND we did put in some time translating.

Thank you!

I investigated it for a bit and indeed UFPDF (which is a UTF-8-support hack over FPDF) does not seem to support the directionality property of Unicode characters. :|

I filed CRM-2211 to track this issue, but it won’t get fixed for CiviCRM 1.8 (which went stable).

The only approach I came up with so far is to reverse the Hebrew lines on PHP side; this can be done with the following (assuming $line does not have any non-Hebrew, non-digit characters, so can be reversed as a whole):

<?php
preg_match_all('/(\d+)?./us', $line, $ar);
$line = join('',array_reverse($ar[0]));
?>

It’s a crude hack, but seems to make UFPDF reverse the Hebrew strings.

Actually, to go this way it’d be best to get the Unicode ranges of all right-to-left characters (if I understand that properly, directness is a property of a Unicode codepoint), scan the lines for groups of such characters and then flip them in the above manner.

Do let us know what’s the final solution that works for you, as I’d gladly add it to the next CiviCRM release.

FWIW, I managed to force UFPDF to display the strings properly by binding to FriBidi using the PECL fribidi package (there’s a bug in the package that makes it uninstallable on Ubuntu/Debian systems but is easily fixable). The relevant issue is CRM-2211, the fix is in r12024.