Kapitälchen-Font aussuchen

[MoonKid]

Bin kein Typograf und finde mich auch nur minimal im Fachbereich der Fonts zurecht.

Meine Frage bezieht sich daher mehr auf das generelle Vorgehen in so einem Fall und nicht (unbedingt) auf konkrete Vorschläge für Fonts.

Ich arbeite schon länger mit TeX (XeTeX). Aktuell entwerfe ich eine Vistenkarte für mich. Da brauche ich auch mal Kapitälchen ( \textsc{} ).

Die wenigsten Schriften unterstützen das einfach so. Da hilft es auch nicht, wenn man über 6000 Fonts im System installiert hat. Die unter Linux gängigen Font-Manager sind auch nicht sehr hilfreich, da sie (nach meinem bescheidenen Verständnis) nicht die Möglichkeit bieten eine Schrift nach diesem Kriterium ("Kapitälchen-F#higkeit" nenne ich das jetzt mal) zu suchen.

Ich kenne auch bereits das Kommandozeilen-Tool "fc-query" - werde aber aus deren Ausgabe nicht wirklich schlau bzw. sehe hier nie Hinweis auf Kapitälchen. Wobei es auch Schriften mit einem "SC" im Dateinamen im System gibt, die eben nur Kapitälchen können.

Es fällt mir schwer mich hier zurecht zu finden. Ist "Kapitälchen" eine Eigenschaft einer TrueType/OpenType-Font Datei, die sich daraus auslesen lässt? Wie sucht man eine Schrift mit dem Kriterium "Kapitälchen" (und in meinem Fall auch noch Serifen-los)?

Nebenfrage:

Auch bezogen auf die Suche, frage ich mich, wie man Schriften sucht, welche für bestimmte Unicode-Blöcke (z.B. "U3040" Hiragana, "U30A0" Katakana oder japanische Kanji) Zeichen anbieten.

Wie gesagt, bezieht sich meine Frage mehr auf die technischen Aspekte.

[Þorsten]

Ich gehe mal davon aus, dass du lokal verfügbare Fonts finden möchtest, die Kapitälchen per OpenType-Funktion erzeugen. Bei mir funktioniert folgendes:

find /usr/share/fonts/ /usr/local/share/fonts/ ~/.fonts/ -type f -name "*.?tf" | xargs otfinfo -f | grep smcp

Der wichtigste Teil ist hier das Kommando otfinfo -f, das die OpenType-Funktionen auflistet, die die übergebene Fontdatei anbietet. Und smcp ist halt die Funktion zur Erzeugung von Kapitälchen.

 

Und um nach von Fonts unterstützten Scripts (hier Hiragana) zu suchen, sowas wie

find /usr/share/fonts/ /usr/local/share/fonts/ ~/.fonts/  -type f -name "*.?tf" | xargs otfinfo -s | grep Hiragana

[Lars Kähler]

Ich weiß nicht, wie man mit XeTeX umgeht und auch nicht, was »smcp« macht, habe jedoch das dumme Gefühl, dass damit keine echten Kapitälchen erzeugt werden, sondern nur die Versalbuchstaben auf Mittellänge gebracht werden. Das ist Pfusch.

 

Du zäumst das Pferd vom falschen Ende her auf: Wenn Deine Anforderung, eine Visitenkarte mit Kapitälchen aus einer Serifenlosen zu setzen, lautet, dann muss ich mich schon noch ernsthaft fragen, ob Du überhaupt weißt, was Kapitälchen eigentlich sind und wofür sie gut sind.

 

Auf jeden Fall rate ich Dir dringend vom Einsatz sog. »falscher Kapitälchen« ab. Suche Dir lieber eine schöne Schrift mit echten Kapitälchen aus und setze dann damit Deine VKs.

 

Das geht übrigens wahrscheinlich alles sehr viel einfacher, wenn Du zu diesem Zweck so etwas wie Scribus oder auch nur TheGimp benutzt.

[catfonts]

 

... Und smcp ist halt die Funktion zur Erzeugung von Kapitälchen.

 

 

Ich weiß nicht, wie man mit XeTeX umgeht und auch nicht, was »smcp« macht, habe jedoch das dumme Gefühl, dass damit keine echten Kapitälchen erzeugt werden, sondern nur die Versalbuchstaben auf Mittellänge gebracht werden. Das ist Pfusch.

 

Nun, hier hat sich Þorsten ein wenig missverständlich ausgedrückt, und Du, lieber Lars hast daraus die falschen Schlüsse gezogen.

 

smcp ist ein OpenType-Table, indem, wenn diese im Font vorhanden sind, die ECHTEN Kapitälchen eingetragen sind, um bei Aktivierung des Features Kapitälchen dann auch an stelle der Gemeinen verwendet zu werden. Wenn also ein Font die Tabelle "smcp" (für Small Caps) enthält, kann man eben davon ausgehen, dass der Font auch tatsächlich echte Kapitälchen enthält, und diese eben nicht künstlich durch Skalierung der Versalbuchstaben auf x-höhe gebildet werden.

 

Und die von Þorsten präsentierte Linux - Suchzeile sucht eben Dateien anhand der Eigenschaften der Fonts, indem es diese auf das Vorhandensein der OpenType-Table "smcp" abklopft, und damit eben aus zig tausenden Schriftarten auf dem Rechner eben diese aussortiert, welche dann auch echte Kapitälchen beinhalten.

 

Vielleicht könnte ja mal wer hierfür ein grafisches Frontend programmieren, bei denen man dann die Auswahlkriterien, welche OpenType-Funktion der gesuchte Font haben soll, dann einfach durch anwählen von Checkboxen bestimmt werden kann?

 

 

Und The Gimp, also eine Pixelgrafik als Satzprogramm für Visitenkarten? Ist das wirklich dein Ernst?

[TobiW]

Ich weiß nicht, wie man mit XeTeX umgeht und auch nicht, was »smcp« macht, habe jedoch das dumme Gefühl, dass damit keine echten Kapitälchen erzeugt werden, sondern nur die Versalbuchstaben auf Mittellänge gebracht werden. Das ist Pfusch.

Wenn du nicht weißt, was TeX macht, solltest du auch nicht unterstellen Die TeX-Programme gehören zu den wenigen, die sich von Haus aus weigern falsche Kapitälchen zu verwenden und dies nur tun, wenn man sie ausdrücklich dazu zwingt. Fordert man auf dem normalen Wege Kapitälchen von einer Schrift, die diese nicht besitzt, gibt TeX eine Warnung aus und bleibt bei normalen gemeinen. Ebenso verhält es sich für Kursive, Fette und alle anderen möglichen Schnitte: TeX benutzt nur die Schnitte, die wirklich vorhanden sind. Alles andere ist möglich geschieht aber nur durch den Zwang und damit die bewusste (Fehl)Entscheidung des Anwenders.

 

Man kann darüber streiten, ob V-Karten nicht besser mit einer grafischen Oberfläche zu gestalten sind, aber es spricht nichts grundsätzlich dagegen, dies mit TeX zu machen. Zumal XeTeX eine der umfassenden Unterstützungen für alle OpenType-FUnktionen bietet. Wenn sich also der OP mit TeX wohl fühlt, ist es Unsinn, sich zu diesem Zwecke in ein anderes Program einzuarbeiten!

 

Der Fontexplorer für OS X hat übrigens eine Möglichkeit, Schriften nach solchen Features zu durchsuchen und daraus beispielsweise automatisch eine Liste zu generieren. Die Suchfunktion von MyFonts.com enthält ebenfalls einen entsprechenden Kriterienkatalog.

[StefanB]

Du zäumst das Pferd vom falschen Ende her auf: Wenn Deine Anforderung, eine Visitenkarte mit Kapitälchen aus einer Serifenlosen zu setzen, lautet, dann muss ich mich schon noch ernsthaft fragen, ob Du überhaupt weißt, was Kapitälchen eigentlich sind und wofür sie gut sind.

 

Ich muss mich schon ernsthaft fragen, was an serifenlosen Kapitälchen auf einer Visitenkarte so verkehrt sein soll‽

[MoonKid]

