Small Caps in OT?

[Lecter]

Moin,

ich plane einer Schrift Small Caps hinzuzufügen und mich interessiert wie da die gängige Vorgehensweise ist. Macht es Sinn einen seperaten Schriftschnitt zu ergänzen oder lege ich einfach ein OT feature (mir schwebt da „smcp – Small Capitals“ vor) an?

Jemand eine Meinung? :)

Gruß

[Sebastian Nagel]

Eigener Schriftschnitt: geht natürlich, ist aber eher veraltet. Vorteile: unkompliziert zu erstellen; Nachteile: Mehrgleisigkeit für alle nicht-betroffenen Zeichen

Opentype: etwas komplizierter, dafür direkt in den Font integriert statt eine "Kopie".

Sollen die Smallcaps in Office-Anwendungen nutzbar sein? --> eigener Schriftschnitt ist die einfachste Lösung, zumindest brauchen die Kapitälchen aber einen Codepoint aus der Private Use Area damit sie in Word & Co ansprechbar sind (Nachteil: Codierung stimmt nicht mit Bedeutung überein, ein Smallcaps-A ist der Tabelle nach kein A oder a, sondern ein Sonderzeichen. Kriegen sie keinen Codepoint zugewiesen, sind sie nur in Opentype-fähigen Programmen erreichbar.

Wenn Opentype: Du brauchst die Features SMCP (Smallcaps) und C2SC (Capitals to Smallcaps). SMCP ersetzt alle Kleinbuchstaben durch Kapitälchen, lässt aber die Versalien stehen. C2SC ersetzt die Versalien durch Kapitälchen, lässt aber die Minuskeln in Ruhe. Indesign verwndet in der Einstellung "Kapitälchen" das SMCP-Feature, in der Einstellung "alles Kapitälchen" die Features SMCP und C2SC kombiniert.

Brauchst du Smallcaps-Satzzeichen wie Rufezeichen, Fragezeichen oder & ? Wie sieht es mit Ziffern aus?

[Lecter]

Ok. Verstehe.

Ich würde auch mehr zu OT tendieren, das blöde ist bloß, daß man einen neuen Kerning-Text hinterlegen muß weil die Zeichen ja nicht mehr "a" sondern k.a. vielleicht "a.Caps" heissen. Oder kann man die OT-Features im Kerning-Dialog (ach so: Fontlab.) aktivieren?

Office-Anwendungen sind nicht das Ziel.

Guter Tipp mit dem "C2SC".

Über Rufezeichen, Fragezeichen, Ziffern etc. hab ich mir ehrlich gesagt noch keine gedanken gemacht. Unter welches feature würden die dann fallen? SMCP oder C2SC oder gar ein anderes?

Danke soweit schon mal. :)

[Sebastian Nagel]

OT-Features in Fontlab-Metrikfenstern aktivieren: nicht dass ich wüsste (wäre praktisch, aber programmtechnisch nicht ganz einfach bereitzustellen... vielleicht ja in Fontlab 6?).

Aber: Du kannst im Metrikfenster den markierten Buchstaben mit STRG+Mausrad (am Mac eventuell Command+Mausrad?) "weiterblättern", d.h. wenn du A.sc siehst und markiert hast, und dann weiterblätterst, kommst du zu B.sc, ohne das eintippen zu müssen. Wenn du tippen musst, kommt dir zuhilfe, dass du wahrscheinlich den gewünschten Buchstaben schon angezeigt bekommst, wenn du nur "A." eingetippt hast (vorausgesetzt du hast noch nicht weitere Varianten eingebaut, wie, "A.ti", "A.sw" usw.). Ich bin inzwischen beim Kerning von Smallcaps praktisch gleich schnell wie bei "normalen" Alphabeten, getippt wird eigentlich gar nicht mehr, ich habe meine "Kontext-Zeichen" außen, und die betroffene Kombination wird nur noch per Mausrad weitergeblättert (wenn jetzt noch jemand einen Tipp hat wie ich statt der Maus eine Tastaturtaste dafür verwenden kann: her damit, dann bin ich noch schneller).

