2011-10-22T17:26:32 GwenDragon

Es wäre schon schön, wenn du uns einen kleinen Testcase zur Verfügung zu stellst und auch Angaben zu deiner Perl- und Modulversion machst, die du verwendet hast. Ansonsten sind Systemvergleiche ohne Ausgangsdaten und Kurzprogramm schwierig.

Ich tippe auf ein vorhandenes, an fehlerhafter Stelle stehendes oder fehlendes use utf8; oder auf eine merkwürdige De-/Umkodierungsfunktion, die du benutzt.

Du tippst nicht richtig. Ein use utf8; ist wirkungslos, solange die Strings keine im Script notierten Literale sind. Eine Umkodierung ist auch nicht notwendig, weil die Strings als SvUTF8 vorliegen. Damit funktioniert die lesbare Ausgabe von application/pdf mit PDF::Create auf dem Webserver, von dem ich folgende Angaben machen kann:

Perl v5.8.8
$PDF::Create::VERSION 1.05
OS: Linux-Derivat, Details unbekannt
Webserver: Apache, Details unbekannt
Reader: PDF-Plugins in FF 3.6.3 und IE 8
Locale: keine Ahnung was da gesetzt ist und ob das überhaupt einen Einfluss hat.

Unterschiede vs. XP gibt es Einige außer $PDF::Create::VERSION und die Reader, die sind gleich.

Viele Grüße,
Jugend forscht ;-)

Edit, erste Forschungsergebnisse: Der remote Apache liefert eine kleinere Datei als mein localer Apache. Die kleinere Datei ist sauber lesbar.

Eine local direkt erzeugte PDF (ohne Umweg über den Apache) ist unleserlich. Fazit: Es ist irgendein locales Problem ;)

Edit/Überraschung:
=======================

Die remote erzeugte PDF enthält GAR KEINE utf-8-kodierten Zeichen, sondern Zeichen in iso-8859-1 Kodierung, obwohl das Create-Script utf-8-kodierte Zeichen in die PDF::Create::string()-Funktion gibt. Deswegen ist die Datei auch kleiner als eine local erzeugte PDF-Datei (siehe weiter oben) ;)

Fazit: Da kann ich auch gleich alles selbst nach ISO umkodieren, da weiß ich wenigstens, wers gemacht hat!!!

Schönes Wochenende ****SMILE*****
Last edited: 2011-10-22 21:32:51 +0200 (CEST)