Merkwürdiges Verhalten von epdf unter ArcOS

[Damon]

Beim Versuch, unter ArcOS mit epdf zu drucken, erhalte ich die Meldung Distiller-Fehler 255. Merkwürdig ist dabei, daß ich mit dem gleichen Distiller unter ecs2.1 drucken kann. Ich verwende gs7.04. Alle Pfade sind richtig eingetragen. Irgendetwas muß unter ArcOS also fehlen. Hat jemand eine Idee?

[ak120]

Beim Versuch, unter ArcOS mit epdf zu drucken, erhalte ich die Meldung Distiller-Fehler 255. Merkwürdig ist dabei, daß ich mit dem gleichen Distiller unter ecs2.1 drucken kann. Ich verwende gs7.04.

Davon kann man leider nicht ausgehen, sobald RPM-Pakete installiert worden sind, welche einige Konflikte verursachen können.

Alle Pfade sind richtig eingetragen.

Um welche Pfade handelt es sich?

Irgendetwas muß unter ArcOS also fehlen. Hat jemand eine Idee?

Wenn Ghostscript in Kombination mit CUPS über RPM installiert wurde, handelt man sich eine Menge Probleme ein. Die Unverträglichkeit mit bereits bestehenden Anwendungen ist dabei nur ein Problembereich. Die Radikalkur wäre das vollständige Entfernen sämtlicher installierter CUPS- und Ghostscript-Pakete. Hierbei sind jedoch die Abhängigkeiten zu beachten. Anschließend kann man Ghostscript und CUPS aus ZIP-Archiven installieren. EPDF sollte auch mit späteren Versionen als 7.04 zusammenarbeiten können. Sicherlich ist dies keine Sache von 5 Minuten bringt aber als Ergebnis eine CUPS-Umgebung mit deutlich mehr Druckertreibern und Möglichkeiten und Ghostscript funktioniert auch wieder für andere Anwendungen außer CUPS.

[Damon]

Das ist ja wirklich ärgerlich! Dabei wollte ich von ecs auf ArcaOS umsteigen, um eben solche Probleme zu vermeiden! Aber natürlich danke für die Hinweise.

[Frank Wochatz]

Ich kann die Sache leider zur Zeit nicht verfolgen. Meine Arca Installation wird noch dauern, da meine Rechner nach einigem Bastelaufwand zur Zeit sehr gut mit eCs laufen. Never touch a running system, daher habe ich keine Testumgebung. Ev. lässt sich das Problem beheben, wenn man ein privates Environment für ePDF mit einer eigenen GS Version installiert. eDPF läuft auf jeden Fall auch mit neueren GS Versionen, ich benutze es selber all paar Tage.

Btw, wenn Abwärtkompatibilität (eine der Stärken des Systems der letzten 20 Jahre) mit der RPM-Installation über Bord geworfen wird ist das nicht gut, ich kann jetzt nach die neue Situation erforschen (dokumentiert ist ja scheinbar nichts), bei anderen Programmen sind die Entwickler gar nicht mehr da...

[Andi B.]

Btw, wenn Abwärtkompatibilität (eine der Stärken des Systems der letzten 20 Jahre) mit der RPM-Installation über Bord geworfen wird ist das nicht gut,..

Welche Kompatibilität wird durch rpm über Bord geworfen?

Ich weiß nicht, ob es so ist (ich schrieb 'wenn'), aber ich lese im OP, daß es offenbar Probleme gibt.

Btw die Sache ist so, daß es unterschiedliche GS Versionen gibt, und da gab es auch immer mal Verschlimmbesserungen, daher kann man mit ePDF mehrere installierte GS Versionen ansteuern und eine entsprechende GS Version über das Menü auswählen. Die GS Parameter werden deshalb auch alle über ePDF und nicht über Environment gesetzt. Keine Ahnung ob das noch geht, wenn bereits im OS ein GS fest verankert ist.

[ak120]

Btw, wenn Abwärtkompatibilität (eine der Stärken des Systems der letzten 20 Jahre) mit der RPM-Installation über Bord geworfen wird ist das nicht gut, ich kann jetzt nach die neue Situation erforschen (dokumentiert ist ja scheinbar nichts), bei anderen Programmen sind die Entwickler gar nicht mehr da...

