OpenType: Interne Buchstabenbedeutung

[[Mitglied Josh…]]

Ich war bis jetzt der Meinung, bei der Verwendung von OpenType-Schriften würde im geschriebenen Text auch bei automatisch eingefügten Ligaturen intern die eigentliche Buchstabenbedeutung erhalten bleiben. Ich dachte also, die Ligaturen würden nur rein »äußerlich« angewandt, der Text aber mit Einzelbuchstaben abgespeichert.

Jetzt wollte ich aus einem PDF-Fokument Text herauskopieren, und stelle fest, daß Ligaturen entweder als Unicode-Zeichen (fl, fi), nur mit dem ersten Buchstaben (z.B. »f« statt »ffl«), als unbekannte Zeichen, oder gar nicht kopiert werden! Bei mehreren überprüften Schriftmustern verschiedener Schrifthersteller zeigte sich das gleiche Verhalten. Auch die Suche nach Wörtern mit Ligaturen (z.B. »Kuhfladen«, »Affe«) funktioniert nicht.

Hatte ich etwa unrecht, und das ist völlig normal?! Oder kann man das oben von mir beschriebene Verhalten irgendwie erreichen?

[[Mitglied hey…]]

Das Problem könnte eher beim PDF liegen: dort werden Schriften nicht komplett, sondern nur mit dem im Dokument verwendeten Zeichenumfang eingebettet (hier also wohl nur die Ligaturen), daher ist man darauf angewiesen, dass die Verwendete Software beim Kopieren von Text aus dem PDF intelligent rät – das klappt mal mehr, mal weniger gut.

[Ralf Herrmann]

Also die Ligaturen sind im PDF schon fest drin, nicht nur »äußerlich angewandt«. Der Knackpunkt ist, wie die Zeichen im Font benannt sind, damit das schon von Hey angesprochene Raten klappt. Wenn es sauber gemacht ist, klappt auch das Copy & Paste und die Volltextsuche in der Regel problemlos.

[[Mitglied Seba…]]

"äußerlich angewendet" gilt für Layoutprogramme und Layout-Datenformate.

im PDF hingegen nicht mehr unbedingt, das bringt seinen eigenen Font miteingebettet mit sich und macht "Setzkasten" ... gut? schlecht?

[[Mitglied Josh…]]

Tatsächlich: Wenn ich den Adobe Reader benütze, klappt alles! Sämtliche Ligaturen (auch Unicode-Ligaturen) werden als Einzelzeichen kopiert. Vorher habe ich den Foxit Reader zum Öffnen von PDF-Dateien verwandt.

Wie sind denn sinnvollerweise die Ligaturen zu benennen? Wenn man die Ligaturen außerhalb der Codierung speichert, würden Namen wie »fl« oder »fi« ja mit den sobenannten Unicode-Plätzen kollidieren, oder?

Und noch was: Das Ligaturentrennzeichen (Zero Width Non Joiner) bringt Volltextsuche und Kopieren doch bestimmt auch ins Stolpern. Wie benennt man das daher am besten?

[[Mitglied Seba…]]

Ligaturen die nicht historisch bedingt einen anderen Namen haben, werden in der Regel durch ein _ gekennzeichnet, also zum Beispiel f_f_k für die ffk-Ligatur.

Non-Joiner etc. brauchen auch einen Namen, der dann potentiell "stört" beim regenerieren des PDFs, es liegt am Programm, den PDF-Zeichensalat wieder in Text umzuwandeln, also zu filtern, zu verbinden, etc. ... Acrobat kanns, Foxit-Reader offenbar nicht. Liegt wohl an der Nähe von Adobe zur Schriftgestaltung, die setzen sowohl im Bereich PDF als auch bei Fonts praktisch die Standards.

[[Mitglied Þors…]]

Also die Ligaturen sind im PDF schon fest drin, nicht nur »äußerlich angewandt«. Der Knackpunkt ist, wie die Zeichen im Font benannt sind, damit das schon von Hey angesprochene Raten klappt. Wenn es sauber gemacht ist, klappt auch das Copy & Paste und die Volltextsuche in der Regel problemlos.

