Don't open two bugs for the same issue.

"By the way, there are no font bugs solved since PHP 5.0.4."

So wrong. if you have any issue with the ttf function, please report them with:
- the font you use
- a script to reproduce it
- the encoding used in your script

Thanks.

But I close this bug as duplicated of #39543 (> bogus). Add your comments to #39543.

Sorry, regarding to bug #39543, I thought "closed" meant "closed". It's a little nonsense to address me to a bug that is closed just for bad version reporting, as I'm opening it for the most current version, and I can't reopen the closed old one, nor post any comment there.

In fact, I simply cannot post any comment in bug #39543 (it was the first thing I attempted, as you can imagine), because someone sealed that bug just because the version was mistakenly reported as 5.1.2. But the bug is in current version 5.2.4RC1, at least with the euro sign.

I'm very astonished to see that someone has used a bad version reporting mistake to close these two bugs without the possibility to add further comments or verifications to them. It gives the feeling that people looks at these bug reporting thing with no other intention than closing them without a real test.

Excuse me, but I can't understand this bug reporting dynamic. It seems proved that bugs like this one are simply lost. And it's a bit offending to see someone sending me to post a comment in a mistakenly closed bug report where I can't post anything.

"By the way, there are no font bugs solved since PHP 5.0.4."
My comment was based in the changelog. As we're told, please check the changelog. I've done it.

Well, more calmed now. I'll try to refine my report, as the original bug is mistakenly closed (and comments there now allowed) due to bad version reporting, and I can't post this anywhere but here.

I have verified this issue still happens in version 5.2.4RC1 with any string containing the euro sign. I can't verify it happens with other special signs, as the original bug reported, but the euro sign itself is critical enough for business reports.

This is my own offending code. It's exactly the same code as the original posted, but the special "offending" char diffier.


Code to reproduce:

list($x1,,$x2) = imagettfbbox(8, 0, '/var/www/virtual/external.dev/framework/dompdf/lib/fonts/Arial.ttf', '?');


Unexpected result:

Warning: imagettfbbox() [function.imagettfbbox]: any2eucjp(): invalid
code in input string in /var/www/virtual/external.dev/framework/dompdf/include/gd_adapter.cls.php on line 597


Code, data and encoding along all the application is UTF-8.

Details on GD used:
GD Support 	enabled
GD Version 	bundled (2.0.28 compatible)
FreeType Support 	enabled
FreeType Linkage 	with freetype
FreeType Version 	2.2.2
GIF Read Support 	enabled
GIF Create Support 	enabled
JPG Support 	enabled
PNG Support 	enabled
WBMP Support 	enabled
XPM Support 	enabled
XBM Support 	enabled
JIS-mapped Japanese Font Support 	enabled

Ok, I revert the process, easier than asking you again to comment there...

For the record, when the status says "bogus", it means it is not a bug. It can be hundred of reasons. I don't like this wording either but I'm not alone to decide here. But that's no reason to begin a rant here and now. I'm here to help you to fix a problem not to read rants.


"Well, more calmed now."

Good, you'll get more chance to get me reading your report if you are calm.

So, about this bug. Which encoding do you use in your script?

Can you try with a true 5.2.4RC1 (what I see in your phpinfo details is not from 5.2.4RC1, you should read "2.0.34...").

Strange, as I pasted directly that phpinfo() output. I had installed the 5.2.4RC1 version on a dev webserver over a previously PHP version test, but I'm afraid I can't do it again. It was a development environment I set up when I found this bug in our stable dev version 5.2.0, just to test if it had been corrected in 5.2.4RC1, as a prior step before reporting it here. But since yesterday that server doesn't exist anymore, and I have no spare machines right now (resources fly here).

I think I don't understand exactly what are you asking about encoding. For me, encoding is the charset used with data, or code, or HTML output. But it seems it's not what you're asking. I don't manage font charsets, if it helps.

"I have no spare machines right now (resources fly here)."

Fetch a snapshot (windows for example), uncompress it and execute your script using it. That's all I need :)

"I think I don't understand exactly what are you asking about encoding.
For me, encoding is the charset used with data, or code, or HTML output.
But it seems it's not what you're asking."

Which enconding do you use in your script files, iso-xxxx, UTF-8, etc. Your editor should be able to tell you that. That determines what you actually pass to the imagettf function (UTF-8 is the safest way).

The code encoding is UTF-8 as I told. We carefully use UTF-8 for code in the IDE, for data in the DBMS and for output in the webserver.

I think a test is not so easy to perform in my job environment. Usually I have no direct access to installation privileges, further than limited ones in the development servers. No access to clients administration, no PHP installation, recompilation or direct reconfiguration without an administrative permission, etc. I promise you it's not so easy.

