Keine Umlaute mit GIFBUILDER

Ich konnte leider das Problem noch nicht lösen, wohl aber
eine Eingrenzung vornehmen:

1. Mit der Aktivierung von forceCharset = utf-8 im Install-Tool konnte ich erreichen, dass die Umlaute auch in die TYPO3-MySQL-Datenbank gespeichert wurden. Das war vorher für mich nicht offensichtlich - zumindest konnte ich keine Umlaute bei direkten Abfragen mit dem mysql-Client auf die Tabellen tt_content oder pages in der Bash sehen. Alle Texte mit Umlauten musste ich natürlich vorher im Backend ändern. Der GIFBUILDER blieb von dieser Aktion aber unbeeindruckt (auch nach dem Löschen des Inhalts von typo3temp/GB und Leeren des Typo3-Caches)

2. Bei der direkten Verwendung von ImageMagick (meine Version ist 6.2.5) in der Bash mit convert und auch mit der im Typo3-Template verwendeten Schriftdatei (vertana.ttf) werden die Umlaute richtig dargestellt!

3. Ich nehme an, dass auch das GIFBUILDER-Objekt ImageMagick-Funktionen direkt aufruft. Jetzt bleibt nur mehr die Frage offen: Woher bekommt (bzw. durch welche Filter) geht der Text, den das GUIFBUILDER-Objekt an ImageMagick übermittelt. Dieser Text ist in der MySQL-Datenbank UTF-8 codiert und muss irgendwie bei dem Transfer verändert werden.

Ist das vielleicht ein TYPO3-Bug?

aus einem anderen thread habe ich folgendes erfahren:

Das Problem war wirklich der Font mit den erweiterten Zeichensätzen.
Nachdem die Schrift mit TransType (http://www.fontlab.com/Font-tools/
TransType/) zu einem ttf umgewandelt war, lief alles Problemlos. An
dieser Stelle noch mal ein fetter Dank an Michael!

vielleicht ein Ansatz.

Danke für diesen Hinweis, aber:
Wenn bei der direkten Verwendung der ttf-Datei mit ImageMagick in der Bash mit

convert -font .../fileadmin/fonts/verdana.ttf -pointsize 25 -fill white -draw "text 10,35 'Test: ÜüÖöÄäß'" vorlage.jpg testbild.jpg

in das aus vorlage.jpg erstellte neue Bild "testbild.jpg" der Text mit allen Umlauten geschrieben wurde, kann es eigentlich nicht an der verwendeten Schrift liegen. Auch nicht an meiner installierten ImageMagick-Version.

Im nächsten Schritt werde ich versuchen, einen solchen ImageMagick-Aufruf aus PHP heraus zu probieren, dann kann ich sehen, ob das SuSE-Apache-php-Modul dieses Problem verursacht.

Mühsam, mühsam ...

hab da jetzt ein mail nur teils im kopf (kann erst nächste woche nachschlagen) und da hing das Problem vom Titel ab, je nach Setzung von leerzeichen (und/oder bindestrich) gabs umlaute oder auch nicht...

georg

Ich habe jetzt herausgefunden, dass es an der GDLib-Version liegt, die bei SuSE 10.1 verwendet wird. Es handelt sich um das Paket php5-gd, welches in der Version 5.1.2 vorliegt.

Ich habe in einem PHP-Skript mit ImageCreate() und ImageFTText() - das sind Befehle aus dem php5-gd-Modul - eine Grafik mit TTF-Text erzeugt: Dabei werden die deutschen Umlaute nicht richtig angezeigt!

In der PHP-Dokumentation zu ImageFTText() bzw. ImageTTFText() ist zu lesen: ... der auszugebende String, der auch UTF-8-Zeichenfolgen enthalten darf (z.B. &# 123😉.

Damit ließ sich ein "Work-Around" für mein Problem basteln: Im BE müssen bei Texten, die Umlaute enthalten und aus denen mit GIFBUILDER Texte erzeugt werden sollen die Umlaute wie folgt kodiert werden:

Ä: &# 196;
ä: &# 228;
Ö: &# 214;
ö: &# 246;
Ü: &# 220;
ü: &# 252;
ß: &# 223;

(Das Leerzeichen nach &# muss natürlich jeweils weggelassen werden!)

LG

Vielleicht ganz gute Querverlinkung:

http://bugs.typo3.org/view.php?id=5078

und das hier auch:

#51279

PS: Ich weiss, ist schon älter der Thread, aber der Bug tritt leider immer noch auf. Zumindest bei mir auf einem openSuSE 10.2 mit php5 inkl. aller updates.
Und ich hab wenig bock auf php5 neu kompilieren. :-(

ich roll das Thema hier mal wieder neu auf ... (bitte nich hauen 🙂 )

also bei mir ist es so der Apache2 und PHP5 sind ca. gleiche Konfiguriert wurden und die DB natürlich auch...
Test-Server: lokaler Debian Etch Server
Web-Server: SuSE Linux (V. glaube OpenSuse 10.1)

auf dem Debian Server werden die Umlaute perfekt angezeigt im Gifbuilder, aber dann auf dem SuSE Server werden die Umlaute komplett zerhakt... also Garnicht dargestellt... und da wollte ich die class.tslib_gifbilder.php bearbeiten nur leider finde ich den eintrag nicht, wo der Text übergeben wird, den da wollte ich dann mit der str_replace()-Funktion von PHP die UNICODEs (wie in hebi's beitrag gezeigt werden) rein packen statt den öäü usw. 😉

danke schonmal für eure hilfe...

ich habe es jetzt mit suche gefunden mit dem Teil der Funktion klappt es nur finde ich nicht die daten in typo3 wo "imagettftext" oder ähnliches benutz werden

http://de.php.net/imagettftext#57416

MfG Gunah

http://bugs.typo3.org/view.php?id=5078

--> Meine Einträge zum Thema (ganz unten).

die zu ändernde Klasse ist class.t3lib_stdgraphic.php

greets clemens

Hier noch eine Antwort von mir auf so eine Frage in der typo3.german Newsgroup:

1. PHP-Datei mit User Function:

function encode($content,$conf) {
$convmap = array(0x80, 0xff, 0, 0xff);
return mb_encode_numericentity($content,$convmap, "utf-8");
}

Dabei den String utf-8 so einstellen, dass er dem BE Encoding entspricht.

2. Datei im TS einbinden (per includeLibs)

3. im GMENU als postUserFunc

Das klappt ganz gut.

Grüße
Christian

danke für die antworten hab die Lösung vorher schon von "BastianBalthasarBux" selber gebaut und da werden mit einer Funktion auch alle Daten umgewandelt

es funktioniert soweit auch alles ganz gut nur wird das kleien "Ü" nicht richtig angezeigt sobald ein n, s und ein paar andere wenn es alleine steht funtzt das oder bei anderen einpaar anderen Buchstaben
werde deins aber mal ausprobieren in dem ich das original verändere 😉
und das bist da denk ich mal Clemens Riccabona

zu Kitsunet... meinst du in der localconf.php utf8 einstellen... wenn ich das mache sind alle Sonderzeichen im Eimer im normalen text bei mir zumindest und wir haben jetzt schon zuviel zeit in Typo3 reingesteckt das wir es neu aufsetzten ...

MfG Gunah
EDIT: hab es nach der Anleitung gemacht von Bastian funktionierte leider nicht hab dann die funktion umgebaut...

die LÜCKE nach der Raute (#) weg machen...

function ricEncode($content) {
      /*$convmap = array(0x80, 0xff, 0, 0xff);
	  $charset=mb_detect_encoding($content, "auto");
      return mb_encode_numericentity($content,$convmap,$charset);*/
	  $array['search'] =array('Ä','ä','Ö','ö','Ü','ü');
	  $array['replace']=array('&# 196;','&# 228;','&# 214;','&# 246;','&# 220;','&# 252;');
	  return str_replace($array['search'],$array['replace'],$content);
    }

edit2: ich habs herrausgefunden der Server läuft komplett in Latin1 mysql als auch apach2... aber mit "meiner" funktion geht des och

Hallo zusammen,

hatte das selbe Problem und habe es mit der Lösung von Clemens Riccabona gelöst bekommen.

Da ich allerdings ungerne die Core-Files bearbeite habe ich das ganze in eine Extension namens cr_bugfix_5078 gepackt.

Die kann man im TER runterladen und dann funktionieren nach der Installation auch die Umlaute wieder mit normalen TTF Schriften.

Gruß Semidark

Hallo Halbschwarzer!

Super Sache, die EXT, habs schon auf bugs.typo3.org gesehen
Finds auch total altruistisch von Dir, sie cr_ zu präfixen!
Werds die Tage mal testen, und natürlich bewerten! 😉

lg Clemens (R.) 😃

Hallo Clemens,

ich muss gestehen das ich alle meine extensions mit cr präfixe wegen meinem Firmennamen Creatible #paralyzed# . Was aber dein enorme Vorarbeit in keinster art und weise schmälern soll 😉

Habe gerade gesehen das die Extension nun im TER zu finden und habe zu meiner freude festgestellt das es bereits ein paar mal runtergeladen wurde.

Also hier noch ein bisserl mehr werbung 🙂
http://typo3.org/extensions/repository/view/cr_bugfix_5078/0.0.1/

Gruß Semidark

Hihi, deswegen präfixe ich meine exts üblicherweise mit ric* 😉

Vielen Dank, die Umlaute funktionieren prima.

Leider habe ich noch Probleme mit Sonderzeichen in Verbindung mit windngs2.ttf

Hier will ich das Zeichen £ nutzen. Es wird mit nur ein kleiner Rahmen angezeigt..... :-(

Könnt ihr mir helfen oder einen Tipp geben?

Ich habe alles auf UTF8 umgestellt.

Vielen Dank.

tja, alle zeichen funzen damit nicht.
im moment hab ich auch noch ein problem mit kyrillisch.
man muss evtl. die conv-map erweitern.

hat jemand zufällig eine funktionierende convmap für kyrillisch?? 😃

kann dafür die für japanisch liefern. 😉

Hervorragend - war genau das was ich gesucht habe um das Problem der fehlende / fehlerhaften Umlaute in gerendertem Text aus der Welt zu schaffen.

Danke für eure Mühe!

@ulrich,

wenn da ein Kästchen anstatt des Zeichens gerendert wird liegt es sehr warscheinlich am verwendeten Font.

Hast du Überprüft ob das Pfundzeichen im Font vorhanden ist?

@rizzla,
NP

Gruß Semidark

Aus gegebenem Anlass (pm anfrage).
Ich habe meine ricEncode funktion upgedated, und nun sollts auch mit japanisch hinhauen.
Ich hoffe wir kriegen feedback.
Anbei die funktion, vielleicht könnt ma ja die ext updaten! 😉

function ricEncode($content) {
	    $enc = mb_detect_encoding($content, "auto");
            $convmap = array(
              0x0080, 0x00ff, 0, 0x00ff,
              0x0400, 0x04ff, 4, 0x04ff,
              0xe000, 0xe03e, 0x1040, 0xffff,
              0xe03f, 0xe0bb, 0x1041, 0xffff,
              0xe0bc, 0xe0fa, 0x1084, 0xffff,
              0xe0fb, 0xe177, 0x1085, 0xffff,
              0xe178, 0xe1b6, 0x10c8, 0xffff,
              0xe1b7, 0xe233, 0x10c9, 0xffff,
              0xe234, 0xe272, 0x110c, 0xffff,
              0xe273, 0xe2ef, 0x110d, 0xffff,
              0xe2f0, 0xe32e, 0x1150, 0xffff,
              0xe32f, 0xe3ab, 0x1151, 0xffff);
            return mb_encode_numericentity($content,$convmap, $enc);
        }

lgc

ps: ich such immernoch kyrillisch!!! also wenn jemand was weiss, her damit! 😉

Ok Ok. #giggle#

Ich habe die ext aktualisiert. Bei mir funktioniert es wunderbar.

Gruß Semidark