This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
design:text-requirements [2013/09/04 13:04] paul Put the policy requirements first (suggested by Joe) |
design:text-requirements [2013/10/09 13:57] paul Added Paul comments |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== Requirements for Text Output ==== | + | ==== Requirements for Text Output ==== |
- | Policy requirements: | + | The following assumes that there is going to be only one text-only non-canonical format, that its intended consumer is people who like the current format but want to be able to get all the semantic content out of the new canonical format, and that the HTML format will be done in a way where copy-and-paste of text will be easy and predictable. |
- | * an RFC may include ASCII art OR SVG, but not both | + | |
- | * the .txt publication output will include links to the info pages where there are images | + | |
- | * we could potentially include direct links to the HTML anchors, but am concerned about future failure | + | |
- | * non-ASCII characters | + | |
- | Technical requirements: | + | The text-only |
- | The .txt publication | + | |
- | * use classic/ | + | |
- | * have paginated output | + | |
- | * use classic/ | + | |
- | * support UTF-8 encoding | + | |
- | * max of 80 character | + | |
+ | The text-only format must allow for preformatted text and art to be 80 characters wide without wrapping those lines. This is due to the relaxation of the 72-character restriction on preformatted text and art in the new canonical format. | ||
- | Current requirements re: page breaking | + | The text-only format must represent all SVG-based artwork as a "see reference" |
- | #172: page-breaking enhancements | + | === ASCII vs. UTF-8 for Text Output === |
- | Improve the PI autobreaks=" | + | |
- | | + | |
- | - 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: < | + | As of 2013-10-09, it is not clear whether or not the text output will be ASCII or UTF-8. The following assumes ASCII. If the format is UTF-8, then the following is wrong. |
+ | The text-only format must have the same character-set limitations as the current RFC format. For new RFCs that have non-ASCII characters in them, each such character must be represented as // | ||
- | Current internal guidance to the RPC: | + | //Dave thinks: disagree with the above paragraph. I'm leaning towards saying there should be a separate UTF-8 (e.g. .utf8) text version. |
- | "3+ lines held together" | + | //Paul thinks: if there are two versions, |
- | 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. | + | |
- | Break pseudocode nicely. | + | |