Working with PHP 5.2.0 right now. The bug is there too, of course.

By the way, may he bug disappear if PHP-GD is recompiled without japanese support? The "any2eucjp()" in the error suggests it.

About the install, on windows you don't have to install anything. You can run php directly from the uncompressed directory, using the console (cmd).

"By the way, may he bug disappear if PHP-GD is recompiled without
japanese support? The "any2eucjp()" in the error suggests it."

Yes, if you don't need japanese, disable it. I suspect a conflict between the encoding.

I'll ask to the sysadmin team for a recompilation without japanese support and then for a test repetition. It can last for days, I think. I'll tell you the progress, if there's some.

I experienced the same problem as described above. 
source file encoding: UTF-8
PHP version: 5.2.2
GD Version: bundled (2.0.34 compatible)
OS: Sabayon Linux

I recompiled PHP with japanese support disabled and it seems to make 
problem go away.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Feedback provided by grzegorz

Hello! 

I'm in an interresting situation where I have to configurations - one in which the problem occurs, one in which works perfectly fine. 

I can't really tell the difference between the configurations, so i just post the most important phpinfo() elements here and i hope it helps. 

Both versions of php aren't recent. As it works in the older one (5.2.2) and doesn't in the newer one i suspect it is more of a configuration issue. 


---------- WORKING CONFIGURATION --------- 
os x 10.4, xampp server, php 5.2.2
configure string: 
'./configure' '--prefix=/Applications/xampp/xamppfiles' '--program-suffix=-5.2.2' '--libdir=/Applications/xampp/xamppfiles/lib/php/php5' '--includedir=/Applications/xampp/xamppfiles/include/php/php5' '--with-apxs2=/Applications/xampp/xamppfiles/bin/apxs' '--with-config-file-path=/Applications/xampp/etc' '--with-mysql=/Applications/xampp/xamppfiles' '--disable-debug' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-discard-path' '--enable-exif' '--enable-filepro' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-gd-imgstrttf' '--enable-gd-native-ttf' '--with-ttf' '--enable-magic-quotes' '--enable-memory-limit' '--enable-safe-mode' '--enable-shmop' '--enable-sigchild' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-wddx' '--enable-yp' '--with-ftp' '--with-ncurses=/Applications/xampp/xamppfiles' '--with-gdbm=/Applications/xampp/xamppfiles' '--with-jpeg-dir=/Applications/xampp/xamppfiles' '--with-png-dir=/Applications/xampp/xamppfiles' '--with-freetype-dir=/Applications/xampp/xamppfiles' '--without-xpm' '--with-zlib=yes' '--with-zlib-dir=/Applications/xampp/xamppfiles' '--with-openssl=/Applications/xampp/xamppfiles' '--with-expat-dir=/Applications/xampp/xamppfiles' '--enable-xslt=/Applications/xampp/xamppfiles' '--with-xsl=/Applications/xampp/xamppfiles' '--with-dom=/Applications/xampp/xamppfiles' '--with-ldap=/Applications/xampp/xamppfiles' '--with-gd' '--with-mysql-sock=/Applications/xampp/xamppfiles/var/mysql/mysql.sock' '--with-mcrypt=/Applications/xampp/xamppfiles' '--with-mhash=/Applications/xampp/xamppfiles' '--enable-sockets' '--with-curl=/Applications/xampp/xamppfiles' '--enable-mbregex' '--enable-zend-multibyte' '--with-zip=/Applications/xampp/xamppfiles' '--enable-exif' '--with-sqlite' '--with-libxml-dir=/Applications/xampp/xamppfiles' '--enable-soap' '--enable-pcntl' '--enable-dbx' '--with-mysqli=/Applications/xampp/xamppfiles/bin/mysql_config' '--with-bz2=/Applications/xampp/xamppfiles' '--with-ming=shared,/Applications/xampp/xamppfiles' '--with-pear=/Applications/xampp/xamppfiles/lib/php/pear' '--with-mssql=/Applications/xampp/xamppfiles' '--with-imap-dir=/Applications/xampp/xamppfiles' '--with-imap=/Applications/xampp/xamppfiles' '--enable-mbstring=all' '--with-pgsql=shared,/usr' '--with-gettext=/Applications/xampp/xamppfiles'


mbstring config: 
mbstring
Multibyte Support 	enabled
Multibyte string engine 	libmbfl
Multibyte (japanese) regex support 	enabled
Multibyte regex (oniguruma) version 	4.4.4
Multibyte regex (oniguruma) backtrack check 	On