Ein bisschen von Typografie verstehe ich schon. Das wollte ich eigentlich damit ausdrücken, als ich anmerkte das ich TeX (insbesondere XeTeX) verwende. Da beschäftigt man sich zwangsläufig mit sowas. Daher ist es nicht nötig mit "unechten Kapitälchen" zu kommen.

Andererseits bin ich überrascht, das jemand hier im Forum TeX nicht kennt.

Tatsächlich habe ich derzeit auch den Gedanken eine eigenen Anwendung (open, Python, PostgreSql) zu entwickeln, welche die lokal vorhandenen Font-Dateien aufgrund ihrer Fähgikeiten und Eigenschaften durchsuchbar macht. Das ist etwas, was bisher noch keine Anwendung konnte, die ich gesehen habe - propritäre und plattform-dependend Anwendungen fallen da aber schon mal grundsätzlich raus. Aber eigentlich hab ich keine Lust auf so ein Projekt. ;)

otfinfo ist schon mal nice, deckt aber nur OpenType und TrueType ab - soweit ich verstehe.

PostScript-Zeug hab ich hier auch, aber sowas muss ich nun nicht unbedingt supporten. ;)

Hab hier aber auch die Schrift "Alegra Sans SC", welche (laut Verwendung in XeTeX) echte Kapitälchen kann. Die liegt hier in amf-, vf-, tfm-, pfb- und fd-Dateien vor. Was ist das?

Meine Suche darf sich offensichtlich nicht auf OpenType beschränken, den trotz über (laut FontMatrix) 6000 Font-Dateien im System, zeigt mir die scm-Suche nur 4 Schriften aus der gleichen Schriftfamilie an. ;)

Das mit dem Hiragana-Script überrascht mich auch. "Hiragana" steht wofür? Ist das genormt? Mir wäre es lieber, wenn ich konkret den Unicode-Block angeben könnte.

MyFont ist ein netter Ansatz. Man kann aber nicht nach freien Lizenzen suchen. Den Preis auf 0 runterzuschrauben macht einen Font noch lange nicht frei. In der Language-Suche taucht Japanisch nicht einmal auf.

Es muss doch Konventionen und Standards dafür geben, wie solche Informationen (SmallCaps, Unicode-Block, ...) in einer font-Datei abgebildet werden. Bin doch auch sicherlich nicht der Erste, der danach fragt. Kann daher auch nicht glauben, dass die Entwicklung einer entsprechenden Such-Anwendung notwendig ist, weil sie doch schon irgendwo existieren muss.

[Ralf Herrmann]

Es muss doch Konventionen und Standards dafür geben, wie solche Informationen (SmallCaps, Unicode-Block, ...) in einer font-Datei abgebildet werden.

 

Klar. Aber die Sache ist halt etwas komplizierter. Ob in OpenType-Fonts Kapitälchen sind, kannst du wie Thorsten schon angedeutet hat über die eindeutig benannten OpenType-Feature wie »SMCP« (Small Caps) und auch C2SC (Capitals to Small Caps) herausfinden. 

Wie du aber selbst schon sagst, sind Kapitälchen gar nicht unbedingt als OpenType-Feature abgelegt. Bei der »Alegreya Sans SC« sind die Kapitälchen zum Beispiel einfach in der Standardbelegung der Kleinbuchstaben. Das kann man technisch kaum automatisch erfassen. Der Namenszusatz »SC« ist jedoch ein guter Hinweis. 

Was Schriftsysteme und Unicodeblöcke angeht, ist es auch nicht viel besser. Man kann zwar technisch erfassen, ob Zeichen in bestimmten Blöcken liegen, aber das heißt ja noch lange nicht, dass dann eine bestimmte Sprache vollständig unterstützt ist. 

Professionelle Fonteditoren wie FontExplorer bieten aber durchaus eine Suche nach Sprachunterstützung. 

[catfonts]

Und wo du gerade über das ganze Postscript-Zeug geschrieben hast: Dieses heute schon fast obsolete Format, bei dem einige Programme schon aufhören, das zu untersützen ist im Zusammenhang mit der Suche nach Fonts muit einer bestimmten Unicode- oder Funktions-Suche eine Katastrophe, und das liegt einfach daran, dass es aus einer Zeit stammt, als "Hochleistungs-Workstations" noch nur einen Bruchteil der Leistung eines durchschnittlichen Billig-China-Smartphones hatten und eine Festplatte mit 40MB noch als groß galt, und man glaubte, die damals unterstüzte Obergrenze von 512MB würde noch recht lange ausreichen.

 

