The Swing JEditorPane text component supports different kinds
of content via a plug-in mechanism called an EditorKit. Because
HTML is a very popular format of content, some support is provided
by default. The default support is provided by this class, which
supports HTML version 3.2 (with some extensions), and is migrating
toward version 4.0.
The <applet> tag is not supported, but some support is provided
for the <object> tag.
There are several goals of the HTML EditorKit provided, that have
an effect upon the way that html is modeled. These
have influenced its design in a substantial way.
It might seem fairly obvious that a plug-in for JEditorPane
should provide editing support, but that fact has several
design considerations. There are a substantial number of html
documents that don't properly conform to an html specification.
These must be normalized somewhat into a correct form if one
is to edit them. Additionally, users don't like to be presented
with an excessive amount of structure editing, so using traditional
text editing gestures is preferred over using the html structure
exactly as defined in the html document.
The modeling of html is provided by the class HTMLDocument.
It's documention describes the details of how the html is modeled.
The editing support leverages heavily off of the text package.
To maximize the usefulness of this kit, a great deal of effort
has gone into making it extendable. These are some of the
The parser is replacable. The default parser is the Hot Java
parser which is DTD based. A different DTD can be used, or an
entirely different parser can be used. To change the parser,
reimplement the getParser method. The default parser is
dynamically loaded when first asked for, so the class files
will never be loaded if an alternative parser is used. The
default parser is in a seperate package called parser below
The parser drives the ParserCallback, which is provided by
HTMLDocument. To change the callback, subclass HTMLDocument
and reimplement the createDefaultDocument method to return
document that produces a different reader. The reader controls
how the document is structured. Although the Document provides
HTML support by default, there is nothing preventing support of
non-html tags that result in alternative element structures.
The default view of the models are provided as a hierarchy of
View implementations, so one can easily customize how a particular
element is displayed or add capabilities for new kinds of elements
by providing new View implementations. The default set of views
are provided by the HTMLFactory class. This can
be easily changed by subclassing or replacing the HTMLFactory
and reimplementing the getViewFactory method to return the alternative
The View implementations work primarily off of CSS attributes,
which are kept in the views. This makes it possible to have
multiple views mapped over the same model that appear substantially
different. This can be especially useful for printing. For
most html attributes, the html attributes are converted to css
attributes for display. This helps make the View implementations
more general purpose
Larger documents involve a lot of parsing and take some time
to load. By default, this kit produces documents that will be
loaded asynchronously if loaded using JEditorPane.setPage.
This is controlled by a property on the document. The method
be overriden to change this. The batching of work is done
by the HTMLDocument.HTMLReader class. The actual
work is done by the DefaultStyledDocument and
AbstractDocument classes in the text package.
Customization from current LAF
HTML provides a well known set of features without exactly
specifying the display characteristics. Swing has a theme
mechanism for its look-and-feel implementations. It is desirable
for the look-and-feel to feed display characteristics into the
HTML views. An user with poor vision for example would want
high contrast and larger than typical fonts.
The support for this is provided by the StyleSheet
class. The presentation of the HTML can be heavily influenced
by the setting of the StyleSheet property on the EditorKit.
An EditorKit has the ability to be read and save documents.
It is generally the most pleasing to users if there is no loss
of data between the two operation. The policy of the HTMLEditorKit
will be to store things not recognized or not necessarily visible
so they can be subsequently written out. The model of the html document
should therefore contain all information discovered while reading the
document. This is constrained in some ways by the need to support
editing (i.e. incorrect documents sometimes must be normalized).
The guiding principle is that information shouldn't be lost, but
some might be synthesized to produce a more correct model or it might
Inserts content from the given stream. If doc is
an instance of HTMLDocument, this will read
html 3.2 text. Inserting html into a non-empty document must be inside
the body Element, if you do not insert into the body an exception will
be thrown. When inserting into a non-empty document all tags outside
of the body (head, title) will be dropped.
Set the set of styles to be used to render the various
html elements. These styles are specified in terms of
css specifications. Each document produced by the kit
will have a copy of the sheet which it can add the
document specific styles to. By default, the StyleSheet
specified is shared by all HTMLEditorKit instances.
This should be reimplemented to provide a finer granularity
Copies the key/values in elements AttributeSet into
set. This does not copy component, icon, or element
names attributes. Subclasses may wish to refine what is and what
isn't copied here. But be sure to first remove all the attributes that
are in set.
This is called anytime the caret moves over a different location.
Fetch the parser to use for reading html streams.
This can be reimplemented to provide a different
parser. The default implementation is loaded dynamically
to avoid the overhead of loading the default parser if
it's not used. The default parser is the HotJava parser
using an html 3.2 dtd.
Submit a bug or feature Java, Java 2D, and JDBC are a trademarks or registered trademarks of Sun Microsystems, Inc. in the US and other countries. Copyright 1993-1999 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California, 94303, U.S.A. All Rights Reserved.