Beiträge von Utz

    Die von Fraktur genannten Werte (MD5 SHA-1) stimmen mit den Originaldateien überein. Es wurden also keine manipulierten Dateien heruntergeladen. Die Programmierung ist so, wie sie sein muß, um gute Ergebnisse zu erhalten. Leider kann ich nichts daran ändern, daß die Virenscanner Ligafaktur falsch einordnen, ohne Beweise, nur heuristisch und wahrscheinlich nur, weil sich die Programmierer der Scanner nicht vorstellen können, daß Tastenumleitungen mal nichts mit Virenaktivitäten zu tun haben könnten. In diesem Fall liegt also wirklich eine Überfunktion einiger Scanner vor. Der Windows Defender ist, jedenfalls bei mir, nicht dabei. Scanner sollten nur Programme anzeigen, die einen Schaden anrichten können.

    Übrigens hat sich bei Windows 10 im Vergleich zu früheren Ausgaben im Prinzip bis auf eine Anpassung an Windows 10 nichts geändert. Bei den Scannern scheint das anders zu sein.

    Das zuletzt unter »Ligafaktur 10« diskutierte Thema der OpenType-Schriften paßt dort nicht ganz hinein. Ich möchte es hier als eigenständiges Thema fortsetzen.


    Zu diesem Thema, besonders zur Frage der Codierung scheint noch manches unklar zu sein. Deshalb möchte ich das Prinzip am Beispiel des Lang-ſ hier noch einmal ausführlicher für alle Interessierten diskutieren.


    Vollfunktionale OpenType-Frakturschriften (nur um diese geht es) enthalten möglichst alle Fraktursatzregeln und erzeugen selbsttätig einen regelgerechten Frakturtext beim normalen Schreiben. Normales Schreiben bedeutet aber, daß im Text kein codiertes Lang-ſ verwendet werden kann, denn als höheres Unicode-Zeichen kann es nicht einfach mit einer Tastaturtaste gesetzt werden, sondern müßte durch ein Hilfsprogramm, aus einer Zeichentabelle des Textprogramms oder mit einem Tastenkürzel für höhere Unicode-Zeichen eingefügt werden, also meist aufwendig und nicht beim normalen Schreiben mit einer DIN-Tastatur möglich. Das widerspräche auch dem Anspruch vollfunktionaler OT-Schriften.


    Daher bleibt nur die virtuelle OpenType-Lang-ſ-Darstellung aus dem Rund-s, das einfach mit der s-Taste beim normalen Schreiben gesetzt wird. Die Lang-ſ-Darstellung aus dem Rund-s erfolgt ausschließlich über die Namen der Zeichenplätze, nicht über deren Codes, also beispielsweise mit der OT-Befehlszeile »sub s by longs« (= ersetze auf dem Bildschirm das Zeichen auf dem Zeichenplatz namens s durch das Zeichen auf dem Zeichenplatz namens longs). Der Unicode-Standard, der nur die Codes der Zeichenplätze festlegt, hat mit den Namen der Zeichenplätze, die OpenType verwendet, nichts zu tun. Umgekehrt ist es für die OpenType-Befehle egal, ob der Zeichenplatz namens longs codiert ist oder nicht, weil sie nichts mit den Unicode-Codes anfangen können. Trotzdem ist es besser, den longs-Zeichenplatz nicht zu codieren, weil es sonst möglich wäre, das Unicode-codierte Lang-ſ über Zeichentabellen usw. (s.o.) in den Text einzufügen. Dann gäbe es zwei Lang-ſ-Arten mit identischem Aussehen. Das codierte Lang-ſ aber reagiert bei Textänderungen nicht auf die Befehle einer üblichen vollfunktionalen OT-Programmierung* und kann zu Fehlern führen oder verhindert evtl. die regelgerechte Schreibung des Wortes, in dem es vorkommt.


    Auch wenn die OT-Schrift kein codiertes Lang-ſ enthält, fügen doch manche Textprogramme, wenn das Lang-ſ codiert gesetzt wird, dieses mit einer anderen Schrift in den Text ein. Das wäre dann aber leichter zu erkennen und ggf. zu entfernen.


    Was am Beispiel des Lang-ſ diskutiert wurde, gilt gleichermaßen für die Ligaturen, die ebenfalls nicht codiert sein sollten. Damit sind Texte, die mit diesen Schriften dargestellt werden, reine ASCII/ANSI-Antiquatexte ohne codierte höhere Unicode-Frakturzeichen wie Lang-ſ und Ligaturen. Entsprechend sind vollfunktionale OpenType-Frakturschriften normale ASCII/ANSI-Schriften mit zusätzlichen uncodierten Lang-ſ-/Ligatur-Zeichen und einer (aufwendigen) OpenType-Programmierung, die diese Zeichen abhängig vom zugrundeliegenden ASCII/ANSI-Text den Frakturregeln entsprechend auf dem Bildschirm (und beim Druck) anzeigt.


    * Theoretisch wäre es möglich, neben dem codierten Rund-s auch das codierte Lang-ſ als Basis in eine OT-Programmierung einzubeziehen. Das aber wäre überflüssig, extrem kompliziert und viel zu aufwendig, um evtl. Fehler durch ein versehentlich codiert gesetztes Lang-ſ zu beheben.

    Hier kommen ein paar Anmerkungen zu den LOV-Schriften vom Hersteller:


    Vollfunktionale OpenType(OT)-Schriften wie die LOV-Schriften enthalten in der Regel weder ein codiertes Lang-ſ noch codierte Ligaturen und sollten sie auch nicht enthalten. Alle diese Frakturzeichen liegen auf uncodierten Zeichenplätzen und werden durch die OT-Programmierung angesteuert. Unicode-codiertes Lang-ſ und Ligaturen wären hier kontraproduktiv. Ein OT-Text ist eigentlich ein ganz normaler Antiquatext nur mit Rund-s ohne Ligaturen. Das sieht man, wenn man den Text in einer Datei speichert. Nur die für die Textanzeige gewählte OT-Schrift sorgt dafür, daß z.B. s den Regeln entsprechend als Lang-ſ oder Rund-s oder f t als ft-Ligatur oder als f t auf dem Bildschirm angezeigt wird; im Text bleibt es aber immer beim s bzw. f t.


    Zu Unicode und OT kann man sagen: Für den OT-Teil OpenType-programmierter Schriften ist der Unicode-Standard nicht zuständig und wird durch ihn nicht geregelt. Einen Standard oder eine »Best Practice«, wie die OT-Programmierung von Schriften, insbesondere Frakturschriften auszusehen hat, gibt es nicht.


    Noch eine Anmerkung zu den nur in den LOV-Schriften enthaltenen Unicode-Privat-codierten Lang-ſ-Zeichen, die bei einer ersten Durchsicht der Schrifttabelle vielleicht irritierend wirken: Sie haben mit dem normalen Lang-ſ nichts zu tun und sind lediglich Hilfszeichen zur Textsperrung im Ligafaktur-Programm. Textsperrung in OT-Texten ist schwierig, weil OT-generierte Ligaturen wie ſi beim normalen Sperren immer als ein einziges Zeichen auftreten, egal wie groß die Sperrweite ist. Da muß man ein paar Tricks anwenden, um auch das ſi trennen und sperren und in diesem Fall die OT-Programmierung überlisten zu können.


    Zu einem ganz anderen System gehören die LUC-Schriften mit auschließlich codierten Frakturzeichen. Lang-ſ und Ligaturen bilden sich nicht von selbst wie bei den LOV-Schriften, sondern müssen z.B. mit Hilfe von Ligafaktur in den Text eingefügt werden. Anders als Frakturtexte mit LOV-Schriften werden Texte mit codierten Zeichen aber schriftunabhängig als Frakturtexte gespeichert und können als solche auch ohne Schrift erkannt werden; bei Texten, dargestellt mit vollfunktionalen OT-Schriften, sind es dagegen wie erwähnt reine Antiquatexte, die keinen Hinweis auf einen Frakturtext enthalten.

    Ergänzend und grundsätzlich ist bei gelegentlichen Viren-Fehlmeldungen festzusteilen: Das Fraktursatzprogramm Ligafaktur gibt es inzwischen seit zwölf Jahren und ist natürlich frei von Viren, Trojanern und anderen Schadprogrammen. Leider muß heute extra auf diese Selbstverständlichkeit hingewiesen werden, weil manche Virenschutzprogramme, die Ligatur früher nie beanstandet hatten, in letzter Zeit offensichtlich immer aggressiver werden und ihre heuristischen Verfahren (also Annahmen und Theorien ohne konkrete Beweise) ausweiten und nun gelegentlich auch entsprechende Fehlmeldungen zu Ligafaktur verbreiten. Vermutlich sind die zur Ligaturbildung notwendigen Tastenumleitungen der Grund dafür, denn dabei kommt etwas anderes (»verdächtig!«) heraus (Ligaturen) als das, was man eintippt (Einzelzeichen). Änderungen der Tastenausgabe scheinen manchen Schutzprogramm-Herstellern grundsätzlich verdächtig zu sein, den meisten richtigerweise nicht, denn letztlich kommt es nur darauf an, ob ein Schaden entsteht.

    Die Ligatur-Programmierung in Ligafaktur ist natürlich notwendig und kann evtl. den ausgeweiteten Heuristiken der Virenprogramme nicht immer gerecht werden. In diesem Falle einer Fehlmeldung sollte Ligafaktur als Ausnahme bei den Virenprogrammen angemeldet werden, damit diese Meldungen nicht ständig auftauchen und Ligafaktur wieder funktioniert.

    Ähnliche Meldungen (Kaspersky u.a.) tauchen immer mal wieder auf, wenn es um Programme wie Ligafaktur geht, in dem Tastendrücke umgeleitet werden. Wenn möglich, melden Sie Ligafaktur als Ausnahme an und nehmen es so aus zukünftigen Meldungen heraus. In meinem Windows 10 erscheint übrigens keine Defender-Meldung.

    Die neue Ligafaktur-Ausgabe 10 wurde ins Netz gestellt und ist wie die bisherigen Ausgaben registrierungs-, werbe- und kostenfrei bei http://www.ligafaktur.de erhältlich. Sie ist dem aktuellen Windows-System angepaßt: Vorausetzung für die Nutzung ist ein Rechner (PC) mit dem Betriebssystem Windows 10 ab Version 1809. Wer mit älteren Betriebssystemen arbeitet, muß weiter die bisherige Ligafaktur-Ausgabe 9.3 verwenden.


    Seit Erscheinen der Ausgabe 9.3 sind auch einige neue Frakturschriften als ligaturcodierte LUC-Schriften und OpenType-funktionale LOB- und LOV-Schriften hinzugekommen.

    Die Frage bezieht sich vermutlich auf die vollfunktionalen LOV-OpenType-Frakturschriften. Wenn dort ein seltenes Wort mal nicht richtig gesetzt wird, setzt man mit Hilfe des Ligafaktur-Programms einfach einen Bindehemmer vor das Doppel-s mittels der Tastenkombination AltGr+[Punkt]. Dann erscheint Ambaſſadeur mit Lang-s/Lang-s-Ligatur.

    In der alten Rechtschreibung steht im Fraktursatz für einen Doppel-s-Laut die ſſ-Ligatur wie in »Waſſer« oder »deſſen« und eben das ß wie in »Faß«, »naß« oder »Flußſäure«.


    In der neuen Rechtschreibung steht im Fraktursatz für das aufgelöste ß entweder die Zeichenfolge ſs oder als neu eingeführte Ligatur die ſs-Ligatur, die im Grunde dem ß entspricht, aber so ausgebildet sein sollte, daß ſ und s noch als solche erkennbar sind wie die Einzelzeichen in anderen Ligaturen und sich vom ß unterscheiden, um der neuen Rechtschreibung formal zu genügen. Dort ist ja nur das ß als ein ganz bestimmtes Einzelzeichen aufgehoben, nicht die Ligaturbildung aus zwei Zeichen. Ein Ersatz des ß durch ſſ (vielleicht mit einigen Ausnahmen?) oder gar ss ist ausgeschlossen. Man schreibt also »Faſs«, »naſs«, »Fluſsſäure« mit ſs als Zeichenfolge oder Ligatur. Eigentlich sollte ſs aber wie die Zwangsligaturen ch, ck und tz immer eine Ligatur sein und die anderen Zwangsligaturen ergänzen. Natürlich könnte man fragen, warum dann nicht gleich das ß als Ligatur behalten? Das wäre dann aber keine neue Rechtschreibung, denn man könnte nicht zwischen einem erlaubten ß (weiß, Buße) und einem verbotenen, durch ſs zu ersetzenden ß unterscheiden; ß besteht also unterscheidbar neben der neuen ſs-Ligatur.

    Pfennig, Unicode U+20B0 GERMAN PENNY SIGN

    Einfach aus der Windows-Zeichentabelle kopieren oder die Sonderzeichenfunktion des Textprogramms nutzen, wenn die Schrift dieses Zeichen enthält.

    Wenn es ein d oder ein vom d abgeleitetes Zeichen sein soll, fehlt mir vor allem der für das Kurrent-d charakteristische zuerst nach unten laufende Bogen bevor er zur oberen Schleife aufsteigt. Schließlich ist es nicht ein flüchtig geschriebenes, sondern ein langsamer eingeschlagenes Zeichen. Trotzdem scheint es im Zusammenhang mit dem anderen Text als d. und Teil des Datums am wahrscheinlichsten zu sein. Ins Heute übersetzt lautet dann der Silberlöffel-Text:

    ·J·H·H·

    d.·12·octb·

    ·1788·

    Danke für die Hinweise!

    Die Varianten/Schnitte werden von einigen Textprogrammen wie LibreOffice künstlich erzeugt, auch wenn sie nicht existieren. Wenn man sie anwählt, werden sie aus den vorhandenen Schnitten erstellt, indem sie gefettet oder schräg gestellt werden. Diese Varianten sollten in Texten nicht verwendet werden, nur solche, die auch als Schriftdatei existieren.

    Der größere Teil meiner Frakturschriften enthält nur einen Schnitt, den Normalschnitt, Einige enthalten zusätzlich einen fetten und/oder einen Zierschnitt (kursiv) . Und wie gesagt, in allen meinen Textprogrammen (BS Windows) funktionieren alle Schriften mit allen Schnitten problemlos. Es gibt auch keine Rückmeldungen anderer Anwender zu diesem Thema.

    Zuerst einmal würde ich prüfen, ob andere Schriften mit kursivem Schnitt (Italic) dieses Problem ebenfalls zeigen. Wenn ja, ist es sicher ein Fehler in LibreOffice, wenn nicht ... ? Jedenfalls funktioniert die »Frühling« problemlos in allen meinen Textprogrammen.