Hast du irgendwelche weiterführenden Infos, was das »saubere« Machen angeht?

Nach meinen Tests sieht das für mich so aus, als ob das alles nur über die Unicode-Positionen läuft. Die Glyphennamen sind anscheinend irrelevant, zumindest in meinem Workflow (Fontforge bzw. existierende OpenType-Schrift ? XeLaTeX ? Acrobat Reader bzw. verschiedene Linux-PDF-Betrachter).

Die Suche nach bzw. das Herauskopieren von OpenType-behandelten Texten funktioniert anscheinend nur, wenn die ersetzten Zeichen eigene, standardisierte Unicode-Belegungen haben. Das betrifft also ? und die Handvoll Unicode-kodierter Ligaturen (ff, fi, fl, ffi, ffl, st). Anscheinend ist die »Rückübersetzung« (ff ? f f, ? ? s usw.) in Acrobat oder irgendeiner benutzten Bibliothek fest verdrahtet. D.h. also, dass eine Suche nach »flach«, »filigran«, »Effi« und »Frakturschrift« funktioniert, auch wenn die entsprechenden Ligaturen aktiviert sind und der letzte Begriff als »Fraktur?chrift« erscheint. (Dabei ist es übrigens egal, ob das ? per OpenType ersetzt oder manuell über seinen Unicode-Code eingefügt wurde.)

Bei allen anderen Ligaturen und sonstigen Ersetzungen ist aber Pumpe. Hier mal ein Test mit Calibri:

http://thorsten.dt1.org/misc/test/typography/opentype/calibri.pdf

http://thorsten.dt1.org/misc/test/typography/opentype/calibri.tex (XeLaTeX-Quelltext)

In Acrobat Reader 9.3.1 funktioniuert die Suche da nur beim langen s und den Ligaturen im ersten Abschnitt. Nicht einmal die Suche nach Mediävalziffern funktioniert!

Es ist natürlich möglich, dass das an TeX bzw. dem Linux-Acrobat liegt. Kann jemand mit Mac-Software bessere Ergebnisse erzielen?

Tatsächlich: Wenn ich den Adobe Reader benütze, klappt alles! Sämtliche Ligaturen (auch Unicode-Ligaturen) werden als Einzelzeichen kopiert.

Auch die Nicht-Unicode-Ligaturen? Hast du mal Beispiele? Ein PDF vielleicht, bei dem das Suchen und Herauskopieren funktioniert?

Wie sind denn sinnvollerweise die Ligaturen zu benennen? Wenn man die Ligaturen außerhalb der Codierung speichert, würden Namen wie »fl« oder »fi« ja mit den sobenannten Unicode-Plätzen kollidieren, oder?

Wie geschrieben, der Glyphenname scheint keinen Einfluss zu haben. Ich habe in einem OFL-Font auch extra mal die fi-Ligature in »effih« umbenannt (also einen Namen, der garantiert nicht »richtig« ist). Das Suchen und Kopieren hat trotzdem noch funktioniert, weil die Ligature eben noch auf der bekannten Unicode-Position für »fi« stand.

Also, wenn hier jemand genaueres weiß…

[[Mitglied Þors…]]

Ach ja, ein gefühlsmäßig hässlicher Trick scheint bei Nichtligaturen zu funktionieren: man kann bei stilistischen Alternativen, Mediävalziffern u.ä. dem alternativen Zeichen einfach den Unicode-Wert des Originals zuweisen (also z.B. »one.oldstyle« 0x31, den Wert für die 1). Bei Ligaturen geht das natürlich leider nicht, denn welchen Wert soll man z.B. für die fb-Ligatur denn nehmen, den für f oder den für b?

[[Mitglied Þors…]]

Es ist natürlich möglich, dass das an TeX bzw. dem Linux-Acrobat liegt.

Unter Windows Vista liefert AbiWord ? PDFcreator ? Acrobat Reader 9.3.2 dasselbe unbefriedigende Ergebnis. Die Standardligaturen sind alle da, aber suchen und kopieren geht nur mit ff, (f)fi, (f)fl, nicht aber tt, fb etc.

[Ralf Herrmann]

