Bug 697023 - small caps first character is too large
Summary: small caps first character is too large
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 9.18
Hardware: PC Linux
: P4 minor
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-05 13:27 UTC by ghostscript
Modified: 2016-08-09 08:13 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
PDF with small caps (270.09 KB, application/pdf)
2016-08-05 13:27 UTC, ghostscript
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ghostscript 2016-08-05 13:27:36 UTC
Created attachment 12826 [details]
PDF with small caps

I have a PDF created in InDesign CS4, some of the text uses what InDesign calls small caps. (This is where all the characters are uppercase glyphs and "uppercase" characters are larger than "lowercase" letters)

When using -dTextAlphaBits=4 (or -dTextAlphaBits=2) but not -r the first characters of the small caps text are about twice as big as they should be.

If you use the -r argument the characters are rendered at the correct size.

to produce bad output:
gs -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=png16m -dTextAlphaBits=4 -sOutputFile=2016-08-03_gs.png 2016-08-03.pdf 

to produce good output:
gs -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT -sDEVICE=png16m -dTextAlphaBits=4 -r100 -sOutputFile=2016-08-03_gs.png 2016-08-03.pdf 

The -r was not required in ghostscript 9.05.
Comment 1 Ken Sharp 2016-08-06 01:55:13 UTC
If the resolution makes a difference then this is a rendering problem, and nothing to do with the PDF interpreter.

I can't reproduce your problem, I've tried current code and the code from the 9.18 release on 64-bit Linux, 32-bit Windows and 64-bit Windows, all render the file the same way, whether TextAlphaBits is set or not. Can you be more explicit about which text exactly you see a problem with ? I'm assuming its the headline but perhaps its something more obscure and I'm missing it.

Assuming it is the headline, where did you get the version of Ghostscript you are using ? If its from a package rather than being built from source I would suggest that you get the (current) 9.19 source, build that and try again. We need to be sure you are using our source, not something which has been modified.
Comment 2 ghostscript 2016-08-08 08:20:03 UTC
The version I had the problem with is from the ubuntu 16.04 packages. I built Ghostscirpt from source, and 9.18 and 9.19 do not have the problem. 

I did not realize that the ubuntu version was different, but in the change log here http://changelogs.ubuntu.com/changelogs/pool/main/g/ghostscript/ghostscript_9.18~dfsg~0-0ubuntu2/copyright it says the ubuntu package excludes some non-DFSG files. 

I probably should have mentioned that the ubuntu version also throws some warnings like "GPL Ghostscript 9.18: Some glyphs of the font SRVNCI+Helvetica-Bold requires a patented True Type interpreter." I thought the problem was elsewhere in the document and that it would fail to output any glyph when it lacked a required component.

That patented True Type interpreter must be some of those non-DFSG files they excluded from your fine piece of software.
Comment 3 Ken Sharp 2016-08-08 08:50:46 UTC
(In reply to ghostscript from comment #2)

> The version I had the problem with is from the ubuntu 16.04 packages. I
> built Ghostscirpt from source, and 9.18 and 9.19 do not have the problem. 

Thanks for trying that out, its good to know that our source is OK.


> http://changelogs.ubuntu.com/changelogs/pool/main/g/ghostscript/
> ghostscript_9.18~dfsg~0-0ubuntu2/copyright it says the ubuntu package
> excludes some non-DFSG files. 

I'm unsure what they mean by 'DSFG' that's not an acronym I'm familiar with, but....

 
> I probably should have mentioned that the ubuntu version also throws some
> warnings like "GPL Ghostscript 9.18: Some glyphs of the font
> SRVNCI+Helvetica-Bold requires a patented True Type interpreter." I thought
> the problem was elsewhere in the document and that it would fail to output
> any glyph when it lacked a required component.
> 
> That patented True Type interpreter must be some of those non-DFSG files
> they excluded from your fine piece of software.

Looking at the link you provided it appears that they are not using any of the 3rd party library source we supply. This is not uncommon in Linux packages, as these third party libraries can be replaced with the ones already on the system. The maintainers stance is that this is important for security as it means that should security problems emerge then the libraries can be replaced without rebuilding Ghostscript. Our point is that this means using code other than that which we have tested with Ghostscript. In some cases we have patches against the standard libraries which have been submitted upstream but, for one reason or another, not adopted.

Now its *possible* that if you update your FreeType installation to a newer version the problem will go away. Ghostscript uses an unmodified version of FreeType.

However, the fact that you get warnings about using a patented TrueType interpreter make me think that the packager has not included FreeType at all, and hence forcing Ghostscript to use the fallback (very elderly) internal TrueType interpreter. This interpreter dates form a time before the patents on TrueType expired, and this is very likely the source of the problem.

You might want to raise this as a bug with the Ubuntu package maintainer......


[later]
Ah, I see DSFG is the Debian Free Software Guidelines. Debian has some (to our mind) peculiar requirements about open source and they won't accept a number of files we supply, eg the Adobe CMap files. Quite why Ubuntu should be following them escapes me, and why they would exclude FreeType escapes me even further.

That sounds like a mistake to me, someone has (I suspect) been over-enthusiastic about stripping stuff out. If you do open a Ubuntu bug you might mention that at some point we will probably remove thaqt old fallback code, so not supplying (or dynamically linking) FreeTytpe will cause Ghostscript to be unusable with any file containing TrueType (or type 42) fonts.
Comment 4 Till Kamppeter 2016-08-08 13:51:08 UTC
Please note that at Ubuntu we are currently overtaking Debian's packaging nearly completely, so if our current package of GhostScript 9.19 (in Yakkety, 16.10) still shows the problem, please report a bug at Debian.

If Debian refuses to use FreeType in Ghostscript, then please tell, so that I can change this Ubuntu-only.
Comment 5 Till Kamppeter 2016-08-08 15:23:30 UTC
Thanks for the second patch. I will try it.

It seems that you know better about how Ghostscript's built-in drivers work than me. Can you have a look about the re-introduction of the ManualFeed code? Thanks.
Comment 6 Till Kamppeter 2016-08-08 15:29:58 UTC
Sorry, ignore the last comment, it was for another bug.
Comment 7 ghostscript 2016-08-09 08:13:15 UTC
I just tried this in the nightly of Ubuntu 16.10 and it didn't show the problem.

I also posted this issue here https://answers.launchpad.net/ubuntu/+question/328858, but so far there isn't any new news.