Allgemein > Allgemeine Diskussion

Spielt das Betriebssystem eine Rolle?

<< < (2/2)

RobUr:
Hallo Harm,

das wichtigste vorab:
• Output: stimmt
• Fehlermeldung: keine
• LP/OS: Lily 2.14.2 auf Mac OS X 10.4.11

Randbeobachtung aus purer Experimentierlust: Wenn #"TextScript" durch #'TextScript (string wird erwartet) ersetzt wird, landet die rote Linie an genau der Stelle wie in deinem PDF #1.
Mögliche Ursachen: (a) unkorrektes Anführungszeichen (z.B. zwei Apostrophe); (b) unterschiedliche Textkodierung.

Viele Grüße, Robert

harm6:
Hallo Robert,

vielen herzlichen Dank. Jetzt fehlt nur noch jemand, der es auf windows testet.

Zu Deiner Randbeobachtung:

Die Verschiebung der roten Linie unter das Notensystem, wie in meinem ersten PDF, bedeutet, daß sie von der Funktion \centerGrobBetween nicht angesprochen wird, sondern als ganz normales markup erscheint.

Wenn Du "TextScript" durch 'TextScript ersetzt muß das so sein.

An ein Problem mit der Zeichenkodierung kann ich auch nicht glauben, denn wie ist es dann möglich, daß ich das zweite PDF erzeugen kann (mit korrekter roten Linie), indem ich aus dem zweiten score eine Stimme auskommentiere? Außerdem ist dieses Verhalten ein bislang singuläres Ereignis bei mir. Wenn es an der Zeichenkodierung liegt würde ich häufigere Probleme erwarten.

Mein Problem war bislang nur mit 64-bit Ubuntu reproduzierbar.

Danke und Viele Grüße,
  Harm

Arnold:
Hallo Harm,

nur ein paar Gedanken:

#"TextScript" ist ein String mit einem Textinhalt.
#'TextScript ist ein Symbol mit diesem symbolischen Namen.

Sollten da GUILE-Vergleichsfunktionen in 32-Bit- und 64-Bit-Variante unterschiedlich reagieren?

harm6:
Hallo zusammen,

vielen Dank allen, die ihre Ergebnisse und Gedanken mitgeteilt haben.

Ich habe mittlerweile "2.15.13" zusätzlich installiert. Und mit dieser Version klappt alles.
Ich vermute dann mal, daß in der "2.14.2"-Version irgendwo der Wurm drin ist. Interessanterweise klappt das Kompilieren mit "2.14.2" manchmal (aber nicht immer), wenn ich das file vorher mit "2.15.13" kompiliert habe. Wie das möglich ist ahne ich auch nicht.

Gruß,
  Harm

RobUr:
Hallo Harm,

ich kann ein ähnliches Phänomen auf meiner Maschine beobachten:
In (äußerst) seltenen Fällen – und dann immer nach minimalen Änderungen im Quelltext (dabei geht es nicht nur um kommastellenweises Verrücken verschiedener Zeichen, auch – noch viel seltener – Änderung bspw. der Schriftart) – ist im PDF keine Änderung zu sehen. Ich kann mir nur einige Gründe zusammenreimen, ohne ihnen wirklich auf die Schliche gekommen zu sein:
(a) Die interne PDF-Vorschau hakt (Editor: TeXShop 2.37 unter Mac OS X 10.4.11).
(b) Der Editor speichert vorm Kompilieren unbemerkt nicht ab.
(c) Betriebssystem oder Lily oder Editor oder PDF-Previewer arbeiten mit einem undokumentierten Cache, der nicht richtig funktioniert (fehlerhafte Zugriffsberechtigung/willkürliche Aktualisierung?).
(d) Sonstwas ;)

Mich wundert bei der PDF-Anzeige allerdings, dass ein offensichtlich identisches Dokument angezeigt wird, obwohl mein BASH-Script vor dem Compileraufruf das gleichnamige PDF per rm -rf ${1%\.ly}.pdf löscht! (Genau wegen dieses Phänomens hatte ich bereits in 2.12 diese Zeile eingebaut.) Folglich muss es irgendwo am Editor, bei Lily oder im OS liegen.

Besonders nervtötend ist dieses Verhalten natürlich beim Entwickeln und generellen Layoutänderungen. Ich verdränge gewisse Stunden, die ich mit zunehmender Verzweiflung wirsch damit verbrachte, alle Contexte wegen einer Änderung durchzuprobieren, nur um später festzustellen, dass ich bereits im ersten Versuch den richtigen Context angesprochen hatte, dies jedoch nicht dargestellt wurde *grummel*

Vielleicht hast Du ja etwas mehr Geduld, diese möglichen Fehlerursachen einmal zu prüfen ;)

Ach so – gerade fällt mir eine zusätzliche Fehlerquelle ein: Was, wenn ein Hardwaredefekt vorliegt? Es genügte ja schon ein defekter RAM-Sektor, der nicht erkannt und trotzdem beschrieben/gelesen wird …

Unverzagt beste Grüße, Robert

Navigation

[0] Themen-Index

[*] Vorherige Sete