LuaLatex: Font names DB - Segmentation Fault 11

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
Smilies
:D :) :( :o :shock: :? 8) :lol: :-x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:

BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smilies sind eingeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Wenn du eine Datei oder mehrere Dateien anhängen möchtest, gib die Details unten ein.

Ansicht erweitern Die letzten Beiträge des Themas: LuaLatex: Font names DB - Segmentation Fault 11

von cgnieder » Sa 8. Feb 2014, 11:42

u_fischer hat geschrieben:Aber nicht mit deiner Begründung: Auch ü oder ß sind kein ASCII, dennoch hat pdflatex keine Probleme mit \hyphenation{grü-ßen} - sofern \usepackage[T1]{fontenc} geladen ist, d.h. solange ü bei der Ausgabe ein echter Glyph ist und nicht ein Buchstabe u mit einem Akzent drüber.

Damit dṛṣṭi funktioniert, muss man eine Schriftkodierung benützen, in der die Buchstaben Glyphen sind, und nicht r, s, t mit einem Punkt darunter.
Gut zu wissen. Danke für die Berichtigung :)

Grüße

von u_fischer » Sa 8. Feb 2014, 11:18

cgnieder hat geschrieben:
pdfLaTeX kann nicht wirklich Unicode im Gegensatz zu LuaLaTeX oder XeLaTeX. Es kann Ascii-Zeichen. Die anderen sind aus Sicht von pdfLaTeX eigentlich zwei oder drei Zeichen, von denen das erste als Makro aktiv wird und je nachdem, was folgt, den entsprechenden LaTeX-Befehl einfügt. »ä« ist für pdfLaTeX nur eine komplizierte Weise »"{a}« zu schreiben.

Dass das in \hyphenation nicht funktioniert, wundert mich nicht.
Aber nicht mit deiner Begründung: Auch ü oder ß sind kein ASCII, dennoch hat pdflatex keine Probleme mit \hyphenation{grü-ßen} - sofern \usepackage[T1]{fontenc} geladen ist, d.h. solange ü bei der Ausgabe ein echter Glyph ist und nicht ein Buchstabe u mit einem Akzent drüber.

Damit dṛṣṭi funktioniert, muss man eine Schriftkodierung benützen, in der die Buchstaben Glyphen sind, und nicht r, s, t mit einem Punkt darunter.
Bachwels hat geschrieben:Verzichten kann ich auf den aber nicht, also muss ich mich wohl mit den typographisch schwächeren Ergebnissen abfinden.
Die du immer noch nicht bewiesen hast, und die ich auch nicht glaube: lualatex basiert auf pdflatex und hat daher mindestens die gleichen Fähigkeiten.

von cgnieder » Sa 8. Feb 2014, 10:12

Ich bin mir ja nicht sicher, ob das Nicht-Verwenden des Pakets wirklich einfacher ist, als es zu verwenden...
Bachwels hat geschrieben:mit PdfLatex nicht zu kompilieren ist, weil es bei \hyphenation Schwierigkeiten mit den Unicode-Zeichen gibt. (Kein Problem tritt auf, wenn ich diesen Befehl weglassen, aber dann fällt wieder woanders etwas um und es gibt Probleme bei der Silbentrennung...) - Mich erinnert das ein bisschen an gewisse Slapstickszenen bei Chaplin ;)
pdfLaTeX kann nicht wirklich Unicode im Gegensatz zu LuaLaTeX oder XeLaTeX. Es kann Ascii-Zeichen. Die anderen sind aus Sicht von pdfLaTeX eigentlich zwei oder drei Zeichen, von denen das erste als Makro aktiv wird und je nachdem, was folgt, den entsprechenden LaTeX-Befehl einfügt. »ä« ist für pdfLaTeX nur eine komplizierte Weise »"{a}« zu schreiben.

Dass das in \hyphenation nicht funktioniert, wundert mich nicht. Wenn Du das willst, brauchst Du eine Engine, die echt mit Unicode-Input umgehen kann, wie eben LuaLaTeX.

Grüße

von Bachwels » Sa 8. Feb 2014, 07:54

