(In reply to Robert Markowitz from comment #0) > Shortest bug report ever! :-) Robert: Please provide some more information about this problem (and perhaps include an example file), then change status back to UNCONFIRMED. Thanks!
Created attachment 111293 [details] Business Cards in a 2 column table The attached is a two column table of business cards. When I try to open it in Libre Office only the left column contains data. The right column is blank. It should be the same as the left column giving me 10 business cards in total.
Comment on attachment 111293 [details] Business Cards in a 2 column table fix mimetype
(In reply to Robert Markowitz from comment #2) > > The attached is a two column table of business cards. When I try to open it > in Libre Office only the left column contains data. The right column is > blank. It should be the same as the left column giving me 10 business cards > in total. Hi Robert, The layout of the given document does look a little off when I test in a 4.5 (master) build. Could you please attach a screenshot of how the document appears in MS-Word? Thanks! (change status back to UNCONFIRMED after you attach the file, please) Status -> NEEDINFO
Created attachment 111299 [details] Screen Shot from Word 2010
Created attachment 111300 [details] Screen Shot from Libre Office I have attached screenshots of the file from both Word 2010 (my wife's computer), and Libre Office (my computer). Hope this helps.
(In reply to Robert Markowitz from comment #5) > Created attachment 111299 [details] > Screen Shot from Word 2010 (In reply to Robert Markowitz from comment #6) > Created attachment 111300 [details] > Screen Shot from Libre Office Yes, I CONFIRM that the screenshot in LibreOffice looks similar to the layout I saw in LO 4.5 (master), and that the overall layout looks very different in Word 2010. Status -> NEW
I'm not sure where that leaves us. Is it my problem or yours? If it's mine what do I need to do to fix it?
(In reply to Robert Markowitz from comment #8) > I'm not sure where that leaves us. Is it my problem or yours? If it's mine > what do I need to do to fix it? Robert: My guess is that there is a layout issue in the way that we interpret this document in LibreOffice, and a developer will hopefully find time soon to look at the results of your tests and see what we need to do to more faithfully recreate the same layout. It's possible that the fonts used in the document have some impact on the layout. Could you please try using one of the fonts that we ship with LibreOffice in the docx ? (e.g. Liberation Serif). I'd be interested to see if that helps to harmonize layout between Writer and Word.
Created attachment 111433 [details] Half Calibri Light and Half original fonts I changed the font on the upper half (okay 60%) to Calibri Light which is in the list of fonts supported by Libre Office. As you can see, it didn't help.
As you can see, it's been about three months and there doesn't seem to have been any activity at all on this problem. Is there any chance of getting it resolved? Thanks,
(In reply to Robert Markowitz from comment #11) > As you can see, it's been about three months and there doesn't seem to have > been any activity at all on this problem. Is there any chance of getting it > resolved? Developers decide how to prioritize their own time re: when particular bugs get fixed, so I'm not exactly sure when one of them will take a look at this particular bug report. If this behavior is a regression (and used to work correctly), please do let us know more about which versions had the correct behavior. This will make it much easier for us to track down when we introduced the bad behavior.
This appears to have had better layout before the below commit. Adding Cc: to cedric.bosdonnat@free.fr; Could you possibly take a look at this one? Thanks commit 0f581ab761cefde208e576661850b57f2846fdb4 Author: Cédric Bosdonnat <cedric.bosdonnat@free.fr> Date: Mon Sep 24 18:01:05 2012 +0200 n#779627: VML: import mso-position-vertical:center and friends This allows to properly position objects that are vertically and/or horizontally centered relatively to the page. Change-Id: I1f7e78c5b828679817cdfc72e4d90a0850b242fa
Created attachment 118017 [details] Libreoffice 5.0.0.5 This issue is still reproducible with Libreoffice 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: es-ES (es_ES). Besides, right colored dots aren't displayed in this version as in previous ones.
This issue is still present in Version: 5.1.0.0.alpha1+ Build ID: e6fade1ce133039d28369751b77ac8faff6e40cb TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-16_00:12:42 Locale: es-ES (es_ES) on Window 7
Migrating Whiteboard tags to Keywords: (bibisected, filter:docx) [NinjaEdit]
This issue is still present in Version: 5.4.0.0.alpha0+ Build ID: 33f5bc54aaa7fe7aa9335726e30f9c349155e04d CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-12-01_23:21:05 Locale: nl-NL (nl_NL); Calc: CL
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Don't know why this is assigned back to me. I provided all information up front and 2 1/2 years later it's still not fixed. Don't know anything more that I can do.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is still a problem in 6.2 master, images anchored in table cells use document margin, not cell margin to establish their placement (or something like that). A very problematic and regression-prone area to dabble in...
As you can see from the history, I notified you of this problem 5 years ago. I've received occasional comments in technical jargon that I don't understand. Frankly, I've given up on you guys altogether. Since it looks like the subject may now be resurrected, can someone tell me, in English, exactly what the status is, and if there is any hope of it getting resolved? You have to remember that you may all be techies and understand your correspondence, but you made the product available to the public. Therefore, you should be able to discuss problems with your public in a jargon free manner.
Bakos Attila committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10f29d8bf05d44ca8bc11d34d1294ec17f8ac0f1 tdf#87569 tdf#109411 DOCX import: fix shape anchor in tables It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 156685 [details] ScreenchotOfTheSampleFileBeforeAndAfterThePatch
(In reply to Robert Markowitz from comment #22) > As you can see from the history, I notified you of this problem 5 years ago. > I've received occasional comments in technical jargon that I don't > understand. Frankly, I've given up on you guys altogether. > > Since it looks like the subject may now be resurrected, can someone tell me, > in English, exactly what the status is, and if there is any hope of it > getting resolved? > > You have to remember that you may all be techies and understand your > correspondence, but you made the product available to the public. Therefore, > you should be able to discuss problems with your public in a jargon free > manner. Hello, I try to describe the problem with jargon-free: In the document what you have uploaded, the objects (the textboxes, shapes, pictures, etc.) have the setting in Word, to be positioned to the page what the LibreOffice done. However, the Word in spite of the setting, positioned the objects from the cells, so that is why the two program rendered differently the file. Now, with the patch, the objects -- if they are have this setting and they are in a table too -- are positioned to the cell instead of page. This will be avialable in the 6.5 and maybe in the 6.4 releases, so if you download the latest test version the 6.5, you can test it if you want. I hope I helped a bit. :)
Verified in Version: 6.5.0.0.alpha0+ Build ID: dee81fb2e1df5091702b3c8b0e4a3f2b58e89291 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Bakos Attila, thanks for fixing this issue!!
(In reply to Xisco Faulí from comment #27) > Verified in > > Version: 6.5.0.0.alpha0+ > Build ID: dee81fb2e1df5091702b3c8b0e4a3f2b58e89291 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > @Bakos Attila, thanks for fixing this issue!! Thanks for verifing it!
Bakos Attila committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/b83d394a16a9a93b314f20ea8fb2ccbb99d9d07f tdf#87569 tdf#109411 DOCX import: fix shape anchor in tables It will be available in 6.4.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.