In news:4c06da92.2070...@onr.com, Barbara Duprey <b...@onr.com> typed: > 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.
Close to the same thing here; only if I delete the row added after pasting in the image, it more often than not jumps up and left of the table again! It seems to need/want that first line/s every time in a cell. You also have to have at least one para mark on a blank line after any text above it or it'll shove part of the text partly to the bottom. Using pic Layout shoots the image right back out of the cell again, but always up and left; never down as you mentioned. And the stupid anchor still sits there in the cell! Grrrrr! But if I break the problem documents into multiple documents, a lot of those problems will mysteriously "go away" and everything will jump right back to where it belongs. it seems that repagination is the event during which the misalignments happen, but only in a "too long" document, whatever that might be. It appears to be between 20 to 30 Meg mostly. But that makes for a LOT of darned documents when I started out with only one in Word. I maybe could live with it if the limit was around 100K, but not 25k. I'm hoping the PTB might be taking notice of this thread. Thanks for your comments. Cheers, Twayne` --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@openoffice.org For additional commands, e-mail: users-h...@openoffice.org
