Steps to reproduce: 1. Open attached file 2. Check left textbox on first page Observed behaviour: it overlaps the horizontal line Reproduced in Version: 5.4.0.0.alpha0+ Build ID: 7c11fe076005ed4e28f04f14990b7011a03a4517 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Textbox's position was fixed in commit author Justin Luth <justin_luth@sil.org> 2016-12-31 14:45:50 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2017-01-18 09:05:28 (GMT) commit 441d7e046df36900bbf14b37277b15d615f67641 (patch) tree 05df1fb77bab72e79abbf4674198be59b80a8c23 parent b7388a7483da5cffdc4eef6c0474b98c9e5f5af0 (diff) tdf#35021 TabOverMargin: support LEFT tabs also however, the wrong position was introduced again by: author Justin Luth <justin_luth@sil.org> 2017-03-30 09:48:18 (GMT) committer Justin Luth <justin_luth@sil.org> 2017-03-31 06:01:18 (GMT) commit 5251e7988a3bb1cfccff54eccf7fdd7621c4627c (patch) tree 510f6e717921f96c89c1e4debc9397258ee0bef8 parent 4a58754714c4e570f68b31a1926c7de6feb48cc2 (diff) tdf#106701 tabOverMargin: only affect specified tabstops, not autotab Bisected with bibisect-linux-64-5.4 Adding Cc: to Justin Luth
Created attachment 132889 [details] sample file
Created attachment 132890 [details] sample 2 another file affected by the same commit
Created attachment 132895 [details] sample3
Comment 2: 2nd_quarter-2010(1).docx: Although the horizontal line (a border line connected to heading 4 style) appears to be better placed, the address itself is worse (not centered because it is now wrapping around the picture because it is one line too close now. I'd probably blame most of this text height problem on the use of MS Trebuchant font. [Current master is the better rendering if you compare tab positions. I don't think the textbox position itself ever changes - only the text above it.] Comment 3: Virkamatka_anomus(1).doc: The header contains lots of spurious tabs with paragraph style puv-Date defining the tabstop at 6.3in. Using Word2013 to saveas .docx (to remove the password protection) results in a two-page document with a large header - similar to how it appears in LibreOffice. [hard to fully evaluate a locked document] Comment 4: Zurb Mozilla SOW #6.docx: Payment title inside the table - in MSWord some extra words are hidden because a 2.5in tabstop pushes them beyond the end of the cell (hiding "Due Date" and another "Payment"). [very badly designed document still doesn't look the same in master, hard to say what is more correct.] In all of these documents, some aspect just happens to look better with the first patch as a side effect. None of these intentionally use a left-tab-over-margin.
Created attachment 133100 [details] tdf35021_tabOverMarginDemo2.doc: Left tab_over_margin paragraph shouldn't wrap
Created attachment 133101 [details] tdf35021_tabOverMarginDemo2.pdf: from MS Word All of these documents exhibit poor design and display the caveat mentioned in https://cgit.freedesktop.org/libreoffice/core/commit/?id=a9367c1b39600d5a5e2d0067113f06ad59cc37a1 "CAVEAT: Basically all of this stuff tricks the layout engine, so the amount of text allowed on a single line is still "controlled" by the right margin. So, even though the extended line could theoretically be very long, the amount of text still must fit within the limits set by the right margin. Thus large margins [or lots of text after the tab] may cause wrapping in LibreOffice, instead of disappearing off of the end of the paper as it does in MSWord, and editing the text might get confusing - which matches the experience in MSWord." In simpler terms, MS Word never wraps tab_over_margin paragraphs - they just disappear off the end of the page (or cell) on a single line.
Dear Xisco Faulí, 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
*** Bug 40787 has been marked as a duplicate of this bug. ***
*** Bug 99735 has been marked as a duplicate of this bug. ***
from bug 40787#c13 attachment 90834 [details] test document from 2013 situation... with various examples where tabs are shown at end of line/character in Writer and not in Word Only when there is a tab setting at the right margin and the alignment of that tab is left, the superfluous tab characters are not shown
It is probably worth noting that bug 142404 indicates that this behaves VERY differently in Word 2013+ (DOCX). So the value of putting effort into solving this bug just decreased dramatically since most documents created in the past 10 years won't run into this particular form of weirdness.
Dear Xisco Faulí, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug