Opened 6 years ago

Closed 6 years ago

#10045 closed bug (fixed)

PM: Putting fonts in non-packaged/data/fonts does not seem to work

Reported by: stippi Owned by: nobody
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I've created the folder /boot/home/non-packaged/data/fonts and copied files there. This did not result in /boot/home/data to appear, also not after a reboot. I have then moved the "fonts" folder into /boot/common/non-packaged/data, but this also did not make it appear in /boot/common/data. In my case it already contained /boot/common/data/fonts/wenquanyi, but the non-packaged fonts did not appear alongside that packaged font. Also not after rebooting.

Change History (10)

comment:1 by Giova84, 6 years ago

Personally, to avoid this issue, i made an hpkg package which contains my personal/additional fonts. For now seems the only solution to install additional fonts on Haiku PM.

in reply to:  description comment:2 by bonefish, 6 years ago

Replying to stippi:

I've created the folder /boot/home/non-packaged/data/fonts and copied files there. This did not result in /boot/home/data to appear, also not after a reboot.

Um, they are not intended to. The code looking for fonts simply needs to consider B_USER_NONPACKAGED_FONTS_DIRECTORY and B_COMMON_NONPACKAGED_FONTS_DIRECTORY. Apparently this has been forgotten in the app server or the respective change had become a merge victim.

comment:3 by stippi, 6 years ago

I thought the idea is that /boot/common is merged from both the packages and the contents of non-packaged. B_COMMON_FONTS_DIRECTORY should still point to /boot/common/data/fonts. Why is there the need to have additional directories? Obviously that would not only break our own applications. WonderBrush for example looks in B_COMMON_FONTS_DIRECTORY and is still broken even when app_server is fixed. It has its own font engine.

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages? How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages. I would find it intuitive if it worked the same for fonts, or rather all of the folders in that hierarchy.

comment:4 by anevilyak, 6 years ago

Out of curiosity, was it a typo that you wrote that you created /boot/home/non-packaged/data/fonts? I thought the packagefs mounts were at /boot/{system,common,home/config}, so I'm not sure what creating a directory at the spot that you chose was supposed to achieve, I'd have thought it'd need to be under config/non-packaged.

in reply to:  3 ; comment:5 by bonefish, 6 years ago

Replying to stippi:

I thought the idea is that /boot/common is merged from both the packages and the contents of non-packaged.

No.

B_COMMON_FONTS_DIRECTORY should still point to /boot/common/data/fonts.

It does.

Why is there the need to have additional directories? Obviously that would not only break our own applications. WonderBrush for example looks in B_COMMON_FONTS_DIRECTORY and is still broken even when app_server is fixed. It has its own font engine.

Yes, but the same is true for B_COMMON_FONTS_DIRECTORY and BeOS applications, since /boot/common didn't exist back then. This is really a design flaw -- or rather lacking feature -- of the find_directory() functionality. There should really be a more abstract API that simply allows you to iterate through e.g. all font directories without having to enumerate them specifically.

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages?

Well, in the same way it isn't transparent which stuff stems from /boot/system and which from /boot/common or /boot/config/home.

How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages.

No, the shadowing happens at the runtime loader level. The path ~/config/non-packaged/lib is simply listed before ~/config/lib in LIBRARY_PATH.

in reply to:  5 comment:6 by stippi, 6 years ago

Replying to bonefish:

Replying to stippi:

Doesn't that mean it is not transparent any more to applications, which stuff stems from packages and which from non-packages?

Well, in the same way it isn't transparent which stuff stems from /boot/system and which from /boot/common or /boot/config/home.

An enumeration of directories would not do. Ideally, there would be just one virtual directory, where all the shadowing and even turning off user add-ons and data (in safe-mode) is already taken care of.

How does it work for libraries? I thought a library could shadow a packaged library by putting a version in home/config/non-packaged/lib, which then appears in home/config/lib, shadowing any version from packages in home/config/packages.

No, the shadowing happens at the runtime loader level. The path ~/config/non-packaged/lib is simply listed before ~/config/lib in LIBRARY_PATH.

Ok, but then it's not as elegant as I thought. I thought the directory structure stays the same on the surface, where package fs takes care of dynamically and magically blending the contents of packages and the non-packaged structure at these "old" directories. As it is, in various places, apps now need to be aware of package management, plus the non-packaged hierarchy as it turns out.

comment:7 by jua, 6 years ago

I thought the directory structure stays the same on the surface, [...]

Up until reading this ticket, I thought the same. And looking at comments in e.g. ticket #10041 it seems more people have the misunderstanding as well. Maybe the wiki-entry should clarify how non-packaged works to clear that up.

comment:8 by jscipione, 6 years ago

I also tried installing fonts into /boot/home/config/non-packaged/data/fonts and it did not work, but, I was able to install them by putting them into /boot/system/non-packaged/data/fonts

comment:9 by bonefish, 6 years ago

In hrev46170 I think I accidentally fixed that fonts can be installed in /boot/system/non-packaged/data/fonts (formerly /boot/common/...). Not in non-packaged home path, though. I believe src/servers/app/font/FontManager.cpp is where it would need to be added.

comment:10 by anevilyak, 6 years ago

Component: - GeneralServers/app_server
Resolution: fixed
Status: newclosed

Should be fixed in hrev46181.

Note: See TracTickets for help on using tickets.