Steps to reproduce (on Trisquel 5.5): 1. Install and open Font Manager. 2. Open any document (preferably containing a substantial amount of text, to see the bug's effects). 3. Use Font Manager to install a new font from any directory. Expected behaviour: either nothing or the font should become available. (Though I do note that on Windows, LibreOffice does not recognize a newly installed font until a restart.) Actual behaviour: the document loses all semblance of layout. Many lines have all their letters grouped to the left side, others have wide spacing and kerning, and the font changes to DejaVu Sans. This also occurs when deleting fonts. I'll submit a video and/or screenshot soon.
Created attachment 74573 [details] Before and after Here is a before and after screenshot. The top shows the document as it is when I open it. Note that it is saved as an RTF file. On the bottom, you see the document after installing Anonymous Pro. I have highlighted the unreadable parts, but the whole document is badly kerned and unusable. After closing and reopening, everything is fine again, but this is still annoying.
Good chance this is a local issue, I cannot reproduce. Going to ask one other QA person to try but I tested on Bodhi Linux 2.2 using LibreOffice 4.0.0.3 and didn't experience the issue. What I saw was no change, upon restart of LibreOffice, font was there.
I tested this using LibreOffice 4.0.1.0+ on Ubuntu 12.04. I did confirm that the currently opened document becomes a mess when you have freshly installed a font. This is without selecting the new font, it just happens. Text runs off the page, letters are jumbled, much like the Before and after sample attachment. However, everything goes back to normal after you close and reopen the document, and you can view and use the new font without issue.
Setting this as NEW, with a normal, high priority, since it might be regression. I selected Normal since the document is fine after reopening, but I can see how seeing the strange formatting and possibly trying to correct it during the time the font manager is open could hinder a user's work.
I should note that this also occurs when fonts are copied into /usr/share/fonts or one of that folder's subdirectories.
Created attachment 76686 [details] Even UI is affected While I was changing the fonts for my user interface with a document open in Writer, the attached image happened. It's even worse than before. Not only does the document show seemingly random bold characters, but even the words at the top and bottom of the screen are illegible. Again, this is fine after reopening, but it's still really weird.
Created attachment 76728 [details] Video showing the problem I can't remember exactly what caused this problem, but it's on parallel with the other stuff we've seen. Watch the video to see what happens when I click randomly on the document. It's so bad I didn't even bother to obfuscate the document.
I have a very similar behavior as reported in bug 62447, but, the only difference with this bug is that I didn't require to install/delete any font when LibreOffice was open: it happens randomly.
Created attachment 79009 [details] Perhaps the most amusing one yet Well, this bug is no longer about installing or deleting fonts only. I opened Font Manager, and used it only to open a folder that contained a font (NOT to install or delete any fonts) and suddenly a document that I had open became entirely blank. I had trouble taking a screenshot of it, because the bottom bar became greyed out whenever my pointer reached it.
Lubos - any quick thoughts / pointers on this font oddness ? :-) I wonder if your font embedding work improved this for 4.1 ?
*** Bug 62447 has been marked as a duplicate of this bug. ***
I -imagine- that this comes down to the gtk+ toolkit noticing that the fontconfig files have been changed, and refreshing it's font cache information, and us using the old data. I imagine the problem stems from: gtksettings.c (settings_update_fontconfig) ... if (timestamp != last_update_timestamp) { PangoFontMap *fontmap = pango_cairo_font_map_get_default (); gboolean update_needed = FALSE; /* bug 547680 */ if (PANGO_IS_FC_FONT_MAP (fontmap) && !FcConfigUptoDate (NULL)) { pango_fc_font_map_cache_clear (PANGO_FC_FONT_MAP (fontmap)); if (FcInitReinitialize ()) update_needed = TRUE; } At least we get a: gtk_style_context_reset_widgets (priv->screen); When this happens - so (hopefully) we can track and trap that inside vcl somehow; we get a: void gtk_style_context_reset_widgets (GdkScreen *screen) { GList *list, *toplevels; _gtk_icon_set_invalidate_caches (); toplevels = gtk_window_list_toplevels (); g_list_foreach (toplevels, (GFunc) g_object_ref, NULL); for (list = toplevels; list; list = list->next) { if (gtk_widget_get_screen (list->data) == screen) gtk_widget_reset_style (list->data); g_object_unref (list->data); } g_list_free (toplevels); } Hopefully this eventually calls: void gtk_style_context_invalidate (GtkStyleContext *context) ... g_signal_emit (context, signals[CHANGED], 0); and we can catch that ...
Seems like: void GtkSalGraphics::updateSettings( AllSettings& rSettings ) ... g_object_get( pSettings, "gtk-fontconfig-timestamp", &latest_fontconfig_timestamp, (char *)NULL ); if (latest_fontconfig_timestamp != our_fontconfig_timestamp) Has some code to help handle this - so perhaps there is some sequencing problem whereby the resets happen in a different order or somesuch (?).
Pushed a fix to master; I'd really appreciate someone installing and testing the fix - in theory we should be as good as the next gtk+ app now - we listen for the right setting, and refresh our font database. Of course - without some testing it's hard to say, and I can't reproduce that here. Lots of manual fc-cache -r - and I can only corrupt font-manager itself (which I had to download/compile ;-) - is this really a common user use-case ? Anyhow - feedback appreciated; dev-builds are here; please wait 8 hours or so for a new build ... http://dev-builds.libreoffice.org/daily/master/
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=46ee3bd7bd2afc2f05c3ff8650f2f4507e72fe64 fdo#60565 - re-read font data on GtkSettings fontconfig-timestamp notify. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5e55de0845e16896444e2e01a99c9a7055bc868&h=libreoffice-4-1 fdo#60565 - re-read font data on GtkSettings fontconfig-timestamp notify. It will be available in LibreOffice 4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Why is this bug's status currently NEEDINFO, after patches have been committed and the problem is confirmed?
comment 14 says why - Michael wants confirmation that the problem is fixed on the daily build
In the absence of any testing feedback, I've pushed it for review to 4-0 - it seems unlikely to do any significant harm: https://gerrit.libreoffice.org/4376 marking fixed.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=60d26eab97ec50a92f19994a3694f3f1d2d61038&h=libreoffice-4-0 fdo#60565 - re-read font data on GtkSettings fontconfig-timestamp notify. It will be available in LibreOffice 4.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.