eGW, UTF-8 and pERP: problem with UTF-8

classic Classic list List threaded Threaded
34 messages Options
12
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

eGW, UTF-8 and pERP: problem with UTF-8

Hi, Nathan.
We've perp in two kinds of environments.

1- Our controlled equipment:
In this one, we've all control of the environment. This installation is by RPM. We follow all the configuration recommendations that is on setup.

2- Hosted on a external service:
In this one we don't have a lot of controls. Specifically the UTF-8 is not configured like EGW need.
The php.ini is not set properly. Below, the php.ini mbstring configuration on eGW setup:
" Checking php.ini: mbstring.func_overload = 7: ini_get('mbstring.func_overload')='0' "

Actual situation:
We've some problems with UTF-8, specifically the report_purchase_order.
Surprisingly, for us, it works on the second and not on the first environment.

Below, some links about this problem:
http://old.nabble.com/Problems-with-UTF-8-and-report-generation-tp23815989p23815989.html
http://old.nabble.com/Re%3A-Perp-mistakes.-%28multibyte-characters-in-reports%29-tp24005630p24907269.html
http://old.nabble.com/report_purchase_order-is-not-generating-td23370666i20.html

What can we do?
Regards.
Nathan Gray Nathan Gray
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

On Mon, Nov 9, 2009 at 7:42 AM, PCS-Lists <[hidden email]> wrote:
> ...
> Actual situation:
> We've some problems with UTF-8, specifically the report_purchase_order.
> Surprisingly, for us, it works on the second and not on the first
> environment.
> ...
> http://old.nabble.com/report_purchase_order-is-not-generating-td23370666i20.html
>
> What can we do?

You've already exceeded my knowledge of PHP and multibyte characters.
There's nothing more I can think of.
Sorry, when you get it figured out, please share and we'll get it
fixed for everyone.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

>You've already exceeded my knowledge of PHP and multibyte characters.
>There's nothing more I can think of.
>Sorry, when you get it figured out, please share and we'll get it
>fixed for everyone.

Ok, I understand it. Thanks even so. Can you explain me how is your environment? Your GW setup installation checking is completely satisfied? How you did your installation, RPM, tar.gz, ...?Which OS version? Which php version? Do you have development and production environment separately?

Forgive me for the insistence but I'm trying to understand deeply what is happening.

Many thanks and regards.


Justin F. Hallett Justin F. Hallett
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

I don't have version handy, but we run debian testing updated daily,  
so whatever versions are there is what we are running ;)
---
Justin F. Hallett
Blue Falls Manufacturing Ltd.
I.T. Manager
http://www.goarctic.com/
Tel: (780) 789-2626 ext.323
Cel: (780) 935-9771
Fax: (780) 789-2624


On 2009-11-10, at 4:55 AM, PCS-Lists wrote:

>
>> You've already exceeded my knowledge of PHP and multibyte characters.
>> There's nothing more I can think of.
>> Sorry, when you get it figured out, please share and we'll get it
>> fixed for everyone.
>
> Ok, I understand it. Thanks even so. Can you explain me how is your
> environment? Your GW setup installation checking is completely  
> satisfied?
> How you did your installation, RPM, tar.gz, ...?Which OS version?  
> Which php
> version? Do you have development and production environment  
> separately?
>
> Forgive me for the insistence but I'm trying to understand deeply  
> what is
> happening.
>
> Many thanks and regards.
>
>
>
> --
> View this message in context: http://old.nabble.com/eGW%2C-UTF-8-and-pERP%3A-problem-with-UTF-8-tp26267520p26282162.html
> Sent from the Project ERP (pERP) - Developers mailing list archive  
> at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Perp-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/perp-developers
>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
Nathan Gray Nathan Gray
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

In reply to this post by PCSLists
On Tue, Nov 10, 2009 at 4:55 AM, PCS-Lists <[hidden email]> wrote:
>...
> Your GW setup installation checking is completely satisfied?

I believe it was.  It's been a while.

> How you did your installation, RPM, tar.gz, ...?

SVN

> Which php version?

5.2.11-1

> Do you have development and production environment separately?

The environments are separate, but identical.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

>SVN

trunk or stable?

Below is a screenshot of a production environment where I'm having problems with reports and UTF-8. Is your setup like it? Are there differences between both? What are?

