#1106 Stop setting mb_internal_encoding()

[Frida Schratt]

The constructor sets the mb_internal_encoding() to ASCII and changes it back upon destruction. I wonder what in TcPDF specifically requires this?

This was added 10 years ago:

1.53.0.TC016 (2005-08-28)
- fpdf.php and tcpdf.php files were joined in one single class (you can still extend TCPDF with your own class).
- fixed problem when mb_internal_encoding is set.

By the looks of it, the mb functions are only used at two places and in both cases with an explicit encoding.

Is this problem still a problem?

This behaviour is described in the documentation and there are no problem working around it - it is however confusing and if possible to avoid, it would create less confusion.

Other issues on this matter (all closed):

http://sourceforge.net/p/tcpdf/bugs/1020/
https://sourceforge.net/p/tcpdf/bugs/1026/

Feature requests, moved to an issue 821 I can't find:
http://sourceforge.net/p/tcpdf/feature-requests/285/
http://sourceforge.net/p/tcpdf/feature-requests/255/

[Michal Jurica]

I have the same problem with the mb_internal_encoding(). TcPDF change it to ascii and return the original encoding at the end of the script execution. I think it's problem with the register_shutdown_function, that hold the $this pointer and it's not possible to release the class from the memory.

[mauromol]

I also encountered this problem. It's really annoying, because this forces me to perform some string manipulations required to compile my PDFs with explicit encodings, instead of relying on the default value I want to use all over my application...

[sylfabre]

Any update on this matter?