Converting a PostScript file to PDF using the pdfwrite device produces a PDF file with text selection regions that are the correct width and left margin, but much greater in height than the text. I've noted a corrected bug related to /FontBBox, and that patch appears to be in the 8.70 release that I'm testing with. This problem may be similar. The PostScript file is created by a Windows 'print to file' using any of several PostScript print drivers (Generic MS Publisher Imagesetter, Adobe Generic PostScript Driver, HP Laserjet 4000 PS). One particular sample was a printed Excel spreadsheet. I can supply the .ps and .pdf files, but need to know where to send them. Here is the command line I used: gswin32c -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=x.pdf x.ps Using Adobe Acrobat 9 Standard, using Create PDF, From File and supplying the same x.ps file results in valid text selection regions. I am actually testing on Windows 2003 Server, not 2000. I also encounter the same bug in Linux, revision 8.61.
Created attachment 5936 [details] x.ps
Created attachment 5937 [details] result.pdf
The font embedded in the document is defined as either a type 32 or a type 3 depending on characteristics of the interpreter. In this case it is written as a type 3. in both cases, however, the font is declared with a BoundingBox of [0 0 0 0] which is clearly rubbish. We alter this, because old versions at least of Adobe Acrobat don't like this kind of FontBBox, and in the absence of any other information we write the default font bounding box which is [0 0 1000 1000]. This is what causes the extremely large text selection highlight, the actual font bounding box is [0 -31 33 8] so the highlight ends up 25 times too tall. The basic problem is with the incoming PostScript which declares a useless BoundingBox. The only solution to this is to do what Adobe appears to do and check the Bounding Box of each glyph as it is defined. This would slow down processing quite considerably, sand I'm not sure that it would work properly with a non-bitmap font anyway. It is, however, possible for type 3 fonts at least as we use a special accumulator for the CharProcs, so we could determine the glyph bounding box from the accumulated operations. Changing this to an enhancement, as there is nothing wrong with what pdfwrite is currently doing. Also changing the title to reflect the new status.
At some time in the past some additional work on type 3 fonts has resolved this problem, and the type 3 fonts in this example now highlight correctly.