Directive	Local Value	Master Value
mbstring.detect_order	no value	no value
mbstring.encoding_translation	Off	Off
mbstring.func_overload	0	0
mbstring.http_input	pass	pass
mbstring.http_output	pass	pass
mbstring.internal_encoding	no value	no value
mbstring.language	neutral	neutral
mbstring.script_encoding	no value	no value
mbstring.strict_detection	Off	Off
mbstring.substitute_character	no value	no value



----------- BROKEN CONFIGURATION (my webhost)-------------
some linux, php 5.2.3

configure string: 
 Command 	 './configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--prefix=/imports/php5' '--with-config-file-path=/imports/php5/' '--with-openssl=/usr/local/ssl' '--with-dom' '--with-iconv' '--with-curl' '--with-mysql=/usr/local' '--with-gettext' '--enable-mbstring' '--with-xml' '--enable-track-vars' '--enable-exif' '--with-jpeg-dir' '--with-zlib' '--with-zlib-dir' '--with-png-dir' '--with-gd' '--with-gettext' '--with-freetype-dir' '--with-xpm-dir' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-mhash' '--enable-ftp' '--with-pear' '--with-pspell' '--with-mysqli=/usr/local/bin/mysql_config' '--with-ldap' '--with-ldap-sasl' '--with-imap=../imap-2004g' '--with-imap-ssl=/usr/local/ssl' '--with-libxml' '--with-xsl' '--with-libexpat-dir=/usr' '--with-mcrypt' '--enable-bcmath' '--with-mime-magic' '--enable-calendar' '--with-pdo-mysql' '--enable-sockets' '--enable-soap' '--with-tidy'

mbstring
Multibyte Support 	enabled
Multibyte string engine 	libmbfl
Multibyte (japanese) regex support 	enabled
Multibyte regex (oniguruma) version 	4.4.4
Multibyte regex (oniguruma) backtrack check 	On

Directive	Local Value	Master Value
mbstring.detect_order	no value	no value
mbstring.encoding_translation	Off	Off
mbstring.func_overload	0	0
mbstring.http_input	pass	pass
mbstring.http_output	pass	pass
mbstring.internal_encoding	no value	no value
mbstring.language	neutral	neutral
mbstring.strict_detection	Off	Off
mbstring.substitute_character	no value	no value






Conclusions? 
To save you reading all that configurations - i realized only two differences: 
- the working config was compiled with --enable-mbstring=all, the broken one only with --enable-mbstring

- the working config's phpinfo shows mbstring.script_encoding set to no value, the broken config (even though it's newer) doesn't list this option.

Hey! 

I could fix the problem (on my host) by forcing an internal encoding. 
ini_set( "mbstring.internal_encoding", "UTF-8" );

Is it possible that gd fails just because there is no default encoding set? 

Can anyone verify this? 

p.s.
So here's what i think is happening: 
I have two machines (see my previous post), it works on one machine because the mbstring.internal_encoding is not set and gd has no japenese support built in. Thus php and gd will fall back to unicode. 

On the other machine mbstring.internal_encoding isn't set either, but this time gd has japanese support built in. As no encoding is set php falls back to unicode while gd falls back to japanese, resulting in incompatible encodings. The rest is history. 

Well... just some wild imaginations of someone who's never taken a look at the sourcecode...

There is no fallback ot UTF-8. It accepts UTF-8 by default. The problem about JIS is when you pass a non UTF-8 string, it can be seen as JIS enconded string.

About the mbstring issues, I have no idea how it works and how it affects the input parameters. It is something happening before we got the hand in the gd function.

Please try using:

- Without mbstring, with jis enabled
- Without mbstring, without jis

It will help us (you and us) to figure out what break your config.

Hey! 

I'm sorry, i always found compiling the php module with all the dependencies a pain, which is why I'm using Xampp. 

I'm being pretty busy at the moment and don't have time for setting up the build environment and testing it out. As I said - I got around the issue by using ini_set( ... ) with mbstring compiled in on two different servers (with and without jis comiled into gd).

Maybe there is someone who test compiles php everyday that could try it out with the different settings. 

If you would like to have the code used for testing please let me know.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

same problem.
Warning: imagettfbbox(): any2eucjp(): invalid code in input string in /media/psf/pf/lib/ImageChart/LineChart.class.php on line 551

os:centos 7
file encoding:utf-8
text：标题 in chinese
font:msyh.ttf (Microsoft YaHei)
phpver:5.5.14
extver:
curl-7.37.0.tar.gz
freetype-2.5.3.tar.bz2
jpegsrc.v9a.tar.gz
libevent-2.0.21-stable.tar.gz
libmcrypt-2.5.8.tar.gz
libpng-1.6.12.tar.gz
libxml2-2.6.30.tar.gz
libxslt-1.1.22.tar.gz
php-5.5.14.tar.bz2
zlib-1.2.8.tar.gz

