Forum: Mikrocontroller und Digitale Elektronik Internationale Schriftarten Fonts auf Display eines µC darstellen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rangi J. (rangi)


Lesenswert?

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

von Purzel H. (hacky)


Lesenswert?

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.

von J. S. (jojos)


Lesenswert?

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.

von Rangi J. (rangi)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von Εrnst B. (ernst)


Lesenswert?

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

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von Rangi J. (rangi)


Angehängte Dateien:

Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

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.

von Michael B. (laberkopp)


Lesenswert?

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.

von Michael G. (michael_g968)


Lesenswert?

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, ...

von Frank K. (fchk)


Lesenswert?

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

von J. S. (jojos)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.