As users of word processing and spreadsheet applications, we are used to being able to control page parameters such as the orientation of data and margins. When data is presented in EDGAR HTML, controlling page orientation and margins becomes more difficult – if not impossible.
For filing agents, financial printers, law firms or EDGAR departments, problems arise when creating an HTML proof that approximates a page-for-page representation of the original document, which requires the avoidance of “spill over” and short pages. Problems are also encountered when the public goes to view and print the document.
While HTML is a “page” description language, it was designed to provide a method of presenting electronic data to be displayed on a variety of mediums, such as internet web browsers. The notion of the “page” applies to the electronic page, or web page, as opposed to the printed page. Early versions of HTML, including the specification for EDGAR, did not even include HTML/CSS directives to force a page to break much less to specify page orientation.
Later versions of HTML/CSS (specifically CSS 3) provide for specifying parameters for printing such as margins and page orientation, support for these rules is varied.
In addition to the above, the SEC does not actually require page breaks to inserted. The de facto standard is to match the breaks of the original document, hard or soft breaks, with hard HTML breaks. Since the content of an HTML document can reflow depending on the size of the medium (window, paper, etc.), the depth of a page cannot be depended on nor can one determine the exact method a user will use to view or print the document. When coupled with conversion differences, this frequently leads to the content of an original page spilling on to the next page, resulting in a series of full and short pages each time this occurs.
The most one can hope for with documents in HTML is to convert documents in a manner that they will display well across various platforms. Steps can be taken to mitigate these problems, but there is no complete solution.
Tips for pagination of HTML documents:
- Avoid full and tight pages on the original Word document. For example, the typical default browser margins are set to .75in all the way around the page. If the original document is set to any value less than the browser defaults, pages may spill over during printing.
- If you do not want paragraphs to wrap (or break) differently when viewed or printed, set each page in a division with a fixed width. This constrains the resulting page display and the rendering will be version consistent across browsers as well as when printed. However, this adds to the conversion time.
- Set data up to allow the “best fit type” text flowing. Setting table stub lines and headings in a manner that allow for improved re-justification. For example, make sure multi-line table rows are actually set in a single row with cell padding and hangs to allow the stub lines to wrap gracefully.
- When proofing, set up the page setup with expanded margins (.25in top and bottom, .5in left and right). This will not affect public viewing but will avoid spill over during the proof process.
- Some PDF print functions allow the page content to be reduced to allow more information to be placed on the printed page.
- If you are concerned about the “printed” version of your HTML documents, the SEC allows users to submit a unofficial PDF version of your official HTML documents with your filing. For more information on this subject, see 5.2.3 Unofficial PDF in volume II of the EDGAR Filer Manual.
Finally, most filers accept these limitations. After all EDGAR is “Electronic Data” and was designed to store and disseminate electric content, not printed material.
