1. Create a new document in Writer. 2. Enter a few characters. 3. Place the text curser anywhere in that text and open the context menu (ctrl+mouse or right mouse) 4. In that context menu open the list of available fonts. Result: The list opens but is incomplete. It seems to get cut off after about 100 font names. I see this issue on Mac OS X and 64-bit Windows 7. Couldn't see this issue on Linux, but the reason may be that the Linux system I checked is very basic and may not have enough fonts installed.
Confirmed. Looks like the popups have a limit in the number of entries. Lowering prio, since there's a workaround.
(In reply to comment #0) OpenOffice.org 3.3.0 has the same problem.
*** Bug 47416 has been marked as a duplicate of this bug. ***
Un-claiming this bug. Cannot currently commit time to it.
Confirmed for Version: 4.1.0.3 Build ID: 719826cd009b9a1fa43e253db0616288c682826 Context menu shows about 204 ttf fonts in alphabetic order. In my case there are still some 41 ttf fonts not shown. Win XP, 4GB Workaround (menu - format - character - font) shows all installed fonts. Regards Luzius
In Windows 7, only the first 90 fonts are shown. The font menu should use cascaded menus instead of present design, which is sheer idiocy.
*** Bug 71184 has been marked as a duplicate of this bug. ***
*** Bug 45006 has been marked as a duplicate of this bug. ***
The comments in stdmenu.cxx say: // more than 100 fonts reduces the speed of opening the menu. // So only the first 100 fonts will be displayed. But cutting the list at font no. 100 and assuming that for the other fonts workarounds will be used is not precisely a clean solution. It resolves one bug by creating another. For example: Would it be possible to load just 100 fonts in the first instance and, upon scrolling down, then load the missing fonts dynamically in increments of 100? Or should the current list be replaced with a list of recently used fonts, as has been suggested before? At least that would make a coherent UI without bugs.
*** Bug 77959 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > The comments in stdmenu.cxx say: > > // more than 100 fonts reduces the speed of opening the menu. > // So only the first 100 fonts will be displayed. > > But cutting the list at font no. 100 and assuming that for the other fonts > workarounds will be used is not precisely a clean solution. It resolves one > bug by creating another. > > For example: Would it be possible to load just 100 fonts in the first > instance and, upon scrolling down, then load the missing fonts dynamically > in increments of 100? Or should the current list be replaced with a list of > recently used fonts, as has been suggested before? At least that would make > a coherent UI without bugs. I'm agree with you. We could replace the actual list with the list of recently used fonts (last 10 or 20 recently used should be enough!) tag VOTE added for this RFE :) The context menu is common to all the applications, we could change the component from "Writer" to "LibreOffice".
Add your vote here: https://wiki.documentfoundation.org/Vote_for_Enhancement#fdo.2334085_-_Enhancement.2FUI:_List_of_fonts_incomplete_in_context_menu
I checked the issue in Win7 64bit, LO4.2.5 and it displayed all more than 200 fonts on my system. Maybe it got fixed somehow. Windows only recommendation: Win has many hidden fonts that are still displayed (also in MSOffice). Can we take them out of the list?
I personally think it should be removed from the right-click menu as its in the formatting toolbar, the sidebar, and in the right-click characters dialog. I also think size and alignment should also be removed from the right-click. Alot of clutter for nothing.
(I feel I have to comment #11) Just a not on "most recently used fonts": You mean "most frequently used fonts"? In any case: "used by whom"? Only LibreOffice, or all applications? I doubt this is the correct thing to do. I'd expect to see the fonts that the current document uses, at least. Having a lot of fonts makes most programs hard to use, because the concept of font selection hasn't changed significantly the last 20 years. What about grouping fonts to similar fonts ("Panose" is the word that pops up in my mind). Within each group list the most frequently used font (nee not above) with the option to expand the view to more or all fonts in that group. Sometimes new problems need new solutions ;-)
I have suggested the removal of all formatting options from the context menu in bug 81132, which includes the font list. As the font list is incomplete and incorrectly sorted (bug 77959), the simplest thing to close this 3+ year old bug report is by removing the option from the context menu.
Closing as suggested by Jay.