package.html, [...]: Removed.

* gnu/java/net/protocol/ftp/package.html,
	gnu/javax/swing/text/html/package.html,
	gnu/javax/swing/text/html/parser/package.html,
	gnu/javax/swing/text/html/parser/models/package.html,
	gnu/javax/swing/text/html/parser/support/package.html,
	gnu/javax/swing/text/html/parser/support/low/package.html,
	gnu/xml/aelfred2/package.html, gnu/xml/dom/package.html,
	gnu/xml/pipeline/package.html, gnu/xml/transform/package.html,
	gnu/xml/util/package.html, java/awt/geom/doc-files/Area-1.png,
	java/awt/geom/doc-files/CubicCurve2D-1.png,
	java/awt/geom/doc-files/CubicCurve2D-2.png,
	java/awt/geom/doc-files/CubicCurve2D-3.png,
	java/awt/geom/doc-files/CubicCurve2D-4.png,
	java/awt/geom/doc-files/CubicCurve2D-5.png,
	java/awt/geom/doc-files/Ellipse-1.png,
	java/awt/geom/doc-files/FlatteningPathIterator-1.html,
	java/awt/geom/doc-files/GeneralPath-1.png,
	java/awt/geom/doc-files/QuadCurve2D-1.png,
	java/awt/geom/doc-files/QuadCurve2D-2.png,
	java/awt/geom/doc-files/QuadCurve2D-3.png,
	java/awt/geom/doc-files/QuadCurve2D-4.png,
	java/awt/geom/doc-files/QuadCurve2D-5.png,
	javax/imageio/package.html, javax/imageio/event/package.html,
	javax/imageio/metadata/package.html,
	javax/imageio/spi/package.html, javax/imageio/stream/package.html,
	javax/swing/border/doc-files/BevelBorder-1.png,
	javax/swing/border/doc-files/BevelBorder-2.png,
	javax/swing/border/doc-files/BevelBorder-3.png,
	javax/swing/border/doc-files/EmptyBorder-1.png,
	javax/swing/border/doc-files/EtchedBorder-1.png,
	javax/swing/border/doc-files/EtchedBorder-2.png,
	javax/swing/border/doc-files/LineBorder-1.png,
	javax/swing/border/doc-files/MatteBorder-1.png,
	javax/swing/border/doc-files/MatteBorder-2.png,
	javax/swing/border/doc-files/MatteBorder-3.png,
	javax/swing/border/doc-files/MatteBorder-4.png,
	javax/swing/border/doc-files/MatteBorder-5.png,
	javax/swing/border/doc-files/MatteBorder-6.png,
	javax/swing/border/doc-files/SoftBevelBorder-1.png,
	javax/swing/border/doc-files/SoftBevelBorder-2.png,
	javax/swing/border/doc-files/SoftBevelBorder-3.png,
	javax/swing/plaf/basic/doc-files/BasicBorders-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders-2.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.ButtonBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.FieldBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.MarginBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.MenuBarBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.RadioButtonBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneBorder-2.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneDividerBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicBorders.ToggleButtonBorder-1.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-1.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-2.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-3.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-4.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-5.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-6.png,
	javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-7.png,
	javax/swing/plaf/doc-files/ComponentUI-1.dia,
	javax/swing/plaf/doc-files/ComponentUI-1.png,
	javax/swing/plaf/doc-files/TreeUI-1.png,
	javax/xml/datatype/package.html, javax/xml/namespace/package.html,
	javax/xml/parsers/package.html, javax/xml/transform/package.html,
	javax/xml/transform/dom/package.html,
	javax/xml/transform/sax/package.html,
	javax/xml/transform/stream/package.html,
	javax/xml/validation/package.html, javax/xml/xpath/package.html:
	Removed.

From-SVN: r102404
This commit is contained in:
Tom Tromey 2005-07-26 23:22:38 +00:00 committed by Tom Tromey
parent 86979811f3
commit 6c8a62bbfe
77 changed files with 72 additions and 2308 deletions

View File

@ -1,3 +1,75 @@
2005-07-26 Tom Tromey <tromey@redhat.com>
* gnu/java/net/protocol/ftp/package.html,
gnu/javax/swing/text/html/package.html,
gnu/javax/swing/text/html/parser/package.html,
gnu/javax/swing/text/html/parser/models/package.html,
gnu/javax/swing/text/html/parser/support/package.html,
gnu/javax/swing/text/html/parser/support/low/package.html,
gnu/xml/aelfred2/package.html, gnu/xml/dom/package.html,
gnu/xml/pipeline/package.html, gnu/xml/transform/package.html,
gnu/xml/util/package.html, java/awt/geom/doc-files/Area-1.png,
java/awt/geom/doc-files/CubicCurve2D-1.png,
java/awt/geom/doc-files/CubicCurve2D-2.png,
java/awt/geom/doc-files/CubicCurve2D-3.png,
java/awt/geom/doc-files/CubicCurve2D-4.png,
java/awt/geom/doc-files/CubicCurve2D-5.png,
java/awt/geom/doc-files/Ellipse-1.png,
java/awt/geom/doc-files/FlatteningPathIterator-1.html,
java/awt/geom/doc-files/GeneralPath-1.png,
java/awt/geom/doc-files/QuadCurve2D-1.png,
java/awt/geom/doc-files/QuadCurve2D-2.png,
java/awt/geom/doc-files/QuadCurve2D-3.png,
java/awt/geom/doc-files/QuadCurve2D-4.png,
java/awt/geom/doc-files/QuadCurve2D-5.png,
javax/imageio/package.html, javax/imageio/event/package.html,
javax/imageio/metadata/package.html,
javax/imageio/spi/package.html, javax/imageio/stream/package.html,
javax/swing/border/doc-files/BevelBorder-1.png,
javax/swing/border/doc-files/BevelBorder-2.png,
javax/swing/border/doc-files/BevelBorder-3.png,
javax/swing/border/doc-files/EmptyBorder-1.png,
javax/swing/border/doc-files/EtchedBorder-1.png,
javax/swing/border/doc-files/EtchedBorder-2.png,
javax/swing/border/doc-files/LineBorder-1.png,
javax/swing/border/doc-files/MatteBorder-1.png,
javax/swing/border/doc-files/MatteBorder-2.png,
javax/swing/border/doc-files/MatteBorder-3.png,
javax/swing/border/doc-files/MatteBorder-4.png,
javax/swing/border/doc-files/MatteBorder-5.png,
javax/swing/border/doc-files/MatteBorder-6.png,
javax/swing/border/doc-files/SoftBevelBorder-1.png,
javax/swing/border/doc-files/SoftBevelBorder-2.png,
javax/swing/border/doc-files/SoftBevelBorder-3.png,
javax/swing/plaf/basic/doc-files/BasicBorders-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders-2.png,
javax/swing/plaf/basic/doc-files/BasicBorders.ButtonBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.FieldBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.MarginBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.MenuBarBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.RadioButtonBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneBorder-2.png,
javax/swing/plaf/basic/doc-files/BasicBorders.SplitPaneDividerBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicBorders.ToggleButtonBorder-1.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-1.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-2.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-3.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-4.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-5.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-6.png,
javax/swing/plaf/basic/doc-files/BasicGraphicsUtils-7.png,
javax/swing/plaf/doc-files/ComponentUI-1.dia,
javax/swing/plaf/doc-files/ComponentUI-1.png,
javax/swing/plaf/doc-files/TreeUI-1.png,
javax/xml/datatype/package.html, javax/xml/namespace/package.html,
javax/xml/parsers/package.html, javax/xml/transform/package.html,
javax/xml/transform/dom/package.html,
javax/xml/transform/sax/package.html,
javax/xml/transform/stream/package.html,
javax/xml/validation/package.html, javax/xml/xpath/package.html:
Removed.
2005-07-22 Tom Tromey <tromey@redhat.com>
* include/Makefile.in: Rebuilt.

View File

@ -1,60 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in gnu.java.net.protocol.ftp package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - gnu.java.net.protocol.ftp</title></head>
<body>
<p>
This package contains an FTP client. It can handle both active and passive
mode connections and the various transfer modes and representation types.
</p>
<p>
Interaction with the server is via a simple stream interface. Only one
concurrent stream (input or output) is supported.
</p>
<p>
The control connection to the server can be protected using TLS
(the starttls method).
</p>
</body>
</html>

View File

@ -1,50 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.swing.text.html package.
Copyright (C) 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.swing.text.html</title></head>
<body>
<p> Provides supporting classes for web browsers,
web robots, web page content analysers, web editors and
other applications applications working with Hypertext
Markup Language (HTML).
</p>
</body>
</html>

View File

@ -1,53 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.swing.text.html.parser package.
Copyright (C) 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - gnu.javax.swing.text.html.parser.models</title></head>
<body>
<p>This package contains classes for working with content models. In this implementation, the
standardized content model is pre-processed by <code>transformer</code> into an instance of
<code>node</code>. Node holds a single element of the content model with the optional unary operation.
The derived class <code>list</code> holds multiple nodes connected by the same binary operation.
As the members of this <code>list</code> can also be lists itself, these structures support
the most of required operations. Several cases when the model cannot be expressed using
BNF syntax are handled providing specialised classes that are also derived from <code>node</code>.
</p>
@author Audrius Meskauskas, Lithuania
</body>
</html>

