The test case of the Bug 688823 makes pdfwrite to synthesize an Encoding with characters outside StandardEncoding. Currently it finds a character in some encoding, and chooses the character code from it. It may cause Encoding conflict if later it meets another character from another 'standard' encoding with a character code already used. The conflict causes pdfwrite to create another font copy, which enlarges the output PDF. Need to think how to choose character codes better. Maybe we should drop the wish to make the encoding to be closer to one of 'standard' encoding, and simply assign consecutive numbers for char codes ?
Also (1) use 'notdef' entries for adding characters to a 'standard' encoding; (2) try 'bigger' encodings first (PDFDocEncoding to StandardEncoding).
Passing to Ken since he handles pdfwrite from now.
Enhancement still missing in Ghostscript 9.03