Mmmh Fonts.
In the last couple of days, I worked mainly on the font sub-system in the app_server. I didn't think I would spend that much time on it, and I haven't even touched the FreeType backend other than temporarily fixing threaded access to it, as explained earlier.
On BeOS, when starting up, the app_server will scan the well-known font directories, and makes all fonts it finds and supports available to end-user applications. When you install a new font, you have to launch the Fonts preferences application, and press its "Rescan" button. And while you're at it, you can also specify the amount of memory the app_server uses for font caching.
On Haiku, this will work a little bit differently: on startup, the app_server will only make some fonts available - those that we're used the most during the last session. The app_server just stores a short list of those fonts and where they can be found on disk. It doesn't know about other fonts before you ask for one; if you ask for a font the app_server doesn't know yet, or ask for a list of all fonts, the app_server will scan the well-known directories for fonts for the first time. This makes the system boot time completely independent from the number of installed fonts. As a graphics designer, or just a collector, you can now serve your font needs without penalty.
This method does also work in a multi-user scenario: the user font directories are only added to the app_server when you log in - and they, too, are scanned the first time it's necessary, and not just always. Each user will only see the fonts he can really access, the font manager is able to present different font lists for each user.
And when you install a new font, it will be picked up immediately, using node monitoring; it's really surprising how few system components make use of this nice and handy feature in BeOS. That situation is greatly different in Haiku: we are keen to get rid of all those "restart" and "rescan" buttons the BeOS UI present you in one place or another, and node monitoring plays a big role in achieving this.
But let's come back to the Fonts preferences application for a moment: have you ever changed the cache settings there? Have you felt good about it? Did you know what you were doing? Did you notice any change? If you're like me, you can answer with a honest "no" to most of these questions. I think it's a bad option to put into a user accessible preferences application. The app_server should be able to figure out a good value by itself, and maybe even make the cache size dynamic, adapting it to the current work load. For this reason, you won't find that setting anymore in the Haiku Fonts preferences - I took the liberty and removed it.
The app_server font cache is still under construction, and I'll write something about how it will work in one of the next posts.
18 Comments:
I fully agree. If a question isn't understandable to the user, it shouldn't be asked to him. It should just work!
Good idea about getting rid of cryptic settings. The font cache size should probably be some percentage of the total physical RAM.
Could you please briefly explain the reason behind user specific fonts? I always thought of fonts as system wide components.
Go node monitoring !
Go Axel !
Go Banana !
percentage of the total physical RAM
I would think it could be more intelligent than that even.
I would expect it to firstly determine how much cache would be useful based on how many fonts are installed/used, and then further determine how much RAM is in use at any given time to determine if a larger font cache would have any adverse affects on running apps, or the potential to run more apps.
As a Grafic designer I use fonts alot, so I have to install and rescan the fonts and in Zeta there is no rescan button so I have to restart.
I think it is a good idea, to make things easier and remove the fonts cash for the user. I by myself dont know how to use it in a right way.
What you are going to do I think is a very good solution.
Will the postscript fonts work well?
What about the OpenType fonts will they work in Haiku?
Will there be a way to group the fonts in categories and types or will it be the task for a 3rd Party App?
I would love to see the fonts install automaticly after putting them in their fonts folder.
Thx great decission to remove the uneccesary rescan and font cache.
To admiral horror: user specific fonts are helpful when you don't have root privileges on the system you are using.
Since all fonts are managed by the system itself (applications are just using the system API), it would be quite painful to not be able to install any new fonts yourself, at least if you are into graphics.
To bruno: Haiku uses FreeType and shares its capabilities towards supporting font formats. And that should cover the font formats you care about. For a full list have a look at the FreeType website.
So, if I understand correctly, user specific fonts are more like a workaround for the problem that regular users don't have permissions to install new fonts.
Is it not possible to give different levels of font permissions to different users? Like, for example, admins - add and remove, regular users - add only, guests - none.
A friend of mine did a lot of graphic design in his spare time and he had MANY fonts. He found a little app (windows, of course) to drop an icon in the system tray that allowed for hotswapping of loded fonts. It seems like it would be easy to enable a little icon in the deskbar to allow for this with a simple checkbox in the font preference panel. I'm sure the technologically "cool" thing to do is to have some MRU caching system, but wouldn't it be better to allow the user to decide which fonts to use? Perhaps autoload fonts that are requested but not currently loaded? Updating the list of available fonts would be easy with node monitoring ...
Maybe this is more of an R2 idea, but it would seem like it would be quite useful.
-J
To admiral horror: it's all a question of having the permission to write into the app_server fonts directories. If you're only a guest, you probably cannot install any new fonts. As an ordinary user you can install and remove *your* own fonts at will - you just cannot remove any system fonts.
To btj: I'm afraid I don't understand what you're getting at. If I understand you at all, I'd say if you have that many fonts, a further grouping feature would be desirable. Something like that could be realized in the fonts preferences panel, but there is currently no way to export these groups into other applications, as that would need an extension to the existing API.
Increased font cache in BeOS is preferable to increase display speed of, say, Japanese fonts (which tend to be slow, maybe because of size?).
Is font cache size in Haiku going to take into consideration double-byte font sets with many characters such as these? If not, is is possible to add an option in preferences to such effect?
Last question: If user A installs font Verdana, will user B have access to that font? If not then what happens when user B installs the same font? Will there be 2 identical files in the font folder?
To koki: the font cache should be smart enough to cache the default fonts as far as they are used. I don't think there is a need for such an option, as the cache size should be dynamic.
To admiral horror: both users will see the font once, and it's only once in the global font list as well, as fonts are identified by family and style name, which is identical for that font.
This is not yet final, though, as the odd situation can occur that two fonts have the same family and style, but a different face - in that case, only one of them is currently picked up for both users.
Axel,
> the font cache should be smart
> enough to cache the default
> fonts as far as they are used.
My understanding is that a dynamic cache would load fonts when required, and unload them when not. This sounds suitable for small font sets, but what about Japanese/Chinese fonts that have thousands of characters?
> don't think there is a need for
> such an option, as the cache
> size should be dynamic.
Perhaps an option to pre-cache big fonts would be a good thing to have?
Koki, as Axel said, the app_server will hold a list of most frequently used fonts during sessions. Based on these statistics the size of the cache will be adjusted.
It is just like a dynamic structure in a lot of programming languages - you collect during every session and through all sessions the length of such, build an arithmetical middle of those values on every end of session and write that value somewhere on a HDD. Next time you init that highly-used structure with that middle value because it is a very good estimate for the further usage.
In other words, Koki, if you install and use a large font like a Japanese font, then the next time you boot up, the OS will calculate the cache to include that font. I think!
"To btj: I'm afraid I don't understand what you're getting at. If I understand you at all, I'd say if you have that many fonts, a further grouping feature would be desirable. Something like that could be realized in the fonts preferences panel, but there is currently no way to export these groups into other applications, as that would need an extension to the existing API. "
font attributes? (for grouping)
> ... For this reason, you won't find
> that setting anymore in the Haiku
> Fonts preferences - I took the liberty
> and removed it.
Hmmm, I thought that R1 was supposed to be JUST like BeOS 5. Am I wrong? For me this type of changes seems to be for R2...
To loziniak: Sorry, I'm afraid your impression is not exactly correct.
Haiku won't be just R5. It will be R5 just better.
I don't see any reason to copy misconceptions and bugs, at least, and that also means UI bugs to me.
Post a Comment
<< Home