Nach meinen Tests sieht das für mich so aus, als ob das alles nur über die Unicode-Positionen läuft. Die Glyphennamen sind anscheinend irrelevant, zumindest in meinem Workflow

Das hängt vor allem auch vom Fontformat ab. Aber natürlich kann es nicht nur Unicode-basiert sein, da viele OpenType-Zeichen (wie eben Sonderligaturen außer fi/fl) ja gar keine Unicode haben müssen, sondern nur über ihren Namen angesprochen werden.

[[Mitglied Þors…]]

Das hängt vor allem auch vom Fontformat ab.

Inwiefern? Mit welchem Format lasst sich das gewünschte Verhalten (Ligaturen und Alternativzeichen in PDFs; man kann aber noch nach den Ursprungszeichen suchen und Textpassagen problemlos kopieren) denn erreichen?

Aber natürlich kann es nicht nur Unicode-basiert sein, da viele OpenType-Zeichen (wie eben Sonderligaturen außer fi/fl) ja gar keine Unicode haben müssen, sondern nur über ihren Namen angesprochen werden.

Was meinst du genau mit "es"? Das Erzeugen von OpenType-Zeichen oder das Suchen in bzw. Kopieren aus PDFs? Letzteres funktioniert nach meinen Tests eben nur Unicode-basiert. Oder andersherum: OpenType-Zeichen ohne Unicode-Belegung können weder gefunden noch vernünftig kopiert werden.

Falls du weißt, wie das trotzdem geht, nur her mit der Weisheit...

[[Mitglied Seba…]]

Ich hoffe ich habe die Frage richtig verstanden:

Ich gehe mal vom Adobe-Indesign-PDF-Ansatz und Opentype-Schriften aus, deren Sonderligaturen zwar eine Glyphen-ID (GID) haben, aber keinen Unicode (z.B. eine ct-Schmuckligatur, die über das DLIG-Feature angesprochen werden kann):

Wenn du in dieser Konstellation in Indesign "c" und "t" eingibst, und das DLIG-Feature aktivierst, ersetzt Indesign deren Glyphen (nicht den Code) durch die "ct"-Glyphe. Kopierst du diese Passage, erhältst du wieder ein "c" und ein "t". Wenn ich daraus ein PDF mache, und den Text dort kopiere, funktioniert das bei mir ebenso (Windows XP, Indesign CS2, Acrobat 8, PDF/X-3).

Wenn du hingegen die "ct"-Glyphe über die Glyphenpalette eingibst, arbeitet Indesign mit dieser Glyphe, nicht mit Unicode-Werten (je nach Glyphenname - idealerweise per Konvention "c_t" - kann Indesign interpretieren, dass es sich um eine ct-Ligatur handelt, und gibt dir trotzdem ein "c" und "t" zurück wenn du es wo anders hin kopierst). Aber bei mir klappt hier das Kopieren aus dem generierten PDF nicht mehr - da hört sich die Codierung offenbar auf und es wird nur die Glyphe angezeigt. Damit ist kopieren, suchen, etc. natürlich gestorben.

Ähnlich sollte es sein, wenn du eine unicode-codierte Ligatur (fi) "hart" einfügst, also als eigenes Zeichen statt über die LIGA-Funktion. Wenn die Programme, die diesen Text interpretieren, nicht darauf vorbereitet sind, dass "fi" = "f" und "i" sind und dir praktisch intern einen workaround liefern, wird die Suche nicht funktionieren wenn du nach "fidelo" suchst, aber im Dokument "[filiga]delio" steht. Bei den Standardligaturen sind sie vermutlich so schlau. Wenn aber codierte(!) Sonderligaturen im Dokument sind, ist damit naturgemäß Schluss.

(kurz getestet mit meiner Tierra Nueva-Schrift - Details auf Anfrage)

[Ralf Herrmann]

Hier die Empfehlungen von FontLab:

3.2 Glyph name limitations

