Issue with Hebrew Text Direction in Exaprom PDF 2.0 for LabVIEW

[maxnoder1995]

Hi everyone,
I'm using Exaprom PDF 2.0 in LabVIEW to create PDFs with Hebrew text. My workflow includes the following VIs:
New PDF.vi
Append Paragraph.vi
Close PDF.vi

When configuring the Append Paragraph.vi, I set the following properties:
Font Name: Arial
Size: 12
Type & Direction: ASCII
Embedded: Enabled
Encoding: CP1255 (for Hebrew)

The text "שלום" (shalom) gets added to the PDF but is reversed to "םולש" (left-to-right instead of right-to-left). If I change the Type & Direction property to UTF-16 (RTL), the text appears as "??" in the PDF. My Questions:
1. How can I correctly display Hebrew text in RTL order using CP1255 encoding?
2. How do I properly use UTF-16 (RTL) for Hebrew text in this library?
3. Do I need to convert or modify the string in LabVIEW?

Are there additional settings or workarounds to fix this issue? Any advice or examples would be greatly appreciated!
Thanks in advance,
Max

[maxnoder1995]

Hi everyone,
I'm using Exaprom PDF 2.0 in LabVIEW to create PDFs with Hebrew text. My workflow includes the following VIs:
1. New PDF.vi
2. Append Paragraph.vi
3. Close PDF.vi

When configuring the Append Paragraph.vi, I set the following properties:
Font Name: Arial Size: 12
Type & Direction: ASCII
Embedded: Enabled
Encoding: CP1255 (for Hebrew)

The text "שלום" (shalom) gets added to the PDF but is reversed to "םולש" (left-to-right instead of right-to-left). If I change the Type & Direction property to UTF-16 (RTL), the text appears as "??" in the PDF. My Questions:

1. How can I correctly display Hebrew text in RTL order using CP1255 encoding?
2. How do I properly use UTF-16 (RTL) for Hebrew text in this library? Do I need to convert or modify the string in LabVIEW?
3. Are there additional settings or workarounds to fix this issue?

Any advice or examples would be greatly appreciated!
Thanks in advance,
Max

[tst]

I haven't used this library, but I expect that if ASCII is reversed, then reversing the Hebrew strings would help (ideally you would just need to detect and reverse runs on RTL characters, but neutral characters might also be included in the run. Testing is needed).

For UTF16, I expect you need to encode the string as UTF16, possibly by building the sequence of bytes yourself (Windows does have some functions for converting to UTF (search for "widechar"), but I'm not sure if what you get out of it would be useful for inserting into the VI. If it's just Hebrew, it's usually reasonably easy, because there is a 1:1 mapping from the ASCII value to the UTF16 value of each letter, so you can just create a lookup table or have the logic add the relevant bytes. Again, testing is needed.

[maxnoder1995]

Thank you for your response! I had hoped there might be a slightly simpler solution, but I understand your approach. While working on the reverse process you mentioned, a new challenge has arisen—a particularly tricky issue with wrapping text. it seems I need to wrap the text from bottom to top. While I think I can manage that, the difficulty lies in determining where to start wrapping because the font size and page width are variable. any idea?

[wiebe@CARYA]

Fonts, and related character encodings, are a nasty business.

LabVIEW (nor the library) has any way to know what the data in your original string means. That string could show Chinese characters if I open that VI...

LabVIEW doesn't use UTF, or even Unicode (by default). So, looking up those characters in your code page is expected to be needed. LabVIEW's MBSC should be converted to the font's encoding, which sadly isn't standard either.

Of course you  might have configured (parts of) LabVIEW to use Unicode...

I suppose your current solution can't be too much off, as it works.

If you use a Windows API to convert the string, it probably stops working when the code is moved to a PC with another code page. Some MBSC codes translate to more than one Unicode character (which is the entire reason code pages exist in the first place).

Note that not all standard PDF fonts have all character sets. I don't know if Exaprom embeds the font or refers to PDF's internal "Arial" font (Helvetica, IIRC). Just don't assume other fonts work (well).

[tst]

I don't have much experience with generating PDFs (and when I did, I don't remember if they included Hebrew), but I doubt trying to play with things on the LV side is a winning strategy. I would look into trying to get the layout engine to handle this for you.

A quick search indicates that Exaprom is no longer supported and works with the iTextSharp DLL, which is also unsupported, so I would suggest searching for other alternatives. Even if still using this, I would suggest checking what needs to be done there to enable full RTL support, assuming it's possible.

I suppose you could also try generating HTML (where RTL support should be OK) and seeing if you can convert that to PDF.

[wiebe@CARYA]

IIRC, iTextSharp isn't free for commercial usage.

However, older versions don't explicitly mention this, as the exact licensing wasn't clear for those versions. This has often been translated to "so the old version it's free", and that could be a reason to stick to the old version.

I could redirect to "my" PDF Toolkit (Carya Automatisering | Products), but I can't guarantee it will work.

Like I said, it's very hard, confusing and messy.