<commit_before><?xml version="1.0" standalone="no"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
    "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd">
<document>
  <header>
    <title>XML Parsing</title>
  </header>
  <body>
    <section>
      <title>XML Input</title>
      <p>FOP can take the input XML in a number of ways:</p>
      <ul>
        <li><strong>SAX Events through SAX Handler</strong>: <code>FOTreeBuilder</code> is the SAX Handler which is obtained through <code>getContentHandler</code> on <code>Driver</code>.</li>
        <li><strong>DOM (which is converted into SAX Events)</strong>: The conversion of a DOM tree is done via the <code>render(Document)</code> method on <code>Driver</code>.</li>
        <li><strong>Data Source (which is parsed and converted into SAX Events)</strong>: The <code>Driver</code> can take an <code>InputSource</code> as input.
This can use a <code>Stream</code>, <code>String</code> etc.</li>
        <li>XML+XSLT Transformation (which is transformed using an XSLT Processor and the result is fired as SAX Events: <code>XSLTInputHandler</code> is used as an <code>InputSource</code> in the render(<code>XMLReader</code>, <code>InputSource</code>) method on <code>Driver</code></li>
      </ul>
      <p>The SAX Events which are fired on the SAX Handler, class <code>FOTreeBuilder</code>, must represent an XSL:FO document.
If not there will be an error.
Any problems with the XML being well-formed are also handled here.</p>
    </section>
    <section>
      <title>Element Mappings</title>
      <p>The element mapping is a hashmap of all the elements in a particular namespace.
This makes it easy to create a different object for each element.
Element mappings are static to save on memory.</p>
      <p>To add an extension a developer can put in the classpath a jar that contains the file <code>/META-INF/services/org.apache.fop.fo.ElementMapping</code>.
This must contain a line with the fully qualified name of a class that implements the <em>org.apache.fop.fo.ElementMapping</em> interface.
This will then be loaded automatically at the start.
Internal mappings are: FO, SVG and Extension (pdf bookmarks).</p>
    </section>
    <section>
      <title>Tree Building</title>
      <p>The SAX Events will fire all the information for the document with start element, end element, text data etc.
This information is used to build up a representation of the FO document.
To do this for a namespace there is a set of element mappings.
When an element + namepsace mapping is found then it can create an object for that element.
If the element is not found then it creates a dummy object or a generic DOM for unknown namespaces.</p>
      <p>The object is then setup and then given attributes for the element.
For the FO Tree the attributes are converted into properties.
The FO objects use a property list mapping to convert the attributes into a list of properties for the element.
For other XML, for example SVG, a DOM of the XML is constructed.
This DOM can then be passed through to the renderer.
Other element mappings can be used in different ways, for example to create elements that create areas during the layout process or setup information for the renderer etc.</p>
      <p>While the tree building is mainly about creating the FO Tree there are some stages that can propagate to the renderer.
At the end of a page sequence we know that all pages in the page sequence can be laid out without being effected by any further XML.
The significance of this is that the FO Tree for the page sequence may be able to be disposed of.
The end of the XML document also tells us that we can finalise the output document.
(The layout of individual pages is accomplished by the layout managers page at a time; i.e. they do not need to wait for the end of the page sequence.
The page may not yet be complete, however, containing forward page number references, for example.)</p>
    </section>
  </body>
</document>
<commit_msg>Move some content from design/index.xml.<commit_after><?xml version="1.0" standalone="no"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
    "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.dtd">
<document>
  <header>
    <title>XML Parsing</title>
  </header>
  <body>
    <section>
      <title>XML Input</title>
      <p>The xml document is always handled internally as SAX. The SAX events
       are used to read the elements, attributes and text data of the FO document.
       After the manipulation of the data the renderer writes out the pages in the
       appropriate format. It may write as it goes, a page at a time or the whole
       document at once. Once finished the document should contain all the data in the
       chosen format ready for whatever use.</p>
      <p>FOP can take the input XML in a number of ways:</p>
      <ul>
        <li><strong>SAX Events through SAX Handler</strong>: <code>FOTreeBuilder</code> is the SAX Handler which is obtained through <code>getContentHandler</code> on <code>Driver</code>.</li>
        <li><strong>DOM (which is converted into SAX Events)</strong>: The conversion of a DOM tree is done via the <code>render(Document)</code> method on <code>Driver</code>.</li>
        <li><strong>Data Source (which is parsed and converted into SAX Events)</strong>: The <code>Driver</code> can take an <code>InputSource</code> as input.
This can use a <code>Stream</code>, <code>String</code> etc.</li>
        <li>XML+XSLT Transformation (which is transformed using an XSLT Processor and the result is fired as SAX Events: <code>XSLTInputHandler</code> is used as an <code>InputSource</code> in the render(<code>XMLReader</code>, <code>InputSource</code>) method on <code>Driver</code></li>
      </ul>
      <p>The SAX Events which are fired on the SAX Handler, class <code>FOTreeBuilder</code>, must represent an XSL:FO document.
If not there will be an error.
Any problems with the XML being well-formed are also handled here.</p>
    </section>
    <section>
      <title>Element Mappings</title>
      <p>The element mapping is a hashmap of all the elements in a particular namespace.
This makes it easy to create a different object for each element.
Element mappings are static to save on memory.</p>
      <p>To add an extension a developer can put in the classpath a jar that contains the file <code>/META-INF/services/org.apache.fop.fo.ElementMapping</code>.
This must contain a line with the fully qualified name of a class that implements the <em>org.apache.fop.fo.ElementMapping</em> interface.
This will then be loaded automatically at the start.
Internal mappings are: FO, SVG and Extension (pdf bookmarks).</p>
    </section>
    <section>
      <title>Tree Building</title>
      <p>The SAX Events will fire all the information for the document with start element, end element, text data etc.
This information is used to build up a representation of the FO document.
To do this for a namespace there is a set of element mappings.
When an element + namepsace mapping is found then it can create an object for that element.
If the element is not found then it creates a dummy object or a generic DOM for unknown namespaces.</p>
      <p>The object is then setup and then given attributes for the element.
For the FO Tree the attributes are converted into properties.
The FO objects use a property list mapping to convert the attributes into a list of properties for the element.
For other XML, for example SVG, a DOM of the XML is constructed.
This DOM can then be passed through to the renderer.
Other element mappings can be used in different ways, for example to create elements that create areas during the layout process or setup information for the renderer etc.</p>
      <p>While the tree building is mainly about creating the FO Tree there are some stages that can propagate to the renderer.
At the end of a page sequence we know that all pages in the page sequence can be laid out without being effected by any further XML.
The significance of this is that the FO Tree for the page sequence may be able to be disposed of.
The end of the XML document also tells us that we can finalise the output document.
(The layout of individual pages is accomplished by the layout managers page at a time; i.e. they do not need to wait for the end of the page sequence.
The page may not yet be complete, however, containing forward page number references, for example.)</p>
    </section>
  </body>
</document>

{'fraction_non_alphanumeric': 0.08091745255559436, 'fraction_numerical': 0.0013971358714634998, 'mean_word_length': 3.8613469156762874, 'pattern_counts': {'":': 0, '<': 177, '<?xml version=': 2, '>': 177, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 6}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2561988', 'n_tokens_mistral': 2304, 'n_tokens_neox': 2258, 'n_words': 1200}