PDF translation for ISO-8859-2 or cp1250 (Slovenian, Croatian, Serbian, Slovak, etc.)

[keglevich]

Dear developers!

I am currently working on a Serbian translation for PrestaShop which I would like to use in the future as my small webshop service. I successfully translated more or less every field (module). More or less fields (using MS IE and Mozilla) don't show any problems at all, but I have two small problems with out specific character map with PDF documents and TABS:

1.) I was trying to make PDF translations with our character map (image attached to show those 6 lower and upper case characters which are special in our language). Character map which we are using by default in that case would be iso-8859-2, maybe even cp-1250 would be OK, but I'm not 100% sure. The thing is that when I make a translation, I can normally save it and export it, but when I try to open PDF document, all those symbols are not shown properly. Instead of those 6 symbols I get in the PDF reader only some strange symbols which are usually shown when wrong codepage in used. I also tried to change PDF font and PDF codepage, but nothing seems to change at all. Also I was trying to achieve the same on the prestashop website using just demo version, but in that demo version there's lots of codepages to choos and also some different fonts to choose, but no matter whan you choose, PDF preview always looks 100% the same. Also I tried to preview "Slovak" language in PDF which is very similar to ours, but also shows wrong symbols.
I found some threads, similar to mine, but since I'm not really a PHP developer, I can't understand most of it. In one thread (http://www.prestashop.com/forums/viewthread/7506/translations/backend_translation) user named "spott" suggested to check for server decoding (html_entity_decode), but I googled a little and found that iso-8859-2 isn't even allowed with html_entity_decode (http://www.w3schools.com/php/func_string_html_entity_decode.asp).
However, if someone here who has enough knowledge can reproduce whan I am typing about and make PDF reader (adobe reader 8+) show the right symbols in PDF preview, would he be kind enough to write a step-by-step tutorail how to achieve this since I'm not a programmer enough to solve this by mself?

2.) I also found in one thread (http://www.prestashop.com/forums/viewthread/7506/translations/backend_translation) that exporting TABS translations isn't possible at the moment. User "spott" also suggested to take translations directly out of the database (lang_tabs table). Where can I find that database, how to access it?

I know both my questions are probably in some sense funny to well educated programmer, but development is not my area of work so I can only contribute by a proper translation at this moment. Therefore I need your help...

Thank you for all your answers in advance, Radovan.

[ramires]

i think that we all shoud use the UTF endcoding.
Using the ISO Latin 2 (8859-2) isnt good idea. I ve the same problem with polish lang too, so i think that better way will be including the fonts into the document than rediscovering wheel again.

Of course that way demands the own created fonts, but if we create it once ours problem gone.

that is my opinion.

[keglevich]

So, when I sum up everything, there's currently no solution to use proper fonts in PDF documents with prestashop?

Is there maybe someone from development team who can check through my first post and try to answer or solve the problem? However, I would be glad to help as much as I can to import proper fonts, but I'm afraid all I can contribute is a decent Serbian translation...

Thanks again, Radovan.

[Avlad]

The only real solution - use utf-8 for the .pdf generation. This bug was known by PrestaTeam at least since 02 June 2008, when Philippe Sang writes:
> Yes we are aware about this problem and working on for RC4.

The problem is that fpdf did not support utf-8 encoding. Simple solution - use ufpdf: http://acko.net/node/56 – UFPDF: Unicode/UTF-8 extension for FPDF.

I have installed ufpdf, have generated utf-8 fonts, fix updf for this application and rewrite pdf.php to work with ufpdf and new fonts. Detailed description here:
http://www.prestashop.com/forums/viewthread/3480/P15/_lang____pdf
Now I have all invoices printed in utf-8. It is especially useful, when you need to use two languages with incompatible encodings, for example CP1251 and CP1257.

This also several times reported to the Presta team in forum in the bug tracker:
http://www.prestashop.com/bug_tracker/view/629/
http://www.prestashop.com/bug_tracker/view/628/

Probably, it will be fixed by Presta Team in the next few years, however right now you can use my solution.

[keglevich]

The only real solution - use utf-8 for the .pdf generation. This bug was known by PrestaTeam at least since 02 June 2008, when Philippe Sang writes:
> Yes we are aware about this problem and working on for RC4.

The problem is that fpdf did not support utf-8 encoding. Simple solution - use ufpdf: http://acko.net/node/56 – UFPDF: Unicode/UTF-8 extension for FPDF.

I have installed ufpdf, have generated utf-8 fonts, fix updf for this application and rewrite pdf.php to work with ufpdf and new fonts. Detailed description here:
http://www.prestashop.com/forums/viewthread/3480/P15/_lang____pdf
Now I have all invoices printed in utf-8. It is especially useful, when you need to use two languages with incompatible encodings, for example CP1251 and CP1257.

This also several times reported to the Presta team in forum in the bug tracker:
http://www.prestashop.com/bug_tracker/view/629/
http://www.prestashop.com/bug_tracker/view/628/

Probably, it will be fixed by Presta Team in the next few years, however right now you can use my solution.

Dear Avlad,

your answer is indeed a very good news for me. I am interested in doing the same thing myself. I also checked your forum link, but the only problem is that everything is in Russian language so I can't translate practically anything. Is it possible to you to write a small step-by-step tutorial in English language with "code" or links to modified .php files needed to reproduce that solution.
It would mean really a lot to me to solve this particular case.

Thank you for your answer in advance again, Radovan.