Pander Posted February 3, 2019 Report Share Posted February 3, 2019 Please, remove the fonts files and add font dependencies in Linux package. The following files can be removed package 0ad-data-common version 0.0.23: /usr/share/games/0ad/tools/fontbuilder/fonts/LinBiolinum_Kah.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/LinBiolinum_RBah.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/LinBiolinum_RIah.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/LinBiolinum_Rah.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/DejaVuSansMono.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeMono.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeSans.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeSansBold.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeSansOblique.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeSerif.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/FreeSerifBold.ttf /usr/share/games/0ad/tools/fontbuilder/fonts/texgyrepagella-bold.otf /usr/share/games/0ad/tools/fontbuilder/fonts/texgyrepagella-regular.otf actually, remove the entire direcotry /usr/share/games/0ad/tools/fontbuilder and add the package dependencies to the following font packages: fonts-dejavu-core fonts-freefont-ttf fonts-linuxlibertine fonts-texgyre Also check if the usage of the fonts in 0ad needs to be changed from absolute paths to paths as offered by font-config. Fixing this removes the size of the 0ad packages and enables using the latest version of the fonts on Ubuntu, Debian and other GNU/Linux distributions. 1 Quote Link to comment Share on other sites More sharing options...
Stan` Posted February 3, 2019 Report Share Posted February 3, 2019 Not sure you'll gain much space. But sounds like a nice thing to do. I'm afraid it won't be top priority though. Not sure about crossplatform compatibility. Pinging @Itms and @s0600204 as they might know more. Quote Link to comment Share on other sites More sharing options...
Pander Posted February 3, 2019 Author Report Share Posted February 3, 2019 Thanks. Besides the amount of space saved, it is good practice for GNU/Linux platforms that offer these fonts already. Quote Link to comment Share on other sites More sharing options...
Itms Posted February 3, 2019 Report Share Posted February 3, 2019 I think that the main issue here is a platform issue as Stan points out. There is no guarantee the fonts will be present in all Linux distributions. I think you should contact the package manager of your distribution and ask them to look into using such a dependency, which would indeed be desirable from the user perspective. 1 1 Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted February 3, 2019 Report Share Posted February 3, 2019 1 hour ago, Pander said: Thanks. Besides the amount of space saved, it is good practice for GNU/Linux platforms that offer these fonts already. It mostly works for software that tries to looks like the system one or with similar controls (the same design for the whole user system). But it doesn't work always for custom designed applications like the 0 A.D. game. A new version of a font could look worse with the current in-game background. So we should account it too for the removing. Though we don't use fonts in real-time, but we plan. Quote Link to comment Share on other sites More sharing options...
Imarok Posted February 3, 2019 Report Share Posted February 3, 2019 Not using prerendered fonts, but rendering them in realtime should already save much space. Quote Link to comment Share on other sites More sharing options...
Stan` Posted February 4, 2019 Report Share Posted February 4, 2019 12 hours ago, vladislavbelov said: It mostly works for software that tries to looks like the system one or with similar controls (the same design for the whole user system). But it doesn't work always for custom designed applications like the 0 A.D. game. A new version of a font could look worse with the current in-game background. So we should account it too for the removing. Though we don't use fonts in real-time, but we plan. 12 hours ago, Imarok said: Not using prerendered fonts, but rendering them in realtime should already save much space. See my Github for a attempt to bench Cairo ans FreeType for atlas texture génération. Quote Link to comment Share on other sites More sharing options...
s0600204 Posted February 4, 2019 Report Share Posted February 4, 2019 Considering how we currently use fonts, it does seem odd that the source files are bundled with the game. I guess they're only there because they're in the "binaries" folder, and that folder is bundled almost in its entirety. 23 hours ago, Itms said: There is no guarantee the fonts will be present in all Linux distributions. As a loose idea as to how many distributions have the fonts available in their package repositories (stats courtesy of Repology): LinuxLibertine : 66 packages (across 20 "families") DejaVu : 145 packages (across 33 "families") FreeFont : 122 packages (across 26 "families") TeX Gyre : 37 packages (across two package names across 5 "families") And for the eastern Asian languages: Hanazono : 48 packages (across 10 "families") Japanese Kanji Source-Han-Sans : 92 packages (across 13 "families") Pan-CJK characters (Repology groups distributions by "family", e.g. Ubuntu, Debian, SteamOS, LinuxMint are one "family". If you're running LinuxMint, then as LinuxMint is derived from Ubuntu, then the repositories for the appropriate version of Ubuntu are mostly compatible with your LinuxMint system. It's not a perfect categorisation, but as a rough guide it works.) Alternatively, here's something I threw together to more easily compare some of the commonly used distributions. CentOS, Fedora, OpenSUSE, OpenMandriva, and Slackware are the ones that are noticeably problematic. On 2/3/2019 at 9:44 PM, stanislas69 said: Not sure about crossplatform compatibility. Yes, Windows and OSX would most likely still need the fonts bundled with the game. The way I see it, we have three possibilities: We change nothing, but tell the packagers to exclude the "binaries/tools/fontbuilder" when packaging the "0ad-data" package for their repositories. We remove the font files entirely, make the files' respective packages a build-time-only dependency, and write instructions on where to download the files for systems that don't have a package repository or do but lack the specific packages. (The caveat is that we don't use them at build-time either...) We relocate the font files somewhere else within our repository, such as into a subdirectory under "libraries/source/". I think I personally favour a combination of the second and third: move the files and then, when we get in-game rendering working we add package dependencies and use the new location as a fallback (whether that be as the source of a 0ad-fonts package, auto-bundling of the fonts by build-osx-bundle.sh, and/or some other solution). 22 hours ago, vladislavbelov said: [...] But it doesn't work always for custom designed applications like the 0 A.D. game. A new version of a font could look worse with the current in-game background. [...] I think the fonts we use are reasonably stable (LinuxLibertine and FreeFont haven't had any releases since 2012, and DejaVu since 2016. TeX Gyre is the most recently updated at 2018, but the release before that appears to have been 2016). I would imagine that if the typeface anatomy of fonts change too much between versions, then the font's creators would possibly get complaints from their user-base. Also, some of the fonts we use claim to be a like-for-like replacement (Gyre Pagella for Palatino), or to have the same appearance as - but a wider character range than - another font family (DejaVu for Vera), and so in theory shouldn't deviate too much from their "inspiration". I get what you mean though: having two users with what should be the same font but - due to changes between versions - are visually different could disrupt our established visual style (such as it is), or make for an inconsistent experience between users. It is true that many games get bundled with their own fonts, even on Linux systems (eg. SuperTux, SuperTuxKart).That might be down to simplicity: they have to bundle the fonts for Windows and OSX systems, so it's easiest to just do the same for Linux as well. Huh, this turned into a longer post than I anticipated. Apologies, and congratulations if you got this far without glazing over. 7 Quote Link to comment Share on other sites More sharing options...
vladislavbelov Posted February 6, 2019 Report Share Posted February 6, 2019 On 2/5/2019 at 1:06 AM, s0600204 said: As a loose idea as to how many distributions have the fonts available in their package repositories (stats courtesy of Repology): LinuxLibertine : 66 packages (across 20 "families") DejaVu : 145 packages (across 33 "families") FreeFont : 122 packages (across 26 "families") TeX Gyre : 37 packages (across two package names across 5 "families") It also requires a visual comparison. Are they visually equal for all distributions? I think we can just move fonts. Because currently we don't even need them on user machines. The important step is the font rendering - to use real fonts instead of prerendered pictures. And on this step we can decide how to distribute fonts. 1 Quote Link to comment Share on other sites More sharing options...
Pander Posted February 10, 2019 Author Report Share Posted February 10, 2019 If a distribution offers packages for a specific version of a font, the font files in there should be identical over different distributions. So yes, they are visually equally. I have never come across a case where that was not, not for these major widely used fonts. If you have, I'm interested. Good to exclude the fonts now from the package process as they are not needed. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.