Ken Sharp | 22 Jul 10:28 2014

Re: pswrite and NOPLATFONTS

At 09:38 18/07/2014 +0100, Chris Liddell wrote:

>More from me, or the ps2write/pdfwrite maintainer when we have it.

There are 2 commits :

commit b6575b8a91e23365b340771fc67b29819ba7937b
Author: Chris Liddell <chris.liddell <at>>
Date:   Mon Jul 21 11:02:55 2014 +0100

commit 8d3081c0403a1d911a79dce57008ede4279d050a
Author: Ken Sharp < <at>>
Date:   Tue Jul 22 09:09:47 2014 +0100

Both commits are required and should not be applied separately.

With both these in place there is a new switch 'NoOutputFonts' which 
defaults to false, when set to true (eg -dNoOutputFonts) the pdfwrite 
family of devices (including ps2write and eps2write) will not emit *any* 
fonts at all. All text will be drawn by emitting the glyph description 
directly into the page stream every time a glyph is used. For most fonts 
this will result in paths, for bitmap fonts it will result in bitmaps.

Note that the output will be larger, slower to process, the text rendering 
will be less consistent and, particularly at lower resolution, of poorer 
quality. In addition most PostScript RIPs handle text specially, in 
particular filled text is usually rendered differently to a filled path. 
Drop-out correction will not be applied (or applied differently) and 
(Continue reading)

Dwight Kelly | 14 Jul 15:49 2014



There's a utility in Ghostscript named genht which converts specially 
formatted PostScript threshold halftone resources into C data structures.

How do I get Ghostscript to generate threshold patterns from PS spot 
function(s) and save them to disc for use with genht?

Thank you,
Dwight Kelly
Alex Korobkin | 9 Jul 00:12 2014

GS not producing level 3 PostScript for me

Hi all, 

I cannot figure out how to produce Level 3 PostScript with GS, it always creates level 2 for me. Tested with 9.05 and 9.14 on Ubuntu 12.04, and 9.05 on Ubuntu 14.04. 

pdf2ps -dLanguageLevel=3 ./test.pdf

%%Creator: GPL Ghostscript 905 (ps2write)
%%LanguageLevel: 2

gs -q -sDEVICE=ps2write -dNOPAUSE -dBATCH -dSAFER -dLanguageLevel=3 -sOUTPUTFILE=%stdout $pdf

%%Creator: GPL Ghostscript 914 (ps2write)
%%LanguageLevel: 2

Am I using incorrect device or a wrong switch? 
Docs point me to , but I don't see an answer there. 

$ gs -h
GPL Ghostscript 9.14 (2014-03-26)
Copyright (C) 2014 Artifex Software, Inc.  All rights reserved.
Usage: gs [switches] [ ...]
Most frequently used switches: (you can use # in place of =)
 -dNOPAUSE           no pause after page   | -q       `quiet', fewer messages
 -g<width>x<height>  page size in pixels   | -r<res>  pixels/inch resolution
 -sDEVICE=<devname>  select device         | -dBATCH  exit after last file
 -sOutputFile=<file> select output file: - for stdout, |command for pipe,
                                         embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PostScriptLevel3 PDF
Default output device: bbox
Available devices:
   alc1900 alc2000 alc4000 alc4100 alc8500 alc8600 alc9100 ap3250 appledmp
   atx23 atx24 atx38 bbox bit bitcmyk bitrgb bitrgbtags bj10e bj10v bj10vh
   bj200 bjc600 bjc800 bjc880j bjccmyk bjccolor bjcgray bjcmono bmp16 bmp16m
   bmp256 bmp32b bmpgray bmpmono bmpsep1 bmpsep8 ccr cdeskjet cdj1600 cdj500
   cdj550 cdj670 cdj850 cdj880 cdj890 cdj970 cdjcolor cdjmono cdnj500 cfax
   chp2200 cif cljet5 cljet5c cljet5pr coslw2p coslwxl cp50 cups declj250
   deskjet devicen dfaxhigh dfaxlow display dj505j djet500 djet500c dl2100
   dnj650c epl2050 epl2050p epl2120 epl2500 epl2750 epl5800 epl5900 epl6100
   epl6200 eplcolor eplmono eps2write eps9high eps9mid epson epsonc epswrite
   escp escpage faxg3 faxg32d faxg4 fmlbp fmpr fpng fs600 gdi hl1240 hl1250
   hl7x0 hpdj1120c hpdj310 hpdj320 hpdj340 hpdj400 hpdj500 hpdj500c hpdj510
   hpdj520 hpdj540 hpdj550c hpdj560c hpdj600 hpdj660c hpdj670c hpdj680c
   hpdj690c hpdj850c hpdj855c hpdj870c hpdj890c hpdjplus hpdjportable ibmpro
   ijs imagen inferno ink_cov inkcov iwhi iwlo iwlq jetp3852 jj100 jpeg
   jpegcmyk jpeggray la50 la70 la75 la75plus laserjet lbp310 lbp320 lbp8
   lex2050 lex3200 lex5700 lex7000 lips2p lips3 lips4 lips4v lj250 lj3100sw
   lj4dith lj4dithp lj5gray lj5mono ljet2p ljet3 ljet3d ljet4 ljet4d
   ljet4pjl ljetplus ln03 lp1800 lp1900 lp2000 lp2200 lp2400 lp2500 lp2563
   lp3000c lp7500 lp7700 lp7900 lp8000 lp8000c lp8100 lp8200c lp8300c
   lp8300f lp8400f lp8500c lp8600 lp8600f lp8700 lp8800c lp8900 lp9000b
   lp9000c lp9100 lp9200b lp9200c lp9300 lp9400 lp9500c lp9600 lp9600s
   lp9800c lps4500 lps6500 lq850 lxm3200 lxm5700m m8510 mag16 mag256
   md1xMono md2k md50Eco md50Mono md5k mgr4 mgr8 mgrgray2 mgrgray4 mgrgray8
   mgrmono miff24 mj500c mj6000c mj700v2c mj8000c ml600 necp6 npdl nullpage
   oce9050 oki182 oki4w okiibm oprp opvp paintjet pam pamcmyk32 pamcmyk4 pbm
   pbmraw pcl3 pcx16 pcx24b pcx256 pcx256 pcx2up pcxcmyk pcxgray pcxmono
   pdfwrite pdfwrite pdfwrite pgm pgmraw pgnm pgnmraw photoex picty180 pj
   pjetxl pjxl pjxl300 pkm pkmraw pksm pksmraw plan plan9bm planc plang
   plank planm png16 png16m png256 png48 pngalpha pnggray pngmono pnm pnmraw
   ppm ppmraw pr1000 pr1000_4 pr150 pr201 ps2write psdcmyk psdcmykog psdrgb
   pwgraster pxlcolor pxlmono r4081 rinkj rpdl samsunggdi sgirgb sj48
   spotcmyk st800 stcolor sunhmono t4693d2 t4693d4 t4693d8 tek4696 tiff12nc
   tiff24nc tiff32nc tiff48nc tiff64nc tiffcrle tiffg3 tiffg32d tiffg4
   tiffgray tifflzw tiffpack tiffscaled tiffsep tiffsep1 txtwrite uniprint
   xcf xes xpswrite
Search path:
   /usr/share/ghostscript/9.14/Resource/Init :
   /usr/share/ghostscript/9.14/lib :
   /usr/share/ghostscript/9.14/Resource/Font :
   /usr/share/ghostscript/fonts : /var/lib/ghostscript/fonts :
   /usr/share/cups/fonts : /usr/share/ghostscript/fonts :
   /usr/local/lib/ghostscript/fonts : /usr/share/fonts
Ghostscript is also using fontconfig to search for font files
For more information, see /usr/share/doc/ghostscript/Use.htm.
Please report bugs to

gs-devel mailing list
gs-devel <at>
Johannes Meixner | 2 Jul 12:32 2014

Public available Ghostscript testsuite or test files?


in short:
Is there a public available Ghostscript testsuite or test files?

Details, background information and reasoning:

From time to time we (i.e. SUSE) get bug reports from our customerts
about Ghostscript in our released products e.g. in SLES11
(SUSE Linux Enterprise Server 11) which has Ghostscript 8.62.

We do not do software version upgrades in our released products
because we try to avoid any possible backward incompatible changes
(or even regressions because of new bugs in the new version).

We cannot do software version upgrades in our released products
when the new version has an incompatible library. For example
Ghostscript version 8.62 has that is used by some
other programs
# rpm -e --test ghostscript-library 2>&1 | grep libgs is needed by libspectre1 is needed by evince
so that we could at most upgrade to the last Ghostscript 8.x
but not to Ghostscript 9.x.

Therefore in case of bugs in Ghostscript 8.x we try to fix them
on our own via patches. I wrote "try to fix" because actually
we do not have sufficient knowledge about Ghostscript internals
to really decide whether or not a non-trivial patch may cause
regressions elsewhere in Ghostscript.

We already had an issue once where the upstram patches from
"just applied" on our Ghostscript sources and "just fixed" that
particular issue but caused regressions elsewhere in Ghostscript.

If we had a Ghostscript testsuite, we could verify at least to a
certain extent whether or not our patches cause regressions.

As far as I know Ghostscript upstream has a testsuite that is run
automatically to check whether or not changes cause regressions.

I assume in the Ghostscript upstream testsuite there are many
PostScript and PDF test files that are automatically processed
but I also assume that those files are from Ghostscript customers
and therefore they cannot be made public available.

Nevertheless I would like to ask if perhaps at least
some of the test files could be made public available?

Perhaps test files that have been provided as public accessible
Ghostscript bugzilla attachments?

Ghostscript 8.x provides some documetation about testing e.g.

But it seems in Ghostscript 9.x this was removed so that currently
I do not know what the officially right way is how to do testing
for Ghostscript 9.x.

In the Ghostscript 9.x sources test scripts are still provided
in toolbin/tests/ in particular toolbin/tests/README
wherefrom I picked out:
     comparefiles (usually /home/regression/comparefiles)

At first glance it seems the needed test scripts are still provided
but what seems to be missing are test files.

If some test files could be provided in the Ghostscript sources,
ideally there could be a ready-made "make test" build target.

At the beginning only a few basic test files together with
a "make test" build target would be perfectly sufficient.

Kind Regards
Johannes Meixner

SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Ken Sharp | 10 Jun 10:26 2014

Re: Fwd: GhsotScript slowdowns on very large pdf files - how to profile or other directions?

At 10:12 10/06/2014 +0200, Jacek Bator wrote:

>gswin32c.exe -dSAFER -dBATCH -dNOPAUSE -r150 -sDEVICE=pnggray 
>-dTextAlphaBits=4 -sOutputFile=doc-%05d.png -f input.pdf
>and there where no any slowdown as you suspected and performance was 
>bettter than for pdf output.

Except at very high resolution the rendering output performance is always 
likely to be superior to the pdfwrite performance, its what Ghostscript is 
optimised for after all, also rendering is a rather simpler problem than 
producing a decent PDF file.

As I said I'm not actually surprised to hear that pdfwrite slows down as 
the number of pages increases, I suspect this is true to some extent for 
all PDF producers due to having to keep lots of state around, also 
potentially inspecting that state for duplications etc.

The pdfwrite device does try to avoid this, in part by MD5 hashing objects, 
previously it would rewind temporary files and byte compare stored objects 
with new ones for every new object. The new method is faster. Nevertheless 
there are bound to be other areas where linear searches take place, the 
code seeks back and forth through temporary files or other areas where 
there is slow performance (producing linearised files will also be still 

This isn't an area of high priority for us but if you want to investigate 
I'll certainly look at anything you come up with.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I love the "swooshing" sound deadlines make as they go by.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ken Sharp | 9 Jun 10:33 2014

Re: Fwd: GhsotScript slowdowns on very large pdf files - how to profile or other directions?

At 10:16 09/06/2014 +0200, Jacek Bator wrote:

>file size. Unfortunately Ghostscript is not performing too well with such 
>files. While processing particular file performance per page drops while 
>more pages are processed. For ex. for one of my test documents (65000 
>pages,pure text an some fonts embedded/subseted) at the beginning it's 
>processed with 5 sec for 100 pages but it slows down continuously and 
>after page no 50 000 it's
>18-20 sec per 100 pages. For real documents with more complicated 
>structure it slow downs even faster and more.

You need to mention the (implied) use of pdfwrite as the output device. I 
know you mention it at the end of the mail but people start reading at the 
beginning, its best to get people thinking in the right direction early.

I suspect that if you try this with a rendering device, such as PNG, you 
will not experience any such progressive slowdown.

The problem is likely to be (in my opinion) that pdfwrite has to maintain a 
great deal of state which increases as the job progresses. Things like the 
page tree, copies of resources and other objects, even though stored in 
external files, also occupy memory. Traversing various memory structures 
also occupies more time as the size increases. It would not surprise me to 
find that linear searches are performed on various lists and these will 
obviously be potentially slow.

Then there is the requirement to verify each new resource of any type 
against all the existing resources to see if its a duplicate, and can be 
eliminated. As the total number of resources increases the time taken to 
check each new resource also increases.

I would start by comparing the performance 'shape' using a rendering device 
against that using pdfwrite. At the very least this will indicate whether 
the biggest problem (and therefore potential gains) are to be found in the 
PDF interpreter or the pdfwrite device.

If each page in the job is approximately the same type of content (as would 
seem likely with such immense files) then you can do a comparative profile. 
Run a profile with say 5,000 pages, then again at progressively larger 
numbers of pages and compare the profiles, if a particular routine moves up 
the profile (ie takes a larger percentage of the processing time) then you 
know this is the one that is being exercised more and causing the degradation.

>First I have tried some C level profiling but without any luck, most clues 
>where leading to PS code execution. Then I have tried to debug on ps level 
>by looking -dPDFDEBUG output and by inserting some control messages into 
>PS code.
>My first tip was <> -> pdfgetpage. While 
>processing following pages i'ts always calls pdffindpage? and iterates 
>trough page tree because when first accessed, page is not yet located in 
>PageIndex for  dopdfpages>>pdfgetpage sequence processing.

That seems unlikely to lead to the kind of performance degradation you 
describe, since this is done on every page.


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The Web isn't better than sex, but sliced bread is in serious trouble
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Jacek Bator | 9 Jun 10:16 2014

Fwd: GhsotScript slowdowns on very large pdf files - how to profile or other directions?


Sometimes I'm using Ghostscript to process very large PDF files (with more than 30 000 pages). Mainly to embed the fonts, convert to specific PDF specification and lower file size. Unfortunately Ghostscript is not performing too well with such files. While processing particular file performance per page drops while more pages are processed. For ex. for one of my test documents (65000 pages,pure text an some fonts embedded/subseted) at the beginning it's processed with 5 sec for 100 pages but it slows down continuously and after page no 50 000 it's
18-20 sec per 100 pages. For real documents with more complicated structure it slow downs even faster and more.
First I have tried some C level profiling but without any luck, most clues where leading to PS code execution. Then I have tried to debug on ps level by looking -dPDFDEBUG output and by inserting some control messages into PS code.

My first tip was -> pdfgetpage. While processing following pages i'ts always calls pdffindpage? and iterates trough page tree because when first accessed, page is not yet located in PageIndex for  dopdfpages>>pdfgetpage sequence processing.

So I have implemented method that prefills  pages PageIndex array and PageNames dictionary whit all in one pass. It improved processing but only in specific situations. It worked best when pages tree was defined in one /Pages element or multiple /Pages elements where pretty large. It may be worth to include this patch in GS so I'll post it on bugtracking system.

Unfortunately files I'm dealing with where produced by merging multiple documents and page tree is well balanced inside so advantage to above changes was pretty small. My next bet is that some PS interpreter structure (dictionary or stack) is too large and access to it becomes pretty slow but I don't have a clue how to profile it yet. I have observed that slowdown is greater for documents with more pdf objects inside.

My previous 65K test file has 148 000 pdf objects inside. But on another test file with "only" 33K pages (real data, no images) slowdown is greater (it has 480 000 pdf objects inside).
Slowest part are pages from about 2800 to about 6000 (3 min per 100 pages, where it was 15 sec at the begining) then GS speeds up little bit but it's is still slower than at the beginning. When GS is executed with -dFirstPage=2800 -dLastPage=6000 it's blasting fast so I guess is not entirely data specific problem.

So I'm not sure how could I collect some more detailed profiling data. Is there any way to measure execution time for PS procedures (for example I would like to check resolveR execution times)? Or maybe someone can point me to another direction?

All test were performed on Windows environment with 32 bit GS.
Usual test command was: gswin32c.exe -sDEVICE=pdfwrite "-sOUTPUTFILE=out.pdf" -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress  -f in.pdf

Jacek Bator

gs-devel mailing list
gs-devel <at>
Ken Sharp | 6 Jun 08:56 2014

Re: Type 3 font problem

At 20:17 05/06/2014 +0100, Chris Liddell wrote:
>There are many reasons that pdfwrite can resort to emitting a Type 3 font, 
>and they are all dictated by the content of the input, so without seeing 
>an example, it's pretty much impossible to guess at the reason.
>FWIW, a PDF interpreter that doesn't support Type 3 fonts is just broken - 
>Type 3 fonts are "core functionality" for PDF.

Due to having mail trouble yesterday I accidentally replied to this without 
CC'ing gs-devel.

The problem turned out to be that one of the fonts did not contain a 
/.notdef glyph, which is a requirement for all fonts. pdfwrite refuses to 
emit a font broken like that, and so falls back to a type 3 font.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I always try to go the extra mile at work, but my boss always finds me 
and brings me back.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Schubert, Stefan | 5 Jun 13:34 2014

Type 3 font problem

Hi there,


we have a strange effect according font handling:


Having a colored pdf (which acrobat reader properties says it contains no type 3 fonts) and converting it to greyscale with gs9.14 like this:


gswin64c -dEmbedAllFonts=true -dShowAnnots=false -dShowAcroForm=false -dNOTRANSPARENCY -sPAPERSIZE=a4 -sColorConversionStrategy=Gray

-dProcessColorModel=/DeviceGray -sDEVICE=pdfwrite -dBATCH -dNOPAUSE –dNOOUTERSAVE –sOutputFile=withType3.pdf withoutType3Sample.pdf


I end up with a pdf which suddenly contains a typo 3 font and causes display problems in some integrated pdf viewing tool (like telerik – where it’s simply not supported, yet).


Does someone know why gs convert fonts into typo3 and if there is a commandline switch which suppress this behavior? After a first brief scan over the documentation I found no suitable hint.






gs-devel mailing list
gs-devel <at>
Albert Astals Cid | 11 May 12:49 2014

Patch to make SHARE_LCMS work

Hi Chris, gs-devels, I see that f5457548e8162438a43b1aeb2040e34c001adaa4 
introduced SHARE_LCMS to use malloc instead of gs_alloc_bytes.

The Ubuntu packages pass the SHARE_LCMS=1 to the 
compilation of the code but unfortunately it was not taking effect.

I've created the following patch that makes it work for me. Can you guys check 
if it is correct?


P.S: I give up any copyrights i may have on this mini patch so that it can be 
incorporated upstream.
Attachment (share_lcms.patch): text/x-patch, 1098 bytes
gs-devel mailing list
gs-devel <at>
Michael K | 18 Apr 02:47 2014

gsapi_run_file segfaults (all versions after 9.07)

I have a program that uses the ghostscript API
It has been working without problem up until I upgraded Ghostscript to 9.10 (from 9.07).
Now I get a segfault using  gsapi_run_file().

I have attached a simple example to demonstrate.
Does anyone know if this is a ghostscript bug or have I been using it incorrectly (and I now finding out about it!)


#include <stdio.h>
#include <stdlib.h>
#include "ierrors.h"
#include "iapi.h"

/* stdio functions */
static int /* __attribute__ ((unused)) */ GSDLLCALL
gsdll_stdin(void *instance, char *buf, int len)
    int ch;
    int count = 0;
    while (count < len) {
        ch = fgetc(stdin);
        if (ch == EOF)
            return 0;
        *buf++ = ch;
        if (ch == '\n')
    return count;

static int /* __attribute__ ((unused)) */ GSDLLCALL
gsdll_stdout(void *instance, const char *str, int len)
    fwrite(str, 1, len, stdout);
    return len;

static int /* __attribute__ ((unused)) */ GSDLLCALL
gsdll_stderr(void *instance, const char *str, int len)
    fwrite(str, 1, len, stderr);
    return len;

void *GSinst;

int main(int argc, char *argv[])
    int GScode=0;
    int GSexitCode;

    const char sPSprogram[]   = "";

#define NoOfGSargs
    char *GSargs[] = {
argv[0], "-sDEVICE=x11alpha", "-dBATCH", "-dNOPAUSE", "-q" 

    if( (GScode = gsapi_new_instance( &GSinst, NULL )) < 0 ) {
fprintf( stderr, "Ghostscript gsapi_new_instance fail (%d)\n", GScode);

    gsapi_set_stdio(GSinst, gsdll_stdin, gsdll_stdout, gsdll_stderr);

    if( (GScode = gsapi_init_with_args( GSinst, NoOfGSargs, GSargs )) < 0 ) {
        fprintf( stderr, "Ghostscript gsapi_new_instance fail (%d)\n", GScode);

    if( gsapi_run_file( GSinst, sPSprogram, 0, &GSexitCode) < 0 ) {
    fprintf( stderr, "Error: Could not load %s\n", sPSprogram );

   fprintf( stderr, "Never gets here because Ghostscript dumps core (all versions after 9.07)\n");

Attachment (gstest.c): text/x-csrc, 2323 bytes
gs-devel mailing list
gs-devel <at>