A glyph name must not be longer than 31 characters. The glyph name consists of a basename, optionally followed by a period (.) which is then followed by a suffix. Both the basename and the suffix may only include: uppercase English letters (A-Z), lowercase English letters (a-z), European digits (0-9), and underscore (_). Other char-acters such as spaces are not permitted! A glyph name must start with a letter or the underscore character – with the exception of the special glyph name “.notdef” that starts with the period. For example, “twocents”, “a1”, and “_” are valid glyph names, while “2cents” and “.twocents” are not.

3.3 Simple glyph names

Review the Adobe Glyph List for New Fonts (AGLFN) [10]. If your glyph represents a character listed in AGLFN, use the glyph name listed there. Instead of using arbitrary names (e.g. “middot”), use standardized names listed in AGLFN (“periodcentered”).

Review the Unicode Standard code charts. If your glyph represents a default form of a character encoded in the Unicode Standard but not listed in AGLFN:

a) for BMP codepoints, use the name “uniXXXX”, that is lowercase “uni” followed by a four-digit Unicode codepoint written using uppercase hexadecimal digits. Note that “uni” must be lowercase and XXXX must use uppercase letters for hexadecimal digits, so “uni01EB” is a vaild glyph name but “uni01eb” or “Uni01Eb” are not.

b) for SMP codepoints, use the name “uXXXXX” or “uXXXXXX”, that is lowercase “u” followed by 5 or 6 uppercase hexadecimal digits representing the codepoint.

3.4 Glyph names with suffix

If your glyph represents an alternate form of a character that is encoded in the Uni-code Standard or is listed in AGLFN, use the glyph name of the basic form as the basename, followed by a period, followed by a suffix.

For the suffix, use the name of the OpenType Layout feature that you would most likely access that glyph through.

For example, for a small-caps A, use “A.smcp”, for a stylistic alternate R use “R.salt”, for a swash Q use “Q.swsh”, for a superior m use “m.sups”, for a tabular 5 use “five.tnum” etc. If there are multiple OpenType Layout features that can be used to access a glyph, pick one of your likings.

3.5 Compound glyph names

If your glyph represents a “compound character”, i.e. a ligature or an accented char-acter that does not have a precomposed Unicode codepoint, and if the character is not explicitly listed in AGLFN or the Unicode Standard, construct the compound glyph name as follows.

For each element of the compound character, take the basename (or the entire glyph name if there is no suffix). Concatenate these using underscore to make the com-pound basename.

For each element of the compound glyph that has a suffix, concatenate the suffixes using underscore to make the compund suffix. You may eliminate duplicate suffix elements.

For example, for a ligature of the glyphs “c” and “t”, use “c_t” as glyph name. For a ligature of the glyphs “f”, “f” and “i”, use “f_f_i” as glyph name. For a ligature of “longs” and “i” use “longs_i” as glyph name. For a ligature of the glyphs “F.smcp”, “F.smcp” and “I.smcp”, use “F_F_I.smcp” as glyph name. For a ligature of the glyphs “R.salt” and “s.sups”, use “R_s.salt_sups” as glyph name. For the African ?? character use the glyph name “E_dotbelowcomb_acutecomb”.

If each element of a compound glyph name represents a BMP character, you can use an alternative way of building the basename, which can potentially produce a shorter glyph name. The glyph name starts with “uni” and must be followed by unseparated groups of four uppercase hexadecimal digits representing the BMP codepoint of each element. So instead of “E_dotbelowcomb_acutecomb”, you can use the name “uni004503230301”.

Remember that a glyph name should be no longer than 31 characters, so you may need to abbreviate the name if needed.

Mehr hier: http://www.twardoch.com/download/unicod ... ntlab5.pdf

[[Mitglied Josh…]]

Folgendes habe ich inzwischen herausgefunden:

In PDF-Dateien kann eine Liste („to-Unicode character mapping (cmap) list“) gespeichert werden, in der steht, für welche Unicode-Zeichen die durch OpenType-Funktionen eingefügten Glyphen stehen.

Haben durch OpenType eingefügte Glyphen keine Codierung, werden ihnen in dieser Liste die Ursprungszeichen zugeordnet. Wurden beispielsweise durch OpenType die Einzelbuchstaben t und z durch den tz-Verbund ersetzt, und dieser ist uncodiert in der Schrift abgelegt, so wird in der Liste der Verbund den beiden ursprünglichen Einzelbuchstaben zugeordnet, sodaß der Text mit den Einzelbuchstaben durchsucht und kopiert werden kann. (Vorausgesetzt natürlich, daß das PDF-Anzeigeprogramm auch die Liste ausliest!)

