VDR Portal

Quoted from "wastl"

grundsatzueberlegung: basteln wir hier nicht am falschen code herum?

Eigentlich ist das schon die richtige Stelle.

Quoted from "wastl"

entw. die utf8-streams kommen richtig daher oder es gibt so und anders im VDR-code wo einen bug.

Genau, ich habs bei mir mal etwas nachvollzogen, die falsch codierten Strings kahmen von epgsearch, deren config hatte ich noch nicht in utf-8 umgewandelt (bin neulich erst umgestiegen).

Also ich denke wir können einfach annehmen das alle Strings vom VDR correkt utf-8 codiert sind, und alle Strings vom Skin sowieso.

Quoted from "wastl"

die probleme entstehen ja in der aufbereitung (falscher einsprungspunkt in einen text-string). alles andere (auch deine jetzigen aenderungen im UTF8CodeAdjust) ist ja nur noch verschleierung eines problems, das zuvor nicht korrekt geloest worden ist.

Eigentlich löst es meine jetzige Version vollkommen korrekt. Es wird strikt utf-8 angenommen, und Einstiegspunkte innerhalb der Sequenz werden ignoriert. So soll es AFAIK auch sein (uft-8 ist ja extra so designt das man an beliebigen Punkten einspringen kann), und das funktioniert meiner Beobachtung nach auch.
Das einzige Problem ist noch das der darüberliegende Code nicht erwartet das auch mal kein Zeichen zurückkommt.

BTW: Ich habs das oben nochmal angepast, nicht lachen ich habe mich da jetzt mal mit max. Lesbarkeit ausgespielt Weil die ganzen Probleme (und ne menge Raterei) kamen eigentlich nur daher das die Funktion überhaupt nicht lesbar war. Und deswegen waren da schwer zu findene Fehler drin. Und ich wollte die Sache jetzt auch mal zuende ausarbeiten.
Ich teste das Ding jetzt noch mal gründlich durch, und dann solte das abgeharkt sein.


Nur der darüberliegende Code... Auf nen VDR der nicht auf uft-8 läuft sollten die Strings entsprechend dem aktuellen encoding nach utf-8 gewandelt werden (schon im Plugin). Und der Code der letztenlich die einzelnen Zeichen zeichnet sollte darauf angepasst werden das Stringlänge != Zeichenzahl im String ist (und dann ist das leidige Thema wohl endlich mal erledigt, zieht sich ja schon ewig durch den Bugtracker). Aber da blicke ich noch nicht so durch.

cu

Quoted from "wastl"

es ist und bleibt eine verschleierung eines zuvor eingefuehrten problems.

Eigentlich nicht, utf-8 ist ja nicht generell ein Problem Ist nur die Frage wie man damit umgeht.

Quoted from "wastl"

habe schon ein wenig herumgespielt mit korrektur des einsprungpunktes ('start') und dann gibt es auch keine probleme mehr mit fehlerhaftem utf8-zeug. (einfach solange 'start' verschieben, bis nicht mehr (c & 0xC0) == 0x80 ).

Das ist eine Möglichkeit. Aber das utf-8 Zeug ist ja nicht fehlerhat, es ist halt einfach so das nicht an jeder Indexposition des Strings ein gültiges Zeichen ist. AdjustCounter liefert dann halt <ungültiges Zeichen> als Zeichen zurück wenn man an so einer Stelle im String einsteigt.


Also IMHO sauberer (und Konsequent) wäre es wenn du den Rückgabewert (c) von Utf8CodeAdjustCounter auf UNICODE_NONCHARACTER (im Moment liefert er noch UNICODE_ZERO_WIDTH_NO-BREAK_SPACE damits keine Kästchen gibt, das muss man dann halt umstellen) prüfst anstatt selber auf (c & 0xC0) == 0x80 ) zu prüfen. Weil Utf8CodeAdjustCounter setzt dann i auch pracktischerweise aufs nächste gültige Zeichen (oder zumindest überspringt er die komplette angebrochene Sequenz).

Quoted from "wastl"

aja: das bisserl hex-rechnerei (von 0 - F kann ichs mir grad noch merken) sollte schon drin sein
da sollte man schon ohne defines auskommen ... (da wirds ja dann richtig langweilig)

Ich langeweile mich gerne mal Mit dem 0-F vertut man sich nämlich gerne mal. Also ich hät schon gerne das das so bleibt. Vor allem die Syslogausgabe ist hier wichtig, weil wenn dann mal jemand jammert das sein Display keine Umlaute anzeigt, dann sieht man gleich im Syslog welches Plugin da fehlerhafterweise kein uft-8 liefert. Nicht das dann die Raterei und das debugging wieder von vorne losgeht weil man dann zuerst Fehler im Code vermutet

Quoted from "wastl"

EDIT: ein problem, das du nicht bedacht hast bei deinen ueberlegungen utf8-skins vs. !utf8 vdr:
was passiert mit der VDRfont, wenn das dann auf einem !utf8-system ausgegeben werden soll? es wird nicht funktionieren ;-)

Wer hat den noch nen !utf-8 System Aber egal, dafür ist linux verantwortlich, eigentlich sollte für jedes utf-8 Zeichen ein passendes 8-Bit Zeichen ersatzweise gewählt werden (oder das "habe ich nicht" Zeichen). D.h. man kann auf nen !utf-8 linux auch wunderbar utf-8 liefern und low level wird das umgewandelt. Oder anderst ausgedrück, soll sich freetype2 damit rumschlagen.

