Siehe oben. Feste "drawtext"-Größe und innerhalb dieser rechtsbündiger Text.
Man kann das "size" nicht an die "area" hängen weil dort die Font-Einstellungen unbekannt sind.
Deshalb mein Gedanke das hier ein "text-align" fehlt um den Text im Bereich des "drawtext" rechtsbündig zu bekommen.
Ich denke M-Reimer und ich wollen eigentlich eine Art expectedchars Angabe und dazu ein textalignment fürs drawtext
textalignment greift dann im Zusammenhang mit expectedchars
Ist bei einem drawtext expectedchars auf 6 gesetzt, es ist aber nur 5 lang verhält es sich trotzdem so, als wäre es 6 Zeichen lang.
textalignment brächte man auch nicht, wenn man davon ausgeht, dass drawtext's mit expectedchars immer rechtsbündig ausrichtet. (INicht auf die area sondern auf das drawtext bezogen)
So klarer?
Was doch jetzt noch fehlt, ist einen Text bei Bedarf um eine bestimmte Anzahl Zeichen einzurücken, damit man eben z.B. Datumsangaben "schön" ausrichten kann...wenn der 7.11.2014 unter dem 13.11.2014 steht, soll die "7" ja genau unter der "3" stehen. Da würde ich dann indent="1" setzen...was das mit der Anzahl der Zeichen, also dem Vorgeschlagenen "size" Attribut zu tun hat, erschließt sich mir nicht so ganz. Oder ich verstehe die Problematik noch irgendwie falsch...
Um die Datumsangaben sauber untereinander zu bekommen wäre aber der "naheliegendere" Weg die Dinger rechtsbündig auszurichten innerhalb eines Feldes das soviele Zeichen wie nötig aufnehmen kann (hier 9 Zeichen). Ein Zeichen davorzustellen ist bei Proportionalschrift immer ein Kompromiss weil die Zeichen eben alle anders breit sind. Man bekommt hinten also mehr oder weniger einen Flattersatz.
Das ergibt aber auch keinen Sinn. Ein Datum besteht ja aus drei Segmenten. Wenn ich alle Punkte ordentlich untereinander haben wollte, würden mir EM auch nicht helfen.
Ich bin mittlerweile wieder der Ansicht, das eine andere Einheit uns gar nicht hilft.
"Punkte untereinander" geht mit mehreren "drawtext" hintereinander. Das erste Feld hat eine "Größe" von zwei Zeichen, das zweite ist fest der Punkt, das dritte hat wieder zwei Zeichen, dann noch ein Punkt und zuletzt ein Feld mit 4 Zeichen Breite.
Frag mich nicht ob man das in der Praxis auch sauber hintereinander bekommt 
Top sieht das dann aber auch nicht aus. Eben weil die Felder dennoch unterschiedlich breiten Inhalt haben. Ich halte "Punkte untereinander" auch für entbehrlich. Am saubersten sieht wohl rechtsbündig aus.
Ah ok...d.h. also wenn z.B. size="10" gesetzt ist, dann wird der Text quasi in eine Textbox innerhalb der Area gezeichnet, die 10 * BreiteNull (ergibt sich aus der definierten Font für den Text) breit ist. Die Textbox kann per x Attribut von drawtext positioniert werden, der Text selbst wird in der Textbox rechtsbündig ausgerichtet.
Passt das so? Am Beispiel einer Aufnahmeliste könnte das dann so ausschauen:
Mon 13.11.2014 Das ist die erste Aufnahme
Die 7.12.2014 Das ist die zweite AufnahmeFür die zweite Spalte wäre dann z.B. x="10%" und size="10". Dann müsste natürlich das Datum separat zur Verfügung stehen...wenn man Tag und Monat als Integer hat, wäre das doch immer noch ein ziemliches Gefummel oder?
Sorry wenn ich so nachbohre, aber wenn wir uns schon eine Lösung überlegen, soll die auch so viele Fälle wie möglich abfangen
Ciao Louis
Keine festen Spalten. Die sollen ja abhängig von der Fontbreiten platziert werden.
Für die zweite Spalte wäre dann z.B. x="10%" und size="10". Dann müsste natürlich das Datum separat zur Verfügung stehen...wenn man Tag und Monat als Integer hat, wäre das doch immer noch ein ziemliches Gefummel oder?
Wenn der Monat nicht zusätzlich mit führender Null verfügbar ist, dann wird das zum Gefummel. Da hast du Recht.
Wenn der Monat nicht zusätzlich mit führender Null verfügbar ist, dann wird das zum Gefummel. Da hast du Recht.
Wo ist das Problem. louis hat die conditions nicht ohne Grund in die xml Syntax eingebaut.
Keine festen Spalten. Die sollen ja abhängig von der Fontbreiten platziert werden.
Naja, ich denke halt an die Ausrichtung von Texten auf einem Menu Item. Da hat man doch irgendwo schon "feste Spalten"...so wird es in der "Default" VDR Ansicht bei den Listen ja auch gemacht...z.B. ist die standard Schedules Ausgabe (what's on, what's on now / next) ja z.B. auch aufgebaut. Mit dem "size" Attribut so wie vorgeschlagen könnte man dann eben eine rechtsbündige Anordnung einzelner Spalten erreichen. Das würde zwar auch mit mehreren Areas funktionieren, in denen man das drawtext dann jeweils mit align="right" positioniert, aber das wäre performancetechnisch nicht so dolle, weil die Anzahl der Areas pro Zeile sich ja mit der Anzahl der Menu Items multipliziert...und zu viele Areas (bzw. in der Realität Pixmaps) sollte man nicht benutzen.
Je mehr ich darüber nachdenke, desto sinnvoller erscheint mir dieses "size" Attribut oder wie es dann auch immer heissen soll
Ciao Louis
Ich will die Anordnung so, wie ich es im Elchi jetzt gemacht habe.
Erwartete Textbreite | halbe Höhe Abstand | Erwartete Textbreite | Halbe Höhe Abstand .......
Hi,
schick was hier passiert. 
Ich hoffe nur bei eurem Datum vergesst ihr den Monat nicht.
So sieht das auch nicht so doll aus:
1.12.2014
31.12.2014
1.1.2015
Dann lieber gleich:
01.12.2014
31.12.2014
01.01.2015
Tschüß Frank
Hi louis,
ich bin hier grade auf eine kleine Unklarheit gestoßen.
Im Prinzip geht es hier um den Teil unter "<!-- scraper poster -->"
Ich möchte gerne einen Rahmen (recback.png) um das Poster machen wenn eins vorhanden ist, aber so wie es aussieht liefert "condition="{hasposter}"" immer "true"
Oder hab ich da irgendwas verdaddelt?
vllt kannst du dir das mal ansehen:
log:
xml:
Und gleich noch eine Frage, du scheibst im Wiki:
ZitatUse only as many areas as needed! Especially in menu items you should not use too many areas, because the number is multiplied by the number of menu items displayed.
But: Texts and Images should never be placed on "background areas" which are filled with a color or a background image.
Demnach wäre das hier nicht so gut, oder?
Aber wie löst man das dann, hänge ich meine line_vert dann direkt irgendwo an <menuitems>?
Ich hoffe nur bei eurem Datum vergesst ihr den Monat nicht.
So sieht das auch nicht so doll aus:Code1.12.2014 31.12.2014 1.1.2015
Dann lieber gleich:Code01.12.2014 31.12.2014 01.01.2015
Datumsangaben ohne führende Nullen finde ich im Allgemeinen schon recht merkwürdig. 
Beim Tag kann man vielleicht ja noch drüber streiten, aber spätestens beim Monat hört es bei mir auf...
Lars.
Es ging mir auch eher um Zeitangaben. Die ganze Diskussion verstehe ich auch nicht. Es funktioniert doch.
Was aber wichtig wäre, dass pure Zahlen auch wirklich als Integer durchgereicht werden. Auch Tag und Monat.
{vps} sollte nur gesetzt werden, wenn auch wirklich eine VPS Zeit vorhanden ist.
Ist keine VPS-Zeit vorhanden wird im Moment "01.01. 01:00" eingetragen.
Hi Boostar,
Im Prinzip geht es hier um den Teil unter "<!-- scraper poster -->"
Ich möchte gerne einen Rahmen (recback.png) um das Poster machen wenn eins vorhanden ist, aber so wie es aussieht liefert "condition="{hasposter}"" immer "true"
das ist leider noch eine Unschönheit im scraper2vdr /tvscraper Plugin...wenn der Event erfolgreich gescrapt wird, dann wird auch davon ausgegangen, dass ein Poster vorhanden ist...das ist aber leider nicht immer der Fall. hasposter liefert also immer true zurück, wenn der Event erfolgreich gescrapt worden ist, unabhängig ob dann auch wirklich ein Poster da ist...wenn der Event aber nicht erfolgreich gescrapt wurde, sollte hasposter false zurückliefern, ansonsten wäre das ein Bug.
Ob ich das Problem im scraper2vdr Plugin fixe oder im skindesigner muss ich mir mal überlegen...aber es wäre prima, wenn du dazu ein Ticket auf vdrdeveloper.org (im skindesigner) aufmachen würdest.
Ciao Louis
Nochmal Hi Boostar
Aber wie löst man das dann, hänge ich meine line_vert dann direkt irgendwo an <menuitems>?
Hm, kommt drauf an was du genau erreichen willst...wenn du für den kompletten Bereich, in dem die menuitems gemalt werden sollen, einen Hintergrund definieren willst, sollte der in das allgemeine <background> des views. Wenn du allerdings für jedes menuitem einen dedizierten Background malen willst, und vielleicht auch noch beim aktiven menuitem einen anderen als für die inaktiven, dann musst du dir eine area in <menuitems> für den Background definieren. Im nOpacity skin mache ich das auch...solange das nur 2 bis max. 3 areas pro menuitem sind, sollte das auch nicht so schlimm sein, mit meinem Hinweis wollte ich nur vermeiden, dass jemand pro menuitem zig areas definiert...das geht dann irgendwann von der Performance her in die Knie.
Wenn dir das noch nicht reicht, musst du ein bisschen genauer beschreiben, was du vor hast
Ciao Louis
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
