Fontbureau Input – nicht-diktengleiches Coding-Fontsystem

[Sebastian Nagel]

Fontbureau hat ein untypisches, weil nicht-diktengleiches Coding-Fontsystem vorgestellt ...

 

http://input.fontbureau.com/

http://input.fontbureau.com/info/

 

Ich teste mal, bin aber vom Konzept noch nicht ganz überzeugt ... Was haltet ihr davon? 

 

(Abseits der Besonderheit gibt es auch monospace-Varianten, die so oder so einen Versuch wert sind. Und die Webseite selbst, mit der sich spezialisierte Font-Varianten generieren lassen, ist auch einen Besuch wert.)

[Phoibos]

Coole Sache, sich einstöckige a und g aussuchen zu dürfen. Nettes Angebot.

[RobertMichael]

ich find die idee dahinter auch ganz nett, ist für mich jedoch eher uninteressant. ich würde mich dann eher an der desktop-version erfreuen... wie verhält es sich dann aber dort mit den alternates, sind die alle inklusive?

[Sebastian Nagel]

Grade getestet – im Standard-Downloadpaket mit allen Schnitten sind die Alternates eingebettet und per Opentype umschaltbar.

[Christian Z.]

Ich kann mich nicht erinnern, mal in einem irgendeinem Code-Editor die Schrift umgestellt zu haben, weil mir die Standard-Schrift Probleme bereitete. Wenn überhaupt, die Darstellungsgröße. Meistens nicht einmal die Hintergrundfarbe.

 

Monospace zu hinterfragen halte ich für gar nicht so abwegig. Eigentlich muss bei einer Coding-Schriftart hauptsächlich ja "nur" jeder Buchstabe am Bildschirm absolut eindeutig erkennbar sein (I,l,1, 0,O, usw.) und der häufigeren Benutzung und höheren Bedeutung von Satzzeichen Rechnung getragen werden.

[Ralf Herrmann]

Mir ist die Schrift viel zu »gestaltet« und würde mich daher eher beim Programmieren stören. 

 

Monospaced-Fonts sind beim Programmieren freilich keine Pflicht, aber auch nicht einfach nur ein historisches Überbleibsel. 

Der Input-Erklärungstext stellt als Vorteil heraus, dass man mit dieser Schrift einen Vertipper von n und m leichter sehen würde. Nun ja. Das kann man auch leicht umdrehen. In einer Monospaced-Schrift sehe ich ein fehlendes ' im Code dafür deutlich schneller. Überhaupt funktionieren dort natürlich alle tabellenartigen Darstellungen deutlich besser – und die sind ja in Quellcode nicht so selten. 

Lesbarkeitsprobleme (rn vs. m, 0 vs. O usw.) können ja unabhängig von der Glyphen-Weite behandelt werden. 

[Christian Z.]

Deren Argument ist ja auch, dass man fehlende Anführungszeichen schnell durch Syntax-Higlighting erkennt.

 

Tabellenartige Darstellungen im Quelltext sind doch eigentlich nur mit Tabulatoren gebaut, d.h. es gibt ein Problem, wenn man von einer Monospace-Schrift auf diese Schrift wechselt oder umgekehrt. Also nur wenn alle, die Quelltext austauschen wollen, diese neue Schrift nutzen würden, gäbe es kein Problem. Vielleicht ist Monospace doch nicht so verkehrt.

[R::bert]

Wie findet Ihr das komplexe g?

Schade, dass es die 0 nicht noch als normale Version (also mit »leerer« Punze) gibt.

(Ob man den Strang mit an den neuen Wiki-Artikel von Ralf heften sollte?)

[R::bert]

Vielleicht ist Monospace doch nicht so verkehrt.

 

Vielleicht ist dann dieser interessante Ansatz einen Blick Wert:

 

 

User von DSType

 

Hach … davon noch ’ne schöne, gut ausgebaute statisch-proportionale Groteskfamilie! 

 

[ThierryM]

ich habe gerade mal versucht, die input unter windows 7 in notepad++, einem texteditor, zu verwenden. dabei zeigt sich leider, dass die buchstaben in der jeweils obersten zeile oben abgeschnitten werden. schade – dann halt nicht und wieder zurück zur consolas. alle anderen festbreitenschriften zeigen dieses problem nicht.

 

wenn ich mal was in (pseudo-)monospace-optik gestalten will, könnte ich mir vorstellen, die input zu verwenden. als unsichtbare code-schriftart erscheint sie mir dagegen nicht besser als existierende festbreitenschriften. auffällig ist, dass sie ziemlich viel geschlossene formen aufweist, während in anderen – camingo code, consolas, fira mono, source code, ubuntu mono, um nur ein paar zu nennen – buchstaben wie ›a‹, ›C/c‹, ›e‹, ›G‹ oder ziffern wie ›1‹ und ›2‹ offener gestaltet sind. in 8 oder 10 punkt macht das in meinen augen einen unterschied zugunsten der offeneren formen. störend in der form finde ich, selbst in diesen kleinen größen, das komplexe ›a‹ (warum dieses schwänzchen?), das komplexe ›g‹ (sehr kleine obere punze), das ›ß‹ (einfach schlecht gezeichnet) und die geschwungenen klammern (unnötig aufdringlich).

[Sebastian Nagel]

Nach 3 Tagen Versuch (OSX Coda2 und Win Notepad++ / Sublime) bin ich jetzt zurück bei de Groots Consolas ...

 

Erst die nicht-diktengleichen Fonts probiert – sieht schön aus, aber das "geht" tatsächlich nicht, da habe ich gefühlt Text vor mir, keinen Code.

 

Dann die diktengleichen Sans in verschiedenen Weiten – die recht fein abstufbaren Weiten haben ja schon was, man spart Platz und bringt tatsächlich mehr auf den Schirm als mit einer breiteren Schrift.

 

Aber letztlich scheitert es bei mir an den geschlossenen Formen und der dadurch entstehenden Selbstähnlichkeit – dadurch sieht mein Code viel "muster/texturhafter" aus als in anderen Schriften und wird so schlechter lesbar.

 

Bleibt für mich die Anwendung übrig, wenn etwas nach "Code" aussehen soll, also eine Gestaltungs-Schrift, kein reines Werkzeug.

[Alexander Bürgin]

Mich würde die Font beim Coden stören. ich finde mansche Sachen müssen sich nicht ändern... Im web ändert schon genug ;)

 

ich finde das Schriftbild zu unruhig für eine coderfont... Diese müssen einfach nur funktional sein.

 

Ich danke als Hausschrift für einen Coder ginge das ganze noch eher, wenn mans mag...