Jallan wrote:
Robin Laing wrote:
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.
Yes the definitions are at the beginning of content.xml. If you make
a change, the T(numbers) will change to remain linear.
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.
This is where things could be fun. There are tags that indicate all
the formatting for that section in memory. Why can't that formatting
information be displayed on an editable pop-up. Or at least be able
to be marked when View > Non Printing Characters is selected?
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.
But there are style tokens that are used to tell writer how to format
the document. I have not seen the styles box change with some of the
text I selected. Of course I wasn't looking for it in the past. I
was looking at the status bar.
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.
But there are style tokens inserted and the remainder are renumbered.
I tried this on a test document and examined the content.xml.
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.
A structure map, to me is very similar to Reveal Codes in that if your
cursor is at a set location, you would know what is happening. It
would be a decent tool for debugging. As the properties such as
{com.sun.star.style.CharacterProperties} are in memory, then they
could be displayed. And if I had a way of showing where there were
formatting changes as with non-printing characters, then it would
provide a tool to find those troublesome properties. This is what I
see as Reveal Codes.
But direct formatting on top of this text confuses things.
>
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.
The macro doesn't allow editing of the properties. It is only a
display from what I have been able to get it to do. Also it won't
allow scrolling through a document. At least I have not been able to
get to work that way.
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
That is what it did. I tried everything and I could not get it to
change the formatting.
, 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 tried everything I could think of. Nothing worked. OOo 2.0
imported the document differently than 1.4.
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.
I agree but if there was a decent indication as you suggested, it
would have pointed me in the correct direction.
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.
Ah, more time, more time. I need more time. :) I never have enough
time. It is quicker to grab the file and find a unused Win computer
to make the necessary changes.
But remember that this coding does not reflect how things are actually
being managed internally.
Jallan
--
Robin Laing
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
