[ANNOUNCE] UTF-8 patch 0.1.0 mit Freetype und Antialiasing

Hi!

Kann man nach einspielen dieses Patches auch ohne weiteres das iocharset der Festplatte auf UTF8 einstellen?

Cheers

mic

Edit: Sorry, hab mir den Patch nochmal genauer angesehen und einen Teil meiner Frage zurückgezogen.

Hi,

das hört sich ja super an!
Ich habe jedoch noch folgende Frage zur Installation: Aus der Wiki

Installation


    * patch anlegen
    * benötigte fonts in standard video Verzeichnis kopieren. 


courbd.ttf, arialbd.ttf und arial.ttf werden standardmäßig benötigt.

Ist damit in jedem Fall das /video Verzeichnis oder das config-Verzeichnis (bei mir /etc/vdr) gemeint.

Gruß
Boris

Bringt der Patch auch Vorteile auf nem TV oder "nur" in Zusammenhang mit der Ausgabe auf nem Monitor?

LG
Roman

Sehr schön. Sobald Xorg 7.0 raus ist, wird mein neues LFS mit UTF8 Unterstützung fertig, da passt dieser Patch hervorragend rein.

Cooler Patch, welche Chancen wird er wohl bei Klaus haben?

Hallo erstmal,

ich wollte diesen Patch schon seit längerer Zeit ausprobieren, da ich ja auch früher wegen der fehlenden Möglichkeit, verschiedensprachige Texte gleichzeitig im OSD des VDR anzuzeigen, in der Mailinglist 'rumgemeckert hatte. Immer hat bei mir aber wenn ich mich daran erinnerte, entweder die aktuell eingesetzte VDR-Version nicht gepasst, oder ich hatte einfach keine Zeit (geht mir momentan fast auch so mit der Zeit).
Nun, ich habe gestern abend trotzdem nachdem ich es von zzam erfuhr, mir das in den Screenshots im Wiki und im Code des Patches mal ein wenig angeschaut, ich muß nur sagen, feine Sache! Momentan benutze ich sogar den vdr-1.3.37, ich könnte den Patch auch probieren und genießen, nur gibt es da ein kleines Problem. Ich arbeite an einem Patch, der auch an den Phrases in i18n.c und generell in dieser Datei 'rummacht, und meiner ist auch schon lauffähig (bis auf die Plugins) :-). Es gehrt um die Auslagerung der Phrases in externe Sprachdateien, mittels gettext und PO/MO-Dateien.
Es wäre doch einfach nur wünschenswert, daß wir diese beiden Patches koordinieren, so daß sie "gut miteinander können", oder daß wir sogar die beiden Features zusammen entwickeln. Ich hatte vor etwa einem Monat eine Diskussion in der ofiziellen ML gehabt, Klaus ist natürlich momentan nicht gewillt, sowas anzunehmen. Was weißt Du denn, wie steht's um UTF-8 und Freetype2, was für Chancen gibt's dafür?
Separat kann man die Patches natürlich benutzen, aber ich fände es eigentlich schade. Wir haben aber, glaube ich, ein großes Problem, wenn wir sie separat entwickeln (und das wird sich wohl 'ne Weile, zumindestens bis nach dem Weihnachtsurlaub nicht ändern können), nämlich immer wenn jemand beide anwenden will, muß erstmal vieles angepasst werden.
Was meinst Du zur ganzen Sache? Kannst Du Dir vorstellen, wir würden unsere beiden Patches in den nächsten Wochen (bei mir nur ab 2. Hälfte Januar) irgendwie koordinieren, so daß man sie dennoch beide benutzen kann (problem wie gesagt, beide verändern Sachen in i18n.c[h]), oder wir sehen sogar daß wir sie unter einem Hut bekommen, und somit Klaus ein rundes, durchdachtes Konzept präsentieren? In meinem Patch z.B. wandern die ganzen Phrases 'raus aus dem Code und werden über gettext (aber auch eine caching-version ist geplant) aus den externen Lokalisierungsdateien geladen, je nach Einstellung der Locale, die ich ja auch VDR-interne beim Sprachenwechsel verändere). Somit könnte man die nun externen Texte schon in UTF-8 vorliegen haben, dann würde das Konvertieren durch Deinen Patch nicht mehr notwendig sein, usw. Außerdem hat man so auch die Möglichkeit, nur die benötigten Likalisierungen zu installierren, und mein Patch trennt auch die Anzahl der OSD-Lokalisierung von der Anzahl der Content-Sprachen. Einen kleinen Teil meins Patches, nämlich die EEinstellung der Sprache nicht merhr als Zahl, sondern als string in setup.conf zu speichern, hat Klaus für einen 1.4er Version akzeptiert, alles andere hängt vielleicht auch davon ab, wie bequem es sich auf wirklichen UTF-8-Systemen benutzen lässt, oder keine Ahnung, wie man Klaus dazu bringen könnte, solche Sachen anzunehmen. Wie gesagt, wir müssen dann beide unseren Code gegenseitig reviewen und dann aushecken, wie wir's am Besten machen würden. Na, was meinst Du?

Schönen Gruß,
Lucian

In Version 1.5.x werde ich wohl oder übel UTF-8 akzeptieren müssen, und auch das mit den Texten in *.po Dateien wird wohl sinnvoll sein.

Aber eines ist absolute, 100%-ige Voraussetzung: es muß möglich sein, eine VDR-Version _komplett_ UTF-8-frei zu erzeugen - und damit meine ich, daß das gesamte UTF-8 Gedöns per "#ifdef USE_UFT8" (Name ist nur ein Beispiel) geklammert sein muß und es somit eine Version ohne jegliche UTF-8 "Verschmutzung" geben kann. Ich möchte nämlich auf meinen Systemen nicht die geringste Spur von UFT-8 haben.

Klaus

Danke trantor,

dann werd ich wohl auf UTF-8 umstellen können

Zitat

Cooler Patch, welche Chancen wird er wohl bei Klaus haben?

Das ist ne gute Frage

Viele Grüße
Boris

[EDIT ON]
Ups - da war Klaus schneller
[EDIT OFF]

Zitat

Original von kls
In Version 1.5.x werde ich wohl oder übel UTF-8 akzeptieren müssen, und auch das mit den Texten in *.po Dateien wird wohl sinnvoll sein.

Aber eines ist absolute, 100%-ige Voraussetzung: es muß möglich sein, eine VDR-Version _komplett_ UTF-8-frei zu erzeugen - und damit meine ich, daß das gesamte UTF-8 Gedöns per "#ifdef USE_UFT8" (Name ist nur ein Beispiel) geklammert sein muß und es somit eine Version ohne jegliche UTF-8 "Verschmutzung" geben kann. Ich möchte nämlich auf meinen Systemen nicht die geringste Spur von UFT-8 haben.

Klaus

Hallo Klaus

das alles klingt ja gar nicht mal so schlecht.
Müsste eigentlich auch so elegant machbar sein, daß diese *.po Dateien ohne UTF-8 sondern in den jeweiligen character sets so wie bisher gespeichert und gehandhabt werden, und bloß wenn UTF8 #defined ist, die Texte so wie derzeit in trantor's Patch konvertiert werden. Sinnvoll wäre es dann aber,glaube ich, nicht mehr die pure gettext-Variante wie es derzeit auf meinem VDR läuft, zu verwenden, sondern die installierten *.po Dateien (die ja bei der Installation ausgewähhlt, oder nachträglich hinzugefügt werden können, also die Anzahl der Sprachen ist bei mir nun dynamisch) beim Starten von VDR schon geparst, geladen und wenn UTF8, konvertiert werden, und nicht mehr über gettext eigentlich die *.mo Dateien bei jedem Aufruf von Translate angefasst werden.

Nun, ich denke es wäre sinnvoll, trantor und ich machen da zusammen etwas, weil wir ja beide schon funktionierenden Code haben. Zeit scheint ja noch bis 1.5 zu sein, oder?

Schönen Gruß,
Lucian

Zitat

Original von Zoolook
das alles klingt ja gar nicht mal so schlecht.
Müsste eigentlich auch so elegant machbar sein, daß diese *.po Dateien ohne UTF-8 sondern in den jeweiligen character sets so wie bisher gespeichert und gehandhabt werden, und bloß wenn UTF8 #defined ist, die Texte so wie derzeit in trantor's Patch konvertiert werden.

Die *.po-Dateien können meinetwegen machen, was sie wollen. Ich selber brauche nur die englische Variante (die ja eh' im Code drinsteckt und kein UTF-8 braucht) und die deutsche (die natürlich ISO8859 sein wird). Alles andere ist mir egal.

Zitat

Sinnvoll wäre es dann aber,glaube ich, nicht mehr die pure gettext-Variante wie es derzeit auf meinem VDR läuft, zu verwenden, sondern die installierten *.po Dateien (die ja bei der Installation ausgewähhlt, oder nachträglich hinzugefügt werden können, also die Anzahl der Sprachen ist bei mir nun dynamisch) beim Starten von VDR schon geparst, geladen und wenn UTF8, konvertiert werden, und nicht mehr über gettext eigentlich die *.mo Dateien bei jedem Aufruf von Translate angefasst werden.

Ich habe mich bisher mit den Einzelheiten, wie das am sinnvollsten zu machen ist, noch überhaupt nicht befaßt, und werde das vor der 1.5.x auch nicht tun

Zitat

Nun, ich denke es wäre sinnvoll, trantor und ich machen da zusammen etwas, weil wir ja beide schon funktionierenden Code haben. Zeit scheint ja noch bis 1.5 zu sein, oder?

Ich hoffe, das meiste, was ich noch für die 1.4 erledigen möchte, über Weihnachten machen zu können...

Klaus

Zitat

Original von kls
Ich hoffe, das meiste, was ich noch für die 1.4 erledigen möchte, über Weihnachten machen zu können...

Da scheint sich ja ein super Rutsch ins neue Jahr anzubahnen....

Viele Grüße
Boris

Hi,

ich hab den Patch mal eingespielt. Leider stürtzt vdr dann nach ein paar Sekunden ab. Ich hab mal gdb installiert und benutzt. Hier ist der Output:

vdr@section_eight /usr/local/src/vdr-1.3.37-utf8 $ gdb --args vdr -L /usr/local/src/VDR/PLUGINS/lib/ -c /usr/local/vdr/etc/ -v /data/vdr/  -s /usr/local/bin/vdrshutdown
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".


(gdb) run
Starting program: /usr/local/src/vdr-1.3.37-utf8/vdr -L /usr/local/src/VDR/PLUGINS/lib/ -c /usr/local/vdr/etc/ -v /data/vdr/ -s /usr/local/bin/vdrshutdown
[Thread debugging using libthread_db enabled]
[New Thread -1211127616 (LWP 5189)]
[New Thread -1212335184 (LWP 5196)]
[Thread -1212335184 (LWP 5196) exited]
[New Thread -1212335184 (LWP 5198)]
[New Thread -1220727888 (LWP 5199)]
[New Thread -1229120592 (LWP 5200)]


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1220727888 (LWP 5199)]
0x080e617e in cSdtFilter::Process (this=0x8221420, Pid=17, Tid=66 'B',
    Data=0x0, Length=410) at channels.h:154
154       const char *Charset(void) const { return charset; }
Current language:  auto; currently c++
(gdb)

So siehts aus wenn ich vdr ohne gdb starte:

vdr@section_eight /usr/local/src/VDR $ ./vdr -L /usr/local/src/VDR/PLUGINS/lib/ -c /usr/local/vdr/etc/ -v /data/vdr/  -s /usr/local/bin/vdrshutdown
Speicherzugriffsfehler

vdr ist nur mit deinem UTF-8 gepatcht. Meine Make.config sieht so aus:

INCLUDES += -I/usr/include/freetype2
CXXFLAGS += -fPIC


NO_KBD=1
REMOTE=LIRC

Kannst Du damit was anfangen?

Hi Trantor,

Zitat

Original von trantor
to Eichbaum:
UTF-8 patch braucht von i18n nur strings in utf8 oder auch z.B. utf-16 falls alle interne Strukturen werden auf wchar umgestellt. Wäre sehr klever. Bei meinem patch ist die konvertierung nur eine Notlösung um an unicode strings zu kommen.
mich interresiert eigentlich andere Sache: was willst du mit allen ~140 patches machen ? alle patchen?

*grübel*
Ich glaub da hast Du mich verwechselt...

Gruß
Boris

Zitat

Original von trantor
hast du was in syslog?
fonts installiert?

Jupps Fonts sind da (in /usr/local/vdr/etc).

Dec 16 08:25:40 section_eight vdr[27038]: VDR version 1.3.37 started
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//setup.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//sources.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//diseqc.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//channels.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//timers.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//svdrphosts.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//ca.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//remote.conf
Dec 16 08:25:40 section_eight vdr[27038]: loading /usr/local/vdr/etc//keymacros.conf
Dec 16 08:25:40 section_eight vdr[27038]: video directory scanner thread started (pid=27038, tid=-1213039696)
Dec 16 08:25:40 section_eight vdr[27038]: probing /dev/dvb/adapter0/frontend0
Dec 16 08:25:40 section_eight vdr[27038]: video directory scanner thread ended (pid=27038, tid=-1213039696)
Dec 16 08:25:42 section_eight vdr[27038]: found 1 video device
Dec 16 08:25:42 section_eight vdr[27038]: setting primary device to 1
Dec 16 08:25:42 section_eight vdr[27038]: tuner on device 1 thread started (pid=27038, tid=-1213039696)
Dec 16 08:25:42 section_eight vdr[27038]: section handler thread started (pid=27038, tid=-1221432400)
Dec 16 08:25:42 section_eight vdr[27038]: SVDRP listening on port 2001
Dec 16 08:25:42 section_eight vdr[27038]: loading /usr/local/vdr/etc//themes/sttng-default.theme
Dec 16 08:25:42 section_eight vdr[27038]: loading /usr/local/vdr/etc//themes/sttng-default.theme
Dec 16 08:25:42 section_eight lircd-0.8.0-CVS[5486]: accepted new client on /dev/lircd
Dec 16 08:25:42 section_eight vdr[27038]: remote control LIRC - keys known
Dec 16 08:25:42 section_eight vdr[27038]: switching to channel 27
Dec 16 08:25:42 section_eight vdr[27038]: info: Kanal nicht verfügbar!
Dec 16 08:25:42 section_eight vdr[27038]: LIRC remote control thread started (pid=27038, tid=-1229825104)
Dec 16 08:25:44 section_eight vdr[27038]: switching to channel 1
Dec 16 08:25:45 section_eight vdr[27038]: channel 10 (WDR Köln) event 07:30 'Planet Wissen' status 4
Dec 16 08:25:46 section_eight vdr[27038]: changing pids of channel 1 from 101+101:102=deu;103=deu:104 to 101+101:102=deu;106=deu:104
Dec 16 08:25:46 section_eight vdr[27038]: retuning due to modification of channel 1
Dec 16 08:25:46 section_eight vdr[27038]: switching to channel 1
Dec 16 08:25:46 section_eight vdr[27038]: channel 12 (hr-fernsehen) event 07:55 'Landesschau Baden-Württemberg' status 4
Dec 16 08:25:46 section_eight vdr[27038]: channel 16 (arte) event 02:41 'Sendepause' status 4
Dec 16 08:25:46 section_eight vdr[27038]: channel 1 (Das Erste) event 05:30 'Morgenmagazin' status 4
Dec 16 08:25:46 section_eight vdr[27038]: channel 11 (Bayerisches FS) event 06:00 'Sternstunden - Adventskalender' status 4
Dec 16 08:25:47 section_eight lircd-0.8.0-CVS[5486]: removed client

Anscheinend nichts auffälliges. Die channels.conf hatte ich schon per iconv nach utf8 konvertiert.

Ja. Alles neu. Plugins hab ich keine.

Das gleiche hatte ich auch. Da ich allerdings zig Patches eingespielt habe, konnte ich noch nicht testen, woran es liegt. Allerdings ist mir aufgefallen, dass nach Einspielen des Patches kein OSD zu sehen war, bevor sich vdr mit einem Speicherfehler verabschiedete. Es war aber schon der Channel gelockt.