Description: When I install a font, and LibreOffice is open, LibreOffice become no responce. Steps to Reproduce: 1. Open LibreOffice 2. Create any of file from start center 3. Find, download & install any fonts from https://en.wikipedia.org/wiki/Free_software_Unicode_typefaces Actual Results: As description. Expected Results: When a new font is installed, LibreOffice should show a progress bar for such situation instead of no responce. Reproducible: Always User Profile Reset: No Additional Info: Version: 5.3.0.2 (x64) Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 布局引擎：新; Locale: zh-CN (zh_CN); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Hi Volga, I just installed all fonts from EBGaramond on Windows 7 Home. They are right away available into LibreOffice for work. Tried with 64 and 32 bits LibreOffice versions. Jacques
On Windows 10 Pro 64-bit en-US 12GB Ram, Intel i7-920 CPU with Version: 5.3.0.2 (x64) Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: en-US (en_US); Calc: group Confirmed while installing the Code2000 (v1.71, 7.99mb, 53,068 glyphs). LibreOffice canvas becomes unresponsive for about 10 seconds as this Unicode font is loaded. Other text applications (Wordpad, Notepad++) not similarly affected and keyboard entry and changes to document are not interrupted. However, installing a 50,000 glyph font is not a common occurrence--a 10 second pause while font is parsed into LibreOffice does not seem excessive. My copy of EB Garamond12-Regular (v.016, 483kb) has only 1958 glyphs, and I also have no noticeable delay as that font is installed. I don't see this as much of an issue. @Volga, please let us know your system specs (CPU & Ram), and which font and its glyph count you were installing.
Yes, currently I use LibO on Windows 10 Home 64-bit edition, 8GB RAM, Intel Core i53337U. I have installed Trad. Chinese Supplemental Fonts from Settings when I run LibO Writer, then Writer unresponsive several minutes. PS: There is an instruction how to install supplememtal fonts on Windows 10: https://answers.microsoft.com/en-us/windows/forum/windows_10-start/some-fonts-are-missing-after-upgrade/95839dfa-0df2-4bc0-875a-fd6b57e61fe4?page=1&auth=1 According to the answer the Trad Chinese Supplemental Fonts including DFKai-SB, MingLiU, MingLiU_HKSCS, PMingLiU, all of them are very large fonts.
Additionaly, when I install some non-CJK/Tangut fonts, LibO Writer seems no responce only a few time.
(In reply to Volga from comment #3) > Yes, currently I use LibO on Windows 10 Home 64-bit edition, 8GB RAM, Intel > Core i53337U. Errata: I use 4G RAM when I report.
Move this bug to bug 102985, since this bug is related to font loading when font installation is changed.
This problem affecting me again when I opened LibreOffice 6.0.2.1, and I try to install Open Sans. I suggest LibreOffice should showing notice at status bar during this work instead of being no responsive, then refresh font list after new fonts installed. Version: 6.0.2.1 (x64) Build ID：f7f06a8f319e4b62f9bc5095aa112a65d2f3ac89 CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; 区域语言：zh-CN (zh_CN); Calc: CL Steps to Reproduce: 1. Open LibreOffice 2. Open http://www.opensans.com/ 3. Download Open Sans and Open Sans Condensed zip packages 4. Drag all font files out from them, then drag into C:\Windows\Fonts Actual Results: LibreOffice no responced in 5 minutes.
This is still present in: 版本：6.1.0.2 (x64) Build ID：b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; 区域语言：zh-CN (zh_CN); Calc: group threaded However, I saw GIMP 2.10.4 release notes having the following announcement: “GIMP now performs the loading of fonts in a parallel process, which dramatically improves startup time.” So I think maybe there is a solution to improve our font loading, we can also implement this process to load and update the fonts if system fonts have been changed, then the interface would not be affected.
Dear Volga, 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 guess still as reported. But I convert to enhancement.