Hier war Dateigröße ein Thema, und drum hat man den Font eben auf mehrere Teildateien aufgesplittet,  um eben nur damit seine Festplatte vollstopfen zu müssen, was man davon wirklich brauchte.

 

Und so stecken dann in den Dateien *.PFB und *.PFA die eigentlichen Postscript-Beschreibungen der Glyphen als kubische Bezierkurven. In PFB als Binärcodierte, maschinenlesbare Form und in PFA  in für Menschen lesbarem ASCII-Postschript-text.

Lateinische Buchstaben sind dann schön brav im ANSI-Code gespeichert, fremde Schriftsysteme, wie z.B. Kyrillisch haben dann ihre eigene Codierung, wobei es hier sogar oft mehrere Varianten gibt, Schriftsysteme wie die Südost-Asiatischen müssen dann nauf mehrere Fonts aufgeteilt sein.

 

Möchte man eine Schriftfamilie erstellen, die auch Kapitälchen enthält, gibt es nur die Möglichkeit, einen kompletten zusätzlichen Font zu bauen, der die Kapitälchen dann an Stelle der Gemeinen hat. Hier muss man sich dann über eine Benennung des Fonts einigen, denn da gab es keine Norm, und für ein Suchprogramm sind das dann einfach nur x-beliebige Gemeine.

 

In den Dateien *.PFM bzw *.AFM stecken dann die Dicktenwerte der Glyphen und eventuell die Unterschgneidungstabelle. Auch hier wieder entweder im kompakten hexadezimalen Binärformat (PFB) oder im lesbaren ASCII-Format (AFM)

 

Mit jeweils einer der beiden Sorten hat eine Software alles, was sie braucht um damit Schrift darstellen zu können.

 

Hinzu kommt dann noch eine Textdatei, in der dann z.B. drin steht, dass der Font keine lateinische ANSI-Codierung, sondern beispielsweise Kyrillisch in 8859-5, CP1251, MacCyr oder KOI8 Codierung enthält, die sich extrem unterscheiden, diese trägt die Dateierweiterung *.INF - wird nur von Windows verwendet und ist eben auch nicht immer dabei.

 

So weit zum Postscript-Zeug.

 

Jetzt kommt das alte Truetype-Zeug, das schleppt nämlich auch Altlasten aus einer Zeit, in der Festplatten immerhin schon ein paar GB fassten mit sich. Hier sind dann wenigstens schon die *.PFB und *.PFM-Daten, sowie der inhalt der *.INF enthalten, wobei die Konturen dann im einfacheren quadratischen B-Splines, aber noch immer nur die Codes zwischen Hexadezimal 20 und FF, und alles, was kein ANSI-Code ist, muss da irgendwie rein gequetscht werden. Das bedeutet wieder, dass man denen von außen eben nicht ansehen kann, ob die Gemeinen gemeinerweise eigentlich Kapitälchen sind, oder, noch gemeiner, einfach noch einmal mit Versalien belegt wurden. Und sind die Codeplätze in so einem Font mi Hiragana (eine der japanischen Schriftarten neben Kanji und Katakana, wobei diese im japanischen Satz für jeweils verschiedene Satzelemente nebeneinander verwendet werden) und man schreibt in dieser Schrift einen normalen Text, sieht man japanisches Kauderwelsch, jedoch könnte ein Suchalgoritmus eben hier schon anhand der Metadaten im Font ermitteln, dass es sich eben um eine japanische Schrift handelt.

 

Schöner wird es dann mit den OpenType-Schriften, sowohl im Postscript- wie auch im Truetype-G'schäckle, also entweder mit den kubischen Bezier-Kurven oder den quadratischen B-Splines, wobei man das noch nicht einmal an der Dateikennung .OF oder .TTF erkennen kasnn. Mir sind schon reihenweise Schriften mit der eigentlich falschen Bezeichnung untergekommen, der anwendungssoftware ist das aber ohnehin egal.

 

