Schriftsysteme Webdesign

[krukon]

Hallo ihr Wissenden, 

ich möchte ein Schriftsystem fürs Web aufsetzen. Dafür hab ich mit https://type-scale.com/ ein Verhältnis gewählt, das mir harmonisch erscheint. Nun frage ich mich, warum die vorgeschlagenen Schriftgrößen so krumme Werte haben  (zb. 36,06px) und ob solche Zahlen tatsächlich praktikabel im Webdesign sind. 

Ich danke euch fürs Wissen teilen. 

 

Viele Grüße 

Konstanze 

[Ralf Herrmann]

Die Website rechnet halt einfach von der Ausgangsgröße hoch und runter ohne zu runden. Ich sehe keinen Grund, solche krummen Werte zu verwenden. 

[Phoibos]

Da es den Nutzern überlassen ist, wie die Website gerendert wird, würde ich solche Spielereien lassen. 

[Þorsten]

vor 53 Minuten schrieb Phoibos:

Da es den Nutzern überlassen ist, wie die Website gerendert wird, würde ich solche Spielereien lassen. 

Was ist für dich in diesem Kontext denn eine »Spielerei«?

 

Du hast generell natürlich in der Beziehung recht, dass Leser Einfluss darauf haben (sollten), wie groß Website-Text in ihrem Browser sein sollte. Das heißt aber nicht, dass Autoren und ihre Gestalter sich keine Gedanken darüber machen sollten, wie viel größer bzw. kleiner Text verschiedener Überschriftebenen und etwaiger Marginalien erscheinen sollte. 

[Phoibos]

Schriftgrössen mit Nachkommastellen im Screendesign sind Spielereien. Und ob mein Browser Dein sorgfältig ausgewürfeltes CSS berücksichtigt, kannst Du nicht feststellen. 
Kann CSS nicht auch relative Größen für Überschriften er al?

bearbeitet September 30, 2019 von Phoibos
Tante Edith hat die Relativierung Screendesign angemahnt.

[Phoibos]

Mir fällt noch zum Thema Screendesign ein, dass solche absoluten krummen Werte aufgrund der nicht bekannten ppi des Ausgabegeräts sinnfrei sind. Im Zweifel wird das sorgsam ausgelotete Design kaputtgerundet.

[Sebastian Nagel]

Irgendwie ist dieses System seltsam ...

 

Es geht von 1em aus, und skaliert dann stur (statt visuell) mit 0,8-faktoren nach oben und unten. Das ergibt dann natürlich schnell krumme Werte, die mathemisch sauber sein mögen, dabei aber keinen praktischen Mehrwert haben, aber auch keinen dramatischen Nachteil mehr (schlimmstenfalls auf alten Systemen mit negativen Auswirkungen aufs Rendering der Formen, wenn keine ganzen Pixel verwendet werden - moderne renderer und heute Displays haben damit aber keine Mühe).

 

Dann stellt sich die Frage, was 1em ist - em ist eine relative Größenangabe in Bezug auf das Eltern-Element, 1em bedeutet "gleich groß wie von oben verordnet").

Dabei geht das System davon aus, das das (jedes?) Eltern-Element eine statische Größe von 16px hat, nur so machen die Pixelwerte in Klammern im allgemeinen Sinn - hat ein Elternelement eine andere Schriftgröße (z.b. eine Randspalte mit Basis 14px) dann ändert sich auch die Größe der "Kinder" entsprechend, da über em definiert (ergäbe dann aber andere px-Werte in den Klammern).

Das ist nicht ganz schlimm bzw. kann durchaus mal gewollt sein wenn man semantisch koreekt deklarieren will aber dabei kontext-abhängig für die gleichen Tags / Klassen verschiedene visuelle Größen haben möchte - aber ein "einfach handhabbares System" aus grafiker-sicht ist das dann meist nicht mehr.

