Merkwürdiges Verhalten von epdf unter ArcOS

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Damon
Beiträge: 120
Registriert: So 27. Jul 2014, 16:50

Merkwürdiges Verhalten von epdf unter ArcOS

Beitragvon Damon » Di 13. Jun 2017, 12:24

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?
Benutzeravatar
ak120
Beiträge: 744
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Di 13. Jun 2017, 18:39

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.

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
Beiträge: 120
Registriert: So 27. Jul 2014, 16:50

Beitragvon Damon » Do 15. Jun 2017, 09:56

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.
Benutzeravatar
Frank Wochatz
Beiträge: 783
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitragvon Frank Wochatz » Do 15. Jun 2017, 10:23

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...
Zuletzt geändert von Frank Wochatz am Do 15. Jun 2017, 10:24, insgesamt 1-mal geändert.
Andi B.
Beiträge: 376
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitragvon Andi B. » Do 15. Jun 2017, 14:29

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.
Zuletzt geändert von Frank Wochatz am Do 15. Jun 2017, 15:10, insgesamt 1-mal geändert.
Benutzeravatar
ak120
Beiträge: 744
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 15. Jun 2017, 14:58

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...


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?
Zuletzt geändert von ak120 am Do 15. Jun 2017, 15:14, insgesamt 2-mal geändert.
Benutzeravatar
Frank Wochatz
Beiträge: 783
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitragvon Frank Wochatz » Do 15. Jun 2017, 15:14

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.
Beiträge: 376
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitragvon Andi B. » Fr 16. Jun 2017, 09:31

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
Beiträge: 120
Registriert: So 27. Jul 2014, 16:50

Beitragvon Damon » Fr 16. Jun 2017, 11:00

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
Beiträge: 120
Registriert: So 27. Jul 2014, 16:50

Beitragvon Damon » Fr 16. Jun 2017, 11:41

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.
Beiträge: 376
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitragvon Andi B. » Fr 16. Jun 2017, 16:00

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
Benutzeravatar
Frank Wochatz
Beiträge: 783
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitragvon Frank Wochatz » Fr 16. Jun 2017, 18:45

Gut zu hören, dass es auch mit der GS-Installation in Arca erst einmal soweit funktioniert.
Benutzeravatar
HerwigB
Beiträge: 41
Registriert: Mo 23. Dez 2013, 06:39
Wohnort: Sankt Veit an der Glan
Kontaktdaten:

Beitragvon HerwigB » Di 8. Aug 2017, 09:53

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
Beiträge: 61
Registriert: Mo 30. Dez 2013, 19:55

Beitragvon andreas » Mi 9. Aug 2017, 17:07

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.
Benutzeravatar
ak120
Beiträge: 744
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitragvon ak120 » Do 10. Aug 2017, 19:02

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.


Die letzte offizielle Version für OS/2 war 8.60:
https://sourceforge.net/projects/ghostscript/files/GPL%20Ghostscript/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
Beiträge: 64
Registriert: Mo 10. Feb 2014, 20:46

Beitragvon axelwein » Do 10. Aug 2017, 20:03

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
Benutzeravatar
HerwigB
Beiträge: 41
Registriert: Mo 23. Dez 2013, 06:39
Wohnort: Sankt Veit an der Glan
Kontaktdaten:

Beitragvon HerwigB » Fr 11. Aug 2017, 12:19

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.
Benutzeravatar
HerwigB
Beiträge: 41
Registriert: Mo 23. Dez 2013, 06:39
Wohnort: Sankt Veit an der Glan
Kontaktdaten:

Beitragvon HerwigB » Mo 14. Aug 2017, 15:50

Der Bug tritt auch unter Win32 auf und ist somit Crossplattform.
Benutzeravatar
Frank Wochatz
Beiträge: 783
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitragvon Frank Wochatz » So 20. Aug 2017, 01:35

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.
Benutzeravatar
HerwigB
Beiträge: 41
Registriert: Mo 23. Dez 2013, 06:39
Wohnort: Sankt Veit an der Glan
Kontaktdaten:

Beitragvon HerwigB » Mi 23. Aug 2017, 07:46

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.
Benutzeravatar
Sepp Mayr
Beiträge: 118
Registriert: Mo 13. Jan 2014, 11:28
Wohnort: Bayern, oda wos hobt ihr dachd?
Kontaktdaten:

Beitragvon Sepp Mayr » Mi 23. Aug 2017, 19:27

HerwigB hat geschrieben:-dUseCIEColor ist trotzdem deprecated.

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

I griaß eich, da Sepp
Mia san mia
Benutzeravatar
HerwigB
Beiträge: 41
Registriert: Mo 23. Dez 2013, 06:39
Wohnort: Sankt Veit an der Glan
Kontaktdaten:

Beitragvon HerwigB » Fr 25. Aug 2017, 08:29

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
Beiträge: 113
Registriert: Fr 27. Jun 2014, 10:57

Beitragvon _diver » Fr 17. Nov 2017, 13:15

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.


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
Beiträge: 113
Registriert: Fr 27. Jun 2014, 10:57

Beitragvon _diver » Fr 17. Nov 2017, 18:41

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

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste