Bug 688298 - Miss-placed characters with pdfwrite
Summary: Miss-placed characters with pdfwrite
Status: NOTIFIED DUPLICATE of bug 687297
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: leonardo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-07 10:14 UTC by Stefan Kemper
Modified: 2011-09-18 21:46 UTC (History)
0 users

See Also:
Customer: 870
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Kemper 2005-09-07 10:14:27 UTC
------------------------------------------------------------------------
Symptoms: characters placed wrong with pdfwrite
------------------------------------------------------------------------
Ghostscript version (or include output from "gs -h"):
AFPL Ghostscript 8.51 (2005-04-18)
------------------------------------------------------------------------
Where you got Ghostscript:
Sourceforge
------------------------------------------------------------------------
Hardware system you are using (including printer model if the problem
involves printing): Intel Pentium
------------------------------------------------------------------------
Operating system you are using:
Linux
------------------------------------------------------------------------
If you are using X Windows, and your problem involved output to the 
screen, the output from running xdpyinfo and xwininfo:

------------------------------------------------------------------------
C compiler you are using, including its version, if you compiled 
Ghostscript yourself: 
gcc 3.2
------------------------------------------------------------------------
If you compiled Ghostscript yourself, changes you made to the makefiles:

------------------------------------------------------------------------
Environment variables:

   GS_DEVICE

   GS_FONTPATH

   GS_LIB

   GS_OPTIONS

------------------------------------------------------------------------
Command line:
gs -sDEVICE=pdfwrite -dBATCH -dNOPAUSE -sOutputFile=part_page12.pdf -f
part_page12.prn
------------------------------------------------------------------------
URL or FTP location of test files (include the data at the end of this 
form if 500K or less):

------------------------------------------------------------------------
Suggested fix, if any:



------------------------------------------------------------------------
Visibility of report to the public (change the answers if you want): 
May we make this problem report public?  yes 
May we include your e-mail address in a public report?  no 
May we make the test data (if longer than about 20 lines) public?  no 
Other preferences about visibility:

------------------------------------------------------------------------
Other comments:
Text that is contained in the PostScript file as a complete string is
splitted
into several texts when using pdfwrite to create a PDF-file from it.
Viewing
the file in Acrobat Reader has two disadvantages:
1.: The text is displayed with blanks inbetween
2.: The text can not be searched

This can be seen in the sample at two places: 
Line 1, word circumferential.
Line 6, word finishing.

Our main problems are displacement of characters. As the PostScript-file
prints fine on a printer, the PDF-file should be displayed in the same
way.
The sample is only a part of one document which we have to convert to
PDF
for our customer.
BTW: Viewing the PDF-file with GhostScript shows correct placement of
characters.
Comment 1 Stefan Kemper 2005-09-07 10:15:40 UTC
Created attachment 1675 [details]
part_page12.prn
Comment 2 Alex Cherepanov 2005-09-07 11:11:08 UTC
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.
Comment 3 leonardo 2005-09-08 08:46:13 UTC
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 ***
Comment 4 Alex Cherepanov 2005-09-08 14:08:44 UTC
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.
Comment 5 Marcos H. Woehrmann 2011-09-18 21:46:12 UTC
Changing customer bugs that have been resolved more than a year ago to closed.