PS to PDF conversion in Geos and DOS

    As this was some kind of public Geos demand, here it is:

    PS to PDF conversion in Geos and DOS with DOS Ghostscript. Works also in DOSBox in Android. Not tested in DOSBox/Windows, DOSBox/Linux, and Basebox. It should work there, too, but I think it is better to use the conversion in Windows and Linux for better result. Here are the files from Breadbox, included are the sources of the changed Geos files, too.

    The conversion goes like this, first you print.the document to a PS file. Then you convert the PS file to a PDF, the conversion takes place in DOS, Geos shells out automatically, and you have to wait until the conversion is done, and you will get back to Geos again.

    Note: You need to copy the files manually to their folder, the instruction is in the readme file. You will replace the spooler.geo, so please make a backup copy of it before you begin. The conversion involves the DOSROOM folder, which maybe seemes a bit odd. Breadbox planned to change the use of it to a Download/Transfer folder to create a communication folder with Android.

    You use the files at your own risk!

    It works! :)

    Als kleine Herausforderung habe ich ein 40-seitiges GeoWrite-Dokument von Rainers R-BASIC Doku verwendet. Die Verarbeitung hat (gefühlt) einige Minuten gedauert, das Ergebnis ist aber besser als erwartet. Die Schriftart weicht etwas ab, die Grafiken sind dafür quasi identisch.

    Ein Manko ist aktuell die Dateigröße. Das unter macOS erzeugte PDF ist 500 KB groß, das unter GEOS/DOS erzeugte PDF dagegen 16 MB.

    Great that it works. I dont know anything about the file sizes. I do know that the Ghostscript generated PDF is an older version of PDF. I also know that the Ghostscript generated PDF is a "proper" PDF which is editable in Adobe Acrobat Pro. I have tested myself, several documents, GeoWrite documents and test prints from the printer test page. That was one of the strangest edits I have ever made.

    Quote from Mütze

    It works! :)

    Als kleine Herausforderung habe ich ein 40-seitiges GeoWrite-Dokument von Rainers R-BASIC Doku verwendet. Die Verarbeitung hat (gefühlt) einige Minuten gedauert, das Ergebnis ist aber besser als erwartet. Die Schriftart weicht etwas ab, die Grafiken sind dafür quasi identisch.

    Ein Manko ist aktuell die Dateigröße. Das unter macOS erzeugte PDF ist 500 KB groß, das unter GEOS/DOS erzeugte PDF dagegen 16 MB.

    Ich habe es jetzt noch nicht probiert... Kann man die erzeugte PDF-Datei auch mit dem PDF-Viewer in Geos öffnen und betrachten?

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Quote from Achim

    Kann man die erzeugte PDF-Datei auch mit dem PDF-Viewer in Geos öffnen und betrachten?

    Mit Rainers 40-seitigem Dokument sofortiger Absturz... ;)

    Aber es lohnt sich vielleicht die Grenzen des Viewers auszuloten. Ist ja durchaus möglich, dass er einfach strukturierte Dokumente in (auch akzeptabler Ladezeit) anzeigen kann...

    Bei meinem einseitigen Testdokument ergeben sich mit URW Roman und URW Mono als Schriftart kleine PDF-Dateien, die auch schnell konvertiert und schnell mit dem Viewer angezeigt werden. Ein Problem scheint mit der korrekten Positionierung der Umlaute und einiger weiterer Zeichen zu bestehen.

    Testweise verwendetes URW Sans erzeugt eine um ein vielfaches größere Datei. PDF-Viewer versucht die Datei einzulesen, zeigt dann aber nichts an.

    Auf meinem Hostsystem werden alle Dateien korrekt dargestellt. Das Problem liegt also beim Viewer.

    Quote from Mütze

    ...

    Auf meinem Hostsystem werden alle Dateien korrekt dargestellt. Das Problem liegt also beim Viewer.

    Bei mir genauso. X/ Mit dem DOS-PDF-Betrachter MU-PDF lassen sich alle von mir getesteten Dokumente korrekt anzeigen. Leider ist das Programm wirklich nur das, was der Name sagt, ein Betrachter. Da kann man nix anderes mit machen. Vielleicht weiß noch jemand einen leistungsfähigeren PDF-Betrachter für DOS... :/

    Gruß Achim


    PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

    Ja, der PDF-Viewer benötigt viel Zuwendung und da das PDF Format quasi ein Standardformat ist, brauchen wir auch unter PC/GEOS einen guten Viewer.

    Mir juckt es auch schon in den Fingern. Von PDF internas habe ich aber keine Ahnung.

    Jirka

    Es ist auch dein FreeGEOS!

    Das wäre was für Dich! Ist höllisch kompliziert :D

    Ich habe neulich mal in den Source geguckt und festgestellt dass die über große Strecken "malloc" genutzt haben, die Speicherverwaltung ist nur so halbherzig auf GEOS angpeasst. Da wäre also noch Luft nach oben....

    Bye,
    MeyerK

    Ich hab mal vor längerer Zeit ein bisschen in die Struktur geschaut. PDF ist so ein bisschen wie GeoDraw. Ein Textobjket an dieser Stelle, ein anderes dort, ne Grafik an jener Position usw. Das merkt man auch, wenn man eine PDF bearbeitet. Aber alles relativ komplex verlinkt. Und dann noch ZIP komprimiert, soweit ich mich erinnere. Also alles ohne Garantie. :P

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Bei den Textexporten, die ich mal in Bernds Editor eingebaut hatte, begann ich damals auch mit einem PDF-Export. Es wurden dann valide PDFs mit ein paar Textzeilen erstellt :).

    Die PDF-Grundstruktur geht eigentlich, aber die Formatspezifikation ist einfach so umfangreich, daß es a) einfach unglaublich viel Arbeit ist und b) es zahllose Details gibt, hinter denen die Teufelchen hocken.

    Ein großes Problem ist die Wysiwig-Darstellung. Dazu müßten nämlich die in Geos verwendeten Schriften im PDF eingebettet werden. Was inzwischen eh zum guten Ton gehört. Das könnte einfacher werden, falls es mit Geos und den TTF-Schriften klappt. Damals hatte ich einfach die Basisfunktionalität genutzt und im PDF definiert: Serifen-Schrift, 12 pt. Da sucht sich das PDF-Anzeigeprogramm dann eine vorhandene Schrift aus.

    Quote from hanslse

    It would also be a good thing to investigate why the PDF files gets so big. Could it be the fonts?

    Hi!

    I can think of two possible reasons:

    a) Geos always includes the fonts in the files. This was one of the fixes made by Grossibär to the PS-creation (as the previous version only replaced the Geos-Fonts with similar PS-Fonts that simply haven’t been „similar enough“). (AFAIK some converters are reducing space by removing unused characters from the fonts. E.g. Rainers 40-pages document is most likely not using „French characters“ like éèêÉÈÊàáâÀÁÂ.)

    b) If I recall correctly, Geos exports every bitmap-graphic with 24bit color depth to PS. And ps2pdf is then turning this information into something that is similar to an „embedded TIFF“ - of course uncompressed. I guess that the macOS converter is using either a compressed version of TIFF or another format (PNG or JPEG).


    Not to mention that Geos and ps2pdf are using the „highest possible resolution“ while the macOS converter might do some downscaling to 200 or 300dpi.

    There are two rules in life:
    1. Never give out all of the information.

    Edited once, last by jpolzfuss (March 13, 2025 at 9:18 AM).

    Auch die unter GEOS/DOS erzeugten PDFs können je nach verwendeter Schriftart im Quelldokument eine sehr unterschiedliche Dateigröße haben.

    Einseitiges GeoWrite-Dokument, jeweils nur eine Schriftart, unterschiedliche Schriftgrößen, fett, kursiv, keine Grafiken:

    URW Sans: 259 KB

    Sather Gothic: 268 KB

    URW Roman: 3 KB

    URW Mono: 3 KB

    Der GEOS-Viewer zeigt die beiden PDFs mit URW Roman / URW Mono ruckzuck an, mit kleinen Darstellungsfehlern.

    Die PDFs mit URW Sans / Sather Gothic versucht der Viewer zu öffnen, zeigt aber nur ein leeres Fenster an. Kann die evtl. eingebettete Schrift nicht laden? Stürzt nicht ab.

    Kleiner Effekt am Rande: Wenn ich über Druck in ein PS-Datei (Postscript in *.PS, EPS-Library von Grossibaer installiert) und Konvertierung in PDF mit PDFCreator unter Windows eine PDF erstelle, können Schüler, die ein iPAD (interner iPad-PDF-Viewer) benutzen, die Datei häufig nicht anzeigen. Sie müssen dann Acrobat benutzen.
    PDFCreator kann verschiedene PDF-Varianten erzeugen. Welche gehen und welche nicht habe ich nicht im Detail untersucht.

    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Ja, seitdem in aktuellen Windows- und macOS-Versionen die PS-Unterstützung systemseitig wegen Sicherheitsbedenken entfernt wurde, müssen die Hersteller von PS2PDF-Programmen selber was basteln, dass den Job macht. Da kann ich mir schon vorstellen, dass dort nicht jede Einstellung kompatibel genug ist.

    Nun ja, wenn des er iPad-interne Betrachter mit Dateien, die woanders oder mit anderen Programmen auf dem iPad korrekt angezeigt werden, nicht klar kommt, dann liegt es eher nicht am Dateiformat :P;)
    Oder die anderen Programme sind einfach fehlertoleranter. :)

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Quote from Rainer

    Kleiner Effekt am Rande: Wenn ich über Druck in ein PS-Datei (Postscript in *.PS, EPS-Library von Grossibaer installiert) und Konvertierung in PDF mit PDFCreator unter Windows eine PDF erstelle, können Schüler, die ein iPAD (interner iPad-PDF-Viewer) benutzen, die Datei häufig nicht anzeigen. Sie müssen dann Acrobat benutzen.
    PDFCreator kann verschiedene PDF-Varianten erzeugen. Welche gehen und welche nicht habe ich nicht im Detail untersucht.

    Rainer

    Interesting observation regarding viewing the pdf. In what way does the student view the pdf? In a browser like Edge?

    For example, I have noted that fill in forms in pdf format only works in Acrobat Reader or Pro, not in web browsers like Edge.

    Quote from MeyerK

    Ich habe neulich mal in den Source geguckt und festgestellt dass die über große Strecken "malloc" genutzt haben, die Speicherverwaltung ist nur so halbherzig auf GEOS angpeasst. Da wäre also noch Luft nach oben....

    Ein Kandidat wäre https://github.com/bluewaysw/pcgeos/issues/757 - die Inflate-komprimierten Streams (Zip-Kompression) stattdessen per zlib zu implementieren, wo du ja schon ein paar Verbesserungen an der Speicherverwaltung gemacht hast. Es gibt natürlich noch eine Menge anderer mallox-Sachen (z.B. ein großes Array von Font -Informationen, wenn ich mich richtig erinnere), aber eine einheitliche Library für das Auspacken wäre schon mal was.