Und hier gibt es dann auch wieder 2 Dinge, die bei einer solchen Schriftensuche nach Font-Eigenschaften wichtig sind, eigentlich sogar drei...

 

1. Die Unicode-Belegung: OpenType-Fonts untersützen ja den kompletten Unicode, und in den Font-Metadaten lassen sich eben Markierungen setzen, die angeben, aus welchen Unicode-Bereichen jetzt Glyphen vorhanden sind. Das Problem dabei: Ist auch nur EIN EINZIGES Zeichen, z.B. aus der ominösen Hiragans im Font enthalten, und ich als Font-Gestalter klicke im Font-Editor auf das automatische Erkennen der unterstützen "Supported Unicode ranges", dann wird der Haken auch bei Hiragana gesetzt. Und durchsuche ich jetzt meinen Font-Bestand nach Schriften mit Hiragana, wird die Schrifart auch ausgegeben, obwohl ich darin nur ein einzioges Schriftzeichen habe, dass ich vielleicht verwendet habe, um es als Logo zu nutzen.

 

2. Uncodierte Glyphen: In einer OpenType-Schriftart kann ich zusätzlkich beliebig viele Glyphen unterbringen, die keinen Unicode.Platz besitzen, z.B. Kapitälchen, Mediävalziffern, Tabellenziffern, Ligaturen, Logos und wer weiß was noch alles. Dieses wird dann über OpenType-Tables zugänglich gemacht, die entweger ständig aktiv sind, wie beispielsweise Standardligaturen, oder eben in der Anwendung hinzu- oder umgeschaltet werden müssen (wofür die Anwendung auch den betreffenden Schalter haben muss) um so beispielsweise Gemeine durch Kapitälchen zu ersetzen.

 

und das dritte: Nun, hier gibt es ja auch noch dieses Private Use Aera,  in dem alles mägliche drin sein kann...

[MoonKid]

Klingt irgendwie alles annährend unmöglich - ich meine meinen Plan.

Oder hälst du es technisch für machbar eine Such-Software zu entwickeln, welche Open- und TrueType Font-Files auf dem System nach Eigenschaften wie SmallCaps oder Unicode-Blöcken durchsuchbar macht?

 

Aber alleine schon solche stumpfsinnigen Dinge, wie den Alegreya-Font, der seine SmallCaps nur im Dateinamen auszeichnet, aber nicht als Parameter in den Metadaten speichert, rauben mir echt den Nerv. Was denkt sich ein Font-Entwickler dabei? (ernsthaft gefragt!) Dahinter muss doch irgendeine Design-Entscheidung oder ein technischer Grund stehen, wenn er einen Font in dutzende Dateien aufspatlet?

 

FontExplorer ist praktisch nicht existent für mich, da er nicht plattform-independent läuft. Hab hier ein unixoides System.

[Ralf Herrmann]

Aber alleine schon solche stumpfsinnigen Dinge, wie den Alegreya-Font, der seine SmallCaps nur im Dateinamen auszeichnet, aber nicht als Parameter in den Metadaten speichert, rauben mir echt den Nerv. Was denkt sich ein Font-Entwickler dabei? 

 

Das ist nicht »stumpfsinnig«, sondern eine Dienstleistung. Es gibt immer noch viel zu viele Anwendungen, die OpenType-Feature wie eben Kapitälchen gar nicht unterstützen. Ein spezieller Kapitälchen-Font macht somit die Nutzung dieser Zeichen überhaupt erst möglich. Man kann die Kapitälchen-Schrift dann wie jede andere Schrift direkt aus dem Schriftmenü wählen. 

[Wrzlprmft]

Klingt irgendwie alles annährend unmöglich - ich meine meinen Plan.

Oder hälst du es technisch für machbar eine Such-Software zu entwickeln, welche Open- und TrueType Font-Files auf dem System nach Eigenschaften wie SmallCaps oder Unicode-Blöcken durchsuchbar macht?

Eine kleine grafische Oberfläche für die entsprechenden oben erwähnten Unix-Tools zu entwickeln, sollte nicht so schwierig sein. Wenn Du schon immer mal programmieren lernen wolltest o. Ä. und genug Zeit hast, hast Du hier ein kleines nettes Projekt.