gw_setup.pdf

You are being very helpful.
Thanks and regards
Justin F. Hallett Justin F. Hallett
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

that first warning doesn't look right to me, have you tried it with =7?
---
Justin F. Hallett
Blue Falls Manufacturing Ltd.
I.T. Manager
http://www.goarctic.com/
Tel: (780) 789-2626 ext.323
Cel: (780) 935-9771
Fax: (780) 789-2624


On 2009-11-19, at 7:32 AM, PCS-Lists wrote:

>
>> SVN
>
> trunk or stable?
>
> Below is a screenshot of a production environment where I'm having problems
> with reports and UTF-8. Is your setup like it? Are there differences between
> both? What are?
>
> http://old.nabble.com/file/p26421354/gw_setup.pdf gw_setup.pdf
>
> You are being very helpful.
> Thanks and regards
> --
> View this message in context: http://old.nabble.com/eGW%2C-UTF-8-and-pERP%3A-problem-with-UTF-8-tp26267520p26421354.html
> Sent from the Project ERP (pERP) - Developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Perp-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/perp-developers
>


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
Pongrácz István-2 Pongrácz István-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

Hi,

Sure, the mbstring.func_overload must be 7 in generally.
You can change it in your php.ini or in your .htaccess, depends on your
webserver configuration.

The rest are not relevant (I mean warnings).

Üdvözlettel / Kind regards

Pongrácz István
ügyvezető / CEO

StartIT Kft.
http://www.startit.hu
http://www.fit-pc2.hu
http://ilearningglobal.biz/pongraczi
Mobil/cellular: +36 20 4489 581
 
 
----------------eredeti üzenet-----------------
Feladó: "Justin F. Hallett" [hidden email]
Címzett: "PCS-Lists"
CC: [hidden email]
Dátum: Thu, 19 Nov 2009 08:04:57 -0700
-------------------------------------------------
 
 

> that first warning doesn't look right to me, have you tried it with =7?
> ---
> Justin F. Hallett
> Blue Falls Manufacturing Ltd.
> I.T. Manager
> http://www.goarctic.com/
> Tel: (780) 789-2626 ext.323
> Cel: (780) 935-9771
> Fax: (780) 789-2624
>
>
> On 2009-11-19, at 7:32 AM, PCS-Lists wrote:
>
>>
>>> SVN
>>
>> trunk or stable?
>>
>> Below is a screenshot of a production environment where I'm having
problems
>> with reports and UTF-8. Is your setup like it? Are there differences
between

>> both? What are?
>>
>> http://old.nabble.com/file/p26421354/gw_setup.pdf gw_setup.pdf
>>
>> You are being very helpful.
>> Thanks and regards
>> --
>> View this message in context:
>> http://old.nabble.com/eGW%2C-UTF-8-and-pERP%3A-problem-with-UTF-8-
>> tp26267520p26421354.html
>> Sent from the Project ERP (pERP) - Developers mailing list archive at
>> Nabble.com.
>>
>>
>>
>> ------------------------------------------------------------------
>> ------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
>> trial. Simplify your report design, integration and deployment - and
focus

>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Perp-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/perp-developers
>>
>
>
>
> --------------------------------------------------------------------
> ----------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
> trial. Simplify your report design, integration and deployment - and focus
on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Perp-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/perp-developers
>






------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

Hi all,

talbking about this problem with Ralf Becker (gw developer), he said me:

"Newer php does NOT allow: php_value mbstring.func_overload 7
you have to use instead:  php_admin_value mbstring.func_overload 7"

The link to forum is
http://old.nabble.com/Problems-with-UTF-8-and-report-generation-td23816008s3741.html#a23816008

Then I made the changes that he suggested disabling the first parameter and inserting the second, but it not solved the problem.

Pongraczi wrote
Hi,

Sure, the mbstring.func_overload must be 7 in generally.
You can change it in your php.ini or in your .htaccess, depends on your
webserver configuration.

The rest are not relevant (I mean warnings).

...
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

Hi all,
   I have the same problems, one of this char (àèéìòù) in a report field and that field appears as empty. But I have no problem with those chars in EGW or pERP (I mean in web browser), so why don't we look in another direction? It's only a report problem so the solution must be in TBS or tinyDoc classes.
    Nathan, the second argument of LoadTemplate() method may be the right one:

====
HtmlCharSet   Optional. Indicates the character encoding (charset) to use for Html conversion of the data when they will be merged. It should be the same as the charset of the template. The default value is '' (empty string) which is equivalent to 'ISO-8859-1' (Latin 1).
====

    Now, if those charset should be the same, the problem may be caused by pERP tables/columns stored in cp1252 West European (at least in my db) and by OOo documents/templates that  afaik are encoded in UTF-8.

Regards
MicheleT


PCS-Lists wrote
Hi all,

talbking about this problem with Ralf Becker (gw developer), he said me:

"Newer php does NOT allow: php_value mbstring.func_overload 7
you have to use instead:  php_admin_value mbstring.func_overload 7"

The link to forum is
http://old.nabble.com/Problems-with-UTF-8-and-report-generation-td23816008s3741.html#a23816008

Then I made the changes that he suggested disabling the first parameter and inserting the second, but it not solved the problem.

Pongraczi wrote
Hi,

Sure, the mbstring.func_overload must be 7 in generally.
You can change it in your php.ini or in your .htaccess, depends on your
webserver configuration.

The rest are not relevant (I mean warnings).

...
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

MicheleT,

someone, somewhere in the past noticed that the problem is around TBS. Below the link:
http://old.nabble.com/Re%3A-Perp-mistakes.-%28multibyte-characters-in-reports%29-td24005630.html

However, I don't got advance from this.


Nathan,

I observed that you are making some changes over the gw trunk template. How you suggest that I update my environments? Trunk or stable release.

Nathan Gray Nathan Gray
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

On Tue, Nov 24, 2009 at 10:24 AM, PCS-Lists <[hidden email]> wrote:
>...
> I observed that you are making some changes over the gw trunk template.

Not sure what you're referring to.

> How you suggest that I update my environments? Trunk or stable release.

Depends.
SVN trunk (eGW + pERP) will have the latest features and bugs, but it
will also have the latest bug fixes.
If you need compatibility, the latest released versions of eGW + pERP
work with each other.

If you try to mix, with eGW on a stable release, and pERP on trunk,
you will eventually find things that don't work, as I take advantage
of the latest changes.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Perp-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/perp-developers
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

In reply to this post by PCSLists
PCS-Lists wrote
MicheleT,

someone, somewhere in the past noticed that the problem is around TBS. Below the link:
http://old.nabble.com/Re%3A-Perp-mistakes.-%28multibyte-characters-in-reports%29-td24005630.html

However, I don't got advance from this.
I looked at you purchaseorder.pdf and it seems there's something wrong in the data merge process. The difference with my case is that in my final report I don't see any TBS instruction, only empty spaces.
My problem seems to be caused by line 374 of tinyDoc.class.php: if I insert a var_dump($encodeData); before and after that line I can see that my data are all ok before its execution and that they become null soon after.
Would you please verify if it happens to you too?

Regards
MicheleT
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

Hi Michele, hi all,

What should happen? I followed your advice and inserted var_dump($encodeData) before and after the line 374 of tinyDoc.class.php but nothing was returned for me. The report was generated like the others and in apache error_log appeared the below message:
Error generating report purchase_order PV-001-0065-08-09: item 'n_fileas' is not an existing key in the array., referer: http://****/egroupware/index.php?menuaction=perp_api.ui_perp_report.get_report&appname=perp_ap&report_name=perp_ap.purchase_order


Do you have some idea?Anybody does?

Thanks for your efforts

MicheleT wrote
I looked at you purchaseorder.pdf and it seems there's something wrong in the data merge process. The difference with my case is that in my final report I don't see any TBS instruction, only empty spaces.
My problem seems to be caused by line 374 of tinyDoc.class.php: if I insert a var_dump($encodeData); before and after that line I can see that my data are all ok before its execution and that they become null soon after.
Would you please verify if it happens to you too?

Regards
MicheleT
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

In reply to this post by MicheleT-2
MicheleT wrote
I looked at you purchaseorder.pdf and it seems there's something wrong in the data merge process. The difference with my case is that in my final report I don't see any TBS instruction, only empty spaces.
My problem seems to be caused by line 374 of tinyDoc.class.php: if I insert a var_dump($encodeData); before and after that line I can see that my data are all ok before its execution and that they become null soon after.
Would you please verify if it happens to you too?