Quoted from "wastl"

ausser man schmeisst saemtlichen !utf8-support aus graphlcd hinaus und arbeitet graphlcd-intern nur mit utf8 und wandelt alles, was von einem !utf8-vdr kommt, um.

Im Prinzip ist das ja die Idee. Ich glaube das ist die einzig brauchbare Möglichkeit

Quoted from "wastl"

aber dann muesste man auch die alten bitmap-fonts hinauswerfen (die koennen nur iso) ...

Ach ne bitte nicht, für kleine Schriften und Spielereien wie meine Uhr taugt True Type überhaupt nicht.

Aber das ist ja eigentlich überhaupt kein Problem, diese Fonts haben ja eh ein undefiniertes Encoding (als darf sich der mit dem finnischen VDR eh nicht wundern wenn da deutsche Umlaute kommen). Also bekommen die einfach von Unicode alle Zeichen von 0-255 (also definieren wir jetzt fnt als Basic Latain Charset mit VDRSymbol Extension), Und die anderen Zeichen bekommen ein '?' zugewiesen.
D.h. adjustcounter iefert c (Unicode), wenn c grösser als 255 und fnt Font dann c='?'. Und schon ist die Sache erschlagen.

Quoted from "wastl"

aber zugegeben: ich zerbreche mir da auch schon einige zeit den kopf, wie man das sauber (und mit wenig aufwand) am besten hinbekommt. zzt aergert mich halt, dass das utf8-zeug nur zeit kostet und anderes zeug aufhaelt ...

Ja, das nervt wirklich etwas. Aber deas Problem zieht sich ja schon ewig.

cu

Da kann ich mir jetzt aber nen hämischen Kommentar nicht verkneifen

Such den Fehler der wieder neu reinkam und gewinne die dann wieder funktionierenden 4 Byte Squenzen. Ich Vote weiterhin für die Lesbare Variante auch wenns uncool ist und die anderen C Programierer einen auslachen

BTW: Genau dewegen kann ich C nicht leiden

cu

0xE0 = 11100000
0xC0 = 11000000

Das if trifft niemals. Und wirklich JEDER der an diesen Codeblock war hatt so einen Fehler reinproduziert. Menschen sind halt nicht dafür gemacht sowas im Kopf zu machen und on the fly HEX zu denken.

Zugegeben, ich wollte nen Fehler finden (wegen weils dir mit den Konstanten zu einfach war) und hab gleich den Taschenrechner angeworfen

cu

Also bei mir siehts auch OK aus.

Was mir in diesem Zusammenhang schon immer aufgefallen ist, ist das er am Ende wieder abruppt "auf Anfang" springt, sieht irgendwie unruhig aus. Geht da evtl. noch was?

cu

Quoted from "wastl"

(relevant, wenn zb. UTF-8 fonts mit eigenen zeichen verwendet werden wollen, zb VDRSymbols - diese sind auf !UTF-8-systemen natuerlich nutzlos)

Habs nicht probiert, aber der VDRSymbols Font sollte auch auf !uft-8 Systemen funktionieren. Denn die Symbole liegen auch (zusätzlich zu den Unicode Positionen) im Bereich 128-255 (und die Plugins nutzen bei !utf-8 diese Zeichen), d.h. gehen die Umlaute auf nen !utf-8 System, dann gehen auch die Symbole. Nur bei pre TrueType VDRs (IIRC <= 1.5.7) müssen die Positionen im WarEagle Patch auf die aktuelle "Norm" angepasst werden (die Symbole lagen früher mal an anderen Positionen).

cu

Ist das git down?

Vorher gings auch nicht, aber gerade gings wieder.

cu

Quoted from "wastl"

frage: wozu soll das gut sein, in ein und demselben font dieselben speziellen VDR-zeichen mehrmals abzubilden? <sarcasm>ausfallssicherheit?</sarcasm>
noch dazu, wenn diese ohnedies in einem niedrigen unicode-block eingeblendet sind?

Naja, nen !utf-8 VDR (oder dessen Plugin) kann diese Zeichen ab 0xE000 ja überhaupt nicht erreichen. Aber sie ab 0xE000 abzulegen macht Sinn weil dieser Bereich ist ja genau für so einen Zweck reserviert (und da ist auch noch Platz für sehr viel mehr). Irgendwann (eigentlich besteht ja schon länger überhaupt kein Grund mehr auf utf-8 zu verzichten) kann man die ab Position 0x80 mal rauswerfen (dürfen da ja eigentlich garnicht sein) und dann ist alles Normgerecht.
Also eine typische Übergangslösung.

Quoted from "wastl"

aber egal, wenn jemand die abfrage auf system == UTF8 oder nicht benoetigt ist sie jetzt da ...

Genau, schadet ja nicht.

cu

Irgendwie ist da immer noch nen kleiner Bug. http://imageshack.us/clip/my-videos/695/zg0.mp4/

Ich hoffe du erkennst das auf dem Video (irgendwie ist der simLCD Treiber wieder kaputtgegangen deswegen siehts einwenig seltsam aus). Es geht um das reinragen des Hintergrundes ins Logo. Die Buchstaben fangen korrekt an, aber der Hintergrund nicht, wobei man den Hintergrung vermutlich auf Transparent setzen könnte, dann würde das hier vermutlich nicht stören.

BTW: Das mit dem sauberen durchscrollen sieht gleich viel besser aus. Sowas macht doch ne Menge aus.

cu