When i say "Line" i mean the "Line" tool from the drawing toolbar (also applies to TextBox tool from that toolbar). Bug (1) Page border width is in "pt", one pt is 0.352(7)mm. Minimal border width is 0.05pt (0.017635 mm). Border width granularity is 0.01pt. Maximal border width is 9pt (3.175mm). Line width is in "cm", one cm is 10mm. Minimal line width is 0.01cm (0.1mm). Line width granularity is 0.01cm (0.1mm). Maximal line width is freaking big. Meaning that: A) it's very difficult to make the line width to be visibly equal to the page border width, unless you choose a very specific size (like, 2.83pt page border and, accordingly, 0.01cm line) B) page borders can be much thinner than lines could ever be C) lines can be much thicker than page borders could ever be Bug (2) Actual page border is drawn *inward* from the logical page border. Actual line is drawn *through* the logical line. This is obvious if you make really thick 9pt page border (say, 2cm space from the left edge of the page) and then look at the horizontal ruler. The ruler will tell you that the left edge of the thick black line of the border is exactly 2cm away from the edge. At the same time, if you create a line, set its PositionAndSize to be 2cm ToTheLeft from the EntirePage, you'll see that the line center is 2cm away, not its left edge. Obviously, this is preferred behaviour for lines (as lines have no inherent "inward" or "outward" edge). However, this also applies to the TextBox tool. Text boxes *do* have inward and outward edges. Tables also have inward and outward edges, *and* their borders are defined as page borders - in pt, up to 9.00pt. However, table borders are drawn like lines - squarely through the logical border, so that half the width is on one side, and the other half is on the other side. Possible fixes: For (1) - Allow lines/borders to be defined in pt/cm respectively, with the granularity and maximal width changed to match For (2) - Add inward/outward/centered property to each line (for lines inward would be right, outward would be left, relative to the direction of the line; for textboxes it's obvious; defaults to centered). Add inward/outward/centered property to page/table borders (defaults to inward for pages, centered for tables). Use-case: i want to place a textbox at the edge of my page and align it with the page border. That has proven to be very difficult, because of the border/line width discrepancy and because textbox line is drawn through the textbox logical border while page border line is drawn along its inward logical edge. When exported to PDF, i can clearly see that the box and the page borders are not aligned (i would assume that printing it on paper wouldn't change anything). This applies to both 5.2.0.0.alpha0 and 5.0.4.2.
Sounds fair, so setting to NEW.
** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
LibreOffice Version: 5.3.1.2 (x64) Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU Threads: 8; OS Version: Windows 6.19 The bug is present. Nothing is changed, as far as i can see.
There are multiple problems in one issue. That cannot be handles properly. I suggest to focus on entering border width and to change the subject accordingly. Reasoning: The text box, which you get by the T icon in the toolbar is a drawing object. All drawing objects have line and fill properties. The "line" in a drawing object is represented by a draw:stroke attribute in file format. Your observation is correct, that it is symmetric to its logical position. I see no chance to change it, especially as it is the same behavior as in SVG. The border of a page or of a table cell is represented by fo:border attributes in file format. Tables have a special feature to collapse the borders of adjacent cells. In case that is not enabled, the borders of cells are inside the cell, so that the width of the paragraph area = cell-width minus border-widths minus padding-widths. For pages you get similar: width of page-content = page-width minus border-width minus padding-width. I think, that this behavior is correct. The fact, that the value for the border-width cannot be entered in cm or mm or others, is indeed a problem. That is not covered by file format and a shortcoming of LibreOffice.
Dear LRN, 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://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
Dear LRN, 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