Bug 60565 - EDITING: Installing or deleting fonts with Writer open results in bizarre document layout
Summary: EDITING: Installing or deleting fonts with Writer open results in bizarre doc...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0 target:4.1.0.2 target:4.0.5
Keywords:
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-02-10 05:00 UTC by Linus Drumbler
Modified: 2013-06-20 09:59 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Before and after (2.87 MB, image/png)
2013-02-11 01:40 UTC, Linus Drumbler
Details
Even UI is affected (182.76 KB, image/png)
2013-03-18 15:24 UTC, Linus Drumbler
Details
Video showing the problem (1.33 MB, video/ogg)
2013-03-19 03:44 UTC, Linus Drumbler
Details
Perhaps the most amusing one yet (56.15 KB, image/png)
2013-05-08 00:17 UTC, Linus Drumbler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Linus Drumbler 2013-02-10 05:00:46 UTC
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.
Comment 1 Linus Drumbler 2013-02-11 01:40:22 UTC
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.
Comment 2 Joel Madero 2013-02-25 17:41:17 UTC
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.
Comment 3 Brenda Granados 2013-02-27 16:06:05 UTC
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.
Comment 4 Brenda Granados 2013-02-28 15:58:10 UTC
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.
Comment 5 Linus Drumbler 2013-02-28 20:20:23 UTC
I should note that this also occurs when fonts are copied into /usr/share/fonts or one of that folder's subdirectories.
Comment 6 Linus Drumbler 2013-03-18 15:24:36 UTC
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.
Comment 7 Linus Drumbler 2013-03-19 03:44:07 UTC
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.
Comment 8 Francisco 2013-03-30 17:11:32 UTC
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.
Comment 9 Linus Drumbler 2013-05-08 00:17:03 UTC
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.
Comment 10 Michael Meeks 2013-05-10 08:41:44 UTC
Lubos - any quick thoughts / pointers on this font oddness ? :-) I wonder if your font embedding work improved this for 4.1 ?
Comment 11 Michael Meeks 2013-05-15 10:51:00 UTC
*** Bug 62447 has been marked as a duplicate of this bug. ***
Comment 12 Michael Meeks 2013-05-15 10:56:56 UTC
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 ...
Comment 13 Michael Meeks 2013-05-15 11:07:23 UTC
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 (?).
Comment 14 Michael Meeks 2013-06-18 17:08:42 UTC
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/
Comment 15 Commit Notification 2013-06-18 17:09:26 UTC
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.
Comment 16 Commit Notification 2013-06-18 19:03:32 UTC
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.
Comment 17 Linus Drumbler 2013-06-19 14:24:09 UTC
Why is this bug's status currently NEEDINFO, after patches have been committed and the problem is confirmed?
Comment 18 Joel Madero 2013-06-19 14:31:12 UTC
comment 14 says why - Michael wants confirmation that the problem is fixed on the daily build
Comment 19 Michael Meeks 2013-06-20 09:44:50 UTC
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.
Comment 20 Commit Notification 2013-06-20 09:59:24 UTC
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.