Hallo Forum, ich stehe hier vor folgendem Problem: ich habe eine fertige Hardware mit Display und es soll jetzt zusätzlich möglich sein, länderspezifische Zeichen nachzuladen. Also beispielsweise eine Auswahl an Kanji oder ein Auswahl an chinesischen, koreanischen, ... Zeichen. Bislang funktioniert das so, dass ich für jede geforderte Schriftart kleine Bilder (1Bit/px) für jedes Zeichen generieren lasse. Diese werden dann zusammen gefasst und als Datei auf dem µC gespeichert. Das sind dann maximal 20kB pro Datei und passt locker in den vorhandenen Flash. Dabei verwende ich bislang ausschließlich UTF8 U+0000 bis U+00FF. Mit den internationalen Anforderungen von oben wird das jetzt schon schwieriger. Meine erste Idee war, das Rendering auf dem µC laufen zu lassen. Vom Code und der Performance sollte das passen. Jedoch sprengt die schiere Größe der ttf-Dateien meine Flash-Größe. Zweite Idee ist, dass ein PC-Programm im Kommunikationspfad den Datenstrom auswertet, das Zeichen rendert und dann kleine Bilder zum µC sendet. Die dritte Idee wäre, ein eigenes Format für die Fonts zu erstellen. Das bedingt aber auch neue Tools zum Erstellen und Verarbeiten. Jede Menge Arbeit also. Zuvor würde ich aber gerne wissen, ob es hier nicht eine fertige Lösung gibt. Wie macht ihr sowas? Gibt es ein Dateiformat, was eine Zwischen-Welt darstellen könnte zwischen ttf und bit-Font? Zur Info, ich habe etwa 1MB an Flash dafür zur Verfügung. Vielen Dank für Hinweise
Es geht um ein Grafikdisplay. Welche Fontgroesse moechtest du ? Falls nur eine oder zwei, wuerde sich anbieten, bitmaps fuer die Character zu speichern. 8x13 oder so.
Die lvgl Grafiklib hat ein gutes Fontsystem, auf deren Website ist ein Converter für TTF Fonts. Der Output sind C Files, nach dem Kompilieren sieht man ja wie groß die sind.
Purzel H. schrieb: > Es geht um ein Grafikdisplay. Ja, klar, was sonst. Purzel H. schrieb: > Falls nur eine oder zwei, wuerde sich anbieten, bitmaps fuer die Character zu speichern. 8x13 oder so. Ja, im Grunde mache ich das so, nur dynamisch für 1 bis viele und jeweils alle Zeichen. Dann in eine Datei zusammengefasst und zur Laufzeit nachladbar. J. S. schrieb: > Die lvgl Grafiklib Soweit ich verstanden habe, macht lvgl auch einfach nur zur Entwurfszeit aus einem ttf ein Byte-Array. Soweit bin ich auch. Bin ich der erste der sowas braucht?
Rangi J. schrieb: > Bin ich der erste der sowas braucht? Sicherlich nicht. Aber die Überlegung sollte sein, welche Texte genau Dein System darstellen muss, und somit den benötigten Glyphenvorrat zu minimieren. Denn für einen TTF-Renderer ist Dein System um gleich mehrere Größenordnungen zu klein. Sieh Dir mal an, wie groß ein typischer TrueType-Font ist - schon die 08/15-Schriftart Arial ist über 1 MByte groß. Bedenke bei Deinem Gerät auch, was die zu erwartenden Absatzmärkte sind, und schränke den benötigten Glyphenvorrat auch unter dieser Hinsicht ein. Zu guter Letzt: Konvertierungen von TrueType-Fonts in relativ niedrigauflösende Pixelmatritzen sehen in der Regel beschissen aus. Einfach, weil diese Fonts für Antialiasing oder Techniken wie ClearType (Subpixelantialiasing) gestaltet sind. Du müsstest, damit das Resultat erträglich aussieht, also Deine Glyphenbitmaps mit mehreren Bits pro Pixel organisieren, was noch mehr Speicher benötigt. Wenn Du Dir wirklich ernsthaft einen TrueType-Renderer ansehen willst: FreeType ist das Stichwort, nach dem Du suchst. Aber das ist etwas, was auf Computern der Raspberry-Pi-Klasse und größer läuft, nicht aber auf µCs mit nur ein paar MByte Speicher.
Wenn du weißt welche Zeichen du benötigst dann erzeuge doch einfach aus einem TTF deine 1bpp Bitmaps und leg dir ne Tabelle an mit einem Mapping Unicode -> bitmap. Hast du ja jetzt schon im Prinzip im Griff. Wenn du das nicht definieren kannst und theoretisch "alle" asiatischen Zeichen benötigst wird das mit 1MByte Flash wohl nichts werden. Eine TTF-Datei bringt dir nur was wenn du viele verschiedene Schriftgrößen brauchst. Bei ein oder zwei wirst du nix gewinnen. Du kannst natürlich auch deine Bitmaps in eine TTF packen und das Format weiterverwenden. Für die Datenaufbereitung ist dann evtl. https://github.com/fonttools/fonttools ganz nützlich.
Rangi J. schrieb: > Soweit ich verstanden habe, macht lvgl auch einfach nur zur Entwurfszeit > aus einem ttf ein Byte-Array. Ein Byte-Array ist am Ende jeder Font, auch dein originales Truetype-File kannst du als Byte-Array in dein Programm reinkompilieren. lv_font_conv rendert die verwendeten Zeichen in der gewünschten Auflösung, speichert sie als (ggfs. komprimiertes) Bitmap, und behält auch die Kerning-Informationen bei. Auch praktisch: Du kannst mehrere TTF/WOFF-Dateien zusammen in einen Ziel-Font packen, und aus jeder die Zeichen wählen die du brauchst, z.B. um ein paar Symbole aus FontAwesome mit reinzunehmen. https://github.com/lvgl/lv_font_conv https://fontawesome.com/search?s=regular&f=classic&o=r
Harald K. schrieb: > Wenn Du Dir wirklich ernsthaft einen TrueType-Renderer ansehen willst: > FreeType ist das Stichwort, nach dem Du suchst. Aber das ist etwas, was > auf Computern der Raspberry-Pi-Klasse und größer läuft, nicht aber auf > µCs mit nur ein paar MByte Speicher. Naja, du übertreibst. Eine für TTF hinreichend reduzierte freetype Bibliothek liegt bei ~200kB Codegröße. Ein Font mit lateinischen Schriftzeichen, Zahlen und ein paar Sonderzeichen um die 60kB. RAM brauchts natürlich auch noch bisschen aber auf einem µC mit 1MB Flash ist das durchaus machbar. Wenns aber asiatisch wird mit mehr als einem sehr reduzierten Subset wirds schwierig.
Angehängte Dateien:
Harald K. schrieb: > Denn für einen TTF-Renderer ist Dein System um gleich > mehrere Größenordnungen zu klein. ja, das schrieb ich schon ganz oben, bekannt. Harald K. schrieb: > Zu guter Letzt: Konvertierungen von TrueType-Fonts in relativ > niedrigauflösende Pixelmatritzen sehen in der Regel beschissen aus. reicht aus. siehe Beispielbild Μαtthias W. schrieb: > Wenn du weißt welche Zeichen du benötigst dann erzeuge doch einfach aus > einem TTF deine 1bpp Bitmaps und leg dir ne Tabelle an mit einem Mapping > Unicode -> bitmap. Hast du ja jetzt schon im Prinzip im Griff. Wenn du > das nicht definieren kannst und theoretisch "alle" asiatischen Zeichen > benötigst wird das mit 1MByte Flash wohl nichts werden. Nein, ich kann es leider nicht zur Entwurfszeit wissen, aber der Kunde muss es dann bei der Verwendung festlegen. Dafür benötigt der dann aber ein Tool zum Auswählen. Zudem ein Dateiformat zum speichern und transportieren. Und genau dafür suche ich Standards.
Wenn nur wenige Wörter angezeigt werden müssen, würde ich erwägen, sie als Bitmap zu speichern und (kleine) Fonts nur für Zahlen zu benutzen.
Rangi J. schrieb: > Harald K. schrieb: >> Denn für einen TTF-Renderer ist Dein System um gleich >> mehrere Größenordnungen zu klein. > ja, das schrieb ich schon ganz oben, bekannt. Ich schrieb ja. Ist es nicht. Mit etwas Aufwand sehe ich das durchaus machbar. Wieviel RAM hast du denn zur Verfügung? Was ist an Flash noch frei? Rangi J. schrieb: > Nein, ich kann es leider nicht zur Entwurfszeit wissen, aber der Kunde > muss es dann bei der Verwendung festlegen. Dafür benötigt der dann aber > ein Tool zum Auswählen. Zudem ein Dateiformat zum speichern und > transportieren. Und genau dafür suche ich Standards. TTF könnte tatsächlich eine Option sein. In TTF-Dateien lassen sich auch Bitmaps ablegen. Dann könnte man den Rendererteil aus der Freetype rauslassen und nochmal deutlich Flash sparen. Ich würde mal ein paar Versuche mit https://github.com/fonttools/fonttools und den Demos von freetype machen.
Rangi J. schrieb: > Mit den internationalen Anforderungen von oben wird das jetzt schon > schwieriger. Wieso ? Es scheint ja nicht nötig zu sein, dass dein uC jede Sprache darstellen kann, sondern nur die, die ausgewählt wurde. Statt fest eingebundenen Textstrings und Characterbitmaps könntest du auch nachladbare Textstrings und Characterbitmaps nutzen. Wenn die Schriftgrösse fest steht (z.B. 5*8 Pixel) ist ein fertig gerenderter Font sicher kleiner als ein TTF. Man kann sogar die Zeichen rauswerfen, die nicht benutzt werden, weil sie von keinem Textstring der Applikation zur Textdarstellung genutzt werden. Das macht PDF so wenn man Fonts embedded und kompakt sein will, das erlauben viele Fonts z.B. das GEM Format. Klar ist: wer ganz Unicode darstellen will, kommt mit 1MB nicht aus.
Moin, hab sowas vor jahren 2 mal machen düfen, einaml für ein französisches TV unternehmen, und einmal für einen drucker. war damals aber alles selber gestrickt, basis war FreeType, für das rastern. Das was da rausgefallen ist wurde dann noch mal händisch nachgearbeitet und dann in C code gegossen. Die glyphen ware da auch deutlich kleiner, bzw hatten besondere anforderungen. Internationaler TTF font von arial ist glaube ich an die 20MB gross, ... da ist dann aber auch so zeimlich alles drinnen was man sich so an zeichen vorstellen kann. Und ein A z.B ist dort nur 1 mal hinterlegt, auch wenn das als UNICode zeichen x mal benötigt wird, ... die arbeiten im ttf mit mapping tabellen zwischen zeichencode und glyph Du kannst ja mal hochrechnen wie viel flash du den brauchen würdest, wenn du alle relevanten zeichen mit einbaust, ... da kommt dann ne ganze menge zusammen. und bitte berücksichtigen, das Arial kein monospacing font ist, ... ein i ist schmäler als ein w, ... ggf greif in die trickkiste der alten dos game/demo entwickler, ... für einen monospacing font wurden da alle zeichen in ein bild gepackt. das wurde dann daraus einfach nur rauskopiert. das ging dann von mono bis farbig alles, je nach dem was das bild konnte. und bilder kann man ggf einfach komprimieren. z.B. gif png, ... wenn genug ram da ist. Ja das waren noch zeiten, ...
Rangi J. schrieb: > Zuvor würde ich aber gerne wissen, ob es hier nicht eine fertige Lösung > gibt. Die Chinesen lösen dieses Problem mit SPI-Font-ROMs, die ihre zahlreichen Zeichen als Bitmaps enthalten. https://datasheet.lcsc.com/lcsc/2004292104_SHOUDING-SD16S1Y_C521333.pdf https://www.buydisplay.com/download/manual/ER3300-1_Datasheet.pdf fchk
Lvgl hat auch Support um die Fonts zur Laufzeit nachzuladen: https://docs.lvgl.io/master/overview/font.html#load-a-font-at-run-time Und Fonts können bis 4 BPP haben und sehen dann mit Antialiasing sehr geschmeidig aus. Für aktuelle, schnelle Controller kein Problem. edit: Eine Font Engine für Realime Rendering kann man auch integrieren, flexibler geht es kaum, steht im übernächsten Absatz.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.