Es soll wohl auch Programme geben, die in die bewußte Liste nicht die Ursprungszeichen eintragen, sondern durch die Zeichennamen bestimmen, welchen Zeichen die Glyphen zugeordnet werden.

Bei XeLaTeX gibt’s jetzt das bekannte Problem, daß bei Postscript-OpenType-Schriften diese cmap-Liste nicht richtig (oder gar nicht? – ich weiß es gerade nicht mehr) erstellt wird. Bei TrueType-Schriften dagegen funktioniert alles!

[[Mitglied Þors…]]

Danke für die detaillierten Antworten, allerseits!

Sebastian, der Unterschied zwischen Erzeugen mittels OpenType-Feature (»richtiger« Ansatz) und Einfügen über Glyphenpalette/per Glyphenname (in diesem Kontext »falscher Ansatz«) ist mit schon bewusst. Sowohl mit XeLaTeX als auch AbiWord (dort nur Standardligaturen, aber darunter auch welche ohne Unicode-Kodierungen) erzeugt der »richtige« Ansatz offenbar nur PDFs, in denen Suchen & Kopieren nicht funktionieren.

Hier die Empfehlungen von FontLab: [...]

:? Die Schriften, mit denen ich getestet habe, folgen alle den Empfehlungen. Daran sollte es nicht liegen. Langsam frage ich mich, ob es überhaupt FOSS- bzw. nur Nicht-Adobe-Software gibt, mit der man OpenType-angehübschte, aber weiter vernünftig durchsuchbare PDFs erstellen kann.

Bei XeLaTeX gibt’s jetzt das bekannte Problem, daß bei Postscript-OpenType-Schriften diese cmap-Liste nicht richtig (oder gar nicht? – ich weiß es gerade nicht mehr) erstellt wird. Bei TrueType-Schriften dagegen funktioniert alles!

Hast du mal ein Beispiel für eine (frei verfügbare) Schrift (Windows-Systemschrift geht auch), mit der es in XeLaTeX funktioniert?

Anschlussfrage: wie finde ich heraus, ob eine Schrift Postscript-OpenType oder TrueType ist? Sind .ttf-Dateien immer (nur) TrueType?

[[Mitglied Josh…]]

Langsam frage ich mich, ob es überhaupt FOSS- bzw. nur Nicht-Adobe-Software gibt, mit der man OpenType-angehübschte, aber weiter vernünftig durchsuchbare PDFs erstellen kann.

Wie ich bereits geschrieben habe: Es geht. Wenn man TrueType-Schriften verwendet, erstellt XeLaTeX richtige CMAP-Listen.

Hast du mal ein Beispiel für eine (frei verfügbare) Schrift (Windows-Systemschrift geht auch), mit der es in XeLaTeX funktioniert?

Mit der hier erhältlichen „Old Standard“ (TrueType-Fassung!) sollte es gehen.

Anschlussfrage: wie finde ich heraus, ob eine Schrift Postscript-OpenType oder TrueType ist? Sind .ttf-Dateien immer (nur) TrueType?

PostScript hat die Endung .otf, TrueType .ttf. Herkömmliche TrueType-Schriften und OpenType-TrueType-Schriften (die sich auch nur durch das Vorhandensein zusätzlicher OpenType-Daten in der Schriftdatei unterscheiden) kann man also an der Dateiendung nicht unterscheiden. Windows zeigt aber als Dateisymbol bei TrueType-Schriften ohne OpenType-Daten das Blatt mit dem blauen T an, bei TrueType-Schriften mit OpenType-Daten dagegen das Blatt mit grünem O.

[Ralf Herrmann]

PostScript hat die Endung .otf, TrueType .ttf.

Üblicherweise. Nach OpenType-Spezifikationen kann z.B. auch ein OpenType TT die Endung .otf haben …