Eine Randbemerkung noch zu separaten Kapitälchen-Schriften: Fontspec ermöglicht es diese, mit SmallCapsFont=… einzubinden.

[catfonts]

Klingt irgendwie alles annährend unmöglich - ich meine meinen Plan.

Oder hälst du es technisch für machbar eine Such-Software zu entwickeln, welche Open- und TrueType Font-Files auf dem System nach Eigenschaften wie SmallCaps oder Unicode-Blöcken durchsuchbar macht?

 

Soll ich mal ehrlich sein? Nein! Schon gar nicht, wenn dies die Noch-nicht-Opentype-Truetypeschriften und eventuell sogar die Postscrip-Typ1-Schriftem umfassen soll. denn es gibt in den Fonts, außer im Fontnamen oder eben mit der entsprechenden OpenType-Funktion keine Möglichkeit, Kapitälchen oder andere typografische Besonderheiten zu markieren. Und wenn die Software sich die Formen der im Font vorhandenen Glyphen anschauen soll, und daraus enscheiden, ob der Font jetzt normale Gemeine oder an deren Stelle vielleicht Kapitälchen hat, dann würde das Programm seeeeeeeehr lange die Schriften durchsuchen, ohne Garantie, hier wirkliuch Treffer zu landen.

 

Aber alleine schon solche stumpfsinnigen Dinge, wie den Alegreya-Font, der seine SmallCaps nur im Dateinamen auszeichnet, aber nicht als Parameter in den Metadaten speichert, rauben mir echt den Nerv. Was denkt sich ein Font-Entwickler dabei? (ernsthaft gefragt!) Dahinter muss doch irgendeine Design-Entscheidung oder ein technischer Grund stehen, wenn er einen Font in dutzende Dateien aufspatlet?

Ernsthaft geantwortet: Vor OpenType hate der Schriften-Designer einfach gar keine andere Möglichkeit, er konnte gerade einmal 218 fest vorgegebene Zeichen in seinem Font untergringen. Und noch heute sind viele Programme im Einsatz, die selbst in einem fetten Opentype-Unicode-Font nur diesec 218 Zeichen verwenden können.

Besser wurde es dann mit der immer breiter werdenden Unicode-Unterstützung. Aber auch hier hat der Schriften-Designer keine Möglichkeit, das Vorhandensein von Kapitälchen, Mediävalziffern, Tabellenziffern, Ligaturen, Hoch- und Tiefgestellen Ziffern und was es sonst so an typografischen Gestaltvarianten gibt anwählbar im Font unterzubringen, ohne dazu auf OpenType-Funktionen, und die damit bedingte überschaubare Nutzerzahl - also praktisch nur die Gestalter-Profis mit Indesign & Co und die TeX-Gemeinde mit XeTeX und LuaTeX zu bedienen, das Gros der PC-Nutzer aber praktisch davon auszusperren.

Und letztlich fragt sich der Fontgestalter: Wie sag ichs meinem Kunden? Unicode-Abdeckung lässt sich, wie schon mal geschrieben, ja noch einigermaßen in den Font-Metadaten unterbringen, da gibt es gleich mehrere Orte, z.B. die Codepages, die vom Font abgedeckt sind, und eben die Unicode-Bereiche aus denen Glyphen im Font enthalten sind - was dann aber noch nich sagt, dass ich dann auch in der, oder gar allen Sprachen auch schreiben kann, die diesen Unicode-Block verwenden. Habe ich nur ein µ und ein Ω im Font, um beispielsweise Stücklisten füre elektronische Schaltungen damit screiben zu können, sagt mit die Unicode-Abdeckung schon, dass da der Block Griechisch von Font verwendet wurde.

Sobald es aber um Design-Spielereien geht, ist schluss mit Lustig, da gibt es kein standartisiertes Feld in den Metadaten des Fonts, wo ich das z.B. ankreuzen kann. Es gibt da zwar ein Feld für freien Text, aber da kann praktisch jeder Font-Designer reinschreiben, was er möchte. Und schriebe ich dort hinein: "Ich plane auch noch in einer späteren Version Kapitälchen" und edeine Software sucht nur nach diesem Begriff, würde mein Font fälschliuch ausgegeben.

 

