> I have been wondering a long time why it didn't come to the Swing
> developers to include the same clone/copy portion-extraction methods in
> the document interface as in the String class (does a "public Document
> subDocument(int offs, int len)" method seem to far-fetched?).
The whole document / styled text stuff was bolted onto Swing in a hurry.
As fare as it can be traced these are the remains of the Sun HotJava
browser product.
The API is bad. Swing's typical Model/View architecture is not used,
instead the Document class has been thrown in as the model part. The
documentation is non-existing, and the stuff hasn't been brought up to
date in ages (e.g. HTML 4.0 support or non-nonsense RTF support).
> All we
> have is getText() which very inconveniently returns a String and
> nothing else. Too bad if you want to keep the styled text, not to
> mention other element types that you may have had in the original
> document, the only portion of your Document you'll ever get is plain
> ASCII, oh I mean Unicode.
Not exactly. You can obtain the corresponding Element of a character,
and you can obtain the attributes of that Element. You can also get the
Style (which is just a particular attribute set).
Granted, all this is a big mess, and you probably have to write a bunch
of ugly code to get what you want. However, I don't think it is impossible.
> If anybody has had to face that problem and has somehow found a way
> around it, I'd be both grateful and curious to hear about his/her
> solution.
An intensive study of the Element class and function might be in order.
For a long term solution you might want to waste^Wspend your time on
dealing with one or both of these:
http://jcp.org/
http://developer.java.sun.com/developer/bugParade/
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
supaiku@web.de - 17 Feb 2005 14:43 GMT
First, many thanks for the answer Thomas.
> The API is bad. Swing's typical Model/View architecture is not used,
> instead the Document class has been thrown in as the model part. The
> documentation is non-existing, and the stuff hasn't been brought up to
> date in ages (e.g. HTML 4.0 support or non-nonsense RTF support).
Wow. Sounds like they shouldn't be too proud of that. The Document
interface is the whole foundation of the swing.text package.
> Not exactly. You can obtain the corresponding Element of a character,
> and you can obtain the attributes of that Element. You can also get the
> Style (which is just a particular attribute set).
You mean by going through the whole Element tree?
But even by doing that, I wonder how I can neatly extract a portion of
the Document (and get another Document of course). I can get Glyphs,
Sections, Paragraphs or the whole thing but I can't get a specific
segment of a Document from one offset to another. Methods to create a
Document from scratch out of self-constructed Elements are scarcely
available (the Element interface only has getter methods). And since
Element doesn't implement Cloneable either I can't even copy them!
> Granted, all this is a big mess, and you probably have to write a bunch
> of ugly code to get what you want. However, I don't think it is impossible.
How about using the EditorKit's write and read methods to copy the
Document using heavy Input and OutputStreams? Or is there a more
inefficient way of doing it?
> An intensive study of the Element class and function might be in order.
> For a long term solution you might want to waste^Wspend your time on
> dealing with one or both of these:
I went there and checked their RFE's. Doesn't seem like it's in there.
I'm not sure if my posting a request will jolt them out of their
inertia and prompt them to redesign the whole Document model.
About cramming my head with Element specifications and the other crap,
I've already perused the Swing book I work with but low-level Document
creation was not really addressed. Maybe because it's all f.cked up.
Thomas Weidenfeller - 17 Feb 2005 16:26 GMT
> You mean by going through the whole Element tree?
> But even by doing that, I wonder how I can neatly extract a portion of
[quoted text clipped - 4 lines]
> available (the Element interface only has getter methods). And since
> Element doesn't implement Cloneable either I can't even copy them!
Copying Elements doesn't help much, because there is no general way to
insert an Element. HTMLDocument has something, but the StyledDocument
interface doesn't require such a method. As an extra "bonus" some
Element implementations in the package aren't public, so you can't
construct them manually for some data.
If I have understood the whole mess correctly (and it is a long time ago
since I looked at it in detail), then Elements are automatically created
and inserted when you add characters with attributes to a document. So
you don't need the elements, you need the attributes.
E.g. (not checked, will not compile):
class Segment {
String text;
AttributeSet attr;
};
int start = ... // Text start pos/offset in document
int len = ... // length of text segment
ArrayList segments = new ArrayList();
DefaultStyledDocument d = ...;
int pos = start;
while(pos < (start + len)) {
Segment s = new Segment();
Element e = getCharacterElement(pos);
pos = e.getEndOffset();
s.text = // copy substring out of document
s.attr = e.getAttributes();
segments.add(s);
}
> How about using the EditorKit's write and read methods to copy the
> Document using heavy Input and OutputStreams? Or is there a more
> inefficient way of doing it?
If I remember correctly, StyledEditorKit doesn't implement the
read/write methods in a useful way. You just get the text portion out of
that class and lose all style information :-(. Subclasses might have
working implementations.
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
supaiku@web.de - 18 Feb 2005 01:40 GMT
Thanks for the reply again and your attempt to shed some light on this
mess.
> If I have understood the whole mess correctly (and it is a long time ago
> since I looked at it in detail), then Elements are automatically created
> and inserted when you add characters with attributes to a document. So
> you don't need the elements, you need the attributes.
Seems like it, yes. Even when you insert icons or components via the
JTextPane they are associated to a character in the Document as
attributes.
>E.g. (not checked, will not compile):
[code example]
What you're trying to do is get the character and attribute data from
subsequent leaf elements and then build segments with the same data,
right?
Actually there is a Segment class in the swing text package, which I'm
sure you know, but it doesn't contain any style attribute.
Thomas Weidenfeller - 18 Feb 2005 08:26 GMT
> What you're trying to do is get the character and attribute data from
> subsequent leaf elements and then build segments with the same data,
> right?
> Actually there is a Segment class in the swing text package, which I'm
> sure you know, but it doesn't contain any style attribute.
I didn't know there is a Segment class. I just happen to call my class
Segment. What I wanted to show was how to get text and the associated
attributes from a particular offset in a document. Then one could use a
second loop (which I didn't show), to insert these segments in a fresh
document. The possible result (if I have understood the Document mess
more or less correctly) should be a "sub document" of the original one.
That's what you asked for, didn't you?
I think it is high time that you start to write your own code to figure
out how/if thinks work in reality.
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
supaiku@web.de - 18 Feb 2005 10:02 GMT
> I didn't know there is a Segment class. I just happen to call my class
> Segment. What I wanted to show was how to get text and the associated
> attributes from a particular offset in a document. Then one could use a
> second loop (which I didn't show), to insert these segments in a fresh
> document. The possible result (if I have understood the Document mess
> more or less correctly) should be a "sub document" of the original one.
> That's what you asked for, didn't you?
Yes, and I'm still at a loss as to how this can be done. Even if I can
retrieve the element/attribute structure between pos and length by
keeping the original parent-child structure (which is not done in your
code) how do I recreate a new document after that is beyond me.
> I think it is high time that you start to write your own code to figure
> out how/if thinks work in reality.
Well, do you think I'm waiting for you answers all day by repeatedly
checking the group and doing nothing else? I have tried various stuff,
including messing with the JTextPane, the editorkits and the views but
unfortunately to no avail.