inkscape2tikz Exporter - wie installieren?
  • spoogy Juli 2010
    Hallo,

    ich möchte gerne aus Inkscape nach TikZ konvertieren.
    Es gibt ein Plug-In namens inkscape2tikz, was heir zu finden ist: http://code.google.com/p/inkscape2tikz/

    Allerdings scheitert kommt eine Fehlermeldung, wenn ich die Datei exportiere:

    "Diese Erweiterung benötigt "python-lxml". Diese erhalten Sie unter "http://cheeseshop.python.org/pypi/lxml/" oder durch ein Packet ihres Packetmanagers (z.B.: sudo apt-get install python-lxml)"

    Nun habe ich probiert lxml zu installieren. Das klappt leider auch nicht. Folgendes habe ich in das OS X Terminal eingegeben laut Anleitung: http://codespeak.net/lxml/installation.html#installation

    STATIC_DEPS=true easy_install lxml==dev


    Nach einer Weile des Kompilierens kommt nach 8 Minuten folgender Fehler heraus:

    lipo: can't figure out the architecture type of: /var/folders/1U/1U092w1VHO8jB+TcfBvfU++++TI/-Tmp-//cc8rLTjU.out
    error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1


    Hat jemand eine Idee, was ich machen kann?
    Ihr würdet mir sehr helfen damit.

    Viele Grüße
    Spoogy :)
  • ~suv Juli 2010
    Du arbeitest mit Snow Leopard, vermute ich?

    Falls ja, schlechte Nachrichten: mit den aktuellen Inkscape Versionen (0.47, ebenso 0.48pre1) funktionieren Erweiterungen, die lxml oder numpy Module importieren, nicht auf Snow Leopard (Inkscape hat diese Module eigentlich mit dabei). Es gibt auch keinen allgemein bekannten workaround, den ich empfehlen könnte (u.a. auch, weil ich selbst noch mit Leopard arbeite).

    Siehe Bug #482993 in Inkscape: “Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard)” (das Problem ist bekannt, Michael (packager für osx) arbeitet daran, ungünstigstenfalls gibt's eine 0.48.1 Version falls es nicht mehr rechtzeitig für 0.48 gelöst wird).
  • spoogy Juli 2010
    Danke, ~suv,

    richtig, ich bin auf Mac OS X 10.6.4 (Snow Leo)

    Das scheint ja eine lange Diskussion mit einigen Lösungsvorschlägen zu sein, bei denen ich aber die Erfolgswahrscheinlichkeit nicht beurteilen kann.

    Ich benutze die aktuelle Developer Version 0.48+devel r9641 vom 25.07.2010. Geht es dort auch nicht?

    Gibt es irgendeine Möglichkeit, die mir dazu verhilft, diesen inkscape --> TikZ Exporter zum Laufen zu bringen? Ich mein, das Problem scheint ja seit ca 9 Monaten bekannt zu sein?
  • ~suv Juli 2010
    spoogy schrieb:
    Ich benutze die aktuelle Developer Version 0.48+devel r9641 vom 25.07.2010. Geht es dort auch nicht?
    Nein.

    spoogy schrieb:
    Gibt es irgendeine Möglichkeit, die mir dazu verhilft, diesen inkscape --> TikZ Exporter zum Laufen zu bringen?
    Ich kann beschreiben, was ich - hätte ich Snow Leopard installiert - als erstes versuchen würde:
    • das Shell-Skript Inkscape.app/Contents/Resources/bin/inkscape in einem plain text Editor öffnen (Sicherheitskopie nicht vergessen!)
    • Nach der Zeile 24 mit
      export PATH=\"/usr/texbin:/opt/local/bin:/sw/bin/:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:$CWD:$PATH\"
      eine neue Zeile einfügen mit diesem Inhalt:
      export VERSIONER_PYTHON_VERSION=2.5
    • Done. Inkscape neu starten und testen, ob die Module 'lxml' und 'numpy' jetzt erfolgreich importiert werden können.

      Die Erklärung findest Du im bug report, in Kürze: die bei Inkscape.app mitgelieferten Python-Module sind für die Architekturen PPC und i386 (Python 2.3-2.6) vorhanden und werden in einem separaten (spawned) Python-Prozess - die default Python-Version des Systems, falls in $PATH (siehe Zeile 24 im vorhin erwähnten Shell-Skript) keine andere Version zuerst gefunden wird - importiert. Da auf Snow Leopard jedoch die default Python-Version (2.6) in x86-64 (64bit) installiert ist, scheitert der Import der Module für 2.6, da 32bit.
      Die eingefügte Umgebungsvariable $VERSIONER_PYTHON_VERSION ist ein Apple-spezifischer Selektionsmechanismus auf Snow Leopard, um aus Kompatibilitätsgründen anstatt Python 2.6 (64bit) Python 2.5 (32bit wie bei 10.5.8 Leopard) zu starten.

    spoogy schrieb:
    Ich mein, das Problem scheint ja seit ca 9 Monaten bekannt zu sein?
    Muss ich wirklich den ungeliebten alten Spruch hervorkramen? ;-) «Du weisst, was Open Source …»

    Nachtrag: zu Deinem Installations-Problem nach
    spoogy schrieb:
    STATIC_DEPS=true easy_install lxml==dev
    kann ich leider keinen Lösungs-Vorschlag beitragen (hab allerdings nicht richtig danach gegoogled), ausser sicherzustellen, dass etwaige halbfertige Installations-Reste vollständig entfernt werden - solltest Du nicht inzwischen das Problem behoben haben.
    spoogy schrieb:
    lipo: can't figure out the architecture type of …
    Hast Du allenfalls einen Kompiler installiert und verwendet, der nicht aus Apple's Küche kommt und der daher keine Universal binaries in einem Schritt zusammenbauen kann? Oder stört eine vorhandene MacPorts-Installation anderweitig (z.b. durch Verlinken mit neueren oder inkompatiblen Versionen etwaiger System-Bibliotheken) den Build-Prozess? -> google fragen ;)
  • spoogy August 2010
    Hi ~suv,

    vielen Dank, für dein ausführliche Hilfe!
    Bevor ich dein posting gelesen hatte, habe ich ein Patch gefunden, was vermutlich so ähnlich sein könnte, wie das, was du beschreibst.
    Mit dem Patch klappt es jetzt!

    Schau mal: https://bugs.launchpad.net/inkscape/+bug/482993/comments/17

    Jetzt laufen alle extentions, die lxml benötigen!


    ~suv schrieb:
    [quote]
    spoogy schrieb:
    lipo: can't figure out the architecture type of …
    Hast Du allenfalls einen Kompiler installiert und verwendet, der nicht aus Apple's Küche kommt und der daher keine Universal binaries in einem Schritt zusammenbauen kann? Oder stört eine vorhandene MacPorts-Installation anderweitig (z.b. durch Verlinken mit neueren oder inkompatiblen Versionen etwaiger System-Bibliotheken) den Build-Prozess? -> google fragen;) [/quote]

    Nein, hab eigenmächtig keine weiteren Kompiler installiert. Nur Apple´s XCode.

    Danke und viele Grüße
  • ~suv August 2010
    spoogy schrieb:
    Bevor ich dein posting gelesen hatte, habe ich ein Patch gefunden, was vermutlich so ähnlich sein könnte, wie das, was du beschreibst.
    Mit dem Patch klappt es jetzt!
    Wenn Du im bug report nach comment #17 weiterliest, ... -> obiger Vorschlag wurde dort diskutiert (bzw. als Ansatz schon in comment #11 gelistet) und ist eine Weiterentwicklung des patch, die eben nicht gleich den Pfad ($PATH) umbiegt...

    Aber gut zu wissen, dass es jetzt klappt bei Dir.
  • spoogy August 2010
    Welches comment nach #17 im Bug-Report ist die Weiterentwicklung?
    Kann ich meinen Patch, der anscheinend zuviel verhunzt, wieder rückgängig machen?
  • ~suv August 2010
    spoogy schrieb:
    Kann ich meinen Patch, der anscheinend zuviel verhunzt, wieder rückgängig machen?
    Kein backup gemacht vor dem patchen? ;-) Nächstes mal daran denken - kann Ärger ersparen und dafür Time Machine zu bemühen wäre mit Kanonen auf Spatzen... ('cp inkscape inkscape-orig.sh' unmittelbar vor dem patchen).

    spoogy schrieb:
    Welches comment nach #17 im Bug-Report ist die Weiterentwicklung?
    Liegt nicht als neuer patch vor, nur per Diskussion die Bestätigung, dass es funktioniert... Ich denke, lass es mal so, wie's jetzt für Dich funktioniert - letztenendes bewirken beide Vorschläge dasselbe: Inkscape startet Python 2.5 in 32bit mode in einem separaten Prozess und der kann dann die mitgepackten Module 'lxml' und 'numpy' importieren, wenn's von einem Erweiterungs-Skript verlangt wird.

    Ausserdem wird diese Änderung bei Deinem nächsten update auf z.B. eine neue Entwicklerversion eh neu zu erstellen sein (solange das Problem noch nicht grundsätzlich für alle neuen packages gefixt ist), da sie ja innerhalb des packages geschieht und daher nur für das jeweilige Inkscape.app gilt.
  • spoogy August 2010
    Ok, alles klar. Ich lass das am besten so.

    Der Interesse halber:
    1) Warum das Anhängen eines '.sh', wenn das original keine Endung hat?

    2) Ich dachte, der Patch ändert systemweit irgendetwas?
    Auszug aus Patch:
    (...)
    export PATH=\"/usr/texbin:/opt/local/bin:/sw/bin/:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:$CWD:$PATH\"
    (...)
    + export PATH=\"/System/Library/Frameworks/Python.framework/Versions/2.5/bin:$PATH\"

    3) Wie ist die Syntax zu verstehen, wenn Doppelpunkte und $-Zeichen verwendet werden?
  • houzhouz August 2010
    Die Variable PATH enthält eine Liste mit Verzeichnisnamen.
    ‚:‘ ist das Trennzeichen zwischen den einzelnen Verzeichnissen.
    ‚$‘ bedeutet, dass im Folgenden der Inhalt der Variablen gemeint ist. „$PATH“ ist also der Inhalt der Variablen PATH. Die Variable CWD ist das aktuelle Verzeichnis.
    Die Zeile „export PATH="/System/Library/Frameworks/Python.framework/Versions/2.5/bin:$PATH"“ bewirkt also, dass PATH auf das Verzeichnis „/System/Library/...“, gefolgt vom alten Inhalt von PATH gesetzt wird. Es wird also in Zukunft zuerst in dem neuen Pfad nach Programmen gesucht, danach an den alten Stellen. Das ganze gilt aber nur innerhalb des Scriptes, in dem das „export“ steht (und von dort aus aufgerufenen Scripten/Programmen), ändert am System also nichts.
  • ~suv August 2010
    spoogy schrieb:
    1) Warum das Anhängen eines '.sh', wenn das original keine Endung hat?
    Persönliche Angewohnheit - es ist ja ein Shell-Skript, und mit der Endung sehe ich das sofort, im Terminal oder im Finder, und kann es auch einfach im Text-Editor meiner Wahl öffnen.

    spoogy schrieb:
    2) Ich dachte, der Patch ändert systemweit irgendetwas?
    Nein - dann hätte ich davor gewarnt... ;-)

    Im Einzelnen:
    --- inkscapeoriginal	2010-05-30 09:58:10.000000000 -0700
    +++ inkscape 2010-06-08 16:30:06.000000000 -0700
    es wird nur die Datei 'inkscape' verändert

    @@ -23,6 +23,13 @@
    Der Bereich '6 Zeilen, beginnend mit Zeile 23' wird geändert und ist neu '13 Zeilen, beginnend mit Zeile 23'

     #	LaTeX distribution for Mac OS X
    export PATH=\"/usr/texbin:/opt/local/bin:/sw/bin/:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:$CWD:$PATH\"

    bleibt unverändert (Zeilen 23-25)

    +#Force Inkscape to use python 2.5 for Snow Leopard (MacOS X 10.6) to allow extensions to operate properly:
    +OSSTRING=`sw_vers -productVersion | cut -c 1-4 `
    +if [[ \"$OSSTRING\" == \"10.6\" ]]; then
    + export PATH=\"/System/Library/Frameworks/Python.framework/Versions/2.5/bin:$PATH\"
    +fi
    +
    +
    wird eingefügt (7 neuen Zeilen)

     # Setup PYTHONPATH to use python modules shipped with Inkscape
    ARCH=`arch`
    PYTHON_VERS=`python -V 2>&1 | cut -c 8-10`
    bleibt unverändert (Zeilen 33-35)

    spoogy schrieb:
    3) Wie ist die Syntax zu verstehen, wenn Doppelpunkte und $-Zeichen verwendet werden?
    [ulist][*]$ kennzeichnet einen Variablennamen,
    [*]Doppelpunkt ist der delimiter (Trennzeichen) einer Auflistung von Suchpfaden, die in $PATH abgespeichert werden,
    [*]export $PATH bewirkt, dass die Variable nicht nur für den aktuellen Prozess gilt, sondern die Prozesse, die davon gestartet werden, diese geänderte Variable mitvererben (in diesem Falle ist es der Prozess 'inkscape-bin', der am Ende des Skripts gestartet wird, und der diesen geänderten $PATH dann verwendet, um das zuerst darin gefundene "python" executable aufzurufen, wenn eine Erweiterung ausgeführt wird (mit dem patch wird das immer '/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python' sein).
  • spoogy August 2010
    Ist ja genial!

    Vielen Dank, ihr beiden. Ich lern immer was dazu.

    Allerdings: Die Variable PATH kann ich auch aus dem Terminal aufrufen: Warum bewirkt dann die im Skript ausgeführte Änderung dieser Variablen nur lokal (für Inkscape) eine Änderung, und nicht systemweit?
  • houzhouz August 2010
    Wie gesagt, das wird nur an aufgerufene Programme „vererbt“, aber nicht nach außen gegeben.
  • ~suv August 2010
    Bash Guide for Beginners > The Bash environment > Variables: Exporting variables
    ubuntuusers.de › Wiki › Umgebungsvariable

    (den Text im ubuntu-wiki hab ich nur überflogen, auf der Suche nache dt. Shell-Tutorials, kann daher die Qualität und etwaige Differenzen zur Verwendung der Shell unter Mac OS X nicht einschätzen)
  • spoogy August 2010
    Alles klar.
    Vielen Dank!

Hey Fremder!

Sieht so aus als wenn du neu hier bist. Wenn du mitmachen willst, drücke einen dieser Buttons!

In dieser Diskussion