Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
- From: ken <ken@xxxxxxxxxxx>
- Date: Sat, 9 May 2009 12:50:31 +0100
In article <51a6dff2-e452-40e6-83b0-2f3f531599d4
@x6g2000vbg.googlegroups.com>, pipitas@xxxxxxxxxxxxxx says...
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.
They should be identical (barring a few matedata style things, a few
bytyes at most), sounds like they are using different fonts for Courier-
Bold.
- 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.
Again, without seeing the file I can't tell really. However, you can't
use a font 'unencoded', at least not without using glyphshow, and I'm
guessing that's not the case. Even then the font *does* have an
encoding, its jut not being used.
Assuming that the Courier fonts on the two systems are different (see
Courier-Bold) above, the most likely explanation is that the default
encoding (all fonts *must* haev an Encoding) is different between the
two fonts. One may be using StandardEncoding and the other might be
using MacRomanEncoding for instance.
If you don't apply a specific encoding, then the glyphs which appear in
response to a given character code may be differnt between the two
fonts. This is most likely to be the case with character codes > 127.
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?
Sort of, the data representation is different, but the execution of the
font program is broadly the same. Its not quite as simple as
compression, its a more compact representation of the same information.
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 :-)
Assuming everyone runs the same revision of GhostScript, on the smae
operating system, with the same fonts available and using the same
command line options. Not so easy to reproduce for certain.
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?
Don't know, can't tell in the dark....
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!
Well I was describing general differences, remember I'm not looking at
your file...
By the way, the /.notdef glyph in PostScript fonts is conventionally
empty, so it sounds like your viewer is using a TrueType font instead,
where the /.notdef glyph is conventionally a hollow square.
Could this be a bug in the prfont.ps utility, or a bug in Ghostscript?
Likely neither, you just need to do more research to understand exactly
what's going on. Font substitution always leads to problems, you should
really embed all fonts.
Ken
.
- Follow-Ups:
- References:
- Prev by Date: Re: How to find out build configuration of my currently used Ghostscript executable?
- Next by Date: Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
- Previous by thread: Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
- Next by thread: Re: Different behaviour of NimbusMonL-Bold and Courier-Bold in PDF created by pdfwrite
- Index(es):
Relevant Pages
|
