This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
design:text-requirements [2013/09/26 07:44] rsewikiadmin |
design:text-requirements [2013/10/15 19:52] (current) paul |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== Requirements for Text Output ==== | + | ==== Requirements for Text Output ==== |
- | Policy requirements: | + | The following assumes that the text-only non-canonical format intended consumer |
- | * an RFC may include ASCII art OR SVG, but not both | + | |
- | * Paul asks: Why? The term "ASCII art" is under-specified. The IETF community does not agree what is and is not "ASCII art". For instance, in RFC 5996, Figure 1 is clearly " | + | |
- | * HF: Taking this back to the list for discussion. | + | |
- | * the .txt publication output | + | |
- | * we could potentially include direct links to the HTML anchors, but Heather is concerned about future failure | + | |
- | * Paul says he is not at all concerned as long as the URLs are structured to be long-lived. He thinks that having direct links makes much more sense for someone who is going to process the text format using tools. | + | |
- | * HF: Taking this back to the list for discussion | + | |
- | * non-ASCII characters in the Author' | + | |
- | * Wasn't this supposed to be "with exceptions allowed by the RSE"? | + | |
- | * HF: What I've been telling the community is that we would start small, with just author names, | + | |
- | Technical requirements: | + | The text-only format must have the same page height limitations as the current RFC format. |
- | The paginated .txt publication | + | The text-only |
- | * maintain a similar look and feel to existing text output. | + | |
+ | The text-only format must represent all SVG-based artwork as a "see reference" | ||
- | ----- | + | The RFC Editor must list all of the changes |
- | For reference: | + | |
- | Current requirements re: page breaking for xml2rfc v2 | + | |
- | + | ||
- | #172: page-breaking enhancements | + | |
- | Improve | + | |
- | - the middle of a figure (see Figure 1 in the attached file) | + | |
- | - in the middle of a reference (see Section 10.2 in the attached file) | + | |
- | - between a section title and the first sentence (see Section 5 in the attached file). This is the same as #72, which is marked fixed, but doesn' | + | |
- | If there is an Appendix A, insert a page break before it. (This could be tied to rfcedstyle=" | + | |
- | doesn' | + | |
- | + | ||
- | Ticket URL: < | + | |
- | + | ||
- | + | ||
- | Current internal guidance to the RPC: | + | |
- | + | ||
- | "3+ lines held together" | + | |
- | Keep a section title with the first 3 lines of the section. | + | |
- | Keep a figure on one page. This includes its title (if any). | + | |
- | - if figure does not fit on one page, break between discrete items in the figure. | + | |
- | Keep a table on one page. This includes its title (if any). | + | |
- | - if table does not fit on one page, break between rows. | + | |
- | Keep a term with its definition. | + | |
- | - if definition is long (over 5 lines), keep at least the first 3 lines of the definition with the term. | + | |
- | Keep a given reference on one page. | + | |
- | Start Appendix A on a new page. | + | |
- | + | ||
- | More subjective: | + | |
- | Keep intro text with what it's introducing. (Example: text that introduces a list, an equation, or a piece of pseudocode) | + | |
- | Break pseudocode nicely. | + | |
+ | After the RFC Editor has made the cut-over to the new canonical format (and thus the new non-canonical text-only format), all RFCs with a higher number must be in the new format. |