[要約] RFC 7995は、RFC文書をPDF形式で提供するための仕様です。目的は、RFC文書の可読性と整合性を向上させ、広範な利用者にとっての利便性を高めることです。
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 6949で概説されているように、RFCシリーズでのRFCのPDFレンダリングのオプションと要件について説明します。また、インターネットドラフトでのPDFの使用、およびPDFの作成と操作に使用できるまたは必要なソフトウェアツールについても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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シリーズは進化しています。将来のドキュメントでは、PDFを含むさまざまな形式でレンダリングされた標準形式のXMLを使用します。
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形式とそれを操作するツールは、少なくともIETFコミュニティでは、他のRFC形式のものほどよく知られていません。このドキュメントでは、オープンソース製品と商用製品の両方を使用して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は、Prepressのデジタルデータ交換用に特別に設計されており、カラー管理と印刷手順に細心の注意を払っています。 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形式では2つの追加の標準ファミリが重要です。長期保存（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の場合、準拠レベル「U」のPDF / A-3が必要です。これは、PDF 1.7ファイルのアーカイブ性と長期安定性、必須のUnicodeマッピング（セクション14.8.2.4.2（「タグ付きPDFでのUnicodeマッピング」）および[PDFの文字コードのUnicode値へのマッピング」）をキャプチャします。 ]）、および要件機能の多く。
o Use PDF/A-3 for embedding additional data (including the XML source file) in RFCs and Internet-Drafts.
o RFC /インターネットドラフトに追加データ（XMLソースファイルを含む）を埋め込むには、PDF / A-3を使用します。
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のオプションと要件を示します。 2つのサブセクションがあります。セクション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ファイルは、特定のサイズのページと余白に合わせてレイアウトされます。一般的に使用される用紙サイズには、「USレター」（8.5x11インチ、216x279 mm、北米で一般的に使用されている）と「A4」（210x297 mm、8.27x11.7インチ、その他の国の標準）の2つがあります。 。通常、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-Draftおよび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.
Internet-Draftの出力形式の一般的な機能の1つは、議論を助けるためのオプションの表示可能な段落番号です。 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はその性質上、ページ分割されているため、ページ分割の問題を考慮する必要があります。これは、ヘッダーとフッターの実行、および最適な読み取りのためにテキストがページにどのように配置されるかという2つの領域に反映されています。
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.
Internet-Draftsと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 Editorは、RFC内でUnicode文字を使用できる場所を定義しています[RFC7997]。
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 Internet-DraftsおよびRFCsの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およびインターネットドラフトへのハイパーリンク
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（ "Referencing RFCs"）で指定されているように、参照セクションからのRFCへのハイパーリンクは、RFC "info"ページ（たとえば、<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 参照セクションからインターネットドラフトへのハイパーリンクは、ドラフトのデータトラッカーエントリページを指している必要があります。このページは、利用可能なさまざまな形式にリンクしています。
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-35」のように、「pg-＃」の形式で各ページに名前付き宛先が作成されます。
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>要素のtocInclude属性の値が「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 1行の実行ヘッダー（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 （すべてのページの）1行で実行されているフッターは、左側に著者の姓、中央にカテゴリ、右側にページ番号（[ページ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 更新、廃止、エラッタに関する最新情報を表示する動的ブロックを含むHTML形式の機能をPDFで複製しようとするべきではありません。
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は、xml2rfc変換プロセスでの余分な労力を犠牲にして、さまざまなワークフローでPDFファイルのユーティリティを改善する多数の機能を提供します。 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 画像の代替テキストもUnicodeをサポートする必要があります。
The XML allows both ASCII art and SVG to be used for artwork.
XMLでは、アートワークにASCIIアートと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の両方を使用できる場合は、ASCIIアートワークよりもSVGアートワークを優先する必要があります。
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>は、画像、数式、およびその他の非テキストアイテムが、「/ Alt」タグを使用してテキストによる代替を提供することを推奨していますPDFで、音声読み上げテクノロジーによって発声できる人間が読めるテキストを提供します。
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ソースで使用可能なアートワークおよび図の代替テキストは、PDF / Altプロパティを使用して保存する必要があります。 Internet-Draftの作成者とRFC Editorは、すべてのSVGまたは画像の代替テキストがXMLソース内に含まれていることを確認する必要があります。
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には、作成者、日付、ドキュメントシリーズ、ドキュメントを取得できるURLを含む、XMPメタデータとして直接埋め込まれたXMLバージョンのすべてのメタデータが必要です。この情報は、公開時の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要素にマップする必要があります。これには、Abstract、Status of This Memoセクション、目次、Author's Addressセクションなどのボイラープレートセクションのセクション見出しと、通常目次に含まれる明白なセクション見出しが含まれます。可能であれば、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キー[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 可能であれば、これをインターネットドラフトの標準機能にもしてください。
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 Internet-Draftアップロードツールによって生成された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 Editorによって生成された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のインターネットドラフトには、使用中の展開された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-1、2008。
Also available free from 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-1、2012。
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/Extensible_Metadata_Platform>など、多くの説明リソースがあります。
[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-2、2011。
[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-3、2012 。
[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-1、2014。
[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、「The application / pdf Media Type」、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。、「Making Postscript and PDF International」、RFC 2346、DOI 10.17487 / RFC2346、May 1998、<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。、「The "xml2rfc" Version 3 Vocabulary」、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。、「The Use of Non-ASCII Characters in RFCs」、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、「application / pdf Media Type」、Work in Progress、draft-hardy-pdf-mime 2016年9月4日。
Appendix A. History and Current Use of PDF with RFCs and Internet-Drafts
付録A. RFCとインターネットドラフトでのPDFの歴史と現在の使用
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のテキストレンダリングに加えて、またはその代わりに、RFCのPostscriptレンダリングを長い間受け入れてきました。これらは通常、文書内に複雑な図や数学があったときに作成されました。たとえば、RFC 1119および1142にある図と数学を検討し、RFC 3550のテキストバージョンにある図とPostscriptバージョンの図を比較します。 RFCエディターは、RFCのPDFレンダリングを提供しています。通常、これは、RFCのPostscriptバージョンがあり、RFCエディターがPDFを生成するために使用する場合を除いて、広範な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 Editorによって生成および発行されたPDFに加えて、IETFツールコミュニティは、インターネットドラフト用のPDFも長い間サポートしています。ほとんどのRFCは、個々の作成者が編集したInternet-Draftsで始まります。 <https://datatracker.ietf.org/submit/>のInternet-Drafts送信ツールは、（必須の）テキスト送信と（現在はオプションの）XMLに加えて、PDFファイルとPostscriptファイルを受け入れます。 PDFがInternet-Draftの特定のバージョンに対して送信されなかった場合、ツールは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>）は自動的に回避する必要があります（段落全体が1行だけの場合を除く）。必要に応じて、少し長いページサイズを使用して、段落（孤立）の最初の行の後に改ページが発生しないようにします。同様に、段落の最後の行（未亡人）の前で改ページが発生しないことを確認してください。
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.
セクション見出しを連続させる：セクション見出しの直後に改ページを挿入しないでください。セクション見出しの後のセクションの最初の（2）行のページにスペースがない場合は、見出しの前に改ページを挿入します。
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.
改ページ後の長いテーブルのヘッダー：ページ付けされたドキュメントを作成する際のもう1つの一般的なオプションは、テーブルを単一のページに表示できない場合にテーブルの列見出しを含めることです。同様に、テーブルをテーブルタイトルから分割しないでください。
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.
空白の保持：途切れのないスペース（nbsp）や途切れのないハイフン（nbhy）などのXMLエンティティの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.
このセクションでは、現在RFC EditorとInternet-Draftsで使用されているものを含むPDFファイルを表示、比較、作成、操作、および変換するためのツールと、さまざまなプロセスで使用可能な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、OS X、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およびインターネットドラフトで使用される機能（リンク、デジタル署名、タグ付き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の最も重要な使用例の1つです。一部のプリンターは直接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形式は独自の形式であるため、PDFの生成を含め、XMLソースドキュメントをさまざまな形式に変換するためのソフトウェアが必要になります。
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（Extensible Stylesheet Language Transformations）を使用してXSL-FO（XSL Formatting Objects）を生成することで、有望な方向性が1つ提案されます; XSL-FOは、Apache FOPなどのFOP（Formatting Objects Processor）によって処理されます。
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:
このドキュメントの要件を満たすさまざまな書体が利用可能です。 GoogleのNoto書体ファミリ<https://www.google.com/get/noto/>は、Unicodeの重要なサブセットをサポートし、固定幅、セリフ、およびサンセリフのスタイルを含みます。別の潜在的に有用な書体のセット（ただし、広範なUnicodeサポートなし）には以下が含まれます。
o Source Sans Pro <https://en.wikipedia.org/wiki/Source_Sans_Pro>
o Source Sans Pro <https://en.wikipedia.org/wiki/Source_Sans_Pro>
o Source Serif Pro <https://en.wikipedia.org/wiki/Source_Serif_Pro>
o Source Serif Pro <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の幅広いサポートが期待できるもう1つのフォントは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の両方で役立つ場合があります。これらには、2つの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およびインターネットドラフトが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）、ジョーヒルデブランド、ポールホフマン、ダフジョンソン、テッドレモン、ショーンレナード、ヘンリックレフコウェッツ、ジュリアンReschke、Adam Roach、Leonard Rosenthol、Alice Russo、Robert Sparks、Andrew Sullivan、Dave Thaler。
Authors' Addresses
著者のアドレス
Tony Hansen (editor) AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 United States of America
Tony Hansen（編集者）AT＆T Laboratories 200 Laurel Ave. South Middletown、NJ 07748アメリカ合衆国
Email: tony@att.com
Larry Masinter Adobe 345 Park Ave. San Jose, CA 95110 United States of America
Larry Masinter Adobe 345 Park Ave. San Jose、CA 95110アメリカ合衆国
Email: masinter@adobe.com
URI: http://larrymasinter.net
Matthew Hardy Adobe 345 Park Ave. San Jose, CA 95110 United States of America
マシューハーディアドビ345 Park Ave. San Jose、CA 95110アメリカ合衆国
Email: mahardy@adobe.com