Die Smallcaps solltest du "A.sc" nennen, das ist offenbar gängige Praxis und kurz genug zum schnellen Tippen falls notwendig.

Rufezeichen, Fragezeichen, ... Ist sicher ein Streitpunkt, in welches Feature das gehört. Nachdem im gemischten Satz Versalien sowieso aus dem Textband hervorstehen, speziell natürlich im Deutschen, können das auch Fragezeichen und Rufezeichen tun. Somit würde ich die eher ins C2SC-Feature packen. Gut möglich dass ich das nächste Woche wieder ganz anders sehe

Hast du spezielle Kapitälchenziffern, können ggf. auch Kapitälchen-Währungszeichen notwendig werden, nimmst du hingegen die Minuskelziffern für Kapitälchen, können meiner Meinung nach auch die normal-hohen stehenbleiben.

Aber: übertreib's nicht mit diesen Sonderzeichen, im Kapitälchensatz sind diese Dinge dermaßen selten, dass man sich echt fragen muss ob der Aufwand und die zusätzliche Komplexität lohnt – hängt von der Schrift und deren Einsatzzweck ab.

[Lecter]

Ist aber mal ein Muss für die Version 6. Obwohl ich mir in diversen Apps seit Jahren ungehört simple Features wünsche... ;)

Ich bin ehrlich gesagt kein Freund von Paar-Kerning sondern habe lieber einen Satz bzw. ein Wort drumrum. Muß vielleicht mal an meinen Kerning Text mit Suchen/Ersetzen ran.

Oh, du kannst im Metrix- so wie im Glyph-Fenster mit "," und "." vor und zurück navigieren. Die Mouserad-Varinate war mir neu aber ich benutze relativ selten die Mouse und versuche das gern über Tastenkürzel zu erschlagen.

Habs automatisch "a.SC" genannt, vielleicht sollte ich nochmal die Groß-/Kleinschreibung überdenken. ;)

Oh ja ich hab schon gemerkt, daß die Sonderzeichen "ä", "á" etc. schon einen ziemlichen Rattenschwanz nach sich ziehen. :/ Der Aufwand lohnt sich wahrscheinlich nicht, aber es wär halt ganz cool, wenn man mal weiß wie’s funktioniert, und es trotzdem implementiert, auch wenns dann niemand nutzt.

Wieder was gelernt. :) Thnx for Support.

[Sebastian Nagel]

Paarkerning: ich mach es meistens mit solchen Testketten:

minimumaaminomon

minimumabminomon

minimumacminomon

...

D.h. ich schaue dass ich über die Metrik ein perfektes Bild für "einfache" gerade Zeichenkombinationen hinkriege (minimum), kerne dann ggf. noch die Kombination von runden und geraden Zeichen (nnnonnnnoonnnnn) falls nötig, und nehme das dann als Umgebung und Vergleichsmöglichkeit für alle anderen Kombinationen, die ich in die Mitte stelle (aa, ab, ac, ad ...) und durchackere. Ich hab's auch aufgegeben lange zu überlegen welche Kombinationen denn nun "gebraucht" werden und welche nicht, ich stoße bei fremdsprachigen Testtexten immer wieder auf Kombinationen von denen ich dachte dass die niemals vorkommen, insofern kerne ich inzwischen innerhalb eines Alphabets praktisch "alles mit allem" - ein Lucas-de-Groot'scher Rundumschlag praktisch.

Mittels Kerning-Klassen vermeide ich, dass die Sache völlig unwartbar wird, außerdem lässt sich auch die Sache mit Monstern wie "adieresis.sc" einigermaßen umgehen weil ich sie selten direkt eingeben muss, die blättere ich meist nur bei kritischen Kombinationen wie "f+ä" quer durch und prüfe ob Kollisionen zum Vorschein kommen - dann gibt's ne Klassen-Ausnahme.

