Bug 69060 - FILEOPEN: Documents with embedded fonts take too long to open
Summary: FILEOPEN: Documents with embedded fonts take too long to open
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: Other Windows (All)
: medium normal
Assignee: Mike Kaganski
Whiteboard: BSA target:6.3.0
Keywords: perf, preBibisect
: 86714 114196 114697 119262 (view as bug list)
Depends on:
Blocks: Fonts-Embedded
  Show dependency treegraph
Reported: 2013-09-06 23:27 UTC by Eric Bright
Modified: 2024-06-07 23:29 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:

Test file using LO and Linux Libertine G font (104 bytes, text/plain)
2013-10-06 03:39 UTC, Eric Bright
Test-file using LO and Linux Libertine G font under Win 8.1 (309 bytes, text/plain)
2014-04-21 07:23 UTC, Eric Bright
Document with Simsun font removed (4.47 MB, application/vnd.oasis.opendocument.text)
2015-05-18 15:39 UTC, Gordo
Callgrind of attachment 138279 (5.32 MB, application/x-xz)
2017-12-08 17:44 UTC, Buovjaga

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Bright 2013-09-06 23:27:54 UTC
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: rc
Comment 1 Eric Bright 2013-09-06 23:47:46 UTC
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.
Comment 2 Eric Bright 2013-09-06 23:54:57 UTC
LO shows the exact same behaviour with other fonts like Georgia.
Comment 3 tommy27 2013-10-05 15:28:29 UTC
please upload a test file
Comment 4 retired 2013-10-05 16:50:37 UTC
After adding a test file please reset the bug to "UNCONFIRMED".
Comment 5 Eric Bright 2013-10-06 03:39:18 UTC
Created attachment 87174 [details]
Test file using LO and Linux Libertine G font

This file is a dummy, one-page Lorem ipsum file created using LO 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.
Comment 6 tommy27 2013-10-06 07:14:41 UTC
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.

P.S. lucifer --> version should always indicate the first version where the bug appeared, not the last.
Comment 7 Pierre C 2013-12-06 12:39:53 UTC
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.
Comment 8 sephren 2014-04-20 18:08:18 UTC
I can confirm this bug on W7 x64, too. Also using Linux Libertine font in .odt files. Issue is not fixed in
Comment 9 Eric Bright 2014-04-21 07:10:41 UTC
The problem exists in LO 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:
Comment 10 Eric Bright 2014-04-21 07:23:41 UTC
Created attachment 97664 [details]
Test-file using LO and Linux Libertine G font under Win 8.1
Comment 11 Pierre C 2014-04-21 09:57:09 UTC
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
Comment 12 Michael Stahl (allotropia) 2014-04-22 09:14:54 UTC
Lubos, do you have some time to look at font embedding performance?
Comment 13 Gordo 2015-05-18 15:39:44 UTC
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
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Comment 14 Pierre C 2016-05-23 06:22:53 UTC
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 ?
Comment 15 Olivier Hallot 2016-07-20 19:19:21 UTC
Confirmed. A simple font embed (Ubuntu Condensed and Liberation Serif) in a file with just 2 lines gives a 109MB file size.
Comment 16 Pierre C 2016-08-27 19:58:58 UTC
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 
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
Comment 17 Xisco Faulí 2016-09-02 09:31:53 UTC
Please, setting version back to release as it was the earliest one affected. Please, don't change the version field to a later one
Comment 18 Xisco Faulí 2016-09-13 11:25:21 UTC
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.
Comment 19 Telesto 2017-12-07 18:42:07 UTC
*** Bug 114196 has been marked as a duplicate of this bug. ***
Comment 20 Telesto 2017-12-07 18:53:21 UTC
Setting to LibreOffice instead of Writer. Draw & Impress are also affected
Two draw examples:
attachment 122763 [details] (bug 65046)
attachment 138279 [details] (bug 114314)
Comment 21 Buovjaga 2017-12-08 17:44:58 UTC
Created attachment 138321 [details]
Callgrind of attachment 138279 [details]

Did it for opening attachment 138279 [details]

Arch Linux 64-bit
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
Comment 22 Mike Kaganski 2017-12-28 10:31:42 UTC
(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.

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.
Comment 23 Mike Kaganski 2017-12-30 08:37:40 UTC
*** Bug 114697 has been marked as a duplicate of this bug. ***
Comment 24 Mike Kaganski 2018-05-23 09:37:40 UTC
An abandoned attempt: https://gerrit.libreoffice.org/47112 (no time to work on it at the moment, unfortunately)
Comment 25 Telesto 2018-10-11 13:30:19 UTC
*** Bug 119262 has been marked as a duplicate of this bug. ***
Comment 26 Commit Notification 2019-01-11 04:39:29 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 27 Mike Kaganski 2019-01-11 05:25:09 UTC
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.
Comment 28 Buovjaga 2019-01-14 18:25:40 UTC
(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: (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
Comment 29 Buovjaga 2019-01-14 19:17:39 UTC
*** Bug 86714 has been marked as a duplicate of this bug. ***