Ghostscript 9.26

I recently noticed that Ghostscript 9.26 was available from the riscosports website.

I am currently using the 8.71 version as supplied with my ARMX6 and on MW Software website.

Anyone know if its a safe update to 9.26? Any benefits to change?

Hi Chris,

Running 9.27 here OK.

Running 9.27 here OK

Where is that one from? Only seen the 9.26 version on the Riscosports site.

Sorry to resurrect this thread, but I was just doing some testing with GS 9.2x

I noticed that viewing a PDF via Martin W’s “!GView” gave grey-coloured text, rather than black. 8.71 seemed OK. That said, Chris G’s GhostView seemed OK, although rather “version 0.1-ish”.

This is making me a bit unsure of GS 9.2×. Would welcome/value other peoples’ experiences of pros/cons of 9.x vs 8.×.

I am now using GS 9.27 on both my ARMX6 and 4te2 and it seems OK. I usually use it with !PDFTest o the ARMX6 and at the moment with !PDF on the 4te2 (the 4te2 does not seem to like the better latest !PDFTest)

I have seen the grey-coloured issue a few times and is usually fixed in !PDFTest by Bitmap mode on or off as necessary, I can’t remember the trick in !PDF (oh I think its turn of Type 3 fonts tick option), Most cases where I have seen the issue its due to document having been scanned to PDF format.

I think GS 9.27 is only really for RISC OS 5.2X due to the bigger memory footprint requirement per help file.

I am now using GS 9.27

Where is that one from?

(strange echoes from the past)
I have seen no other trace of 9.27, so can I ask again?

I have seen no other trace of 9.27, so can I ask again?

I found it on Packman (both the 9.27 and 8.71 version are there)

Thanks Chris.

I think GS 9.27 is only really for RISC OS 5.2X

Doesn’t the GS 9.27 from Packman require VFP too? (Remembering an earlier thread [Edit: https://www.riscosopen.org/forum/forums/11/topics/17456]) So you are going to be on modern hardware.

I have a problem here with GS9.27 meaning I’ve not been comfortable upgrading.

Sometimes I need to produce black and white PDFs. Colour bitmaps seem to end up as colour even with the Colour option unticked in the PostScript printer configuration window. (If I’m doing something wrong there please correct me.)

I’ve been using the following GS commands to convert the PostScript file to a black and white PDF:

set g$dir <obey$dir>

gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -sProcessColorModel=DeviceGray -sColorConversionStrategy=Gray -sOutputFile=<g$dir>.mspdf/pdf <g$dir>.ms/ps

ms/ps is the originating PostScript file. mspdf/pdf is the finished B&W PDF.

This all works fine with 8.71 but it quits with a load of errors using 9.27:

Fatal signal received: EMT trap

Stack backtrace:

Running thread 0×1596acc (Main Thread)
( 1599f74) pc: 6716a8 lr: 671b54 sp: 1599f78 __write_backtrace()
( 1599fe4) pc: 6717c8 lr: 639d98 sp: 1599fe8 __unixlib_raise_signal()
( 1599ff4) pc: 639c98 lr: 6389d8 sp: 1b88ed4 __rt_stkovf_split_small()
( 1b88f10) pc: 3085c0 lr: 404548 sp: 1b88f14 copied_type1_glyph_outline()
( 1b88fcc) pc: 4044ac lr: 132784 sp: 1b88fd0 gs_default_glyph_info()
( 175d6f0) pc: 1324a0 lr: 639e08 sp: 175d6f4 gs_type1_glyph_info()
( 175d8a0) pc: 2eedac lr: 2ef96c sp: 175d8a4 pdf_compute_font_descriptor()
( 175d8c8) pc: 2ef924 lr: 306210 sp: 175d8cc pdf_finish_FontDescriptor()
( 175d8f0) pc: 3061c4 lr: 291c80 sp: 175d8f4 pdf_finish_resources()
( 1598edc) pc: 2919a8 lr: 639e08 sp: 1598ee0 pdf_close()
( 1598ef0) pc: 3fbe80 lr: 57c120 sp: 1598ef4 gs_closedevice()
( 1598fbc) pc: 57bf14 lr: 57c6f8 sp: 1598fc0 gs_main_finit()
( 1598fcc) pc: 57c6e4 lr: ea78 sp: 1598fd0 gs_to_exit_with_code()
( 1598fec) pc: ea04 lr: 6398dc sp: 1598ff0 main()

Can someone verify this error or do they have an alternative way of doing what I’m doing?

thanks

Has anyone seen any advantages in the newer version? Better rendering, faster/smaller conversion? Better output of PDFs?

Just trying to get a balanced view.

Has anyone seen any advantages in the newer version? Better rendering, faster/smaller conversion? Better output of PDFs?

Well it does seem to handle UTF-8 stuff better if used with !PDFTest the euro system appears but if used with the less developed !PDF then it does not show at all. As I understand it the newer GS is more up to date and handles things better.

Sometimes I need to produce black and white PDFs. Colour bitmaps seem to end up as colour even with the Colour option unticked in the PostScript printer configuration window. (If I?m doing something wrong there please correct me.)

I was intrigued by this. So I ran a few tests using a copy of the WROCC newsletter to test. Turned off the Colour tick in Postscript 3 driver, then printed via PrintPDF. This produced grey text where colour had been used in sprite files or draw files and coloured text. But all jpeg pictures still showed in Colour. As for the error you see with GS 9.27 I think thats to do with your use of the PREPRESS option – its not recommanded as it can cause issues as you have seen. I have seen it myself with both 8.71 and 9.26/9.27. Is there some reason you don’t use PrintPDF.

Are your PDF’s for printing? If so then your Colour pictures would get printed in Grey scale anyway if sent to a mono printer.

But all jpeg pictures still showed in Colour.

JPEG rendering doesn’t have a monochrome option. It could be fudged by the use of a colour transfer function, but this is additional complexity.

Fair point Rick. Personally I would have coverted any colour pictures to greyscale etc via DPlingScan or similar before adding to a doument that was being turned into a PDF file if it was really needed.

Chris, you keep mentioning PDF and PDFtest, but I don’t think either of them uses GhostScript for their rendering, so are not relevant to this thread.

PDF and PDFTest are PDF viewers of Ghostscript files generated by GS 9.27 etc. as is GView. otherwise how do we view the ghostscript generated files?

But Ghostscript is a viewer of PDF files! GView is just a WIMP wrapper around that to display its output in a window.

Although I suppose checking its conversion from plain postscript to PDF in other viewers might show up oddities, but I’d expect the generating program to be far more significant (e.g. PS2/PS3 driver, direct from ArtWorks, etc).