* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
@ 2020-04-29 6:43 ` travankor
2020-05-01 12:45 ` bsduck
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: travankor @ 2020-04-29 6:43 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 355 bytes --]
New comment by travankor on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-621019220
Comment:
@bsduck
Can you try this?
Add to `~/.config/fontconfig/fonts.conf`:
```
...
<match target="font">
<edit name="lcdfilter" mode="assign">
<const>lcddefault</const>
</edit>
</match>
...
```
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
2020-04-29 6:43 ` travankor
@ 2020-05-01 12:45 ` bsduck
2020-05-06 4:27 ` ericonr
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: bsduck @ 2020-05-01 12:45 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 173 bytes --]
New comment by bsduck on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-622373407
Comment:
This fixes the problem, indeed.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
2020-04-29 6:43 ` travankor
2020-05-01 12:45 ` bsduck
@ 2020-05-06 4:27 ` ericonr
2020-05-09 12:05 ` travankor
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: ericonr @ 2020-05-06 4:27 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-624435198
Comment:
Should we close this issue or is there anything that can be done in packaging to solve it?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (2 preceding siblings ...)
2020-05-06 4:27 ` ericonr
@ 2020-05-09 12:05 ` travankor
2020-05-09 12:06 ` travankor
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: travankor @ 2020-05-09 12:05 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
New comment by travankor on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-626165884
Comment:
The problem that @bsduck experiences is that you need to specify lcdfilter with the Microsoft ClearType patch, otherwise you get color fringing. Most other distro's don't use ClearType because upstream recommends their non-patented solution ("Harmony") instead (they even claim their solution is better).
@ericonr I haven't done any scientific testing or anything, but I would be ok to `rm` ClearType from the freetype build. The other option might be document this under Font Configuration.
Refs:
-
1. https://www.freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html
2. https://www.freetype.org/freetype2/docs/subpixel-hinting.html
3. https://bugs.archlinux.org/task/60658
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (3 preceding siblings ...)
2020-05-09 12:05 ` travankor
@ 2020-05-09 12:06 ` travankor
2020-05-09 12:06 ` travankor
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: travankor @ 2020-05-09 12:06 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
New comment by travankor on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-626165884
Comment:
The problem that @bsduck experiences is that you need to specify lcdfilter with the Microsoft ClearType patch, otherwise you get color fringing. Most other distro's don't use ClearType because upstream recommends their non-patented solution ("Harmony") instead (they even claim their solution is as good).
@ericonr I haven't done any scientific testing or anything, but I would be ok to `rm` ClearType from the freetype build. The other option might be document this under Font Configuration.
Refs:
-
1. https://www.freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html
2. https://www.freetype.org/freetype2/docs/subpixel-hinting.html
3. https://bugs.archlinux.org/task/60658
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (4 preceding siblings ...)
2020-05-09 12:06 ` travankor
@ 2020-05-09 12:06 ` travankor
2020-07-29 23:31 ` ericonr
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: travankor @ 2020-05-09 12:06 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
New comment by travankor on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-626165884
Comment:
The problem that @bsduck experiences is that you need to specify lcdfilter with the Microsoft ClearType patch, otherwise you get color fringing. Most other distro's don't use ClearType because upstream recommends their non-patented solution ("Harmony") instead (they even claim their solution is as good).
@ericonr I haven't done any scientific testing or anything, but I would be ok to `rm` the ClearType patch from the freetype build. The other option might be document this under Font Configuration.
Refs:
-
1. https://www.freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html
2. https://www.freetype.org/freetype2/docs/subpixel-hinting.html
3. https://bugs.archlinux.org/task/60658
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (5 preceding siblings ...)
2020-05-09 12:06 ` travankor
@ 2020-07-29 23:31 ` ericonr
2020-07-30 5:55 ` mvf
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: ericonr @ 2020-07-29 23:31 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-665982489
Comment:
@travankor Wow, sorry for my delay in getting to this. We added the patch in #13296, by @andry-dev and @Gottox
I agree with the removal of the patch, since it is an upstream recommendation and avoids system breakage, which IMO is what we should strive for. Documenting fixes for an issue that appears because of a patch that we added feels a bit wrong. However, we could have a build option to run `vsed` in the config file and enable ClearType, so anyone who'd like to use it has an easy way to add it to their build.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (6 preceding siblings ...)
2020-07-29 23:31 ` ericonr
@ 2020-07-30 5:55 ` mvf
2020-07-30 10:00 ` andry-dev
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: mvf @ 2020-07-30 5:55 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
New comment by mvf on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-666137216
Comment:
IMHO we should keep the patch. The largest distros have it enabled (Debian/Ubuntu, Fedora, openSUSE). Arch seems to be an outlier here, and some users don't seem too happy about it.
This is a configuration issue. The fix is to let `fontconfig` ship a file that lets `lcdfilter` default to `lcddefault`. Here's `/etc/fonts/conf.d/11-lcdfilter-default.conf` as found on Ubuntu 20.04 and Debian buster:
```xml
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
<its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
</its:rules>
<description>Use lcddefault as default for LCD filter</description>
<!-- Use lcddefault as default for LCD filter -->
<match target="pattern">
<!--
This configuration is available on the major desktop environments.
We shouldn't overwrite it with "assign" unconditionally.
Most clients may picks up the first value only. so using "append"
may simply works to avoid it.
-->
<edit mode="append" name="lcdfilter">
<const>lcddefault</const>
</edit>
</match>
</fontconfig>
```
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (7 preceding siblings ...)
2020-07-30 5:55 ` mvf
@ 2020-07-30 10:00 ` andry-dev
2020-07-30 10:01 ` andry-dev
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: andry-dev @ 2020-07-30 10:00 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
New comment by andry-dev on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-666272488
Comment:
I may be a bit biased (since I'm the author of the patch), but I agree with @mvf.
When I made the patch I had lcdfilter in my `~/.config/fontconfig/fonts.conf` so nothing looked weird for me; shipping a system-wide config file would fix it for everyone.
I noticed that lots of people on Arch install the patched `fontconfig-cleartype` package from the AUR.
Since major distros use it, nobody complains about their font rendering, the font rendering is actually better with it and the fix is just to ship a config file, I think this is a valuable patch that should be kept.
It's my fault for not noticing the need for a system-wide config at the time.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (8 preceding siblings ...)
2020-07-30 10:00 ` andry-dev
@ 2020-07-30 10:01 ` andry-dev
2020-07-30 15:26 ` ericonr
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: andry-dev @ 2020-07-30 10:01 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
New comment by andry-dev on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-666272488
Comment:
I may be a bit biased (since I'm the author of the patch), but I agree with @mvf.
When I made the patch I had lcdfilter in my `~/.config/fontconfig/fonts.conf` so nothing looked weird for me; shipping a system-wide config file would fix it for everyone.
I noticed that lots of people on Arch install the patched `fontconfig-cleartype` package from the AUR.
Since major distros use it, nobody complains about their font rendering, the font rendering is (IMHO) actually better with it and the fix is just to ship a config file, I think this is a valuable patch that should be kept.
It's my fault for not noticing the need for a system-wide config at the time.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (9 preceding siblings ...)
2020-07-30 10:01 ` andry-dev
@ 2020-07-30 15:26 ` ericonr
2022-04-16 2:02 ` github-actions
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: ericonr @ 2020-07-30 15:26 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
New comment by ericonr on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-666454568
Comment:
@andry-dev @mvf
I see. If we can fix this with a config file, I'd be fine with the change as well. I mostly want to avoid having broken out of the box setups. Can either of you make a PR for it? I don't think I would be able to properly justify it myself.
That said, Void does have the policy of avoiding patching packages for functionality (kind of like Arch), which makes the fact that bigger distros have it enabled not entirely relevant to us. If possible, I would like to have this change turned into a `vsed` call and conditional installation of the config file, so it can be easily turned into a build option (which can even be enabled by default), but I'm not sure the commiters would agree.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (10 preceding siblings ...)
2020-07-30 15:26 ` ericonr
@ 2022-04-16 2:02 ` github-actions
2022-07-18 2:13 ` github-actions
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: github-actions @ 2022-04-16 2:02 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
New comment by github-actions[bot] on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-1100506668
Comment:
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (11 preceding siblings ...)
2022-04-16 2:02 ` github-actions
@ 2022-07-18 2:13 ` github-actions
2022-08-01 2:14 ` [ISSUE] [CLOSED] " github-actions
2023-02-20 1:13 ` bsduck
14 siblings, 0 replies; 16+ messages in thread
From: github-actions @ 2022-07-18 2:13 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
New comment by github-actions[bot] on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-1186692997
Comment:
Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [ISSUE] [CLOSED] subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (12 preceding siblings ...)
2022-07-18 2:13 ` github-actions
@ 2022-08-01 2:14 ` github-actions
2023-02-20 1:13 ` bsduck
14 siblings, 0 replies; 16+ messages in thread
From: github-actions @ 2022-08-01 2:14 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Closed issue by bsduck on void-packages repository
https://github.com/void-linux/void-packages/issues/21429
Description:
Hello,
RGB subpixel font rendering does not work as expected with GTK programs.
Enabling it in the Xfce settings panel gives a broken rendering across the whole desktop environment. Doing so in Plasma gives a very good rendering in KDE programs but a poor one within GTK programs.
While some other Linux systems fail at this too (Fedora, Mageia), most (including Debian, Manjaro, Solus, openSUSE...) do manage this properly and enabling RGB supixel rendering gives a very good rendering in all programs, both Qt and GTK.
* xuname:
*Void 5.4.35_1 x86_64 GenuineIntel uptodate rF*
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: subpixel rendering is broken in GTK programs
2020-04-28 14:21 [ISSUE] subpixel rendering is broken in GTK programs VoidDuck
` (13 preceding siblings ...)
2022-08-01 2:14 ` [ISSUE] [CLOSED] " github-actions
@ 2023-02-20 1:13 ` bsduck
14 siblings, 0 replies; 16+ messages in thread
From: bsduck @ 2023-02-20 1:13 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 199 bytes --]
New comment by bsduck on void-packages repository
https://github.com/void-linux/void-packages/issues/21429#issuecomment-1436164670
Comment:
Font rendering works properly now. Thank you for fixing.
^ permalink raw reply [flat|nested] 16+ messages in thread