Bug 127123 - Recently Used Fonts are not stored across sessions when sidebar is used
Summary: Recently Used Fonts are not stored across sessions when sidebar is used
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fonts-Name-Combobox
  Show dependency treegraph
 
Reported: 2019-08-23 15:04 UTC by Pedro
Modified: 2024-08-31 03:16 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Microsoft Word 2019 has a list of the 5 most recently used fonts on top (67.63 KB, image/png)
2019-08-23 15:04 UTC, Pedro
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro 2019-08-23 15:04:07 UTC
Created attachment 153596 [details]
Microsoft Word 2019 has a list of the 5 most recently used fonts on top

Steps to reproduce:
1 - Open Writer document,
2 - Press drop-down list of Font names;

When performing these steps the fonts are organized by alphabetical order (as it should be). 
However, a nice minor feature would be to present the 5 most recently used fonts in the top of the list, so that the user could easily select his most used fonts.

This is a feature offered by Microsoft Word since a long time.
Didn't find any bug requesting this.
Comment 1 Dieter 2019-08-23 15:39:51 UTC
LO also offers recently used fonts, but only for the actual document. So in my view the feature request is more precisely some thing like "LO should remember recently used fonts".

For me a valid enhancement request
Comment 2 Pedro 2019-08-23 15:47:45 UTC
Yes, that is what I meant. Show by default on the open modules.

I am writing a thesis on Writer, and it doesn't show me recently used fonts, maybe because I am using styles or the default fonts that I defined for documents.
Comment 3 V Stuart Foote 2019-08-23 17:19:05 UTC
On opening a document, the Fonts listbox is populated in one pass alphabetically by parsing all fonts available on system. It is fundamentally a Direct Formatting tool--also note we do not even show the font assigned when using the Formatting (Style) toolbar--adjusting 'Font' in the Paragraph style dialog.

We already provide MRU for fonts at the top of the list box, but it is dynamic during editing. And, have other UI issues of returning to top of alphabetical list on next access to the listbox (bug 90161)

That said, it would be convenient to add a static MRU segment at the top of the droplist, populated from LO user profile. Perhaps even allow for pining of preferred fonts into a static MRU.
Comment 4 V Stuart Foote 2019-08-23 17:28:48 UTC
UI changes Design team had been considering is laid out in this blog:

https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/
Comment 5 Heiko Tietze 2019-08-26 07:28:19 UTC
Consider more than one projects where completely different fonts are used. Would be annoying to list the arty Comic for your thesis, right? In the other (more common) scenario you create similar documents where the preferred font should always be at hand. So what actually is need is both, per document and some kind of favorite. I would make this a duplicate of bug 91130. What do you think, Pedro?
Comment 6 Pedro 2019-08-26 13:27:20 UTC
> Consider more than one projects where completely different fonts are used.
> Would be annoying to list the arty Comic for your thesis, right? In the
> other (more common) scenario you create similar documents where the
> preferred font should always be at hand. So what actually is need is both,
> per document and some kind of favorite. I would make this a duplicate of bug
> 91130. What do you think, Pedro?

I disagree. Bug 911130 refers to something completely different.

>My idea is that the font name drop down list will begin with containing only a >short list of fonts that are commonly used and available on a user's system (e.g. >Liberation Serif, Times New Roman, Liberation Sans, Arial, etc) and additional >fonts will be added to the list according to the following scenarios.

>1) A user opens a document which contains fonts not already shown in the list
>2) A user clicks on a 'More Fonts...' entry at the bottom of the list and selects >to use a particular font in the character dialog's font tab

Now, the discussion over there drifted to overlap this bug.
IMO, the use case you mention is something different. It's to have a list of preferred fonts at the top of the drop-down list, NOT the most recently used.

That's something that could be done in a different manner: allow the user to pin fonts to the top of the drop-down menu.
Comment 7 Maxim Monastirsky 2019-08-26 21:10:07 UTC
As Stuart pointed out, we already have this feature of listing the last 5 chosen fonts. The list is stored in the user profile in the user/config/fontnameboxmruentries file, and we even have an expert config option to enable/disable this feature (org.openoffice.Office.Common.Font.View.History). So I'm not sure why it doesn't work for Pedro, maybe there's some bug involved here. I would suggest at first to check the expert config, or even reset the user profile completely, and see if that helps.

One problem that I did notice while testing this, is what happens when there are several font name controls visible at the same time. This might be because of several open documents, but as well might be in a single document, if both the formatting toolbar and the sidebar are visible. It appears that each font name control manages the MRU list on its own, and they're not synced. Moreover, each control updates the fontnameboxmruentries file on its own when destroyed, so the final contents of the fontnameboxmruentries file determined by the control destroyed last, which might or might not be the one where the user selected his fonts last.

In my testing I was selecting fonts in the toolbar control, and they appeared in the MRU list at first, but not after restarting Writer. The problem turned out to be with the sidebar. Everything went fine after I disabled the sidebar via View > Sidebar. So that's another thing to watch out.
Comment 8 Heiko Tietze 2019-08-27 07:02:08 UTC
Based on Maxim's input we should treat this as a bug.
Comment 9 Pedro 2019-08-27 09:39:31 UTC
(In reply to Maxim Monastirsky from comment #7)
> As Stuart pointed out, we already have this feature of listing the last 5
> chosen fonts. The list is stored in the user profile in the
> user/config/fontnameboxmruentries file, and we even have an expert config
> option to enable/disable this feature
> (org.openoffice.Office.Common.Font.View.History). So I'm not sure why it
> doesn't work for Pedro, maybe there's some bug involved here. I would
> suggest at first to check the expert config, or even reset the user profile
> completely, and see if that helps.
> 
> One problem that I did notice while testing this, is what happens when there
> are several font name controls visible at the same time. This might be
> because of several open documents, but as well might be in a single
> document, if both the formatting toolbar and the sidebar are visible. It
> appears that each font name control manages the MRU list on its own, and
> they're not synced. Moreover, each control updates the fontnameboxmruentries
> file on its own when destroyed, so the final contents of the
> fontnameboxmruentries file determined by the control destroyed last, which
> might or might not be the one where the user selected his fonts last.
> 
> In my testing I was selecting fonts in the toolbar control, and they
> appeared in the MRU list at first, but not after restarting Writer. The
> problem turned out to be with the sidebar. Everything went fine after I
> disabled the sidebar via View > Sidebar. So that's another thing to watch
> out.

Well, I'm using the Tabbed bar, so maybe it has something to do with it?
Comment 10 Pedro 2019-08-27 09:47:55 UTC
I have the boolean org.openoffice.Office.Common.Font.View.History set to true, but still not commonly used fonts. 
And I don't have this file:user/config/fontnameboxmruentries at C:\Users\MyName\AppData\Roaming\LibreOffice\4\user\config

I really thought this was a lacking feature. Nevertheless I already reset my user profile and still nothing.
Comment 11 Heiko Tietze 2019-08-27 13:11:45 UTC
Xisco: Has this ever worked before?
Comment 12 Buovjaga 2020-06-06 15:33:01 UTC
(In reply to Heiko Tietze from comment #11)
> Xisco: Has this ever worked before?

Wrong way to request bibisection... Figure it out *first* before adding the keywords!!
Comment 13 QA Administrators 2022-06-07 03:26:53 UTC Comment hidden (obsolete)
Comment 14 Telesto 2022-08-31 18:06:17 UTC
The title is slightly misleading. It's not limited to Sidebar.
Comment 15 QA Administrators 2024-08-31 03:16:09 UTC
Dear Pedro,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug