In news:[email protected], Barbara Duprey <[email protected]> typed: > Twayne wrote: >> In news:[email protected], >> Barbara Duprey <[email protected]> typed: >> >>> McLauchlan, Kevin wrote: >>> >>>> Twayne [mailto:[email protected]] noted: >>>> >>>> >>>> >>>>> In news:[email protected], >>>>> JOE Conner <[email protected]> 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` >>>>> >>>>> >>>> <snip> >>>> >>>> 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` > > My "problem child" is a 1.6M file -- 15 pages, each with a > 5-column table containing a header row and 5 picture rows. > Above each picture is a line of text. Apparently just > reopening an existing file goes through repagination, for > some reason. Yes, I sure hope this issue gets some > attention. Do you think there's any point in opening an > issue, or would it just be closed as a duplicate? (I'm sure > there must be at least one out there already!)
IMO it might make it if if were phrased properly and concisely detailed, not sure. The hardest part is probably the research to find anything similar is already submitted and accurate - it's over a year since I've had anything to do with the issues sytem. Perhaps if it were tied tothe repagination process as that's a new revelatioin, at last to me. I suspect pagination of causing other things too, like the jumping cursor and not going back to where it originally was, and a couple other things I can't think of right now. If it relocates the cursor, then it could relocate images, I'd assume. I also noticed that captions also follow the right image when they get relocated - maybe that's due to anchoring, I don't know right now; it just occurred to me. Probably the worst part of getting them to look at this is I've never found a pattern to be able to predict when or if it may or may not act up. Like your example; I'd have predicted iit would be OK based on the infor you provided but it's getting toward the border line of the file sizes I've experienced it on. Good luck, Twayne --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
