Summary: | Miss-placed characters with pdfwrite | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Stefan Kemper <stefan.kemper> |
Component: | PDF Writer | Assignee: | leonardo <leonardo> |
Status: | NOTIFIED DUPLICATE | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | 870 | Word Size: | --- |
Description
Stefan Kemper
2005-09-07 10:14:27 UTC
Created attachment 1675 [details]
part_page12.prn
The text misplacement is caused by incorrect text metrics of the degree character. This is a duplicate of the bug 687297. Before GS fonts are fixed you can use real Adobe Helvetica font. The word spliting problem is an enhancement request and Leonardo (to whom the bug is currently assigned) knows this part of Ghostscript the best. Here is a better explaination. When Ghostscript generates PDF, it uses a font installed to Ghostscript. That font defines incorrect metrics for the character 'degree' - see bug 687297. Using that wrong metrics it computes offsets for characters in the text "Shell plates between TG4 + TG5 (55°-305° circumferential)". In the source document that text is divided into fragments with a small gap between, and Ghostscript preservers same structure when writing the PDF. When the document is viewed with Adobe, the viewer takes font metrics from Adobe font, in which the 'degree' character is narrower. Therefore the first fragment of the text becomes narrower, but the second fragment starts with an absolute position, which is same as in the original document. Therefore the gap becomes much bigger and visible. When a viewer performs a search, it must decide whether close text fragments are parts of same text or independent texts. With PDF such decision is always a hewrisric one. Since the gap becomes bigger, the hiwristic mistakes, and the search fails. A right way to fix this problem is to fix the font distributed with Ghostscript. Therefore I'll close this bug as a duplicate of 687297. A temporary workaround is to embedd the buggy font when generating the PDF. Another one suggested by Alex - see Comment #2. *** This bug has been marked as a duplicate of 687297 *** I don't entirely agree with the comment #3. The original PS file (and a generated PDF file) render wrong with GS fonts. The degree character and the following dash character overlap. So the embedding of the GS fonts won't help much. There's no heuristics in Acrobat reader. Ghostscript splits a string of text from a single xshow operation into multiple TJ operations. This should not happen. Conversion of the sample file with a real Helvetica still splits the words and the resulting file is still unsearchable by Acrobat Reader. I recommend to reopen the bug. Changing customer bugs that have been resolved more than a year ago to closed. |