Man kann sich behelfen mit folgender Vorgehensweise:
1. Eine Kopie der CONFIG.SYS (z.B. CONFIG.RPM) erstellen. Die problematischen Sachen aus der CONFIG.SYS herausschmeißen. Also LIBPATH und PATH um die unsinnigen Verzeichniseinträge erleichtern.
2. Wenn man unbedingt eines der vermeintlich neuen Programme verwenden möchte, dann nur über eine abgeschottete Ausführungsumgebung in welcher PATH gesetzt wird, und die Bibliotheken über BEGINLIBPATH erreichbar gemacht werden. Hier empfiehlt es sich auch sämtliche benötigte Umgebungsvariablen wie z.B. UNIXROOT zu setzen.
(Wem die Warnmeldungen von ANPM stören, kann auch noch die CONFIG.SYS umkopieren, also die alte unterschieben nachdem die zuvor bearbeitete gesichert wurde. Und das ganze nach dem Verlassen wieder umkehren)

Zumindest können bestehende Programme dann in der normalen Umgebung wie gewohnt genutzt werden. Zumindest kann ich jetzt wieder das in OS/2 mitgelieferte Dienstprogramm LINK nutzen und kein nutzloses Programm gleichen Namens mit verkrüppelter Textausgabe drängelt sich über den PATH vor. Es gibt sicherlich noch weitere Beispiele für Namenskonflikte.

Bei dem RPM-Zeug sollte man sich auf das Wesentliche beschränken, und immer eine zuvor funktionsfähige Alternative bereithalten. Wer sich damit näher beschäftigen möchte, wird schnell feststellen, daß schon das Fundament (Bibliotheken und grundlegende Dienstprogramme) so marode ist, daß es schon fast verwunderlich ist wieviel trotzdem noch irgendwie läuft.
Als Spielplatz für Kids denen Linux zu langweilig geworden ist, mag das ganze noch eine fragwürdige Daseinsberechtigung haben - aber keineswegs für den verlässlichen Produktiveinsatz?

[Frank Wochatz]

Tut mir Leid Andi, jetzt hab ich versehentlich deinen Beitrag editiert statt darauf zu antworten. Das lag nicht in meiner Absicht, ich versuche mal den Beitrag wieder herzustellen.

[Andi B.]

Tut mir Leid Andi, jetzt hab ich versehentlich deinen Beitrag editiert statt darauf zu antworten. Das lag nicht in meiner Absicht, ich versuche mal den Beitrag wieder herzustellen.

Lass nur, war wohl eh nicht so wichtig

Nur das ePDF auch in einer rpm Umgebung problemlos läuft. Auch GSView. Und ja, ich kann die rpm Ghostscript Version in ePDF auswählen und nutzen. Und ich biege keine Pfade in der config.sys um. Außer den Punkt (.; ). Der wandert bei mir hinter die %UNIXROOT% Pfade. Damit immer die rpm dlls genutzt werden und nicht etwa irgendwelche alten Duplikate welche fälschlicherweise in irgendwelchen Programmverzeichnissen liegen. Das ist nämlich eins der Hauptprobleme von so manchem OS/2 Nutzer. Aber jeder soll sein System verbiegen wie er will. Auch wenn dann so manches nur mehr mit unnötigen Hindernissen oder auch gar nicht läuft....

[Damon]

Hallo Andy,

Ja, das Problem mit dem dll-Chaos habe ich unter ecs auch, deshalb wollte ich auf ArcaOS umsteigen.

Du schreibst, daß epdf bei Dir unter ArcaOS läuft? Heißt das, daß Du keine eingen GS-Umgebung verwendest? Wärst Du so nett und schreibst einmal ein Beispiel für eine Distiller-Einstellung?

Wie meinst Du das mit dem Punkt, der vom Libpath .; zu Unixroot wandert? Etwa so: SET UnixRoot=X:. ?

Dank im Voraus!

[Damon]

Problem ist gelöst! Ich hatte unter den Distillereinstellungen zwar x:\usr\bin\gsos2.exe eingetragen, aber den lib-Pfad aus der alten Installation stehen lassen!

Danke für die Tipps!

[Andi B.]

Wie meinst Du das mit dem Punkt, der vom Libpath .; zu Unixroot wandert?

ANPM (ArcaNoae Paket Manager) will den Libpath in der config.sys so ändern, dass ganz vorne der .; steht und erst danach die %UNIXROOT% Verzeichnisse. ANPM meckert auch jedesmal beim Aufruf, wenn dies nicht so drinnen steht. Solange bis ANPM es reparieren darf, oder man diese Überprüfung abstellt (irgendwo eine Einstellung in ANPM). Bei mir also würde das so aus sehen -

