Created attachment 58510 [details] Screenshots after and before resizing the image. When resizing an image anchored as character, the paragraph below it does not come up following the new size of the image. Steps to reproduce: 1. Open a new document in Writer. 2. Type some text, and press Enter (new line). 3. Insert a picture. 4. Anchor this picture as character (right-click on the image > Anchor > As character). 5. Click on the right side of the image to put the cursor after it. 6. Type some text on a new paragraph (press Enter before). 7. Now, resize down the image. What occurs: - The paragraph below the image does not follow the new size of the image. Expected behavior: - The paragraph should come up, following the image's new size. Screenshot attached. Tested on LibreOffice 3.5.0 and 3.5.1. Windows 7 32-bits SP1. Core 2 Duo E6400, 3GB RAM. (Sorry for my bad english.)
One detail more: If you save the file, close it and reopen it, Writer then adjust the paragraph's position correctly. But if you resize the image again, the bug persists.
This bug doesn't affect LibreOffice 3.4 (at least not 3.4.5).
Very old Bug in Master branch, already visible in 3.5 Master in July 2011 Still a problem with parallel installation of "LOdev 3.5.2rc0+ [Build ID: ec752de-73cb0b8-f269e46] Win-x86@6-fast pull time 2012-03-19 11:08:23 – WIN7 Home Premium (64bit)
[Reproducible] with LibreOffice 3.5.1.2 (Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66) running on MacOS X 10.6.8, using the steps given in original description. The result is exactly the same as Josiasmat's screenshot shows. Changed Platform from 'Windows' to 'All' because the bug is also present on MacOS. (Could someone try on some Linux variant, please?) Not a critical bug, but a very annoying (and ridiculous) one.
[reproductible] on all platforms, windows x64 and ubuntu linux amd64, for both 3.5 and 3.5.1. It is important for large documents (phd. thesis, in my case) where resize an image, make a lot of work for repagination.
@Silviu Berbinschi The Platform fild normally will be ignored. Please do not do useless Status field modifications
[ people pls try to become heroes in writing clear summaries :-) ] Hmm, I cannot reproduce this in 3.4.6, 3,5,2rc1 nd in buld from master. All on Ubuntu. Will attach sample document. Josias, can you pls retry / provide a test document ? thanks! - Cor
Created attachment 58871 [details] test document with image anchored as character
Created attachment 58875 [details] Sample Document showing problem @Cor Nouws: Indeed, with your sample I can not see the problem. Attached Document shows the problem. I created my document exactly followint reporter's steps.
(In reply to comment #9) > Created attachment 58875 [details] > Sample Document showing problem Cannot download it for some reason. Mind to send it directly to me pls :-)
(In reply to comment #9) > Created attachment 58875 [details] > Sample Document showing problem > > @Cor Nouws: > Indeed, with your sample I can not see the problem. Attached Document shows the > problem. > I created my document exactly followint reporter's steps. It depends if there is some text on the line before the picture. In the doc sample from Cor, if you remove the words "Aap noot " before the picture, then you can reproduce the bug. Best regards. JBF
Why Platform = "Windows"? The bug is also present on MacOS X, see my comment #4. Therefore, changed Platform back to "All", to prevent the (wrong) assumption this was a Windows-only bug.
(In reply to comment #11) > It depends if there is some text on the line before the picture. In the doc > sample from Cor, if you remove the words "Aap noot " before the picture, then > you can reproduce the bug. And I thought I had tried that too :-) Apparently there was a single space in front of the image at that moment. Simple work arounds, will not be a wide spread use case, so I remove this one from the most annoying container issue.
<http://wiki.documentfoundation.org/BugReport_Details#Version> The problem is not limited to pictures, same with DRAW objects, OLE objects, Fontwork, ..., see attached "newsample3.ods" @Cor: I can't see a workaround, and I do not believe that "will not be a wide spread use case". Since I started to use OOo I read "use "Anchor as character to avoid problems", and now users have these problems ... @Michael: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Created attachment 58902 [details] New Sample Document 3 See Comment 14
(In reply to comment #14) > <http://wiki.documentfoundation.org/BugReport_Details#Version> > > > The problem is not limited to pictures, same with DRAW objects, OLE objects, > Fontwork, ..., see attached "newsample3.ods" > > @Cor: > I can't see a workaround, and I do not believe that "will not be a wide spread > use case". Since I started to use OOo I read "use "Anchor as character to avoid > problems", and now users have these problems ... > > @Michael: > Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept > this Bug The workaround is to add a space (or any text) after the object, thus the position of the rest of the text is updated. But evidently not everyone is readying this bug report, thus not everyone will know this workaround, so I believe this is yes a very annoying bug for who have to deal with a lot of images, graphs, objects... in a document. I myself discovered the bug when I was writing a tutorial with images, and at the moment I've not figured out the workaround, so I restarted Writer every time I wanted to see things in their proper places. Excuse me for saying this, but I think this is the kind of bug that makes one consider going back to M$ Word.
(In reply to comment #16) > Excuse me for saying this, but I think this is the kind of bug that makes one > consider going back to M$ Word. I'm sorry, but I agree with you. I'm a ten years OOo power user, I created an Italian newsgroup for OOo and derivative many years ago, but I sadly can't use LibO for productive use. It's a real pain for hits bugs and erratic behavior, and I receive a lot of complaints.
Added this bug again to our meta bug 37361 - "LibreOffice 3.5 most annoying bugs", convinced by the comments of Rainer, Josiasmat, and Vitriol. Especially I have to agree to Rainer's statement that this could be a rather wide spread problem, and it is this kind of problem which is very frustrating for many users (cf. Vitriol's last comment).
@Cor: Yes, of course, the space will do the job, but think that it's a makeshift, not an acceptable workaround (for someone who wrote a dissertation and now has to add 500 spaces for his picture size fine tuning ...). Let's be generous with the MAB tag. But of course I agree, we should avoid making more or less every bug a MAB.
hi all, Ah well, sorry if I misinterpertred the severity for many people. Sometimes I just happen to think to simple ;-) No objection from me for MAB then of course.
(In reply to comment #16) > Excuse me for saying this, but I think this is the kind of bug that makes one > consider going back to M$ Word. I so aggree to this. Our company has been using (or at least trying to use) OO/LibO for several years now for a few . Everytime we try to update and spread a new version regression bugs like this keep us from doing so. You guys should really handle regressions more serious to be honest.
Yet another attempt to fix the headline/summary spelling ... (it’s ‘shrinking’, not ‘schrinking’, a spelling that looks rather German to me ;-)
Not a major bug.
(In reply to comment #23) > Not a major bug. ROTFL. No comment...
Hi, same problem here with LibreOffice 3.5.3 under Linux. this bug is indeed very annoying : dealing with technical documents, we insert a lot of images and we often resize these images. The workaround is not easy to find, and I'd not discover it without this bug report. So, please fix this annoying bug... RB
*** Bug 51056 has been marked as a duplicate of this bug. ***
*** Bug 51211 has been marked as a duplicate of this bug. ***
Any updates on this? This bug keeps our company from using the latest version of LibO. I mean this bug has been around for like 4 months and is one of the most annoying when working with larger documents with lots of pictures in them and all pictures are anchored as characters.
If a bug fits into the “3.5 most annyoing bugs” list, we do not want it on the 3.6 MAB list, please see https://wiki.documentfoundation.org/Most_Annoying_Bugs
Instead of changing version numbers or removing it from a MAB list or whatever (since that's all you've been doing in about 7 months the bug exists) you should like put the effort into fixing it maybe. I really can't believe this bug has not been able to get fixed in almost 7 months of time. I'm sorry to say, but people already posted exact reproduction information and even workarounds for it and still the bug status is NEW and all you've been doing is 'move' it around and mess with the bug infos for your MAB list and stuff. Sorry if this sounds harsh, but that's the way most people probably feel about this and as far as I can tell our company (although we would really like to) will not upgrade any further than LibO 3.4. Kind of sad isn't it? And by the way, this bug still exists in 3.6.x so the bug report version has to be set to that AFAIK, doesn't it? MAB list and bug report version are kind of different things. PS: If this doesn't belong here, I'm sorry, but this is still the place which is ignored least usually.
*** Bug 51825 has been marked as a duplicate of this bug. ***
Hi, (In reply to comment #30) > Instead of changing version numbers or removing it from a MAB list or > whatever (since that's all you've been doing in about 7 months the bug > exists) you should like put the effort into fixing it maybe. Please try to be kind for the people putting effort in helping with bug triage. It's a lot of work. And important, to reduce the change that bugs are not getting the attention they deserve. (And then still, alas, it's sometimes long to wait, we/I know that.) And people doing bug triage, mostly are not working in the code. > And by the way, this bug still exists in 3.6.x so the bug report version has > to be set to that AFAIK, doesn't it? MAB list and bug report version are > kind of different things. People doing bug triage know how this must be handled. You can find it on the QA wiki too. http://wiki.documentfoundation.org/QA#How_to_participate Regards - Cor
I've talked with one of the devs. It would be helpsome if we could really narrow down the time-frame in which the issue was introduced in the code. Without having looked myself (running...) : from comment #2 we know that is was OK in 3.4.5 So it must have been introduced in one of the commits in master, that did not make it to 3.4.x... Is there maybe someone under the readers who happens to have some developer snapshot/daily build from the period July 2011 end December 2011 ? Would be usefull if we could test with versions from then. Cheers,
(In reply to comment #33) Due to Comment 3 the Bug has been introduced before 2011-August. Unfortunately I can not contribute exact pull date of my most early available Version for a test: Already [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" from (July 2011?) The most early hit in Bugzilla for that version is 2011-08-02 06:33:08 UTC
(In reply to comment #32) > Please try to be kind for the people putting effort in helping with bug > triage. It's a lot of work. And important, to reduce the change that bugs > are not getting the attention they deserve. (And then still, alas, it's > sometimes long to wait, we/I know that.) > And people doing bug triage, mostly are not working in the code. Hi, I'm sorry if it sounded too harsh, I had a bad day there. I don't have any snapshots/dailies from there AFAIK (gotta look again), but I can tell for sure that the bug is not in 3.4.6 either, since that's the version we are currently running. Hope it helps a bit at least.
Thanks Rainer, hitec, And the oldest 35master daily build I have hanging around here is 35913b9-4eb4f62-260b7c1 from August 19 2011. In which the bug is present. So no possibility here now, to narrow the time frame a bit more, alas. I guess there are no archives with daily builds ? The first possible date for the builds to check, should be just after the '3.4 branch point' ( which I cannot get clear from http://cgit.freedesktop.org/libreoffice/core/refs/tags )
Does anybody know where the bibisect builds start? Due to Bug 45183 3.5.0 Beta3 is included, but that's too late.
*** Bug 56186 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Does anybody know where the bibisect builds start? Due to Bug 45183 3.5.0 > Beta3 is included, but that's too late. Hi Rainer, I learned from Bjoern that it is indeed from that time. So too late to hunt this specific bug. And archives with daily builds ... nope. But ...
@ dear_developers that are going to look at this issue: note that somewhere in the comments (#11) it is noticed that the bug only occures with the image at the start of a line. When there is text in front of the immage, it does shrink as expected. I hope this helps.
Created attachment 73923 [details] Sample document with formula
[Reproducible] with "LibreOffice 3.6.4.3 - Build ID: 2ef5aff" - Windows 7 (64 bit) for formulas (see sample)
Same with LibreOffice 3.6.5.2 (Build ID: 5b93205)
Reproduced: Version 4.1.0.0.alpha0+ (Build ID: 80cbc04c2cbe25ebdfe2f22bb2e5ba62728e963) Bodhi Linux +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Moving to 3.6 MAB as 3.5 has come to EOL and we are closing the meta bug tracker for 3.5 MAB.
Reproduced on LibreOffice 4.0.0.3, running on Windows 7 x64.
Please do not change version: https://wiki.documentfoundation.org/BugReport_Details#Version
*** Bug 62777 has been marked as a duplicate of this bug. ***
Comment on attachment 58871 [details] test document with image anchored as character according to comment #9 this bugdoc does not actually cause the bug, marking obsolete
this regression was introduced between OOo 3.3 and OOo 3.4 beta and imported from there into LO.
*** Bug 48498 has been marked as a duplicate of this bug. ***
Additional info concerning formula objects: "Bug 48498 - Incorrect distance to following contents after formula object anchored as character changes height" with LibO 3.5.1 showed a phenomenon what was not reproducible with the most objects, but is shown in "Sample document with formula" 2013-01-30 12:30 UTC: With formula objects there also is a problem with INCREASING height, see <https://bugs.freedesktop.org/show_bug.cgi?id=48498#c4>. Although that problem looks similar and also appeared with 3.5, that problem seems to be different, I can't reproduce it with LibO 3.6.6.2, while the original problem reported here persists with 3.6.6.2.. The "increase formula height problem" seems unrelated.
*** Bug 64474 has been marked as a duplicate of this bug. ***
*** Bug 64684 has been marked as a duplicate of this bug. ***
*** Bug 64732 has been marked as a duplicate of this bug. ***
*** Bug 64944 has been marked as a duplicate of this bug. ***
was introduced by: CWS sw34bf05 commit c5a8a2c3cbcee0175127a0662e3d820ea4deea22
*** Bug 65104 has been marked as a duplicate of this bug. ***
*** Bug 56749 has been marked as a duplicate of this bug. ***
*** Bug 46463 has been marked as a duplicate of this bug. ***
confirmed in LibO 4.0.4 and 4.1.0 (Win7 64bit) moving it to mab4.0 vs. mab3.6 because 3.6 has reached EOL so we are in the process of closing the meta bug.
confirmed in libreoffice 4.0.4.2 on Ubuntu 12.04 LTS. my workaroud is to cut the image, and immediately paste it in again.
*** Bug 69844 has been marked as a duplicate of this bug. ***
*** Bug 52428 has been marked as a duplicate of this bug. ***
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
Just proposed a fix as https://gerrit.libreoffice.org/#/c/8606/ which is just partially reverting the commit identified in comment 54. That commit claims to fix a layout loop from i#84870, however opening the test document on master and 4.1.4 release builds still (or again) loops. So partially reverting the change that didnt fix its issue should do no harm and at least heal this regression. i#84870 needs a proper fix, not this stacking of workarounds, it seems.
(In reply to comment #65) I filed Bug 76219 to reflect the i#84870 state. Actually, it *was* fixed in one LO release (3.5.2.2), and *is* fixed in AOO.
Bjoern Michaelsen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=72a4987434368bfb0b15f5ebb70a52108d349d5f fdo#47355: partially revert c5a8a2c3cbcee0175127a0662e3d820ea4deea22 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Bjoern Michaelsen committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a54da6a84f751250c694120d1a29aaac89cd3af4&h=libreoffice-4-2 fdo#47355: partially revert c5a8a2c3cbcee0175127a0662e3d820ea4deea22 It will be available in LibreOffice 4.2.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Confirmed fixed in Master version: 4.3.0.0.alpha0+ Build ID: 55211e612d2cbed03dd81c039d07ea4e936c2804 on openSuSE 12.3 (64-bit)
*** Bug 46902 has been marked as a duplicate of this bug. ***
*** Bug 76615 has been marked as a duplicate of this bug. ***
*** Bug 77181 has been marked as a duplicate of this bug. ***
*** Bug 80287 has been marked as a duplicate of this bug. ***
Created attachment 114496 [details] Bug 47355 in LO Writer 4.4.0.3 Bug appears on page 8, second (lowest) image on the page: shrink it by dragging lower handles, text under it does not follow.
(My previous comment doesn't seem to appear, I copy it here:) I have this same problem in LibreOffice Writer Version: 4.4.0.3 See newly attached file, go to page 8, second (lower) image on the page. Shrink it by dragging one of the lower handles upwards, text under it will not follow.
(In reply to Bart from comment #75) The attachment 114496 [details] is OK. The behaviour of the abovementioned image is correct, as it is manually positioned (right-click->Image->Type->Position->Vertical: From bottom by 7.92 cm to Base line). Fixing the alignment (e.g. by right-clicking->Alignment->Base at Top) "fixes" the "problem".
https://www.jualtasmurahbbs.com/ tas murah berkualitas ransel korea tas ransel export tas ransel anak tas ransel keren tas ransel polo tas ransel wanita grosir tas murah online harga tas jual tas murah model terbaru terbaru category tas ransel wanita tas https://www.jualtasmurahbbs.com/category/tas-sekolah-anak/ jual tas anak sekolah laki maupun perempuan terbaru karakter anak yang lucu asli tanggulangin sidoarjo grosir karakter anak yang lucu grosir online taskulit karakter anak yang lucu asli tanggulangin sidoarjo pusat grosir https://www.jualtasmurahbbs.com/category/kipling/ tas kipling terbaru belanja grosir tas ransel wanita pusatnya tas online murah berkualitas merek travolt halaman web kami bfd pengiriman ke seluruh indonesia produktaslokalonline jual tas free gantungan monyet tas https://www.jualtasmurahbbs.com/category/tas-ransel-wanita/ tas ransel wanita tas murah harga terjangkau kualitas import kw super premium tas ysl sling bag tas bag murah marcellivo jual produk terbaru konveksi tas jual tas bag murah marcellivo tas bag murah aktifkan https://www.jualtasmurahbbs.com/category/tote-bag/ tote bag bandung membawa barang bawaan saat bepergian namun kini sudah dipakai oleh music bandeiger terbaru handbag handbag wanita handbag eiger handbag murah handbag polo handbag music band https://www.jualtasmurahbbs.com/category/cath-kidston/ grosir tas cath kidston bandung kerja wanita terbaru tas kantor tas kantor tl elle tas tambahan model jenis jual tas tambahan murah dan tas kantor mothercare jual tas tambahan murah bentukada berbagai macam wujud tas https://www.jualtasmurahbbs.com/category/anello/ tas anello bandung resmi tas kabizaku murah langsung pabrik dicari distributor tas batam kabizaku tiap kota hub pin bbm dcc toko dompet karawang alif tokodompetkarawang alif belanja tas jansport murah model https://www.jualtasmurahbbs.com/category/jansport/ jual tas jansport murah bandung konveksi tas tote pilot bag konveksi jakarta adalah konveksi tas terpercaya yang telah berpengalaman dalam fashion terkini tas berkualitas baik berupa tas souvenir sebagai cinderamata