Created attachment 1477421 [details] fedora-29-welcome-georgian-replacement-character.png When installing: Fedora-Workstation-netinst-x86_64-29-20180820.n.1.iso in qemu, on the welcome page I see: Ქართული Georgian i.e. the first character of the word “Georgian” in Georgian language seems to be shown as a replacement box showing only the code point U+1CA5. 1CA5;GEORGIAN MTAVRULI CAPITAL LETTER KHAR;Lu;0;L;;;;;N;;;;10E5; Maybe there is no suitable font?
This character seems to be new in Unicode 11.0.0
$ fc-list :charset=1CA5 lists nothing for me on my Fedora 29 system. (It lists all fonts I have installed supporting that character).
Created attachment 1496705 [details] Fedora 29 Screenshot
it may be related to #1530086 kind of issue. Once you selected Georgian, then you are able to see Right Top corner with missing glyphs too with Unicode: 1C98, 1CA1, 1CA9 1C90 1C93 1C92, 1C9B etc. Fonts were good on other screen. Tested with ISO: Fedora-Workstation-Live-x86_64-29-20181021.n.0.iso
(In reply to A S Alam from comment #4) > it may be related to #1530086 kind of issue. > Once you selected Georgian, then you are able to see Right Top corner with > missing glyphs too with Unicode: 1C98, 1CA1, 1CA9 1C90 1C93 1C92, 1C9B etc. > Fonts were good on other screen. > > Tested with ISO: Fedora-Workstation-Live-x86_64-29-20181021.n.0.iso We might not have a font supporting U+1CA5 in Fedora at all.
It is surprising then that neither bpg-sans-fonts or google-noto-sans-georgian-fonts cover the glyph(s).
Could we please reassign this to something else. If the fonts are not part of the Fedora now then Anaconda is not the correct component to handle that.
The Georgian script became bicameral in Unicode 11, but the problem is that the new letters are NOT used in title case. The Mtavruli capitals were introduced for all caps emphasis styling, so the auto capitalization function should not be used for Georgian texts. See https://www.unicode.org/reports/tr44/#Change_History (under UnicodeData.txt for Unicode 11). (In reply to Jens Petersen from comment #6) > It is surprising then that neither bpg-sans-fonts or > google-noto-sans-georgian-fonts cover the glyph(s). There is a work around for Noto fonts: https://github.com/googlefonts/noto-fonts/issues/1261 Here you can get bpg-fonts that support Mtavruli: https://bpgfonts.wordpress.com/2018/09/07/gnu-gpl-license-grant-to-linux-distributors/
So anaconda should make an exception for Georgian not to automatically capitalize the first letter.
(In reply to Mike FABIAN from comment #9) > So anaconda should make an exception for Georgian not to automatically > capitalize the first letter. Shouldn't that be handled elsewhere?
bpg-fonts-20120413-14.fc32 just built in rawhide, it includes the newer bpg versions of DejaVu indicated in Comment #8. If I need to also build this for stable branches, please let me know.
(In reply to Jens Petersen from comment #10) > (In reply to Mike FABIAN from comment #9) > > So anaconda should make an exception for Georgian not to automatically > > capitalize the first letter. > > Shouldn't that be handled elsewhere? I guess this code does it: https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/localization.py#L315 def get_native_name(locale): """ Function returning native name for the given locale. :param locale: locale to return native name for :type locale: str :return: english name for the locale or empty string if unknown :rtype: st :raise InvalidLocaleSpec: if an invalid locale is given (see LANGCODE_RE) """ parts = parse_langcode(locale) if "language" not in parts: raise InvalidLocaleSpec("'%s' is not a valid locale" % locale) name = langtable.language_name(languageId=parts["language"], territoryId=parts.get("territory", ""), scriptId=parts.get("script", ""), languageIdQuery=parts["language"], territoryIdQuery=parts.get("territory", ""), scriptIdQuery=parts.get("script", "")) return upcase_first_letter(name) So it upper cases the first letter of the language name. For almost all languages, this is what we want if the name appears isolated in a list, it is sort of like at the start of a sentence then. For languages which don’t have uppercase letters (like Japanese for example), the uppercasing changes nothing. Georgian seems special in that uppercase letters are available, but apparently they are not supposed to be used in title case.
So it looks like we need something like this: $ git diff diff --git a/pyanaconda/localization.py b/pyanaconda/localization.py index 59a58d51f..e642cb5db 100644 --- a/pyanaconda/localization.py +++ b/pyanaconda/localization.py @@ -335,6 +335,8 @@ def get_native_name(locale): territoryIdQuery=parts.get("territory", ""), scriptIdQuery=parts.get("script", "")) + if parts["language"].startswith("ka"): + return name return upcase_first_letter(name) def get_available_translations(localedir=None): lines 1-13/13 (END) which looks crazy, but what else could one do?
The question is if we should use other fonts which would work or to change Anaconda code. Honestly the first variant seems like a less hacky to me...
Created attachment 1635300 [details] F32 Live Screenshot
When I install bpg-dejavu-sans-fonts in Live OS, the issue seems to be fixed (see the attachment F32 Live Screenshot). Could someone confirm that this is the expected output? If yes, we need to make sure that the font is installed in the boot.iso (handled by lorax) and Live images (handled by spin-kickstarts). Anaconda doesn't install any fonts.
(In reply to Jiri Konecny from comment #14) > The question is if we should use other fonts which would work or to change > Anaconda code. Honestly the first variant seems like a less hacky to me... The first option is a short-term workaround. The way Georgian has been standardized Unicode-side is not expected to change. So if anaconda does not handle it properly, the issue will come back in a few releases when the Fedora font set gets updated.
(In reply to Nicolas Mailhot from comment #17) > (In reply to Jiri Konecny from comment #14) > > The question is if we should use other fonts which would work or to change > > Anaconda code. Honestly the first variant seems like a less hacky to me... > > The first option is a short-term workaround. The way Georgian has been > standardized Unicode-side is not expected to change. So if anaconda does not > handle it properly, the issue will come back in a few releases when the > Fedora font set gets updated. Don't you think that this problem is bigger than Anaconda? Anaconda is just one of the projects but all the projects supporting Georgian may experience the same issue. I don't think it's reasonable to fix one case instead of fixing the root cause here.
Yes, sure, it’s bigger than a font or Anaconda, it’s how Georgian is expected to behave, and how it got standardised
(In reply to Vendula Poncova from comment #16) > When I install bpg-dejavu-sans-fonts in Live OS, the issue seems to be fixed > (see the attachment F32 Live Screenshot). Could someone confirm that this is > the expected output? If yes, we need to make sure that the font is installed > in the boot.iso (handled by lorax) and Live images (handled by > spin-kickstarts). Anaconda doesn't install any fonts. The text on the right top corner (Fedora's installation) is correctly shown in Georgian, as long as it's all caps. But the word "Georgian" in the language menu is inaccurate, because titlecasing is not expected in modern Georgian. (In reply to Mike FABIAN from comment #9) > So anaconda should make an exception for Georgian not to automatically > capitalize the first letter. Yes, automatic capitalization just should not be applied to Georgian text. A localizer can decide, whether or not to use uppercase for emphasis. > (In reply to Jens Petersen from comment #6) > > It is surprising then that neither bpg-sans-fonts or > > google-noto-sans-georgian-fonts cover the glyph(s). > > There is a work around for Noto fonts: > https://github.com/googlefonts/noto-fonts/issues/1261 > Here you can get bpg-fonts that support Mtavruli: > https://bpgfonts.wordpress.com/2018/09/07/gnu-gpl-license-grant-to-linux- > distributors/ Now Google Noto fonts also include Mtavruli characters (updated 2 months ago): https://github.com/googlefonts/noto-fonts/tree/master/hinted/NotoSansGeorgian
Problem still exists on F32.
Is there a python library that provides an appropriate title case function?
Will making bpg-dejavu-sans-fonts default in the @fonts group cause any problems?
No, because bpg-dejavu-sans-fonts is not a complete fork of dejavu, it is missing other parts. Also, bpg-dejavu-sans-fonts is quite shaky legal-wise, the Georgian dev is completely clueless about licensing, I’m not sure its GPL use is compatible with the licensing in the other parts of dejavu, and even if it is, there are good reason we are not using the GPL for font files (it would make documents, that embed font parts, such as ODF or PDF, GPL, which is definitely not what our users need). We really need someone to revive the upstream dejavu project and restart merging fixes and enhancements, since the original authors lost the drive. (Can’t really blame them when downstreams like Fedora Workstation removed DejaVu as default font just because it was steady and “boring”).
(In reply to Nicolas Mailhot from comment #24) > No, because bpg-dejavu-sans-fonts is not a complete fork of dejavu, it is > missing other parts. > > Also, bpg-dejavu-sans-fonts is quite shaky legal-wise, the Georgian dev is > completely clueless about licensing, I’m not sure its GPL use is compatible > with the licensing in the other parts of dejavu, and even if it is, there > are good reason we are not using the GPL for font files (it would make > documents, that embed font parts, such as ODF or PDF, GPL, which is > definitely not what our users need). Sounds like Noto Georgian may be a better bet then. Not to mention the BPG family names typos. > We really need someone to revive the upstream dejavu project and restart > merging fixes and enhancements, since the original authors lost the drive. That would be great indeed. > (Can’t really blame them when downstreams like Fedora Workstation removed > DejaVu as default font just because it was steady and “boring”). That is not completely accurate, Dejavu is still default, just not for Gnome UI chrome. (And that was encouraged by Gnome, not particularly Fedora Workstation.)
Hello, One thing I can tell - we don't have a case in Georgian alphabet, some fonts include uppercase characters, some don't, but they are not really uppercase, they're just another set of glyphs or fonts inserted in the collection. They never should be mixed - we don't do that. Georgian devs are not clueless about licensing, we've been in quite long strict discussions about it since 2004. I have direct contact with all original font developers (Including mentioned BPG), so, I can check anything we need. Dejavu family includes fonts originally created by BPG, and Georgian LUG members were quite careful when we've asked him to include his works and release them as GPL licensed so we could include it in Linux distributions. Same applies to the keyboard layouts - that was done at the same time... What exactly is the case? How can I help?
direct answer to this issue is to have all characters in lowercase, because this is how Georgian language works - WE DON"T HAVE UPPERCASE characters, don't use them.
It's a good idea to switched to Google Noto as a default font for Georgian, or use it as an alternative to BPG. P.S. We use Mtavruli characters almost everywhere and we definitely need them. You can see a lot of examples at the end of this document: https://www.unicode.org/L2/L2016/16034-n4707-georgian.pdf See also this Q&A: https://www.unicode.org/L2/L2017/17045-georgian-resp.pdf In modern Georgian, Mtavruli is not used for mixed/title casing, only with the All Caps function, but it does NOT mean, that we don't have uppercase or they are not capital letters.
Not that we just don't use them, WE DON'T HAVE THEM, therefore, we don't have mixed casing at all. There are no capital letters. "Mtavruli" is just a representation, it's not a case or capitalization. You can read it in attached document "Mtavruli-style letters are never used as “capitals”; a word is always entirely presented in mtavruli or not"
+ Georgian glyphs in Google Noto are terrible and inadequately large when compared to other fonts containing Georgian glyphs and VERY large compared to glyphs written in Latin with the same Google Noto. Probably, that's the reason why nobody uses it here :)
@George Machitidze ### Legal aspects Much as I love the GPL and use it for my own projects it does not translate well to font files. From a legal point of view, software is derived into other software, so a license that propagates to derived works like the GPL does, works well. It’s software both parts of the equation. However, fonts can be derived into documents due to how document formats embed fonts (fully or via subsetting). Therefore, the GPL and software licenses in general are completely inadequate for font files. Most people do not want their documents GPLed just because they used a Free and Open font in them. Because the GPL is inadequate, there was quite a lot of experimenting at the start of the century to find a working license for Free and Open fonts. Some proposed font-specific GPL legal extensions. Others wrote brand new experimental licenses. In the end most everyone agreed to use the OFL, which is the font license of most Google fonts today, and the font license Fedora recommends for new font projects. DejaVu antedates all of this however. It is a direct derivative of Bitstream Vera, which was released under one of licenses people experimented with before settling on the OFL. Vera/DejaVu licensing is unlikely to change today because that would require Bitstream cooperation and probably quite a lot of money to motivate the Bistream legal department to look at it. When adding to or modifying Vera or DejaVu, you should strive to keep things simple and integrate the original Vera/DejaVu legal framework. DejaVu licensing is complex and one-of-a-kind due to the inadequacies of the original experimental Bitstream licensing. It’s not as simple as using vanilla GPL for software or the OFL for new font projects. https://github.com/dejavu-fonts/dejavu-fonts/blob/master/LICENSE When the DejaVu project was active it served as legal clearing house and made sure contributors understood and and agreed with those legal clauses. Now it is dormant, people that release DejaVu derivatives must do this work themselves. ### Font coverage aspect From a font file point of view the only thing we can do is try to integrate fonts with correct opentype metadata and correct unicode coverage. It is no use, as you wrote, to remove coverage from font files. Software that wants to use specific code-points will just fall back to fonts that include this coverage. If you want to prevent those fallbacks the only reliable way is to integrate good coverage in your font file so the fallback need not happen. If things still do not work after a font with good unicode coverage was deployed, then that means: 1. some piece or text rendering is making mistakes when applying the unicode standard. No use work-arrounding the standard by using incomplete or non-compliant font files here, you need to identify which part is misapplying the standard and get it fixed 2. the Unicode standard is wrong. Well, I sort of doubt this is the case here, but human creations are imperfect by nature. If the standard is wrong then you need to get it fixed because software implementers are applying the standard and do not have time to waste sifting through all the pseudo-standards people keep inventing all over the world. That’s the sole reason people use Unicode today. It is horribly complex, and not ideal, but having to deal with multiple conflicting encoding rules would be way worse. Chinese/Japanese/Korean people yelled for a decade Unicode made the wrong decisions for their scripts. They are using Unicode like everyone else today anyway, because the alternative to Unicode, are way worse from a software interoperability point of view.
@George Machitidze > You can read it in attached document "Mtavruli-style letters are never used as “capitals”; a word is always entirely presented in mtavruli or not" And you can also read the answer: > This statement was not correct. A number of documents from the late 19th century and early 20thcentury make use of mtavruli > characters in initial position in sentences, lines of verse, and for propernames and place-names. For example: https://ka.wikipedia.org/wiki/%E1%83%A5%E1%83%90%E1%83%A0%E1%83%97%E1%83%A3%E1%83%9A%E1%83%98_%E1%83%93%E1%83%90%E1%83%9B%E1%83%AC%E1%83%94%E1%83%A0%E1%83%9A%E1%83%9D%E1%83%91%E1%83%90#/media/%E1%83%A4%E1%83%90%E1%83%98%E1%83%9A%E1%83%98:Deda_Ena_1876_cover.jpg Google Noto fonts are used as default for Georgian in Android and Arch-based distributions. They look nice. You can read here what Besarion thinks about Mtavruli (or ask him, if you have a direct communication) https://bpgfonts.wordpress.com/2016/02/24/mtavruli-for-perfection/
@Nicolas Mailhot Thanks for details 1. If we should ditch DejaVu for legal issues - definitely, it must be done 2. Easy way - so far, only non-DejaVU font I can recommend to be GPL licensed (verified author and font) are from BPG family (https://bpgfonts.wordpress.com/2009/02/03/gpl-gnu-license-bpg-fonts/), If we need any clarification on that - I can contact him. 3. Long way - I can ask all major designers to create a font for us so we can include it somewhere, one of them already responded to my FB post regarding this issue (we have a discussion there). We can request any legal document if there is a concern - they can sign it. 4. I am not really sure about Google Noto - we don't know who is the author, but fonts are terrible and oversized (that's clearly visible) @ALAN I am Georgian, I've founded Georgian linux user group with my friends, I work on localization projects since 2004 (Ministry of Education and Science of Georgia), I am not a Fedora ambassador right now, just because I'm busy and lazy. I know what I am talking about, I'm not arguing. We've faced all these issues in 2004 and the result our work is: 0. Established relation with each-other, which was pretty hard because of different countries authors live (Georgia, Finland), differences in interests (Linux, Mac, Windows fans), difference in directions (RH fans, Canonical fans, KDE fans, GNOME fans), age gap (18 to 60 yo). We've all sat and decided to do the job the right way, usually we fight 1. Created new Georgian keyboard (MESS), included with other four keyboards in OSS XKB etc 2. BPG published fonts in GPL, while other his fonts and fonts from other people (including GEO series from Gia Shervashidze and fonts from Reno Siradze) are also available for free and virtually without limitations 3. Localization of KDE, GNOME, Fedora, Ubuntu, Windows Regarding Google Noto: Google NEVER asked anyone anything, they've even included Keyboard only few years ago, they don't know whom to ask and what to do - they've never reached us or government. Same applies to all their products and all l10n/i18n parts. We've tried, but they don't care. Same applies to Apple and both are now under heavy criticism from users as we are hardly to reading the texts and glyphs. Virtual keyboards also look ugly and are not proportional. We get no response - tried to push issues though representative officials, via government, via Georgian Mac's User Group (some of us are founding members there too) - nothing works. We were able to solve issues only with OSS software and M$. These Google fonts look REALLY BAD. It's hard to see whole picture if you haven't studied Georgian, but one thing you can easily find out - Georgian glyphs in Google Noto are HUGE. proportions are inadequate. Try to write few letters in latin Goto and then the same with Georgian, size is about 1.5 bigger. It's elementary and offensive. Who else are we looking for? If I will ask something like that to Besarioni, definitely, he'll laugh at me and never talk again (he's a man of character).
@George Machitidze The author of Google Noto Georgian is Akaki Razmadze. More info - https://www.marketer.ge/akaki-razmadze-ios13-android-10/ He also designed FiraGO Georgian, which is publicly available under FOSS license. So, I think, you can feel free to contact him. It's a modern-style typeface. Please see Besarion's post on FB https://www.facebook.com/groups/geotypography/permalink/1499502893517216/?comment_id=1500283223439183&comment_tracking=%7B%22tn%22%3A%22R%22%7D Yes, I know who you are (from Tbilisi forum), I am Georgian too.
Good, that's Akaki But font is large: https://drive.google.com/file/d/1rUsmuLRyLCqfenjFMsc73SPe-ZBfSv-C/view?usp=sharing
Yeah, it's based on Latin proportions. Maybe this type of fonts are more compatible for mobile screens. https://i.imgur.com/Qb8rFah.png Besarion has made a comparison of them here: https://bpgfonts.wordpress.com/2009/01/31/%E1%83%9E%E1%83%A0%E1%83%9D%E1%83%9E%E1%83%9D%E1%83%A0%E1%83%AA%E1%83%98%E1%83%94%E1%83%91%E1%83%98-%E1%83%99%E1%83%9A%E1%83%90%E1%83%A1%E1%83%98%E1%83%99%E1%83%A3%E1%83%A0%E1%83%98-%E1%83%93/
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Yes, it still exists in Fedora-Everything-netinst-x86_64-33-20200906.n.0.iso
I have proposed a fix for the installer in the pull request: https://github.com/rhinstaller/anaconda/pull/2837
FEDORA-2020-384ff75a01 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01
FEDORA-2020-384ff75a01 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-384ff75a01` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-384ff75a01 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-384ff75a01 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.