Text object gets deleted in Adobe Reader 11

故事扮演 提交于 2019-12-12 03:43:58

问题


In adobe acrobat x i was inserting text objects and when it is opened in adobe reader 10 it was opening properly.but in adobe reader 11 when i click on that pdf file text objects gets deleted.why this happens? How to solve it? The source pdf file click here

The pdf file which has problem when double clicking on it in adobe reader 11. click here


回答1:


In a nutshell:

You try to change the contents of a free text annotation by changing its normal appearance stream.

This is insufficient: A compliant PDF viewer may ignore this entry and provide their own appearances. So it's mere luck that older Adobe Reader versions chose to not ignore your change.

Thus, you also need to change the information a PDF viewer is expected to create their own appearance from, i.e. foremost the rich text value of RC (in the free text annotation dictionary) that shall be used to generate the appearance of the annotation, and also the Contents value which is the Text that shall be displayed for the annotation.

Furthermore there are defects in your PDFs:

  • the cross reference table in your first attempt result.pdf was broken;
  • the intent (IT value) of the free text annotation in your source files is spelled incorrectly.

In detail:

Your result.pdf is broken. Different PDF viewers may display broken PDFs differently.

Some details:

It has been created based on your Src.pdf in append mode but additionally the following change in the original revision has been made to its /Pages object:

In the source:

6 0 obj
<</Count 6
/Type /Pages
/Kids [ 7 0 R 8 0 R 9 0 R 10 0 R 11 0 R 12 0 R ]
>>
endobj

In the result:

6 0 obj
<</Count 3
/Type /Pages
/Kids [ 7 0 R 8 0 R 9 0 R 12 0 R 11 0 R 10 0 R ]
>>
endobj

So the order of the last three pages was changed (which is ok) and the /Count was reduced from 6 to 3. This is inconsistent as there still are 6 child objects but according to the PDF specification ISO 32000-1, Count is

The number of leaf nodes (page objects) that are descendants of this node within the page tree.

Furthermore the cross reference stream of the appended revision is broken.

xref
0 1
0000000000 65535 f
24 1
0001465240 00000 n
57 1
0001466075 00000 n
66 1
0001466909 00000 n
73 1
0001467744 00000 n
93 1
0001473484 00000 n
131 1
0001478703 00000 n 

The entries are 19 bytes long including their respectively ending single byte newline character According to the spec, though,

Each entry shall be exactly 20 bytes long, including the end-of-line marker.

The format of an in-use entry shall be: nnnnnnnnnn ggggg n eol

where [...] eol shall be a 2-character end-of-line sequence

There may be more errors in the PDF but you may want to start fixing these.

EDIT

Now with the new PDF Pay-in.pdf with a proper cross reference at hand, let's look at it more in-depth.

Adobe Preflight complains about many occurances of:

[...]
An unexpected value is associated with the key
    Key: IT
    Value: /FreeTextTypewriter
    Type: CosName
    Formal Representation: Annot.AnnotFreeText
    Cos ID: 86
    Traversal Path: ->Pages->Kids->[0]->Annots->[13]
[...]

Ok, let's look at that object 86:

86 0 obj
<<  /P 8 0 R
    /Type /Annot
    /CreationDate (D:20130219194939+05'30')
    /T (winman)
    /NM (0f202782-2274-44b8-9081-af4010be86d4)
    /Subj (Typewritten Text)
    /M (D:20130219195100+05'30')
    /F 4
    /Rect [ 53.2308 33.488 552.088 826.019 ]
    /DS (font: Helv 12.0pt;font-stretch:Normal; text-align:left; color:#000000 )
    /AP <</N 107 0 R >>
    /Contents (wwww)
    /IT /FreeTextTypewriter
    /BS 108 0 R
    /Subtype /FreeText
    /Rotate 90
    /DA (16.25 TL /Cour 12 Tf)
    /RC (<?xml version="1.0"?>
         <body xmlns="http://www.w3.org/1999/xhtml"
               xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/"
               xfa:APIVersion="Acrobat:10.0.0"
               xfa:spec="2.0.2"
               style="font-size:12.0pt;text-align:left;color:#000000;font-weight:normal;
                      font-style:normal;font-family:Helv;font-stretch:normal">
           <p dir="ltr">
             <span style="line-height:16.3pt;font-family:Helvetica">wwww</span>
           </p>
         </body>)
>>
endobj 

Preflight stated that it is unhappy about the line /IT /FreeTextTypewriter. Looking at the PDF specification again uncovers for annotations with /Subtype /FreeText, i.e. Free Text Annotations specified in section 12.5.6.6:

IT name (Optional; PDF 1.6) A name describing the intent of the free text annotation (see also the IT entry in Table 170). The following values shall be valid:

FreeText The annotation is intended to function as a plain free-text annotation. A plain free-text annotation is also known as a text box comment.

FreeTextCallout The annotation is intended to function as a callout. The callout is associated with an area on the page through the callout line specified in CL.

FreeTextTypeWriter The annotation is intended to function as a click-to-type or typewriter object and no callout line is drawn.

Default value: FreeText

Thus, your value FreeTextTypewriter is invalid (remember, PDF names are case sensitive!). Therefore, the annotation is (slightly) broken which may already result in all kinds of problems.

But there are other important entries here, too, to understand your issue: All you do in your appended changes is to replace the appearance stream in object 107 (as per /AP <</N 107 0 R >>) of this annotation by a different one. But this annotation contains an RC value, too, which according to the specification is

A rich text string (see 12.7.3.4, “Rich Text Strings”) that shall be used to generate the appearance of the annotation.

Thus, any PDF viewer may regenerate the appearance from that rich text description, especially as the specification in section 12.5.2 says about the content of the AP dictionary

Individual annotation handlers may ignore this entry and provide their own appearances.

Thus, simply replacing the normal appearance stream does not suffice to permanently change the appearance of that annotation, you have to change the appearance dictionary and at least remove any alternative source for the appearance.

Furthermore the entry /Contents (wwww) is not replaced by your appended changes either. So a PDF viewer trying to decide whether to use the appearance stream or not will feel tempted to somehow create a new appearance as your appearance stream in no way represents that value.

Especially when starting to manipulate the free text (e.g. when clicking into the PDF in your case), the PDF viewer knows it eventually will have to create a new appearance anyways, and unless the current appearance is as it would have created it anyway, the viewer may prefer to begin anew starting with an appearance derived from the rich text or even the contents value.



来源:https://stackoverflow.com/questions/15083341/text-object-gets-deleted-in-adobe-reader-11

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!