Created attachment 151787 [details] The DOCX file which has the problem Step to reproduce: 1. Download the font "TH Sarabun New" from [1]. The font is licensed under GPL 2.0 + font exception. 2. Open the attached DOCX document. The text is configured to use "TH Sarabun New" as the complex (Thai) font, and "Liberation Sans" as the western font. Both of them are 16 pt. Expectation: The Thai text (the word "ไทย") and most of the dots (".") are displayed using "TH Sarabun New", while the English text (the word "English") and the dots between the pipes ("|", including the pipes themselves) are displayed using "Liberation Sans". The whole text is fit within one line. MS Word 2019 shows this expected behavior. (See the screenshots.) Actual result: The Thai text is displayed using "TH Sarabun New", while the English text, all dots, and the pipes are displayed using "Liberation Sans". The whole text is not fit within one line. The problem is reproducible on: - LO 6.0.7-0ubuntu0.18.04.6 from Ubuntu 18.04. - LO 6.2.4.2 on Ubuntu 18.04, Snap and AppImage. - LO 6.2.4.2 on Windows 10 version 1903 (build 18326.86) The reason this is important is that most of the Thai fonts use the different font metrics then western fonts. For historical reason [2], Thai fonts consider that point-size means "line-height". As Thai symbols contain the symbol above and below the character, Thai fonts are usually 30% smaller than western fonts at the same point-size. [3] Adding to this problem, MS Word considers the language of the text using the keyboard layout when it's typed, not actual text. For example, typing a dot (".") while using a Thai keyboard layout will make that dot Thai while typing a dot while using an English keyboard layout will make that dot English. MS Word seems to record this information in the file, which LO seems to be unable to read. So, when LO opens the file, LO displays the text using the wrong font with different font metric, causing the document's layout to changes. [1] http://mdresearch.kku.ac.th/files/font/THSarabunNew.zip [2] http://thep.blogspot.com/2016/02/thai-font-metrics.html (In Thai) [3] However, some Thai fonts, mostly fonts from Thai Linux Working Group (TLWG), now uses the new metric which considers point-size to be character size. This makes those fonts have the same size as western fonts. See [2].
Created attachment 151788 [details] All screenshots from MS Office 2019 and LibreOffice 6.4.2.4
Hello Ratchanan, Thank you for reporting the bug. I can confirm that the bug is present in master. Version: 6.3.0.0.alpha1+ Build ID: 77ae0abe21f672cf4b7d2e069f1d40d20edc49a7 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-31_15:33:33 Locale: en-GB (en_GB.utf8); UI-Language: en-US Calc: threaded
I remember seeing the same document in another report. Where did you get it from ?
(In reply to Xisco Faulí from comment #3) > I remember seeing the same document in another report. > Where did you get it from ? I didn't take it from anywhere. I created it by myself.
I'm assuming keyword bibisectRequest was added by mistake, if not, please readd with explanation.
repro 7.5+ and also true for DOC format. writerfilter/source/dmapper/DomainMapper.cxx: case NS_ooxml::LN_CT_Fonts_hint : /* assigns script type to ambiguous characters, values can be: NS_ooxml::LN_Value_ST_Hint_default NS_ooxml::LN_Value_ST_Hint_eastAsia NS_ooxml::LN_Value_ST_Hint_cs */ //TODO: unsupported?
Dear Ratchanan Srirattanamet, 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
This issue still persists in LibreOffice version: Version: 24.2.4.2 (X86_64) Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.9; UI render: default; VCL: kf6 (cairo+wayland) Locale: th-TH (th_TH.UTF-8); UI: en-US Calc: threaded