Code: Alles auswählen

LIBPATH=.;P:\USR\LOCAL\LIB;P:\USR\LIB; ...

Dies macht aber oft Probleme. Den wenn jemand fälschlicherweise in einem Programmverzeichnis eine shared lib liegen hat (ist leider häufig der Fall, vor allem bei alten Ports/Hacks von Paul wurde dies manchmal sogar vorgeschlagen), dann wird eventuell die alte, falsche dll geladen. Besser ist es, den .; hinter die %UNIXROOT% Verzeichnisse zu legen. Also bei mir sieht das dann so aus -

Code: Alles auswählen

LIBPATH=P:\USR\LOCAL\LIB;P:\USR\LIB;.; ....

Sollte es bei dieser Einstellung mit einem Programm doch ein Problem mit einer der neuen dlls (vom rpm) geben, dann sollte man in dieser Reihenfolge -
1) schaun ob es nicht eine neuere Version des Programms gibt welche auch mit den neuen dlls läuft
2) den Autor kontaktieren und über den Fehler informieren
3) als letzte Möglichkeit mit LIBPATHSTRICT behelfen

[Frank Wochatz]

Gut zu hören, dass es auch mit der GS-Installation in Arca erst einmal soweit funktioniert.

[HerwigB]

Hallo Frank,

mit dem GS 9.14 (aber auch unserem GS 9.18) gibts ein Problem mit ePDF (299-5):

Wenn die beiden Parameter -dUseCIEColor (der ist deprecated ab 9.11 und vor dem warnt GS ausdrücklich) und/oder -dFastWebView in der Parameterliste sind, dann crasht GS.

Es handelt sich womöglich um einen Upstream Bug, wir sind gerade am checken.

-dFastWebView lässt sich abwählen, aber -dUseCIEColor (zumindest hab ich das nicht gefunden) scheint immer in der Parameterliste, die ePDF an GS übergibt, zu sein.

LG,

[andreas]

welche version ist denn zu empehlen? und woher bekomme ich sie?
ich bekomme bei den version 8.71, 9.10 und 9.15 jeweils den distiller-code 255.
habe jeweils zum libpath die gs-pfade lib; resource\init; resource\font eingetragen.

[ak120]

welche version ist denn zu empehlen? und woher bekomme ich sie?
ich bekomme bei den version 8.71, 9.10 und 9.15 jeweils den distiller-code 255.
habe jeweils zum libpath die gs-pfade lib; resource\init; resource\font eingetragen.

Die letzte offizielle Version für OS/2 war 8.60:
https://sourceforge.net/projects/ghosts ... ript/8.60/

Alles was danach kompiliert wurde, ist entweder nur noch in Teilmengen nutzbar oder enthält irreführende Dokumentation. Ich wüßte z.B. nicht was die GS-Pfade im LIBPATH zu suchen haben? Am schlimmsten sind üblicherweise die Versionen, welche über YUM und RPM installiert werden sollen. Den letzten Beitrag von Herrn Herwig B. sollte man besser nicht zu ernst nehmen, da leider neben den möglichen tatsächlichen Beobachtungen etwas zu sehr herumspekuliert wird und Sachverhalte völlig aus dem Zusammenhang gerissen werden. Eine Version 9.11 von Ghostscript gab es nicht und es findet sich demnach nichts in den "Release Notes", was diese vagen Behauptungen auch nur ansatzweise stützen würde.

[axelwein]

welche version ist denn zu empehlen? und woher bekomme ich sie?
ich bekomme bei den version 8.71, 9.10 und 9.15 jeweils den distiller-code 255.
habe jeweils zum libpath die gs-pfade lib; resource\init; resource\font eingetragen.

also ich verwende ghostscript-9.04-os2-20111228 unter eCS 2.1. Da funktioniert sie wunderbar.
Erhältlich:
http://os2ports.smedley.id.au/index.php ... hostscript

Die Pfade sollten in ePDF eingetragen werden, nichts in die CONFIG.SYS!

Viele Grüße
Axel

[HerwigB]

Den letzten Beitrag von Herrn Herwig B. sollte man besser nicht zu ernst nehmen, da leider neben den möglichen tatsächlichen Beobachtungen etwas zu sehr herumspekuliert wird und Sachverhalte völlig aus dem Zusammenhang gerissen werden.

Was wie jeder Satz des Herrn ak120 völliger Unsinn ist...

Eine Version 9.11 von Ghostscript gab es nicht und es findet sich demnach nichts in den "Release Notes", was diese vagen Behauptungen auch nur ansatzweise stützen würde.

Schwallen ohne selber probieren, gell?

Das sagt der GS 9.18 Interpreter selber

U:\usr\bin\gsos2.exe -q -dNOPAUSE -dBATCH -dNOOUTERSAVE -dUseCIEColor -dNOSAVER -dPDFSETTINGS=/default -dProcessColorModel=/DeviceRGB -dColorImageResolution=72 -dGrayImageResolution=72 -dMonoImageResolution=300 -r72 -dDownsampleColorImages=false -dDownsampleGrayImages=false -dDownsampleMonoImages=false -dColorImageDownsampleType=/Subsample -dGrayImageDownsampleType=/Subsample -dMonoImageDownsampleType=/Subsample -dColorImageFilter=/FlateEncode -dGrayImageFilter=/FlateEncode -dMonoImageFilter=/FlateEncode -dCompatibilityLevel=1.2 -dAutoRotatePages=/PageByPage -dPreserveOverprintSettings=false -dEmbedAllFonts=true -dSubsetFonts=false -dNOPLATFONTS -dUCRandBGInfo=/Remove -dCompressPages=false -sDEVICE#pdfwrite -sOutputFile#K:\TEST\TEST.pdf U:\var\temp\POSTSCRIPT.880
GPL Ghostscript 9.18:

Use of -dUseCIEColor detected!
Since the release of version 9.11 of Ghostscript we recommend you do not set
-dUseCIEColor with the pdfwrite/ps2write device family.

Bitte also nicht rumschwallen, sondern selber probieren.

Wie gesagt, wenn -dUseCIEColor und -dFastWebView in der Parameterliste vorkommen, dann crasht 9.18 nachvollziehbar.
Es geht nicht darum PDFs zu erzeugen, es geht darum Lauffähigkeit von ePDF mit aktuellen GS Versionen sicherzustellen.

[HerwigB]

Der Bug tritt auch unter Win32 auf und ist somit Crossplattform.

[HerwigB]

https://bugs.ghostscript.com/show_bug.cgi?id=698354

[Frank Wochatz]

Hallo Leute, sorry lese gerade erst jetzt den Beitrag. Ich werden den Parameter mal entfernen und kurzfristige eine neue ePDF Version zur Verfügung stellen.

[HerwigB]

Hallo Frank,

danke vielmals!

Tatsächlich handelt es sich um einen Cross-Platform-GhostScript Bug. Der Crash mit -dUseCIEColor ist auch unter GS 9.14/9.18 win32 vorhanden. In der neuesten GS 9.21 win32 ist er jedenfalls beseitigt. Wir werden "unser" GS ebenfalls auf 9.21 bringen sobald zeitlich möglich.

-dUseCIEColor ist trotzdem deprecated.

[Sepp Mayr]

-dUseCIEColor ist trotzdem deprecated.

Wos wui ma des song?
-dUseCIEColor is jedenfois vaoidet. Oiso 's ned mehr ganz nei.

I griaß eich, da Sepp

[HerwigB]

Wos wui ma des song?
-dUseCIEColor is jedenfois vaoidet. Oiso 's ned mehr ganz nei.

Genau des.
Und nimms neamma. GS is bes waunnst es trotzdem tuast.
Und blederweis reisst GS 9.14/9.18 a no an Stern waunnst es trotzdem nimmst.
GS 9.21 wead des nemma tuan. Oba des homma no net.

[_diver]

Hallo Frank,

danke vielmals!

Tatsächlich handelt es sich um einen Cross-Platform-GhostScript Bug. Der Crash mit -dUseCIEColor ist auch unter GS 9.14/9.18 win32 vorhanden. In der neuesten GS 9.21 win32 ist er jedenfalls beseitigt. Wir werden "unser" GS ebenfalls auf 9.21 bringen sobald zeitlich möglich.

-dUseCIEColor ist trotzdem deprecated.

Ja der switch ist deprecated, aber dennoch dürfte GS nicht crashen. Ich bin gerade am testen einer gefixten version. Damit sollte es dann wieder gehen und auch -dFastWebView wieder. Der crashte hier nämlich auch.
Wenn alles gut geht, sollte ich heute das neue RPM in's repo stellen können.

[_diver]

Die neue Version ist im EXP RPM repo verfügbar.