Created attachment 8445 [details] printout.ps See https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/960989 comment #15. A PostScript file generated by Okular (attached) is converted to PDF by the CUPS printing workflow, using Ghostscript (I tested with 9.05 but 9.04 seems to show the same problem. At the top, in the text (probably an address) at the right of the logo the spaces and accents are not set correctly, most spaces, like in the phone numbers are missing. To reproduce, run gs -sDEVICE=pdfwrite -sOutputFile=out.pdf printout.ps with the attached file as input.
For some reason we are writing the space glyph for at least some of these fonts with a Width entry of 0. Not sure why yet.
The problem is the input PostScript. It contains fonts which are subset, but do not contain the space glyph. The program then proceeds to use the space glyp[h from that font. This is then substituted with the /.notdef glyph, and it is the width of this glyph which is used. The problem is further exacerbated by the fact that the program tries to 'fit' the string into a known width (presumably in case of font substitution, though this isn't clear). pdfwrite can't find the space glyph (because it isn't present!) and the font does not contain a MissingWidth key, so it assigns the glyph a width of 0 rather than using the /.notdef width. The PostScritp program then rearranges all the characters in the string so that the 'error' caused by the 0 space width is distributed amongst all the characters in the string. The result is that the space disappears. I did try using the width of the /.notdef in preference to 0 when a glyph cannot be found in the font, but this caused several other files to go awry, I'm not sure why yet but two of them are the Quality Logic CET files, and the other two are 'real world' PDF files. I will look further and see if I can determine a way around this, but at the moment I'm inclined to feel that this is a buggy PostScript file and the problem should be addressed by the PostScript producer (Note that this file has already been apparently transformed from PDF to PostScript).
I believe this is (finally!) fixed with Git commit: be6456331f4cff58f11f681450166fe2309e2ad5 I still feel that relying on the /.notdef glyph in place of a space glyph is very bad practice and the producer of the application which did this shuold be informed that this is a bug. Its 'probably' the PostScript produced by Okular, but without that PostScript file to check I cannot be sure. It is just possible that the very early version of Ghostscript used to produce the PDF (from which the PostScritp attached to this report was produced) had a bug.