-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Georgian support #126
Comments
Here's the various fonts I built: The 'fb' versions are built with the
|
Yeah, I was waiting for someone who knows Georgian to appreciate the font and keymap. Looks like the day has come! :)
Ouch. I've seen a description of a Public Domain license like this:
The problem is that this is not even close to the text of the license and I don't know if the text of this license even exists. Analyzing its freedom is quite difficult[1]. There are equivalents[2] to this license and in my opinion WTFPL[3] is the closest. But we can't make such assumptions and guess at the terms of the license. So on the one hand Public Domain is good because it shows that the authors did not want to impose any restrictions, but on the other hand this license is textless and cannot be verified for GPL2 compatibility. [1] https://wiki.creativecommons.org/wiki/public_domain
Not long ago I deleted Agafari fonts after the legal review that SUSE did (many thanks to them for that). So I wouldn't want to add fonts with questionable licenses again. If there is an opportunity to ask a lawyer, I would be very happy to do so. Or maybe SUSE can help me one more time here. @stanislav-brabec, what do you think?
Is it really so bad ?
This means actually creating a new standalone font. If you do that, I think it might solve the license problem, since it will be based on the GPL font. But of course that's a separate big job.
Good! Did you show these fonts to him, what did he think about them ? |
Hello, font link: https://bpgfonts.wordpress.com/2017/12/21/bpg-2017-dejavu-sansmono/ |
As I said before I have never tried to convert ttf to psfu, but there are a few projects that seem to be able to do it. Here's one for instance: https://github.com/NateChoe1/ttf2psf Have you tried using it ? |
I tried, but couldn't get which of additional files needed to choose. Copied .psfu.gz to /lib/kbd/consolefonts and did setfont [root@fedora tmp]# LANG= setfont DejaVuSansMono |
"Converting" from TTF to PSF is rarely going to give great results. While they can have bitmaps, TTF fonts are usually vector fonts. PSF/BDF are pixel fonts, intended to be displayed only exactly as they were drawn, at that size (for fonts with multiple sizes, each size is drawn separately). Vector fonts are designed to scale, and designed to be rendered by engines like freetype with all the tricks they can do - subpixel hinting, antialiasing and so on. Especially at small sizes, they usually look pretty rough without all those tricks. Console font rendering doesn't do any of that stuff - it's intended to use pixel fonts, and it just displays the chosen font exactly as drawn. When you 'convert' a vector font to a bitmap font, you wind up with just the 'raw' rendering of the font at that size, without any of the rendering tricks usually used to make it display better. It doesn't look anything like as good as a hand-drawn bitmap font. There are plenty of TTF vector fonts in the world with Georgian characters (that's why you can see Georgian characters just fine at a desktop in Fedora), what we're missing (aside from the console-setup one which you say isn't great :|) is a bitmap font with Georgian characters. We can certainly try doing a TTF to bitmap conversion and see if it looks better than the not great console-setup one, but I wouldn't put too much faith in it... |
On the licensing issue, this is what console-setup says about the Georgian font:
Again, I'm not clear on what makes them so sure that a console font produced from a hex file is "automatically" public domain, I can't immediately find any explanations of this. I can ask Red Hat legal to chime in too, I'll try and remember to poke them about that on Monday. |
Yeah, you're right. I agree with that.
That's great. Thank you for that. |
I know author. He's one of the pioneers in translating software to Georgian (and my ex-boss from one of projects back 20 years ago) and one of the firsts to make Georgian fonts. We'll have no problem whatsoever doing whatever we wish with his fonts. I can even try to find him/bring him here, but since I'm not living in Georgia for almost 10 years, that would be not an easy task. |
If the source has BSD license, the resulting font is BSD licensed as well. BSD license is not compatible with GPL, but you can distribute kbd with a multi-license: mention that parts of kbd package have a different license. MIT is compatible with GPL. Public Domain license does not request any limitations, so it is possible to distribute such fonts under GPL as well. Agafari was a different issue: It did not allow commercial distribution. So it was not legally possible to distribute kbd (both binaries and sources) for commercial purposes. (But GPL allows that, and disallows further limitations.) Well, it is still possible to ask Ethiopian Science and Technology Commission for GPL license permission. (Several years ago I succeeded with a similar request for Czech data for dasher keyboard.) https://gitlab.gnome.org/GNOME/dasher/-/blob/master/Data/training/training_czech_CS.COPYING Once you render the TTF font into bitmap, there is a project psftools that makes possible to create a kbd compatible font. I used it for kbd fonts analysis and comparison. http://www.seasip.info/Unix/PSF/ |
#127 fixes this, using a different font with clear licensing, I hope - see https://bugzilla.redhat.com/show_bug.cgi?id=2336875#c39 |
We got a bug filed on Fedora/RHEL today - https://bugzilla.redhat.com/show_bug.cgi?id=2336875 - which makes it clear we don't functionally support Georgian with kbd at all. There's no layout, and no console font with Georgian characters. (Georgian seems to be functionally similar to Russian or Greek - it has its own similar-to-Latin-sized alphabet, so we need a console font with those characters, and a "switched" layout to input both the native characters and Latin characters).
console-setup does have both. I have kinda manually derived/reverse-engineered a standalone, "switched" Georgian console layout - switcher key combo is shift+ctrl, as with Russian. I've also figured out how to 'build' complete PSF console fonts with Georgian support from the BDF sources in console-setup (based on the stuff in the Makefile), and confirmed that I can use them to display Georgian characters at a console. But I'm not sure of the licensing/sourcing implications there. The console-setup licensing docs state that all console fonts are "public domain by nature" (not sure what that means), and that the georgian16.bdf source is also "public domain" (in copyright.fonts). Other BDF sources that console-fonts uses to build a complete Georgian console font (with also Latin characters etc.) are either public domain or permissively licensed (MIT / BSD kinda style).
I don't know if we can just take a 'georgian-16.psfu' I build out of console-setup bits, declare that it's public domain, and stuff it in kbd? We might have to ask a lawyer?
Also, the "recipes" console-fonts uses for full Georgian console fonts are:
georgian14.bdf+7x14-IL2.bdf+7x14.bdf+7x14c.bdf+h14.bdf+etl14-unicode.bdf (size 14)
georgian16.bdf+unifont.bdf+h16.bdf+etl16-unicode.bdf (size 16)
the other sources there result in really different rendering for Latin characters from what I'm used to, and it might kinda clash with the other commonly used console fonts in kbd (especially latarcyrheb and eurlatgr). I suppose we could theoretically do something like replacing the Cyrillic characters in latarcyrheb with Georgian characters from georgian16.bdf / georgian14.bdf , calling the result latargeoheb , and shipping that? I'd have to figure out how to do that exactly, of course.
Any thoughts on this? It would be nice to have this support I guess - we now know at least one person wants it.
The text was updated successfully, but these errors were encountered: