Description: LibreOffice seems to render certain Unicode line drawing characters improperly. This text: │ │ │ │ │ │ │ │ │ │ │ │ ┝━━┿━━┷━━━━━━━━┷━━━━━┯━━┷━━━━━┷━━━━━━━━┷┯━━━━┷━━━━━┷━━━━━┷━┯━━━━━━┷━━━━━┥ │ │ │ │ │ │ uses these characters to form the heavy horizontal line: U+2501 horizontal heavy U+2525 vertical light left heavy U+251D vertical light right heavy U+2537 horizontal heavy up light U+252F horizontal heavy down light U+253F horizontal heavy vertical light When the text is displayed by cat, vi, or the text editor joe, it is fine. When it is displayed or printed with LibreOffice, it is not fine. Steps to Reproduce: 1.Select the line drawing text in the description box above 2.Insert it into a LibreOffice text document 3.Observe the skewed lines that don't match up properly Actual Results: See attachment Expected Results: See attachment Reproducible: Always User Profile Reset: No Additional Info: Version: 5.4.3.2 Build ID: 1:5.4.3~rc2-0ubuntu0.16.04.1~lo1 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Created attachment 137724 [details] PDF showing expected display and actual display by LibreOffice
Created attachment 137725 [details] Correct display of line drawing Unicode characters by cat
Created attachment 137726 [details] Incorrect display of line drawing Unicode characters by LibreOffice
Yeah. It kind of depends on the zoom level. With an old version like 3.3, at some zoom level it appears correct. Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 17cfe6e25d479428de308c22fcd218dcf8827840 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 15th 2017
** 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
I confirm the bug! I confirm that a) different zoom-level and b) different fonts, lead to different results but each wrong. my system, Version: 6.1.4.2 Build ID: 6.1.4-4 CPU threads: 4; OS: Linux 4.20; UI render: default; VCL: gtk3; Locale: it-IT (en_GB.UTF-8); Calc: group threaded
Dear Roger House, 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
Also in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: a09c5c69e3b5fbf448cae1d6c476f39067e40023 CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Hold on! By definition the line-drawing art require use of a fixed-width non-proportional font. Also, the font must have pretty much complete coverage of the Unicode 2500-257F "Box Drawing" chart [1] or unexpected font fall back will occur and where the layout is certain to be disrupted. Using MS Consolas, or DejaVu Sans Mono, both of which are complete for the Box Drawing Unicode block will render the box drawing correctly at any font size. Liberation Mono is incomplete, and fall back distorts the line work. Likewise Courier Mono, or Noto Mono. Verify coverage of the Unicode 2500-257F Box Drawing block and select appropriate font. LibreOffice renders correctly to canvas. Nothing to do with Zoom level when the font has the codepoints covered. And only the fallback font is affected by zoom of canvas. =-ref-= [1] https://www.unicode.org/charts/PDF/U2500.pdf