Ja, naja. Ich sag’s ja: Wenn man auf der einen Seite einen Fortschritt erreicht, kracht auf der anderen wieder etwas zusammen. Diesmal ist es, dass der Befehl \hyphenation unbenutzbar wird, weil er diese Sonderzeichen nicht verträgt. Bei LuaLatex geht es problemlos, bei PdfLatex nicht. Verzichten kann ich auf den aber nicht, also muss ich mich wohl mit den typographisch schwächeren Ergebnissen abfinden. Oder gibt es eine Möglichkeit, den Befehl trotzdem wirksam werden zu lassen?

Beispiele an denen man das sehen kann:
\documentclass{scrbook}

\usepackage[ngerman]{babel}
\usepackage{kpfonts}
\usepackage{fontspec}
\setmainfont[Numbers=OldStyle]{Baskerville}

\usepackage{geometry}
\usepackage{microtype}
\KOMAoptions{DIV=last}

\hyphenation{dṛṣ-ṭi
Ma-hā-praj-ñā-pā-ra-mi-tā-sū-tra}
\begin{document}

dṛṣṭi

\end{document}
Wird mit LuaLatex problemlos richtig kompiliert. Wohingegen
\documentclass{scrbook}

\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{kpfonts}

\usepackage{geometry}
\usepackage{microtype}
\KOMAoptions{DIV=last}
\usepackage{newunicodechar}

\newunicodechar{ā}{\={a}}
\newunicodechar{Ā}{\={A}}

%[einige weggelassen]

