Robin Laing wrote:
How does Writer know that I want this paragraph to be a hanging indent
and that text to be subscript? Something is telling it that this needs
to be done to be displayed at that point.
I have never looked at the content.xml before but taking a look at a
simple sample of the content.xml, I see that there are xml control codes
within the document.
For underline, there is
<text:span text:style-name="T1">s a</text:span>
For bold.
<text:span text:style-name="T2">different</text:span>
For hanging indent.
<text:p text:style-name="Hanging_20_indent">{a bunch of text}<text:p
text:style-name="Hanging_20_indent"/>
This looks like an expanded version of reveal codes to me. The problem
is T1 and T2 don't mean anything and are not listed in the styles
menus. I do see that T1 - T5 are defined at the beginning of the
content.xml file.
Styles such as T1, T2 and so forth are defined in any OOo Content.xml
I've looked at, if they exist. They are invented styles based on any
direct formatting in the document. For example, if the user applies
italics to some text through direct formatting, OOo Writer, on saving,
will create a T-something style with the attribute "italic" and the code
will use it in the places where the user has directly applied the italic
attribute to text.
You should find their definitions somewhere in content.xlm before they
are actually used.
In the content.xml, things look pretty linear to me.
Yes, the source code is linear and the actual text in memory is linear,
in that it proceeds from beginning to end, at least if you look at it in
that fashion. How it is stored is another matter but is irrelevant to
higher level examination, just as you don't care exactly which blocks of
a disk are used by a file and in what order they are used.
But in memory the sections of text are resolved into objects with
various formatting attributes based on the tags and the tags themselves
utterly vanish.
A partial picture of the paragraph object (at one level) can be seen at
http://api.openoffice.org/docs/common/ref/com/sun/star/text/Paragraph.html
You can drill down through the Services and Interfaces to get a more
detailed view. For example, double-clicking on
::com::sun::star::style::ParagraphProperties brings you to
http://api.openoffice.org/docs/common/ref/com/sun/star/style/ParagraphProperties.html
The system knows what styles to apply because the corresponding
properties are set within the paragraph object. The Writer interface
Format -> Paragraph provides direct access to most of these attributes.
The attributes you see when you look at the current definitions in the
paragraph formatting dialog box are the attributes applied to the
paragraph structure in memory. It's one to one. That is what is in
memory and you can directly see those properties in the dialog box and
use it to change those properties. There's nothing else to see, no code
tokens.
A concrete example: in text stream processing one might have a token at
some point in the stream setting line spacing to 14 points and at a
later point another token setting it to 17 points. But in OpenOffice
there are no tokens. One sets the line spacing as one of the paragraph
attributes. There is no code token. There is nothing to reveal beyond
what Format -> Paragraph shows you.
Besides having style attributes, a paragraph contains "text portions"
which can be discovered through
::com::sun::star::container::XEnumerationAccess , a general process for
gaining access to objects within objects. For text portions see
http://api.openoffice.org/docs/common/ref/com/sun/star/text/TextPortion.html#TextPortionType
Text portions looked at from another viewpoint are text ranges, each
text range with its own set of character formatting attributes. See
http://api.openoffice.org/docs/common/ref/com/sun/star/text/TextRange.html
Go down one level through ::com::sun::star::style::CharacterProperties
to
http://api.openoffice.org/docs/common/ref/com/sun/star/style/CharacterProperties.html
and you get the various character properties such as font name, font
size, bolding, italics, and various character effects that are applied
to that text range. Again there are no codes. The system keeps track of
where one text range starts and another stops. When, for example, a user
applies bolding to the last word of an unbolded text range, that text
range is split into two text ranges, one with bolding on and one with
bolding off. But no code tokens are inserted.
Note that the text itself need not actually be moved and probably isn't.
There is only a difference in the list or range indicators.
The Reveal Codes macro emulates a possible interface using code tokens
that would produce the same results ... just as saving to .doc or .odt
or .rtf format produces a linear representation also using tagged text.
But while tagged text actually exists within memory when using
WordPerfect, that is not the case with OOo Writer (or with MS Word).
Instead OOo Writer (and MS Word) has objects with properties.
I guess I like the idea of just looking at my text an knowing what is
happening and where it changes. In a test I ran on Friday, I somehow
changed the format of a piece of text and I couldn't get it to change
back. No matter what I did, it wouldn't change back. Even trying to
over type it was no good.
I also like the idea of actually seeing what is happening at a lower level.
Which is why I and others in this discussion would like a map like
Navigator or a structure browser or something of that kind as a
debugging tool to allow a clearer picture of what occurs when direct
formatting is applied. If you are using character styles, you can see
when a character style changes through the Stylist, when the active
character styles changes.
But direct formatting on top of this text confuses things.
It would be nice to have a paragraph map indicating the actual text
ranges and the differences between adjoining ranges as well as any
differences between the attributes of the ranges and the attributes of
the characters styles applied at a lower level. Click on a paragraph,
for example, and get a table showing differences of properties between
the basic paragraph style and the paragraph as actually formatted. Click
on a text range, and get a table showing all differences between the
underling paragraph character style, the second level applied character
styles, and any direct formatting.
One reason to use styles in OOo Writer, rather than direct formatting,
is that currently debugging is much easier. You only have to deal with
style attributes applied to text and you can easily see what paragraph
style and what formatting style is applied at the current cursor
position and see by examining those styles what attributes are set for
the text you are interested in.
The Reveal Codes macro is of sometimes of help here. But apparently it
didn't help you with whatever your problem you had, whether the same you
mentioned below, or a different one.
With the debugging tools, it would be nice to know how a cell in a table
converts all the text to vertical on an imported document and how to get
that format to be changed. None of the settings I could find in any of
the menu would change the contents to normal. Nothing at all. It was
as if the cell was only allowing text to be one character wide. With
RC, I could have deleted the offending codes directly and cleared up the
problem.
If you mean that the text was vertically stacked like
t
h
i
s
, I haven't a clue. I would like to be able to do this in Writer. It can
be done in Calc. But the only way I can think to do this in OOo Writer
would be to follow each character with a line break or paragraph break.
I presume you checked for that. If the characters were also rotated,
that would be normal enough, though not being unable to change this.
I see what you mean about immediately jumping to Reveal Codes if such a
thing happened in Word Perfect, where even if you did not understand
what was going on, you could at least remove code tokens that might be
causing the problem and just see what happens.
But since in OpenOffice.org there are almost no control code tokens,
this can't be done. The internal structuring is layered, with effects
such as rotation and text direction applied to text ranges as attributes
rather than being turned on and off and on by tokens in a text stream.
What you can do, and what I would do in such a situation, is to use
Sift-CTRL-Space (Format -> Default Formatting) to remove any direct
formatting. If that didn't fix it, then it should have to be a setting
in Format -> Paragraph or in the Table -> Table Properties.... If that
fails, then we may be dealing with an undocumented attribute.
I encountered things like that years ago when I used to convert
WordPerfect files to MS Word and on occasion the converted document
would act very strangely, with attributes fixed that should be
changeable, or odd losses of text or duplications of text, as though the
conversion routine had created incorrect values in some properties.
What you might have tried (and perhaps you did) is copying and pasting
the table elsewhere in the document and trying different options of
paste special. That might have lost the impossible formatting. Also, you
can paste a section of a document directly into an OOo HTML document,
and then look at it in HTML source mode to see what HTML coding OOo
Writer then produces from its internal structure.
But remember that this coding does not reflect how things are actually
being managed internally.
Jallan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