bei TrueType-Schriften mit OpenType-Daten dagegen das Blatt mit grünem O.

Wobei dazu nur geprüft wird, ob eine digitale Signierung vorliegt – also nicht gerade ein wirksames Mittel, auf OpenType-Funktionen im Font zu schließen.

[[Mitglied Þors…]]

PostScript hat die Endung .otf, TrueType .ttf.

Üblicherweise. Nach OpenType-Spezifikationen kann z.B. auch ein OpenType TT die Endung .otf haben …[/quote:1qw7dq1q]

Aber umgekehrt ist eine .ttf-Datei immer¹ TrueType (im Sinne von »nicht Postscript«; wahlweise mit oder ohne OpenType-Funktionalität)?

Dann sollte XeLaTeX also mit jeder OpenType-fähigen .ttf-Datei (also z.B. den C-Fonts von Windows) PDFs erzeugen können, in den das Suchen und Kopieren von ersetzten Zeichen funktioniert?

Genau das funktioniert hier bei mir überhaupt nicht, weder mit den Windows C-Fonts (und .ttf-Endung) noch mit der von Joshua empfohlenen OldStandard-Regular.ttf. Hast du, Joshua, evtl. mal eine .tex-Beispieldatei mit daraus generiertem PDF? Langsam verliere ich hier nämlich die Nerven…

¹ von mutwilligen Dateiumbenennungen mal abgesehen

[[Mitglied Josh…]]

\documentclass[fontsize=20pt]{scrartcl}
\usepackage{xltxtra}
\setmainfont{Old Standard TT}

\begin{document}
Gepflegte affige Kniffe im Hause Hufflepuff.
\end{document}

Datei: ttftest.pdf

Der Text wird bei mir im Adobe Reader und in Evince kopiert als:

Gepflegte affige Kniffe im Hause Hufflepuff.

[[Mitglied Þors…]]

\documentclass[fontsize=20pt]{scrartcl}
\usepackage{xltxtra}
\setmainfont{Old Standard TT}

\begin{document}
Gepflegte affige Kniffe im Hause Hufflepuff.
\end{document}

Datei: ttftest.pdf

Der Text wird bei mir im Adobe Reader und in Evince kopiert als:

Gepflegte affige Kniffe im Hause Hufflepuff.

Das ist auch keine Kunst, weil in deinem Beispiel nur Ligaturen mit standardisierten Unicode-Positionen vorkommen (fl, ffi, ff, ffl). Die funktionieren problemlos. Aber probier mal bitte folgendes:

\documentclass[fontsize=20pt]{scrartcl}
\usepackage{xltxtra}
\setmainfont{Old Standard TT}

\begin{document}
Gepflegte affige Kniffe im Hause Hufflepuff.

fj ffj
\end{document}

Erzeugtes PDF

[[Mitglied Josh…]]

Leider bin ich erst wieder am Freitag zu Hause, und kann deshalb erst dann wieder ausprobieren. Ich habe aber schon mit selbsterstellten Frakturschriften, die keine codierten Verbünde enthalten, Dokumente erstellt, und bin mir ziemlich sicher, daß die auch richtig durchsucht und kopiert werden konnten.

[[Mitglied Þors…]]

Danke — und noch mal die Bitte an die interessierten Mitleser, selbst zu probieren und die Ergebnisse hier mitzuteilen, am besten mit einem Beispiel-PDF, in dem jeder selbst suchen kann.

Ich hoffe inständig, dass irgendjemand doch noch eine Lösung findet. Ansonsten habe ich nämlich keine andere Wahl, als auf OpenType-Funktionalität bis auf weiteres zu verzichten. (Es geht mir vor allem um wissenschaftliche Veröffentlichungen, die fast ausschließlich auch als PDF existieren werden. Dort nicht ordentlich suchen zu können ist ein Ausschlusskriterium.)

[[Mitglied Þors…]]

OK, Mini-Erfolg: Ich habe es jetzt doch geschafft, Uwe Borcherts Plakativ und mein triviales Englische-Linien-Beispiel in FontForge so zurecht zu biegen, dass — wenn man die TTF-Versionen benutzt — das Suchen in und Kopieren aus dem Acrobat Reader funktioniert.