phpconfig:
'./configure' '--prefix=/usr/local/services/php' '--enable-fpm' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-config-file-path=/usr/local/services/php/etc' '--with-gd' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-freetype-dir=/usr/local/services/plugin/freetype/' '--with-jpeg-dir=/usr/local/services/plugin/jpeg/' '--with-png-dir=/usr/local/services/plugin/libpng/' '--with-zlib-dir=/usr/local/services/plugin/zlib/' '--enable-xml' '--enable-mbstring' '--enable-soap' '--with-libxml-dir=/usr/local/services/plugin/libxml/' '--with-xsl=/usr/local/services/plugin/libxslt/' '--with-curl=/usr/local/services/plugin/curl/' '--with-mcrypt=/usr/local/services/plugin/libmcrypt/' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-iconv-dir=/usr/local/services/plugin/libiconv/' '--enable-sockets'

Simply use UTF-8 for text. Following code works.
(Make sure you have Japanese font installed or use proper font/text)

<?php
$im = imagecreatetruecolor(300, 150);
$black = imagecolorallocate($im, 0, 0, 0);
$white = imagecolorallocate($im, 255, 255, 255);

imagefilledrectangle($im, 0, 0, 299, 299, $white);

$font = '/usr/share/fonts/mplus/mplus-2c-regular.ttf';

$bbox = imagettfbbox(10, 45, $font, 'Powered by PHP ' . phpversion());

$x = $bbox[0] + (imagesx($im) / 2) - ($bbox[4] / 2) - 25;
$y = $bbox[1] + (imagesy($im) / 2) - ($bbox[5] / 2) - 5;

imagettftext($im, 10, 45, $x, $y, $black, $font, '日本語 Powered by PHP ' . phpversion());

$bbox = imagettfbbox(10, 45, $font, 'and Zend Engine ' . zend_version());

$x = $bbox[0] + (imagesx($im) / 2) - ($bbox[4] / 2) + 10;
$y = $bbox[1] + (imagesy($im) / 2) - ($bbox[5] / 2) - 5;

imagettftext($im, 10, 45, $x, $y, $black, $font, 'and Zend Engine ' . zend_version());

header('Content-Type: image/png');

imagepng($im);
imagedestroy($im);

I can reproduce an error on PHP 5.5.21 (Further information at <http://phpinfo.bplaced.net/>, GD 2.1.0, Freetype 2.5.0 with JIS-mapped Japanese Font Support enabled. I cannot reproduce it on a system with PHP 5.5.21, GD 2.1.0, Freetype 2.5.5 and no JIS-mapped Japanese Font Support.

    ini_set("mbstring.internal_encoding", "UTF-8");

has no effect. File is encoded as UTF-8 without BOM (with BOM makes no difference).

Code:

<?php

    $box = imagettfbbox(12, 90, 'artichow/font/Tuffy.ttf', '– km €');

    $box = imagettfbbox(12, 90, 'artichow/font/Tuffy.ttf', '– €');

    $box = imagettfbbox(12, 90, 'artichow/font/Tuffy.ttf', 'km €');

?>

For the first two commands, I get

Warning: imagettfbbox() [function.imagettfbbox]: any2eucjp(): invalid code in input string in /test.php on line n

The last command seems to be fine.

It looks like imagettfbbox() tries to determine the character encoding for the string (instead of accepting it as UTF-8) and thinks for some reason it might be some Japanese encoding.

I think you have problem with font file. Try mplus to see if it works.

Indeed, the error message goes away. Probably because there are corresponding Japanese glyphs in the mplus font. But the problem persists: The given string is UTF-8 but ImageTTFBBox() does not treat it as UTF-8 but some JIS encoding. (And this only happens if GD library is compiled with JIS-mapped Japanese Font Support.)

If I draw a diagram with the mplus font, I can see the Japanese symbols. I'd rather expect a simple ndash (–) and the Euro sign (€) in the diagram, no Japanese characters.

Somehow, my last response did not get posted. I wrote on 2015-02-23 11:36 UTC that the error message disappeared with the new font. This was wrong. It is still there.

Have this same issue with PHP 8.0.25 (cli) (built: Nov 20 2022 23:13:38) ( ZTS )

Test case is with "standard aria" and Unicode char ✔

According to

http color slash slash zuga.net/articles/unicode-all-characters-supported-by-the-font-arial-unicode-ms/

this should be supported by Arial (but ok ...)

Example script which triggers the error:

<?php
$fontFile = '/usr/share/fonts/corefonts/arial.ttf';
$text = '✔';
$textBox = imagettfbbox(10.0, 0, $fontFile, $text);