Hi Andy,
First, I want to thank you for taking the time to study my example.
In a message dated 2009.11.06 21:47 -0500, Andy wrote:
In going over your file I found out several things.
1: That at least one, the first one, had two frames. That one had the
"To Frame" option available for Anchor.
Nice catch on the two frames! Now that you mention that, I think that
must have happened when, while attempting to edit (as opposed to insert)
the caption, I hit "Caption" in the context menu - but it happened to be
the context menu for the frame rather than for the picture. The result
must have been that Writer helpfully provided yet another (outer) frame
to enclose the first frame and caption, just as the first frame was
automatically provided to enclose the picture and its caption. [Now
then: It seems that Writer should provide a way to simple way to remove
excess frames without removing their contents, shouldn't it?]
IAC, not only does the picture have a "To Frame" anchor option (where
"To Frame" refers to the inner frame), but the inner frame also has a
"To Frame" anchor option (where "To Frame" refers to the outer frame).
2: The second graphic did not have any frame but some how had a "caption".
Yeah, isn't that neat? ;-) I could not figure out that, either, but
since then have been studying Andrew Pitonyak's macro to remove frames
from pictures, to try to understand how that might have happened.
3: Several, including the first, had the "Frame" anchored to the left
margin but the graphic was located in in different places across the page.
Well, for the first picture, the *inner* frame (that I did not realize
was there) is anchored Left(Paragraph_area), while the *outer* frame
(that I knew about) is anchored Right(Paragraph_area). Obviously the
outer frame controls placement; apparently the inner frame does nothing.
4: Thanks to the comment from TomW, I found out the strangest thing.
Double clicking on the graphic to get the properties, most of the ones
with the "To Frame" option have the 'Horizontal' setting 'From Left'.
Changing this to 'Left' and closing the properties window removed the
"To Frame" option. Changing the 'Horizontal' back did not have the
reverse effect though.
Yes! That setting is state-dependent - *not* a good thing. The only way
to restore the "To Frame" option is to Undo back to that point (or wipe
it out and start over). That is clearly a bug [but at least now I have
some thoughts about it, below] - and unfortunately not a small one.
5: For at least the first graphic, the 'Horizontal' setting 'Right'.
Changing the 'Horizontal' setting has no effect on the "To Frame"
option. Where this is because of the two frames I do not know.
See my comment above about the inner and outer frames, of which only the
outer has effect.
6: The real kicker, so far, is that I have not found anyone that can
give me any reason for the issue we are discussing. While researching
this I was looking over the "Working with Graphics" doc you referred to,
in the process I found two graphics that fit this issue. The difference
being that both have the same settings, 'Horizontal' setting 'Center'.
Changing the 'Horizontal' setting then closing the property window
removes the "To Frame" option.
You mean "two graphics" in my paper? If so, which ones? - "fit this
issue" how?
IAC, I think the reason is elusive because the design is not well
reasoned, and the lack of conceptual clarity has spawned bugs. I don't
blame the Writer Guide for not picking up on that, because it's a bigger
issue than documentation.
I now realize that to begin the analysis we have to return to what, in
my original post, I called the "bonus question":
since Writer believes that a picture with caption is lost without a
frame (and thus supplies one automatically), why would the picture
ever *not* be anchored to the frame?
Or, put another way: Once Writer puts a frame around picture and caption
to keep them together, why doesn't the focus of "Anchor" move completely
from the picture to the frame?
That's the first question that the conceptual design seems to not ask,
let alone answer.
The next basic question is about the anchor domain, once you get outside
the frame. Those eight choices:
{ "Paragraph area" | "Paragraph text area"
"Left paragraph border" | "Right paragraph border"
"Left page border" | "Right page border"
"Entire page" | "Page text area" }.
[expressed more compactly as
{Paragraph|Page}{Area{All|Text}|Border{Left|Right}}]
have a basic conceptual flaw: "Area" is 2-dimensional (or, within a
horizontal line, 1-dimensional), while "Border" is 1-dimensional (or,
within a horizontal line, 0-dimensional). "Border" is not an
independent entity from "Area"; on the contrary, "Paragraph area" is
bounded by the paragraph borders, and "Page area" is bounded by the page
borders. because the selection set is not orthogonal, the model doesn't
compute; it runs into problems.
So we should begin by eliminating something. I would remove the
"border" domain options, reducing the selection domains to "Page" and
"Paragraph" (eliminating the word "area", which is conceptually
redundant). Then we could make design sense of the four position states
{"Left"|"Right"|"Center"|"From left"}, and in the process make this
anchoring business less buggy and more comprehensible.
Thanks again for thinking about this. Now, how do we get it corrected?...
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.org
For additional commands, e-mail: users-h...@openoffice.org
