Problem description: Steps to reproduce: 1. Create an ODT or a DOCX or a DOC document with a line of text in it. 2. Use Linux Libertine G (or any other font for that matter) 3. Embed the font and save (File -> Properties -> Font -> Embed fonts in the document. Then save the document). 4. Try to open the same document. Current behavior: It takes a very long time before the document opens. During that time LO becomes completely non-responsive (all other LO windows freeze). Expected behavior: It should open the document in a reasonable short time (in less than a second to a few seconds at worst). Operating System: Windows 7 Version: 4.1.2.1 rc
Note: The embedded font, Linux Libertine G, is not installed on my computer. It is available to all applications via a font manager. When the font manager is closed, all the fonts that it’s temporarily installed would be unavailable to the system. In this case, when the same font is embedded in a document, it has to be available to the system without the help of a font manager. So, when I attempt to open the document with the embedded font, I keep the font manager closed. However, this behaviour seems to be unrelated to the font manager and it happens regardless of it being open or closed. Now, I am going to try a new document with an embedded font like Georgia or Palatino to see if this behaviour occurs when the fonts are system fonts. I will report back once I finished my test.
LO shows the exact same behaviour with other fonts like Georgia.
please upload a test file
After adding a test file please reset the bug to "UNCONFIRMED".
Created attachment 87174 [details] Test file using LO 4.1.2.3 and Linux Libertine G font This file is a dummy, one-page Lorem ipsum file created using LO 4.1.2.3 and Linux Libertine G font. It takes about 9 to 10 seconds before it can be opened on my Windows 7 x64 installation. Note also the size of the file. The entire family of Linux Libertine G fonts are not 13MB altogether. I am not sure what has made this file so big after the font is embedded.
tested under Win7 64bit slow opening and saving with 4.1.0, 4.1.1 and 4.1.2 final releases. fast opening and saving with 4.0.5 final. hence REGRESSION P.S. lucifer --> version should always indicate the first version where the bug appeared, not the last.
I can confirm the behaviour described on W7 Embedding fonts makes loading time greater and greater while using the doc. Finally the loading time can take 5 min (SSD) I did have curious things also, such as different styles (the styles on the writer document was not what it is defined to be) for all doc. closing LO and launching LO again with a doc that don't any font embedded and all works fine.
I can confirm this bug on W7 x64, too. Also using Linux Libertine font in .odt files. Issue is not fixed in 4.1.5.3.
The problem exists in LO 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 There are actually two issues in here: 1- The very long time it takes to open a simple file with an embedded font (Linux Libertine G in my last test) 2- The huge size of the saved file with the embedded font, way larger than the sum of the simple file plus the font (even the whole family of the font) When I try this simple task, the result is the same: 1- Open Write 2- Create a new document 3- Write “This is a test.” 4- Go to File -> Properties -> Font -> Check the ‘Embed fonts in the document’ 5- Save the document 6- Close LO 7- Open the saved document in LO 8- Wait forever for the document to open! The size of this simple file is 12.9MB. The embedded font is: Linux Libertine G. The format of the document is odt. Here is the link to the sample document: https://mega.co.nz/#!YRRCmJqL!lRw-DGI2yzpBAkRvhVqIVVOMNlDvS8hVQ5rFXkUP9m4
Created attachment 97664 [details] Test-file using LO 4.2.3.3 and Linux Libertine G font under Win 8.1
I don't know if the behaviour is different from my last try tu use this feature. But, as this bug had no activity September 2013 I suppose that there is no change. The problems were so big that this feature is simply unusable. So I never use this feature again. How many people did like me ? IMHO This feature should be mark as experimental, and should I've been marked so just after this bug were rised
Lubos, do you have some time to look at font embedding performance?
Created attachment 115695 [details] Document with Simsun font removed The original attachments are no longer available. I created a test file with the text "This is a test." in Linux Libertine G but it is slightly over the upload limit so I will just explain what I discovered. The large size of the file is due to the default Tahoma, Liberation Serif, Liberation Sans, and, curiously, SimSun fonts being embedded as well. I was seeing about a 30 second load time. I altered that file by taking out the Simsun font and removing the references to it in the xml. It took about 10 seconds to load. I have attached that file. If you open it and save it then the SimSun font will be added back into it. Windows Vista 64 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Just a new try. The document was so long to open that ten minutes later, I just force LO to close. (LO 5.1.3 / W7 x64) This is rarely an experimental feature. I guess how many people use it ?
Confirmed. A simple font embed (Ubuntu Condensed and Liberation Serif) in a file with just 2 lines gives a 109MB file size.
It is now 40 minutes that I'm waiting to have a single slide presentation document opened This is rather a crash isn't it ? (No it has just finished : 42 minutes !) The local temp libreoffice dir C:\Users\Pierre\AppData\Roaming\LibreOffice\4\user\temp\embeddedfonts\fromdocs has 58 fonts. A new file were added every minutes My computer is no so slow : I7 3,4 GHz, 34 Go RAM SSD From my point of view, this option is unusable. And should be depreciated to experimental features Windows 7x64, LO 5.2.1.2
Please, setting version back to 4.1.0.4 release as it was the earliest one affected. Please, don't change the version field to a later one
Adding keyword 'preBisect' as this regression was introduced before branch 4.4 and therefore it can't be bibisected as there's no bibisect repository for this branch.
*** Bug 114196 has been marked as a duplicate of this bug. ***
Setting to LibreOffice instead of Writer. Draw & Impress are also affected Two draw examples: attachment 122763 [details] (bug 65046) attachment 138279 [details] (bug 114314)
Created attachment 138321 [details] Callgrind of attachment 138279 [details] Did it for opening attachment 138279 [details] Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: a9a4c26ed1365ffa089654fefc8fa2f29862b6c7 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded Built on December 7th 2017
(In reply to tommy27 from comment #6) > tested under Win7 64bit > slow opening and saving with 4.1.0, 4.1.1 and 4.1.2 final releases. > fast opening and saving with 4.0.5 final. > hence REGRESSION LibreOffice 4.1 had introduced embedding fonts into writer documents (see https://wiki.documentfoundation.org/ReleaseNotes/4.1#Writer) -> not a regression here; it is expected to take time to save and load; but loading takes *too much* time, the more so the more fonts are in the file, and the more fonts are installed on system. Saving is not slow (it is slower than in 4.0, but reasonably so considering more data to store). The "needless fonts stored in the file" is tracked in bug 65353.
*** Bug 114697 has been marked as a duplicate of this bug. ***
An abandoned attempt: https://gerrit.libreoffice.org/47112 (no time to work on it at the moment, unfortunately)
*** Bug 119262 has been marked as a duplicate of this bug. ***
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/98d71c4e0847797a4ba9229a8e6d832a8a3d5e0f%5E%21 tdf#69060: lock refreshing font data when loading a document It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed in master; no backporting is planned, because I feel not 100% confident with the fix (though I suppose it should be OK, and feel more confident than the previous version) - so I hope for some testing in master.
(In reply to Mike Kaganski from comment #27) > Fixed in master; no backporting is planned, because I feel not 100% > confident with the fix (though I suppose it should be OK, and feel more > confident than the previous version) - so I hope for some testing in master. attachment 122763 [details] and attachment 138279 [details] open quickly Version: 6.3.0.0.alpha0+ (x64) Build ID: 411f3a050ac2be598019d512f8ccfe041080c28f CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-01-14_03:17:11 Locale: fi-FI (fi_FI); UI-Language: en-US Calc: threaded
*** Bug 86714 has been marked as a duplicate of this bug. ***