Merkwürdiges Verhalten von epdf unter ArcOS
Merkwürdiges Verhalten von epdf unter ArcOS
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?
Davon kann man leider nicht ausgehen, sobald RPM-Pakete installiert worden sind, welche einige Konflikte verursachen können.Damon hat geschrieben: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.
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.Alle Pfade sind richtig eingetragen.Um welche Pfade handelt es sich?
Irgendetwas muß unter ArcOS also fehlen. Hat jemand eine Idee?
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
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
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...
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...
Zuletzt geändert von Frank Wochatz am Do 15. Jun 2017, 10:24, insgesamt 1-mal geändert.
Welche Kompatibilität wird durch rpm über Bord geworfen?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 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.
Zuletzt geändert von Frank Wochatz am Do 15. Jun 2017, 15:10, insgesamt 1-mal geändert.
Man kann sich behelfen mit folgender Vorgehensweise:Frank Wochatz hat geschrieben: 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...
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?
Zuletzt geändert von ak120 am Do 15. Jun 2017, 15:14, insgesamt 2-mal geändert.
- Frank Wochatz
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
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 wichtigTut 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.
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)
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....
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!
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!
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!
Danke für die Tipps!
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 -Wie meinst Du das mit dem Punkt, der vom Libpath .; zu Unixroot wandert?
Code: Alles auswählen
LIBPATH=.;P:\USR\LOCAL\LIB;P:\USR\LIB; ...
Code: Alles auswählen
LIBPATH=P:\USR\LOCAL\LIB;P:\USR\LIB;.; ....
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
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
Gut zu hören, dass es auch mit der GS-Installation in Arca erst einmal soweit funktioniert.
- HerwigB
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
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,
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,
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.
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:andreas hat geschrieben: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.
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.
also ich verwende ghostscript-9.04-os2-20111228 unter eCS 2.1. Da funktioniert sie wunderbar.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.
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
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
Was wie jeder Satz des Herrn ak120 völliger Unsinn ist...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.
Schwallen ohne selber probieren, gell?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.
Das sagt der GS 9.18 Interpreter selber
Bitte also nicht rumschwallen, sondern selber probieren.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.
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.
- Frank Wochatz
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
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
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
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.
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.
- HerwigB
- Beiträge: 57
- Registriert: Mo 23. Dez 2013, 06:39
- Wohnort: Sankt Veit an der Glan
- Kontaktdaten:
Genau des.Wos wui ma des song?
-dUseCIEColor is jedenfois vaoidet. Oiso 's ned mehr ganz nei.
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.
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.HerwigB hat geschrieben: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.
Wenn alles gut geht, sollte ich heute das neue RPM in's repo stellen können.
Silvan Scherer (_diver)
CTO bww bitwise works GmbH
DIE Quelle für ArcaOS, Software und Support, außerdem sind wir für finanzielle Unterstützung immer dankbar!
CTO bww bitwise works GmbH
DIE Quelle für ArcaOS, Software und Support, außerdem sind wir für finanzielle Unterstützung immer dankbar!
Die neue Version ist im EXP RPM repo verfügbar.
Silvan Scherer (_diver)
CTO bww bitwise works GmbH
DIE Quelle für ArcaOS, Software und Support, außerdem sind wir für finanzielle Unterstützung immer dankbar!
CTO bww bitwise works GmbH
DIE Quelle für ArcaOS, Software und Support, außerdem sind wir für finanzielle Unterstützung immer dankbar!