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/24 16:13] paul Added unpaginated requirements |
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 |
- | * an RFC may include ASCII art OR SVG, but not both | + | |
- | * Paul asks: Why? The term "ASCII art" | + | |
- | * 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. | + | |
- | * non-ASCII characters in the Author' | + | |
- | * Wasn't this supposed to be "with exceptions allowed by the RSE"? | + | |
- | Technical requirements: | + | The text-only |
- | The paginated .txt publication | + | |
- | * use classic/ | + | |
- | * have paginated output | + | |
- | * use classic/ | + | |
- | * support UTF-8 encoding | + | |
- | * max of 80 character | + | |
- | The unpaginated .txt publication | + | The text-only |
- | * use classic/ | + | |
- | * have no page breaks at all | + | |
- | * support UTF-8 encoding | + | |
- | * max of 80 character | + | |
- | 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. | + | |