Neue OT-Frakturschrift gratis

  • Hallo,


    um die OpenType-Schriften zu fördern, habe ich eine neue programmierte OT-Schrift zum kostenlosen Herunterladen ins Netz gestellt:


    die "Offenbacher Schwabacher". Ich freue mich, wenn Ihr sie schön findet.


    Herunterzuladen von:


    www.fraktur.biz

  • Sehr schön! Die Eingabe funktioniert, wie bei den anderen Helzel-OT-Schriften, meistens automatisch richtig. In den Fällen, wo die Automatik ein langes ſ setzt, aber eigentlich ein rundes s hingehört, kann das runde s mit einem ZWNJ erreicht werden (z.B. Ischia, Wachstube); in den umgekehrten Fällen, wo die Automatik ein rundes s setzt, aber eigentlich ein langes ſ hingehört, kann das lange ſ durch die manuelle Eingabe von „ſ“ erreicht werden (z.B. Iſlam, Aſbeſt).


    Was ist eigentlich der Grund, dass Ligaturen der Helzel-OT-Schriften nicht gemäss UNZ1 kodiert sind? Die OT-Ligaturen lassen sich ja eigentlich problemlos mit der UNZ1-Kodierung vereinbaren.

  • Auch von mir vielen Dank für die weitere kostenlose Schrift!


    Was ist eigentlich der Grund, dass Ligaturen der Helzel-OT-Schriften nicht gemäss UNZ1 kodiert sind? Die OT-Ligaturen lassen sich ja eigentlich problemlos mit der UNZ1-Kodierung vereinbaren.


    Das Thema hatten wir hier doch schon öfter? OpenType-Verbünde auf Codeplätzen abzulegen ist eben nicht unproblematisch und widerspricht dem OpenType-Prinzip.

  • Das Thema hatten wir hier doch schon öfter?


    Tatsächlich? *such such* Aha, du hast diese Meinung wirklich schon ein andermal vertreten, nämlich im Thread Norm UNZ-1 Unicode gerechte Norm für Fraktur-Zusatzzeichen.


    Das überzeugt mich allerdings nicht. Gut, es mag gewisse, fehlerhafte Programmen zum Erstellen von PDFs geben, wo durch solche Schriften vielleicht ein Nachteil entsteht. Das ist aber ganz klar ein Fehler an diesen Programmen, denn gemäss Unicode-Normalisierung sollte so etwas auf keinen Fall passieren. Gegenüber diesem allfälligen Nachteil liegt jedoch der Vorteil auf der Hand: Ein- und dieselbe Schrift kann den UNZ1-Empfehlung genügen und gleichzeitig auch OpenType-Ligaturen aufweisen. Das halte ich doch für einen ziemlich entscheidenden Vorteil, der den von dir genannten allfälligen Nachteil deutlich überwiegt (es sei denn, du lehnst UNZ1 grundsätzlich ab).


    Die Autoritäten, die du im von mir genannten Post argumentierst, würden mich genauer interessieren. Wo sprechen sich Unicode, Microsoft und Adobe dagegen aus, dass in OpenType-Ligaturdefinitionen auf Ligaturen aus der PUA oder auf ff, fi, fl, ffi, ffl, ſt, st verwiesen werden sollte? Diesen Spieß kann ich übrigens mit Leichtigkeit umkehren, denn zumindest Adobe und Microsoft (Unicode produziert keine Schriften) verwenden ebendiese Charaktere in den OpenType-Ligaturdefinitionen ihrer eigenen Schriften (nachgesehen habe ich in Adobe Caslon Pro, Adobe Garamond Pro, Calibri – immerhin die Default-Schrift in Microsoft Word! – und Gabriola). Ferner tun das auch Apple und Ubuntu in ihren jeweiligen Systemschriften (Lucida Grande und Ubuntu). Wenn es diese großen Font-Anbieter tun, dann kann es ja wohl nicht derart problematisch oder widersprüchlich sein, wie du behauptet hast.

  • Nein, es ist kein Fehler der Programme, sondern kann durchaus ein gewünschtes Verhalten sein, siehe das Beispiel mit der ² in meinem alten Beitrag.


    Lediglich aus Kompatibilitätsgründen behalten Hersteller die codierten Verbünde in alten Schriften bei. Man will dadurch verhindern, daß alte Dokumente, die mit früheren Fassungen einer Schrift unter Verwendung codierter Verbünde erstellt wurden, unbrauchbar werden, wenn jemand eine neuere Schriftversion installiert, die keine codierten Verbünde mehr enthält. Hier kann man einen Weblog-Beitrag dazu von einem Adobe-Mitarbeiter lesen:


    http://blogs.adobe.com/typblog…6/05/eliminate_priva.html


    Dort wird auch Adobes Meinung zum Unicode-Privatbereich erwähnt:

    Zitat

    We’ve been saying for several years at least that if we had it to do over again, we would not encode anything in PUA except for dingbats and the like. If we change it even in already shipping fonts, we’re sending a strong signal to other font developers, and not doing it kind of undermines the message that it’s a bad idea.


    Wenn Du möchtest, werde ich versuchen, noch weitere Verweise herauszusuchen.

  • Nein, es ist kein Fehler der Programme, sondern kann durchaus ein gewünschtes Verhalten sein, siehe das Beispiel mit der ² in meinem alten Beitrag.


    Du hast recht, bei der ‹²› mag das sinnvoll sein. Als generelle Regel schafft aber ein derartiges Verhalten allerlei Unvorhersehbarkeiten, besonders bei Ligaturen. Ein vernünftiges Programm sollte sich also besser an den Unicode-Standard halten, der solche Fälle mittels ausführlicher Normalisierungsregeln abdeckt. Dort ist ausführlich festgelegt, in welcher Art und Weise gewisse Charaktere zur besseren Verständnis in andere umgewandelt werden. So sollte etwa die Ligatur ‹st› für Suchfunktionen etc. gleich behandelt werden wie die Sequenz ‹st›.


    Lediglich aus Kompatibilitätsgründen behalten Hersteller die codierten Verbünde in alten Schriften bei.


    Ach wo, Calibri und Gabriola sind neue Schriften, extra für Microsoft Office 2007 bzw. für Windows 7 geschaffen.


    Aber deine Argumentation (und die von Adobe) zielt ja überhaupt nicht auf eine generelle Ablehnung von „kodierten Verbünden“ in OpenType-Regeln, sondern lediglich von PUA-Ligaturen. Das dünkt mich schon eher nachvollziehbar. Im Gegensatz dazu stehen die in Unicode standardisierten Ligaturen, gegen deren Verwendung in OpenType-Regeln nichts einzuwenden ist.


    Aus deiner Argumentation folgert allerdings keine Unvereinbarkeit von OpenType-Ligaturen und der UNZ1-Empfehlung. Das ist ein Fehlschluss. Eine Schrift kann beispielsweise zwei Kopien der tz-Glyphe enthalten, eine in der PUA gemäß UNZ1-Empfehlung, und eine zweite ohne Unicode-Nummer zur Verwendung in OpenType-Regeln.


    Der einzige Grund, der gegen eine Vereinbarkeit von UNZ1 und OpenType-Ligaturen spricht, ist die grundsätzliche Ablehnung von UNZ1. Solange man aber UNZ1 nicht grundsätzlich ablehnt, spricht nichts dagegen, dass eine OpenType-Schrift wie Helzels Offenbacher Schwabacher gleichzeitig auch UNZ1 unterstützt.

  • Du hast recht, bei der ‹²› mag das sinnvoll sein. Als generelle Regel schafft aber ein derartiges Verhalten allerlei Unvorhersehbarkeiten, besonders bei Ligaturen. Ein vernünftiges Programm sollte sich also besser an den Unicode-Standard halten, der solche Fälle mittels ausführlicher Normalisierungsregeln abdeckt. Dort ist ausführlich festgelegt, in welcher Art und Weise gewisse Charaktere zur besseren Verständnis in andere umgewandelt werden. So sollte etwa die Ligatur ‹st› für Suchfunktionen etc. gleich behandelt werden wie die Sequenz ‹st›.


    Was Programme tun sollten und was sie tun sind zwei verschiedene Dinge. UNZ1-Verbünde sind doch größtenteils PUA-Verbünde! In Unicode ist nicht festgelegt, wie diese aufzulösen sind.


    Ach wo, Calibri und Gabriola sind neue Schriften, extra für Microsoft Office 2007 bzw. für Windows 7 geschaffen.


    Du nennst Microsoft-Schriften. Es kann gut sein, daß ich mich geirrt habe, und Microsoft nicht dieselbe Meinung vertritt wie Adobe.


    Aber deine Argumentation (und die von Adobe) zielt ja überhaupt nicht auf eine generelle Ablehnung von „kodierten Verbünden“ in OpenType-Regeln, sondern lediglich von PUA-Ligaturen. Das dünkt mich schon eher nachvollziehbar. Im Gegensatz dazu stehen die in Unicode standardisierten Ligaturen, gegen deren Verwendung in OpenType-Regeln nichts einzuwenden ist.


    Meine Argumentation zielt sehr wohl auf die generelle Ablehnung von codierten Verbünden. Ich kann Dir auch mehrere Gründe dafür nennen:


    • Unicode definiert (nach neuer Auffassung) nur noch Grapheme (characters), also die kleinsten bedeutungstragenden Schrift-Einheiten. Nur diese erhalten somit einen Code. Verbünde werden durch ihre Einzelbuchstaben codiert. Eine zusätzliche Code-Zuweisung an Verbünde wäre damit redundant und widerspräche der Unicode-Logik.
    • Codierte Verbünde verleiten den Anwender dazu, die Verbünde über ihren Code einzusetzen (z.B. über Zeichenauswahlfenster o.ä.), was dazu führt, daß Text nicht mehr durchsucht werden kann usw. (Dieses Fehlverhalten ist ja wohl auch der einzige Grund, warum überhaupt codierte Verbünde gefordert werden!)
    • Es ist gerade der Witz an OpenType in Verbindung mit Unicode, daß jede Schrift beliebige Verbünde enthalten kann, die in der Schrift selbst definiert sind. Codierte Verbünde erfordern dagegen Regeln, wie diese Verbünde behandelt werden, beispielsweise bei der Umwandlung in ein nicht OpenType-fähiges Format wie PDF (siehe oben). Damit kann immer nur eine eingeschränkte Zahl an Verbünden berücksichtigt werden, und jedes einzelne Programm muß die Regeln für jeden einzelnen Verbund umsetzen.


    Aus deiner Argumentation folgert allerdings keine Unvereinbarkeit von OpenType-Ligaturen und der UNZ1-Empfehlung. Das ist ein Fehlschluss. Eine Schrift kann beispielsweise zwei Kopien der tz-Glyphe enthalten, eine in der PUA gemäß UNZ1-Empfehlung, und eine zweite ohne Unicode-Nummer zur Verwendung in OpenType-Regeln.


    Klar ginge das. Die beiden ersten der drei genannten Punkte bleiben jedoch bestehen.


    Der einzige Grund, der gegen eine Vereinbarkeit von UNZ1 und OpenType-Ligaturen spricht, ist die grundsätzliche Ablehnung von UNZ1. Solange man aber UNZ1 nicht grundsätzlich ablehnt, spricht nichts dagegen, dass eine OpenType-Schrift wie Helzels Offenbacher Schwabacher gleichzeitig auch UNZ1 unterstützt.


    Ich lehne die UNZ1 nicht grundsätzlich ab. Sie kann aber nicht mehr sein, als eine Notlösung für Anwender, die aus irgendwelchen Gründen OpenType-Funktionen nicht benutzen können. Für diese Anwender kann man getrennt UNZ1-Schriften bereitstellen. OpenType-Schriften für alle anderen Anwender sollten jedoch sauber aufgebaut sein, und nicht irgendwelche Notlösungen, Altlasten und Redundanzen mitschleppen.

  • Meine Argumentation zielt sehr wohl auf die generelle Ablehnung von codierten Verbünden. Ich kann Dir auch mehrere Gründe dafür nennen:


    OK, ist ja gut. Aber du wirst schon zugeben, dass eine Schrift, falls sie denn ein Unicode-definierte Zeichen wie U+FB02 LATIN SMALL LIGATURE FL (‹fl›) enthält, dieses Zeichen dann auch problemlos in OpenType-Regeln verwenden kann. Keines deiner Argumente spricht dagegen (sie sprechen bloß grundsätzlich gegen solche Zeichen).


    Ich halte es übrigens für äußerst unwahrscheinlich, dass beim Schriftdesign jetzt und in Zukunft gemäß deiner Argumentation auf die Zeichen ‹fl› und ‹fi› verzichtet wird, und zwar aus dem einfachen Grund, dass diese beiden Zeichen zum Standard-Mac-Zeichensatz gehören und auf der Standard-Mac-Tastatur zu finden sind. Ein Verzicht auf diese beiden bedeutet also einen merklichen Verlust an zu erwartender normaler Funktionalität. Und, wie gesagt, wenn nun diese Zeichen halt einmal in einer Schrift vorhanden sind, dann spricht eben nichts dagegen, sie auch in OpenType-Regeln zu verwenden.


    Ich lehne die UNZ1 nicht grundsätzlich ab. Sie kann aber nicht mehr sein, als eine Notlösung für Anwender, die aus irgendwelchen Gründen OpenType-Funktionen nicht benutzen können. Für diese Anwender kann man getrennt UNZ1-Schriften bereitstellen. OpenType-Schriften für alle anderen Anwender sollten jedoch sauber aufgebaut sein, und nicht irgendwelche Notlösungen, Altlasten und Redundanzen mitschleppen.


    Du hast ja schon recht, dass die Unicode-Logik für die Aufnahme neuer Zeichen nur noch Charaktere zulässt. Es gehört aber auch zur Unicode-Logik, dass eine fortwährende Kompatibilität mit älteren Standards gewährleistet wird. Insofern gehören eben auch Altlasten und Redundanzen wie das Zeichen U+FB02 (‹fl›) zu Unicode.


    Darüber hinaus gehört auch die PUA zu Unicode, und Unicode erwähnt ausdrücklich, der Gebrauch der PUA-Zeichen „may be determined by private agreement among cooperating users“ (The Unicode Standard, Version 6.0, S. 533). Auch das ist also ein Teil der Unicode-Logik. Ich stimme dir zwar zu, dass die UNZ1-Ligaturen problematisch sein können. Aber die Verdoppelung der Schriftversionen, die du vorschlägst (Normalversion ohne UNZ1, Spezialversion mit UNZ1), ist mindestens ebenso problematisch. Zumal sind bei der Verdoppelung der Schriftversionen die Probleme viel unmittelbarer und konkreter, denn schon nur beim Download muss man sich zwingend für eine der beiden Versionen entscheiden, wohingegen die von dir genannten Probleme mit den UNZ1-Ligaturen sich nur unter ganz bestimmten Bedingungen ergeben, nämlich bei Ligatureinfügung per Zeichenpalette, Ligafaktur o.ä. oder aber beim Durchsuchen eines mit bestimmten Programmen erstellten PDFs (Durchsuch-Probleme ergeben sich allerdings auch mit Schriften ohne UNZ1, wenn ein Programm nicht mit dem ZWNJ umzugehen weiß).


    Und schließlich finde ich, dass deine Forderung nach Schriftverdoppelung auch zu dem falschen Eindruck beiträgt, OpenType und UNZ1 wären unvereinbar. OpenType und UNZ1 sind aber problemlos vereinbar; eine UNZ1-Schrift kann ebensosehr von OpenType-Ligaturen profitieren wie eine Schrift ohne UNZ1.

  • Irgendwie habe ich genau diese Disskussion hier schon vor gut 2Jahren durch - und das hat bei mir dazu geführt, dass icgh meine Frakturschriften zunächst einmal nur in UNZ1-Variantew anbiete, da ich so den größeren Nutzerkreis erreichen kann, da ich damals schon nicht gegen dieArgumemte sowohl der OpenType-Fraktion ankam, die auf nicht codierte ligaturen bestanden, um so eine Mischnutzung mit gestörter Durchsuchbarkeit zu begegnen - und eben den UNZ1-Anhängern, die aus nicht unähnlichen Gründen und genau so nachvollziehbaren Grübden eine OpebnType-Funktionalität in Schriften mit codierten Verbünden ablehnen, oder nach anfänglicher erstellung solcher Schriften eben wieder zu einer getennten Behandlung mit doppelten Schriften gewechselt sind.


    Trotz allen durchaus richtigen Argumenten bin ich nach wie vor eigentlich trotz allem Liebhaber einer Kombination aus OpenType-Funktionalität UND im PUA codierten Verbünden nach UNZ1 und dan auch Verwendung dieser Glyphen anstatt der Verwendung von doppelt angelegten Glyphen, einmal codiert für nicht Opentype-nutzer undeinmal nicht codiert, aber in OpenType-Tables refrerenzierten Glyphen. und dashat folgenden Grund:


    Reinrassige und saubere Unicode-Opentye-Schriften ohne codierte Verbünde lassen sich heute praktisch nur mit den Produkten des Lehmziekel-Software-Herstellers nutzen. OK, ist der Hauptanbieter im bereich kommerzieller Nutzung, aber trotzden eben nur ein recht beschränkter Nutzerkreis. Nahezu alle andeen Programme, diebehaupten Opentype-Schriftarten zu unterstützen, beachten, wenn überhaupt - nur wenige OpenType-Tables ober sagen damit lediglich, das sie Glyphen oberhalb der Ansi-Norm verwenden können. Das Gros der Nutzer hat dann überhaupt keine Ahnung, welche Glyphen da in der Schrift drin stecken, und wie viel Mühe sich der Schriftengestalter mit Verbünden gemacht hat, er sieht sie schlicht nicht. und dann wird trotz angeblicher OpenType-Kompatibilität des Programms der Text ohne Verbündeausgegeben.


    Ähnlich bei reinrassigen UNZ1-Schriften. Hier sehen wieder die Nutzer von Software die Opentype unterstützt nicht die notwendigkeit, sich um die andere Version der Schrift zu kümmern, und setzen diese dann ganz selbstverständlich in ihrem Programm ein. da sie jetzt aber gewohnt sind, das sich ihr Programm richtig um Verbünde kümmert, kommt höchstens der Gedanke: "Schade! kein verbünde drin" und die Überrachung ist dann groß, wenn man diesen Nutzer dann an die Zeichentabelle erinnert.


    Auch nehme ich natürlich mit reinen UNZ1-Schriften den Druck bei den Software-Entwicklern weg, überhaupt OpenType-Funktionalität in ihre Programme ein zu bauen.


    Ich fürchte nur, eine Lösung wird es auch in vielen Jahren nicht geben, der leidtragende ist der Nutzer dieser Schriften

  • … und eben den UNZ1-Anhängern, die aus nicht unähnlichen Gründen und genau so nachvollziehbaren Grübden eine OpebnType-Funktionalität in Schriften mit codierten Verbünden ablehnen …


    Ich kenne keine Gründe, die bei UNZ1 gegen eine Verwendung von OpenType sprechen würden.


    Reinrassige und saubere Unicode-Opentye-Schriften ohne codierte Verbünde lassen sich heute praktisch nur mit den Produkten des Lehmziekel-Software-Herstellers nutzen.


    Du meinst Adobe, nehme ich an? Das mag vor zwei Jahren gestummen haben, aber das hat sich mittlerweile geändert: Firefox 4 weist eine vorbildliche Unterstützung von OpenType auf, und das soll immerhin der im deutschen Sprachraum meistverwendete Browser sein. Da mittlerweile eine starke Konkurrenz zwischen den verschiedenen Browsern herrscht, ist die Hoffnung nicht unbegründet, dass auch die anderen Browser in nicht allzu ferner Zukunft nachziehen. Sogar Microsoft Word kann mittlerweile ein wenig OpenType, das freie Textverarbeitungsprogramm AbiWord kann es aber deutlich besser.

  • Das mag vor zwei Jahren gestummen haben, aber das hat sich mittlerweile geändert:


    Nun ja, Firefox ist schon ein positives Beispiel, Abiword war schon damalsrecht gut nutzbar, wenn auch nicht wirklich perfekt und die Fähigkeiten von MS Word buche ich immer noch unter "angeblich" an, denn da wird gerade das unterstützt, was Kleinstweich so glaubt, mindestens haben zu müssen, so richtig klappt das mit den Ligaturen aber nicht, Schaut man aber in die wichtigsten Text und Satzprogramme wird es neben Adobe - ja die meinte ich mit Lehmziegel - wird es traurig. in Canada scheint man von OpenType nichts gehört zu haben, so ist bei den Wagenburg-Leuten (Corel) nichts zu merken, Ebenso kennt der schnelle Weißkäse (Quark) kein Opentype. und in der OpenSource-Ecke, wo es ja sonst immer recht innovativ zu geht, kennt weder Gimp, Scribus noch OpenOffice.org/LibreOffice/Lotus Symphony wie man mit OpenType umgeht. Wiedas bei den Programmen für den angeknabberten Apfel aussieht, weiß ich allerdings nicht zu sagen. ein Abiword allein, das auch nur spezies kennn, macht noch lange keinen OpenType-Frühling

  • Ich stimme dir zu, was Textverarbeitungsprogramme angeht, sieht es noch nicht besonders gut aus. Heute habe ich selber zum ersten Mal eigene Tests mit Microsoft Word durchgeführt, und siehe da, es verhält sich noch schlechter, als ich befürchtet hatte: Die Ligaturen erscheinen einzig und alleine in der Vorschau, die in der Charakter-Dialogbox enthalten ist. Im Gegensatz zu dieser Vorschau zeigt das eigentliche Dokument hingegen keine Ligaturen. Sehr, sehr ärgerlich! Die Dialogbox macht also gewissermaßen ein falsches Versprechen und gaukelt eine Ligaturumsetzung vor, die dann aber im eigentlichen Dokument gar nicht gegeben ist. Ich fühle mich veräppelt.


    In Open- bzw. LibreOffice sieht es nicht ganz so schlecht aus. Zwar werden keine OpenType-Ligaturen unterstützt, dafür funktionieren aber (je nach Betriebsystem) Graphite- oder AAT-Ligaturen. Sperren funktioniert aber nicht korrekt, so dass sich ein ähnliches Gesamtbild ergibt wie bei AbiWord, wo Sperren überhaupt nicht möglich ist.


    Textverarbeitungsprogramme sind das eine. Was hingegen Browser angeht, so sieht es eben dank Firefox viel besser aus. Das Fazit ist, dass je nach Anwendungsgebiet die OpenType-Ligaturen bereits eingesetzt werden können: Im Internet sind sie gut einsetzbar; in der Textverarbeitung hingegen nur eingeschränkt. Daher sollte man, denke ich, auf alle Fälle die OpenType-Unterstützung propagieren, sei es nun bei UNZ1-Schriften oder bei anderen (wie der OffenbacherSchwab OT, um die es hier ja geht).


    Und weil es so schön ist, hänge ich einen kleinen Screenshot an, der das Forum hier in OffenbacherSchwab OT zeigt (eine kleine Spielerei mit der CSS-Bearbeitungsfunktion der Firefox-Erweiterung Web Developer, indem ich den folgenden zusätzlichen CSS-Code eingefügt habe: „ * { font-family: OffenbacherSchwab OT !important;} “). Man beachte insbesondere die völlig korrekt dargestellten langen ſ und die korrekten Ligaturen!


    Das bringt mich übrigens auf einen Mangel von OffenbacherSchwab OT: Korrektes Sperren ist in dieser Schrift nicht möglich – beim Sperren werden sämtliche Ligaturen aufgelöst.

  • Das mit dem Sperren scheint allgemein ein riesiges Problem zu sein, denn auch bei Adobe funktioniert das nicht richtig. Immer wenn eine bestimmte Sperrung eingestellt wird, zerfallen nicht nur die Ligaturen, sondern die Durchsuchbarkeit ist auch zum Teufel, da alle Software, die ich damit geprüft habe eben doch Spartien in Form von Leerzeichen in das gesperrte Wort einfügt. Manchmal sind das dann noch nicht einmal umbruch-verhindernde Leerzeichen, so dass ein gespertes Wort an irgendeiner Stelle getrennt wird - sehr Ärgerlich!


    Ebenso sieht das so aus, als müsse man, wen man seine Schrift auf mögklichst vjeler Software nutzbar zu machen nicht nur die codierten Ligaturen derin haben, sondern auch noch die Tables von drei verschiedenen Smartfont-Systemen einbauen (OpenType, Graphite und AAT) - ein gerade für Freefonts unzumutbarer Aufwand, ohne die Garantie, das es hinterher dann auch überhaupt eingesetzt werden kann.


    Was dasSperr-Problem angeht: Auch wenn ich hier bei Schriftpuristen einiges an Gegenwind erleben musste ist meine Lösung folgende:


    Gerade bei Frakturschriften ist sperren ja die Auszeichnungsart die an stelle der Kursiv-Stellung tritt, da man ja Frakturschriften, bisauf wenige Ausnahmen nicht kursiv setzten sollte (und schon gar nicht durch Schrägziehen).
    Also habe ich an Stelle eines kursiven Schnittes einen gesperrten erzeugt, und erreiche damit nicht nur, das man meine Schrift nicht kursiv verbiegt, sondern dass die Ligaturen dann richtig behandelt werden, also die Zwangsaligaturen nicht aufgelöst, die anderen aufgelsperrt werden (obwohl sie als "Ligatur" eine Glyphe bleiben. Würde ich diesüber OpenType dan machen, bliebe die Sperrung auch durchsuchbar.

  • Das mit dem Sperren scheint allgemein ein riesiges Problem zu sein, denn auch bei Adobe funktioniert das nicht richtig.


    In Firefox funktioniert es wenigstens mit den Schriften von Google völlig korrekt, und auch durchsuchbar (sie gehen auf deine eigenen Schriften zurück, nicht wahr?).


    Ebenso sieht das so aus, als müsse man, wen man seine Schrift auf mögklichst vjeler Software nutzbar zu machen nicht nur die codierten Ligaturen derin haben, sondern auch noch die Tables von drei verschiedenen Smartfont-Systemen einbauen (OpenType, Graphite und AAT) - ein gerade für Freefonts unzumutbarer Aufwand, ohne die Garantie, das es hinterher dann auch überhaupt eingesetzt werden kann.


    Auch das tun die Schriften von Google, und da sie nicht nur gratis, sondern auch frei sind, kann man diese Lösung ja für andere Schriften einfach übernehmen.

  • Leute!


    Das Gros der Frakturschreibenden arbeitet auf dem heimischen Rechner. Die erstellten Dokumente werden ausgedruckt und/oder untereinander elektronisch zur Weiterbearbeitung ausgetauscht. Mit InDesign oder Express arbeitet da kaum einer. Von OpenOffice.Org nimmt man Abstand, weil diese Anwendung eben keine vernünftige Rechtschreibprüfung in „bewährter“ Rechtschreibung aufweist. (Dies ist von der OpenOffice.Org Gemeinschaft offensichtlich so gewollt.) Da hinter LibreOffice zum Teil dieselben Leute stehen, ist wohl nicht davon auszugehen, daß sich dort in naher Zukunft etwas zum positiven ändert.


    Zur Anwendung wird von den allermeisten Frakturschreibenden Microsoft Word herangezogen, und dies in Versionen deren Veröffentlichung Generationen zurückliegen. Der Grund nicht auf eine aktuelle Version zu aktualisieren, dürfte auch hier die Sorge um die Rechtschreibprüfung sein. Obwohl sich in den Einstellungen der aktuellen Wordversion diese Prüfung auf „Normale“ Schreibung setzen läßt, geht das hartnäckige Gerücht um, diese Unterstützung gäbe es in neueren Versionen nicht mehr.


    Es braucht Schriften „die das gesetzte“ nicht verändern wenn das Dokument in einer anderen Anwendung (dies kann schon ein Versionensprung sein) geöffnet wird. Und da gefallen auch Schriften von Google nicht.




    N.B.:
    Es gibt auch Leute die sich wieder eine ältere Version von Firefox installierten, weil es für diese angeblich noch Unterstützung für normale deutsche Rechtschreibung gäbe!

  • Von OpenOffice.Org nimmt man Abstand, weil diese Anwendung eben keine vernünftige Rechtschreibprüfung in „bewährter“ Rechtschreibung aufweist.


    Nun, dasist nicht ganz richtig:
    Gerade beo OOo hat man die Möglichkeit auch die Rechtschreibprüfung Deutsch (alte Rechtschreibung) auszuwählen, auch wenn dr Standard eben die neue ist. Will man etwas anderes, als die Vorgabe muss man eben selbst aktiv werden, statt sich dann eben mit Uralt-Office zu begnügen.
    http://www.j3e.de/myspell/de_OLDSPELL.zip


    Aber wie wäre denn das, wenn man sich hier eine OpenOffice UNZ1-Rechtschreibprüfung nach bewährter Orthografie als Projekt in Angriff nimmt, welche dann auch codierte Ligatuten als zumindest alternative richtige Schreibweise anerkennt
    Siehe hierzu http://de.openoffice.org/spell…heck-detail.html#addbooks


    Und hier braucht mabn das Rad auch nicht komplett neu zu erfinden, da man durchaus mit den Wortlisten der oben genannten Rechtschreib-Wörterbücher in alter Rechtschreibung ausgehen kann und diese dann lediglich um Frakturbelange ergänzen muss.
    schließlich sind die vorhandenen Wörterbücher unter offenen Lizenzen verfügbar.


    Geradewo Oracle angekündigt hat, OpenOffice.org komplett der OpenSource-Gemeinde zu überlassen, sollten alle, die an einer weiterentwicklung auch intressiert sind, daran mitwirken, statt es einfach als ungenügend abzutun und sich dann lieber veralteter Software zu zu wenden.

  • Als Neuling hab ich gedacht, dass ich mit der im ersten Beitrag erwähnten OT-Schrift von Gerhard H in meinem neuen Office gleich loslegen kann. Irgendwas läuft da aber nicht, statt Buchstaben bekomme ich nur Rechtecke angezeigt. Aber witzig: Im enthaltenen Publisher 2010 funktioniert alles bestens!
    Dann hab ich noch die von Ligafaktur angebotenen Schriften probiert. Hier wird zwar der Text korrekt angezeigt, in der Vorschau auch mit langem "s", aber in Word nicht, in Publisher schon.
    Weiß jemand Rat? Vielen Dank für jede Hilfestellung (auch wenn sie nur lautet: geht im Moment nicht)

  • Wenn du hier in dem Strang ein wenig gelesen hättest (ich glaub gerade 2 Einträge über deinem) würdest du sehen, das MS Word mit einer Opentype-Funktionellen Schrift und anderen "Smartfont-Techniken) einfach nicht umgehen kann. (Das der Publischer das zumindest teilweise kann ist eine nette Entdeckung…)


    Bei den Schriften diedu auf de Ligafaktur-Seite bekommst, solltest du dich auch nicht für die Schriften mit einer internen Automatik entscheiden, wenn du Word nutzen möchtest - also NICHT die dort angebotenen LFO-Schriften, die funktionieren mit Word leider auch nicht, sondern lade dir das Programm Ligafaktur herunter und nutze UNZ1-Schriften, die Verbünde als codierte Glyphen enthalten. Ligafaktur setzt sich dann zwischen deiner Tasdtatur und Word und tauscht gleich bei der Eingabe den entsprechenden Code aus. Lediglich fpür wenige Sonderfälle, bei der eine Regel nicht weiter helfen kann, wie z.B. bei Wachstube / Wachſtube musst du von Hand eingreifen und eventuell ein speziuellesTrennzeichen einsetzen.Hierzu biete ich für Windows einen geänderten Tastaturtreiber hier an:
    http://www.peter-wiegel.de/download.html - damit kannst du dieses Trennzeichen mir AltGr+- direkt eintippen, ebenso einige Sonderzeichen und Ligaturen direkt, wie u.A auch …

  • Danke für den Rat! Ich hab natürlich den Strang komplett gelesen, aber manche Kommentare haben ja auf die Vorversion Bezug genommen. Und natürlich wollte ich es selbst einmal mit meinem neuesten Office probieren ...
    Ligafaktur hab ich natürlich in den aktuellen Version, aber benütze es eigentlich so selten, dass ich bei der Bedienung immer etwas unsicher bin. Und die LFO-Schriften funktionieren mit Publisher ganz gut - zumindest habe ich noch keine Fehler bemerkt. Aber wie gesagt, ich bin viel zu wenig mit der Materie vertraut und lese zunächst vor allem mit.