Das mit dem . , zum Weiterschalten ist mir neu, also auch was - sehr nützliches! - gelernt :)

Allerdings funktioniert das bei mir nur im Glyphenfenster, nicht im Metrik-Fenster, da erscheint bei mir an betroffener Stelle einfach ein . oder ein , - so wie ich es auch erwartet hätte, weil ich so ja auch direkt gewünschte Zeichen eingeben kann. Irgend eine Einstellung die das steuert wie sich das "zu verhalten hat"?

[Lecter]

Super kerning tipp. Danke.

Es funktioniert doch im Metrik-Fenster, du musst natürlich den Glyphen vorher markieren/anwählen, den du skippen willst.

Gruß.

[TYPOGRAFSKI]

ich bin kein kerning profi und habe bei meinem ersten font zu viel gekernt, besser die zeit in den spacing reinstecken und nur das nötigste kernen.

bei der aktuellen schrift nutze ich die texte von leslie cabarga, die sind ziemlich gut.

http://www.logofontandlettering.com/kernking.html

ich habe auch mal von peter bilak seine testtexte bekommen, die sind echt hardcore,

es ist aber gut die zum schluß mal durchzugehen.

[Lecter]

Hardcore Kerning-Testtext – klingt interessant.

[Sebastian Nagel]

Es funktioniert doch im Metrik-Fenster, du musst natürlich den Glyphen vorher markieren/anwählen, den du skippen willst.

wenn ich die Glyphe markiere (direkt im Metrik-Hauptfenster, nicht in der Eingabezeile darüber bzw. darunter) und dann "." eintippe, erscheint bei mir der "." an der ausgewählten Stelle. So wie wenn ich "x" tippe, erscheint das "x".

Ich muss dann mal genauer nachsehen ob man das so einstellen kann:

"wenn . oder , getippt wird, schreib das nicht hin sondern blätter weiter"

[Lecter]

"direkt im Metrik-Hauptfenster!" und nicht der erste Glyph, sondern die folgenden. In FL 4.5 geht’s nicht. In der 5er Version dann schon. Vielleicht ist’s auch ein Mac-Feature... don’t know.

[NinaS]

FWIW, ich hab hier die 5er Version und bei mir geht das auch nicht … bzw. es «schreibt» dann halt einen Punkt oder ein Komma hin.

Ob man das irgendwo einstellen kann? Praktisch wärs ja schon (mein Mausrad klemmt).

[Lecter]

Selbst in der 5.0-Demo funzt’s. Auf einem anderen Rechner (auch MAC).

hm???.

[Sebastian Nagel]

Ich überlege immer noch ob wir aneinander vorbeireden oder ob wir wirklich verschiedenes Verhalten vorliegen haben.

In deinem Screenshot 1 hast du das I markiert. Ich kann bei mir (Fontlab 5 unter Windows):

- strg+Mausrad machen, dann wechselt das I zum J

- das J direkt tippen, dann wechselt das I zum J (tippe ich "A.sc", erhalte ich das Smallcaps-A).

- tippe ich . dann wechselt das I nicht zum J, sondern zum . Ich sehe dann also HG.B statt wie zuvor HGIB. Lieber wäre mir aber tatsächlich, dass ich beim Tippen von . das J bekomme, und für den . muss ich halt "period" eingeben. Dann wäre ich einen Schritt weiter von der Maus unabhängig...

Aha aha aha, jetzt bin ich die keyboard-Shortcuts durchgegangen, und finde unter Tools --> customize --> keyboard --> all commands

--> next: next glyph --> strg+acute

und --> prev: previous glyph: strg+ß

und siehe da, das klappt im Glyphen- wie im Metrik-Fenster.

