Vorschlag für eine neue deutsche PC-Tastaturbelegung
Der Diplom-Informatiker Karl Pentzlin aus dem bayerischen Schongau beschäftigt sich intensiv mit Schriftzeichen, Unicode und deren Aufnahme in die Zeichensatz-Standards von ISO, DIN, IEC und Unicode. In seinem jüngsten Dokument schlägt er nun die Überarbeitung unserer Computer-Tastatur vor.
Die Ziele:
- Alle Namen sollen korrekt geschrieben werden können
- Alle in Deutschland gängigen Sprachen sollen korrekt geschrieben werden können.
- Jeder, der es will, soll »wie gedruckt« schreiben können
- Alles, was bisher funktionierte, soll unverändert weiter funktionieren
- Die Belegung soll den internationalen Normen genügen (ISO/IEC 9995)
Karl Pentzlin hat dem DIN-Ausschuss 2137, dem als Typograf der Leipziger Andreas Stötzner angehört, im letzten Monat dieses mehrseitige Konzept (PDF) vorgelegt.
16 Kommentare
Kommentarfunktion ist deaktiviert.
<em>kursiv</em> <strong>fett</strong> <blockquote>Zitat</blockquote>
<a href="http://www…">Link</a> <img src="http://bildadresse.jpg">
Kadir
Finde ich persönlich wirklich gut.
Wenn alles so bleiben soll wie bisher, würde ja auch nichts dagegen sprechen und es wäre viel einfach, typografisch richtiger zu schreiben ohne die ganzen Codes für die Sonderzeichen auswendig lernen zu müssen (ok, ich habe auch einen A4 Zettel an der Pinnwand).
Ich könnte mir vorstellen, dass die „ (hier: alt + 0132) Geschmacksbildung“ (und: alt +0147) was Typografie angeht, besser voran schreiten könnte, wenn man es den Schulklassen im IT-Unterricht (der immer öfter angeboten wird) leichter verständlich machen kann. Sonst geht man immer davon aus, das Zollzeichen wäre die richtige Wahl für die sog. Gänsefüßchen.
mren
Und warum nicht gleich Neo? http://www.neo-layout.org
Thomas Kunz
Och nö, da bleibe ich doch lieber bei meiner eigenen Tastaturbelegung (siehe pdf-Datei). Die finde ich viel logischer.
JoJo
Wenn schon, dann gehört für mich das große „ß“ nicht auf die „H“-, sondern auf die „ß“-Taste.
Karl Pentzlin (DIN NA 043-01-35-01 GAK)
@ Jürgen Siebert: Vielen Dank für die Erwähnung des Tastaturvorschlages. Dieser entspricht (zumindest in dem gezeigten Belegungsschaubild) tatsächlich dem aktuellen Diskussionsstand im DIN-Ausschuss NA 043-01-35-01 GAK (als „Belegung T2“; die „alte“ Tastatur wird weiterhin als „Belegung T1“ standardkonform bleiben).
(Nur der Korrektheit halber: Mit Andreas Stötzner bin ich über einen anderen DIN-Ausschuss verbunden; er ist nicht Mitarbeiter im Tastaturausschuss. Die genannten Unicode-Zeichencodierungsanträge für Fussball usw. sind angenommen; ich zähle dies nicht zu meinen wichtigsten Arbeiten.)
@ JoJo: Um das versale ß über den Kleinbuchstaben legen zu können, hätte man das „?“ umlegen müssen; damit wäre die Tastatur speziell für Blindschreiber umgewöhnungsbedürftig (deshalb die Entscheidung: vorhandene Zeichenbelegungen dürfen keinesfalls verändert werden). Das versale ß wurde daraufhin, um Verwechslungen speziell für Nicht-Deutschmuttersprachler vorzubeugen, bewusst weit entfernt fom Kleinbuchstaben-ß belegt.
@ Thomas Kunz: Die explizite Eingabe von Ligaturen ist nicht mehr Stand der Technik; deshalb sind auch in Unicode keine Ligaturen codiert, die über die Kompatibilität zu 8-Bit-Zeichensätzen (z.B. Mac) hinausgehen. Ligaturen sollen automatisch gesetzt werden, wenn die Grundzeichen eingegeben werden, und sind in der Schriftart hinterlegt (die dann auch weniger übliche Ligaturen wie z.B. „fj“ enthalten kann). Die aktuellen Versionen von Adobe Indesign und Quark XPress beherrschen dies, in Microsoft Word 2010 lässt sich dies über eine Option einschalten. Um „Schlaflager auf der Schilfinsel“ korrekt schreiben zu können, gibt es den Bindehemmer (auf AltGr+Punkt) zum Verhindern von automatischen Ligaturen.
Georg Seifert
Ein Problem mit diesen Vorschlägen ist, das am Mac die Alt (AltGr) Belegung schon seit vielen Jahren benutzt wird und viele von den geforderten Zeichen enthält (en-dash, alle Anführungszeichen …)
Crissov
Ich habe von ca. 2003 bis 2006 meine eigene Tastaturbelegung genutzt, aber nach dem Umstieg habe ich mir nie den Aufwand gemacht, sie bspw. mit Ukelele auf OS X zu portieren, weil dessen Standardbelegung meine meistgenutzten Zeichen bereits enthält.
Ich befürchte, dass Karl Pentzlin das Layout noch nicht von Benutzern hat testen lassen, denn einige Belegungen scheinen etwas seltsam bis kontraintuitiv. Für den Tastaturgebrauch kann man übrigens einige diakritische Zeichen zusammenfassen, die Unicode trennt, bspw. Cedille (samt Komma) und Ogonek, Brevis mit Caron und Punkt oben mit Ring, die in den relevanten Sprachen nie mit denselben Buchstaben kombiniert werden.
Karl Pentzlin (DIN NA 043-01-35-01 GAK)
Zunächst, das Layout ist keine Erfinung von mir, sondern das Ergebnis einer langfristigen Gremiumsarbeit (an der ich lediglich beteiligt bin). Das Layout muss u.a. internationalen Normen entsprechen (Reihe ISO/IEC 9995), in denen beispielsweise sowohl die Belegung als auch die Ansteuerung der Gruppe 2 festgelegt ist (die Zeichen, die in der Abbildung rechts oben auf den Tasten erscheinen).
Für den deutschen Standard stand nur die AltGr-Belegung („Ebene 3 der Gruppe 1“) zur Disposition, wobei ISO/IEC 9995 aus gutem Grund Kombinationen „AltGr + Shift + dritte Taste“ nicht ohne weiteres zulässt.
Für die AltGr-Belegung ist die Motivation für die einzelnen Zeichen in der eingangs schon erwähnten PDF-Datei nachzulesen.
Die von Crissov vorgeschlagene Zusammenfassung von diakritischen Zeichen funktioniert nicht (z.B. s mit Cedille im Türkischen, s mit Komma im Rumänischen).
Die hier mehrmals angesprichene Mac-AltGr-Belegung bot sich aus mehreren Gründen nicht zur Übernahme als Standard an (weder vom Zeichenvorrat, noch von ihrer Struktur, noch von der Verbreitung ihrer Anwendung unter „Normalverbrauchern“).
Crissov
Auf dem Mac gibt es zweimal Alt, kein AltGr, aber tatsächlich sind die damit erreichbaren Zeichen (der MacRoman-Satz) weder optimal gewählt noch optimal verteilt. Dafür gibt es eine klare Unterscheidung zwischen Tasten für Befehle (⌘/Apfel/Cmd und z.T. ^/Strg/Ctrl) und solchen für Zeichen (⎇/Alt, ⇧/Shift und ⇪/Shift-Lock).
Man kann sehr wohl Tottasten kombinieren, denn Tastaturen sind Texteingabegeräte und nicht Textkodiergeräte. Man stelle sich vor, Handschrifterkennungssysteme wären so restriktiv wie Tastaturen!
Dass das Komma ein anderes Akzentzeichen als die Cedille ist, war und ist selbst im Unicode-Konsortium umstritten – wenn ich mich recht an entsprechende Erzählungen entsinne, haben die rumänischen Vertreter damals eher aus politischen, nationalistischen Gründen darauf bestanden, diesen Glyphenunterschied zu einem Zeichenunterschied zu machen, aber große Teile der Sprachgemeinschaft ignorieren das weiterhin. Eigentlich wären die (Open-Type-)Schriften dafür zuständig, die Unterscheidung zu gewährleisten, aber da (nicht nur) dieses Kind in den Brunnen gefallen ist, müssen sich jetzt so oder so die Betriebssysteme und Textverarbeitungsprogramme/-komponenten um die normalisierte Kodierung kümmern. (Dass sie das auch bei typographischen Interpunktionszeichen tun, ist ein ähnliches, aber anderes Thema.)
Für einen deutschen Benutzer bzw. einen Benutzer in Deutschland ist diese Unterscheidung also selbst dann irrelevant, wenn er einen rumänischen Namen hat oder schreiben will. Ähnliches gilt bspw. fürs (kleine) Eth in Unterscheidung zu einem ›D‹ mit Querstrich.
Damit wird die eigentlich gute Idee, die und Akzente oben und unten spatial kompatibel in unterschiedlichen Tastenreihen anzuordnen, ziemlich hinfällig – wobei einem das ›G‹ mit Cedille ohnehin schon ein wenig in die Parade fährt und die ganze Analogie zu schwanken beginnt, wenn man bedenkt, dass eigentlich der Durchstrich in die Mitte gehörte.
Natürlich sollte ein Standard kompatibel zu anderen Standards sein, dafür gibt es sie ja, aber damit ein Standard akzeptiert wird, muss er vor allem für die Anwender gemacht sein, und das sind hier nicht die Computerperipheriehersteller, sondern wir, die Tipper. Für die ist die Länge eines horizontalen Überstriches ziemlich egal und wenn die paar Buchstaben, die in europäischen Orthographien einen Querstrich haben können (›L‹, ›H‹, ›T‹, ›D‹ und die Ziffer ›0‹ für die leere Menge) von denen mit Makron o.ä. (›A‹, ›E‹, ›I‹, ›O‹, ›U‹) distinkt sind (wie hier oft Konsonanten vs. Vokale), dann kann und sollte man das zusammenlegen – wobei es in diesem Fall tatsächlich noch die skandinavische Form des ›Ö‹ gibt, die als ›Ø‹ geschrieben wird und deswegen eine eigene Tastenkombination oder sprachabhängige Behandlung bräuchte. Anderenfalls wird die Belegung zu komplex, um von Menschen genutzt zu werden. Für einen türkischen Namen ist es auch kein Problem, dieselbe Tottaste für das Hinzufügen bzw. Entfernen des Punktes vom »normalen« ›I‹ zu verwenden. Es erfordert hingegen Mentalakrobatik, das große Eszett nicht auf der Taste rechts neben der Null oder das lange abseits des runden ›s‹ zu suchen.
Wahrscheinlich ist es auch einfacher, für einen Doppelakut (v.a. im Ungarischen) zweimal die ›´‹-Tottaste vor dem ›O‹ oder ›U‹ zu drücken, als dafür eine eigene Kombination einzuführen. Das mag allerdings mit manchen Tastaturtreibern Probleme bereiten. Analog könnte man sich vorstellen, Hatschek und Zirkumflex aus zwei Tastendrücken links neben der Löschtaste zusammenzubauen, aber letzteren gibt es ja schon am gegenüberliegenden Ende dieser Tastenreihe.
Übrigens kann man umgekehrt von den Menschen nicht unbedingt erwarten zu wissen, dass das was wie ein Apostroph neben ›d‹ oder ›t‹ aussieht, eigentlich ein Hatschek ist. Deswegen sollte bspw. auch die Tastenfolge »´d« ein ›ď‹ (U+010F) ergeben.
Falls das ganze mal ein DIN-Standard und von Apple unterstützt wird, hoffe ich, dass sich ⇨ auch auf die ⇪-Taste legen lässt, die kein Mensch braucht, nichtmal motorisch Behinderte.
Thomas Kunz
@ Karl Pentzlin (Kommentar Nr. 5):
In OT-fähigen Programmen benötige ich die Ligatur-Tasten auch nicht. Aber manchmal tippt man ja auch in einen nicht-OT-fähigen Editor – wie zum Beispiel jetzt gerade.
Simon Wehr
Seid OpenType habe ich niemals Ligaturen selber eingetippt. Höchstens mal aus typografischer Spielsucht per Glyphentabelle. Für Weblogkommentare finde ich Ligaturen ehrlich gesagt überbewertet. Und falls nicht: Auch hier sollte sich die Textcodierung anpassen, nicht die Texteingabe.
Matthäus
das einzige was mir an einer neuen tastatur wichtig wäre ist, dass statt die belegung von # und @ vertauscht wird.
Johannes
Eine sehr gute Idee, endlich alle lateinisch geschriebenen Sprachen ohne viel Mühe schreiben/tippen zu können. Vielleicht habe ich ja Tomaten auf den Augen, doch finde ich dem polnischen kreska nicht, der gerne — äh: häufig — der häufig mit einem Akut verwechselt wird, vgl. Adam Twardochs Hinweise und Erläuterungen.
Vielleicht ist es ja auch anachronistisch, weil es halt „immer“ falsch gemacht wird und also inzwischen richtig ist. Aber wenn das lange s dabei ist, sollte dann der Vollständigkeit halber nicht auch der dabei sein?
Johannes
Karl Pentzlin (DIN NA 043-01-35-01 GAK)
Zum polnischen Kreska: Leider wird in Unicode zwischen Akut und Kreska nicht unterschieden, sodass eine Unterscheidung auf der Tastatur verwirrend wäre, da beide Eingaben zum gleichen Zeichen führen würden. (Dies ist nicht das einzige Detail in Unicode, das dort aus tyografischer Sicht unbefriedigend gelöst ist – man wird damit leben müssen, sowohl wegen der „stability policies“ in Unicode, als auch wegen des Umgangs mit solchen Details im derzeitigen Unicode Technical Commitee.)
Johannes
Moin Karl,
vielen Dank für die Aufklärung!
Johannes
Christoph Päper
Beim Kreska hat man es im Unterschied zum Ogonek richtig gemacht. Das exakte Aussehen von Diakritka ist genauso wie bei den Grundbuchstaben genuine Aufgabe der Fonts, die entsprechende Sprach- und Kulturabhängigkeiten unterstützen sollten. Das Problem an der Stelle ist das Zuordnen von Text (durch Heuristik oder Marken ) zur richtigen Sprache (und ggf. Kultur).
Wenn es keine Orthographie gibt, die sowohl Akut als auch Kreska mit demselben Basisbuchstaben verwendet, sie also unterscheidet, dann gibt es aus lingusitischer und mithin ergonomischer (d.h. tastaturgestalterischer) Sicht keinen Grund, sie getrennt zu behandeln.
Auf Ebene der Kodierung (d.h. Unicode) kann man hingegen etwas besser darüber streiten, ob nur bedeutungsdifferenzierende Zeichen (zu finden per Minimalpaaranalyse) behandelt werden müssen oder auch graphische Varianten: das lange »s« ist bspw. ein Grenzfall – eigtl. sollte es nicht explizit eingegeben werden, sondern (bei entsprechendem aktiviertem OT-Feature) von den Schriften in Abhängigkeit von Sprache sowie mithilfe von ZWNJ (»Bindehemmer«) automatisch gesetzt werden.
Ich finde übrigens (etwas im Gegensatz zum Unicode-Konsortium), man sollte bei den vorgefertigten (»precomposed«) Buchstaben auf Zusammenlegung (»unification«) setzen und bei den kombinierenden diakritischen Zeichen (v.a. U+0300–6F) sowohl die spezielle Auswahl als auch diverse generellere Angaben ermöglichen.