ID: 42218
Updated by: [EMAIL PROTECTED]
Reported By: fernando at barnatech dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Suse 10.2
PHP Version: 5.2.4RC1
Assigned To: pajoye
New Comment:
"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).
Previous Comments:
------------------------------------------------------------------------
[2007-08-08 08:02:32] fernando at barnatech dot com
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.
------------------------------------------------------------------------
[2007-08-06 17:15:14] [EMAIL PROTECTED]
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...").
------------------------------------------------------------------------
[2007-08-06 15:29:25] fernando at barnatech dot com
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
------------------------------------------------------------------------
[2007-08-06 15:21:15] fernando at barnatech dot com
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.
------------------------------------------------------------------------
[2007-08-06 11:55:21] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42218
--
Edit this bug report at http://bugs.php.net/?id=42218&edit=1
