| Summary: | gs no more rendering figure inside the frame | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | pavel sanda <ps> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 9.15 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | 2015-03-14.eps | ||
|
Description
pavel sanda
2015-08-17 08:57:43 UTC
Created attachment 11871 [details]
2015-03-14.eps
(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. (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. (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. (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? (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. 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. Thanks, I forwarded your suggestion to tex-k list. |