Das Problem ist nur, dass das — wenn man nicht alle Fonts selbst (um-)bauen will — kaum nützlich ist. Die Schnittmenge der Schriften, die einerseits konsequent auf OpenType-Funktionalität setzen (d.h. Ligaturen, Alternativformen, Ziffernformen u.ä. nicht im Unicode PUA kodieren) und diese Schriften andererseits in TTF anbieten, scheint (noch?) verschwindend klein zu sein (zumindest was FOSS-Schriften angeht).

Ohnehin ist der sture und äußerst unflexible Verlass auf Glyphennamen nicht für alle Situationen ausreichend. Die saubere und verlässliche Art, das zu programmieren, wäre die Auswertung der GSUB-Tabellen. Na ja, vielleicht kommt das irgendwann noch, obwohl die XeTeX-Entwickler sich in der Vergangenheit da ziemlich stur gegeben haben.

Für Hinweise zu XeTeX-OpenType-kompatiblen Schriften wäre ich weiterhin äußerst dankbar.

[[Mitglied Josh…]]

Diese Unterhaltung ist zwar schon etwas älter, aber Du hattest ja geschrieben, daß Du für Hinweise weiterhin dankbar seist, und ich hatte angekündigt, mich nochmal damit zu beschäftigen, was ich jetzt getan habe. Ich habe mehrere Schriften getestet (PDF-Dateien erzeugt mit XeLaTeX und überprüft mit Evince) und bin zu folgendem Ergebnis gekommen:

Schriften, in denen die Verbünde ohne Code abgelegt sind, funktionieren einwandfrei. Da die Verbünde keinen eigenen Code haben, schließt XeTeX vom Zeichennamen auf die zu verwendenden Codes. Heißt ein Verbund beispielsweise „f_t“ weist ihm XeLaTeX in der CMAP-Liste die Codes der beiden Zeichen f und t zu. Verbünde sind somit als Einzelbuchstaben durchsuch- und kopierbar.

(Andere Programme außer XeTeX müssen nicht unbedingt die Zeichennamen verwenden, um auf die Codes zu schließen. Indesign verwendet die Codes der Ursprungszeichen in der OpenType-Ersetzung, kehrt also sozusagen die Ersetzung um. In Indesign ist daher die Benennung der Zeichen gleichgültig.)

Einzige mir bekannte kostenlose Schrift, bei der das der Fall ist, ist die Sorts Mill Goudy. Bei ihr sind alle Verbünde ohne Code abgelegt.

Ebenfalls einwandfrei funktionieren Schriften, in denen die Verbünde, die eine Unicode-Stelle haben, auf dieser liegen, und zusätzliche Verbünde ohne Code abgelegt sind. Die Verbünde mit Unicode-Stelle lassen sich trotzdem als Einzelbuchstaben durchsuchen und kopieren, wohl weil Evince diese Unicode-Stellen kennt und entsprechend behandelt. Dazu gehört die zur Zeit im leichten Schnitt kostenlos erhältliche Erato.

Natürlich funktionieren auch Schriften, die nur Verbünde mit Unicode-Stelle und keine zusätzlichen Verbünde ohne Code enthalten, so die PT Serif.

Hat ein durch eine OpenType-Ersetzung eingefügtes Zeichen einen eigenen Code, trägt XeLaTeX diesen in der CMAP-Liste ein. Liegen Verbünde im Privaten Unicode-Bereich, werden in der CMAP-Liste also deren Codes eingetragen. Die Verbünde sind somit nicht ihren Einzelbuchstaben zugeordnet, sondern werden mit ihrem PUA-Code kopiert. Das ist der Fall bei Cardo, Linux Libertine und Vollkorn.

Wenn Du eine bestimmte Schrift verwenden möchtest, die privat-codierte Verbünde enthält, könntest Du ja den Schrifthersteller anschreiben und bitten, die Verbünde nicht mehr auf Privatstellen abzulegen.

Ich habe nur TrueType-Schriften geprüft, weil in XeLaTeX bei Postscript-Schriften die CMAP-Erzeugung nicht funktioniert.