Description: Text for arabic languages not recognized font Steps to Reproduce: 1. Ope sample document Actual Results: Check font not recognized Expected Results: Font recognized Reproducible: Always User Profile Reset: No Additional Info: Check in google docs is show correctly
Created attachment 152244 [details] Sample
Not correct bug report. Please explain from the beginning. You attached DOCX but saverd with LO? That's not acceptable, there must be source ODT. Better to include image in document than to say "Check in google docs".
Created attachment 152248 [details] Compare document in libreoffice and google docs Please see picture to see the libreoffice not set correct font and may be font size (need investigate)
Source document made in MS Office, and it must be show correct font. When i save as in ODT it is font Tahoma (lose origin name font)
[Automated Action] NeedInfo-To-Unconfirmed
Confirmed on Windows 10 Pro 64-bit en-US (1803) with Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded With sample OOXML open in Writer 6.2.4.2 and the Text box/frame held in the header.xml is selected, with text cursor focus into the text run--the Calibri font assigned in the style does not display. It was displaying through 6.2.3.1 on same system.
I can't reproduce it in Version: 6.4.0.0.alpha0+ Build ID: a294457eb95e60028539b6783abac78b56561fe2 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
nor in Version: 6.2.6.0.0+ Build ID: 1914932e2fd0598508823464765f3b1ac31236a1 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
oh wait, I need to select the textbox.. Also reproduced in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) and Versión: 4.4.0.3 Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Configuración regional: es_ES I don't think this is a regression... @V Stuart Foote, could you please doublecheck with 6.2.3.1 ?
(In reply to Xisco Faulí from comment #9) > > @V Stuart Foote, could you please doublecheck with 6.2.3.1 ? Hmmm, my mistake. I must not have been paying attention to where cursor focus was. Looking at it again (had already moved this system to 6.2.4.2, so working now in an /a parallel install of 6.2.3.1) with the text selected in the draw Frame in the document header--*there is no font identified* on this build as well--no Regression. The font displayed is some Windows system fallback for the Arabic script in the Draw shape text box. Unzipping the .docx, the documents app.xml shows it had been created with "LibreOfficeDev/6.3.0.0.beta1$Windows_X86_64 LibreOffice_project/a187af327633f5f00363be5131bd21a13e0f1a7b" Opening the header1.xml shows the object as a wordprocessingShape but with no Font assigned in line or via a style. And, when opening the LibreOffice generated.docx into Word 2016--the Shape as held in the header as a shortcut receives Calibri (Body) font assignment--so just MS Word having different fallback. Guess from OPs post, same happens in Google Docs. So is this legitimately a LO export filter mishandling?
I think we need more information here, as to me it is unclear what the font was in MS Office, how the document was created, which version of MS Office was used. Seven, could you please detail a step-by-step process that explains how we can reproduce this? Starting with creating the document in MS Office, which font you used, which format it is saved as, and what you expect the font field to show when you open the document in LibreOffice. When you said "When i save as in ODT it is font Tahoma (lose origin name font)", do you mean from MS Office? Is the file "Sample" saved from MS Office or LibreOffice? At least I can confirm that Google Docs sees the font as Calibri. Setting as NEEDINFO.
Dear seven, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear seven, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp