TTF font subsetting for PS backend

Development matplotlib-devel
1

Even if my Postscript is to spec, it's not terribly useful if it crashes a very popular tool :wink:

I'm curious -- does the file fail if you set "ps.fonttype: 42" in your matplotlibrc? That would at least rule out anything non-font in the file.

I just built my own ESP Ghostscript 815.04 and am able to make some pretty high resolution renderings at the commandline. I'm not exactly sure how "400%" in the GUI relates to dpi, but I can do 1200 dpi without problem. Perhaps there's something else going on in the evince stack... I'll try later on my Ubuntu box at home, since building all that on this RHEL4 box could be time consuming.

Does the following work for you?

    gs -sOUTPUT_DEVICE=pngalpha -sOutputFile=test%03d.png -r1200x1200 simple_plot_ps.ps

Cheers,
Mike

Eric Firing wrote:

···

Michael Droettboom wrote:

Oh dear. It works for me with my fairly old version of GNU ghostscript (7.07) and a couple different Postscript HP laser printers I tried. The file position where the error occurs at least seems plausible -- it's where the first text is shown.

I'll have to look into this further. More data points are welcome.

Cheers,
Mike

Mike,

Attached are a minimal script to reproduce the problem, and the ps file I get that shows the problem--but only when I try to display at sufficiently high resolution. Threshold seems to be between 200% and 400% on my machine, but I have no idea why there is a dependence on magnification at all.

With this simpler example, the error output is:

ERROR: /unknownerror in --%op_show_continue--
Operand stack:

Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
   --dict:1126/1686(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)-- --dict:7/7(L)--
Current allocation mode is local
Current file position is 5228
ESP Ghostscript 815.04: Unrecoverable error, exit code 1

Now, if I do

ps2pdf testps.ps

The resulting pdf file works fine; evince displays it at 400%.
If I then do

pdftops testps.pdf testpsrt.ps

the new ps file resulting from this round trip *fails* in evince at 400% in the same way:

evince testpsrt.ps
ERROR: /unknownerror in --%op_show_continue--
Operand stack:
   80.9999 219.2 0.0 0.0 32 6.93003e-05 0.0 (0.0)
Execution stack:
   %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
Dictionary stack:
   --dict:1126/1686(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)-- --dict:63/75(L)-- --dict:18/24(L)-- --dict:0/15(L)-- --dict:0/15(L)-- --dict:8/15(L)-- --dict:2/15(L)--
Current allocation mode is local
ESP Ghostscript 815.04: Unrecoverable error, exit code 1

** (evince:6215): WARNING **: Interpreter failed.

On the other hand, running testps.py -dcairo.ps results in a ps file which does *not* fail in evince at 400%.

Eric
------------------------------------------------------------------------

import pylab
pylab.plot([1,2,3], '.')
pylab.savefig('testps.ps')

2

Michael Droettboom wrote:

Even if my Postscript is to spec, it's not terribly useful if it crashes a very popular tool :wink:

I'm curious -- does the file fail if you set "ps.fonttype: 42" in your matplotlibrc? That would at least rule out anything non-font in the file.

Aha! You may be off the hook. It fails in the same way, at 400%. With a ps file generated either way, it starts to render the image at that magnification, then crashes.

efiring@...340...:~/programs/py/mpl/tests$ evince testps.ps
ERROR: /unknownerror in --%op_show_continue--
Operand stack:

Execution stack:
    %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
    --dict:1126/1686(ro)(G)-- --dict:0/20(G)-- --dict:103/200(L)-- --dict:7/7(L)--
Current allocation mode is local
Current file position is 85042
ESP Ghostscript 815.04: Unrecoverable error, exit code 1

** (evince:7480): WARNING **: Interpreter failed.

I just built my own ESP Ghostscript 815.04 and am able to make some pretty high resolution renderings at the commandline. I'm not exactly sure how "400%" in the GUI relates to dpi, but I can do 1200 dpi without problem. Perhaps there's something else going on in the evince stack... I'll try later on my Ubuntu box at home, since building all that on this RHEL4 box could be time consuming.

If you have gv installed on your RHEL4 box, you can use that instead of evince.

Does the following work for you?

   gs -sOUTPUT_DEVICE=pngalpha -sOutputFile=test%03d.png -r1200x1200 simple_plot_ps.ps

  gs -sDEVICE=pngalpha -sOutputFile=testps2.png -dNOPAUSE -r1200 -c showpage -c quit testps.ps

does not yield an error message. The problem seems peculiar to the way gui apps are running gs, and to the mpl way of generating the postscript, since it does not occur with cairo-generated postscript.

Eric

3

Eric Firing wrote:

Michael Droettboom wrote:

Even if my Postscript is to spec, it's not terribly useful if it crashes a very popular tool :wink:

I'm curious -- does the file fail if you set "ps.fonttype: 42" in your matplotlibrc? That would at least rule out anything non-font in the file.

I should also add that the Type 42 output is now using the ttconv code, not the old Python code. As a third point of comparison, it might be worth reverting my changes (just reverting backend_ps.py should be enough) and trying that. (I'll also send you a copy of simple_plot.ps I have lying around off-list to save you the trouble).

I just built my own ESP Ghostscript 815.04 and am able to make some pretty high resolution renderings at the commandline. I'm not exactly sure how "400%" in the GUI relates to dpi, but I can do 1200 dpi without problem. Perhaps there's something else going on in the evince stack... I'll try later on my Ubuntu box at home, since building all that on this RHEL4 box could be time consuming.

If you have gv installed on your RHEL4 box, you can use that instead of evince.

I don't have gv installed, but I tried ggv and kghostscript and both can zoom into their maximums without crashing. Both are running against ghostscript 7.07, however.

Does the following work for you?

   gs -sOUTPUT_DEVICE=pngalpha -sOutputFile=test%03d.png -r1200x1200 simple_plot_ps.ps

gs -sDEVICE=pngalpha -sOutputFile=testps2.png -dNOPAUSE -r1200 -c showpage -c quit testps.ps

does not yield an error message. The problem seems peculiar to the way gui apps are running gs, and to the mpl way of generating the postscript, since it does not occur with cairo-generated postscript.

It seems that way. Now if only I knew why that was... :wink:

Cheers,
Mike