Regards
MicheleT
Solved (thanks to http://www.tinybutstrong.com/forum.php?msg_id=6201#msg_6201)!
I've only inserted this line
    $encodeData = htmlspecialchars(utf8_encode($encodeData));
before line 322 in tinyDoc.class.php. Hope it works for you too.

Nathan, I know that this is not the better way to do it and that if you look at that link you can find a better one. The call to the utf8_encode() function demonstrates that pERP data reach that line in a non UTF-8 encoding, so I think it's better to encode all pERP data before calling TBS methods.

Regards
MicheleT
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

In reply to this post by PCSLists
PCS-Lists wrote
What should happen? I followed your advice and inserted var_dump($encodeData) before and after the line 374 of tinyDoc.class.php but nothing was returned for me.
You should see on the first page of your report the content of $encodeData. There should be a line for each field of the report. After those lines you'll find a lot of pages full of strange characters: this is the zipped doc generated by TBS so don't care.

PCS-Lists wrote
 The report was generated like the others and in apache error_log appeared the below message:
Error generating report purchase_order PV-001-0065-08-09: item 'n_fileas' is not an existing key in the array., referer: http://****/egroupware/index.php?menuaction=perp_api.ui_perp_report.get_report&appname=perp_ap&report_name=perp_ap.purchase_order
Sorry, but this means that you have another kind of problem and that also explains why you had all those TBS instructions in your purchaseorder.pdf. Are you sure that this happens only when there are special chars in the report? If so, the cause shold be in perp_ap.ui_perp_report.

Regards
Michele
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

MicheleT wrote
You should see on the first page of your report the content of $encodeData. There should be a line for each field of the report. After those lines you'll find a lot of pages full of strange characters: this is the zipped doc generated by TBS so don't care.
My report was generated like the others. No first page with content of $encodeData. Is really the below code, what I would make?
    // remove specials chars from 0x00 to 0x1F
          $encodeData = preg_replace('/[\x{00}-\x{1F}]+/u', '', $encodeData);
     var_dump($encodeData);
          return $encodeData;  (line 374)
     var_dump($encodeData);


MicheleT wrote
Sorry, but this means that you have another kind of problem and that also explains why you had all those TBS instructions in your purchaseorder.pdf. Are you sure that this happens only when there are special chars in the report? If so, the cause shold be in perp_ap.ui_perp_report.
Specifically the report_purchase_order is not generated correctly, but now special chars seems to be ok, like you can observe beside: purchaseorder2.pdf
However, I have other reports that are not generated correctly only when I insert special characters, like report_inventory_location (on perp_inventory)  
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

PCS-Lists wrote
My report was generated like the others. No first page with content of $encodeData. Is really the below code, what I would make?
    // remove specials chars from 0x00 to 0x1F
          $encodeData = preg_replace('/[\x{00}-\x{1F}]+/u', '', $encodeData);
     var_dump($encodeData);
          return $encodeData;  (line 374)
     var_dump($encodeData);
Not exactly. Look below

    // remove specials chars from 0x00 to 0x1F
     var_dump($encodeData);
          $encodeData = preg_replace('/[\x{00}-\x{1F}]+/u', '', $encodeData);  (line 374 in my copy of SVN trunk 4098)
     var_dump($encodeData);
          return $encodeData;


PCS-Lists wrote
Specifically the report_purchase_order is not generated correctly, but now special chars seems to be ok, like you can observe beside: purchaseorder2.pdf
I'm afraid you forget to insert the link to purchaseorder2.pdf. You say that special chars seems to be ok now. What didi you change? Did you insert my code before line 322?

PCS-Lists wrote
However, I have other reports that are not generated correctly only when I insert special characters, like report_inventory_location (on perp_inventory)  
It works fine for me but only after the change at line 322 and other little changes. In my test there were these chars:

\ " ò ç à ° ù § è é [ { } ] ì ^ € ¢ © & ' < >


Let me know if you need other special chars.

Below you can see the actual state of encodeData() function in my working copy:


  public function encodeData($encodeData)
  {
    // XML charset of OpenOffice / OpenDocument / Word 2007 is utf-8
    switch($this->getCharset())
    {
      case 'ISO 8859-1':
      case 'ISO 8859-15':
        $encodeData = utf8_encode($encodeData);
        break;
      case 'UTF-8':
      case 'UTF8':
        default:
        //MIKE start pERP does not set charset option so tinyDoc assumes default UTF-8
        $encodeData = htmlspecialchars(utf8_encode($encodeData));
        //MIKE end
        break;
    }

//MIKE start No need to do it after $encodeData = htmlspecialchars(utf8_encode($encodeData));
    // convert special XML chars
    //$encodeData = str_replace('&' ,'&',  $encodeData); // the '&' has to be the first to convert
    //$encodeData = str_replace('\'' ,''', $encodeData);
    //$encodeData = str_replace('"' ,'"', $encodeData);
//MIKE end


Regards
Michele
PCSLists PCSLists
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

MicheleT,

I have a question:
I observed that there are two files tinyDoc.class.php
1) perp_api/inc/report/tinyDoc/tinyDoc.class.php
2) perp_api/inc/report/symfony/lib/plugins/sfTinyDocPlugin/lib/tinyDoc.class.php
What of these are you talking about?
I was working in the second file until now, and none of your suggestions worked for me.

About the special characters, I need á, ã, ó, õ, ô, ê

MicheleT wrote
PCS-Lists wrote
My report was generated like the others. No first page with content of $encodeData. Is really the below code, what I would make?
    // remove specials chars from 0x00 to 0x1F
          $encodeData = preg_replace('/[\x{00}-\x{1F}]+/u', '', $encodeData);
     var_dump($encodeData);
          return $encodeData;  (line 374)
     var_dump($encodeData);
Not exactly. Look below

    // remove specials chars from 0x00 to 0x1F
     var_dump($encodeData);
          $encodeData = preg_replace('/[\x{00}-\x{1F}]+/u', '', $encodeData);  (line 374 in my copy of SVN trunk 4098)
     var_dump($encodeData);
          return $encodeData;


PCS-Lists wrote
Specifically the report_purchase_order is not generated correctly, but now special chars seems to be ok, like you can observe beside: purchaseorder2.pdf
I'm afraid you forget to insert the link to purchaseorder2.pdf. You say that special chars seems to be ok now. What didi you change? Did you insert my code before line 322?

PCS-Lists wrote
However, I have other reports that are not generated correctly only when I insert special characters, like report_inventory_location (on perp_inventory)  
It works fine for me but only after the change at line 322 and other little changes. In my test there were these chars:

\ " ò ç à ° ù § è é [ { } ] ì ^ € ¢ © & ' < >


Let me know if you need other special chars.

Below you can see the actual state of encodeData() function in my working copy:


  public function encodeData($encodeData)
  {
    // XML charset of OpenOffice / OpenDocument / Word 2007 is utf-8
    switch($this->getCharset())
    {
      case 'ISO 8859-1':
      case 'ISO 8859-15':
        $encodeData = utf8_encode($encodeData);
        break;
      case 'UTF-8':
      case 'UTF8':
        default:
        //MIKE start pERP does not set charset option so tinyDoc assumes default UTF-8
        $encodeData = htmlspecialchars(utf8_encode($encodeData));
        //MIKE end
        break;
    }

//MIKE start No need to do it after $encodeData = htmlspecialchars(utf8_encode($encodeData));
    // convert special XML chars
    //$encodeData = str_replace('&' ,'&',  $encodeData); // the '&' has to be the first to convert
    //$encodeData = str_replace('\'' ,''', $encodeData);
    //$encodeData = str_replace('"' ,'"', $encodeData);
//MIKE end


Regards
Michele
MicheleT-2 MicheleT-2
Reply | Threaded
Open this post in threaded view
|

Re: eGW, UTF-8 and pERP: problem with UTF-8

PCS-Lists wrote
I observed that there are two files tinyDoc.class.php
1) perp_api/inc/report/tinyDoc/tinyDoc.class.php
2) perp_api/inc/report/symfony/lib/plugins/sfTinyDocPlugin/lib/tinyDoc.class.php
What of these are you talking about?
I was working in the second file until now, and none of your suggestions worked for me.

About the special characters, I need á, ã, ó, õ, ô, ê
I'm sorry, I didn't even know of the second one. I was talking about the first one and my patch should work for your special characters too.

Regards
12