https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Bug ID: 1833858 Summary: Hangul Jamo is seperated and printed respectively Product: Fedora Version: 32 Status: NEW Component: google-droid-fonts Assignee: nicolas.mailhot@laposte.net Reporter: hyunwoo.park@gmail.com QA Contact: extras-qa@fedoraproject.org CC: fonts-bugs@lists.fedoraproject.org, nicolas.mailhot@laposte.net, oliver@redhat.com, paul@frixxon.co.uk, tremble@tremble.org.uk Target Milestone: --- Classification: Fedora
Created attachment 1687129 --> https://bugzilla.redhat.com/attachment.cgi?id=1687129&action=edit wrong display of Hangul at LibreOffice Writer
Description of problem: When Hangul is output to the monitor, Chosung, Neutral, and Jongseong are output separately.
Version-Release number of selected component (if applicable): Font file, /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf, of google-droid-sans-fonts-20200215-3.fc32.noarch
How reproducible: If you create a test.html containing "가속도" and open the file in the chrome browser, the Korean alphabet will be displayed separately. Or, write "가속도" at LibreOffice Writer and select font as "Droid Sans Fallback".
Steps to Reproduce: 1. write "가속도" at LibreOffece Writer 2. select the text and change font name to "Droid Sans Fallback"
Actual results: The text is displayed like "가ㅅㅗㄱㄷㅗ".
Expected results: Text should be "가속도"
Additional info: https://kldp.org/node/163247
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
hyunwoo.park@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Comment|0 |updated
--- Comment #0 has been edited ---
Created attachment 1687129 --> https://bugzilla.redhat.com/attachment.cgi?id=1687129&action=edit wrong display of Hangul at LibreOffice Writer
Description of problem: When Hangul is output to the monitor, Chosung, Neutral, and Jongseong are output separately.
Version-Release number of selected component (if applicable): Font file, /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf, of google-droid-sans-fonts-20200215-3.fc32.noarch
How reproducible: If you create a test.html containing "가속도" and open the file in the chrome browser, the Korean alphabet will be displayed separately. Or, write "가속도" at LibreOffice Writer and select font as "Droid Sans Fallback".
Steps to Reproduce: 1. write "가속도" at LibreOffece Writer 2. select the text and change font name to "Droid Sans Fallback"
Actual results: The text is displayed like "가ㅅㅗㄱㄷㅗ".
Expected results: Text should be "가속도"
Additional info: https://kldp.org/node/163247
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #1 from hyunwoo.park@gmail.com --- Created attachment 1687130 --> https://bugzilla.redhat.com/attachment.cgi?id=1687130&action=edit wrong display of Hangul at Google Chorme
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |i18n-bugs@lists.fedoraproje | |ct.org, klember@redhat.com, | |moceap@hotmail.com, | |pnemade@redhat.com, | |psatpute@redhat.com Component|google-droid-fonts |harfbuzz Assignee|nicolas.mailhot@laposte.net |pnemade@redhat.com Doc Type|--- |If docs needed, set a value
--- Comment #2 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Since I doubt Google would have published Droid for more than a decade with borken Hangul, probably a problem shaper side
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #3 from Nicolas Mailhot nicolas.mailhot@laposte.net --- If Droid *is* broken for Hangul guess it will need blacklisting for the corresponding locales
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #4 from Jens Petersen petersen@redhat.com --- Have you tried with google-noto-sans-cjk-ttc-fonts (Noto Sans CJK)?
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #5 from hyunwoo.park@gmail.com --- Created attachment 1687495 --> https://bugzilla.redhat.com/attachment.cgi?id=1687495&action=edit LibreOffice Writer, Noto Sans CJK KR/Droid Sans Fallback
@Jens Petersen, "Noto Sans CJK" works Okey.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #6 from hyunwoo.park@gmail.com --- @Jens Petersen, "Noto Sans CJK *" fonts at google chrome works fine at google chrome browser.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #7 from Parag Nemade pnemade@redhat.com --- Seems some problem in DroidSansFallbackFull.ttf font. I think better we make it optional font installed on the Fedora system?
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #8 from Nicolas Mailhot nicolas.mailhot@laposte.net --- If part of DroidSansFallbackFull is bad we have mecanisms to blacklist those parts but before doing that it would be nice if the shaper guys could tell us if the problem is font file or shaper side, and what locales need blacklisting)
Given that we are talking about a font family that was the default Android font family for years, that the biggest Android seller is Samsung, and Samsung is a Korean company, hitting problems on Hangul font file side would be rather surprising
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Parag Nemade pnemade@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|harfbuzz |google-droid-fonts Assignee|pnemade@redhat.com |nicolas.mailhot@laposte.net
--- Comment #9 from Parag Nemade pnemade@redhat.com --- In LibreOffice Writer, text "가속도" gets rendered as "가속도" using Noto Sans CJK KR font but same rendered as "가ㅅㅗㄱㄷㅗ" if Droid Sans Fallback font is used. I also checked with UnDotum font, font family provided by un-core-dotum-fonts.
I think as other Korean fonts proved that text rendering is working fine and same, this is not a shaper issue but issue in DroidSansFallbackFull.ttf font file.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #10 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Hi Parag,
There are many ways to compose the same symbols in OpenType and Unicode, and gh will use it as generic fallback no matter what we do fontconfig side.
Therefore, I would really like the shaper guys to state if the files are totally broken for Hangul, or if it’s just a composition method they didn't implement fully yet. That matters for the long term directions of this package and the other packages that depend on it.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Nicolas Mailhot nicolas.mailhot@laposte.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|google-droid-fonts |harfbuzz Assignee|nicolas.mailhot@laposte.net |pnemade@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #11 from Parag Nemade pnemade@redhat.com --- Let me not be in confused state here. Can you please tell me who are you looking at when you say shaper guys? I can try to ask those people to comment here.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #12 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Probably, harfbuzz upstream, but maybe they’ll tell you this is handled at another level of the stack.
I know that Hangul is a very regular writing system so what Droid does here does not surprise me, the script has been designed to make this kind of decomposition possible. What I would like to know (and that’s pure shaping IMHO) is whether the composition of individual shapes in the font files relies on some dark corner or OpenType Harfbuzz is not supporting yet, of if it uses pre-Unicode composition mecanisms that never made it to the spec and won’t ever be supported
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Parag Nemade pnemade@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Link ID| |Github | |harfbuzz/harfbuzz/issues/24 | |00
--- Comment #13 from Parag Nemade pnemade@redhat.com --- I have reported this issue upstream at https://github.com/harfbuzz/harfbuzz/issues/2400
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Hangul Jamo is seperated |Droid Hangul Jamo is |and printed respectively |separated and printed | |respectively
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #14 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Upstream confirms the font is missing information to assemble the decomposed glyphs.
Therefore, I will ensure it does not match Korean locales in fontconfig. If something explicitly sets Droid for an Hangul run of text, it will still use the font file however. I don’t think we have a technical mechanism to blacklist in that case.
That, would probably require implementing https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/200 and https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/197
Not much point making packaging the fallback font file separately, gh will require it, so it will be present on any system that prints. It really needs handling at the fontconfig level to blacklist reliably.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #15 from Jens Petersen petersen@redhat.com --- So far I could only reproduce this in Fedora 32 (ie not Fedora 31).
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #16 from Akira TAGOH tagoh@redhat.com --- We do.
<fontconfig> <match target="scan"> <test name="family"> <string>Droid Sans Fallback</string> </test> <edit name="lang" mode="assign"> <!-- 3. replace lang property with the result of ops --> <minus> <!-- 2. subtract the given langset from lang property --> <name>lang</name> <langset> <!-- 1. convert string to langset --> <string>ko</string> </langset> </minus> </edit> </match> </fontconfig>
If the decomposed glyphs are really required to satisfy Hangul rendering, it should be reflected to ko.orth instead of the sort of this workaround. Though, needing some feedback about it from native speakers or hangul experts.
Please note that constructing strict and complicated orthograhy file isn't what it is intended for. it should be enumerated for minimal requirements.
Current ko.orth was built based on KS X 1001 character set. that would means Droid Sans Fallback satisfies KS X 1001 but not good enough somehow, for harfbuzz.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #17 from Akira TAGOH tagoh@redhat.com --- My bad. please ignore my comment in the second half. totally misread comments.
What exactly apps really needs to do may be to check capability if they have otlayout:hang and/or otlayout:jamo perhaps.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #18 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Akira, after removing the locale in the font specific setup I did intend to look at the generic orth part. I did not want to imply the korean orth was broken before checking it myself. You did it, thank you very much, that confirms other Droid-like fonts may be matched fontconfig-side for Hangul even though are too incomplete for the shaper to make use of them.
Anyway, given what harfbuzz upstream wrote, fontconfig should probably either only match a Korean locale for fonts that include precomposed Korean glyphs, or for fonts that include decomposed glyphs and otlayout:hang. I’m quite sure apps don’t want to get into the business of comparing langs to otlayouts, for every lang that relies on an otlayout, that would require separate matching lists in every single app for every locale that does this, which would be insane. This kind of filtering belongs in fontconfig.
However, even if we fix font filtering for hangul in a generic way in fontconfig, there still remains the need to explicitly blacklist Droid if selected by the user. We don’t have a good mechanism for that, that’s the key difference between https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/197
and just hiding the lang for Droid.
Anyway I will keep this bug open for the local partial fix (hiding korean lang for droid in the droid package). But you probably need to open some generic issues fontconfig side.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #19 from Nicolas Mailhot nicolas.mailhot@laposte.net --- Jens, F32 droid is a huge refresh over F31 droid:
1. the fontconfig file was completely rewritten and revised, using what we learnt in the past decade 2. the font files were switched to the latest upstream version. That required writing a script to dig in the 2 GiB of upstream android repository
So both 1. and 2.can create changes, independent of generic changes in our font processing stack. And 1. and 2. can not be easily untangled, the fontconfig rewrite was triggered by the fact the git trawling script was finding new font file splits in the android upstream repo.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #20 from Akira TAGOH tagoh@redhat.com --- Sure. but please be aware that what we need to fix at the end is apps (or rendering/layout libarary requriing a font to draw) since they do query to fontconfig what the best font is for.
lang property represents the glyph coverage. precomposed glyphs aren't necessarily needed to represent Hangul if they have hang script tag as supported OpenType layout. in that sense, they don't meet criteria as "minimal" requirement to add them into orth. so if those libraries requires it to render Hangul properly, they should make sure if fonts has otlayout:hang otherwise blacklist them.
Unfortunately capability property isn't supposed to affect score in fontconfig to find out the best font. if this is really needed, it should be implemented indeed. but it isn't the sort of one-stop, anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Shin Jae Wook jashin@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jashin@redhat.com
--- Comment #21 from Shin Jae Wook jashin@redhat.com --- Hi,
This bug exists on Fedora 33 as well.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|harfbuzz |google-droid-fonts Version|32 |33 Assignee|pnemade@redhat.com |nicolas.mailhot@laposte.net
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Luke Hutchison luke.hutch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke.hutch@gmail.com
--- Comment #22 from Luke Hutchison luke.hutch@gmail.com --- Korean text renders fine in Droid Sans, but not with Droid Sans Fallback. Does Droid Sans contain fully-composed Korean characters, or is it falling back to a font like Noto rather than Droid Sans Fallback?
The google-droid-sans-fonts package is depended upon by many packages on Fedora, so removing the entire package is often simply not an option.
What is the best fix?
1. Removing DroidSansFallbackFull.ttf from the google-droid-sans-fonts package
2. Removing the jamo from DroidSansFallbackFull.ttf
3. Copying the fully-composed Korean characters from Droid Sans (or whatever font it is falling back to, e.g. Noto) into DroidSansFallbackFull.ttf
4. Copying any useful fallback characters in DroidSansFallbackFull.ttf into DroidSans.ttf
Broader questions: Why does font rendering fall back to a font that doesn't even contain the required fully-composed Korean characters? Is the font determined valid for fallback simply because it contains jamo, even though it doesn't contain fully-composed Korean characters? What library makes the font fallback decisions these days, based on the required glyphs -- is it HarfBuzz or FontConfig or something else?
Surely if Korean font rendering is required, a font that contains jamo but not full characters should only be selected if it is the only font on the system that has any sort of Korean characters at all.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #23 from Luke Hutchison luke.hutch@gmail.com --- PS Droid Sans Fallback is often selected as the sans fallback font by Chrome on Fedora, and since the droid-sans-fonts package is default on Fedora (or at least a dependency of many other packages), this font frequently breaks Web browsing in Korean on Fedora -- so it's a pretty visible bug.
Even within a single sentence, some words (words starting with 가) fall back to Droid Sans Fallback, and some fall back to Noto Sans CJK. See a depiction of this pattern here:
https://github.com/harfbuzz/harfbuzz/issues/3003
The reason for this is probably that 가 is the pronunciation of the first jamo in the Korean alphabet, so it is used when spelling out bullet points etc. (equivalent to A, B, C, ...), and I'm guessing that Droid Sans Fallback contains the phonetic spelling of each jamo such as 가. So the fallback decision is made based on the first character in each word (at least in Google Docs, which probably calls the font measuring API for each word in a sentence, triggering a fallback decision for each word).
This indicates that the fallback logic can be improved. Currently the fallback determination seems to be being made based on the first Unicode codepoint in a span of text submitted for shaping. Is that a correct assumption?
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #24 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #25 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #26 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #27 from Luke Hutchison luke.hutch@gmail.com --- Still an issue in Fedora 34. Can somebody please bump the version number?
Is there some way to flag Droid Sans Fallback so that it is never used to display characters in the Hangeul range?
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|33 |34
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #28 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #29 from Luke Hutchison luke.hutch@gmail.com --- Still an issue in Fedora 35, but I don't have rights to update the Version field of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
hyunwoo.park@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|34 |35
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
hyunwoo.park@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|35 |36
--- Comment #30 from hyunwoo.park@gmail.com --- I have upgraded fedora 36 from fedora 35. And, the issue seems to be present at fedora 36.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nicolas.mailhot@laposte.net |aekoroglu@linux.intel.com
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #31 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Ludek Smid lsmid@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |EOL Last Closed| |2023-05-25 19:27:19
--- Comment #32 from Ludek Smid lsmid@redhat.com --- Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.
Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field.
If you are unable to reopen this bug, please file a new report against an active release.
Thank you for reporting this bug and we are sorry it could not be fixed.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
hyunwoo.park@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|EOL |--- Version|36 |39 Status|CLOSED |ASSIGNED Keywords| |Reopened
--- Comment #33 from hyunwoo.park@gmail.com --- This issue appears in Fedora Linux 39.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #34 from hyunwoo.park@gmail.com --- I have fedora 39. And, same issue appears.
With following ~/.fonts.conf, the issue disappears.
[hyonwoo.park@details ~]$ cat /etc/fedora-release Fedora release 39 (Thirty Nine) [hyonwoo.park@details ~]$ rpm -qf /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf google-droid-sans-fonts-20200215-17.fc39.noarch [hyonwoo.park@details ~]$ cat .fonts.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> <fontconfig>
<selectfont> <rejectfont> <pattern> <patelt name="family" > <string>Droid Sans Fallback</string> </patelt> </pattern> </rejectfont> </selectfont>
</fontconfig> [hyonwoo.park@details ~]$
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
--- Comment #35 from Aoife Moloney amoloney@redhat.com --- This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Aoife Moloney amoloney@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |EOL Status|ASSIGNED |CLOSED Last Closed|2023-05-25 19:27:19 |2024-11-27 20:59:36
--- Comment #36 from Aoife Moloney amoloney@redhat.com --- Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26.
Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field.
If you are unable to reopen this bug, please file a new report against an active release.
Thank you for reporting this bug and we are sorry it could not be fixed.
fonts-bugs@lists.fedoraproject.org
-
bugzilla＠redhat.com