Bug 696152 - gs no more rendering figure inside the frame
Summary: gs no more rendering figure inside the frame
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.15
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-17 08:57 UTC by pavel sanda
Modified: 2015-08-19 09:49 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
2015-03-14.eps (147.62 KB, application/postscript)
2015-08-17 08:59 UTC, pavel sanda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pavel sanda 2015-08-17 08:57:43 UTC
attached is eps file which loads fine when using several postscript viewers (e.g. gv, evince) but the content inside frame disappears when converting via epstopdf.

the underlying problem is related to the gs version.  epstopdf --debug shows the exact gs invocation, which is:
gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
-sOutputFile=2015-03-14.pdf -dPDFSETTINGS#/prepress -dMaxSubsetPct=100 \
-dSubsetFonts=true -dEmbedAllFonts=true -dAutoRotatePages#/None \
2015-03-14.eps -c quit

when using older gs 901 the interior of the frame appears. 
with gs 910 as well as gs 914 it disappears.

the problem can be consistently reproduced by using matlab imagesc function for graphs with scaled x axis.
Comment 1 pavel sanda 2015-08-17 08:59:39 UTC
Created attachment 11871 [details]
2015-03-14.eps
Comment 2 Ken Sharp 2015-08-17 09:09:34 UTC
(In reply to pavel sanda from comment #0)

> the underlying problem is related to the gs version.  epstopdf --debug shows
> the exact gs invocation, which is:
> gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
> -sOutputFile=2015-03-14.pdf -dPDFSETTINGS#/prepress -dMaxSubsetPct=100 \
> -dSubsetFonts=true -dEmbedAllFonts=true -dAutoRotatePages#/None \
> 2015-03-14.eps -c quit

That command line emobdies a lot of options. I'd suggest that you simply delete the -dPDFSETTINGS=/prepress and it will work.

Or you can go through the list of settings defined as part of the canned 'prepress' configuration and determine which one is causing the problem.

 
> when using older gs 901 the interior of the frame appears. 
> with gs 910 as well as gs 914 it disappears.

You've put 'master' as the version, but 9.14 is not the master version. If you mean 'master' then you must have built from the source in our Git repository. If you haven't then it would be better to state the actual version number you are using.
Comment 3 pavel sanda 2015-08-17 10:36:02 UTC
(In reply to Ken Sharp from comment #2)
> > the underlying problem is related to the gs version.  epstopdf --debug shows
> > the exact gs invocation, which is:
> > gs -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite \
> > -sOutputFile=2015-03-14.pdf -dPDFSETTINGS#/prepress -dMaxSubsetPct=100 \
> > -dSubsetFonts=true -dEmbedAllFonts=true -dAutoRotatePages#/None \
> > 2015-03-14.eps -c quit
> 
> That command line emobdies a lot of options. I'd suggest that you simply
> delete the -dPDFSETTINGS=/prepress and it will work.

These settings are not manually by me but the toolchain generating latex outputs, I can't 'simply delete' those settings.

I firstly reported the problem directly to epstopdf people but they suggested to report it here as the problem seems to stem from gs itself.

> You've put 'master' as the version, but 9.14 is not the master version. If
> you mean 'master' then you must have built from the source in our Git
> repository. If you haven't then it would be better to state the actual
> version number you are using.

Sorry, will fix it. The newest version available in my system is 9.15 and it does not work, but see also the comments about versions above.
Comment 4 Ken Sharp 2015-08-17 11:38:10 UTC
(In reply to pavel sanda from comment #3)

> > That command line emobdies a lot of options. I'd suggest that you simply
> > delete the -dPDFSETTINGS=/prepress and it will work.
> 
> These settings are not manually by me but the toolchain generating latex
> outputs, I can't 'simply delete' those settings.

Is epstopdf anything more than a script ? In any event, I'd very strongly recommend removing the PDFSETTINGS, if you (or the epstopdf people) require specific PDF settings then they should be set individually, not in a block.


> Sorry, will fix it. The newest version available in my system is 9.15 and it
> does not work, but see also the comments about versions above.

I'm aware there's a problem, it exists in master also, I just wanted to make the point that its really a good idea not to set the version to 'master' unless that really is what you are using.
Comment 5 pavel sanda 2015-08-17 14:20:22 UTC
(In reply to Ken Sharp from comment #4)
> In any event, I'd very strongly
> recommend removing the PDFSETTINGS, if you (or the epstopdf people) require
> specific PDF settings then they should be set individually, not in a block.

I can forward your message, but it's not really in my hands.

Is this the final answer or is my report still considered as a bug to be solved?
Comment 6 Ken Sharp 2015-08-18 00:03:49 UTC
(In reply to pavel sanda from comment #5)
> (In reply to Ken Sharp from comment #4)
> > In any event, I'd very strongly
> > recommend removing the PDFSETTINGS, if you (or the epstopdf people) require
> > specific PDF settings then they should be set individually, not in a block.
> 
> I can forward your message, but it's not really in my hands.
> 
> Is this the final answer or is my report still considered as a bug to be
> solved?

As I said in comment #4: "I'm aware there's a problem, it exists in master also" so yes its a bug. It'll be addressed when I have time.
Comment 7 Ken Sharp 2015-08-19 07:38:16 UTC
The image is very large in one direction (the X axis) which leads to a high
effective resolution for the image (in that direction).

However it is not similarly sized in the Y direction which leads to a low effective resolution in the Y direction.

Previously when deciding on a candidate for downsampling we only considered the X direction, assuming that the image would be of similar resolution in each direction. This led to the image being downsampled, so that the height of the image became 1, effectively invisible.

Commit af72527ff3b08ff91230a0884ce601b949735cf6 uses the lower of the two resolutions to decide whether to downsample.
Comment 8 pavel sanda 2015-08-19 09:49:58 UTC
Thanks, I forwarded your suggestion to tex-k list.