Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite

Thank you, Ken, for your quick response.

On 9 Mai, 10:50, ken <k...@xxxxxxxxxxx> wrote:
In article <1053a671-9ca4-4732-844e-
9db6dd368...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, pipi...@xxxxxxxxxxxxxx
says...

So, if I use the same font under its alias-name "Courier", it does not
get embedded into the PDF file, and the PDF says it's using a "Type 1"
font, not subsetted! If I use it under its original name, it does
indeed get embedded as a "Type 1C", as a subset.

I'm looking for an explanation for this behaviour. In the Ps2pdf.htm
docu file I find this statement:

"(note 11) The default, screen, and ebook settings
never embed the 14 standard fonts (Courier, Helvetica,
and Times families, Symbol, and ZapfDingbats)."

Most likely this note completely explains what I'm seeing.

Yes, the base 14 fonts do not get embedded, becasue they are guaranteed
to be present on all readers.

Probably I
can enforce the embedding by passing the appropriate option on the
commandline (I didn't research yet how to do this...)

No, I don't think so.

I did some more reading in the meanwhile, and according to Ps2pdf.htm
it should embed even Courier if I do it like that:

gswin32c.exe -dNOPAUSE -sDEVICE=pdfwrite \
-sOutputFile=WinXP-Courier-Bold-glyphs.pdf \
-f c:/pa/gs/gs8.61/lib/prfont.ps \
-c ".setpdfwrite <</AlwaysEmbed [/Helvetica /Times-
Roman /Courier-Bold /Courier]>> setdistillerparams \
-c "/Courier-Bold DoFont"
-c quit

This time I did run the commandline on Windows, and it yields (nearly)
the same results:

* The file size is nearly the same as the Ubuntu-made Courier-Bold-
glyphs.pdf, but it is 197212 Bytes instead of 190696 Bytes.

* The pdffonts command does give the very same result describing the
fonts used (even the object IDs are the same).

* The visual comparison of both PDFs does give interesting
differences:

- for the first two pages each of the files appears
exactly the same, pixel by pixel, even if I do a
zooming in on 200%. These pages are headlined
"characters 0-127" and "characters 128-255".

- for the next 4 pages each of the files is very
different to the other. These pages are headlined
"unencoded characters". Some of the glyphs have
swapped their locations. But even many of those
glyphs which are on the same location of the table
grid (examples for my case: Ccircumflex and
Cdotaccent are showing slight differences in size
and appearance).

I do not have any idea why this should be so. OK, both files have been
generated by two slightly different versions of Ghostscript on 2 very
different operating systems. But they both use an un-embedded Courier.
And they both are opened with Acrobat Reader on Windows, so they
should be using the same instance of Courier (wherever AcroRd.exe
finds it, I don't know) to render the pages. Why there are some glyphs
swapped to different places in the table grid for the "unencoded
characters" on pages 3-6 may well be due to the fact that both files
were generated on different platforms (maybe the generation process
used 2 different versions of prfonts.ps, I'll have to check that!).
But why those glyphs that are on the same locations do display
differences is beyond me.

I think once I fully understand and grasp these "simple" font
questions, I'm halfway through to a finding a solution for my other
PDF problems.

I didn't find out much yet about the "Type 1C" fonttype, and how it is
different from Type 1.

Compact Font Format.

OK. So it's basically the same as "Type 1" but compressed?

But I am wondering about these questions:

* Why does pdffonts report Courier-Bold like it's embedded 5
different times? Why not only once?

Could be a problem with the tool, or it could be embedded 5 times, can't
say without seeing the file. The tool could be reporting its presence on
each page (pages are required to declare which objects, including fonts,
the are using).

* And why is one of the 5 entries tagged with a "ToUnicode" map,
while 4 are not?

Again, without seeing the file, I can't tell.

Currently I have no possibility to upload the files onto a webspace I
have control over. I'll research if there are websites which do offer
this as a public service.

However, everybody with Ghostscript installed can run the same command
and produce the "same" files :-) Would also be interesting if other
versions of Ghostscript in other environments produce such
differences. The "pdffonts" utility is part of the XPDF package, BTW.

* Why is the NimbusMonL-Bold embedded with 5 different subsets and
names?

Presumably because you allowed SubsetFonts true. Each page then gets its
own subset.

That was my first supposition too. But the PDFs are 6 pages long --
that should mean we'd have 6 different subsets, no?

* Why is 1 out of 5 NimbusMonL-Bold subset fonts tagged with a
"ToUnicode" map, while 4 are not?

See your question about Courier above, whatever the reason its
undoubteldy the same.

BTW, I was a bit sleazy in my description saying "NimbusMonL-Bold
embedded with 5 different subsets and names". In fact it is embedded
with 5 different object IDs and 3 different names (3 object IDs do
share the same name/prefix).

I assume the general difference in the two files' visual display
through Acrobat Reader on Windows is due to the fact that the Courier
PDF does not have the font embedded, and Acrobat then uses the font
with that name found through its own resources (or through the OS),
while the Nimbus PDF has a Nimbus subset font embedded itself.

Correct, and the appearance of the two versions of Courier may not be
the same. THis also explains the slight positioning differences you see
when glyphs are not individually positioned, the widths (not kerning or
hinting) of the glyphs are not the same and so there are minor
positioning differences.

The problem is _not_ constrained to just minor width or minor
positioning differences. The _major_ difference is that some of the
very same characters whose glyphs draw fine in the big table grid are
not present at all in the text area of the lower left corner. They are
represented by the .notdef glyph there!

Could this be a bug in the prfont.ps utility, or a bug in Ghostscript?

Can anyone shed more light on this?

Not without seeing the PDF file.

I'll work on this. However, I could reproduce basically the same
result in 2 different environments:

* Ubuntu on 64AMD, Ghostscript v. 8.61
* WinXP Prof on i386, Ghostscript v. 8.64
.

Relevant Pages
Loading