Meist einfacher ist es, stattdessen mit rem-Größen zu arbeiten - das sind auch relative Größen, die ihre Größe aber immer von der Dokumentbasis (body-tag) aus berechnen, d.h. ganz egal was ein direktes Eltern-Element hat, ein so formatiertes Element ist überall gleich groß (die Basis sollte dann in px definiert sein - wenn nicht, gibt der Browser oder User einen Standardwert vor und alles andere orientiert sich dann relativ daran). Das ist aus grafischer Sicht einfacher zu handhaben, birgt aber die Gefahr, dass man dir Semantik verschiebt, um die Optik zu beeinflussen ("eine ü4 ist an der Stelle zu groß? mach ich eben schnell eine ü5 draus ...").

Man könnte auch alles in px deklarieren ... das wirkt so als hätte man die absolute Kontrolle, wird halt schrecklich mühsam, wenn man für andere Bildschirmgrößen (Smartphone, ...) das dann anpassen möchte - mit relativen Angaben und einer Basisgröße ist das einfach, mit absoluten nicht. Da kommt einfach raus dass Gestaltung für Bildschirme (Mehrzahl!) nicht das selbe ist wie für gedruckte Medien.

 

 

Die Problematik, dass "1px" nicht überall visuell gleich groß ist, stellt sich inzwischen eigentlich nicht mehr bzw. immer weniger ... die Angabe in px ist inzwischen eine für virtuelle Pixel, die sich auf die einigermaßen etablierte Größe eines Pixels auf einem herkömmlichen Bildschirm beziehen - das Betriebssystem macht daraus dann eine Umrechnung in hardware- oder "device-pixel", d.h. eine 12px-schrift auf einem Retina/hiDPI-screen ist nicht kleiner, sondern nur schärfer / detailreicher als auf einem Display herkömmlich üblicher Auflösung (klassischerweiße etwas um die 100ppi), die übrigen Pixel werden nicht für zusätzlichen Platz sondern für zusätzliche Schärfe verwendet. Welcher Faktor hier verwendet wird, gibt in der Regel das Gerät vor (Android-Smartphones meist zwischen 1,5 und 3x; Windows-10-rechner über den Bildschirmtreiber oder frei wählbaren Skalierungsfaktor für das komplette UI; Apple-Geräte immer mit dem fixen Faktor 2x und die Displays haben eine dem entsprechende Hardware-Pixelzahl die bei diesem Faktor etwa die übliche Darstellungsgröße sicherstellen). Der Webdesigner bzw. der Browser muss sich selten darum kümmern, wobei es sie Möglichkeit gibt das auszulesen und ggf. auch spezifisch zu nutzen (oft: bessere Bilder für Geräte die das auch anzeigen können).

 

Dass ein User bewusst die Gestaltung so umstellt dass sie ihm besser passt, muss ein Gestalter am Bildschirm in Kauf nehmen bzw. sollte das auch begrüßen und nicht erschweren (z.b. für Lesbarkeit bei schlechter Sicht, z.b. durch Überschreiben einer Basis-Schriftgröße - siehe rem-Angaben). Allerdings sollte er auch nicht davon ausgehen dass das viele tatsächlich machen und eine eigenständige, gute  Gestaltung ohnehin sinnlos ist (effektiv wirkt sonst das was der Browserhersteller sinnvoll fand).  Und er sollte auch nicht den Absender in der Kommunikationsbeziehung ignorieren - der hat ebenso wie der Empfänger Bedürfnisse, die ein Kommunikationsgestalter berücksichtigen muss. Nur weil der Empfänger in Web eingreifen kann, heißt das nicht dass alle Macht und alle Verantwortung bei ihm liegt.

 

 

In der Praxis:

Größe für Body in px festlegen, im Zweifel 16px. Das ist der Wert der zu verändern ist, wenn man alle Größen  anpassen möchte, z.b. für Smartphones, für Barrierefreiheit per Schalter auf der Webseite, oder als einfache Möglichkeit, dass der User sich eine eigene Größe anlegeb kann ohne zig werte ändern zu müssen.

