------- Additional comments from pl Mon Apr 23 10:41:49 +0000 2007 -------

As far as I can see there is no standard violation here. Ghostscript complains
(or seems to from its output), that there is no "Encoding" entry in the Font
object of a TrueType subset font. However this is the recommended by the PDF
standard.

quoting from the relevant section of the PDF reference (section 5.5.5, p430 of
PDFReference 1.7):
<quote>
•A font that is used to display glyphs that do not use MacRomanEncoding or
WinAnsiEncoding should not specify an Encoding entry. The font descriptor’s
Symbolic flag (see Table 5.20) should be set, and its font program’s “cmap”
table should contain a (1, 0) subtable. It may also contain a (3,subtable; if
present, this subtable should map from character codes in the range 0xF000 to
0xF0FF by prepending the single-byte codes in the (1,subtable with 0xF0 and mapping
to the corresponding glyph descriptions.
</quote>

OOo exports all its TrueType subsets as symbol encoded fonts for simplicity
since all our subsets can contain glyphs outside the WinAnsiEncoding range. We
also set the Symbolic flag in the font descriptor as described.

So I think that this is a false positive on ghostscript's side.

----

Marcos gets the warning message with 8.56, but no warning with 8.54

He will attach a sample PDF file to demonstrate this.

Created attachment 2928 [details]
test.pdf

This warning first appeared in r6846 in a change in lib/pdf_font.ps:

lib/pdf_font.ps
16c16
< % $Id: pdf_font.ps 6705 2006-04-14 17:55:42Z ray $
---
> % $Id: pdf_font.ps 6846 2006-06-08 17:59:04Z ray $
82,85c82,83
<            { exch pop findencoding
<            }
<            { pop
<            }
---
>            { exch pop findencoding }
>            { pop }
88,101c86,102
<        { dup /BaseEncoding knownoget
<          {
<              dup / eq
<                { pop
<                  (   **** Warning: Ignoring bad BaseEncoding name.\n) 
pdfformaterror
<                  % as found in a PDF file from J.D.Edwards OneWorld (B7333),
bug 687786
<                }
<                {
<                  findencoding 3 -1 roll pop exch
<                }
<              ifelse
<          }
<        if
<        /Differences knownoget { updateencoding } if
---
>        { dup type /arraytype eq
>        { exch pop
>          (   **** Warning: Encoding is an array, not name or dictionary.\n) 
pdfformaterror
>        }
>        { dup /BaseEncoding knownoget
>            { dup / eq
>                { pop
>                  (   **** Warning: Ignoring bad BaseEncoding name.\n) 
pdfformaterror
>                  % as found in a PDF file from J.D.Edwards OneWorld (B7333),
bug 687786
>                }
>                { findencoding 3 -1 roll pop exch }
>              ifelse
>            }
>          if
>          /Differences knownoget { updateencoding } if
>        }
>        ifelse
103,105c104,108
<       ifelse
<     }
<    if
---
>        ifelse
>      } {
>       (   **** Warning: Encoding not present.\n)  pdfformaterror
>      }
>      ifelse

The same problem can be observed with pdf files generated by pdfTeX 1.40.3 that
contain TrueType fonts.

> >gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -s
> OutputFile=palatinox2.pdf -fpalatinox.pdf
> GPL Ghostscript 8.56 (2007-03-14)
> Copyright (C) 2007 artofcode LLC, Benicia, CA.  All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Processing pages 1 through 1.
> Page 1
>    **** Warning: Encoding not present.
> 
>    **** This file had errors that were repaired or ignored.
>    **** The file was produced by:
>    **** >>>> MiKTeX pdfTeX-1.40.3 <<<<
>    **** Please notify the author of the software that produced this
>    **** file that it does not conform to Adobe's published PDF
>    **** specification.


There has been a discussion about the issue the pdftex mailing list raising
similar points as here, <URL:http://permalink.gmane.org/gmane.comp.tex.pdftex/3441>:

(i)  The problem seems to be introduced with gs v8.56.
(ii)  Accordings to pdf specs it is a false positive, i.e., pdfTeX output is ok
and gs is wrong.

I've attached a sample pdf file generated by pdfTeX.

Thanks,
Stephan Hennig

Created attachment 2957 [details]
pdfTeX output

The problem is fixed as of rev. 7981.