EPS in DXF umwandeln

Mittwoch, Mai 24, 2017 by crypti

Nachdem der Cutworks-Webshop inzwischen auch Kunststoff-Teile im Sortiment hat und nach Aussage unseres Kunststoff-Partners ein Großteil der Kunden mit EPS-Dateien arbeitet, habe ich mich mal im Netz umgeschaut, wie man ein EPS in ein DXF umwandeln kann, ohne das über einen Cloud-Service oder teure Zusatz-Software abbilden zu können.

Nach ziemlich langem Suchen bin ich auf ein Linux-Forum gestoßen, bei dem der entsprechende Blogger eine Umwandlung mit Hilfe von pstoedit durchführt.

WOW - ein Gratis-Tool auf der Linux-Kommandozeile, dass genau die Dinge macht die ich brauche - ich bin begeistert. Nachdem ich dann endlich wusste, wie das Tool heisst, konnte ich auf der sourceforge-Seite sogar eine Windows-Version herunterladen und installieren.

Die ersten Tests zeigten zwar, dass zwingend eine Installation von Ghostscript notwendig ist (die 32bit-Version - egal, ob pstoedit 64 oder 32 bit ist). Nach der Installation konnte ich mit dem folgenden Befehl eine EPS erfolgreich in eine DXF umwandeln:

pstoedit.exe -dt -f dxf:-polyaslines <Quelldatei>.eps <Zieldatei>.dxf 

Optional kann man mit -mm das Modell als mm umwandeln, standardmäßig wird sonst inch benutzt!

Das ganze lässt sich ziemlich leicht als Java-Service im Backend über ProcessBuilder bzw. Runtime.exec() aufrufen, so dass man schwupp die wupp - in kürzester Zeit auch EPS-Dateien lesen kann.

Nachtrag 25.05.2017:

Bei der Integration in Java führte die Ausführung von pstoedit immer dazu, dass nur der DXF-Header erzeugt wurde, nach dem Header brach die Generierung ab. Hintergrund ist, dass bei Aufruf von gswin32c in das Standard-Temp-Verzeichnis (C:\Users\%userName%\Appdata\LocalLow\Temp\2) geschrieben wird, welches als System-Account wohl nicht zur Verfügung steht. Daher führt der Ghostscript-Aufruf wohl zu einer leeren Datei.
Zur Behebung des Problems muss man den Tomcat-Dienst dann einfach als priviligierter Nutzer (z.B. Administrator) ausführen, anschließend funktioniert die Umwandlung ohne Probleme.

Rest-Services mit Jersey - JAXB Internal Server Error 500

Donnerstag, April 30, 2015 by crypti

Für den neuen Webshop benötige ich als Schnittstelle zum ERP einen REST-Webservice.
Da die Daten relativ umfangreich sind, sollen Sie als XML exportiert werden.

Es gibt ja ziemlich gute Tutorials im Web, z.B. auch bei Vogella:

http://www.vogella.c … ls/REST/article.html.

Für die einfachsten Sachen, z.B. die Rückgabe als String hat das soweit funktioniert. Als ich mich jedoch daran gemacht habe, JAXB zu nutzen, fingen die Probleme an.

Immer und immer wieder habe ich einen Internal Server Error 500 von Tomcat / Winstone erhalten.
Warum? - Keine Ahnung.

Leider hat der Tomcat einfach mal komplett gar nix ausgegeben.

Nach langer Suche im Web und in Foren, kam ich auf einen Hinweis mit dem @XMLAttribute-Tag.

Also habe ich mal eine noch einfachere Klasse erstellt und siehe da, es ging auch nicht. Bis ich alle Annotations aus der JAXB-Klasse (bis auf @XmlRootElement) entfernt habe. Plötzlich kam der Output zurück. Blöd nur, dass ich verschiedene Felder der Klasse als Attribut und nicht als Feld definieren wollte.

Schritt für Schritt habe ich versucht wieder die Attribute einzubauen, aber man bekam wiederum nur einen HTTP 500 ohne irgendeine Fehlermeldung.

Hm - wird wohl irgendwie JAXB daran Schuld sein. OK - daraufhin habe ich die Klasse einfach mal direkt mit JAXB gemarshalled und - Wunder oh Wunder - er zeigte mir verschiedene Exceptions bzw. Fehler an.

Die ganze Problematik dabei war eigentlich folgende:

JAXB erwartet pro Feld ENTWEDER einen Getter ODER eine Annotation.

Da ich aber Pojo-Like natürlich getter und setter aus Eclipse generiert habe, sind sich die Sachen in die Quere gekommen.

ALSO MERKE:

JAXB-Klassen dürfen entweder Annotations an den Feldern haben und keine Getter, oder aber GETTER und keine Annotations.

Ohne Annotations (also mit Gettern) wird das Feld zum XMLElement, mit Annotations kann es entweder XmlElement oder XmlAttribut werden.

Also merken!!