Created attachment 2962 [details]
Sample PS

Please attach your command line(s).

Passing to Ken since he handles pdfwrite from now.

Command-line examples as requested:

1) For not subsetting (e.g. fully embed) TrueType fonts:
gswin32c -sFONTPATH=c:/windows/fonts -dNOPAUSE -dBATCH -sDEVICE=pdfwrite
-dPDFSETTINGS=/prepress -dEmbedAllFonts=true -dSubsetFonts=false
-sOutputFile=out.pdf in.ps

2) For not embedding (used for testing only):
gswin32c -sFONTPATH=c:/windows/fonts -dNOPAUSE -dBATCH -sDEVICE=pdfwrite
-dPDFSETTINGS=/prepress -dEmbedAllFonts=false -sOutputFile=out.pdf in.ps

Any news on this bug yet?

As far as I can see, pdfwrite in fact always embeds the full font, and never
embeds a subset, when the original font is a TrueType.

Although these are full fonts, they are still written with the usual prefix 
'XXXX+', which is why they can't be recognised as the same font, and presumably
why merging the files together results in several large embedded fonts.

So actually there are two problems here, neither as described in the summary:

1) When writing a complete TrueType font pdfwrite still prefixes it with a 
unique name identifier.

2) pdfwrite ignores 'SubsetFonts' and always embeds the complete font when the
original is a TrueType.

Note to self, the second of these problems is even commented in gdevpsft.c,
psf_write_truetype_data(), around line 877:

    /*
     * For subset fonts, we should trim the loca table so that it only
     * contains entries through max_glyph.  Unfortunately, this would
     * require changing numGlyphs in maxp, which in turn would affect hdmx,
     * hhea, hmtx, vdmx, vhea, vmtx, and possibly other tables.  This is way
     * more work than we want to do right now.
     */

The first problem is a liitle more obscure.
We add the prefix in gdevpdtf.c, pdf_compute_BaseFont(), around line 733. 
Because we have allowed subsetting, and font has been marked as a candidate for
subsetting, we apply the subset prefix to the font name. Even though we don't
actually write a subset...


dlkz, I'm not sure where you are getting the switches you are trying to use, 
there is no 'SubsetFonts' device parameter, and I can't find it described in
the documentation anywhere.

However, the SubsetFonts distiller parameter *does* work. If you add:

-c ".setpdfwrite <</SubsetFonts false>> setdistillerparams" -f

to your command line, you should find that the fonts are no longer candidates
for subsetting (as subsetting has been disabled). If I do this I correctly see
that the font is output without a subset prefix in the name.

Presumably this would allow you to merge PDF files without ending up with lots
of fonts which appear to be (but are not) subsets.

Please don't close this issue! At some point we should fix the fact that TT
fonts are not written as subsets, and this makes a useful marker for me. Not
to mention having some useful information above.

Ken,

>dlkz, I'm not sure where you are getting the switches you are trying to use, 
>there is no 'SubsetFonts' device parameter, and I can't find it described in
>the documentation anywhere.

In Ghostscript documentation ps2pdf, it is stated that:
"options may include -dparameter=value [...] for setting distiller parameters"

So -dSubsetFonts=false is shortcut to
-c ".setpdfwrite <</SubsetFonts false>> setdistillerparams"

Regards

Hmm, well I was using gs directly rather than ps2pdf, though the syntax should
do the same, I missed the sentence in the ps2pdf docs.

Did you try this with a recent version of gs ? I did try it here (but not with
ps2pdf), and got a PDF file with no subset prefix on the TT font names. Of
course its not ideal, since no fonts will be subset, but it may help you until
this problem is addressed properly.

revision 9696 addresses the fact that large TrueType fonts are subset even when
subset is set to false.

This does not totally prevent the subsetting of large fonts, but it does mean
that fonts have to be considerably larger before automatic subsetting is forced.

Patch here:
http://ghostscript.com/pipermail/gs-cvs/2009-April/009282.html

Although this resolves the issue, I want to leave the issue open as a reminder
to tackle TrueType font subsets in a more general fashion.

*** Bug 690548 has been marked as a duplicate of this bug. ***

Hello Ken,
Thank you for having worked on this during the last few years.
I have had a recent occasion to try the GS 9.00 series and, even I didn't test thoroughly, the TrueType font handling seemed to follow expected behavior.
So, best wishes and God bless.
Daniel A. Lavoie

*** Bug 693083 has been marked as a duplicate of this bug. ***

See also bug 689209, where various tables need to be subset for bitmapped truetype fonts.

Unfortunately, the given workaround does not work:

gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=x2.pdf -dSAFER -c "<</SubsetFonts false>> setdistillerparams" -f x1.pdf

This does not copy x1.pdf to x2.pdf with the embedded fonts removed. Nor does:

gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=x2.pdf -dSAFER -c "<</AlwaysEmbed [ ]>> setdistillerparams" -f x1.pdf

(In reply to mirabilos from comment #14)
> Unfortunately, the given workaround does not work:

There is no 'given workaround'.

 
> gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=x2.pdf -dSAFER -c
> "<</SubsetFonts false>> setdistillerparams" -f x1.pdf
> 
> This does not copy x1.pdf to x2.pdf with the embedded fonts removed. Nor
> does:

This bug is regarding fonts being subset instead of being embedded as complete fonts.

It is nothing to do with removing fonts.


> gs -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=x2.pdf -dSAFER -c
> "<</AlwaysEmbed [ ]>> setdistillerparams" -f x1.pdf

So this does not seem to be relevant to the bug report here. In addition you have not supplied an example file to work from.

I would suggest that you open a new bug report, since this appears to be a different problem (if indeed there is a problem). Be clear about what you are trying to achieve, attach a specimen file and give the command line which you are using.