Wenn ich jetzt , und . zusätzlich eintrage geht es auch mit denen, dafür muss ich halt period und comma eintippen wenn ich diese zeichen aufrufen will.

Wäre nur noch interessant, warum wir das nicht standardmäßig haben und du schon :)

[Lecter]

In den gescreenshotteten Bildern bin ich wie gesagt mit "." von "I" nach "J" gelangt.

Wäre nur noch interessant, warum wir das nicht standardmäßig haben und du schon :)

Das würde mich auch interessieren, da ich bisher meine Shortcuts nicht customise. Und das auf zwei völlig unabhängigen Rechnern, mit unterschiedlichen Betriebsystemen und unterschiedlichen Programmversionen.

?

[NinaS]

Aha aha aha, jetzt bin ich die keyboard-Shortcuts durchgegangen, und finde unter Tools --> customize --> keyboard --> all commands

--> next: next glyph --> strg+acute

und --> prev: previous glyph: strg+ß

und siehe da, das klappt im Glyphen- wie im Metrik-Fenster.

Heureka! Danke fürs Suchen *freu*

[fred eric]

Hallo,

ich habe das gleiche Problem wie Lecter, ich würde meiner Schrift gerne Kapitälchen hinzufügen, konnte der Diskussion aber in manchen Punkten nicht so ganz folgen, da noch zu unerfahren. Zum einen würde mich interessieren, ob ich unter "choose encoding or codepage" eine bestimmt Liste auswählen muss (z. B. unter OpenType LatPro Sc gibt es "a - z.smcp") oder sollte man über "Generate Glyphs" für jeden Buchstaben ein Feld anlegen mit dem bereits oben erwähnten Kürzel

"A - Z.sc"?

Zum anderen würde ich gerne wissen, wie man dann den neuen Glyphen einen Platz in der Privat Use Area zuweisen kann, oder geschieht dies automatisch?

Wie ist es, wenn man dann noch Minuskelziffern und Tabellenziffern hinzufügen möchte, habe diese einen festen Platz im Unicode?

Es wäre super, wenn mir jemand in diesen Punkten weiter helfen könnte.

Gruß

[Ralf Herrmann]

Ich weiß jetzt nicht, welchen Fonteditor benutzt, aber prinzipiell werden OpenType-Kapitälchen wie alle anderen OpenType-Sonderzeichen angesprochen. Das heißt, du vergibst beliebige Namen (wie a.sc) und definierst dann im Kapitälchen-Feature die Ersetzung sub a by a.sc. Mehr braucht es gar nicht.

PUA-Codes kannst du, wenn du möchtest, den Zeichen zuweisen. Die sind ja nicht standardisiert. Da kannst du also beliebige Codes aus dem PUA-Bereich vergeben.

Für die Ziffernsets gilt genau das Gleiche. Es müssen hier lediglich die korrekten Features LNUM/PNUM/TNUM/ONUM für die Ersetzungen benutzt werden.

[Þorsten]

Wenn man sich schon – zusätzlich zur obligatorischen Erreichbarkeit über Opentype-Funktionen! – dazu entscheidet, den Kapitälchen Unicode-Positionen zuzuweisen, wie wäre es mit den bereits standardisierten Zeichen namens »Lᴀᴛɪɴ Lᴇᴛᴛᴇʀ Sᴍᴀʟʟ Cᴀᴘɪᴛᴀʟ …« – also U+1D00 für ᴀ, U+0299 für ʙ usw. usf.?

Klar, diese Unicode-Bereiche sind eigentlich nicht für »echte« Kapitälchen vorgesehen, sondern sind für IPA-Zeichen gedacht, die aber eben so aussehen wie Kapitälchen. Aber solange man keine Schrift entwickelt, die sowohl IPA-Zeichen als auch »echte« Kapitälchen enthält (und beide sich irgendwie unterscheiden), wo ist das Problem? Die Vorteile liegen m.E. hingegen auf der Hand. Der wichtigste wäre wohl, dass ein Text, dessen Kapitälchen IPA- statt PUA-kodiert sind, auch ohne den betreffenden Font noch größtenteils¹ lesbar sind, eben z.B. so:

