Internet Architecture Board (IAB) T. Hansen, Ed.
Request for Comments: 7995 AT&T Laboratories
Category: Informational L. Masinter
ISSN: 2070-1721 M. Hardy
Adobe
December 2016
Internet Architecture Board (IAB) T. Hansen, Ed.
Request for Comments: 7995 AT&T Laboratories
Category: Informational L. Masinter
ISSN: 2070-1721 M. Hardy
Adobe
December 2016
PDF Format for RFCs
RFC的PDF格式
Abstract
摘要
This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF.
本文档讨论RFC系列中RFC PDF呈现的选项和要求，如RFC 6949所述。它还讨论了在互联网草稿中使用PDF，以及用于制作和使用PDF的可用或所需的软件工具。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7995.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7995.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Choosing PDF Versions and Standards .............................3
3. Options and Requirements for PDF RFCs ...........................4
3.1. "Visible" Requirements .....................................5
3.1.1. General Visible Requirements ........................5
3.1.2. Page Size and Margins ...............................5
3.1.3. Headers and Footers .................................5
3.1.4. Paragraph Numbering .................................6
3.1.5. Paged Content Layout ................................6
3.1.6. Typeface Choices ....................................7
3.1.7. Hyphenation and Line Breaks .........................8
3.1.8. Hyperlinks ..........................................8
3.1.9. Similarity to Other Outputs .........................9
3.2. "Invisible" Options and Requirements ......................10
3.2.1. Internal Text Representation .......................10
3.2.2. Unicode Support ....................................11
3.2.3. Image Processing (Artwork) .........................12
3.2.4. Text Description of Images (Alt-Text) ..............12
3.2.5. Metadata Support ...................................12
3.2.6. Document Structure Support .........................13
3.2.7. Embedded Files .....................................13
3.3. Digital Signatures ........................................14
4. Security Considerations ........................................15
5. References .....................................................16
5.1. Normative References ......................................16
5.2. Informative References ....................................17
Appendix A. History and Current Use of PDF with RFCs and
Internet-Drafts .......................................18
A.1. RFCs .......................................................18
A.2. Internet-Drafts ............................................18
Appendix B. Paged Content Layout Quality ..........................18
Appendix C. Tooling ...............................................19
C.1. PDF Viewers ................................................19
C.2. Printers ...................................................19
C.3. PDF Generation Libraries ...................................20
C.4. Typefaces ..................................................20
C.5. Other Tools ................................................20
IAB Members at the Time of Approval ...............................21
Acknowledgements ..................................................21
Authors' Addresses ................................................22
1. Introduction ....................................................3
2. Choosing PDF Versions and Standards .............................3
3. Options and Requirements for PDF RFCs ...........................4
3.1. "Visible" Requirements .....................................5
3.1.1. General Visible Requirements ........................5
3.1.2. Page Size and Margins ...............................5
3.1.3. Headers and Footers .................................5
3.1.4. Paragraph Numbering .................................6
3.1.5. Paged Content Layout ................................6
3.1.6. Typeface Choices ....................................7
3.1.7. Hyphenation and Line Breaks .........................8
3.1.8. Hyperlinks ..........................................8
3.1.9. Similarity to Other Outputs .........................9
3.2. "Invisible" Options and Requirements ......................10
3.2.1. Internal Text Representation .......................10
3.2.2. Unicode Support ....................................11
3.2.3. Image Processing (Artwork) .........................12
3.2.4. Text Description of Images (Alt-Text) ..............12
3.2.5. Metadata Support ...................................12
3.2.6. Document Structure Support .........................13
3.2.7. Embedded Files .....................................13
3.3. Digital Signatures ........................................14
4. Security Considerations ........................................15
5. References .....................................................16
5.1. Normative References ......................................16
5.2. Informative References ....................................17
Appendix A. History and Current Use of PDF with RFCs and
Internet-Drafts .......................................18
A.1. RFCs .......................................................18
A.2. Internet-Drafts ............................................18
Appendix B. Paged Content Layout Quality ..........................18
Appendix C. Tooling ...............................................19
C.1. PDF Viewers ................................................19
C.2. Printers ...................................................19
C.3. PDF Generation Libraries ...................................20
C.4. Typefaces ..................................................20
C.5. Other Tools ................................................20
IAB Members at the Time of Approval ...............................21
Acknowledgements ..................................................21
Authors' Addresses ................................................22
The RFC Series is evolving, as outlined in [RFC6949]. Future documents will use a canonical format, XML, with renderings in various formats, including PDF.
如[RFC6949]所述，RFC系列正在发展中。未来的文档将使用规范格式XML，并以各种格式呈现，包括PDF。
Because PDF has a wide range of capabilities and alternatives, not all PDFs are "equal". For example, visually similar documents could consist of scanned or rasterized images, or include text layout options, hyperlinks, embedded fonts, and digital signatures. (See [APP-PDF] for a history of PDF.)
由于PDF具有广泛的功能和备选方案，并非所有PDF都是“平等的”。例如，视觉上相似的文档可以由扫描或光栅化的图像组成，或者包括文本布局选项、超链接、嵌入字体和数字签名。（有关PDF的历史记录，请参见[APP-PDF]
This document explains some of the relevant options and makes recommendations, for both the RFC Series and Internet-Drafts.
本文件解释了RFC系列和互联网草案的一些相关选项并提出了建议。
The PDF format and the tools to manipulate it are not as well known as those for the other RFC formats, at least in the IETF community. This document discusses some of the processes for creating and using PDFs using both open source and commercial products.
PDF格式及其操作工具不像其他RFC格式那样广为人知，至少在IETF社区是这样。本文档讨论了使用开源和商业产品创建和使用PDF的一些过程。
The details described in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards-compatible with the details described in this document.
本文档中描述的详细信息预计将根据在实施新发布工具集过程中获得的经验进行更改。修订后的文档将在工具集完成后发布，以捕获这些更改。其他实施者不得期望这些更改与本文档中描述的细节保持向后兼容。
PDF [PDF] has gone through several revisions, primarily for the addition of features. PDF features have generally been added in a way that older viewers "fail gracefully", but even so, the older the PDF version produced, the more legacy viewers will support that version but the fewer features will be enabled.
PDF[PDF]经过了几次修订，主要是为了增加功能。PDF功能的添加方式通常会使较老的查看器“优雅地失败”，但即便如此，生成的PDF版本越老，支持该版本的传统查看器就越多，但启用的功能就越少。
As PDF has evolved a broad set of capabilities, additional standards for PDF files are applicable. These standards establish ground rules that are important for specific applications. For example, PDF/X was specifically designed for Prepress digital data exchange, with careful attention to color management and printing instructions. The PDF/E standard was designed for engineering documents with dynamic workflows (where a document continues to be revised after publication) and allows interactive media (including animation and 3D).
由于PDF已发展出一系列广泛的功能，因此适用于PDF文件的其他标准。这些标准确立了对特定应用非常重要的基本规则。例如，PDF/X是专门为印前数字数据交换而设计的，并对颜色管理和打印说明给予了仔细的关注。PDF/E标准是为具有动态工作流的工程文档（文档在发布后会继续修改）而设计的，并允许使用交互式媒体（包括动画和3D）。
Two additional standards families are important to the RFC format, though: long-term preservation (PDF/A), and user accessibility (PDF/UA [PDFUA]). These then have sub-profiles (PDF/A-1, PDF/A-2 [PDFA2], PDF/A-3 [PDFA3]), each of which has conformance levels. These standards are then supported by various software libraries and tools.
另外两个标准系列对RFC格式很重要：长期保存（PDF/A）和用户可访问性（PDF/UA[PDFUA]）。然后，这些子配置文件（PDF/A-1、PDF/A-2[PDFA2]和PDF/A-3[PDFA3]），每个子配置文件都具有一致性级别。这些标准随后得到各种软件库和工具的支持。
It is effective and useful to use these standards to capture PDF for RFC requirements, and they will make the PDF files useful in workflows that expect them.
使用这些标准捕获RFC需求的PDF是有效和有用的，它们将使PDF文件在期望它们的工作流中有用。
Recommendations:
建议：
o Use PDF 1.7; although relatively recent, it is well supported by widely available viewers.
o 使用PDF 1.7；虽然相对较新，但它得到了广泛观众的支持。
o For RFCs, require PDF/A-3 with conformance level "U". This captures the archivability and long-term stability of PDF 1.7 files, mandatory Unicode mapping (Sections 14.8.2.4.2 ("Unicode Mapping in Tagged PDF") and 9.10.2 ("Mapping Character Codes to Unicode Values") of [PDF]), and many of the requirement features.
o 对于RFC，要求PDF/A-3的一致性级别为“U”。这包括PDF 1.7文件的可归档性和长期稳定性、强制性Unicode映射（第14.8.2.4.2节（“标记PDF中的Unicode映射”）和[PDF]的第9.10.2节（“将字符代码映射到Unicode值”）以及许多需求功能。
o Use PDF/A-3 for embedding additional data (including the XML source file) in RFCs and Internet-Drafts.
o 使用PDF/A-3在RFC和Internet草稿中嵌入其他数据（包括XML源文件）。
o Use PDF/UA for user accessibility.
o 使用PDF/UA进行用户访问。
This section lays out options and requirements for PDFs produced by the RFC Editor for RFCs. There are two subsections: Section 3.1 covers "visible" requirements related to how the PDF normally appears when it is viewed with a PDF viewer; Section 3.2 covers "invisible" options and requirements, which primarily affect the ability to process PDFs in other ways but do not ordinarily control the way the document appears. (Of course, a viewer UI might display processing capabilities, such as showing whether a document has been digitally signed.)
本节列出了RFC编辑器为RFC生成的PDF的选项和要求。有两个小节：第3.1节涵盖了与PDF查看器查看PDF时通常显示方式相关的“可见”要求；第3.2节介绍了“不可见”选项和要求，这些选项和要求主要影响以其他方式处理PDF的能力，但通常不控制文档的显示方式。（当然，查看器UI可能会显示处理功能，例如显示文档是否经过数字签名。）
In many cases, the choice of PDF requirements is heavily influenced by the capabilities of available tools to create PDFs. Most of the discussion of tooling is to be found in Appendix C.
在许多情况下，PDF需求的选择受到创建PDF的可用工具功能的严重影响。关于工具的大部分讨论见附录C。
PDF supports rich visible layout of fixed-sized pages.
PDF支持固定大小页面的丰富可见布局。
For a consistent "look" of RFCs and good style, the PDFs produced by the RFC Editor should have a clear, consistent, identifiable, and easy-to-read style. They should print well on the widest range of printers and should look good on displays of varying resolution.
为了使RFC具有一致的“外观”和良好的风格，RFC编辑器生成的PDF应该具有清晰、一致、可识别和易于阅读的风格。它们应该能够在最广泛的打印机上很好地打印，并且在不同分辨率的显示器上看起来应该很好。
PDF files are laid out for a particular size of page and margins. There are two paper sizes in common use: "US Letter" (8.5x11 inches, 216x279 mm, in popular use in North America) and "A4" (210x297 mm, 8.27x11.7 inches, standard for the rest of the world). Usually, PDF printing software is used in a "shrink to fit" mode where the printing is adjusted to fit the paper in the printer. There is some controversy, but the argument that A4 is an international standard is compelling. However, if the margins and header positioning are chosen appropriately, the document can be printed without any scaling.
PDF文件按特定大小的页面和页边距进行布局。常用的纸张尺寸有两种：“美国字母”（8.5x11英寸，216x279毫米，在北美广泛使用）和“A4”（210x297毫米，8.27x11.7英寸，世界其他地区的标准尺寸）。通常，PDF打印软件是在“收缩到适合”模式下使用的，在这种模式下，可以调整打印以适合打印机中的纸张。虽然存在一些争议，但A4是一项国际标准的观点是令人信服的。但是，如果适当选择了边距和页眉位置，则可以打印文档而无需任何缩放。
Recommendation: The Internet-Draft and RFC processors should produce A4 size by default. However, the margins and header positioning need to be chosen to look good on both paper sizes without scaling. Following the advice found in [RFC2346], this means that we should use A4 portrait mode with left and right margins of 20 mm, and top and bottom margins of 33 mm.
建议：默认情况下，Internet草稿和RFC处理程序应生成A4大小。但是，需要选择页边距和页眉位置，以便在不缩放的情况下在两种纸张尺寸上都看起来不错。按照[RFC2346]中的建议，这意味着我们应该使用A4纵向模式，左右边距为20 mm，上下边距为33 mm。
Page headers and footers are part of the page layout. There are a variety of options. Note that page headers and footers in PDF can be typeset in a way that the entire (longer) title might fit.
页眉和页脚是页面布局的一部分。有多种选择。请注意，PDF中的页眉和页脚可以按照整个（较长的）标题进行排版。
Recommendation: Page headers and footers should contain information similar to the headings in the current text versions of documents, including page numbers, title, author, and date. However, the page headers and footers should be typeset in a way so as to be unobtrusive. The page headers and footers should be placed into the PDF in such a way that they do not interfere with screen readers.
建议：页眉和页脚应包含与文档当前文本版本中的标题类似的信息，包括页码、标题、作者和日期。但是，页眉和页脚的排版方式应不引人注目。页眉和页脚应以不干扰屏幕阅读器的方式放置在PDF中。
One common feature of the Internet-Draft output formats is optional visible paragraph numbers, to aid in discussions. In the PDF, and thus in the printed rendition, it is possible to make paragraph numbers unobtrusive and even to impinge on the margins.
互联网草稿输出格式的一个共同特点是可选的可见段落编号，以帮助讨论。在PDF中，因此在打印的格式副本中，可以使段落编号不引人注目，甚至影响页边空白。
Recommendation: When the XML "editing=yes" option has been chosen, show paragraph numbers in the right margin, typeset in a way so as to be unobtrusive. (The right margin instead of the left margin prevents the paragraph numbers from being confused with the section numbers.) If possible, the paragraph numbers should be coded in such a way that they do not interfere with screen readers.
建议：选择XML“editing=yes”选项后，在右边空白处显示段落编号，以不引人注目的方式排版。（右页边距而非左页边距可防止段落编号与章节编号混淆。）如果可能，段落编号的编码方式应确保不会干扰屏幕阅读器。
By its nature, PDF is paginated, so pagination issues must be considered. This is reflected in two areas: running headers and footers, and how text is laid out on a page for optimal reading.
就其性质而言，PDF是分页的，因此必须考虑分页问题。这体现在两个方面：运行页眉和页脚，以及如何在页面上布局文本以实现最佳阅读。
Appendix B describes the process of creating a paged document from running text such that related material is present on the same page together and artifacts of pagination don't interfere with easy reading of the document.
附录B描述了从运行的文本创建分页文档的过程，以便相关的材料一起出现在同一页面上，并且分页工件不会干扰文档的轻松阅读。
Layout engines differ in the quality of the algorithms used to automate these processes. In some cases, the automated processes require some manual assistance to ensure, for example, that a text line intended as a heading is "kept" with the text for which it is a heading.
布局引擎在用于自动化这些过程的算法的质量上有所不同。在某些情况下，自动化流程需要一些手动协助，以确保（例如）作为标题的文本行与作为标题的文本“保持”在一起。
Recommendations:
建议：
o Headers and footers should be printed on each page. The information should include the RFC number or Internet-Draft name, the page number, the category (e.g., Informational), a shortened version of the authors' names, the date of the RFC or Internet-Draft, and the short form of the document title.
o 页眉和页脚应打印在每页上。信息应包括RFC编号或互联网草稿名称、页码、类别（如信息性）、作者姓名的缩写、RFC或互联网草稿的日期以及文件标题的缩写形式。
o Choose a layout engine so that
o 选择一个布局引擎，以便
* manual intervention is minimized
* 尽量减少人工干预
* widow and orphan processing is automatic
* 寡妇和孤儿处理是自动的
* heading and title contiguation is automatic
* 标题和标题连续是自动的
A PDF may refer to a font by name, or it may use an embedded font. When a font is not embedded, a PDF viewer will attempt to locate a locally installed font of the same name. If it cannot find an exact match, it will find a "close match". If a close match is not available, it will fall back to something implementation dependent and usually undesirable.
PDF可以按名称引用字体，也可以使用嵌入式字体。未嵌入字体时，PDF查看器将尝试查找本地安装的同名字体。如果找不到精确匹配，它将找到“紧密匹配”。如果不存在紧密匹配，它将退回到依赖于实现的、通常不受欢迎的情况。
In addition, the PDF/A standards mandate the embedding of fonts. Instead of using additional software to embed the fonts, the software generating the PDF files should produce PDF/A-conforming files directly, thus ensuring that all glyphs include Unicode mappings and embedded fonts from the outset.
此外，PDF/A标准要求嵌入字体。生成PDF文件的软件应直接生成符合PDF/A的文件，从而确保所有字形从一开始就包括Unicode映射和嵌入字体，而不是使用其他软件嵌入字体。
If the HTML version of the document is being visually mimicked, the font(s) chosen should have both variable-width and constant-width components, as well as bold and italic representations.
如果在视觉上模拟文档的HTML版本，则所选字体应具有可变宽度和恒定宽度组件，以及粗体和斜体表示。
The typefaces used by Internet-Drafts and by RFCs need not be identical.
互联网草稿和RFC使用的字体不必相同。
Few fonts have glyphs for the entire repertoire of Unicode characters; for this purpose, the PDF generation tool may need a set of fonts and a way of choosing them. The RFC Editor is defining where Unicode characters may be used within RFCs [RFC7997].
很少有字体具有用于整个Unicode字符库的字形；为此，PDF生成工具可能需要一组字体和选择字体的方法。RFC编辑器正在定义在RFC[RFC7997]中可以使用Unicode字符的位置。
Typefaces are typically licensed, and in many cases there is a fee for use by PDF creation tools; however, there is usually no fee for display or print of the embedded fonts.
字体通常是经过许可的，在许多情况下，PDF创建工具的使用是收费的；然而，显示或打印嵌入字体通常是免费的。
Recommendations:
建议：
o For consistent viewing, all fonts should be embedded. The fonts used must be available for use by the IETF community. Some discussion of available typefaces can be found in Appendix C.4.
o 为了保持一致的查看，应嵌入所有字体。所使用的字体必须可供IETF社区使用。关于可用字体的一些讨论见附录C.4。
o The choice of typefaces with respect to serif, sans-serif, monospace, etc., should follow the recommendations for HTML and CSS renderings ("CSS" refers to a Cascading Style Sheet) [RFC7992] and [RFC7993].
o 关于衬线、无衬线、单空格等字体的选择应遵循HTML和CSS呈现的建议（“CSS”指级联样式表）[RFC7992]和[RFC7993]。
o The range of Unicode characters allowed in the XML source for Internet-Drafts and RFCs may be bounded by the availability of embeddable fonts with appropriate glyphs [RFC7997].
o 互联网草稿和RFC的XML源中允许的Unicode字符范围可能受到具有适当字形的可嵌入字体可用性的限制[RFC7997]。
Typically, when doing page layout of running text, especially with narrow page width and long words, layout processors of English text often have the option of either hyphenating words or using existing hyphens as a place to introduce word breaks. However, inserting line breaks mid-word can be harmful when the "word" is actually a sequence of characters representing a protocol element or protocol sequence.
通常，在对运行文本进行页面布局时，尤其是对于窄页面宽度和长单词，英文文本的布局处理器通常可以选择使用连字符或使用现有连字符作为引入分词的位置。然而，当“单词”实际上是表示协议元素或协议序列的字符序列时，在单词中间插入换行符可能是有害的。
Recommendation: Avoid introducing hyphenated line breaks mid-word into the visual display, consistent with requirements for plain text and HTML.
建议：避免在视觉显示中引入连字符换行符，这符合纯文本和HTML的要求。
PDF supports hyperlinks to sections of the same document and also to sections of other documents.
PDF支持指向同一文档各节以及其他文档各节的超链接。
The conversion to PDF can generate:
转换为PDF可以生成：
o hyperlinks within the document
o 文档中的超链接
o hyperlinks to other RFCs and Internet-Drafts
o 指向其他RFC和Internet草稿的超链接
o hyperlinks to external locations
o 指向外部位置的超链接
o hyperlinks within a table of contents
o 目录中的超链接
o hyperlinks within an index
o 索引中的超链接
Recommendations:
建议：
o All hyperlinks available in the HTML rendition of the RFC should also be visible and active in the PDF produced. This includes both internal hyperlinks and hyperlinks to external resources.
o RFC HTML格式副本中可用的所有超链接也应在生成的PDF中可见并处于活动状态。这包括内部超链接和指向外部资源的超链接。
o The table of contents, including page numbers, is useful when printed. Section numbers and page numbers in the table of contents should also be hyperlinked to their respective sections in the body of the document.
o 目录（包括页码）在打印时很有用。目录中的章节号和页码也应超链接到文件正文中各自的章节。
o As specified in Section 4.8.6.2 ("Referencing RFCs") of [RFC7322], hyperlinks to RFCs from the references section should point to the RFC "info" page (e.g., <https://www.rfc-editor.org/info/rfc7322>), which then links to the various formats available.
o 如[RFC7322]第4.8.6.2节（“参考RFC”）所述，参考部分的RFC超链接应指向RFC“信息”页面（例如<https://www.rfc-editor.org/info/rfc7322>)，然后链接到各种可用格式。
o Hyperlinks to Internet-Drafts from the references section should point to the Datatracker entry page for the draft, which then links to the various formats available.
o 从参考资料部分到Internet草稿的超链接应指向草稿的Datatracker条目页面，然后链接到各种可用格式。
There is some advantage to having the PDF files look like the text or HTML renderings of the same document. Even so, there are several options. The PDF
让PDF文件看起来像同一文档的文本或HTML呈现有一些好处。即便如此，也有几种选择。PDF
1. could look like the text version of the document, or
1. 可能看起来像文档的文本版本，或者
2. could look like the text version of the document but with pictures rendered as pictures instead of using their ASCII art equivalent, or
2. 可能看起来像文档的文本版本，但图片呈现为图片，而不是使用其ASCII艺术等效物，或
3. could look like the HTML version.
3. 可能看起来像HTML版本。
Recommendation: The PDF rendition should look like the HTML rendition, at least in spirit. Some differences from the HTML rendition would include different typeface and size (chosen for printing), page numbers in the table of contents and index, and the use of page headers and footers.
建议：PDF格式副本至少在精神上应该与HTML格式副本相似。与HTML格式副本的一些差异包括不同的字体和大小（选择打印）、目录和索引中的页码以及页眉和页脚的使用。
Most of the choices used for the renderings per [RFC7992] and [RFC7993] are thus applicable. See those documents for specifics on the rendering of the specific XML elements. Some notes:
因此，根据[RFC7992]和[RFC7993]用于渲染的大多数选项都适用。有关特定XML元素呈现的详细信息，请参见这些文档。一些注意事项：
o Every place in the document that would receive an HTML ID would be given an identical PDF named destination. In addition, a named destination will be created for each page with the form "pg-#", as in "pg-35".
o 文档中每个接收HTML ID的位置都将被赋予一个相同的名为destination的PDF。此外，将为每个页面创建一个命名目的地，格式为“pg-#”，如“pg-35”。
o No pilcrows are generated or made visible.
o 不会生成或使皮尔克罗可见。
o The table of contents (generated if the XML's <rfc> element's tocInclude attribute has the value "true") [RFC7991] will have the section number linked to the section start but will also include a page number that is linked to the corresponding page. The section title and the page number will be separated by a visually appropriate separator, and the page numbers will be aligned with each other.
o 目录（如果XML的<rfc>元素的tocclude属性具有值“true”时生成）[RFC7991]将具有链接到节开始的节号，但也将包括链接到相应页面的页码。章节标题和页码将用视觉上合适的分隔符分隔，页码将相互对齐。
o The index (generated if the XML's <rfc> element's indexInclude attribute has the value "true") will have the section number linked to that section named destination but will also include a page number that is linked to the page named destination.
o 索引（如果XML的<rfc>元素的indexInclude属性具有值“true”时生成）将具有链接到名为destination的节的节号，但也将包括链接到名为destination的页的页码。
o The running header in one line (on page 2 and all subsequent pages) has the RFC number on the left (RFC NNNN), the (possibly shortened form) title centered, and the date (Month Year) on the right. The text is rendered in a way that is visually unobtrusive.
o 一行（第2页和所有后续页面）中的运行标题左侧为RFC编号（RFC NNNN），中间为标题（可能缩写），右侧为日期（月-年）。文本以视觉上不引人注目的方式呈现。
o The running footer in one line (on all pages) has the author's last name on the left, category centered, and the page number on the right ([Page N]). The text is rendered in a way that is visually unobtrusive.
o 一行（在所有页面上）的运行页脚左边是作者的姓氏，以类别为中心，右边是页码（[第N页]）。文本以视觉上不引人注目的方式呈现。
o We should not attempt to replicate in PDF the feature of the HTML format that includes a dynamic block that displays up-to-date information on updates, obsoletions, and errata.
o 我们不应该试图在PDF中复制HTML格式的特性，该特性包括一个动态块，用于显示更新、淘汰和勘误表的最新信息。
PDF offers a number of features that improve the utility of PDF files in a variety of workflows, at the cost of extra effort in the xml2rfc conversion process; the trade-offs may be different for the RFC Editor production of RFCs and for Internet-Drafts.
PDF提供了许多功能，可以提高PDF文件在各种工作流中的实用性，而代价是在xml2rfc转换过程中付出额外的努力；对于RFC编辑器制作的RFC和互联网草稿，权衡可能不同。
The contents of a PDF file can be represented in many ways. The PDF file could be generated:
PDF文件的内容可以用多种方式表示。可以生成PDF文件：
o as an image of the visual representation, such as a JPEG image of the word "IETF". That is, there might be no internal representation of letters, words, or paragraphs at all.
o 作为视觉表示的图像，例如“IETF”一词的JPEG图像。也就是说，可能根本没有字母、单词或段落的内部表示。
o placing individual characters in position on the page, such as saying "put an 'F' here," then "put a 'T' before it," then "put an 'E' before that," then "put an 'I' before that" to render the word "IETF". That is, there might be no internal representation of words or paragraphs at all.
o 将单个字符放置在页面上的适当位置，例如说“在此处放置一个‘F’”，然后在其前面放置一个‘T’，“在其前面放置一个‘E’”，然后在其前面放置一个‘I’”，以呈现“IETF”一词。也就是说，可能根本没有单词或段落的内部表示。
o placing words in position on the page, such as keeping the characters of the word "IETF" together. That is, there might be no internal representation of paragraphs at all.
o 将单词放置在页面上的适当位置，例如将单词“IETF”的字符保持在一起。也就是说，段落可能根本没有内部表示。
o ensuring that the running order of text in the content stream matches the logical reading order. That is, a sentence such as "The Internet Engineering Task Force (IETF) supports the Internet." would be kept together as a sentence, and multiple sentences within a paragraph would be kept together.
o 确保内容流中文本的运行顺序与逻辑读取顺序匹配。也就是说，像“互联网工程任务组（IETF）支持互联网”这样的句子将作为一个句子放在一起，一个段落中的多个句子将放在一起。
All of these end up with essentially the same visual representation of the output. However, each level has trade-offs for auxiliary uses, such as searching or indexing, commenting and annotation, and accessibility (text-to-speech). Keeping the running order of text in the content stream in the proper order supports all of these auxiliary uses.
所有这些最终都以基本相同的输出视觉表示形式结束。但是，每个级别都有辅助用途的权衡，例如搜索或索引、注释和注释，以及可访问性（文本到语音）。保持内容流中文本的正确运行顺序支持所有这些辅助用途。
In addition, the "role map" feature of PDF (Section 14.7.3 ("Structure Types") of [PDF]) would allow for the mapping of the logical tags found in the original XML into tags in the PDF.
此外，PDF的“角色映射”功能（PDF的第14.7.3节（“结构类型”）允许将原始XML中的逻辑标记映射到PDF中的标记。
Recommendations:
建议：
o Text in content streams should follow the XML document's logical order (in the order of tags) to the extent possible. This will provide optimal reuse by software that does not understand Tagged PDF. (PDF/UA requires this.)
o 内容流中的文本应尽可能遵循XML文档的逻辑顺序（按照标记的顺序）。这将为不理解标记PDF的软件提供最佳重用。（PDF/UA需要这一点。）
o It might be possible to use the "role map" annotation to capture enough of the xml2rfc source structure, to the point where it is possible to reconstruct the XML source structure completely. However, there is not a compelling case to do so over embedding the original XML, as described in Section 3.2.7.
o 可以使用“角色映射”注释捕获足够多的xml2rfc源结构，从而完全重构XML源结构。但是，如第3.2.7节所述，在嵌入原始XML时没有令人信服的理由。
PDF itself does not require the use of Unicode. Text is represented as a sequence of glyphs that can then be mapped to Unicode.
PDF本身不需要使用Unicode。文本表示为一系列符号，然后可以映射到Unicode。
Recommendations:
建议：
o PDF files generated must have the full text, as it appears in the original XML.
o 生成的PDF文件必须具有原始XML中显示的全文。
o Unicode normalization may occur.
o 可能会发生Unicode规范化。
o Text within SVG for SVG images should also have Unicode mappings.
o SVG中用于SVG图像的文本也应该具有Unicode映射。
o Alt-text for images should also support Unicode.
o 图像的Alt文本也应支持Unicode。
The XML allows both ASCII art and SVG to be used for artwork.
XML允许ASCII art和SVG用于艺术品。
Recommendations:
建议：
o If both ASCII art and SVG are available for a picture, the SVG artwork should be preferred over the ASCII artwork.
o 如果ASCII艺术和SVG都可用于图片，则SVG艺术应优先于ASCII艺术。
o ASCII artwork must be rendered using a monospace font.
o ASCII艺术品必须使用单空格字体呈现。
Guidelines for the accessibility of PDF <http://www.w3.org/TR/WCAG20-TECHS/PDF1.html> recommend that images, formulas, and other non-text items provide textual alternatives, using the "/Alt" Tag in PDF to provide human-readable text that can be vocalized by text-to-speech technology.
PDF的可访问性指南<http://www.w3.org/TR/WCAG20-TECHS/PDF1.html>建议图像、公式和其他非文本项提供文本选项，使用PDF中的“/Alt”标记提供可通过文本到语音技术发声的人类可读文本。
Recommendation: Any alt-text for artwork and figures available in the XML source should be stored using the PDF /Alt property. Internet-Draft authors and the RFC Editor should ensure that alt-text for all SVG or images is included within the XML source.
建议：XML源中可用的任何艺术品和图形的alt文本都应使用PDF/alt属性存储。Internet草稿作者和RFC编辑器应确保XML源中包含所有SVG或图像的alt文本。
Metadata encodes information about the document authors, the document series, date created, etc. Having this metadata within the PDF file allows it to be used by search engines, viewers, and other reuse tools. PDF supports embedded metadata in a variety of ways, including using the Extensible Metadata Platform (XMP) [XMP]. The RFC Editor maintains metadata about an RFC on its info page.
元数据对有关文档作者、文档系列、创建日期等的信息进行编码。将此元数据包含在PDF文件中可供搜索引擎、查看器和其他重用工具使用。PDF以多种方式支持嵌入式元数据，包括使用可扩展元数据平台（Extensible metadata Platform，XMP）[XMP]。RFC编辑器在其信息页面上维护有关RFC的元数据。
Recommendation: The PDFs generated should have all of the metadata from the XML version embedded directly as XMP metadata, including the author, date, the document series, and a URL for where the document can be retrieved. This information should be consistent with the RFC Editor info page at the time of publication.
建议：生成的PDF应该将XML版本中的所有元数据作为XMP元数据直接嵌入，包括作者、日期、文档系列和可以检索文档的URL。此信息应与发布时的RFC编辑器信息页面一致。
PDF supports an "outline" feature where sections of the document are marked; this could be used in addition to the table of contents as a navigation aid.
PDF支持“大纲”功能，其中文档的各个部分都有标记；除目录外，还可将其用作导航辅助。
The section structure of an RFC can be mapped into the PDF elements for the document structure. This will allow the bookmark feature of PDF readers to be used to quickly access sections of the document.
RFC的节结构可以映射到文档结构的PDF元素中。这将允许使用PDF阅读器的书签功能快速访问文档的各个部分。
Recommendation: The section structure of an RFC should be mapped into the PDF elements for the document structure. This would include section headings for the boilerplate sections, such as the Abstract, the Status of This Memo section, the table of contents, and the Author's Address section, plus the obvious section headings that are normally included in the table of contents. If possible, this should be done in a way that the same fragment identifiers for the HTML version of the RFC will work for the PDF version.
建议：RFC的节结构应映射到文档结构的PDF元素中。这将包括样板章节的章节标题，如摘要、本备忘录章节的状态、目录和作者地址章节，以及通常包含在目录中的明显章节标题。如果可能的话，这样做的方式应该使RFC的HTML版本的相同片段标识符适用于PDF版本。
PDF has the capability of including other files; the files may be labeled by both a media type and a role, the AFRelationship key [PDFA3]. In this way, the PDF file also acts as a container.
PDF具有包含其他文件的能力；文件可以通过媒体类型和角色（AFRelationship key[PDFA3]）进行标记。这样，PDF文件也可以充当容器。
Embedded content may be compressed.
嵌入的内容可以被压缩。
Many PDF viewers support the ability to view and extract embedded files, although this capability is not universal.
许多PDF查看器支持查看和提取嵌入文件的功能，尽管这种功能不是通用的。
Embedding content in the PDF file allows the PDF to act as a complete package that can be transformed, archived, and digitally signed. (Some sample code illustrating how items can be attached to a PDF file and subsequently extracted can be found at <https://github.com/Aiybe/xmptest>.) Useful possibilities:
在PDF文件中嵌入内容可以使PDF成为一个完整的包，可以进行转换、存档和数字签名。（有关如何将项目附加到PDF文件并随后提取的示例代码，请访问<https://github.com/Aiybe/xmptest>）有用的可能性：
o Embed the source XML input file itself within the PDF. If the source SVG and images for illustrations are also embedded, this would make the PDF file totally self-referential.
o 将源XML输入文件本身嵌入到PDF中。如果还嵌入了用于插图的源SVG和图像，这将使PDF文件完全具有自参考性。
o Embed directly extractable components that are useful for independent processing, including ABNF, MIBs, and source code for reference implementations. This capability might be supported through other mechanisms from the XML source files but could also be supported within the PDF.
o 嵌入对独立处理有用的可直接提取组件，包括ABNF、MIB和参考实现的源代码。此功能可能通过XML源文件中的其他机制得到支持，但也可以在PDF中得到支持。
o Finding, extracting, and embedding other components may require additional markup to clearly identify them and additional review to ensure the correctness of embedded files that are not visible.
o 查找、提取和嵌入其他组件可能需要额外的标记以清楚地标识它们，并需要额外的检查以确保不可见的嵌入文件的正确性。
Recommendations:
建议：
o Embed the XML source and all illustrations, for RFCs, as a standard feature for xml2rfc's PDF output.
o 对于RFC，将XML源代码和所有插图嵌入为xml2rfc PDF输出的标准功能。
o If possible, make this a standard feature for Internet-Drafts as well.
o 如果可能的话，也将此作为Internet草稿的标准功能。
o Named <sourcecode> entries should be embedded.
o 应嵌入命名的<sourcecode>项。
o Bitmap images (SVG sources, JPEGs, PNGs, etc.) should be embedded.
o 应嵌入位图图像（SVG源、JPEG、PNG等）。
The RFC Editor and staff are at times called to provide evidence that a particular RFC is the "original" and has not been modified; digital signatures can provide that verification. As signatures also apply to embedded content, embedding the XML source will provide a way of signing the source XML that was used to produce the PDF file as well.
RFC编辑和工作人员有时被要求提供证据，证明特定RFC为“原始”且未被修改；数字签名可以提供这种验证。由于签名也适用于嵌入式内容，嵌入XML源将提供一种对用于生成PDF文件的源XML进行签名的方法。
PDF has supported digital signatures since PDF 1.2, and there are multiple methods and options available for signing PDF files. The method chosen for the signing of Internet-Drafts and RFCs will be determined by separate policy.
PDF从PDF 1.2开始就支持数字签名，并且有多种方法和选项可用于签署PDF文件。互联网草案和RFC的签署方式将由单独的政策决定。
If PDF digital signatures are chosen, the authors suggest the following:
如果选择PDF数字签名，作者建议如下：
o PDF documents generated by the Internet-Draft upload tools should be signed with no restrictions on what can be done to the documents afterwards.
o 由互联网草稿上传工具生成的PDF文档应在签名后对文档的处理没有任何限制。
o If Internet-Drafts are allowed to be uploaded in PDF form by an individual, the signature being added should be set in the same way as that noted in the previous paragraph. A PDF that would not allow the IETF Secretariat to re-sign it in that fashion should be rejected.
o 如果允许个人以PDF格式上传互联网草稿，则添加的签名应与上一段中所述的方式相同。不允许IETF秘书处以这种方式重新签署的PDF应被拒绝。
o PDF documents generated by the RFC Editor should be signed and certified, and restrictions placed on them to only allow additional signatures and comments (markup) to be added.
o RFC编辑器生成的PDF文档应经过签名和认证，并对其进行限制，仅允许添加额外的签名和注释（标记）。
The following security considerations apply:
以下安全注意事项适用：
Threats:
威胁：
o There is a risk that user-submitted Internet-Drafts in PDF might contain malware that targets a vulnerability in one of the deployed PDF consumers (readers, printers, validation tools, etc.) in use.
o 存在这样一种风险，即用户以PDF格式提交的Internet草稿可能包含恶意软件，该恶意软件的目标是使用中的某个已部署PDF使用者（阅读器、打印机、验证工具等）中的漏洞。
o There is a small risk that a PDF production toolset might itself have some vulnerability by which it could be tricked into producing malware-bearing PDF files.
o PDF生产工具集本身可能存在一些漏洞，从而被诱骗生成带有恶意软件的PDF文件，这种风险很小。
o Section 7 of [RFC3778] describes some additional security considerations for PDF, although this specification is intended to avoid features (like scripting) that might trigger some of those concerns.
o [RFC3778]的第7节描述了PDF的一些附加安全注意事项，尽管本规范旨在避免可能引发这些问题的功能（如脚本）。
Mitigations:
缓解措施：
o The toolsets for producing PDFs need careful security reviews before deploying broadly.
o 用于生成PDF的工具集在广泛部署之前需要仔细检查安全性。
o If users are allowed to submit Internet-Drafts in PDF, such PDF files should be examined carefully for conformance to this specification, as well as any known exploits of deployed PDF software.
o 如果允许用户以PDF格式提交互联网草稿，则应仔细检查此类PDF文件是否符合本规范，以及是否存在已部署PDF软件的已知漏洞。
[PDF] ISO, "Document management -- Portable document format -- Part 1: PDF 1.7", ISO 32000-1, 2008.
[PDF]ISO，“文件管理——可移植文件格式——第1部分：PDF 1.7”，ISO 32000-12008。
Also available free from Adobe.
也可从Adobe免费获得。
[XMP] ISO, "Graphic technology -- Extensible metadata platform (XMP) specification -- Part 1: Data model, serialization and core properties", ISO 16684-1, 2012.
[XMP]ISO，“图形技术——可扩展元数据平台（XMP）规范——第1部分：数据模型、序列化和核心属性”，ISO 16684-112012。
Not available free, but there are a number of descriptive resources, e.g., <http://en.wikipedia.org/wiki/ Extensible_Metadata_Platform>.
不是免费提供的，但有许多描述性资源，例如：<http://en.wikipedia.org/wiki/ 可扩展的元数据平台>。
[PDFA2] ISO, "Document management -- Electronic document file format for long-term preservation -- Part 2: Use of ISO 32000-1 (PDF/A-2)", ISO 19005-2, 2011.
[PDFA2]ISO，“文件管理——长期保存的电子文件格式——第2部分：ISO 32000-1（PDF/A-2）的使用”，ISO 19005-22011。
[PDFA3] ISO, "Document management -- Electronic document file format for long-term preservation -- Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", ISO 19005-3, 2012.
[PDFA3]ISO，“文件管理——长期保存的电子文件格式——第3部分：支持嵌入文件的ISO 32000-1的使用（PDF/A-3）”，ISO 19005-32012。
[PDFUA] ISO, "Document management applications -- Electronic document file format enhancement for accessibility -- Part 1: Use of ISO 32000-1 (PDF/UA-1)", ISO 14289-1, 2014.
[PDFUA]ISO，“文件管理应用程序——增强可访问性的电子文件格式——第1部分：ISO 32000-1（PDF/UA-1）的使用”，ISO 14289-12014。
[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, DOI 10.17487/RFC3778, May 2004, <http://www.rfc-editor.org/info/rfc3778>.
[RFC3778]Taft，E.，Pravetz，J.，Zilles，S.，和L.Masinter，“应用程序/pdf媒体类型”，RFC 3778，DOI 10.17487/RFC3778，2004年5月<http://www.rfc-editor.org/info/rfc3778>.
[RFC2346] Palme, J., "Making Postscript and PDF International", RFC 2346, DOI 10.17487/RFC2346, May 1998, <http://www.rfc-editor.org/info/rfc2346>.
[RFC2346]Palme，J.，“制作Postscript和PDF国际”，RFC 2346，DOI 10.17487/RFC2346，1998年5月<http://www.rfc-editor.org/info/rfc2346>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>.
[RFC6949]Flanagan，H.和N.Brownlee，“RFC系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013年5月<http://www.rfc-editor.org/info/rfc6949>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322]Flanagan，H.和S.Ginoza，“RFC风格指南”，RFC 7322，DOI 10.17487/RFC7322，2014年9月<http://www.rfc-editor.org/info/rfc7322>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991]Hoffman，P.“xml2rfc”版本3词汇表”，RFC 7991，DOI 10.17487/RFC7991，2016年12月<http://www.rfc-editor.org/info/rfc7991>.
[RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <http://www.rfc-editor.org/info/rfc7997>.
[RFC7997]Flanagan，H.，Ed.，“RFC中非ASCII字符的使用”，RFC 7997，DOI 10.17487/RFC7997，2016年12月<http://www.rfc-editor.org/info/rfc7997>.
[RFC7993] Flanagan, H., "Cascading Style Sheets (CSS) Requirements for RFCs", RFC 7993, DOI 10.17487/RFC7993, December 2016, <http://www.rfc-editor.org/info/rfc7993>.
[RFC7993]Flanagan，H.，“RFC的级联样式表（CSS）要求”，RFC 7993，DOI 10.17487/RFC7993，2016年12月<http://www.rfc-editor.org/info/rfc7993>.
[RFC7992] Hildebrand, J., Ed., and P. Hoffman, "HTML Format for RFCs", RFC 7992, DOI 10.17487/RFC7992, December 2016, <http://www.rfc-editor.org/info/rfc7992>.
[RFC7992]Hildebrand，J.，Ed.，和P.Hoffman，“RFC的HTML格式”，RFC 7992，DOI 10.17487/RFC7992，2016年12月<http://www.rfc-editor.org/info/rfc7992>.
[APP-PDF] Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M. Bailey, "The application/pdf Media Type", Work in Progress, draft-hardy-pdf-mime-04, September 2016.
[APP-PDF]Hardy，M.，Masinter，L.，Markovic，D.，Johnson，D.，和M.Bailey，“应用程序/PDF媒体类型”，正在进行的工作，草稿-Hardy-PDF-mime-042016年9月。
Appendix A. History and Current Use of PDF with RFCs and Internet-Drafts
附录A.PDF与RFC和互联网草稿的历史和当前使用
NOTE: This section is meant as an overview to give some background.
注：本节旨在概述一些背景知识。
The RFC Series has for a long time accepted Postscript renderings of RFCs, either in addition to or instead of the text renderings of those same RFCs. These have usually been produced when there was a complicated figure or mathematics within the document. For example, consider the figures and mathematics found in RFCs 1119 and 1142, and compare the figures found in the text version of RFC 3550 with those in the Postscript version. The RFC Editor has provided a PDF rendering of RFCs. Usually, this has been a print of the text file that does not take advantage of any of the broader PDF functionality, unless there was a Postscript version of the RFC, which would then be used by the RFC Editor to generate the PDF.
RFC系列长期以来一直接受RFC的Postscript渲染，除了这些RFC的文本渲染之外，也可以替代这些RFC的文本渲染。这些通常是在文件中有复杂的数字或数学时产生的。例如，考虑RFC 1119和1142中发现的数字和数学，并将RFC 3550的文本版本中的数据与PASScript版本中的数据进行比较。RFC编辑器提供了RFC的PDF呈现。通常，这是文本文件的打印，没有利用任何更广泛的PDF功能，除非有RFC的Postscript版本，RFC编辑器将使用该版本生成PDF。
In addition to PDFs generated and published by the RFC Editor, the IETF tools community has also long supported PDF for Internet-Drafts. Most RFCs start with Internet-Drafts, edited by individual authors. The Internet-Drafts submission tool at <https://datatracker.ietf.org/ submit/> accepts PDF and Postscript files in addition to the (required) text submission and (currently optional) XML. If a PDF wasn't submitted for a particular version of an Internet-Draft, the tools would generate one from the Postscript, HTML, or text.
除了RFC编辑器生成和发布的PDF之外，IETF工具社区还长期支持互联网草稿的PDF。大多数RFC从互联网草稿开始，由个人作者编辑。互联网草稿提交工具<https://datatracker.ietf.org/ submit/>除了（必需）文本提交和（当前可选）XML之外，还接受PDF和Postscript文件。如果没有为互联网草稿的特定版本提交PDF，这些工具将根据Postscript、HTML或文本生成一个PDF。
The process of creating a paged document from running text typically involves ensuring that related material is present on the same page together and that artifacts of pagination don't interfere with easy reading of the document. Typical high-quality layout processors do several things:
从运行的文本创建分页文档的过程通常涉及确保相关材料一起出现在同一页面上，并且分页工件不会干扰文档的轻松阅读。典型的高质量布局处理器执行以下几项操作：
Widow and Orphan Management: Widows and orphans (<https://en.wikipedia.org/wiki/Widows_and_orphans>) should be avoided automatically (unless the entire paragraph is only one line). Ensure that a page break does not occur after the first line of a paragraph (orphans), if necessary, using slightly longer page sizes. Similarly, ensure that a page break does not occur before the last line of a paragraph (widows).
寡妇和孤儿管理：寡妇和孤儿(<https://en.wikipedia.org/wiki/Widows_and_orphans>)应自动避免（除非整个段落只有一行）。如有必要，请使用稍长的页面大小，确保段落（孤立）的第一行之后不会出现分页符。同样，确保分页符不会出现在段落的最后一行（widows）之前。
Keep Section Heading Contiguous: Do not insert a page break immediately after a section heading. If there isn't room on a page for the first (two) lines of a section after the section heading, insert a page break before the heading.
保持节标题连续：不要在节标题后立即插入分页符。如果页面上没有空间容纳章节标题后的第一（两）行，请在标题前插入分页符。
Avoid Splitting Artwork: Figures should not be split from figure titles. If possible, keep the figure on the same page as the (first) mention of the figure.
避免拆分艺术品：图形不应从图形标题中拆分。如果可能的话，将图与（第一次）提到的图放在同一页上。
Headers for Long Tables after Page Breaks: Another common option in producing paginated documents is to include the column headings of a table if the table cannot be displayed on a single page. Similarly, tables should not be split from the table titles.
分页符后长表的标题：生成分页文档的另一个常见选项是，如果表不能在单个页面上显示，则包含表的列标题。同样，表格不应从表格标题中拆分。
keepWithNext and keepWithPrevious: The XML attributes "keepWithNext" and "keepWithPrevious" should be used and followed whenever possible.
keepWithNext和keepWithPrevious：应尽可能使用和遵循XML属性“keepWithNext”和“keepWithPrevious”。
Whitespace Preservation: The Unicode Points for XML entities such as Non-Breaking Space (nbsp) and Non-Breaking Hyphen (nbhy) should be followed as directed whenever possible.
保留空白：XML实体（如不间断空格（nbsp）和不间断连字符（nbhy））的Unicode点应尽可能按照指示执行。
This section discusses tools for viewing, comparing, creating, manipulating, and transforming PDF files, including those currently in use by the RFC Editor and Internet-Drafts, as well as outlining available PDF tools for various processes.
本节讨论用于查看、比较、创建、操作和转换PDF文件的工具，包括RFC编辑器和Internet草稿当前正在使用的工具，以及概述各种过程的可用PDF工具。
As with most file formats, PDF files are experienced through a reader or viewer of PDF files. For most of the common platforms in use (iOS, OS X, Windows, Android, ChromeOS, Kindle) and for most browsers (Edge, Safari, Chrome, Firefox), PDF viewing is built in. In addition there are many PDF viewers available for download and installation.
与大多数文件格式一样，PDF文件是通过PDF文件的读取器或查看器来体验的。对于大多数常用平台（iOS、OSX、Windows、Android、ChromeOS、Kindle）和大多数浏览器（Edge、Safari、Chrome、Firefox），内置了PDF查看功能。此外，还有许多PDF查看器可供下载和安装。
PDF viewers vary in capabilities, and it is important to note which PDF viewers support the features utilized in PDF RFCs and Internet-Drafts (features such as links, digital signatures, Tagged PDF, and others mentioned in Section 3).
PDF查看器的功能各不相同，请务必注意哪些PDF查看器支持PDF RFC和Internet草稿中使用的功能（如链接、数字签名、带标签的PDF以及第3节中提到的其他功能）。
While almost all viewers also support the printing of PDF files, printing is one of the most important use cases for PDFs. Some printers have direct PDF support.
虽然几乎所有查看器都支持打印PDF文件，但打印是PDF最重要的用例之一。有些打印机直接支持PDF格式。
Because the xml2rfc format is a unique format, software for converting XML source documents to the various formats will be needed, including PDF generation.
由于xml2rfc格式是一种独特的格式，因此需要将XML源文档转换为各种格式的软件，包括生成PDF。
One promising direction is suggested in <http://greenbytes.de/tech/webdav/rfc2629xslt/ rfc2629xslt.html#output.pdf.fop>: using XSLT (Extensible Stylesheet Language Transformations) to generate XSL-FO (XSL Formatting Objects); XSL-FO is then processed by a FOP (Formatting Objects Processor) such as Apache FOP.
本文提出了一个有希望的方向<http://greenbytes.de/tech/webdav/rfc2629xslt/ rfc2629xslt.html#output.pdf.fop>：使用XSLT（可扩展样式表语言转换）生成XSL-FO（XSL格式对象）；XSL-FO然后由诸如ApacheFop之类的FOP（格式化对象处理器）处理。
Several libraries are also available for generating PDF signatures. The choice of library to use for xml2pdf will depend on many factors: programming language, quality of implementation, quality of PDF generated, support, cost, availability, and so forth.
还有几个库可用于生成PDF签名。xml2pdf使用的库的选择将取决于许多因素：编程语言、实现质量、生成的PDF质量、支持、成本、可用性等等。
Various typefaces are available that might satisfy the requirements of this document. Google's Noto typeface family <https://www.google.com/get/noto/> supports a significant subset of Unicode and includes fixed-width, serif, and sans-serif styles. Another potentially useful set of typefaces (without extensive Unicode support, however) includes:
可以使用各种字体来满足本文件的要求。谷歌的Noto字体家族<https://www.google.com/get/noto/>支持Unicode的重要子集，包括固定宽度、衬线和无衬线样式。另一组可能有用的字体（但不支持广泛的Unicode）包括：
o Source Sans Pro <https://en.wikipedia.org/wiki/Source_Sans_Pro>
o 源Sans-Pro<https://en.wikipedia.org/wiki/Source_Sans_Pro>
o Source Serif Pro <https://en.wikipedia.org/wiki/Source_Serif_Pro>
o 源衬线专业版<https://en.wikipedia.org/wiki/Source_Serif_Pro>
o Source Code Pro <https://en.wikipedia.org/wiki/Source_Code_Pro>
o 源代码专业版<https://en.wikipedia.org/wiki/Source_Code_Pro>
Another font that looks promising for its broad Unicode support is Skolar <https://www.rosettatype.com/Skolar>, but it requires licensing.
另一种有望广泛支持Unicode的字体是Skolar<https://www.rosettatype.com/Skolar>，但它需要许可证。
In addition to generating and viewing PDF, other categories of PDF tools are available and may be useful both during specification development and for published RFCs. These include tools for comparing two PDFs, checkers that could be used to validate the results of conversion, reviewing and commentary tools that attach annotations to PDF files, and digital signature creation and validation.
除了生成和查看PDF外，还提供了其他类别的PDF工具，这些工具可能在规范开发期间和已发布的RFC中都很有用。这些工具包括用于比较两个PDF的工具、可用于验证转换结果的检查工具、将注释附加到PDF文件的审阅和注释工具，以及数字签名创建和验证。
Validation of an arbitrary author-generated PDF file would be quite difficult; there are few PDF validation tools. However, if RFCs and Internet-Drafts are generated by conversion from XML via xml2rfc, then explicit validation of PDF and adherence to expected profiles would mainly be useful to ensure that xml2rfc has functioned properly.
验证任意作者生成的PDF文件将非常困难；PDF验证工具很少。但是，如果RFC和Internet草稿是通过xml2rfc从XML转换生成的，则PDF的显式验证和对预期概要文件的遵守对于确保xml2rfc正常运行非常有用。
Recommendation: Discourage (but allow) submission of a PDF representation for Internet-Drafts. In most cases, the PDF for an Internet-Draft should be produced automatically when XML is submitted, with an opportunity to verify the conversion.
建议：不鼓励（但允许）提交互联网草稿的PDF格式。在大多数情况下，互联网草稿的PDF应该在提交XML时自动生成，并有机会验证转换。
IAB Members at the Time of Approval
批准时的IAB成员
The IAB members at the time this memo was approved were (in alphabetical order):
本备忘录批准时，IAB成员为（按字母顺序排列）：
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
The input of the following people is gratefully acknowledged: Nevil Brownlee (ISE), Brian Carpenter, Chris Dearlove, Martin Duerst, Heather Flanagan (RSE), Joe Hildebrand, Paul Hoffman, Duff Johnson, Ted Lemon, Sean Leonard, Henrik Levkowetz, Julian Reschke, Adam Roach, Leonard Rosenthol, Alice Russo, Robert Sparks, Andrew Sullivan, and Dave Thaler.
感谢以下人士的意见：内维尔·布朗利（ISE）、布赖恩·卡彭特、克里斯·迪尔洛夫、马丁·杜尔斯、希瑟·弗拉纳根（RSE）、乔·希尔德布兰德、保罗·霍夫曼、达夫·约翰逊、特德·莱蒙、肖恩·伦纳德、亨里克·列夫科维茨、朱利安·雷什克、亚当·罗奇、伦纳德·罗森索尔、爱丽丝·鲁索、罗伯特·斯帕克斯、安德鲁·沙利文、，还有戴夫·泰勒。
Authors' Addresses
作者地址
Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 United States of America
Tony Hansen（编辑）美国电话电报公司实验室美国新泽西州南米德尔顿劳雷尔大道200号，邮编07748
Email: tony@att.com
Email: tony@att.com
Larry Masinter Adobe 345 Park Ave. San Jose, CA 95110 United States of America
美国加利福尼亚州圣何塞公园大道345号，邮编95110
Email: masinter@adobe.com
URI: http://larrymasinter.net
Email: masinter@adobe.com
URI: http://larrymasinter.net
Matthew Hardy Adobe 345 Park Ave. San Jose, CA 95110 United States of America
Matthew Hardy Adobe美国加利福尼亚州圣何塞公园大道345号，邮编95110
Email: mahardy@adobe.com
Email: mahardy@adobe.com