文本对象在Adobe Reader 11中被删除 [英] Text object gets deleted in Adobe Reader 11
问题描述
在adobe acrobat x中，我正在插入文本对象，并且在Adobe Reader 10中打开它时，它可以正常打开。但是在Adobe Reader 11中，当我单击该pdf文件时，文本对象被删除了。为什么会这样？怎么解决呢？
原始pdf文件单击此处
在Adobe Reader 11中双击时有问题的pdf文件。
单击这里
简而言之：
您尝试通过更改自由文本注释的正常外观流来更改其内容。
这是不够的：兼容的PDF查看器可能会忽略该条目并提供自己的外观。因此，较早的Adobe Reader版本选择不要忽略只是运气 。
因此，您还需要更改期望PDF查看器创建其自身外观的信息，即最重要的 RC 文本（在自由文本注释词典中），用于生成外观 和 Contents 值，即应为注释显示的文本。
此外，您的PDF中还有缺陷：
- 首次尝试结果中的交叉引用表。pdf已损坏；
- 源文件中自由文本注释的意图（ IT 值）拼写错误。
详细信息：
您的 result.pdf 已损坏。不同的PDF查看器可能会以不同的方式显示损坏的PDF。
一些详细信息：
它是根据您的<追加模式下的href = http://incometaxsoft.com/pdf/Src.pdf rel = nofollow> Src.pdf ，此外，/ Pages对其原始版本进行了以下更改对象：
源中：
6 0 obj
< /计数6
/类型/页面
/孩子[7 0 R 8 0 R 9 0 R 10 0 R 11 0 R 12 0 R]
>> ;
endobj
结果：
6 0 obj
<< /计数3
/ Type / Pages
/ Kids [7 0 R 8 0 R 9 0 R 12 0 R 11 0 R 10 0 R]
>
endobj
所以最后三页的顺序已更改（可以），并且 /计数从6减少到3。这是不一致的，因为仍然有6个子对象，但根据 PDF规范ISO 32000-1 ，计数是
页面树中该节点的后代叶子节点（页面对象）的数量。
此外，附加修订的交叉引用流也已中断。
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
条目的长度为19个字节i根据规范，
每个条目的长度应正好为20个字节，包括行尾标记。
正在使用的条目的格式应为：nnnnnnnnnn ggggg n eol
其中[...] eol应该是2个字符的行尾序列
PDF中可能会有更多错误，但您可能要开始修复这些。
编辑
现在有了新的PDF Pay-in.pdf ，上面有适当的交叉引用，让我们对其进行更深入的研究。
Adobe Preflight抱怨以下情况的多次发生：
[...]
键
的键关联了意外的值： IT
值：/ FreeTextTypewriter
类型：CosName
形式表示形式：Annot.AnnotFreeText
Cos ID：86
遍历路径：-> Pages-> Kids- > [0]-> Annots-> [13]
[...]
好，让我们看一下对象86：
86 0 obj
<< / P 8 0 R
/类型/ Annot
/ CreationDate（D：20130219194939 + 05'30'）
/ T（winman）
/ NM（0f202782-2274-44b8 -9081-af4010be86d4）
/ Subj（打字文本）
/ 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>>
/内容（www）
/ IT / FreeTextTypewriter
/ BS 108 0 R
/子类型/ FreeText
/旋转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表示对此行 /不满意IT / FreeTextTypewriter 。再次发现 PDF规范用于带有 / Subtype / FreeText 的注释，即在12.5.6.6节中指定的自由文本注释：
IT 名称
（可选； PDF 1.6）用于描述自由文本注释意图的名称（另请参见表170中的IT条目） 。以下值应有效：
FreeText 该注释旨在用作纯自由文本注释。普通的自由文本注释也称为文本框注释。
FreeTextCallout 该注释旨在用作标注。标注通过CL中指定的标注行与页面上的区域相关联。
FreeTextTypeWriter 注解旨在用作单击。 -to-type或打字机对象，没有绘制标注线。
默认值： FreeText
因此，您的值 FreeTextTypewriter 无效（请记住，PDF名称区分大小写！）。因此，注释被（轻微）破坏了，可能已经导致了各种各样的问题。
但是这里也有其他重要的条目可以理解您的问题：全部您所做的附加更改是替换此注释的对象107中的外观流（按照 / AP<< / N 107 0 R>> ）由另一种。但是此注释也包含一个 RC 值，根据规范是
富文本字符串（请参见12.7.3.4，富文本字符串），将其用于生成注释的外观。
因此，任何PDF查看器都可以从中重新生成外观富文本描述，尤其是如12.5.2节中的说明所述 AP 词典的内容
各个注释处理程序可能会忽略此条目并提供自己的外观。
因此，仅替换常规的外观流不足以永久更改注释的外观，您必须更改外观字典并至少删除外观的任何其他来源。 / p>
此外，条目 / Contents（wwww）也不会被您附加的更改所取代。因此，尝试确定是否使用外观流的PDF查看器将很想以某种方式创建新外观，因为您的外观流绝不代表该值。
特别是当开始处理自由文本时（例如，在您的情况下单击PDF时），PDF查看器知道它最终将仍然必须创建一个新外观，并且除非当前外观与它原本会创建的一样，否则，观看者可能更喜欢从富文本甚至内容值衍生的外观开始重新开始。
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
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.
这篇关于文本对象在Adobe Reader 11中被删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
