https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Bug ID: 1999078 Summary: Hinting broken for Bitstream Vera/DejaVu in Epiphany Product: Fedora Version: 34 Status: NEW Component: freetype Assignee: mkasik@redhat.com Reporter: ossman@cendio.se QA Contact: extras-qa@fedoraproject.org CC: ajax@redhat.com, caillon+fedoraproject@gmail.com, fonts-bugs@lists.fedoraproject.org, gnome-sig@lists.fedoraproject.org, kevin@tigcc.ticalc.org, mark@net-c.com, mclasen@redhat.com, mkasik@redhat.com, rhughes@redhat.com, rstrode@redhat.com, sandmann@redhat.com Target Milestone: --- Classification: Fedora
Created attachment 1819062 --> https://bugzilla.redhat.com/attachment.cgi?id=1819062&action=edit Screenshot with varying sub pixel placement
Description of problem:
After upgrading from Fedora 33 to Fedora 34, there is some extremely odd hinting bug in Epiphany. The same glyph appears with different amount of hinting in the same line of text, causing a very odd and blurry appearance.
Version-Release number of selected component (if applicable):
freetype-2.10.4-3.fc34.x86_64 bitstream-vera-sans-fonts-1.10-41.fc33.noarch dejavu-sans-fonts-2.37-16.fc34.noarch epiphany-40.3-1.fc34.x86_64 webkit2gtk3-2.32.3-1.fc34.x86_64 pango-1.48.9-2.fc34.x86_64
How reproducible:
100%
Steps to Reproduce: 1. Configure Epiphany to use Bitstream Vera or DejaVu Sans Book 2. Configure full hinting
Actual results:
Fully hinted, consistent glyphs.
Expected results:
Some glyphs are fully hinted, some look like they've been offset by a fraction of a pixel. (See screenshot)
Additional info:
So far I'm only seeing this in Epiphany. I still filed this for freetype since as far as I know it is freetype that does all glyph layout, hinting and sub-pixel stuff. Feel free to move as appropriate. So it seems odd that a bug in Epiphany can screw this up.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Pierre Ossman ossman@cendio.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Hinting broken for |Hinting strangely broken in |Bitstream Vera/DejaVu in |Epiphany |Epiphany |
--- Comment #1 from Pierre Ossman ossman@cendio.se --- Doesn't seem to be font specific. I tried a few variants of Ubuntu's font as well, and see similar problems there.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Marek Kašík mkasik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value
--- Comment #2 from Marek Kašík mkasik@redhat.com --- Hi,
could you point me to a specific web page where you see the issue? What size of the font do you have set?
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #3 from Pierre Ossman ossman@cendio.se --- I noticed it in Slack, which is what I primarily use Epiphany for since it has the best "Web App" functionality. However I can also see it on our company page: https://www.cendio.com/
This is with the following custom stylesheet:
- { font-family: sans-serif;
}
pre { font-family: monospace !important; }
pre * { font-family: monospace; }
Without that it picks some other fonts that are poorly hinted so it's difficult to tell what works from what doesn't.
The "Use custom fonts" setting has no effect on the page for me, but in case it is relevant for you I have the following settings with it enabled:
* Sans serif font: Sans Regular 12 * Serif font: Serif Regular 12 * Monospace font: Monospace Regular 12
I'll attach a screenshot with how that page renders for me.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #4 from Pierre Ossman ossman@cendio.se --- Created attachment 1819109 --> https://bugzilla.redhat.com/attachment.cgi?id=1819109&action=edit screenshot of https://www.cendio.com
Note the section on the left where "ThinLinc is..." starts properly hinted and then goes blurry.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #5 from Marek Kašík mkasik@redhat.com --- Thank you for the info. Unfortunately, I still can not reproduce this. How do you set the full hinting?
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #6 from Pierre Ossman ossman@cendio.se --- Unfortunately every upgrade of the font system tends to disable more and more hinting, so I have quite a few settings in place. I have not checked which are relevant here and which aren't.
The modifications I've done are:
* In GNOME Tweaks, configure the Fonts section to "Hinting: Full" and "Antialiasing: Standard (greyscale)"
* In .bashrc I have "export FREETYPE_PROPERTIES=truetype:interpreter-version=35"
* I've added a fontconfig override as ~/.config/fontconfig/conf.d/99-hinting-full.conf:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig> <match target="pattern"> <edit name="hintstyle" mode="assign"><const>hintfull</const></edit> </match> </fontconfig>
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #7 from Pierre Ossman ossman@cendio.se --- Also note that this still doesn't achieve full hinting for OTF/CFF fonts (bug 1545149), so if Epiphany is choosing such fonts on your system, for some reason, then you might not see the issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Marek Kašík mkasik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|mkasik@redhat.com |mcatanza@redhat.com Component|freetype |epiphany CC| |gecko-bugs-nobody@fedorapro | |ject.org, | |jhorak@redhat.com, | |mcatanza@redhat.com, | |peter@hatina.eu, | |tpopela@redhat.com
--- Comment #8 from Marek Kašík mkasik@redhat.com --- Hi Pierre,
after some testing I am able to reproduce the issue to some extent with pango-view. The reproducer looks like this:
FREETYPE_PROPERTIES=truetype:interpreter-version=35 pango-view --dpi 72 --text="ThinLinc is a software" --font="dejavu sans book 14" --antialias=gray --hinting=full --subpixel-positions --backend=cairo
The important part of that is "--subpixel-positions", it enables pango to position glyphs on non-integral positions. Epiphany seems to do the same (but differently). Since v35 interpreter does not support subpixel hinting the glyphs looks blurry at some parts of the text.
There is nothing I can do with this in freetype. Default interpreter is v40 now and it supports subpixel hinting (although I see that you prefer the old one).
I'm reassigning this bug to Epiphany with question whether there is a possibility to turn of sub-pixel positioning of glyphs?
Regards
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #9 from Pierre Ossman ossman@cendio.se --- Thanks for investigating.
Shouldn't this affect more users of Pango in that case? I'm not seeing this in any other application so far, and I figured Pango is widely used?
(And the v40 engine explicitly doesn't do full hinting horizontally, otherwise I would be fine using that)
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Michael Catanzaro mcatanza@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|epiphany |webkit2gtk3 CC| |erack@redhat.com
--- Comment #10 from Michael Catanzaro mcatanza@redhat.com --- Epiphany doesn't have anything to do with font rendering on web pages. This is 100% handled by WebKit and its dependencies, FreeType, harfbuzz, and Fontconfig. So I'm going to go ahead and reassign this to WebKit I suppose.
(In reply to Pierre Ossman from comment #9)
Thanks for investigating.
Shouldn't this affect more users of Pango in that case? I'm not seeing this in any other application so far, and I figured Pango is widely used?
(And the v40 engine explicitly doesn't do full hinting horizontally, otherwise I would be fine using that)
Pango is not involved here at all. That's only used by the GTK user interface portions of the browser, not used by WebKit.
(In reply to Marek Kašík from comment #8)
I'm reassigning this bug to Epiphany with question whether there is a possibility to turn of sub-pixel positioning of glyphs?
To clarify: you want me to turn *off* subpixel positioning, if it is currently enabled? I think the answer is "no" because all other browsers are doing subpixel positioning nowadays, and so is GTK 4. This implies that at least horizontal hinting must not be performed, since subpixel positioning and horizontal hinting are incompatible. And that further implies that using the v35 interpreter is self-sabotage, since that version of the interpreter does horizontal hinting. Yes?
That said, I'm not actually sure whether WebKit really does subpixel positioning or not. I guess maybe? Most of the relevant code is under Source/WebCore/platform/graphics/freetype or Source/WebCore/platform/graphics/harfbuzz. I have no clue what to look for to find out. Desktop font hinting and antialiasing settings get merged in FontCacheFreeType.cpp using cairo_ft_font_options_substitute(), but of course we have no settings to control subpixel positioning, so I'm not sure whether that happens at all.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #11 from Pierre Ossman ossman@cendio.se --- (In reply to Marek Kašík from comment #8)
There is nothing I can do with this in freetype. Default interpreter is v40 now and it supports subpixel hinting (although I see that you prefer the old one).
Thinking a bit more about this, are you sure this isn't a freetype issue? Epiphany/WebKit must be getting its coordinates from Freetype on how wide glyphs are? And if subpixel hinting isn't done, then those coordinates should be integers?
It's also configured for greyscale antialiasing, not subpixel, which also should mean integer positioning?
To clarify: you want me to turn *off* subpixel positioning, if it is currently enabled? I think the answer is "no" because all other browsers are doing subpixel positioning nowadays, and so is GTK 4. This implies that at least horizontal hinting must not be performed, since subpixel positioning and horizontal hinting are incompatible. And that further implies that using the v35 interpreter is self-sabotage, since that version of the interpreter does horizontal hinting. Yes?
I'm not seeing this in Firefox, nor gedit, which it sounds like I should in that case. Can't really test Chrome since it seems to ignore all font settings and does its own thing...
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #12 from Pierre Ossman ossman@cendio.se --- Created attachment 1819931 --> https://bugzilla.redhat.com/attachment.cgi?id=1819931&action=edit screenshot of chromium
My bad. It was just that Chrome was using other fonts. By overriding the CSS a bit I can get the same font as Epiphany. And the issue does not appear in either Chrome or chromium-91.0.4472.164-1.fc34.x86_64. I've also attached a screenshot in case it is helpful.
So this does seem to be very specific Epiphany or webkit2gtk3 issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #13 from Pierre Ossman ossman@cendio.se --- I tried to pinpoint what in the upgrade caused this, but I'm having problems doing so. Suggestions welcome.
I tried downgrading epiphany to epiphany-3.38.3-1.fc33.x86_64.rpm, but it didn't have any effect.
I then downloaded freetype-2.10.4-1.fc33.x86_64.rpm and webkit2gtk3-2.32.3-1.fc33.x86_64.rpm, unpacked them in a temporary directory and redirected epiphany there using LD_LIBRARY_PATH, but the problem still remains. Even tried pango-1.48.4-1.fc33.x86_64.rpm as well just to make sure.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Nikolaus Waxweiler madigens@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madigens@gmail.com
--- Comment #14 from Nikolaus Waxweiler madigens@gmail.com --- I remember this from Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=824153. I think the solution was to disable subpixel positioning if the TTF v35 engine is active (don't just check for FreeType's HINTING_FULL because the OTF renderer can deal with subpixel positioning just fine).
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #15 from Michael Catanzaro mcatanza@redhat.com --- (In reply to Nikolaus Waxweiler from comment #14)
I remember this from Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=824153. I think the solution was to disable subpixel positioning if the TTF v35 engine is active (don't just check for FreeType's HINTING_FULL because the OTF renderer can deal with subpixel positioning just fine).
The only change in that bug was:
https://chromium.googlesource.com/chromium/src.git/+/0f95346897076c4c2d2c46f...
and I'm not sure what it's doing, but it certainly isn't checking interpreter version.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #16 from Michael Catanzaro mcatanza@redhat.com --- BTW I see no evidence that WebKit is doing subpixel positioning at all. I think I would remember if this feature was added anytime recently, and a quick 'git grep subpixel' shows only results related to subpixel antialiasing.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #17 from Nikolaus Waxweiler madigens@gmail.com --- Linear metrics are advance widths that are the same regardless of pixel size. Before, hinting or just rounding of advance widths would force you to recompute metrics for text after every size (or zoom level) change. It's a simplification you can do when you have subpixel positioning. Isn't it done by Skia?
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #18 from Michael Catanzaro mcatanza@redhat.com --- (In reply to Nikolaus Waxweiler from comment #17)
Linear metrics are advance widths that are the same regardless of pixel size. Before, hinting or just rounding of advance widths would force you to recompute metrics for text after every size (or zoom level) change. It's a simplification you can do when you have subpixel positioning. Isn't it done by Skia?
I have no clue. WebKit doesn't use Skia anyway. It uses harfbuzz, cairo, FreeType, and Fontconfig.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #19 from Pierre Ossman ossman@cendio.se --- Anything I can do in my end to help this progress?
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #20 from Michael Catanzaro mcatanza@redhat.com --- You could try hunting down a font expert to suggest specific code changes in WebKit. We're unlikely to change anything unless somebody suggests a very specific change, and explains exactly why it makes sense to make the change.
So far it has been suggested that we disable subpixel positioning, but I don't think we do any subpixel positioning, and I wouldn't have any clue how to go about disabling it anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #21 from Michael Catanzaro mcatanza@redhat.com --- (Oh, also as I mentioned in comment #10: even if we *were* doing subpixel positioning and I *did* know how to disable that, it seems that's what everyone else is moving to nowadays, so I don't think we would *want* to.)
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #22 from Pierre Ossman ossman@cendio.se --- If this is something that everyone else is doing, then it seems very odd that I'm only seeing the issue in Epiphany? It seems to me that either everyone else has a workaround for this case, or are doing positioning in a way that doesn't cause this issue.
Can I do some test to pinpoint if this is a general webkit2gtk3 issue, or specific to Epiphany?
Is it worth exploring the regression angle, since this worked in Fedora 33? And if so, how? I've tried downgrading the obvious offenders.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #23 from Michael Catanzaro mcatanza@redhat.com --- (In reply to Pierre Ossman from comment #22)
If this is something that everyone else is doing, then it seems very odd that I'm only seeing the issue in Epiphany? It seems to me that either everyone else has a workaround for this case, or are doing positioning in a way that doesn't cause this issue.
My guess: something in WebKit's font rendering code doesn't work well with the font settings you've configured. WebKit either does this something worse, or just differently than other software that you use. But I really have no way to know what that something is. There are no Linux font experts working on WebKit who I can pass this issue to, which is why I haven't moved this bug to WebKit Bugzilla.
Can I do some test to pinpoint if this is a general webkit2gtk3 issue, or specific to Epiphany?
Epiphany doesn't have much control over fonts or web content, so no point in pursuing that angle. ;) All it can do is change the the default fonts and font sizes that get passed to WebKit, if you modify the settings in the Appearance settings panel. But I doubt that's that's relevant to your issue.
Is it worth exploring the regression angle, since this worked in Fedora 33? And if so, how? I've tried downgrading the obvious offenders.
Yeah sure, if you can find this is caused by some package update, that would be very interesting. That said, the version of WebKitGTK available in F33 and F34 should be identical. I see you've already tried downgrading FreeType and WebKitGTK. Next I would try, in order of most likely culprit to least-likely: cario, harfbuzz, and Fontconfig. If it's not due to any of those, then I don't know.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #24 from Marek Kašík mkasik@redhat.com --- Hi,
I had a look at where the subpixel positioning comes from. I've found out that the subpixel positioning was added to cairo 1.17.4 and indeed reverting it shows the result Pierre expects. It was added in these commits:
https://gitlab.freedesktop.org/cairo/cairo/-/commit/ea9329215d3431ded51a71b7... https://gitlab.freedesktop.org/cairo/cairo/-/commit/6fd4222ab00c3b93f038172a... https://gitlab.freedesktop.org/cairo/cairo/-/commit/e4a79db0108be6a2b06dfce5... https://gitlab.freedesktop.org/cairo/cairo/-/commit/52a7c79fd4ff96bb5fac175f...
Pierre, could you test this scratch build of cairo, whether it shows what you expect?
https://koji.fedoraproject.org/koji/taskinfo?taskID=75665713
I would like to point out that reverting it is not a fix, I've created the scratch build just to confirm that we see the same issue. I'll reassign it to cairo if the answer is "yes".
Regards
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #25 from Pierre Ossman ossman@cendio.se --- Sorry for the delay here. I'm trying to set up a VM so I can play around more freely with things. However I'm having trouble getting epiphany to respect the settings properly. It's still not doing full hinting, even with the modifications from comment 6. So there must be something else I've done to my workstation. Everything else is fully hinted, just not Epiphany.
Marek, were you able to get Epiphany to render things the way I'm seeing? And if so, with what changes?
On the plus side, I'm seeing something similar in GNOME Software, which supports the idea that this is not specific to Epiphany. However it doesn't have the per-character behaviour, but rather per paragraph. It is also misplacing things vertically, rather than horizontally. But wouldn't that cause issues with "modern" hinting as well, as that still hints vertically? If so, then it is perhaps a general bug rather than incompatibility with full hinting.
I'll attach a screenshot of what I'm seeing with GNOME software.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #26 from Pierre Ossman ossman@cendio.se --- Created attachment 1823810 --> https://bugzilla.redhat.com/attachment.cgi?id=1823810&action=edit screenshot of gnome software
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #27 from Pierre Ossman ossman@cendio.se --- Never mind, that was some oddity with DejaVu. Installing Bitstream got more consistent behaviour.
I tried that special build of Cairo, and it does indeed seem to be it. With that applied I'm getting correct rendering in both Epiphany and GNOME software.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Marek Kašík mkasik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otte@redhat.com Component|webkit2gtk3 |cairo Assignee|mcatanza@redhat.com |otte@redhat.com
--- Comment #28 from Marek Kašík mkasik@redhat.com --- Thank you for the confirmation. I'm reassigning this to cairo for their consideration.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #29 from Michael Catanzaro mcatanza@redhat.com --- I doubt you'll get any response from the package maintainer here. You'll probably need to take this to upstream.
That said, be prepared to be told that subpixel antialiasing is the new hotness, and horizontal hinting (as performed by the v35 interpreter) is just going to look bad.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #30 from Pierre Ossman ossman@cendio.se --- Sure, filed here: https://gitlab.freedesktop.org/cairo/cairo/-/issues/511
And as noted, vertical hinting also seems to be affected so this should be a general issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #31 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=1999078
Pierre Ossman ossman@cendio.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|34 |36
--- Comment #32 from Pierre Ossman ossman@cendio.se --- I'm afraid this issue remains. Tested with:
epiphany-42.2-1.fc36.x86_64 cairo-1.17.6-1.fc36.x86_64 webkit2gtk3-2.36.1-1.fc36.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #33 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=1999078
Ludek Smid lsmid@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |EOL Last Closed| |2023-05-25 18:18:20
--- Comment #34 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=1999078
Pierre Ossman ossman@cendio.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |NEW Version|36 |38 Resolution|EOL |--- Keywords| |Reopened
--- Comment #35 from Pierre Ossman ossman@cendio.se --- The issue remains, unfortunately. I've moved the discussion upstream, though, so let's continue there:
https://bugs.webkit.org/show_bug.cgi?id=260196
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Fedora Admin user for bugzilla script actions fedora-admin-xmlrpc@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|otte@redhat.com |klember@redhat.com
--- Comment #36 from Fedora Admin user for bugzilla script actions fedora-admin-xmlrpc@fedoraproject.org --- This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #37 from Aoife Moloney amoloney@redhat.com --- This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 '38'.
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 38 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=1999078
Pierre Ossman ossman@cendio.se changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|38 |39
--- Comment #38 from Pierre Ossman ossman@cendio.se --- Still broken, unfortunately.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #39 from Michael Catanzaro mcatanza@redhat.com --- Note that in WebKitGTK 2.45/2.46 the font rendering backend has changed from cairo to skia, so this bug report will no longer be relevant, and also not reproducible unless you can find a way to trigger it without using WebKitGTK.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #40 from Pierre Ossman ossman@cendio.se --- That's hopeful. Fedora 39 has WebKitGTK 2.44. Does Fedora 40 have the new version?
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #41 from Michael Catanzaro mcatanza@redhat.com --- I'm building it for rawhide now. It'll hit stable Fedoras in September.
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
--- Comment #42 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=1999078
Aoife Moloney amoloney@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |EOL Last Closed|2023-05-25 18:18:20 |2024-11-27 21:00:34
--- Comment #43 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