View File

@ -1,51 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.swing.text.html.parser package.
Copyright (C) 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.swing.text.html.parser</title></head>
<body>
<p>Provides the error tolerant, DTD-driven HTML 4.01 parser.
The parser that is used in web robots, html content analysers,
web browsers, web editors and other related applications.
It should compativle with the older HTML versions, supporting
obsoleted HTML featues. This package also includes some
supporting classes.</p>
@author Audrius Meskauskas, Lithuania
</body>
</html>

View File

@ -1,47 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.swing.text.html.parser package.
Copyright (C) 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - gnu.javax.swing.text.html.parser.support.low</title></head>
<body>
<p>This package contains classes that are directly used to process
the text input: adapted stream tokenizer, specialized buffer and text-level content models .</p>
@author Audrius Meskauskas, Lithuania
</body>
</html>

View File

@ -1,47 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.swing.text.html.parser package.
Copyright (C) 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - gnu.javax.swing.text.html.parser.support</title></head>
<body>
<p>This package provides various specialised classes, needed by HTML parser.
</p>
@author Audrius Meskauskas, Lithuania
</body>
</html>

View File

@ -1,506 +0,0 @@
<!DOCTYPE html PUBLIC
'-//W3C//DTD XHTML 1.0 Transitional//EN'
'http://www.w3.org/TR/xhtml1/DTD/transitional.dtd'>
<html><head>
<title>package overview</title>
<!--
/*
* Copyright (C) 1999,2000,2001 The Free Software Foundation, Inc.
*/
-->
</head><body>
<p> This package contains &AElig;lfred2, which includes an
enhanced SAX2-compatible version of the &AElig;lfred
non-validating XML parser, a modular (and hence optional)
DTD validating parser, and modular (and hence optional)
JAXP glue to those.
Use these like any other SAX2 parsers. </p>
<ul>
<li><a href="#about">About &AElig;lfred</a><ul>
<li><a href="#principles">Design Principles</a></li>
<li><a href="#name">About the Name &AElig;lfred</a></li>
<li><a href="#encodings">Character Encodings</a></li>
<li><a href="#violations">Known Conformance Violations</a></li>
<li><a href="#copyright">Licensing</a></li>
</ul></li>
<li><a href="#changes">Changes Since the Last Microstar Release</a><ul>
<li><a href="#sax2">SAX2 Support</a></li>
<li><a href="#validation">Validation</a></li>
<li><a href="#smaller">You Want Smaller?</a></li>
<li><a href="#bugfixes">Bugs Fixed</a></li>
</ul></li>
</ul>
<h2><a name="about">About &AElig;lfred</a></h2>
<p>&AElig;lfred is a XML parser written in the java programming language.
<h3><a name="principles">Design Principles</a></h3>
<p>In most Java applets and applications, XML should not be the central
feature; instead, XML is the means to another end, such as loading
configuration information, reading meta-data, or parsing transactions.</p>
<p> When an XML parser is only a single component of a much larger
program, it cannot be large, slow, or resource-intensive. With Java
applets, in particular, code size is a significant issue. The standard
modem is still not operating at 56 Kbaud, or sometimes even with data
compression. Assuming an uncompressed 28.8 Kbaud modem, only about
3 KBytes can be downloaded in one second; compression often doubles
that speed, but a V.90 modem may not provide another doubling. When
used with embedded processors, similar size concerns apply. </p>
<p> &AElig;lfred is designed for easy and efficient use over the Internet,
based on the following principles: </p> <ol>
<li> &AElig;lfred must be as small as possible, so that it doesn't add too
much to an applet's download time. </li>
<li> &AElig;lfred must use as few class files as possible, to minimize the
number of HTTP connections necessary. (The use of JAR files has made this
be less of a concern.) </li>
<li> &AElig;lfred must be compatible with most or all Java implementations
and platforms. (Write once, run anywhere.) </li>
<li> &AElig;lfred must use as little memory as possible, so that it does
not take away resources from the rest of your program. (It doesn't force
you to use DOM or a similar costly data structure API.)</li>
<li> &AElig;lfred must run as fast as possible, so that it does not slow down
the rest of your program. </li>
<li> &AElig;lfred must produce correct output for well-formed and valid
documents, but need not reject every document that is not valid or
not well-formed. (In &AElig;lfred2, correctness was a bigger concern
than in the original version; and a validation option is available.) </li>
<li> &AElig;lfred must provide full internationalization from the first
release. (&AElig;lfred2 now automatically handles all encodings
supported by the underlying JVM; previous versions handled only
UTF-8, UTF_16, ASCII, and ISO-8859-1.)</li>
</ol>
<p>As you can see from this list, &AElig;lfred is designed for production
use, but neither validation nor perfect conformance was a requirement.
Good validating parsers exist, including one in this package,
and you should use them as appropriate. (See conformance reviews
available at <a href="http://www.xml.com/">http://www.xml.com</a>)
</p>
<p> One of the main goals of &AElig;lfred2 was to significantly improve
conformance, while not significantly affecting the other goals stated above.
Since the only use of this parser is with SAX, some classes could be
removed, and so the overall size of &AElig;lfred was actually reduced.
Subsequent performance work produced a notable speedup (over twenty
percent on larger files). That is, the tradeoffs between speed, size, and
conformance were re-targeted towards conformance and support of newer APIs
(SAX2), with a a positive performance impact. </p>
<p> The role anticipated for this version of &AElig;lfred is as a
lightweight Free Software SAX parser that can be used in essentially every
Java program where the handful of conformance violations (noted below)
are acceptable.
That certainly includes applets, and
nowadays one must also mention embedded systems as being even more
size-critical.
At this writing, all parsers that are more conformant are
significantly larger, even when counting the optional
validation support in this version of &AElig;lfred. </p>
<h3><a name="name">About the Name <em>&AElig;lfred</em></a></h3>
<p>&AElig;lfred the Great (AElfred in ASCII) was King of Wessex, and
some say of King of England, at the time of his death in 899 AD.
&AElig;lfred introduced a wide-spread literacy program in the hope that
his people would learn to read English, at least, if Latin was too
difficult for them. This &AElig;lfred hopes to bring another sort of
literacy to Java, using XML, at least, if full SGML is too difficult.</p>
<p>The initial &AElig; ligature ("AE)" is also a reminder that XML is
not limited to ASCII.</p>
<h3><a name="encodings">Character Encodings</a></h3>
<p> The &AElig;lfred parser currently builds in support for a handful
of input encodings. Of course these include UTF-8 and UTF-16, which
all XML parsers are required to support:</p> <ul>
<li> UTF-8 ... the standard eight bit encoding, used unless
you provide an encoding declaration or a MIME charset tag.</li>
<li> US-ASCII ... an extremely common seven bit encoding,
which happens to be a subset of UTF-8 and ISO-8859-1 as well
as many other encodings. XHTML web pages using US-ASCII
(without an encoding declaration) are probably more
widely interoperable than those in any other encoding. </li>
<li> ISO-8859-1 ... includes accented characters used in
much of western Europe (but excluding the Euro currency
symbol).</li>
<li> UTF-16 ... with several variants, this encodes each
sixteen bit Unicode character in sixteen bits of output.
Variants include UTF-16BE (big endian, no byte order mark),
UTF-16LE (little endian, no byte order mark), and
ISO-10646-UCS-2 (an older and less used encoding, using a
version of Unicode without surrogate pairs). This is
essentially the native encoding used by Java. </li>
<li> ISO-10646-UCS-4 ... a seldom-used four byte encoding,
also known as UTF-32BE. Four byte order variants are supported,
including one known as UTF-32LE. Some operating systems
standardized on UCS-4 despite its significant size penalty,
in anticipation that Unicode (even with surrogate pairs)
would eventually become limiting. UCS-4 permits encoding
of non-Unicode characters, which Java can't represent (and
XML doesn't allow).
</li>
</ul>
<p> If you use any encoding other than UTF-8 or UTF-16 you should
make sure to label your data appropriately: </p>
<blockquote>
&lt;?xml version="1.0" encoding="<b>ISO-8859-15</b>"?&gt;
</blockquote>
<p> Encodings accessed through <code>java.io.InputStreamReader</code>
are now fully supported for both external labels (such as MIME types)
and internal types (as shown above).
There is one limitation in the support for internal labels:
the encodings must be derived from the US-ASCII encoding,
the EBCDIC family of encodings is not recognized.
Note that Java defines its
own encoding names, which don't always correspond to the standard
Internet encoding names defined by the IETF/IANA, and that Java
may even <em>require</em> use of nonstandard encoding names.
Please report
such problems; some of them can be worked around in this parser,
and many can be worked around by using external labels.
</p>
<p>Note that if you are using the Euro symbol with an fixed length
eight bit encoding, you should probably be using the encoding label
<em>iso-8859-15</em> or, with a Microsoft OS, <em>cp-1252</em>.
Of course, UTF-8 and UTF-16 handle the Euro symbol directly.
</p>
<h3><a name="violations">Known Conformance Violations</a></h3>
<p>Known conformance issues should be of negligible importance for
most applications, and include: </p><ul>
<li> Rather than following the voluminous "Appendix B" rules about
what characters may appear in names (and name tokens), the Unicode
rules embedded in <em>java.lang.Character</em> are used.
This means mostly that some names are inappropriately accepted,
though a few are inappropriately rejected. (It's much simpler
to avoid that much special case code. Recent OASIS/NIST test
cases may have these rules be realistically testable.) </li>
<li> Text containing "]]&gt;" is not rejected unless it fully resides
in an internal buffer ... which is, thankfully, the typical case. This
text is illegal, but sometimes appears in illegal attempts to
nest CDATA sections. (Not catching that boundary condition
substantially simplifies parsing text.) </li>
<li> Surrogate characters that aren't correctly paired are ignored
rather than rejected, unless they were encoded using UTF-8. (This
simplifies parsing text.) Unicode 3.1 assigned the first characters
to those character codes, in early 2001, so few documents (or tools)
use such characters in any case. </li>
<li> Declarations following references to an undefined parameter
entity reference are not ignored. (Not maintaining and using state
about this validity error simplifies declaration handling; few
XML parsers address this constraint in any case.) </li>
<li> Well formedness constraints for general entity references
are not enforced. (The code to handle the "content" production
is merged with the element parsing code, making it hard to reuse
for this additional situation.) </li>
</ul>
<p> When tested against the July 12, 1999 version of the OASIS
XML Conformance test suite, an earlier version passed 1057 of 1067 tests.
That contrasts with the original version, which passed 867. The
current parser is top-ranked in terms of conformance, as is its
validating sibling (which has some additional conformance violations
imposed on it by SAX2 API deficiencies as well as some of the more
curious SGML layering artifacts found in the XML specification). </p>
<p> The XML 1.0 specification itself was not without problems,
and after some delays the W3C has come out with a revised
"second edition" specification. While that doesn't resolve all
the problems identified the XML specification, many of the most
egregious problems have been resolved. (You still need to drink
magic Kool-Aid before some DTD-related issues make sense.)
To the extent possible, this parser conforms to that second
edition specification, and does well against corrected versions
of the OASIS/NIST XML conformance test cases. See <a href=
"http://xmlconf.sourceforge.net">http://xmlconf.sourceforge.net</a>
for more information about SAX2/XML conformance testing. </p>
<h3><a name="copyright">Copyright and distribution terms</a></h3>
<p>
The software in this package is distributed under the GNU General Public
License (with a special exception described below).
</p>
<p>
A copy of GNU General Public License (GPL) is included in this distribution,
in the file COPYING. If you do not have the source code, it is available at:
<a href="http://www.gnu.org/software/classpath/">http://www.gnu.org/software/classpath/</a>
</p>
<pre>
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version.
Parts derived from code which carried the following notice:
Copyright (c) 1997, 1998 by Microstar Software Ltd.
AElfred is free for both commercial and non-commercial use and
redistribution, provided that Microstar's copyright and disclaimer are
retained intact. You are free to modify AElfred for your own use and
to redistribute AElfred with your modifications, provided that the
modifications are clearly documented.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
merchantability or fitness for a particular purpose. Please use it AT
YOUR OWN RISK.
</pre>
<p> Some of this documentation was modified from the original
&AElig;lfred README.txt file. All of it has been updated. </p>
</p>
<h2><a name="changes">Changes Since the last Microstar Release</a></h2>
<p> As noted above, Microstar has not updated this parser since
the summer of 1998, when it released version 1.2a on its web site.
This release is intended to benefit the developer community by
refocusing the API on SAX2, and improving conformance to the extent
that most developers should not need to use another XML parser. </p>
<p> The code has been cleaned up (referring to the XML 1.0 spec in
all the production numbers in
comments, rather than some preliminary draft, for one example) and
has been sped up a bit as well.
JAXP support has been added, although developers are still
strongly encouraged to use the SAX2 APIs directly. </p>
<h3><a name="sax2">SAX2 Support</a></h3>
<p> The original version of &AElig;lfred did not support the
SAX2 APIs. </p>
<p> This version supports the SAX2 APIs, exposing the standard
boolean feature descriptors. It supports the "DeclHandler" property
to provide access to all DTD declarations not already exposed
through the SAX1 API. The "LexicalHandler" property is supported,
exposing entity boundaries (including the unnamed external subset) and
things like comments and CDATA boundaries. SAX1 compatibility is
currently provided.</p>
<h3><a name="validation">Validation</a></h3>
<p> In the 'pipeline' package in this same software distribution is an
<a href="../pipeline/ValidationConsumer.html">XML Validation component</a>
using any full SAX2 event stream (including all document type declarations)
to validate. There is now a <a href="XmlReader.html">XmlReader</a> class
which combines that class and this enhanced &AElig;lfred parser, creating
an optionally validating SAX2 parser. </p>
<p> As noted in the documentation for that validating component, certain
validity constraints can't reliably be tested by a layered validator.
These include all constraints relying on
layering violations (exposing XML at the level of tokens or below,
required since XML isn't a context-free grammar), some that
SAX2 doesn't support, and a few others. The resulting validating
parser is conformant enough for most applications that aren't doing
strange SGML tricks with DTDs.
Moreover, that validating filter can be used without
a parser ... any application component that emits SAX event streams
can DTD-validate its output on demand. </p>
<h3><a name="smaller">You want Smaller?</a></h3>
<p> You'll have noticed that the original version of &AElig;lfred
had small size as a top goal. &AElig;lfred2 normally includes a
DTD validation layer, but you can package without that.
Similarly, JAXP factory support is available but optional.
Then the main added cost due to this revision are for
supporting the SAX2 API itself; DTD validation is as
cleanly layered as allowed by SAX2.</p>
<h3><a name="bugfixes">Bugs Fixed</a></h3>
<p> Bugs fixed in &AElig;lfred2 include: </p>
<ol>
<li> Originally &AElig;lfred didn't close file descriptors, which
led to file descriptor leakage on programs which ran for any
length of time. </li>
<li> NOTATION declarations without system identifiers are
now handled correctly. </li>
<li> DTD events are now reported for all invocations of a
given parser, not just the first one. </li>
<li> More correct character handling: <ul>
<li> Rejects out-of-range characters, both in text and in
character references. </li>
<li> Correctly handles character references that expand to
surrogate pairs. </li>
<li> Correctly handles UTF-8 encodings of surrogate pairs. </li>
<li> Correctly handles Unicode 3.1 rules about illegal UTF-8
encodings: there is only one legal encoding per character. </li>
<li> PUBLIC identifiers are now rejected if they have illegal
characters. </li>
<li> The parser is more correct about what characters are allowed
in names and name tokens. Uses Unicode rules (built in to Java)
rather than the voluminous XML rules, although some extensions
have been made to match XML rules more closely.</li>
<li> Line ends are now normalized to newlines in all known
cases. </li>
</ul></li>
<li> Certain validity errors were previously treated as well
formedness violations. <ul>
<li> Repeated declarations of an element type are no
longer fatal errors. </li>
<li> Undeclared parameter entity references are no longer
fatal errors. </li>
</ul></li>
<li> Attribute handling is improved: <ul>
<li> Whitespace must exist between attributes. </li>
<li> Only one value for a given attribute is permitted. </li>
<li> ATTLIST declarations don't need to declare attributes. </li>
<li> Attribute values are normalized when required. </li>
<li> Tabs in attribute values are normalized to spaces. </li>
<li> Attribute values containing a literal "&lt;" are rejected. </li>
</ul></li>
<li> More correct entity handling: <ul>
<li> Whitespace must precede NDATA when declaring unparsed
entities.</li>
<li> Parameter entity declarations may not have NDATA annotations. </li>
<li> The XML specification has a bug in that it doesn't specify
that certain contexts exist within which parameter entity
expansion must not be performed. Lacking an offical erratum,
this parser now disables such expansion inside comments,
processing instructions, ignored sections, public identifiers,
and parts of entity declarations. </li>
<li> Entity expansions that include quote characters no longer
confuse parsing of strings using such expansions. </li>
<li> Whitespace in the values of internal entities is not mapped
to space characters. </li>
<li> General Entity references in attribute defaults within the
DTD now cause fatal errors when the entity is not defined at the
time it is referenced. </li>
<li> Malformed general entity references in entity declarations are
now detected. </li>
</ul></li>
<li> Neither conditional sections
nor parameter entity references within markup declarations
are permitted in the internal subset. </li>
<li> Processing instructions whose target names are "XML"
(ignoring case) are now rejected. </li>
<li> Comments may not include "--".</li>
<li> Most "]]&gt;" sequences in text are rejected. </li>
<li> Correct syntax for standalone declarations is enforced. </li>
<li> Setting a locale for diagnostics only produces an exception
if the language of that locale isn't English. </li>
<li> Some more encoding names are recognized. These include the
Unicode 3.0 variants of UTF-16 (UTF-16BE, UTF-16LE) as well as
US-ASCII and a few commonly seen synonyms. </li>
<li> Text (from character content, PIs, or comments) large enough
not to fit into internal buffers is now handled correctly even in
some cases which were originally handled incorrectly.</li>
<li> Content is now reported for element types for which attributes
have been declared, but no content model is known. (Such documents
are invalid, but may still be well formed.) </li>
</ol>
<p> Other bugs may also have been fixed. </p>
<p> For better overall validation support, some of the validity
constraints that can't be verified using the SAX2 event stream
are now reported directly by &AElig;lfred2. </p>
</body></html>

View File

@ -1,273 +0,0 @@
<html>
<body>
<p>
This is a Free Software DOM Level 3 implementation, supporting these features:
<ul>
<li>"XML"</li>
<li>"Events"</li>
<li>"MutationEvents"</li>
<li>"HTMLEvents" (won't generate them though)</li>
<li>"UIEvents" (also won't generate them)</li>
<li>"USER-Events" (a conformant extension)</li>
<li>"Traversal" (optional)</li>
<li>"XPath"</li>
<li>"LS" and "LS-Async"</li>
</ul>
It is intended to be a reasonable base both for
experimentation and supporting additional DOM modules as clean layers.
</p>
<p>
Note that while DOM does not specify its behavior in the
face of concurrent access, this implementation does.
Specifically:
<ul>
<li>If only one thread at a time accesses a Document,
of if several threads cooperate for read-only access,
then no concurrency conflicts will occur.</li>
<li>If several threads mutate a given document
(or send events using it) at the same time,
there is currently no guarantee that
they won't interfere with each other.</li>
</ul>
</p>
<h3>Design Goals</h3>
<p>
A number of DOM implementations are available in Java, including
commercial ones from Sun, IBM, Oracle, and DataChannel as well as
noncommercial ones from Docuverse, OpenXML, and Silfide. Why have
another? Some of the goals of this version:
</p>
<ul>
<li>Advanced DOM support. This was the first generally available
implementation of DOM Level 2 in Java, and one of the first Level 3
and XPath implementations.</li>
<li> Free Software. This one is distributed under the GPL (with
"library exception") so it can be used with a different class of
application.</li>
<li>Second implementation syndrome. I can do it simpler this time
around ... and heck, writing it only takes a bit over a day once you
know your way around.</li>
<li>Sanity check the then-current Last Call DOM draft. Best to find
bugs early, when they're relatively fixable. Yes, bugs were found.</li>
<li>Modularity. Most of the implementations mentioned above are part
of huge packages; take all (including bugs, of which some have far
too many), or take nothing. I prefer a menu approach, when possible.
This code is standalone, not beholden to any particular parser or XSL
or XPath code.</li>
<li>OK, I'm a hacker, I like to write code.</li>
</ul>
<p>
This also works with the GNU Compiler for Java (GCJ). GCJ promises
to be quite the environment for programming Java, both directly and from
C++ using the new CNI interfaces (which really use C++, unlike JNI). </p>
<h3>Open Issues</h3>
<p>At this writing:</p>
<ul>
<li>See below for some restrictions on the mutation event
support ... some events aren't reported (and likely won't be).</li>
<li>More testing and conformance work is needed.</li>
<li>We need an XML Schema validator (actually we need validation in the DOM
full stop).</li>
</ul>
<p>
I ran a profiler a few times and remove some of the performance hotspots,
but it's not tuned. Reporting mutation events, in particular, is
rather costly -- it started at about a 40% penalty for appendNode calls,
I've got it down around 12%, but it'll be hard to shrink it much further.
The overall code size is relatively small, though you may want to be rid of
many of the unused DOM interface classes (HTML, CSS, and so on).
</p>
<h2><a name="features">Features of this Package</a></h2>
<p> Starting with DOM Level 2, you can really see that DOM is constructed
as a bunch of optional modules around a core of either XML or HTML
functionality. Different implementations will support different optional
modules. This implementation provides a set of features that should be
useful if you're not depending on the HTML functionality (lots of convenience
functions that mostly don't buy much except API surface area) and user
interface support. That is, browsers will want more -- but what they
need should be cleanly layered over what's already here. </p>
<h3> Core Feature Set: "XML" </h3>
<p> This DOM implementation supports the "XML" feature set, which basically
gets you four things over the bare core (which you're officially not supposed
to implement except in conjunction with the "XML" or "HTML" feature). In
order of decreasing utility, those four things are: </p> <ol>
<li> ProcessingInstruction nodes. These are probably the most
valuable thing. Handy little buggers, in part because all the APIs
you need to use them are provided, and they're designed to let you
escape XML document structure rules in controlled ways.</li>
<li> CDATASection nodes. These are of of limited utility since CDATA
is just text that prints funny. These are of use to some sorts of
applications, though I encourage folk to not use them. </li>
<li> DocumentType nodes, and associated Notation and Entity nodes.
These appear to be useless. Briefly, these "Type" nodes expose no
typing information. They're only really usable to expose some lexical
structure that almost every application needs to ignore. (XML editors
might like to see them, but they need true typing information much more.)
I strongly encourage people not to use these. </li>
<li> EntityReference nodes can show up. These are actively annoying,
since they add an extra level of hierarchy, are the cause of most of
the complexity in attribute values, and their contents are immutable.
Avoid these.</li>
</ol>
<h3> Optional Feature Sets: "Events", and friends </h3>
<p> Events may be one of the more interesting new features in Level 2.
This package provides the core feature set and exposes mutation events.
No gooey events though; if you want that, write a layered implementation! </p>
<p> Three mutation events aren't currently generated:</p> <ul>
<li> <em>DOMSubtreeModified</em> is poorly specified. Think of this
as generating one such event around the time of finalization, which
is a fully conformant implementation. This implementation is exactly
as useful as that one. </li>
<li> <em>DOMNodeRemovedFromDocument</em> and
<em>DOMNodeInsertedIntoDocument</em> are supposed to get sent to
every node in a subtree that gets removed or inserted (respectively).
This can be <em>extremely costly</em>, and the removal and insertion
processing is already significantly slower due to event reporting.
It's much easier, and more efficient, to have a listener higher in the
tree watch removal and insertion events through the bubbling or capture
mechanisms, than it is to watch for these two events.</li>
</ul>
<p> In addition, certain kinds of attribute modification aren't reported.
A fix is known, but it couldn't report the previous value of the attribute.
More work could fix all of this (as well as reduce the generally high cost
of childful attributes), but that's not been done yet. </p>
<p> Also, note that it is a <em>Bad Thing&#153;</em> to have the listener
for a mutation event change the ancestry for the target of that event.
Or to prevent mutation events from bubbling to where they're needed.
Just don't do those, OK? </p>
<p> As an experimental feature (named "USER-Events"), you can provide
your own "user" events. Just name them anything starting with "USER-"
and you're set. Dispatch them through, bubbling, capturing, or what
ever takes your fancy. One important thing you can't currently do is
pass any data (like an object) with those events. Maybe later there
will be a "UserEvent" interface letting you get some substantial use
out of this mechanism even if you're not "inside" of a DOM package.</p>
<p> You can create and send HTML events. Ditto UIEvents. Since DOM
doesn't require a UI, it's the UI's job to send them; perhaps that's
part of your application. </p>
<p><em>This package may be built without the ability to report mutation
events, gaining a significant speedup in DOM construction time. However,
if that is done then certain other features -- notably node iterators
and getElementsByTagname -- will not be available.</em>
<h3> Optional Feature: "Traversal" </h3>
<p> Each DOM node has all you need to walk to everything connected
to that node. Lightweight, efficient utilities are easily layered on
top of just the core APIs. </p>
<p> Traversal APIs are an optional part of DOM Level 2, providing
a not-so-lightweight way to walk over DOM trees, if your application
didn't already have such utilities for use with data represented via
DOM. Implementing this helped debug the (optional) event and mutation
event subsystems, so it's provided here. </p>
<p> At this writing, the "TreeWalker" interface isn't implemented. </p>
<h2><a name='avoid'>DOM Functionality to Avoid</a></h2>
<p> For what appear to be a combination of historical and "committee
logic" reasons, DOM has a number of <em>features which I strongly advise
you to avoid using</em> in your library and application code. These
include the following types of DOM nodes; see the documentation for the
implementation class for more information: <ul>
<li> CDATASection
(<a href='DomCDATA.html'>DomCDATA</a> class)
... use normal Text nodes instead, so you don't have to make
every algorithm recognize multiple types of character data
<li> DocumentType
(<a href='DomDoctype.html'>DomDocType</a> class)
... if this held actual typing information, it might be useful
<li> Entity
(<a href='DomEntity.html'>DomEntity</a> class)
... neither parsed nor unparsed entities work well in DOM; it
won't even tell you which attributes identify unparsed entities
<li> EntityReference
(<a href='DomEntityReference.html'>DomEntityReference</a> class)
... permitted implementation variances are extreme, all children
are readonly, and these can interact poorly with namespaces
<li> Notation
(<a href='DomNotation.html'>DomNotation</a> class)
... only really usable with unparsed entities (which aren't well
supported; see above) or perhaps with PIs after the DTD, not with
NOTATION attributes
</ul>
<p> If you really need to use unparsed entities or notations, use SAX;
it offers better support for all DTD-related functionality.
It also exposes actual
document typing information (such as element content models).</p>
<p> Also, when accessing attribute values, use methods that provide their
values as single strings, rather than those which expose value substructure
(Text and EntityReference nodes). (See the <a href='DomAttr.html'>DomAttr</a>
documentation for more information.) </p>
<p> Note that many of these features were provided as partial support for
editor functionality (including the incomplete DTD access). Full editor
functionality requires access to potentially malformed lexical structure,
at the level of unparsed tokens and below. Access at such levels is so
complex that using it in non-editor applications sacrifices all the
benefits of XML; editor aplications need extremely specialized APIs. </p>
<p> (This isn't a slam against DTDs, note; only against the broken support
for them in DOM. Even despite inclusion of some dubious SGML legacy features
such as notations and unparsed entities,
and the ongoing proliferation of alternative schema and validation tools,
DTDs are still the most widely adopted tool
to constrain XML document structure.
Alternative schemes generally focus on data transfer style
applications; open document architectures comparable to
DocBook 4.0 don't yet exist in the schema world.
Feel free to use DTDs; just don't expect DOM to help you.) </p>
</body>
</html>

View File

@ -1,255 +0,0 @@
<html><head><title>
blah
<!--
/*
* Copyright (C) 1999-2001 The Free Software Foundation, Inc.
*/
-->
</title></head><body>
<p>This package exposes a kind of XML processing pipeline, based on sending
SAX events, which can be used as components of application architectures.
Pipelines are used to convey streams of processing events from a producer
to one or more consumers, and to let each consumer control the data seen by
later consumers.
<p> There is a <a href="PipelineFactory.html">PipelineFactory</a> class which
accepts a syntax describing how to construct some simple pipelines. Strings
describing such pipelines can be used in command line tools (see the
<a href="../util/DoParse.html">DoParse</a> class)
and in other places that it is
useful to let processing be easily reconfigured. Pipelines can of course
be constructed programmatically, providing access to options that the
factory won't.
<p> Web applications are supported by making it easy for servlets (or
non-Java web application components) to be part of a pipeline. They can
originate XML (or XHTML) data through an <em>InputSource</em> or in
response to XML messages sent from clients using <em>CallFilter</em>
pipeline stages. Such facilities are available using the simple syntax
for pipeline construction.
<h2> Programming Models </h2>
<p> Pipelines should be simple to understand.
<ul>
<li> XML content, typically entire documents,
is pushed through consumers by producers.
<li> Pipelines are basically about consuming SAX2 callback events,
where the events encapsulate XML infoset-level data.<ul>
<li> Pipelines are constructed by taking one or more consumer
stages and combining them to produce a composite consumer.
<li> A pipeline is presumed to have pending tasks and state from
the beginning of its ContentHandler.startDocument() callback until
it's returned from its ContentHandler.doneDocument() callback.
<li> Pipelines may have multiple output stages ("fan-out")
or multiple input stages ("fan-in") when appropriate.
<li> Pipelines may be long-lived, but need not be.
</ul>
<li> There is flexibility about event production. <ul>
<li> SAX2 XMLReader objects are producers, which
provide a high level "pull" model: documents (text or DOM) are parsed,
and the parser pushes individual events through the pipeline.
<li> Events can be pushed directly to event consumer components
by application modules, if they invoke SAX2 callbacks directly.
That is, application modules use the XML Infoset as exposed
through SAX2 event callbacks.
</ul>
<li> Multiple producer threads may concurrently access a pipeline,
if they coordinate appropriately.
<li> Pipeline processing is not the only framework applications
will use.
</ul>
<h3> Producers: XMLReader or Custom </h3>
<p> Many producers will be SAX2 XMLReader objects, and
will read (pull) data which is then written (pushed) as events.
Typically these will parse XML text (acquired from
<code>org.xml.sax.helpers.XMLReaderFactory</code>) or a DOM tree
(using a <code><a href="../util/DomParser.html">DomParser</a></code>)
These may be bound to event consumer using a convenience routine,
<em><a href="EventFilter.html">EventFilter</a>.bind()</em>.
Once bound, these producers may be given additional documents to
sent through its pipeline.
<p> In other cases, you will write producers yourself. For example, some
data structures might know how to write themselves out using one or
more XML models, expressed as sequences of SAX2 event callbacks.
An application module might
itself be a producer, issuing startDocument and endDocument events
and then asking those data structures to write themselves out to a
given EventConsumer, or walking data structures (such as JDBC query
results) and applying its own conversion rules. WAP format XML
(WBMXL) can be directly converted to producer output.
<p> SAX2 introduced an "XMLFilter" interface, which is a kind of XMLReader.
It is most useful in conjunction with its XMLFilterImpl helper class;
see the <em><a href="EventFilter.html">EventFilter</a></em> javadoc
for information contrasting that XMLFilterImpl approach with the
relevant parts of this pipeline framework. Briefly, such XMLFilterImpl
children can be either producers or consumers, and are more limited in
configuration flexibility. In this framework, the focus of filters is
on the EventConsumer side; see the section on
<a href="#fitting">pipe fitting</a> below.
<h3> Consume to Standard or Custom Data Representations </h3>
<p> Many consumers will be used to create standard representations of XML
data. The <a href="TextConsumer.html">TextConsumer</a> takes its events
and writes them as text for a single XML document,
using an internal <a href="../util/XMLWriter.html">XMLWriter</a>.
The <a href="DomConsumer.html">DomConsumer</a> takes its events and uses
them to create and populate a DOM Document.
<p> In other cases, you will write consumers yourself. For example,
you might use a particular unmarshaling filter to produce objects
that fit your application's requirements, instead of using DOM.
Such consumers work at the level of XML data models, rather than with
specific representations such as XML text or a DOM tree. You could
convert your output directly to WAP format data (WBXML).
<h3><a name="fitting">Pipe Fitting</a></h3>
<p> Pipelines are composite event consumers, with each stage having
the opportunity to transform the data before delivering it to any
subsequent stages.
<p> The <a href="PipelineFactory.html">PipelineFactory</a> class
provides access to much of this functionality through a simple syntax.
See the table in that class's javadoc describing a number of standard
components. Direct API calls are still needed for many of the most
interesting pipeline configurations, including ones leveraging actual
or logical concurrency.
<p> Four basic types of pipe fitting are directly supported. These may
be used to construct complex pipeline networks. <ul>
<li> <a href="TeeConsumer.html">TeeConsumer</a> objects split event
flow so it goes to two two different consumers, one before the other.
This is a basic form of event fan-out; you can use this class to
copy events to any number of output pipelines.
<li> Clients can call remote components through HTTP or HTTPS using
the <a href="CallFilter.html">CallFilter</a> component, and Servlets
can implement such components by extending the
<a href="XmlServlet.html">XmlServlet</a> component. Java is not
required on either end, and transport protocols other than HTTP may
also be used.
<li> <a href="EventFilter.html">EventFilter</a> objects selectively
provide handling for callbacks, and can pass unhandled ones to a
subsequent stage. They are often subclassed, since much of the
basic filtering machinery is already in place in the base class.
<li> Applications can merge two event flows by just using the same
consumer in each one. If multiple threads are in use, synchronization
needs to be addressed by the appropriate application level policy.
</ul>
<p> Note that filters can be as complex as
<a href="XsltFilter.html">XSLT transforms</a>
available) on input data, or as simple as removing simple syntax data
such as ignorable whitespace, comments, and CDATA delimiters.
Some simple "built-in" filters are part of this package.
<h3> Coding Conventions: Filter and Terminus Stages</h3>
<p> If you follow these coding conventions, your classes may be used
directly (give the full class name) in pipeline descriptions as understood
by the PipelineFactory. There are four constructors the factory may
try to use; in order of decreasing numbers of parameters, these are: <ul>
<li> Filters that need a single String setup parameter should have
a public constructor with two parameters: that string, then the
EventConsumer holding the "next" consumer to get events.
<li> Filters that don't need setup parameters should have a public
constructor that accepts a single EventConsumer holding the "next"
consumer to get events when they are done.
<li> Terminus stages may have a public constructor taking a single
paramter: the string value of that parameter.
<li> Terminus stages may have a public no-parameters constructor.
</ul>
<p> Of course, classes may support more than one such usage convention;
if they do, they can automatically be used in multiple modes. If you
try to use a terminus class as a filter, and that terminus has a constructor
with the appropriate number of arguments, it is automatically wrapped in
a "tee" filter.
<h2> Debugging Tip: "Tee" Joints can Snapshot Data</h2>
<p> It can sometimes be hard to see what's happening, when something
goes wrong. Easily fixed: just snapshot the data. Then you can find
out where things start to go wrong.
<p> If you're using pipeline descriptors so that they're easily
administered, just stick a <em>write&nbsp;(&nbsp;filename&nbsp;)</em>
filter into the pipeline at an appropriate point.
<p> Inside your programs, you can do the same thing directly: perhaps
by saving a Writer (perhaps a StringWriter) in a variable, using that
to create a TextConsumer, and making that the first part of a tee --
splicing that into your pipeline at a convenient location.
<p> You can also use a DomConsumer to buffer the data, but remember
that DOM doesn't save all the information that XML provides, so that DOM
snapshots are relatively low fidelity. They also are substantially more
expensive in terms of memory than a StringWriter holding similar data.
<h2> Debugging Tip: Non-XML Producers</h2>
<p> Producers in pipelines don't need to start from XML
data structures, such as text in XML syntax (likely coming
from some <em>XMLReader</em> that parses XML) or a
DOM representation (perhaps with a
<a href="../util/DomParser.html">DomParser</a>).
<p> One common type of event producer will instead make
direct calls to SAX event handlers returned from an
<a href="EventConsumer.html">EventConsumer</a>.
For example, making <em>ContentHandler.startElement</em>
calls and matching <em>ContentHandler.endElement</em> calls.
<p> Applications making such calls can catch certain
common "syntax errors" by using a
<a href="WellFormednessFilter.html">WellFormednessFilter</a>.
That filter will detect (and report) erroneous input data
such as mismatched document, element, or CDATA start/end calls.
Use such a filter near the head of the pipeline that your
producer feeds, at least while debugging, to help ensure that
you're providing legal XML Infoset data.
<p> You can also arrange to validate data on the fly.
For DTD validation, you can configure a
<a href="ValidationConsumer.html">ValidationConsumer</a>
to work as a filter, using any DTD you choose.
Other validation schemes can be handled with other
validation filters.
</body></html>

View File

@ -1,77 +0,0 @@
<html>
<body>
<h1>GNU JAXP XSL transformer</h1>
<div>
This package contains a Java XSL transformer compliant with the JAXP
specification. It depends on the GNU DOM and XPath implementations, and
will generate GNU DOM nodes unless a specific target from another
implementation was given. It understands DOM, SAX, and stream sources
and result sinks and supports these JAXP features.
</div>
<div>
To use this transformer, set the system property
<code>javax.xml.transform.TransformerFactory</code> to the value
<code>gnu.xml.transform.TransformerFactoryImpl</code>. You can then
instantiate <a href='TransformerFactory.html'>TransformerFactory</a>
and transformers in the ordinary manner. Reuse of stylesheets is
supported using the JAXP <a href='Templates.html'>Templates</a>
mechanism.
</div>
<h3>Architecture</h3>
<div>
When given a stylesheet source, this implementation compiles it internally
into a Stylesheet object, which is a container for templates and state.
Each stylesheet instruction is represented by a subclass of TemplateNode,
which is arranged in a directed graph: each TemplateNode has a reference
to its first child and the next node.
</div>
<div>
The transformation process consists of identifying the Template that matches
the root of the source context, and calling <code>apply</code> on its
corresponding TemplateNode. This in turn processes its children and next
TemplateNode, depending on the semantics of each node type.
</div>
<div>
Template nodes may reference XPath expressions or patterns. These are fully
compiled to objects of type <a href='../xpath/Expr.html'>Expr</a> at the
time the stylesheet is compiled.
</div>
<h3>Conformance</h3>
<div>
This implementation is feature complete, but the XSLT specification is
large and there are still many bugs that need to be ironed out. It has
been tested against the OASIS XSLT TC test suite, comprising unit tests
from the Xalan project and Microsoft. Conformance to these unit tests
is approximately 70% at the current time, although normal usage of the
transformer should involve relatively few surprises (the test suite is
designed to test very complex and obscure functionality).
</div>
<h3>Known bugs</h3>
<ul>
<li>When reusing stylesheets using the JAXP Templates mechanism, XSL
<code>apply-imports</code> instructions will not work.</li>
<li>XPath filter expressions do not always work as expected (this is a
problem with the GNU XPath implementation rather than the transformer).
This can result in problems with the <code>position()</code> function,
as well as <code>select</code> expressions and numbering.</li>
</ul>
<div>
Obviously we'd like to improve conformance and fix these bugs. If you're
interested in working on any of these issues please
<a href='mailto:classpathx-xml@gnu.org'>contact us</a>.
</div>
</body>
</html>

View File

@ -1,20 +0,0 @@
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/1999/PR-xhtml1-19991210/DTD/xhtml1-transitional.dtd">
<html><head><title> org.brownell.xml package </title> </head>
<!--
/*
* Copyright (C) 1999,2000 The Free Software Foundation, Inc.
*/
-->
<body>
<p> This package contains XML utilities, including SAX2 XML writers
and a parser of DOM trees, plus a command line driver.
That <a href="DoParse.html">driver</a>
connects parsers simple processing pipelines.
It can be handy for command line validation or
transformation tasks, possibly in batch mode,
or within Makefiles. </p>
</body></html>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

View File

@ -1,481 +0,0 @@
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>The GNU Implementation of java.awt.geom.FlatteningPathIterator</title>
<meta name="author" content="Sascha Brawer" />
<style type="text/css"><!--
td { white-space: nowrap; }
li { margin: 2mm 0; }
--></style>
</head>
<body>
<h1>The GNU Implementation of FlatteningPathIterator</h1>
<p><i><a href="http://www.dandelis.ch/people/brawer/">Sascha
Brawer</a>, November 2003</i></p>
<p>This document describes the GNU implementation of the class
<code>java.awt.geom.FlatteningPathIterator</code>. It does
<em>not</em> describe how a programmer should use this class; please
refer to the generated API documentation for this purpose. Instead, it
is intended for maintenance programmers who want to understand the
implementation, for example because they want to extend the class or
fix a bug.</p>
<h2>Data Structures</h2>
<p>The algorithm uses a stack. Its allocation is delayed to the time
when the source path iterator actually returns the first curved
segment (either <code>SEG_QUADTO</code> or <code>SEG_CUBICTO</code>).
If the input path does not contain any curved segments, the value of
the <code>stack</code> variable stays <code>null</code>. In this quite
common case, the memory consumption is minimal.</p>
<dl><dt><code>stack</code></dt><dd>The variable <code>stack</code> is
a <code>double</code> array that holds the start, control and end
points of individual sub-segments.</dd>
<dt><code>recLevel</code></dt><dd>The variable <code>recLevel</code>
holds how many recursive sub-divisions were needed to calculate a
segment. The original curve has recursion level 0. For each
sub-division, the corresponding recursion level is increased by
one.</dd>
<dt><code>stackSize</code></dt><dd>Finally, the variable
<code>stackSize</code> indicates how many sub-segments are stored on
the stack.</dd></dl>
<h2>Algorithm</h2>
<p>The implementation separately processes each segment that the
base iterator returns.</p>
<p>In the case of <code>SEG_CLOSE</code>,
<code>SEG_MOVETO</code> and <code>SEG_LINETO</code> segments, the
implementation simply hands the segment to the consumer, without actually
doing anything.</p>
<p>Any <code>SEG_QUADTO</code> and <code>SEG_CUBICTO</code> segments
need to be flattened. Flattening is performed with a fixed-sized
stack, holding the coordinates of subdivided segments. When the base
iterator returns a <code>SEG_QUADTO</code> and
<code>SEG_CUBICTO</code> segments, it is recursively flattened as
follows:</p>
<ol><li>Intialization: Allocate memory for the stack (unless a
sufficiently large stack has been allocated previously). Push the
original quadratic or cubic curve onto the stack. Mark that segment as
having a <code>recLevel</code> of zero.</li>
<li>If the stack is empty, flattening the segment is complete,
and the next segment is fetched from the base iterator.</li>
<li>If the stack is not empty, pop a curve segment from the
stack.
<ul><li>If its <code>recLevel</code> exceeds the recursion limit,
hand the current segment to the consumer.</li>
<li>Calculate the squared flatness of the segment. If it smaller
than <code>flatnessSq</code>, hand the current segment to the
consumer.</li>
<li>Otherwise, split the segment in two halves. Push the right
half onto the stack. Then, push the left half onto the stack.
Continue with step two.</li></ul></li>
</ol>
<p>The implementation is slightly complicated by the fact that
consumers <em>pull</em> the flattened segments from the
<code>FlatteningPathIterator</code>. This means that we actually
cannot &#x201c;hand the curent segment over to the consumer.&#x201d;
But the algorithm is easier to understand if one assumes a
<em>push</em> paradigm.</p>
<h2>Example</h2>
<p>The following example shows how a
<code>FlatteningPathIterator</code> processes a
<code>SEG_QUADTO</code> segment. It is (arbitrarily) assumed that the
recursion limit was set to 2.</p>
<blockquote>
<table border="1" cellspacing="0" cellpadding="8">
<tr align="center" valign="baseline">
<th></th><th>A</th><th>B</th><th>C</th>
<th>D</th><th>E</th><th>F</th><th>G</th><th>H</th>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[0]</code></th>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td><i>S<sub>ll</sub>.x</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[1]</code></th>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td><i>S<sub>ll</sub>.y</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[2]</code></th>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td><i>C<sub>ll</sub>.x</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[3]</code></th>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td><i>C<sub>ll</sub>.y</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[4]</code></th>
<td>&#x2014;</td>
<td><i>S<sub>l</sub>.x</i></td>
<td><i>E<sub>ll</sub>.x</i>
= <i>S<sub>lr</sub>.x</i></td>
<td><i>S<sub>lr</sub>.x</i></td>
<td>&#x2014;</td>
<td><i>S<sub>rl</sub>.x</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[5]</code></th>
<td>&#x2014;</td>
<td><i>S<sub>l</sub>.y</i></td>
<td><i>E<sub>ll</sub>.x</i>
= <i>S<sub>lr</sub>.y</i></td>
<td><i>S<sub>lr</sub>.y</i></td>
<td>&#x2014;</td>
<td><i>S<sub>rl</sub>.y</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[6]</code></th>
<td>&#x2014;</td>
<td><i>C<sub>l</sub>.x</i></td>
<td><i>C<sub>lr</sub>.x</i></td>
<td><i>C<sub>lr</sub>.x</i></td>
<td>&#x2014;</td>
<td><i>C<sub>rl</sub>.x</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[7]</code></th>
<td>&#x2014;</td>
<td><i>C<sub>l</sub>.y</i></td>
<td><i>C<sub>lr</sub>.y</i></td>
<td><i>C<sub>lr</sub>.y</i></td>
<td>&#x2014;</td>
<td><i>C<sub>rl</sub>.y</i></td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[8]</code></th>
<td><i>S.x</i></td>
<td><i>E<sub>l</sub>.x</i>
= <i>S<sub>r</sub>.x</i></td>
<td><i>E<sub>lr</sub>.x</i>
= <i>S<sub>r</sub>.x</i></td>
<td><i>E<sub>lr</sub>.x</i>
= <i>S<sub>r</sub>.x</i></td>
<td><i>S<sub>r</sub>.x</i></td>
<td><i>E<sub>rl</sub>.x</i>
= <i>S<sub>rr</sub>.x</i></td>
<td><i>S<sub>rr</sub>.x</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[9]</code></th>
<td><i>S.y</i></td>
<td><i>E<sub>l</sub>.y</i>
= <i>S<sub>r</sub>.y</i></td>
<td><i>E<sub>lr</sub>.y</i>
= <i>S<sub>r</sub>.y</i></td>
<td><i>E<sub>lr</sub>.y</i>
= <i>S<sub>r</sub>.y</i></td>
<td><i>S<sub>r</sub>.y</i></td>
<td><i>E<sub>rl</sub>.y</i>
= <i>S<sub>rr</sub>.y</i></td>
<td><i>S<sub>rr</sub>.y</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[10]</code></th>
<td><i>C.x</i></td>
<td><i>C<sub>r</sub>.x</i></td>
<td><i>C<sub>r</sub>.x</i></td>
<td><i>C<sub>r</sub>.x</i></td>
<td><i>C<sub>r</sub>.x</i></td>
<td><i>C<sub>rr</sub>.x</i></td>
<td><i>C<sub>rr</sub>.x</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[11]</code></th>
<td><i>C.y</i></td>
<td><i>C<sub>r</sub>.y</i></td>
<td><i>C<sub>r</sub>.y</i></td>
<td><i>C<sub>r</sub>.y</i></td>
<td><i>C<sub>r</sub>.y</i></td>
<td><i>C<sub>rr</sub>.y</i></td>
<td><i>C<sub>rr</sub>.y</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[12]</code></th>
<td><i>E.x</i></td>
<td><i>E<sub>r</sub>.x</i></td>
<td><i>E<sub>r</sub>.x</i></td>
<td><i>E<sub>r</sub>.x</i></td>
<td><i>E<sub>r</sub>.x</i></td>
<td><i>E<sub>rr</sub>.x</i></td>
<td><i>E<sub>rr</sub>.x</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stack[13]</code></th>
<td><i>E.y</i></td>
<td><i>E<sub>r</sub>.y</i></td>
<td><i>E<sub>r</sub>.y</i></td>
<td><i>E<sub>r</sub>.y</i></td>
<td><i>E<sub>r</sub>.y</i></td>
<td><i>E<sub>rr</sub>.y</i></td>
<td><i>E<sub>rr</sub>.x</i></td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>stackSize</code></th>
<td>1</td>
<td>2</td>
<td>3</td>
<td>2</td>
<td>1</td>
<td>2</td>
<td>1</td>
<td>0</td>
</tr>
<tr align="center" valign="baseline">
<th><code>recLevel[2]</code></th>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>2</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>recLevel[1]</code></th>
<td>&#x2014;</td>
<td>1</td>
<td>2</td>
<td>2</td>
<td>&#x2014;</td>
<td>2</td>
<td>&#x2014;</td>
<td>&#x2014;</td>
</tr>
<tr align="center" valign="baseline">
<th><code>recLevel[0]</code></th>
<td>0</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>1</td>
<td>2</td>
<td>2</td>
<td>&#x2014;</td>
</tr>
</table>
</blockquote>
<ol>
<li>The data structures are initialized as follows.
<ul><li>The segment&#x2019;s end point <i>E</i>, control point
<i>C</i>, and start point <i>S</i> are pushed onto the stack.</li>
<li>Currently, the curve in the stack would be approximated by one
single straight line segment (<i>S</i> &#x2013; <i>E</i>).
Therefore, <code>stackSize</code> is set to 1.</li>
<li>This single straight line segment is approximating the original
curve, which can be seen as the result of zero recursive
splits. Therefore, <code>recLevel[0]</code> is set to
zero.</li></ul>
Column A shows the state after the initialization step.</li>
<li>The algorithm proceeds by taking the topmost curve segment
(<i>S</i> &#x2013; <i>C</i> &#x2013; <i>E</i>) from the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[0]</code>) is zero, which is smaller than
the limit 2.</li>
<li>The method <code>java.awt.geom.QuadCurve2D.getFlatnessSq</code>
is called to calculate the squared flatness.</li>
<li>For the sake of argument, we assume that the squared flatness is
exceeding the threshold stored in <code>flatnessSq</code>. Thus, the
curve segment <i>S</i> &#x2013; <i>C</i> &#x2013; <i>E</i> gets
subdivided into a left and a right half, namely
<i>S<sub>l</sub></i> &#x2013; <i>C<sub>l</sub></i> &#x2013;
<i>E<sub>l</sub></i> and <i>S<sub>r</sub></i> &#x2013;
<i>C<sub>r</sub></i> &#x2013; <i>E<sub>r</sub></i>. Both halves are
pushed onto the stack, so the left half is now on top.
<br />&nbsp;<br />The left half starts at the same point
as the original curve, so <i>S<sub>l</sub></i> has the same
coordinates as <i>S</i>. Similarly, the end point of the right
half and of the original curve are identical
(<i>E<sub>r</sub></i> = <i>E</i>). More interestingly, the left
half ends where the right half starts. Because
<i>E<sub>l</sub></i> = <i>S<sub>r</sub></i>, their coordinates need
to be stored only once, which amounts to saving 16 bytes (two
<code>double</code> values) for each iteration.</li></ul>
Column B shows the state after the first iteration.</li>
<li>Again, the topmost curve segment (<i>S<sub>l</sub></i>
&#x2013; <i>C<sub>l</sub></i> &#x2013; <i>E<sub>l</sub></i>) is
taken from the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[1]</code>) is 1, which is smaller than
the limit 2.</li>
<li>The method <code>java.awt.geom.QuadCurve2D.getFlatnessSq</code>
is called to calculate the squared flatness.</li>
<li>Assuming that the segment is still not considered
flat enough, it gets subdivided into a left
(<i>S<sub>ll</sub></i> &#x2013; <i>C<sub>ll</sub></i> &#x2013;
<i>E<sub>ll</sub></i>) and a right (<i>S<sub>lr</sub></i>
&#x2013; <i>C<sub>lr</sub></i> &#x2013; <i>E<sub>lr</sub></i>)
half.</li></ul>
Column C shows the state after the second iteration.</li>
<li>The topmost curve segment (<i>S<sub>ll</sub></i> &#x2013;
<i>C<sub>ll</sub></i> &#x2013; <i>E<sub>ll</sub></i>) is popped from
the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[2]</code>) is 2, which is <em>not</em> smaller than
the limit 2. Therefore, a <code>SEG_LINETO</code> (from
<i>S<sub>ll</sub></i> to <i>E<sub>ll</sub></i>) is passed to the
consumer.</li></ul>
The new state is shown in column D.</li>
<li>The topmost curve segment (<i>S<sub>lr</sub></i> &#x2013;
<i>C<sub>lr</sub></i> &#x2013; <i>E<sub>lr</sub></i>) is popped from
the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[1]</code>) is 2, which is <em>not</em> smaller than
the limit 2. Therefore, a <code>SEG_LINETO</code> (from
<i>S<sub>lr</sub></i> to <i>E<sub>lr</sub></i>) is passed to the
consumer.</li></ul>
The new state is shown in column E.</li>
<li>The algorithm proceeds by taking the topmost curve segment
(<i>S<sub>r</sub></i> &#x2013; <i>C<sub>r</sub></i> &#x2013;
<i>E<sub>r</sub></i>) from the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[0]</code>) is 1, which is smaller than
the limit 2.</li>
<li>The method <code>java.awt.geom.QuadCurve2D.getFlatnessSq</code>
is called to calculate the squared flatness.</li>
<li>For the sake of argument, we again assume that the squared
flatness is exceeding the threshold stored in
<code>flatnessSq</code>. Thus, the curve segment
(<i>S<sub>r</sub></i> &#x2013; <i>C<sub>r</sub></i> &#x2013;
<i>E<sub>r</sub></i>) is subdivided into a left and a right half,
namely
<i>S<sub>rl</sub></i> &#x2013; <i>C<sub>rl</sub></i> &#x2013;
<i>E<sub>rl</sub></i> and <i>S<sub>rr</sub></i> &#x2013;
<i>C<sub>rr</sub></i> &#x2013; <i>E<sub>rr</sub></i>. Both halves
are pushed onto the stack.</li></ul>
The new state is shown in column F.</li>
<li>The topmost curve segment (<i>S<sub>rl</sub></i> &#x2013;
<i>C<sub>rl</sub></i> &#x2013; <i>E<sub>rl</sub></i>) is popped from
the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[2]</code>) is 2, which is <em>not</em> smaller than
the limit 2. Therefore, a <code>SEG_LINETO</code> (from
<i>S<sub>rl</sub></i> to <i>E<sub>rl</sub></i>) is passed to the
consumer.</li></ul>
The new state is shown in column G.</li>
<li>The topmost curve segment (<i>S<sub>rr</sub></i> &#x2013;
<i>C<sub>rr</sub></i> &#x2013; <i>E<sub>rr</sub></i>) is popped from
the stack.
<ul><li>The recursion level of this segment (stored in
<code>recLevel[2]</code>) is 2, which is <em>not</em> smaller than
the limit 2. Therefore, a <code>SEG_LINETO</code> (from
<i>S<sub>rr</sub></i> to <i>E<sub>rr</sub></i>) is passed to the
consumer.</li></ul>
The new state is shown in column H.</li>
<li>The stack is now empty. The FlatteningPathIterator will fetch the
next segment from the base iterator, and process it.</li>
</ol>
<p>In order to split the most recently pushed segment, the
<code>subdivideQuadratic()</code> method passes <code>stack</code>
directly to
<code>QuadCurve2D.subdivide(double[],int,double[],int,double[],int)</code>.
Because the stack grows towards the beginning of the array, no data
needs to be copied around: <code>subdivide</code> will directly store
the result into the stack, which will have the contents shown to the
right.</p>
</body>
</html>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.2 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.6 KiB

View File

@ -1,46 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.imageio.event package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.imageio.event</title></head>
<body>
<p></p>
</body>
</html>

View File

@ -1,46 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.imageio.metadata package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.imageio.metadata</title></head>
<body>
<p></p>
</body>
</html>

View File

@ -1,46 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.imageio package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.imageio</title></head>
<body>
<p></p>
</body>
</html>

View File

@ -1,46 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.imageio.spi package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.imageio.spi</title></head>
<body>
<p></p>
</body>
</html>

View File

@ -1,46 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!-- package.html - describes classes in javax.imageio.stream package.
Copyright (C) 2004 Free Software Foundation, Inc.
This file is part of GNU Classpath.
GNU Classpath is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
any later version.
GNU Classpath is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Classpath; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Linking this library statically or dynamically with other modules is
making a combined work based on this library. Thus, the terms and
conditions of the GNU General Public License cover the whole
combination.
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under
terms of your choice, provided that you also meet, for each linked
independent module, the terms and conditions of the license of that
module. An independent module is a module which is not derived from
or based on this library. If you modify this library, you may extend
this exception to your version of the library, but you are not
obligated to do so. If you do not wish to do so, delete this
exception statement from your version. -->
<html>
<head><title>GNU Classpath - javax.imageio.stream</title></head>
<body>
<p></p>
</body>
</html>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.3 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.9 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.3 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.4 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 454 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 857 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.1 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 7.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 1.8 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 6.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.6 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.5 KiB

View File

@ -1,57 +0,0 @@
<body>
<div>
This package provides type mappings between XML and Java data types.
</div>
<table summary='XML Schema type mappings'>
<tr>
<th>XML Schema data type</th><th>Java data type</th>
</tr>
<tr>
<td>xs:date</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:dateTime</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:duration</td><td><a href='Duration.html'>Duration</a></td>
</tr>
<tr>
<td>xs:gDay</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:gMonth</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:gMonthDay</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:gYear</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:gYearMonth</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
<tr>
<td>xs:time</td><td><a href='XMLGregorianCalendar.html'>XMLGregorianCalendar</a></td>
</tr>
</table>
<table summary='XPath 2.0 data type mappings'>
<tr>
<th>XPath 2.0 data type</th><th>Java data type</th>
</tr>
<tr>
<td>xdt:dayTimeDuration</td><td><a href='Duration.html'>Duration</a></td>
</tr>
<tr>
<td>xdt:yearMonthDuration</td><td><a href='Duration.html'>Duration</a></td>
</tr>
</table>
<div>
Other XML Schema data types are considered to have a <q>natural</q> mapping to
Java types, which are defined by the Java Architecture for XML Binding (JAXB).
</div>
</body>

View File

@ -1,9 +0,0 @@
<html>
<body>
<div>
<a href='http://www.w3.org/TR/REC-xml-names'>XML Namespace</a> processing.
</div>
</body>
</html>

View File

@ -1,16 +0,0 @@
<html><head>javax.xml.parsers</head><body>
<p>Bootstrapping APIs for JAXP parsers.
This is the first portable API defined for bootstrapping DOM.
<p>JAXP parsers bootstrap in two stages.
First is getting a factory, and configuring it.
Second is asking that factory for a parser.
<p>The SAX bootstrapping support corresponds to functionality
found in the <em>org.xml.sax.helpers</em> package, except
that it uses the JAXP two stage bootstrap paradigm and
that the parser that's bootstrapped is normally wrapping
a SAX parser rather than exposing it for direct use.
</body></html>

View File

@ -1,5 +0,0 @@
<html><head>trax for dom</head><body>
<p>Support for DOM inputs and outputs to transformers.
</body></html>

View File

@ -1,38 +0,0 @@
<html><head>trax </head><body>
<p>Base "TRAX" API for XSLT transformers.
This API borrows many structural notions from SAX,
such as the way error handling and external entity
resolution are handled, although it does not reuse
the corresponding SAX classes.
To use XSLT transformers: <ul>
<li>Start with <em>TransformerFactory.newInstance()</em>;
<li>Then you may wish to configure that factory through
its features and properties. This includes modifying
the way errors are handled and URIs are resolved.
<li>Then you have several options for how to perform
the XSLT transformations. One generic option is to ask the
factory for a <a href="Transformer.html">Transformer</a>
and then use <em>Transformer.transform()</em> to pull
input text onto output text.
<li>Alternatively, most factories support flexible integration
with SAX event streams. You can cast such factories to a
<a href="sax/SAXTransformerFactory.html">SAXTransformerFactory</a>
and perform either push or pull mode transformations.
</ul>
<p>The <a href="OutputKeys.html">OutputKeys</a> class
holds constants that can be used to configure output
properties used with <em>Result</em> objects, as if
they were specified in <em>xslt:output</em> attributes
in the stylesheet specifying the transform.
<p>The <a href="Templates.html">Templates</a> class
accomodates the notion of "compiled" transforms.
</body></html>

View File

@ -1,9 +0,0 @@
<html><head>trax for sax</head><body>
<p>Support for SAX2-based XSLT transformers.
Normally you would cast a TransformerFactory to a
<a href="SAXTransformerFactory.html">SAXTransformerFactory</a>
and use that to in any of the various modes supported
(such as push or pull).
</body></html>

View File

@ -1,6 +0,0 @@
<html><head>trax for streams</head><body>
<p>Support for text stream inputs and outputs to transformers.
</body></html>

View File

@ -1,9 +0,0 @@
<html>
<body>
<div>
API for the validation of XML documents using a range of schema languages.
</div>
</body>
</html>

View File

@ -1,9 +0,0 @@
<html>
<body>
<div>
This package provides access to an XPath evaluation environment and expressions.
</div>
</body>
</html>