I can describe the problem with iconv() that underlies this for my solaris
environment:
On some of our servers, a call to iconv() with empty $in_charset and
'CP1252//IGNORE' as the $out_charset results in empty output. On other
servers, it results in expected output. This is with only "typical" U.S.
keyboard characters, my use cases do not involve any other languages or
character sets.
PHP config reports the iconv settings on all servers are the same.
iconv.input_encoding, iconv.internal_encoding, and iconv.output_encoding are
all set to ISO-8859-1. Leaving aside whether they should be set to
something else; they're consistent. Sysadmins report no differences in
locale settings on the solaris installations.
I would think that an empty input to that param when calling iconv() would
result in use of the default setting. Oddly though, if I pass "ISO-8859-1"
as $in_charset, output is returned. Maybe this is a bug in the iconv
extension? Although currently I can't explain why some of our servers don't
exhibit this behavior.
Because of that last bit, I can also fix this by hacking
Zend_Pdf_Resource_Font_Simple::encodeString() as follows. Maybe not a bad
change to make in general? Not really sure if I should use input_encoding
or internal_encoding though.
public function encodeString($string, $charEncoding)
{
if (PHP_OS == 'AIX') {
return $string; // returning here b/c AIX doesnt know what
CP1252 is
}
if (empty($charEncoding)) {
$charEncoding = ini_get('iconv.input_encoding');
}
return iconv($charEncoding, 'CP1252//IGNORE', $string);
}
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/Zend-PDF-drawText-and-blank-PDF-files-tp1589208p2531780.html
Sent from the Zend Framework mailing list archive at Nabble.com.
