Bug 689420

Created attachment 3312 [details]
Suggested patch.

Part #1 of 2:
    ps2write: if the FontName cannot be represented as a literal PS 
    name, write it as "(fontname) cvn", escaping chars as necessary.
    
    ATM compatibility notes:
  - In theory, for compatibility with Type 1 renderers that do not 
    include a full PostScript interpreter, the FontName should be a 
    literal name. Only in theory. Time ago, I verified that in 
    practice Adobe Type Manager, Adobe Reader and the Type 1 
    interpreter built into Windows accept and handle fonts that have 
    "/FontName (name) cvn def".
  - Since ps2write's output is consumed by a full-blown PostScript 
    interpreter, ATM compatibility is not necessary.

Part #2 of 2:
    opdfread.sp: un-hex-escape (/#41 -> /A) font names from PDF Font 
    and related objects. Note: this un-escaping is potentially 
    necessary for any name, but font names are the only place that 
    I can think of where these escapes appear and make a difference.

Rather than encoding names into PS strings, I recommend using the much simpler
approach of hex strings. For example:

   /FontName <41424320444546> cvn def

instead of:

   /FontName (ABC DEF) cvn def

Since the target printers are PS Level 2, hex strings are supported.

I vote for the string with escaped characters because it is much easier to read.
When we get the generated files back attached to bug reports, there will be
one less hurdle to jump.

I think I agree with Alex, its easier to read the result, and I'm not sure what
the hex representation gains, other than not having to escape some characters.

The only gain is _much_ simpler code in 'write_font_name'.

If we are going to do the PS style string, then I change my recommedation to:

Re-use the existing s_PSSE filter rather than implementing yet another form
of this conversion. Refer to the code in obj_cvp (iutil.c) where it handles
t_string for an example.

Since implementing the PS style string using the filter needs extra work from
the patch submitter, I am making the 'bountiable' to encourage the follow-up
development.

Ah, thanks Ray, I didn't realise there was already code to handle this. I guess
since its P4 I can just sit back and wait to see if the OP would like to modify
the patch and claim the bounty :-)

BTW, the code to use the s_PSSE_template.process function doesn't need to be
quite as general as that in iutil.c since much of it is do handle long strings.
If the destination string (str) is large enough to accomodate the worst case
FontName (allowing for worst case expansion due to escapes), then the 'process'
only needs to be called once (not in a loop).

Created attachment 3341 [details]
Revised patch.

As requested, attached is a patch revised to use an existing function 
for PS string encoding, rather than implementing this conversion again.

The functionality is the same as before (comment #1).

Please take into account one more thing. With a light modification the old code 
allows us to write a PDF with ebmedded Tyoe 1 font (with no converting into 
CFF). Particularly this feature is used in the FAPI development. I checked the 
revised patch, and it looks safe against that. Anyway please be careful with 
further improvements.

Regarding the "Revised patch" : 

I see the updated write_font_name encodes with Postscript string escapes, and 
the updated opdfread.ps decodes the font name from PDF encoding. I believe they 
are inconsistent.

By another hand, it's a good observation that the PDF name decoding to be 
implemented in opdfread and called in appropriate places. But I believe there 
exist much more places to call it than the patch does. Likely we need to open a 
separate bug for it. Ken, please check for sure and open one.

> With a light modification the old code allows us to write a PDF 
> with ebmedded Tyoe 1 font (with no converting into CFF).

Time ago (when I noticed this problem in the sample for bug #688001), 
I checked that PDFs that use this syntax work OK with Reader and in 
a few other situations - see "ATM compatibility notes" in comment #1. 
But yes, one never knows what another PDF/font consummer could expect.

> I see the updated write_font_name encodes with Postscript string 
> escapes, and the updated opdfread.ps decodes the font name from 
> PDF encoding. I believe they are inconsistent.

There is a difference, but these names are in different places:

- the PS string encode is used inside the PDF stream that contains 
  Type 1 font data, which is expected to be kind of PostScript code;
- the PDF hex encoding (and thus the necessary PDF hex decoding) 
  is for the FontName entry is the PDF dictionary that describes 
  the font (this data is passed to the PDF interpreter).

The problem described as "Bypassing this error, one will get a 
default font (Courier) instead of the requested one." in the 
original report (comment #0) comes exactly from the fact that names 
in these 2 places didn't match (due to lack of PDF hex decoding).

In Comment #10 I wrote "I see the updated write_font_name encodes with 
Postscript string escapes, and the updated opdfread.ps decodes the font name 
from PDF encoding. I believe they are inconsistent."

This statement is wrong, because those encodings are applied to different 
occurances of the name. I withdraw it.

Patch http://ghostscript.com/pipermail/gs-cvs/2007-October/007876.html,
essentially as submitted by SaGS, resolves this issue.