Plötzlich sah er das Schild: Hᴀʟᴛ! Sᴛᴇʜᴇɴʙʟᴇɪʙᴇɴ!

Ein weiterer wäre, dass IPA-kodierte Kapitälchen einfacher einzugeben sind, z.B. über ein Hilfsmittel wie das, das ich gerade verwendet habe.

1. Ja, ich weiß, für X und Q gibt es leider keine Unicode-Positionen, zumindest nicht in der BMP.

[Albert-Jan Pool]

Das Unicode Consortium hat relativ deutliche Regeln für die Vergabe von Unicodes aufgestellt. Laut diesen Regeln bekommen Zeichen nur eine eigene Unicode wenn sie bestimmte Eigenschaften aufweisen. Am besten mal nachlesen um das zu verstehen. Die Konsequenz daraus ist das Kapitälchen keine Unicode brauchen und auch nicht bekommen werden. Und darauf haben sich inzwischen alle Anwendungen und Schrifthersteller eingestellt.

Die Fragen die ich mir erstmal stellen würde sind:

– Funktionieren bei IPA-kodierte Kapitälchen in Anwendungen wie Word und InDesign die Rechtschreibung und die Silbentrennung?

– Wird ein Wort in einem PDF auch dann noch gefunden wenn es in IPA-kodierte Kapitälchen geschrieben ist?

– Word ein Wort auf eine Website auch dann noch von eine Suchmaschine wie Google gefunden wenn es in IPA-kodierte Kapitälchen geschrieben ist?

– Greifen die Stile für Kapitälchen, Groß-/Kleinschreibung in InDesign auf die IPA-kodierte Kapitälchen zu?

– Bleiben bei einem späteren Wechsel zu einer Schrift die keine IPA-kodierte Kapitälchen enthält, immer noch Kapitälchen oder wird dann irgendeine Schrift eingesetzt die zufälligerweise IPA-kodierte Kapitälchen enthält oder erscheinen .notdef Zeichen oder gar keine?

– Was wäre für dem Anwender der Nutzen einer Vergabe von Unicode-Numer für Kapitälchen in die Private Use Area (PUA). Auch hier wird einem Schriftwechsel die Folge haben, dass dann keine Kapitälchen mehr erscheine, sondern höchstens die Zeichen die in der neuen Schrift zufälligerweise auf die PUA-Unicodes in der Schrift liegen. Das sind dann so Sachen wie Logos, vielleicht auch Ornamente oder ausgefallene Aldus-Blättchen usw.

[Mueck]

– Funktionieren ...?

Vermutlich vieles davon nicht ...

Wenn Kapitälchen und IPA-Zeichen gleich aussehen, spricht ja eigentlich nix dasgegen, das Kapitälchen dort zu parken. Dann hat man gleich einen Teil vom IPA supported. Evtl. will man den Rest ja eh irgendwann noch machen. Einige davon braucht man ja auch für's Afrika-Alphabet etc.

Wer ein Programm hat, das OT für Kapitälchen unterstützt, sollte er die Funktion nutzen, klar.

Für denjenigen ohne ein solches ermöglicht es aber womöglich überhaupt erst die Nutzung der Kapitälchen, das wäre besser als nix ...

Die m.E. bessere Option wäre vermutlich, einen Extraschnitt Kapitälchen anzubieten für solche Fälle.

Wäre meiner unwesentlichen Meinung nach eh logisch. Für die Auszeichnungen kursiv und fett gibt's das ja auch ...

[Albert-Jan Pool]

Vermutlich vieles davon nicht ...

