https://bugzilla.novell.com/show_bug.cgi?id=856476
https://bugzilla.novell.com/show_bug.cgi?id=856476#c4
L. A. Walsh
rpm -qa|grep font|wc 265 265 10378
*5 minutes for just 64-bit arch, that's 22 hours. So currently open-suse is setup to discourage installing from RPM's. Regardless, I have most of my font collection from Windows (TTF & OTF), where I have ~4k fonts installed. In order for fonts to display the same on linux and windows -- one generally wants them in both places. So I 'synchronize' C:\windows\fonts with my C:\usr\share\fonts\Windows (I used to try to separate them between TTF and OTF, but that seems pointless and is a pain) -- which is kept synchronized with my linux server (suse13.1) in /usr/share/fonts/Windows. Given the plethora of fonts available, it seems one's always installing SOME font -- so having my font dirs updated average 1/week or more is not uncommon.
Font cache has to be regenerated before program starts to render fonts when needed, at least what says common sense to me.
Common sense would tell one that this would be necessarily only if one expected to use the font one just installed. VI only works well with fixed fonts. More importantly, there aren't many monospace fonts that look reasonable and have reasonable coverage. So common sense would tell one that regenerating a font cache for 1 of thousands of proportional fonts while invoking a text editor wouldn't cause a 5 minute pause for both normal users and ANOTHER pause for root -- 5 minutes each. I can't even run a mkfontscale & such w/o this occurring -- even though that doesn't change the installed fonts. Just doing a 'touch' of the directory -- causes a rebuild of the cache -- common sense would tell me my editor could use the current set of fonts until a new cache was put in place. To tell you how obvious such an algorithm is -- look at the findutils/locate. It's been out for 15-20 years -- it doesn't pause a locate command for 15-30 minutes while updatedb is updated. A new DB is built in background and is put in place when it is done -- replacing the old DB. That's been common knowlege/common sense for 20 years. fontcache doesn't show any common sense in that regard. I can't see any reason why x32 caching is different from x64 -- it seems like braindead design. The fonts start out as NOT arch-dependent. To have to run a 5+ minute process for each time the dir is touched for 32 and 64 bit machines is a horrible design. If we were talking little vs. big endian, that would be a different topic. The data formats in memory are different -- but that's not true on LE machines. Since there are no arch-specific fonts -- one can safely assume there are no font fields that require arch-specific or > 32 bit info data. You can call this of low importance -- and to most engineers and probably more guys than gals, that's more likely the case, but to anyone who wants things to look consistent across platforms and wants full unicode support, fonts and font coverage is important. When the font system is broken -- one can't use the GUI at all -- it displays only squares. The workarounds for these bugs are to disable fc-cache entirely and have it run in a cron-job or an ad-hoc basis. BTW--- to run 1-arch on cygwin -- fc-cache takes >9 minutes. The font system on linux is light years ahead of what MS-windows has -- which is why I usually do my linux work via X rather than the alternative of using linux-cifs and editing the files directly from windows (I can do both and use both depending on circumstance, but most often I am running gui and editor on linux as that's where I am doing my work (windows 7 isn't that stable, even though it can have a prettier desktop that runs with more programs I couldn't do w/o (or don't want to do w/o -- occasional games) w/linux-only -- photoshop and such being key). Also Nvidia cards don't work reliably on linux (nvidia fault for not having open drivers, but linux fault for having internal interfaces that change each kernel release)... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.