Alle weiteren Größen in em oder rem angeben. Das hängt davon ab, wie komplex das Layout ist und wie semantisch korrekt man sein möchte. Bei visuell komplexen Sachen: Bequemer ist rem ... ethischer ist em.

Ansehen, welche Größen / Hierarchien man braucht. Basistext, Nebentext, Seitentitel, 2-4 Überschriften-Hierarchien, ... und diese in optisch sinnvolle Relationen zu bringen (funktionell aber auch ästhetisch). Text hat dann 1rem, Titel 3rem, Ü1 2rem, Ü2 1.5rem, Ü3 1.25rem, Ü4 1rem bold?  Sich erst eine Größensammlung anzulegen und dann zu sehen wofür man die nun brauchen könnte, ist der verkehrte Weg, auch wenn irgendwer eine n Generator dafür geschrieben hat ...  Was sinnvolle Größenverhältnisse sein können bzw. wie man sie für seine aufgabe finden kann, steht z.b. in Peter Willbergs Lesetypografie - die ist größtenteils medienunabhängig gültig. mit der Zeit hat man natürlich ein Gefühl dafür und braucht keine Bekräftigung durch einen Rechner mehr.

[Þorsten]

vor 2 Stunden schrieb Phoibos:

Schriftgrössen mit Nachkommastellen im Screendesign sind Spielereien. Und ob mein Browser Dein sorgfältig ausgewürfeltes CSS berücksichtigt, kannst Du nicht feststellen. 
Kann CSS nicht auch relative Größen für Überschriften er al?

Da schmeißt du ziemlich viel durcheinander. Klar sind nichtganzzahlige Pixelwerte nicht sinnvoll. Aber das hat nichts damit zu tun, ob ein Browser CSS-Deklarationen überhaupt anwendet. Und ja, relative Größen sind in den meisten Fällen vorzuziehen.

 

Ansonsten … was Sebastian geschrieben hat!

[Gast Schnitzel]

vor 8 Stunden schrieb Sebastian Nagel:

. eine 12px-schrift auf einem Retina/hiDPI-screen ist nicht kleiner, sondern nur schärfer / detailreicher

Hmm, ich arbeite mit zwei Monitoren – iMac 21,5“ Retina und einem Pivot-Bildschirm mit deutlich weniger Pixeln. Thunderbird liegt regelmäßig auf dem zweiten Bildschirm, da ich auf dem iMac die E-Mails nicht mehr lesen kann. Ich könnte wahrscheinlich die Standardschriftgröße/Anzeigegröße ändern, aber hier will ich darauf hinaus, das es auf beiden Geräten deutlich unterschiedlich dargestellt wird. Für Webseiten und Programmfenster gilt das gleiche …

[Ralf Herrmann]

»Nicht *zwingend* kleiner« hätte es noch besser getroffen. Kern der Aussage war ja lediglich, dass die Pixelgröße nicht einfach eins zu eins umgesetzt wird. Sind doppelt so viele Pixel vorhanden, wird die Schrift nicht etwa halb so groß, weil die 12 Pixel vermeintlich eins zu eins auf die Hardware-Pixel verteilt werden. Es wird entsprechend skaliert. Die entstehende absolute physische Größe ist aber nicht geräteübergreifend identisch und das ist wegen der unterschiedlichen Leseabstände auch gar nicht das Ziel. 

[Sebastian Nagel]

Apple hat es sich mit der macOS Software-Lösung für hiDPI-Displays (d.h. alles was nicht klassischerweise irgenwo rund um 100ppi Pixeldichte liegt) verhältnismäßig einfach gemacht (was damals gut so war): sie haben dafür gesorgt, dass ihre hiDPI-Displays (Retina) immer eine etwa so hohe Pixeldichte haben, dass bei einem statischen Faktor zwischen Hardware- und virtuellem Pixel immer der Faktor 2 "gut genug passt", wobei wie Ralf schon angemerkt hat das natürlich auch vom üblichen Leseabstand für die Geräte abhängen muss / soll.