Also prügel hier nicht auf die falschen ein, wir sizen nämlich im selben Boot, mit dem gleichen Dilemma.

[Þorsten]

Ob so etwas für Anwender wirklich sinnvoll wäre, lasse ich mal dahin gestellt, aber technisch lässt sich solche eine Aufgabe sicher schon lösen. Ich könnte mir das gut als Projekt in einem Informatikkurs vorstellen, in dem es um Bilderkennung geht. Die Lösung könnte etwa so aussehen:

1. Für einen gegebenen Font, erzeuge Bilder von Groß- und Kleinbuchstabenpaaren, deren Skelette sich stark unterscheiden (z.B. A/a, G/g).
2. Wende einen Kontur-Erkennungs-Algorithmus auf die Buchstabenpaare an. Beträgt die Übereinstimmung > x, hast du einen Kapitälchenfont, bei dem die Kapitälchen auf den normalen Kleinbuchstabenpositionen liegen.
3. Experimentiere, bis du einen Wert für x gefunden hast, der Kapitälchen- von anderen Fonts mit einer Zuverlässigkeit von p unterscheidet.

↑ Alegreya Sans   —   ↓ Alegreya Sans SC … jeweils auf identische Zeichenhöhe skaliert

P.S. Es sollte trivial sein, eine Lösung abzuleiten, die die Frage beantwortet, ob bestimmte Zeichen vorhanden sind oder nicht.

[catfonts]

das könnte aber dazu führen, dass dann kyrillische Fonts als Kapitälchen ausgegeben werden

[Þorsten]

Ne. Man vergleicht ja nicht wahllos Zeichen, sondern nur genau definierte, also z.B. eben U+0041 mit U+0061 und U+0047 mit U+0067, halt die lateinischen Buchstaben A, a, G, g.

[MoonKid]

Das ist nicht »stumpfsinnig«, sondern eine Dienstleistung. Es gibt immer noch viel zu viele Anwendungen, die OpenType-Feature wie eben Kapitälchen gar nicht unterstützen.

Ah, jetzt verstehe ich die Zielsetzung dahinter.

Der Font-Designer versucht also die Schwächer anderer Software auszugleichen.

Das wiederum fördert jedoch diese Schwäche, so dass der Entwickler der nicht-vollständig-OpenType-umsetzenden Software nicht gezwungen ist, hier mal was zu unternehmen.

Aber das führt zu weit vom Thema weg und wir beide haben damit auch auch direkt gar nix zu tun. Aber deine Erklärung hilft mir schon mal sehr beim Verständnis des Großen und Ganzen - was ja auch der Zweck meines Ur-Postings hier war.

[MoonKid]

Eine kleine grafische Oberfläche für die entsprechenden oben erwähnten Unix-Tools zu entwickeln, sollte nicht so schwierig sein. Wenn Du schon immer mal programmieren lernen wolltest o. Ä. und genug Zeit hast, hast Du hier ein kleines nettes Projekt.

Eine Randbemerkung noch zu separaten Kapitälchen-Schriften: Fontspec ermöglicht es diese, mit SmallCapsFont=… einzubinden.

Du scheinst interessante Vorannahmen über die Fähigkeiten meiner Person zu treffen. ;)

Ich bin kein TeX-Profi, aber nutze es als Anwender sehr intensiv. Und ich bin SW-Entwickler.

Sicher muss ich lernen, meine Fragen konkreter zu stellen. ;)

Der Thread dient für mich dazu, das Thema der Meta-Informationen in den einzelnen Font-Dateitypen besser zu verstehen, um davon wiederum abhängig zu machen, ob eine entsprechende (wie von mir beschriebenen) SW überhaupt realisierbar ist.

Bisher zeigt sich für mich, dass dem nicht so einfach ist. Es gibt z.B. keinen verlässlichen Schalter für SmallCaps in den MetaInformationen. Es steckt teilweise auch einfach im Dateinamen (z.B. bei Alegreya). Unicode-Blöcke und Sprachen sind auch ein Problem, wie hier gezeigt wurde.

