Created attachment 7549 [details] test.pdf The attached PDF-file test.pdf contains text with RenderMode FILLSTROKE. When converting the file to PDF ( for generating PDF/A ), the text is generated with fill and stroke paths. The size of the output file raises extremly and unfortunately the text cannot be searched, because it is defined with paths.
The converted file has (approximately) the same appearance, so this is an enhancement request, not a bug.
The appearance is the same, this is ok. But the text is no more a text and cannot be searched for. So I would be very glad, if you do not interpret this as an enhancement request. There is a tip from me: in the PDF-file a text spacing is set. if the text spacing is set to 0, then everything is ok.
PDF interpreter already processes text rendering modes specially. The sample file has "2 Tr", fill and stroke. This code is easy to change providing Kens tells what he would prefer here. /pdfwrite_textrenderingprocs [ % ... % Tr 2 - Fill then Stroke { gsave 0 .settextrenderingmode setfillstate dup show currentpoint 3 -1 roll grestore gsave setstrokestate //false charpath % We need to make sure the matrix used for the stroke % and therefore stroke width does not include the % Text Matrix Tm. TextSaveMatrix setmatrix .swapcolors stroke .swapcolors grestore moveto } bind ]
(In reply to comment #3) > PDF interpreter already processes text rendering modes specially. > The sample file has "2 Tr", fill and stroke. > This code is easy to change providing Kens tells what he would > prefer here. > > /pdfwrite_textrenderingprocs [ In fact the code doesn't go through this path at all, because (I think) it uses TJ. It goes into the 'else' clause of this test: WordSpacing 0 eq TextSpacing 0 eq and FontMatrixNonHV not and which doesn't appear to use pdfwrite_textrenderingprocs at all. It 'looks like' all I need for pdfwrite is for the PDF interpreter to set the text rendering mode, and then just call whichever 'show' variant is required leaving all the fill/stroke/clip nonsense alone (ie treat it as Tr 0). This code tests to see if the device expects to handle text rendering modes: % Check to see if the current device supports Tr currentdevice 1 dict dup /PreserveTrMode dup put .getdeviceparams dup type /booleantype eq not {cleartomark //false}{3 1 roll cleartomark}ifelse I'm trying to hack the PDF interpreter now to do what I need so that I can test the action of pdfwrite, but it looks like all or at least most of the code to deal with this is already present in pdfwrite.
Created attachment 7930 [details] example patch for Tr 2 *DO NOT USE* This patch forces the PDF interpreter to treat 'spaced' text as if it were in text rendering mode 0 when writing to a device which supports text rendering modes. This works for the supplied test file here, but regression testing shows 6 files with serious problems. I suspect the stroke parameters are not being correctly set up (because we are pretending that the rendering mode is 0), which is causing incorrect colours and/or stroke widths to be emitted. I will continue to look at the PDF interpreter, but it might be useful if Alex could look at this as well.
This is resolved with Git commit: 419d3f8f787d90a71623b27100972eca64d03cc1 However, as noted in the commit log, I suspect Alex will want to reformat the code I've added to the PDF interpeter, and there is something weird that I do not understand happening in one case where a PDF file uses a type 3 font. I think it would be helpful if Alex looked into that. The current code work with that case, but I don't understand why it has to be different to the other cases. So I'm reassigning this one to Alex.
Ken is right. A few things in the commit can be improved. Fix a typo in absolute value comparison. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=70d513095fba13b20e6bba5bb77805b5233028d1
Replace a fragment that stores line width in a dictionary with an equivalent code that uses execution stack and .execn . These tricks are needed to keep the stack depth constant. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=012aef926d1e33cc64c32bf8e94ef92a299d73f9