Created attachment 3873 [details]
W1187YD.PDF

Created attachment 3874 [details]
screenshot.png

Created attachment 3875 [details]
simplified.pdf

Comment on attachment 3875 [details]
simplified.pdf

Much simplified PDF file, all but the applicable text (shown in the screenshot)
as been removed. 

BTW, I found a cool, free plugin for Acrobat Professional that allows the page
size to be reduced: http://www.windjack.com/products/freestuff.html

This looks to me like Ghostscript is using the 'standard' TrueType /.notdef
glyph which is a hollow square. Not all PDF readers do this, in particular
Acrobat simply ignores glyphs in a TrueType font which are not present.

uncompressing the PDF file reveals the following text strings:

[(  \(Refer to )55(ASSEMBL)74(Y)18( DIAGRAM\).  \t )]TJ
( keeping top edges flush.\t\t)Tj
(using\tScrews )Tj


You can see the '\t' in the text strings correspond to the squares in the GS
output. I imagine the font doesn't have a matching glyph and GS (correctly) uses
the standard TrueType /.notdef glyph.

In my former employment, after much complaint from customers, we implemented a
switch to either render TrueType /.notdef glyphs, or to ignore them. I think
something similar will be required here. In my opinion, technically GS is
correct, but it doesn't match Acrobat which is regarded as the standard.

Also, annoyingly, the Producer of the file is Adobe PDF Library from Adobe
Illustrator, so I don't think we can ignore it or ask the producer to fix it.

Ghostscript does paint notdef glyph when the required glyph is absent, rather I 
didn't check whether it is the case here. Note we have had a lot of bugs 
about "boxes", which were resolved as wontfix. Maybe now we should make another 
resolition.

Note that this is a high priority customer and FWIW, I like Ken's idea of
an option better than WONTFIX.

Displaying/rendering the same as Adobe Acrobat (and our competition) is generally
a (IMHO, reasonable) expectation.

The simplest resolution is like this to be inserted into .type42build :

  currentdevice .devicename /pdfwrite eq {
    /.notdef CharStrings /space get
  } {
       /.notdef CharStrings /.notdef get
  } ifelse

One problem here is that somtimes with pdfwrite currentdevice is the cache, so 
maybe will need a global flag set with with .schedule_init .

Ah, I think the fact that I replied may have misled Leonardo into thinking this
is a pdfwrite-specific problem, which I don't think it is. I think the customer
is rendering the PDF file (produced by Adobe), and doesn't want the .notdef
glyphs rendered.

However the point about .type42build looks good, perhaps we could define a new
global flag (a new '-d' parameter ?) and inspect that, instead of checking if
the current device is pdfwrite ?

I do see one potential (if unlikely) problem, what happens if the font doesn't
contain a /space glyph ?

I'll shut up now, this isn't my bug...

A 'space' glyph is NOT the same as ignoring the .notdef -- it moves the current
point.

I still favor Ken's original suggestion (as Jaws did) of having an option to
ignore .notdef -- if this is done by substituting a different glyph for .notdef,
it should be one that does not move the currentpoint (and this should be a
command line option).

Regarding comment #9 : I did not assume it is pdfwrite issue. It definitely is 
PDF interpreter problem. Also we don't need a new -d parameter, because the 
interpreter knows the file type. I have no objection if Ken will work on this 
bug (and other font bugs), because I'm busy with kernel.

Regarding comment #13 : Why Ray thinks that the current point must not move ? 
From old bugs I know it must, so substituting space is right at least for old 
examples. For the this bug's document it looks safe as well. 

Regarding comment #11:

I think that this needs to be an option because 'strict' rendering of .notdef
characters should (AFAIK) use the definition in the font -- ignoring .notdef
character definition in a font or printing a 'space' instead is (IMHO) not
something that we should assume is the desired behavior.

Regarding the comment "From old bugs I know it must [move the currentpoint], 
so substituting space is right at least for old examples." I request that
Igor provides more details on these cases. This does not seem to be usually
expected from the TT fonts I've looked at that either have a 'small square' or
a 'null' character that doesn't print anything nor move the currentpoint.

We really need to get someone to 'own' this problem and fix it, since this is
an important issue.

Since its important I'll take this one on, at least initially. If it turns out
later that I need help I'll ask to re-assign it.

I'll check the position of the glyphs, it looks to me like Acrobat is 'probably'
using the width defined in the /Widths array for the glyph. For sure it isn't
leaving no gap, because otherwise the 'using\tScrews' would run together into
one word, which it doesn't on the Acrobat display. The Widths array does have a
non-zero entry for the glyph, I can check if Acrobat is using that by modifying
the value and seeing if the positioning changes.

Right now I'm looking at a different TrueType issue (pdfwrite and PDF/A output)
so if anyone does want to jump in, feel free. Otherwise I'll get to it next.

Here are related bugs : bug 687929 bug 436099 bug 633996 bug 686959 bug 687387 
Note sometimes the problem is reported as pdfwrite problem, sometimes as PDF 
interp;reter problem. I believe they both have same nature. Likely Adobe 
ignores .notdef when rendering a PDF.

Regarding comment #12: I do not suggest to ignore .notdef in Postscript. I 
suggest to replace with space only when rendering a PDF.

The list of bugs in comment #14 is not neccesserily complete. I listed ones 
that I could fing in half hour. An additional search would be useful. The 
listed bugs were found as containing "boxes" in a comment.

Fixing the assignment according to comment #13

I've spent quite some time trying to work out what prompts Acrobat to render a
/.notdef glyph, and when it doesn't. I haven't been able to draw any
conclusions, but I do have some negative information.

Starting with a file produced by Distiller, the /.notdef glyphs are not rendered
in Acrobat. Its not the font name, changing the standard 'base 14' name to
something totally different makes no difference. Making the font symbolic has no
effect, adding the /.notdef glyph to a /Differences in the Encoding has no effect.

Starting with the output of pdfwrite, the /.notdef glyphs are rendered in
Acrobat. Making the font non-symbolic and removing the direct reference to
/.notdef from the /Encoding causes Acrobat to stop rendering the /.notdef glyphs.

Whenever Acrobat elides the /.notdef it appears to still use the width of the
original glyph, if it is specified in a /Widths array. If there is no /Widths
array, it seems to use the width of the /.notdef glyph.

I've got a patch which I'm just completing testing which addresses the 'issue'.
It introduces a new command line switch RENDERTTNOTDEF, which the PDF
interpreter uses to set a user parameter '\RenderTTNotdef'. The default
behaviour is to render /.notdef glyphs when in PostScript and NOT render them
when interpreting a PDF file.

The reason this is a switch, is because Acrobat does still render /.notdef
glyphs, I just can't work out the rules it is using.

I've checked the behaviour of all the prior issues that Leonardo mentions, and
done a trawl through the database for other cases. There were surprisingly few,
most are related to encoding problems and the presence of the /.notdef was to be
expected. I did find three other case, 687387, 688315 and 687929. All render as
per Acrobat with the patch, and display boxes as reported without.

Patch committed as:

http://ghostscript.com/pipermail/gs-cvs/2008-April/008217.html

which resolves this, and similar issues, for me.