Na ja, wieso dann das Ganze? Kapitälchen und Mediävalziffern brauchen einfach keine Unicode. Und wer eine Anwendung hat der noch nicht auf die Kapitälchen zugreifen kann, ist bis dahin am besten mit einem Kapitälchen-Schnitt wobei die Kapitälchen auf die Unicodes der Kleinbuchstaben liegen. Dann laufen die oben genannte Funktionen fast alle einwandfrei. Einige Anbieter haben aber inzwischen aufgehört solche Schnitte anzubieten. Es gibt inzwischen einfach zu wenig Anwendungen und Anwender die diese Schnitte brauchen bzw. dafür bezahlen wollen.

Wenn Kapitälchen und IPA-Zeichen gleich aussehen, spricht ja eigentlich nix dasgegen, das Kapitälchen dort zu parken.

Ja, aber nur zusätzlich und am besten als Component.

[Ralf Herrmann]

Da sich die OpenType-Ersetzung über den Namen und die Unicode-Ansprache ja technisch gegenseitig nicht stören ist das natürlich technisch machbar. Wenn dann aber sowohl ein unvollständigen IPA-Set, als auch ein unvollständig kodiertes Kapitälchen-Set rauskommen (weil x und q fehlen), dann ist das auch irgendwie alles nur ein Gedankenspiel mit wenig praktischem Nutzen.

Die m.E. bessere Option wäre vermutlich, einen Extraschnitt Kapitälchen anzubieten für solche Fälle.

Wäre meiner unwesentlichen Meinung nach eh logisch. Für die Auszeichnungen kursiv und fett gibt's das ja auch ...

Weil letztere die komplette Schrift betreffen – jeder Buchstabe ändert sein Design. Kapitälchen ändern lediglich die lateinischen Kleinbuchstaben. Zusätzliche Schnitte führen also zu völlig unnötigen Verdoppelungen des Zeichenvorrats. Der Logik nach könnte man dann auch für jeden Ziffernsatz (tabellarisch/proportional/mediäval/versal), jeden Stilsatz, Schwungschrift etc. einen eigenen Font bauen. Das wäre ein ziemliches Durcheinander und eben gerade nicht »logisch«. Die früheren Kapitälchen-Schnitte waren eine Folge der Beschränkungen der PostScript-Schriften mit ihren vorgefertigten Codepages.

[Sebastian Nagel]

:) Konsequent (und in der Praxis nicht einführbar) wäre ja gewesen, den Versalien auch keinen Unicode-Point zu geben und die Glyphenersetzung Minuskel>Versal über ein Opentype-Feature zu regeln ...

Das Ausweichen mit den Kapitälchen auf Codepoints, die dafür nicht vorgesehen sind, zieht einen so großen Rattenschwanz hinter sich her, dass man das zwar als "Sonderanfertigung" machen kann (warum dann aber nicht gleich PUA?), aber ich würde das niemals in einer öffentlich lizenzierbaren Schrift anbieten und dann Support dafür leisten wollen ...

[Þorsten]

Was wäre für dem Anwender der Nutzen einer Vergabe von Unicode-Numer für Kapitälchen in die Private Use Area (PUA). Auch hier wird einem Schriftwechsel die Folge haben, dass dann keine Kapitälchen mehr erscheine, sondern höchstens die Zeichen die in der neuen Schrift zufälligerweise auf die PUA-Unicodes in der Schrift liegen. Das sind dann so Sachen wie Logos, vielleicht auch Ornamente oder ausgefallene Aldus-Blättchen usw.

Und genau deswegen habe ich die Frage in den Raum geworfen, ob die IPA-Bereiche dann nicht das kleinere Übel wären. Statt zufälliger Zeichen/Ornamente/Logos sähe man dann eben die »kapitälchenförmigen« small capital letters – und könnte das Geschriebene also wenigstens noch entziffern.

Dass es generell Murks ist, Kapitälchen über Unicode statt Opentype anzusprechen, ist hier wohl unstrittig. Es geht mir nur darum, welche Notlösung weniger Probleme aufwirft.