In XFDL, option and suboption elements are allowed to store base-64 encoded and compressed base-64 encoded binary data such as signatures, images, enclosed word processing or spreadsheet documents, and so on. XFDL allows an encoding attribute to control whether an element contains data in a format other than plain XML character data. Both compressed and uncompressed base-64 encoding use no characters that are illegal in character data. Typically, based-64 and compressed base-64 encodings are used with the <mimedata> option in XFDL.
Since binary data tends to be long, XFDL processors are expected to "pretty print" the lines of base-64 (whether or not the binary data is first compressed). Each level of element depth beyond the root <XFDL> tag corresponds to three spaces. The first line of base-64 is expected to be on the line after the element start tag, and the lines of base-64 are expected to be indented three spaces more than the element start tag. For example, the <mimedata> option's start tag is indented 9 spaces (three for the page level, three for the item level and three for the option level), so each line of base-64 content in a <mimedata> option begins with 12 spaces. This should be followed by 76 characters of base-64 (except for the last line), then a linefeed (not a return-newline sequence). Thus, the element end tag is on the line after the last line of base-64 content. The end tag is indented so that it aligns under the start tag (e.g. indent 9 spaces for the <mimedata> option).
The previous method describes the creation of new base-64 encoded content. However, the normal XML preservation of white space in element content should be used when reading XFDL forms so that prior white space indenting techniques used with older XFDL forms and by custom options that use the XFDL encoding attribute will continue to function properly (esp. with regard to digital signature validation).