skindesigner: "font [...] not available, skipping" (möglicher VDR Core)

  • In vdr4arch wird momentan VDROpen Sans durch Open Sans mittels 99-skindesigner.conf ersetzt (bzw. als alias konfiguriert). Das eigentliche Ersetzen im Skin klappt auch, allerdings meckert skindesigner beim Cachen (cFontManager::CacheFonts), dass es die VDROpen Sans Fonts nicht gäbe (nachfolgende Ausgabe kommt 288 mal):

    Code
    "skindesigner: font VDROpen Sans Light:Light not available, skipping"


    Fc-match funktioniert allerdings wie erwartet.

    Code
    $ fc-match 'VDROpen Sans Light:Light'
    OpenSans-Light.ttf: "Open Sans" "Light"


    Soweit ich das sehe benutzt skindesigner hierbei auch nur die Core Funktionalität vom vdr, in dem Fall cFont::GetAvailableFontNames(). Auch bei folgendem Aufruf wird VDROpen Sans nicht angezeigt. Es scheint mir, als würde FcFontList() aus fontconfig die aliase nicht auflösen.


    Wie kann man das am besten lösen? Wenn das eher nach VDR Core passt, bitte verschieben.

  • fc-list |grep VDROpen

    Der Befehl findet nix, da ja nur OpenSans* installiert ist. Es wurde ja aber konfiguriert, um als Ersatz zu dienen.


  • Code
    $ grep -Ri vdropen /var/lib/vdr/plugins/skindesigner/installerskins/shady/
    /var/lib/vdr/plugins/skindesigner/installerskins/shady/globals.xml:		<font name="light">VDROpen Sans Light:Light</font>
    /var/lib/vdr/plugins/skindesigner/installerskins/shady/globals.xml:        <font name="semibold">VDROpen Sans Semibold:Semibold</font>
    /var/lib/vdr/plugins/skindesigner/installerskins/shady/README:	b. Font: VDROpen Sans, many other fonts are to fat and don't fit in some areas!


    So ist es. Die Idee war aber shady nicht jedes mal anpassen zu müssen, wenn man es über das Menü aktualisiert. Deshalb eben die 99-skindesigner.conf, um Open Sans als alias für VDROpen Sans zu konfigurieren. Die Schrift wird ja auch richtig ersetzt. Dennoch meckert Skindesigner am Start rum.

  • "VDR OpenSans" ist ein unnötigerweise umgebasteltes "OpenSans". Warum sollte man also nicht das "Original" einsetzen können?


    Meiner Meinung nach ist das Verhalten vom Skindesigner hier nicht korrekt.


    Auch bei Webseiten kann der Webdesigner irgendwas vorgeben. Also irgendeinen Font. Der Browser findet dann schon etwas passendes.


    Ähnlich sehe ich das mit den Aliasen. Der Alias hat gegriffen. Der korrekte Font ist geladen. Die Meldungen vom Skindesigner sind hier unnötig, bzw. sollten maximal einmal und nicht hunderte Mal auftauchen.

  • Eine einfache Liste von schon mal angemeckerten Fontnamen im skindesigner anlegen und jeden dann nur einmal protokollieren sollte nicht so schwer sein. Dafür muss jemand nur ein Ticket anlegen.


    Lars

  • Was spricht denn dagegen, einfach die global.xml anzupassen, oder einfach VDROpen Sans zu installieren? ?(


    Ein möglicher merge conflict bei einem zukünftigen Update und weil es für sowas eben genau diesen Mechanismus mit Aliasen gibt.


    Lars

  • Moin,


    ich werde einfach die VDR Sans im metrixhd im nächsten Release gegen die Sans tauschen...dann ist der blöde Patch nicht mehr nötog ;)


    Ciao Louis

  • fc-match ist nicht besonders groß. Ich hab es testweise auf ca. 40 Zeilen zusammen gekürzt. Allerdings matched es immer, sprich auch wenn man gar keinen Fontnamen übergibt (dann vermutlich auf die Standardschrift).

    Code
    $ fc-match
    DejaVuSans.ttf: "DejaVu Sans" "Book"


    Oder einfach aus dem esyslog ein dsyslog machen, dann seh ich es zumindest nicht mehr. :)

  • Unabhängig von einer Lösung mit fc-match oder was auch immer, könnte man trotzdem eine Schriftart nur einmal melden. 100 gleiche Fehlermeldungen machen es nicht besser. :)


    Lars

  • "VDR OpenSans" ist ein unnötigerweise umgebasteltes "OpenSans". Warum sollte man also nicht das "Original" einsetzen können?

    ...s. Bild...aber ich hätte auch kein Problem damit, mich Louis anzuschließen und auch bei meinen Skins den Font für den 'allgemeinen Gebrauch' zu ändern.

  • Die Sondersymbole sollten in Skindesigner-Skins nicht mehr nötig sein! Genau dafür habe ich mir die Mühe gemacht SVG einzubauen. Um diesen Hack mit verbastelten Fonts im VDR-Bereich endlich obsolete zu machen!

  • Moin,


    ich hab mir das eben nochmal angesehen...im Prinzip würde es genügen, die Abfrage hier komplett rauszuschmeissen, die ist eigentlich unnötig. Muss ich mir aber nochmal anschauen, ob das nicht irgendwelche Seiteneffekte hat.


    Ist es eigentlich Absicht, dass in dem fontconfig file von vdr4arch am Ende die schließende > fehlt?


    Ciao Louis

  • Die Sondersymbole sollten in Skindesigner-Skins nicht mehr nötig sein! Genau dafür habe ich mir die Mühe gemacht SVG einzubauen. Um diesen Hack mit verbastelten Fonts im VDR-Bereich endlich obsolete zu machen!

    Ich sehe da eigentlich ähnlich. Sollte sich das aber doch als allzu großes Problem herausstellen, paketiere ich einfach den Font mit und gut ist.


    Ich dachte das wäre mit OpenSans eine schöne Lösung.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!