Offensichtlch ist auch OpenType ein Standard mich deutlichen Schwächen - wenn man meine Use Cases als Maßstab nehmen würde. Gleichzeitig wird der Standard nicht vollständig implementiert auf beiden Seiten - Anwendungssoftware und Font-Designer.

"Dilema" tifft es gut.

Vielleicht arbeite ich erstmal an einer eigenen Script-Lösung, um das in der Praxis zu "fühlen". Ein Front-End lässt sich später immer noch basteln.

[MoonKid]

Also prügel hier nicht auf die falschen ein, wir sizen nämlich im selben Boot, mit dem gleichen Dilemma.

Tut mir aufrichtig Leid, falls hier jemand sich angegriffen fühlte! War nicht meine Absicht.

Mal an die Profis gefragt: Wie sucht ihr einen SmallCaps Font, wenn ihr ihn braucht?

Ihr habt irgendein Projekt oder Auftrag und da muss jetzt so ein Font her. Ihr führt a.G. eurer Arbeit und Erfahrung eine eigenen Liste? Ihr erinnert euch einfach daran, dass da mal einer war? Oder probiert einfach Stundenlang durch - so wie ich derzeit?

[Phoibos]

Ein guter Anfang: https://www.myfonts.com/search/small+caps/fonts/ Ansonsten kenne ich meine 12-20 Pappenheimer bezüglich ihres Ausbaues.

[Lars Kähler]

@ MoonKid: Du bist hier in einem Forum über Typografie. Warum fragst Du uns nicht einfach einmal nach einer konkreten Empfehlung unsererseits für – ja, was eigentlich?

 

Eine Visitenkarte? Und zwar mit einer Schrift mit echten Kapitälchen, trotzdem serifenlos und wahrscheinlich für lau zu haben, nicht wahr? Habe ich das soweit richtig verstanden?

 

Warum denn unbedingt Kapitälchen auf einer VK? Was willst Du denn damit ausdrücken? Und wieso geht da eigentlich was genau nicht mit Deinem XeTeX? – Weißt Du, wenn Du diese »Lösung« hier schon anbietest wie sauer Bier, in einem Forum, wo jede Menge leute sitzen, die jeden Tag ihr Geld mit brauchbaren Anwendungen verbringen, dann sag’ uns doch auch einmal möglichst präzise, was genau Dir an der immerhin sowieso Open Source seienden Schrift »Alegreya Sans SC« nicht gefällt.

 

Wie hoch ist denn unser Etat? Was bist Du bereit, für eine Schrift auszugeben?

[Martin Z. Schröder]

Mal die Profis gefragt: Wie sucht ihr einen SmallCaps Font, wenn ihr ihn braucht?

Ihr habt irgendein Projekt oder Auftrag und da muss jetzt so ein Font her. Ihr führt a.G. eurer Arbeit und Erfahrung eine eigenen Liste? Ihr erinnert euch einfach daran, dass da mal einer war? Oder probiert einfach Stundenlang durch - so wie ich derzeit?

(Bitte, was heißt a.g.?)

 

Ansonsten kenne ich meine 12-20 Pappenheimer bezüglich ihres Ausbaues.

Schriften sind für den Typografen alltägliche Werkzeuge. Wenn ich es mit neuen Schriften zu tun bekomme, schaue ich mir immer den Umfang an. Wieviele Schnitte hat sie, welche Ziffern sind verfügbar, sind Kapitälchen enthalten. Diese verwende ich auch oft nicht als Kapitälchen, sondern als etwas kräftigere Versalien. Daß man eine Schrift danach sucht, ob sie Kapitälchen hat, kommt, glaube ich, gar nicht vor. Angenommen, man braucht eine Serifenlose, dann hat man den Umfang der vielleicht zehn (bei andern sind es sicherlich mehr, ich arbeite eher mit wenigen Schriften) Serifenlosen vom eigenen Fundus im Kopf oder hat eine Idee für eine Alternative. Dieses Gedächtnis wird mit den Jahren größer.

[Phoibos]

(Bitte, was heißt a.g.?)

Ich hab mal auf Grund interpoliert.

[Lars Kähler]

@ MoonKid: Was ist denn nun mit der VK? Zeig’ Sie uns doch mal!