Bug 688267 - Ghostscript need native PDF graphic state
Summary: Ghostscript need native PDF graphic state
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: All All
: P3 enhancement
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-15 19:19 UTC by Alex Cherepanov
Modified: 2011-10-14 14:22 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
tr.tar.gz (1.36 KB, application/x-gzip)
2005-08-15 19:22 UTC, Alex Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Cherepanov 2005-08-15 19:19:33 UTC
Ghostscript need native PDF graphic state. Currently. conversion from PDF file
with "2 Tr" (fill and stroke) to another PDF expands all text into lines and curves.

There's no way to reproduce Acrobat results (bug 688007) without passing
"2 Tr" from PS level to PDF level.
Comment 1 Alex Cherepanov 2005-08-15 19:22:04 UTC
Created attachment 1619 [details]
tr.tar.gz

A simple PDF file with "2 Tr" and the result of PDF to PDF conversion.
Comment 2 Ralph Giles 2005-08-17 10:06:19 UTC
Assigning to Ray for comment. Igor would like feedback on what the best
resolution  of this (if any) would be. Please follow up, and then close or
assign to Igor.
Comment 3 Igor Melichev 2005-08-23 02:53:15 UTC
Hmm, I can see another possible problem. The PDF 1.3 specification reads on 
page 162 : "In PDF (unlike PostScript),the current path is not part of the 
graphics state and is not saved and restored along with the other graphics 
state parameters.".
Comment 4 Igor Melichev 2005-08-23 03:00:58 UTC
The problem with "2 Tr" actually doesn't require a "native PDF graphic state". 
A conversion of a text into outlines happens due to the implementation of text 
operators is made with charpath for some text rendering modes. A better way is 
to build a copy of the current font with replacing PaintType, and then 'show' 
the text twice - with the original font, and with the "stroking" font.

Alex, IMO you can make a local patch to pdf_ops.ps, but please first comply 
with Ray about the terms|bounty.
Comment 5 Igor Melichev 2005-08-23 03:02:05 UTC
A correction to Comment#3 : I've meant the PDF reference 1.4 .
Comment 6 Alex Cherepanov 2007-06-10 14:23:24 UTC
In fact, the pass-through handling of the text rendering mode is already
implemented in the PostScript part of th PDF interpreter (rev. 7794)

However, the following code in gdevpdtt.c quashes non-default rendering modes
in most cases. 

ppts->values.render_mode = (penum->pis->text_rendering_mode == 3 ? 3 : 
     font->PaintType == 0 ? 0 : penum->pis->text_rendering_mode);

Should it be replaced with :

ppts->values.render_mode = penum->pis->text_rendering_mode;
Comment 7 leonardo 2007-08-29 20:05:59 UTC
Passing to Ken since he handles pdfwrite from now.

Likely this bug doesn't need any fix to modern code and to be closed as 
worksforme, but please check for sure.
Comment 8 Ken Sharp 2007-09-08 03:05:03 UTC
There is a problem of some sort here, and I believe its due to the Tr not being
preserved.

While the original job does work now, I modified it to use different stroke and
fill colours (unlike the original). The PDF resulting from pdfwrite doesnot
contain a Tr, and renders the text all in black, where my modified file renders
a stroked outline in red.

I believe this does need work, and I do think that the text rendering state does
need to be preserved. FWIW, the output file also doesn't contain the correct
(modified) stroke colour either.

I do believe this is a bug, not an enhancement, the file does (now at least)
display incorrectly after conversion.
Comment 9 Shailesh Mistry 2011-07-16 11:33:15 UTC
Bug still reproducible in Ghostscript 9.03
Comment 10 Ken Sharp 2011-10-14 14:22:22 UTC
I believe this is finally fixed in git commit:
419d3f8f787d90a71623b27100972eca64d03cc1