\newunicodechar{ṛ}{\d{r}}
\newunicodechar{ṝ}{\d{\={r}}}
\newunicodechar{Ṛ}{\d{R}}
\newunicodechar{ṣ}{\d{s}}
\newunicodechar{Ṣ}{\d{S}}
\newunicodechar{ś}{\'{s}}
\newunicodechar{Ś}{\'{S}}
\newunicodechar{ṭ}{\d{t}}
\newunicodechar{Ṭ}{\d{T}}

\hyphenation{dṛṣ-ṭi
Ma-hā-praj-ñā-pā-ra-mi-tā-sū-tra}

\begin{document}

dṛṣṭi

\end{document}
mit PdfLatex nicht zu kompilieren ist, weil es bei \hyphenation Schwierigkeiten mit den Unicode-Zeichen gibt. (Kein Problem tritt auf, wenn ich diesen Befehl weglassen, aber dann fällt wieder woanders etwas um und es gibt Probleme bei der Silbentrennung...) - Mich erinnert das ein bisschen an gewisse Slapstickszenen bei Chaplin ;)

von Bachwels » Fr 7. Feb 2014, 10:18

Das ist natürlich die bequemste und übersichtlichste Methode. Vielen Dank für diesen Tip. Darauf wäre ich nie gekommen...

EDIT: In der Paketdokumentation fand ich gerade, dass es noch einfacher (also auch ohne das Paket geht), nämlich so:
\makeatletter
\@namedef{u8:\detokenize{ū}}{\={u}}
\@namedef{u8:\detokenize{Ū}}{\={U}}
[...]
\@namedef{u8:\detokenize{ḍ}}{\d{d}}
\@namedef{u8:\detokenize{Ḍ}}{\d{D}}
\@namedef{u8:\detokenize{ṛ}}{\d{r}}
\@namedef{u8:\detokenize{ṝ}}{\d{\={r}}}
\@namedef{u8:\detokenize{Ṛ}}{\d{R}}
\@namedef{u8:\detokenize{ṣ}}{\d{s}}
\@namedef{u8:\detokenize{Ṣ}}{\d{S}}
[...]
\makeatother
Ich habe keine Ahnung, was das bedeutet, aber es funktioniert... Nochmals besten Dank für den Tip!!!

Da hätte ich nun gleich noch eine weitere Frage: Ich kann nun eine Datei anlegen, in der ich alle diese Definitionen sammele, und diese dann per \input in das Projekt einbinden. Schöner wäre natürlich, ich müsste die Datei nicht jedem Projektverzeichnis gesondert hinzufügen, sondern könnte eine erstellen, die dann in alle Projekte eingebunden werden kann, so dass auch eventuelle Fehlerkorrekturen immer sofort bei allen vorhanden sind. Geht das, ohne dass ich in die Tiefen der Programmierung vordringen muss?

von cgnieder » Do 6. Feb 2014, 19:52

Bachwels hat geschrieben:
u_fischer hat geschrieben:dṛṣṭi kannst du auch mit pdflatex benützen.
Aha. Das ist interessant. Muss ich mal ausprobieren. Dazu muss ich zwar erst mal die Codes der jeweiligen Zeichen herausbekommen [...]
Nicht unbedingt:
\documentclass{article}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{newunicodechar}
\newunicodechar{ṛ}{\d{r}}
\newunicodechar{ṣ}{\d{s}}
\newunicodechar{ṭ}{\d{t}}
\begin{document}
dṛṣṭi
\end{document}
Grüße

von Johannes_B » Do 6. Feb 2014, 19:09

Standardmäßig werden nicht alle (es gibt sooo viele) codes festgelegt, eventuell muss man noch welche von Hand eintragen. Das reicht ja aber einmal pro Dokument (und Copy/paste für andere Dokumente).

http://www.utf8-zeichentabelle.de/unicode-utf8-table.pl

Einmal richtig machen ist hier die Devise.

von Bachwels » Do 6. Feb 2014, 18:53

u_fischer hat geschrieben:dṛṣṭi kannst du auch mit pdflatex benützen.
Aha. Das ist interessant. Muss ich mal ausprobieren. Dazu muss ich zwar erst mal die Codes der jeweiligen Zeichen herausbekommen, aber das wird sich ja vermutlich irgendwie machen lassen. Mal sehen. Danke für den Tip.

von u_fischer » Do 6. Feb 2014, 17:51

Bachwels hat geschrieben:
u_fischer hat geschrieben:Sollte nicht sein und kann ich auch nicht bestätigen. Vielleicht machst du was falsch (oder deine Schrift).
Da muss ich mal meine Schrift fragen. Aber wenn der Text in der einen Konfiguration sehr gut aussieht und in der anderen wie ein Schweizer Käse, kann es ja eigentlich nur an den Sachen liegen, die sich geändert haben, und nicht an denen die gleichgeblieben sind. Zu denen gehört die Schrift. Es ist also schwer vorstellbar, dass es an ihr liegt. Es handelt sich übrigens um Linux Libertins O.
Da pdflatex type1-Schriften, lualatex (bei korrekter Bedienung) opentype-Schriften benutzt, sind die nie gleich. Abgesehen davon kannst du ein normales pdflatex Dokument nicht ohne Änderungen mit lualatex benützen. Also: bist du dir sicher, dass dein lualatex-Dokument korrekt ist?
Ich finde jedenfalls, dass ein Text besser zu lesen, zu korrigieren und zu gestalten ist, wenn da z. B. dṛṣṭi steht und nicht d\d{r}\d{s}\d{t}i. Aber ob ich dafür nun wiederum in Kauf nehmen möchte, dass das Ergebnis typographisch unbefriedigend ist...
.
dṛṣṭi kannst du auch mit pdflatex benützen.
\documentclass{article}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{1E5B}{\d{r}}
\DeclareUnicodeCharacter{1E63}{\d{s}}
\DeclareUnicodeCharacter{1E6D}{\d{t}}
\begin{document}
dṛṣṭi
\end{document}
\documentclass{article}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}						
\usepackage[utf8]{inputenc}
\DeclareUnicodeCharacter{1E5B}{\d{r}}
\DeclareUnicodeCharacter{1E63}{\d{s}}
\DeclareUnicodeCharacter{1E6D}{\d{t}}
\begin{document}
dṛṣṭi 
\end{document}

von Johannes_B » Do 6. Feb 2014, 17:33

Du musst bedenken in welcher Zeit TeX entwickelt wurde. Damals hatte niemand einen PC, da waren Rechner noch Raumgroß, und Speicher war rare. Aus dieser Zeit stammt noch diese »Buchstabenbastelei«.

Bist du dir sicher, dass du die gleiche Schrift benutzt?
Ich bin mir gerade nicht sicher, welche Schrift (dateiendung) bei Einbinden des Pakets libertine geladen wird.

Nach oben