McLauchlan, Kevin wrote:
Twayne [mailto:twa...@twaynesdomain.com] noted:
In news:4c0572d0.8090...@gmail.com,
JOE Conner <joeconner2...@gmail.com> typed:
On 6/1/2010 10:52 AM, Twayne wrote:
I don't know if this will help anyone or not, but I had
some success in figuring out the how/why of OO.o 3.2.2
screwing up images in large documents
SNIP>>
descriptions. Of course, duplicate my
claims on your own before entering a new issue too.
HTH,
Twayne`
I wonder, how are you anchoring the images? To page? Paragraph?
Character?
Joe Conner, Poulsbo, WA USA
Thanks Joe; I know what you're about here. In Word I have the images
anchored to the paragraphs the images occur in. When OO.o
opens the Word
document, the anchors often move. Usually they've moved up
and to the left.
When I look in Writer at the anchors, they've oten move up a
paragarph is
have been changed to anchored to a letter. If one screws up,
they almost all
get screwed up throughout the document.
Regardless of the anchoring situation OO.o requires, it
should be able to
determine them from the Word doc that it opens. I no longer
recall how
small, but a small document doesn't have issues with the
images; I'd have to
look it up from 2.x. And these are only 20 to 30 Meg files,
so they aren't
really all that large, even considering they'e zips.
I can't tell with my meager tools, but it sounds like a
buffer problem to
me of some kind. It's a really annoying issue. I've read that
documents
created from scratch in OO.o don't have this problem but I
don't know that
for a fact.
HTH,
Twayne`
With OOo 2.x (back in the day), I opened some Word docs
that were 200-page to 400-page manuals. Some had tons of
graphics. Some had tons of tables, or lots of lo-o-o-ong
multi-page tables.
Some had both graphic items (photos, drawings, screen-caps)
and tables, along with all the text.
Graphics would do as you describe, _especially_ if they
were in table cells. Tables would set their own margins,
usually out to the left of the page margin (nothing like
they had in the Word source document). Tables that
extended past a single page would often break strangely,
entirely independently of dialog settings. It would not
be unusual for a table to skip a page when it needed
a break (leaving the page blank), no matter what I did
with break settings for the table or the paragraph styles
of the cell text (number of lines, number of rows, keep
with next, etc.).
If a table had (say) an illustration or photo in each
of several cells (down a column - one column was the
graphic, the column beside it was the descriptions or
comments explaining each graphic item), then any of
several operations would cause all (or some) of the
illustrations/graphics to leave their cells and jump
to another location, where they'd pile up.
I took days, weeks fiddling. Sometimes I'd seem to
have some success, but it wasn't consistent and I
could never count on it. The most reliable was to go
to the piled-up stack of pics, select one, copy it,
go to the cell where I wanted it to live, click the
empty Cell-content paragraph and paste.
Mostly, they'd stay put, if I did that. Prior to
that, I'd tried capturing each drawing/photo/dialog
with SnagIt, saving to an external .png file, then
Insert picture > from file (to match the process
that I use with new pics in new documents). That
would seem to work, until the table wanted to re-flow,
and then some-or-all the graphic items would run away
from their cells and pile up in a corner again.
Eventually, I published using Word, then went back
to OOo (with my deadline safely behind me) and
basically constructed the documents from "scratch"
in OOo. That is, I'd bring in big mounds of text,
via Notepad - not directly from a Word file - paste
and format. That wasn't too bad for sections of
paragraphs, but it was horrendously tedious for
tables and for formatted API stuff in programmers
manuals.
A couple of years later, I tried a similar import
of a big-ish Word document into OOo 3.1... same
problems as before. Same solution. Build it over
in OOo.
Fortunately, I've pretty much run out of hefty old
Word documents inherited from another writer -
at least, until we buy another company and I
inherit _their_ product docs...
FWIW, aside from just a determination to use OOo
instead of the MS product (kinda Quixotic given
that I work mostly on Windows XP...), my motivation
to migrate was that the Word documents had been a
mish-mash of styles, spot-formatting, and other sins
due to multiple authors and tinkerers.
But at least in Word, pictures stayed where you
put them. Must be something about the import /
open-word-file-in-OOo process that breaks... since
forever.
All of that to say, you are not alone.
- K
Definitely not alone -- and totally native OOo documents can't be
exempted, at least in 3.1.1 on VistaHP. I recently had a project with
tables, each of which had text and a graphic (pasted into the cell).
They've definitely liked to move, not consistently but fairly
frequently. All had the same anchoring. but only some had problems. I'd
close the document after saving it when it looked fine, and on
reopening, some of the cell contents would have slid down as if that
cell were using vertical centering instead of vertical top. I found that
if I temporarily added a row to the table above the problem area start,
then deleted the row, things would go back to normal.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@openoffice.org
For additional commands, e-mail: users-h...@openoffice.org