Gut zu sehen am iMac kleinen iMac, der ein 4k-Display hat und auf etwa 220ppi kommt, und ein großer iMac mit 5k-Display, der ebenfalls auf 220ppi kommt. Beim voreingestellten Faktor 2 ergibt das etwa eine Größenentsprechung eines normalen Displays mit 110ppi (was allgemein noch als "richtig groß" wahrgenommen wird). Bei den Macbooks ist es genau gleich – die 13"-Geräte haben Displays mit geringeren Pixelabmessungen als die 15"-Geräte, aber alle mitteln sich bei etwa 220ppi ein.

Das hat den riesen Vorteil, dass die softwareseitige Lösung sehr einfach und effizient ist – ein Faktor 2 ist in der Programmierung von Treibern, Userinterface-Bibliotheken und Anwendungen sehr einfach handhabbar und "kostet" auch performance-technisch nicht viel. Und uralte Programme die das alles nicht vestehen, sehen mit Faktor 2 den ihnen dann das System aufzwingt zwar grob aus, aber nicht verwaschen oder kaputt. (Man *kann* in den Systemeinstellungen andere Skalierungen einstellen, sieht dann aber auch gleich die negativen Effekte bei Geschwindigkeit und Darstellungsqualität.)

Das klappt aber alles nur, weil Apple defacto die Kontrolle über alle Bildschirme hat, auf denen macOS meist angezeigt wird, und sie sicherstellen können, dass diese Displays immer rund um 110 oder 220ppi Pixeldichte liegen. Sobald man einen fremden Bildschirm anschließt, der davon deutlich abweicht (was inzwischen technisch durchaus möglich wäre), passt diese Rechnung nicht mehr, die Darstellungsgröße stimmt nicht mehr, bzw. macOS deaktiviert die Skalierung des angezeigten Inhalts ganz (dann wird's bei hohen Pixeldichten oft sehr winzig, bei groberen als angenommen recht groß).

 

Ich hab hier neben dem 27"-iMac mit 5k-Display einen billigen 27"-4k-Bildschirm stehen – selbe Größe wie der iMac, aber eben weniger Pixeldichte – den kann ich unter macOS nicht so konfigurieren, dass die Abbildungsgröße identisch zum Hauptdisplay ist (ich bräuchte einen Faktor 1,6 dafür). Es gäbe die Mögleichkeit über andere Auflösungen die ich an den Bildschirm schicke, dann wird halt das Bild sinnlos matschig weil der Bildschirm intern skaliert. (in meinem Fall ist es nicht wichtig dass die gleich groß sind, der zweite Schirm zeigt Paletten, Entwicklerfenster, etc. an, also ohnehin andere Inhalte).  In der Praxis ist das also selten wirklich das wichtigste Kriterium.

 

Unter Windows 10 (seit knapp 2 Jahren) ist es so, dass man für jeden Bildschirm einen freien Skalierungsfaktor wählen kann (in 1%-Schritten), d.h. letztlich ist die Anzeigegröße nicht mehr abhängig von der Bildschirmauflösung / Pixeldichte, und die Pixeldichte kann so hoch sein wie sie will, ich gewinne damit "nur" Abbildungsschärfe. Windows macht sich und den Anwendungsentwicklern da das Leben schwerer, da verschiedenste Skalierungsfaktoren angenommen werden müssen. Wenn alle UI-Elemente auf moderen UI-Bibliotheken basieren (direct2d statt GDI), ist das einfach, da die Bibliothek diese Funktionen anbietet und die richtige Größenskalierung und Feinheit der Darstellung von Text, Grafikelementen etc. praktisch übernimmt. Bei sehr alten Programmen oder unsauberer Programmierung kommt es schlimmstenfalls zu unbedienbaren Programmen. Seit einem guten Jahr kann man allerdings in so einem Fall dem System die Kontrolle über die Anwendung geben, dieses gaukelt ihr dann ein nicht-skalierendes Betriebssystem vor und vergrößert das was die Anwendung als Anzeige ausgibt letztlich selbst (unscharf / grob, aber funktioniert immer).

Beispiel: mein 15,6"-Thinkpad hat z.B. ein 4k-Display, das resultiert dann in ziemlich genau 300ppi. Bei Faktor 2 wäre die Anzeige zu klein – bei Faktor 2,5 komme ich auf die Anzeigegröße eines herkömmlichen 120ppi-Displays (was für mich und meine Sehstärke passt und mir etwas mehr Platz als gewohnt veschafft), wenn ich auf die gewohnten 110ppi-Äquivalent abziele müsste und könnte ich als Faktor 2,66 wählen. Schließe ich einen externen Bildschirm an, kann ich (wenn es was aus dem Altgeräte-Lager ist) den Faktor dafür auf 1 oder sogar darunter stellen, wenn es mir wichig ist dass die Abbildungsgröße gleich ist – oder eben was anderes. Ich kann danach sogar ein Fenster zwischen den Schirmen platzieren und die Abbildungsgröße bleibt erhalten (nur die Anzeigeschärfe ändert sich wenn sich die Bildschirme qualitativ deutlich unterscheiden).

 

Ich könnte mir gut vorstellen, dass Apple in einer der kommenden Desktop/Notebook-Generationen einen Faktor 3 einführt, um die inzwischen höher auflösenden Displays die es am Markt gibt verwenden zu können – wahnsinnig schwierig sollte das heute nicht mehr sein – damals bei flächendeckender Einführung von "Retina" war das viel komplizierter, da viele Anwendungsenwickler niemals daran gedacht hatten, dass es was anderes geben könnte als Displays rund um 100ppi. Wirklich freie Skalierungsfaktoren für beliebige Bildschirme würden vermutlich aber einen gröberen Umbau im Userinterface-Code (Quartz) von macOS bedeuten, da hat Apple keinen Anlass dafür.

 

 

(Detail: bei iOS gibt es inzwischen meist den Faktor 3 – die Displays werden besser, die Größe sollte gleich bleiben).

[krukon]

Danke für eure Meinungen, 

ich denke solchen modularen Skalen sind schon hilfreich, aber die krummen Werte sind dann wahrscheinlich doch eher zu runden. 

@Sebastian Nagel ich verstehe nicht so ganz, was du damit meinst, denn ich muss ja alle Werte in px definieren, um den screen zu designen. Oder? 

Für die Umsetzung im css wäre es natürlich der Weg, mich interessiert aber die Design Phase davor. Wie ist da dein Workflow? 

vor 20 Stunden schrieb Sebastian Nagel:

 

In der Praxis:

Größe für Body in px festlegen, im Zweifel 16px. Das ist der Wert der zu verändern ist, wenn man alle Größen  anpassen möchte, z.b. für Smartphones, für Barrierefreiheit per Schalter auf der Webseite, oder als einfache Möglichkeit, dass der User sich eine eigene Größe anlegeb kann ohne zig werte ändern zu müssen.

Alle weiteren Größen in em oder rem angeben.

 

[Sebastian Nagel]

vor 3 Stunden schrieb krukon:

denn ich muss ja alle Werte in px definieren, um den screen zu designen. Oder? 

Für die Umsetzung im css wäre es natürlich der Weg, mich interessiert aber die Design Phase davor. Wie ist da dein Workflow?

Eigentlich eben nicht – px ist nicht zwingend für alles notwendig oder zweckmäßig, weder für den Text noch unbedingt für Spaltenbreiten, Boxenbreiten etc. Wie angedeutet, ist es zweckmäßig, eigentlich nur ein Grundmaß in einer absoluten Größe (und da ist dann meist px am sinnvollsten) festzulegen. Alle anderen Größenangaben setzen dann auf dieser Basis auf.

 

Bei Schriftgrößen, Zeilenabständen, Rändern etc. sind eben die rem- oder em-Einheiten zweckmäßig (wieviele Einheiten der Basisgröße bzw. wieviele Einheiten der Mutterelement-Größe).

Bei Spaltenmaßen etc. oft in %-Werten des Mutterelements, wobei auch hier oft eine maximale Breite des Basis-Containers in einem absoluten Pixelmaß angegeben wird (z.B. maximal 1600px, auch wenn das Fenster breiter sei), und erst innerhalb davon wird dann mit %-Anteilen unterteilt (z.B. Randspalte 25% der Gesamtbreite, Hauptspalte 75%).

 

Die Basis-Textgröße ist dann also für große Bildschirme mit 16px definiert – eine Überschrift1 könnte mit 2rem definiert sein, das wären dann indirekt 32px, eine Überschrift2 mit 1.5rem, das wären dann indirekt 24px, eine Überschrift3 mit 1.25rem oder effektiv 20px, etc.  (wobei es in der Praxis heute meist echt egal ist, ob da letztlich krumme Pixelwerte rauskommen oder nicht).

Bei kleineren Bildschirmen könnte die Basis dann auf 14px reduziert werden (da meist geringerer Sehabstand aber weniger Freiraum), alles andere ergibt sich dann wieder von selbst durch die relativen Größenangaben der anderen Elemente.

 

Das alles setzt ein wenig voraus, dass man sich von der Vorstellung verabschiedet, auf einem – im Gegensatz zu Drucksachen – recht beweglichen Medium das visuelle Ergebnis in 100% der Fälle zu 100% kontrollieren zu können. Was man kontrollieren kann sind Regeln, die abhängig von verschiedenen Rahmenbedinungen (Smartphone, Tablet, Großbildschirm, Ausdruck, Screenreader, ... ) wirken werden und ein fallabhängiges visuelles Ergebnis erzeugen.

Man definiert hier also "sinnvolle Grundregeln", daraus manifestiert sich ein erstes visuelles Resultat. Man justiert die Regeln nach, entwickelt Ausnahmen und Feinheiten. D.h. man hat im Grunde erst mal ein einfaches Regelwerk und einen stur agierenden Interpreter dieser Vorgaben (den Browser), und muss dann etwas dafür tun, wenn man etwas mehr "Unordnung" erzeugen will, um das Ergebnis visuell einzigartig zu machen – vielleicht vergleichbar mit einer Skulptur die man aus einem Steinblock rausarbeitet*. Dabei sollte man aber nicht hoffen, dass man einfach "genug Regeln" schreiben muss, um alle Fälle einzeln perfekt abdecken zu können – das sind nämlich durch verschiedenste Einflüsse eher hunderte Situationen als die erhofften 3-4 ... (es sind immer wilde Kombinationen aus Bildschirm/Fenstergrößen, Auflösungen, Browsertechnik, Internetverbindung, Betriebssystem, verfügbaren Schriften, Spracheinstellungen, Benutzer-Sonderregeln, Zoomstufen, ... ... ...).

Dem entsprechend habe ich lange damit aufgehört, eine Webseite erst in einem "Print"programm zu gestalten und sie dann wenn sie "perfekt" ist programmieren zu wollen. Meist gibt es (bei uns) auch andere Medien, die schon ein CI und Inhalte vorgeben, d.h. die Stilistik eines Projekts sind schon definiert. Dann gehe ich recht schnell mit einem HTML/CSS-Prototyp ans Werk und arbeite eine exemplarische Seite immer weiter aus und teste sie laufend auf verschiedenen Geräten. Die Größen ergeben sich dann meist einfach aus der Optik heraus – mit einem System zu starten ist dabei natürlich hilfreich und richtig (wenn es schon eins aus anderen Medien gibt, umso besser) – außer das System will partout nicht passen.

Dann ist die Frage wie es weitergehen soll ... wenn es in ein Redaktionssystem rein geht, kommt dann viel Hickhack von dieser Seite dazu (dann oft extern, die dann meinen Prototyp auswerten und darin umsetzen), wenn es was handgestricktes bleibt, muss oft noch aufgeräumt, systematisiert, ergänzt werden, während weitere Seiten und Elemente gebaut werden.

 

 

* Im Gegensatz dazu hat man in klassischen Layoutprogrammen für Print eine Leinwand, Elemente die man ohne Strukturvorgaben durch das Programm hinwürfelt, und wenn man "Ordnung" schaffen will muss man was dafür tun – etwa Raster einhalten, ausrichten, Formatvorlagen anlegen(!), etc. – vielleicht vergleichbar mit einer Plastik die man aus formbarem Material aufbaut.

[krukon]

Danke euch allen für die ausführliche Erklärung! 

Ich muss vorher in Illustrator layouten, werde der Einfachheit halber gerade px Werte wählen.

[Hans Schumacher]

Am 30.9.2019 um 23:29 schrieb Sebastian Nagel:

Sich erst eine Größensammlung anzulegen und dann zu sehen wofür man die nun brauchen könnte, ist der verkehrte Weg, auch wenn irgendwer eine n Generator dafür geschrieben hat ...  Was sinnvolle Größenverhältnisse sein können bzw. wie man sie für seine aufgabe finden kann, steht z.b. in Peter Willbergs Lesetypografie - die ist größtenteils medienunabhängig gültig. mit der Zeit hat man natürlich ein Gefühl dafür und braucht keine Bekräftigung durch einen Rechner mehr.

In Willbergs Lesetypografie ist zu Größenverhältnissen von Schriftgrößen nicht viel zu finden. Die Größenskala, die noch aus dem Bleisatz kommt und sich in so schönen Bezeichnungen wie nonpareil und minion erhalten hat, gibt es bei Robert Bringhurst (s. Abbildung unten), auf den wohl auch diese Art von Generatoren zurückgehen (»Don't compose without a scale« ist eine Überschrift in seinem populären Werk The Elements of Typographic Style, wo sich auch die traditionelle Skala findet, s. Abbildung. Hier hat auch schon jemand versucht, diese auf das Webdesign zu übertragen – die site ist der Vorläufer der Publikation Web Typography  von Richard Rutter).

Zitat

 

So choosing from the traditional scale, our final font sizing style sheet could look as follows:

body { font-size: 100%; }

h1 { font-size: 2.25em; /* 16x2.25=36 */ }

h2 { font-size: 1.5em; /* 16x1.5=24 */ }

h3 { font-size: 1.125em; /* 16x1.125=18 */ }

h4 { font-size: 0.875em; /* 16x0.875=14 */ }

p { font-size: 0.75em; /* 16x0.75=12 */ }

 

 

[Ralf Herrmann]

Die Bleisatzgrößen – speziell die größeren Grade (24/36/48/60/72) – ergeben sich aus dem maßgeblichen 12-er System. Das hat rein praktische Gründe beim Erstellen des Satzes und ist keine optisch austarierte Skala der Schriftmischung innerhalb eines Dokumentes. Ich wüsste also nicht, warum man dies im Digitalsatz als Basis für irgendetwas heranziehen wollen würde. Man könnte statt 12 verschiedenste andere Vergrößerungsfaktoren wählen, logarithmisch vergrößern oder gänzlich ohne festes System. 

[Hans Schumacher]

Hmm, ja, du hast recht, eigentlich offensichtlich – tja, »diatonic scale« My ass! Die Tonleiter-Vergleiche mit der traditionellen typografischen Skala sind ja dann doch relativ sinnfrei, da ein Schriftgrößengenerator wie oben (typescale.com) ja auch nur mit einem festen Faktor durchgängig von der einmal festgelegten Grundschriftgrösse ausgehend skaliert, in den entstehenden Skalen gibt es dann ja auch keine Halbton-Schritte

 

Trotzdem irgendwie enttäuschend, deshalb hier dann mal ein Versuch die C-Dur Tonleiter (Stammtonreihe) als »typographic scale« umzusetzen. Ausgangspunkt (Stammton) dann mal als 12pt oder pixel festgelegt, die Intervallschritte auch 12 pt (oder 6 pt bei einem Halbton):

Tonleiter:C-D-E- (Halbtonschritt) F-G-A-H- (Halbtonschritt)

12pt (C) / 24pt (D) / 36pt (E) / 42pt (F) / 54pt (G) / 66pt (A) / 78pt (H) / 84pt (C)

Und als Molltonleiter:

C-D- (Halbtonschritt) Es-F-G- (Halbtonschritt) As-B-C
12pt (C) / 24pt (D) / 30pt (Es) / 42pt (F) / 54pt (G) 60pt (As) 72pt (B) 84pt (C)

Dokumentweit bzw. Websiteweit müssten da natürlich nicht alle Töne zum Einsatz kommen, aber ich sehe da schon die Verwendungsmöglichkeiten im Corporate Design (wenn das Soundlogo mit den verwendeten Schriftgrößen korrespondiert: DaDaDaDiDa😀)

 

[Þorsten]

Das wird in der Praxis aber nie (einfach so) funktionieren, weil verschiedene Schrift durch unterschiedliche Grauwerte, x-Höhen und und und eben immer anders wirken. Aber als (immer nachzujustierender) Ausgangspunkt ist es vielleicht auch nicht schlechter als jeder anderer mehr oder weniger willkürlich festgelegter.

[TobiW]

vor 18 Stunden schrieb Hans Schumacher:

Trotzdem irgendwie enttäuschend, deshalb hier dann mal ein Versuch die C-Dur Tonleiter (Stammtonreihe) als »typographic scale« umzusetzen. Ausgangspunkt (Stammton) dann mal als 12pt oder pixel festgelegt, die Intervallschritte auch 12 pt (oder 6 pt bei einem Halbton):

Coole Idee, wobei die Tonabstände eigentlich ja Frequenzverhältnisse sind also wenn man z.B immer 20Hz erhöht, bewegt man sich nicht in Halbtönen aufwärts. Übertragen auf Schriftgrößen könnte man dann eher 12pt als Grundton festlegen und dann aus den reinen Intervallen folgende Größen ableiten:

Steigende Intervalle

• 16pt = Quarte (3:4)
• 18pt = Quinte (2:3)
• 24pt = Oktave (1:2)
• 32pt = Duodezime = Oktave + Quarte (1:2 × 3:4 = 3:8)
• 36pt = Tredezime = Okatve + Quinte (1:2 × 2:3 = 2:6 = 1:3)
• 48pt = Doppeloktav = Okatve + Okatve (1:2 × 1:2 = 1:4)

Fallende Intervalle

• 9pt = Quarte (4:3)
• 8pt = Quinte (3:2)
• 6pt = Oktave (2:1)

 

 

[Hans Schumacher]

Sehr schön! Tolle Skala und Herleitung! Dank deiner Herleitung verstehe ich jetzt einiges vom Bringhurst besser, da finden sich die Intervall-Verhältnisse bei »Page proportions as musical intervals« (in dem Kapitel gibt es dann auch ein paar Einschübe zu Schriftgrößen)  Wenn man schon die Analogie zur Musik herstellt, was ja wie Þorsten und du schon festgestellt habt, einige Schwierigkeiten verursacht, ist das doch ein ziemlich überzeugender Versuch.

[Phoibos]

Am 13.10.2019 um 09:48 schrieb TobiW:

Übertragen auf Schriftgrößen

Ganz toll! Und andere Schriftgrößen in Texten habe ich in meinem Leben auch noch nicht verwandt. Intuition ist einfach was tolles 😄 Und noch toller, wenn sich dafür eine Theorie findet.

[TobiW]

Danke für die Blumen  An die Überschrift von dem Brighurst-Kapitel erinnere ich mich auch, aber ich bin nicht sicher, ob ich das Kapitel schon mal gelesen habe …

 

Wobei ich nicht sagen will, dass die Schriftgrößen sich aus den Musikalischen Intervallen ergeben. Ich glaube eher, das beides zu „schönen“ Ergebnissen führt, weil es eben auf kleinen, ganzzahligen Verhältnissen basiert.