With the update to freetype 2.5 the Infinality patches from namtrac:subpixel can no longer be installed. My understanding was that some functionality of the patches had been upstreamed into freetype 2.5, but at least out-of-the box the font rendering is really ugly. So is there any information on how to get a more usable (or preferrably) identical font rendering with the new library? I really don't want to go back to bitmapped fonts, especially as the ones I liked all have poor UTF-8 support.
Regards, Achim.
On 3 September 2014 02:13, Achim Gratz Stromeko@nexgo.de wrote:
With the update to freetype 2.5 the Infinality patches from namtrac:subpixel can no longer be installed. My understanding was that some functionality of the patches had been upstreamed into freetype 2.5, but at least out-of-the box the font rendering is really ugly. So is there any information on how to get a more usable (or preferrably) identical font rendering with the new library? I really don't want to go back to bitmapped fonts, especially as the ones I liked all have poor UTF-8 support.
Going into YaST's sysconfig editor, go to desktop, USE_LCDFILTER="lcddefault" , FORCE_HINTSTYLE="hintslight". To me at least it looks much better.
Sean writes:
Going into YaST's sysconfig editor, go to desktop, USE_LCDFILTER="lcddefault" , FORCE_HINTSTYLE="hintslight". To me at least it looks much better.
I've removed some changes that I had done when customizing Infinality and things are better now (bold and normal text look different again :-). Still not as good as before, though.
Regards, Achim.
On 02 Sep 20:13, Achim Gratz wrote:
With the update to freetype 2.5 the Infinality patches from namtrac:subpixel can no longer be installed. My understanding was that some functionality of the patches had been upstreamed into freetype 2.5, but at least out-of-the box the font rendering is really ugly. So is there any information on how to get a more usable (or preferrably) identical font rendering with the new library? I really don't want to go back to bitmapped fonts, especially as the ones I liked all have poor UTF-8 support.
FWIW infinality is unmainted atm, but it'll soon get a new maintainer and when it does I'll be updating it.
Regards, ismail
İsmail Dönmez writes:
FWIW infinality is unmainted atm, but it'll soon get a new maintainer and when it does I'll be updating it.
Let me know if you think I could help.
Regards, Achim.
On 03 Sep 11:09, İsmail Dönmez wrote:
On 02 Sep 20:13, Achim Gratz wrote:
With the update to freetype 2.5 the Infinality patches from namtrac:subpixel can no longer be installed. My understanding was that some functionality of the patches had been upstreamed into freetype 2.5, but at least out-of-the box the font rendering is really ugly. So is there any information on how to get a more usable (or preferrably) identical font rendering with the new library? I really don't want to go back to bitmapped fonts, especially as the ones I liked all have poor UTF-8 support.
FWIW infinality is unmainted atm, but it'll soon get a new maintainer and when it does I'll be updating it.
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
Regards, Achim.
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
On Friday 19 September 2014 12:08:06 İsmail Dönmez wrote:
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
Was there some change in policy regarding pattented software on opensuse websites? Couple of years ago it was forbidden to upload those packages to the opensuse domain, that's why it was hosted on opensuse-community and other not official suse websites...
Am Freitag 19 September 2014, 11:55:29 schrieb Stanislav Baiduzhyi:
On Friday 19 September 2014 12:08:06 İsmail Dönmez wrote:
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
Was there some change in policy regarding pattented software on opensuse websites? Couple of years ago it was forbidden to upload those packages to the opensuse domain, that's why it was hosted on opensuse-community and other not official suse websites...
the patent has expired by now, as far as i remember.
On Friday 19 September 2014 12:06:06 Mathias Homann wrote:
Am Freitag 19 September 2014, 11:55:29 schrieb Stanislav Baiduzhyi:
On Friday 19 September 2014 12:08:06 İsmail Dönmez wrote:
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
Was there some change in policy regarding pattented software on opensuse websites? Couple of years ago it was forbidden to upload those packages to the opensuse domain, that's why it was hosted on opensuse-community and other not official suse websites...
the patent has expired by now, as far as i remember.
Why then openSUSE comes with subpixel disabled by default?
http://freetype.org/patents.html According to this page, only hinting has expired, subpixel is still covered by patents.
On Fri, Sep 19, 2014 at 11:55:29AM +0200, Stanislav Baiduzhyi wrote:
On Friday 19 September 2014 12:08:06 İsmail Dönmez wrote:
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
Even https://github.com/yast/yast-fonts is on its way ;).
Petr
On Friday 19 September 2014 12:31:42 Petr Gajdos wrote:
On Fri, Sep 19, 2014 at 11:55:29AM +0200, Stanislav Baiduzhyi wrote:
On Friday 19 September 2014 12:08:06 İsmail Dönmez wrote:
On 19 Sep 09:18, Achim Gratz wrote:
İsmail Dönmez writes:
home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
This is wonderful, thank you very much. Has something changed for the configuration or should I just re-enable the old one?
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
Even https://github.com/yast/yast-fonts is on its way ;).
That's amazing news! Hurry up! I want it already!
Petr
İsmail Dönmez writes:
In my case I had to change /etc/sysconfig/fonts-config to change:
FORCE_HINTSTYLE="hintslight" USE_LCDFILTER="lcddefault" USE_RGBA="rgb"
and run fonts-config afterwards. Also /etc/profile.d/infinality-settings.sh is now much simpler.
I did this and after some further changes it is close to what I had before (as well as I can remember it, anyway). The residual difference is likely due to the color fringe filter, which either didn't exist before or has had a different setting. Since the fringes were quite strong before and are much less noticeably now, I think that's a good thing, after all. :-)
Regards, Achim.
İsmail Dönmez writes:
On 03 Sep 11:09, İsmail Dönmez wrote: home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
The repo is almost empty (save for libfreetype) at the moment and would fall back to Tumbleweed for the other libraries that were formerly provided, is that intended?
Regards, Achim.
On 14 Nov 19:57, Achim Gratz wrote:
İsmail Dönmez writes:
On 03 Sep 11:09, İsmail Dönmez wrote: home:namtrac:subpixel is now updated to FreeType 2.5.3 and latest infinality patchset.
The repo is almost empty (save for libfreetype) at the moment and would fall back to Tumbleweed for the other libraries that were formerly provided, is that intended?
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
Regards, ismail
İsmail Dönmez writes:
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
This is what zypper tells me will happen:
--8<---------------cut here---------------start------------->8--- The following 11 packages are going to be downgraded: cairo-devel 1.14.0-98.1 -> 1.12.16-8.1 libcairo-gobject2 1.14.0-98.1 -> 1.12.16-8.1 libcairo-script-interpreter2 1.14.0-98.1 -> 1.12.16-8.1 libcairo2 1.14.0-98.1 -> 1.12.16-8.1 libqt4 4.8.6-371.1 -> 4.8.6-8.1 libqt4-devel 4.8.6-371.1 -> 4.8.6-8.1 libqt4-linguist 4.8.6-371.1 -> 4.8.6-8.1 libqt4-qt3support 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql-sqlite 4.8.6-371.1 -> 4.8.6-8.1 libqt4-x11 4.8.6-371.1 -> 4.8.6-8.1 --8<---------------cut here---------------end--------------->8---
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
Regards, Achim.
On Friday 14 November 2014 23:28:24 Achim Gratz wrote:
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
There is alternative solution... Will copy pasted some from my G+ post:
# zypper ar http://download.opensuse.org/repositories/home:/TheIndifferent:/fonts-unleas... fonts-unleashed # zypper in fonts-unleashed
Second command will ask couple of questions: 1. Press 't' when asked if you trust the key; 2. Choose option to install with vendor change (in my case it was '1'); 3. Review the changes and press 'y'.
Little more details on what and why can be found here: https://plus.google.com/u/0/110954570004153051295/posts/BF64mmUSmKi
Stanislav Baiduzhyi writes:
On Friday 14 November 2014 23:28:24 Achim Gratz wrote:
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
There is alternative solution... Will copy pasted some from my G+ post:
Thanks, I'll probably try that later on. But the difference only seems to be the additional fontconfig, not the extra libraries that were in the subpixel repo until very recently.
Regards, Achim.
On 14 Nov 23:28, Achim Gratz wrote:
İsmail Dönmez writes:
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
This is what zypper tells me will happen:
--8<---------------cut here---------------start------------->8--- The following 11 packages are going to be downgraded: cairo-devel 1.14.0-98.1 -> 1.12.16-8.1 libcairo-gobject2 1.14.0-98.1 -> 1.12.16-8.1 libcairo-script-interpreter2 1.14.0-98.1 -> 1.12.16-8.1 libcairo2 1.14.0-98.1 -> 1.12.16-8.1 libqt4 4.8.6-371.1 -> 4.8.6-8.1 libqt4-devel 4.8.6-371.1 -> 4.8.6-8.1 libqt4-linguist 4.8.6-371.1 -> 4.8.6-8.1 libqt4-qt3support 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql-sqlite 4.8.6-371.1 -> 4.8.6-8.1 libqt4-x11 4.8.6-371.1 -> 4.8.6-8.1 --8<---------------cut here---------------end--------------->8---
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
ACK this is safe. And the reason for this change is we only need modified freetype2 package now. Rest will dynamically load the needed functionality.
Regards, ismail
İsmail Dönmez writes:
ACK this is safe. And the reason for this change is we only need modified freetype2 package now. Rest will dynamically load the needed functionality.
Thanks for the answer. I had done the upgrade already (and yes, subpixel rendering is still available) since I was keen on trying whether the 3.17.2 kernel would not hang on shutdown. :-) The first exit from KDE went as planned, so I'll keep my fingers crossed.
Regards, Achim.
On Sunday 16 of November 2014 20:54:39 İsmail Dönmez wrote:
On 14 Nov 23:28, Achim Gratz wrote:
İsmail Dönmez writes:
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
This is what zypper tells me will happen:
--8<---------------cut here---------------start------------->8---
The following 11 packages are going to be downgraded: cairo-devel 1.14.0-98.1 -> 1.12.16-8.1 libcairo-gobject2 1.14.0-98.1 -> 1.12.16-8.1 libcairo-script-interpreter2 1.14.0-98.1 -> 1.12.16-8.1 libcairo2 1.14.0-98.1 -> 1.12.16-8.1 libqt4 4.8.6-371.1 -> 4.8.6-8.1 libqt4-devel 4.8.6-371.1 -> 4.8.6-8.1 libqt4-linguist 4.8.6-371.1 -> 4.8.6-8.1 libqt4-qt3support 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql-sqlite 4.8.6-371.1 -> 4.8.6-8.1 libqt4-x11 4.8.6-371.1 -> 4.8.6-8.1
--8<---------------cut here---------------end--------------->8---
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
ACK this is safe. And the reason for this change is we only need modified freetype2 package now. Rest will dynamically load the needed functionality.
AFAIK, Qt still renders fonts differently depending whether FT_CONFIG_OPTION_SUBPIXEL_RENDERING was defined. IOW, Qt built against 'plain' freetype2 and 'patched' freetype2 will not render fonts in the same manner...
Cheers, Hrvoje
Regards, ismail
On 16 Nov 21:22, šumski wrote:
On Sunday 16 of November 2014 20:54:39 İsmail Dönmez wrote:
On 14 Nov 23:28, Achim Gratz wrote:
İsmail Dönmez writes:
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
This is what zypper tells me will happen:
--8<---------------cut here---------------start------------->8---
The following 11 packages are going to be downgraded: cairo-devel 1.14.0-98.1 -> 1.12.16-8.1 libcairo-gobject2 1.14.0-98.1 -> 1.12.16-8.1 libcairo-script-interpreter2 1.14.0-98.1 -> 1.12.16-8.1 libcairo2 1.14.0-98.1 -> 1.12.16-8.1 libqt4 4.8.6-371.1 -> 4.8.6-8.1 libqt4-devel 4.8.6-371.1 -> 4.8.6-8.1 libqt4-linguist 4.8.6-371.1 -> 4.8.6-8.1 libqt4-qt3support 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql-sqlite 4.8.6-371.1 -> 4.8.6-8.1 libqt4-x11 4.8.6-371.1 -> 4.8.6-8.1
--8<---------------cut here---------------end--------------->8---
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
ACK this is safe. And the reason for this change is we only need modified freetype2 package now. Rest will dynamically load the needed functionality.
AFAIK, Qt still renders fonts differently depending whether FT_CONFIG_OPTION_SUBPIXEL_RENDERING was defined. IOW, Qt built against 'plain' freetype2 and 'patched' freetype2 will not render fonts in the same manner...
If I am not mistaken https://build.opensuse.org/package/view_file/KDE:Qt/libqt4/use-freetype-defa... checks for subpixel availability on runtime.
Regards, ismail
On Monday 17 of November 2014 09:27:07 İsmail Dönmez wrote:
On 16 Nov 21:22, šumski wrote:
On Sunday 16 of November 2014 20:54:39 İsmail Dönmez wrote:
On 14 Nov 23:28, Achim Gratz wrote:
İsmail Dönmez writes:
Yes, but this shouldn't result in any functionality change. Let me know if otherwise.
This is what zypper tells me will happen:
--8<---------------cut here---------------start------------->8---
The following 11 packages are going to be downgraded: cairo-devel 1.14.0-98.1 -> 1.12.16-8.1 libcairo-gobject2 1.14.0-98.1 -> 1.12.16-8.1 libcairo-script-interpreter2 1.14.0-98.1 -> 1.12.16-8.1 libcairo2 1.14.0-98.1 -> 1.12.16-8.1 libqt4 4.8.6-371.1 -> 4.8.6-8.1 libqt4-devel 4.8.6-371.1 -> 4.8.6-8.1 libqt4-linguist 4.8.6-371.1 -> 4.8.6-8.1 libqt4-qt3support 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql 4.8.6-371.1 -> 4.8.6-8.1 libqt4-sql-sqlite 4.8.6-371.1 -> 4.8.6-8.1 libqt4-x11 4.8.6-371.1 -> 4.8.6-8.1
--8<---------------cut here---------------end--------------->8---
If you think that's OK, I'll go ahead with the update over the weekend. The version bump for cairo was relatively recent, so I don't think anything depends on it yet.
ACK this is safe. And the reason for this change is we only need modified freetype2 package now. Rest will dynamically load the needed functionality.
AFAIK, Qt still renders fonts differently depending whether FT_CONFIG_OPTION_SUBPIXEL_RENDERING was defined. IOW, Qt built against 'plain' freetype2 and 'patched' freetype2 will not render fonts in the same manner...
If I am not mistaken https://build.opensuse.org/package/view_file/KDE:Qt/libqt4/use-freetype-def ault.diff?expand=1 checks for subpixel availability on runtime.
I don't have the Qt4 sources locally (so can't check when is that invoked), but QFontEngineFT::loadGlyph depends on FT_CONFIG_OPTION_SUBPIXEL_RENDERING during compile time. Maybe it is unused these days...
Cheers, Hrvoje
Regards, ismail
On 17 Nov 13:04, šumski wrote:
I don't have the Qt4 sources locally (so can't check when is that invoked), but QFontEngineFT::loadGlyph depends on FT_CONFIG_OPTION_SUBPIXEL_RENDERING during compile time. Maybe it is unused these days...
My limited testing with konsole showed no adverse effects but I'll keep an eye on it.
Thanks!
On Monday 17 November 2014 13:04:01 šumski wrote:
I don't have the Qt4 sources locally (so can't check when is that invoked), but QFontEngineFT::loadGlyph depends on FT_CONFIG_OPTION_SUBPIXEL_RENDERING during compile time. Maybe it is unused these days...
Hm, that's very interesting point. You are right, in Qt sources it looks like this:
#if defined(FT_LCD_FILTER_H) && defined(FT_CONFIG_OPTION_SUBPIXEL_RENDERING) #define QT_USE_FREETYPE_LCDFILTER #endif
which is used later in loadGlyph to switch between freetype and some other crazy method of rendering.
Surprisingly, looks like that other crazy method is quite good, I was not able to notice the difference between custom-built freetype version and original source.
There is another interesting patch in libqt4 packages: https://build.opensuse.org/package/view_file/openSUSE:13.2/libqt4/use-freety...
Is it possible to do the same for qfontengine_ft.cpp to switch between those code blocks in runtime instead of compile-time?
PS: Hrvoje, thanx for backporting QTBUG41590.patch to libqt5-qtbase, that one was extremely annoying.
On Monday 17 November 2014 13:04:01 šumski wrote:
I don't have the Qt4 sources locally (so can't check when is that invoked), but QFontEngineFT::loadGlyph depends on FT_CONFIG_OPTION_SUBPIXEL_RENDERING during compile time. Maybe it is unused these days...
So, I made this patch, almost complete copy of another patch but applied for different source file:
https://drive.google.com/open?id=0B5Kp-cB1sXJrdDRyX2NZMEJzTUU&authuser=0
After some local testing, for me it works with both default freetype and subpixel-enabled freetype. I'd like to ask someone else to test it as well before asking libqt4 package maintainers to incorporate it.
Also, I can port the same change to Qt5 as well if anyone is interested.
On 18 Nov 13:46, Stanislav Baiduzhyi wrote:
On Monday 17 November 2014 13:04:01 šumski wrote:
I don't have the Qt4 sources locally (so can't check when is that invoked), but QFontEngineFT::loadGlyph depends on FT_CONFIG_OPTION_SUBPIXEL_RENDERING during compile time. Maybe it is unused these days...
So, I made this patch, almost complete copy of another patch but applied for different source file:
https://drive.google.com/open?id=0B5Kp-cB1sXJrdDRyX2NZMEJzTUU&authuser=0
After some local testing, for me it works with both default freetype and subpixel-enabled freetype. I'd like to ask someone else to test it as well before asking libqt4 package maintainers to incorporate it.
Patch looks fine, can you branch libqt4 on OBS and apply your patch, so people can easily test the change?
Also, I can port the same change to Qt5 as well if anyone is interested.
That would be nice :-)
Regards, ismail
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Patch looks fine, can you branch libqt4 on OBS and apply your patch, so people can easily test the change?
Sure, I have to run away now but in two or three ours I'll get back to this.
Also, I can port the same change to Qt5 as well if anyone is interested.
That would be nice :-)
Ok, will do the same thing with branching then.
Also, I wanted to ask you... I have some trust issues towards infinality, as the changes were not upstreamed (and I trust Werner Lemberg from freetype.org more on this), and at the moment project looks abandoned. Why do you keep your subpixel repo with infinality instead of clean freetype? That was the main reason why I created another repo, with freetype directly taken from original SRPM.
On 18 Nov 13:57, Stanislav Baiduzhyi wrote:
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Patch looks fine, can you branch libqt4 on OBS and apply your patch, so people can easily test the change?
Sure, I have to run away now but in two or three ours I'll get back to this.
Also, I can port the same change to Qt5 as well if anyone is interested.
That would be nice :-)
Ok, will do the same thing with branching then.
Also, I wanted to ask you... I have some trust issues towards infinality, as the changes were not upstreamed (and I trust Werner Lemberg from freetype.org more on this), and at the moment project looks abandoned. Why do you keep your subpixel repo with infinality instead of clean freetype? That was the main reason why I created another repo, with freetype directly taken from original SRPM.
Werner Lemberg and Erik (the Infinality guy) works together on this. Werner accepted parts of his patches upstream. But getting the whole stuff in will take more time, see https://lists.gnu.org/archive/html/freetype-devel/2014-11/msg00003.html
You are of course entitled to your opinion but I trust Erik.
Regards, ismail
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Build for libqt4 finished: http://download.opensuse.org/repositories/home:/TheIndifferent:/branches:/op...
URL looks a bit strange with 3 repos inside, for 13.2, factory and tumbleweed underneath, but either OBS does not allow to rename the project on branching, or I haven't found how to do that.
Please everyone who can do it - try those packages and report back with both success or failure.
Also, I'm having some problems with Qt5 packages. What is the correct way to handle patch conflicts? I think I could just reapply them manually and then take diff again, but I would guess there is a way to do it properly.
On 18 Nov 17:08, Stanislav Baiduzhyi wrote:
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Build for libqt4 finished: http://download.opensuse.org/repositories/home:/TheIndifferent:/branches:/op...
URL looks a bit strange with 3 repos inside, for 13.2, factory and tumbleweed underneath, but either OBS does not allow to rename the project on branching, or I haven't found how to do that.
Please everyone who can do it - try those packages and report back with both success or failure.
Tested on Factory and looks fine here. Thanks!
Also, I'm having some problems with Qt5 packages. What is the correct way to handle patch conflicts? I think I could just reapply them manually and then take diff again, but I would guess there is a way to do it properly.
I apply them using quilt and refresh accordingly.
Regards, ismail
On Wednesday 19 November 2014 11:27:54 İsmail Dönmez wrote:
Also, I'm having some problems with Qt5 packages. What is the correct way to handle patch conflicts? I think I could just reapply them manually and then take diff again, but I would guess there is a way to do it properly.
I apply them using quilt and refresh accordingly.
Finally got Qt5 to build, had to do some tricks like applying patch with fuzz=3 and then exporting it back, because OSB applies them with fuzz=0.
http://download.opensuse.org/repositories/home:/TheIndifferent:/branches:/KD...
Following changes were made to the original package: * patch 2 replaced with [1]; * patch 2011 replaced with [2];
[1]: https://drive.google.com/open?id=0B5Kp-cB1sXJrQlFBUnlaZDlkbGs&authuser=0 [2]: https://drive.google.com/open?id=0B5Kp-cB1sXJrTV84cVNSRTZ5RU0&authuser=0
With KMag it is obvious that both grayscale and subpixel antialiasing works fine. On debug it really entered or skipped the code block depending on runtime detection. So I would not expect to see any issues with those packages, but the more testing they'll get - the better.
Op dinsdag 18 november 2014 17:08:56 schreef Stanislav Baiduzhyi:
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Build for libqt4 finished: http://download.opensuse.org/repositories/home:/TheIndifferent:/branches:/op enSUSE:/13.2/
URL looks a bit strange with 3 repos inside, for 13.2, factory and tumbleweed underneath, but either OBS does not allow to rename the project on branching, or I haven't found how to do that.
Please everyone who can do it - try those packages and report back with both success or failure.
Tried on openSUSE 13.2, no adverse effects.
Also, I'm having some problems with Qt5 packages. What is the correct way to handle patch conflicts? I think I could just reapply them manually and then take diff again, but I would guess there is a way to do it properly.
On Tuesday 18 of November 2014 17:08:56 Stanislav Baiduzhyi wrote:
On Tuesday 18 November 2014 14:50:00 İsmail Dönmez wrote:
Build for libqt4 finished: http://download.opensuse.org/repositories/home:/TheIndifferent:/branches:/o penSUSE:/13.2/
URL looks a bit strange with 3 repos inside, for 13.2, factory and tumbleweed underneath, but either OBS does not allow to rename the project on branching, or I haven't found how to do that.
Please everyone who can do it - try those packages and report back with both success or failure.
Also, I'm having some problems with Qt5 packages. What is the correct way to handle patch conflicts? I think I could just reapply them manually and then take diff again, but I would guess there is a way to do it properly.
I've tried the to forward port the patch to Qt5, but there it doesn't really work good. I.e. no text on hovering, the text thumbnail paints no text, etc.
Furthermore, i think the patch is incorrect, or at least an overkill. Original Qt code already checks error codes from freetype (qfontengine_ft.cpp L960-965), and if subpixel is not available it fallbacks to internal implementation (IOW, with that patch, the check will be done twice).
So, IMO wanted effect is best achieved with the current method of removing the FT_CONFIG_SUBPIXEL condition (or just passing the QT_USE_FREETYPE_LCDFILTER define). The former could be even integrated into Qt i think, as there is nothing different how the code would be compiled w/ and w/o the freetype define considering there is already runtime check implemented..
Cheers, Hrvoje
On Wednesday 19 November 2014 16:17:52 šumski wrote:
I've tried the to forward port the patch to Qt5, but there it doesn't really work good. I.e. no text on hovering, the text thumbnail paints no text, etc.
Furthermore, i think the patch is incorrect, or at least an overkill. Original Qt code already checks error codes from freetype (qfontengine_ft.cpp L960-965), and if subpixel is not available it fallbacks to internal implementation (IOW, with that patch, the check will be done twice).
So, IMO wanted effect is best achieved with the current method of removing the FT_CONFIG_SUBPIXEL condition (or just passing the QT_USE_FREETYPE_LCDFILTER define). The former could be even integrated into Qt i think, as there is nothing different how the code would be compiled w/ and w/o the freetype define considering there is already runtime check implemented..
Yes, you're right. I've just debugged the packages, they really behave like that.
Which leads me to another question: maybe it will make sense to do the same change for libqt4 instead of the patch I suggested earlier?
On Wednesday 19 of November 2014 17:46:13 Stanislav Baiduzhyi wrote:
On Wednesday 19 November 2014 16:17:52 šumski wrote:
I've tried the to forward port the patch to Qt5, but there it doesn't really work good. I.e. no text on hovering, the text thumbnail paints no text, etc.
Furthermore, i think the patch is incorrect, or at least an overkill. Original Qt code already checks error codes from freetype (qfontengine_ft.cpp L960-965), and if subpixel is not available it fallbacks to internal implementation (IOW, with that patch, the check will be done twice).
So, IMO wanted effect is best achieved with the current method of removing the FT_CONFIG_SUBPIXEL condition (or just passing the QT_USE_FREETYPE_LCDFILTER define). The former could be even integrated into Qt i think, as there is nothing different how the code would be compiled w/ and w/o the freetype define considering there is already runtime check implemented..
Yes, you're right. I've just debugged the packages, they really behave like that.
Which leads me to another question: maybe it will make sense to do the same change for libqt4 instead of the patch I suggested earlier?
Yes, i would think that also makes sense. Not even instead of suggested patch, but instead of the current Qt4 use-freetype-default.patch. (afaik anti- aliasing is available w/o FT_CONFIG_OPTION_SUBPIXEL_RENDERING)
Cheers, Hrvoje
On Wednesday 19 November 2014 17:58:07 šumski wrote:
Which leads me to another question: maybe it will make sense to do the same change for libqt4 instead of the patch I suggested earlier?
Yes, i would think that also makes sense. Not even instead of suggested patch, but instead of the current Qt4 use-freetype-default.patch. (afaik anti- aliasing is available w/o FT_CONFIG_OPTION_SUBPIXEL_RENDERING)
Will you do that for 13.2? :) If yes - should we expect the 13.2 to be added to KDE:Qt or it will go to official update?
On Thursday 20 of November 2014 10:11:20 Stanislav Baiduzhyi wrote:
On Wednesday 19 November 2014 17:58:07 šumski wrote:
Which leads me to another question: maybe it will make sense to do the same change for libqt4 instead of the patch I suggested earlier?
Yes, i would think that also makes sense. Not even instead of suggested patch, but instead of the current Qt4 use-freetype-default.patch. (afaik anti- aliasing is available w/o FT_CONFIG_OPTION_SUBPIXEL_RENDERING)
Will you do that for 13.2? :) If yes - should we expect the 13.2 to be added to KDE:Qt or it will go to official update?
Well, first step is to get it accepted in the devel project =) Regarding 13.2, i am not sure this is something maintenance would accept? After all, it affects only users of 3rd party-built freetype2...
And wrt. KDE:Qt, i do not know, i'm not a maintainer there =)
Cheers, Hrvoje
On Thursday 20 November 2014 22:18:24 šumski wrote:
And wrt. KDE:Qt, i do not know, i'm not a maintainer there =)
İsmail, I see your name there :) what do you think about it? Would you like me to test this approach in branch first?
On 20 Nov 22:29, Stanislav Baiduzhyi wrote:
On Thursday 20 November 2014 22:18:24 šumski wrote:
And wrt. KDE:Qt, i do not know, i'm not a maintainer there =)
İsmail, I see your name there :) what do you think about it? Would you like me to test this approach in branch first?
Patch looks fine. Just SR with a explaining changes entry.
Thanks!
On Friday 21 November 2014 10:42:25 İsmail Dönmez wrote:
On 20 Nov 22:29, Stanislav Baiduzhyi wrote:
On Thursday 20 November 2014 22:18:24 šumski wrote:
And wrt. KDE:Qt, i do not know, i'm not a maintainer there =)
İsmail, I see your name there :) what do you think about it? Would you like me to test this approach in branch first?
Patch looks fine. Just SR with a explaining changes entry.
Ah, Hrvoje beat me to that, as always.
Please also add 13.2 to the repositories.
On 21 Nov 14:38, Stanislav Baiduzhyi wrote:
On Friday 21 November 2014 10:42:25 İsmail Dönmez wrote:
On 20 Nov 22:29, Stanislav Baiduzhyi wrote:
On Thursday 20 November 2014 22:18:24 šumski wrote:
And wrt. KDE:Qt, i do not know, i'm not a maintainer there =)
İsmail, I see your name there :) what do you think about it? Would you like me to test this approach in branch first?
Patch looks fine. Just SR with a explaining changes entry.
Ah, Hrvoje beat me to that, as always.
Accepted.
Please also add 13.2 to the repositories.
Done. Thank you both!
On Tuesday 02 September 2014 20:13:41 Achim Gratz wrote:
With the update to freetype 2.5 the Infinality patches from namtrac:subpixel can no longer be installed. My understanding was that some functionality of the patches had been upstreamed into freetype 2.5, but at least out-of-the box the font rendering is really ugly. So is there any information on how to get a more usable (or preferrably) identical font rendering with the new library? I really don't want to go back to bitmapped fonts, especially as the ones I liked all have poor UTF-8 support.
openSUSE ships with subpixel rendering disabled, because that's patented technology. So to achieve the same result you just have to rebuild the freetype with subpixel enabled (it is a define in one of the headers and official RPM has proper patch, but not applied during the build).
... or if you're too lazy to build it yourself - you can grab my packages :) https://drive.google.com/folderview?id=0B7j7XkcAA4-MU21tR2cwS1FPT3c&usp=...
And while you're at it - you can try my fontconfig config files, just put them to /etc/fonts/conf.d, but with 2 modifications: 1. edit 00-*.conf just moving some lines up and down according to what fonts you like most. 2. change DPI to your native in 99-*.conf and play with hintstyle according to your preferences, slight works best for me but medium is required for some fonts.
Regards, Achim.
Stanislav Baiduzhyi writes:
openSUSE ships with subpixel rendering disabled, because that's patented technology.
The Freetype folks themselves think that only the color filter is encumbered by the ClearType patents. So it strikes me as odd to disable the subpixel rendering altogether instead of just that particular filter, but what do I know.
So to achieve the same result you just have to rebuild the freetype with subpixel enabled (it is a define in one of the headers and official RPM has proper patch, but not applied during the build).
... or if you're too lazy to build it yourself - you can grab my packages :) https://drive.google.com/folderview?id=0B7j7XkcAA4-MU21tR2cwS1FPT3c&usp=...
[…]
Thanks, I'll have a look. THe subpixel repo had more libraries in, has this become unneccesay with the 2.5 version?
Regards, Achim.
On Wednesday 03 September 2014 20:26:59 Achim Gratz wrote:
Stanislav Baiduzhyi writes:
openSUSE ships with subpixel rendering disabled, because that's patented technology.
The Freetype folks themselves think that only the color filter is encumbered by the ClearType patents. So it strikes me as odd to disable the subpixel rendering altogether instead of just that particular filter, but what do I know.
Well, that's not a question for me, I'm only the end-user with a tick for good-looking fonts. But what I do know is this:
https://build.opensuse.org/package/view_file/M17N/freetype2/freetype2-subpix...
And this, line 88 to 90:
https://build.opensuse.org/package/view_file/M17N/freetype2/freetype2.spec?e...
So to achieve the same result you just have to rebuild the freetype with subpixel enabled (it is a define in one of the headers and official RPM has proper patch, but not applied during the build).
... or if you're too lazy to build it yourself - you can grab my packages :) https://drive.google.com/folderview?id=0B7j7XkcAA4-MU21tR2cwS1FPT3c&usp=... haring
[…]
Thanks, I'll have a look. THe subpixel repo had more libraries in, has this become unneccesay with the 2.5 version?
Yea, there was some patched version of Pango too (I do not use anything GTK- based so will not bother rebuilding this one), plus one dependency-only or something like that rpm that disabled the yast to reinstall freetype from updates repository, which I do not care too much either.
But if you're using NetBeans or any other Java Swing based app - I can share a patched build of openJDK with better fontconfig and dpi support.
Regards, Achim.
On 04 Sep 09:51, Stanislav Baiduzhyi wrote:
But if you're using NetBeans or any other Java Swing based app - I can share a patched build of openJDK with better fontconfig and dpi support.
Better yet put the patches somewhere? :)
Thanks, İsmail
On Thursday 04 September 2014 11:09:50 İsmail Dönmez wrote:
On 04 Sep 09:51, Stanislav Baiduzhyi wrote:
But if you're using NetBeans or any other Java Swing based app - I can share a patched build of openJDK with better fontconfig and dpi support.
Better yet put the patches somewhere? :)
You mean something like this? https://code.google.com/p/tuxjdk/
Thanks, İsmail
On 04 Sep 10:17, Stanislav Baiduzhyi wrote:
On Thursday 04 September 2014 11:09:50 İsmail Dönmez wrote:
On 04 Sep 09:51, Stanislav Baiduzhyi wrote:
But if you're using NetBeans or any other Java Swing based app - I can share a patched build of openJDK with better fontconfig and dpi support.
Better yet put the patches somewhere? :)
You mean something like this? https://code.google.com/p/tuxjdk/
Yes, looks nice indeed!
On Thursday 04 September 2014 11:19:28 İsmail Dönmez wrote:
On 04 Sep 10:17, Stanislav Baiduzhyi wrote:
On Thursday 04 September 2014 11:09:50 İsmail Dönmez wrote:
On 04 Sep 09:51, Stanislav Baiduzhyi wrote:
But if you're using NetBeans or any other Java Swing based app - I can share a patched build of openJDK with better fontconfig and dpi support.
Better yet put the patches somewhere? :)
You mean something like this? https://code.google.com/p/tuxjdk/
Yes, looks nice indeed!
One warning though: use it for your own risk, and it is probably not stable enough to be packages in distribution. Testing group AND target audience at the moment consists of me, myself, and maybe one other guy but I'm not sure.
-
Achim Gratz -
Freek de Kruijf -
İsmail Dönmez -
Mathias Homann -
Petr Gajdos -
Sean -
Stanislav Baiduzhyi -
šumski