You are not logged in.
I like the xeffects better
Where's cairo-ubuntu gone from AUR? Last I saw, "Demind" was the "maintainer", after I orphaned it.
It would be nice to actually get some feedback from trying lcdfilterlegacy - here's the Arch thread.
Edit: Here's my copy of cairo-ubuntu, until the AUR weirdness/sabotage is resolved.
Last edited by brebs (2008-04-21 17:42:56)
Offline
bangkok_manouel wrote:I like the xeffects better
It would be nice to actually get some feedback from the...
Er, where's the "MAC OS fonts" thread gone, and where's cairo-ubuntu gone from AUR? Last I saw, "Demind" was the "maintainer", after I orphaned it.
Yes you're right,but unfortunately i have thought to orphan the package too in a second time dued to lack of time sorry for that.
[ot]
In my opinion you shouldn't change distro, or better you shouldn't leave Arch for Fedora..Fedora!!
I'm joking ...maybe...
[/ot]
Offline
Someone (not me for a change) should reinstate cairo-ubuntu on AUR, and adopt the other -cairo packages it needs. It makes sense for there to be one owner, since all 4 packages need to work together.
Here's backups of my -ubuntu packages.
In other news, Fedora 9 now has its own cairo-ubuntu
Offline
IMPORTANT (-lcd packages)
Last lcd-filtering patches for "cairo" and "fontconfig" changed the filters name (from lcdfilter* to lcd*) [@brebs here you can see -ubuntu doesn't use the last patches because it has the old names]. Waiting for an updated libxft-lcd package (I'm not the maintainer of that package), take a look at this: http://wiki.archlinux.org/index.php/Fon … -lcd_issue
Last edited by ekerazha (2008-04-23 17:51:58)
Offline
Oh great, more confusion for users
My 4 -ubuntu packages are fine, because they all synchronize on e.g. lcdfilterdefault. We'll see if/when Ubuntu change, in Hardy.
Offline
I've sent an e-mail to the libxft-lcd maintainer.
Offline
did anybody try cairo-newspr + libxft-newspr ... ?
Offline
did anybody try cairo-newspr + libxft-newspr ... ?
Yes but I can't see any difference with cairo-ubuntu here. The only reason I have to keep it is the hope about newspr will be updated in a regular basis.
Scientia et sapientia patrimonium humanitatis sunt.
Offline
did anybody try cairo-newspr + libxft-newspr ... ?
I tried them and I recommend them... They look just like the -lcd ones before they got deleted.
I'm pretty satisfied with these, now
Offline
I've made a deeper check and the patch used by the libxft-lcd package seems fine. I've to understand why with the new cairo version/patch, you have to explicitly set the Xft lcdfilter and it doesn't default to the default filter if nothing is setted.
Offline
From what I've understood, the cairo patch defaults to a legacy filter.
So... as suggested on the freedesktop.org ticket, I've added a fonts config file (which enable the "lcddefault" filter). So the new fontconfig-lcd package (release -3) now installs a new config file named 10-lcdfilter.conf and enables it by default.
You don't need the "Xft" trick anymore.
Short version:
Now, installing "fontconfig-lcd", "cairo-lcd" and "libxft-lcd" everything will work fine by default
Last edited by ekerazha (2008-04-26 13:46:29)
Offline
@brebs
There's a bug inside the libxft patch used by -ubuntu (it's an Ubuntu bug): they use some FC_* constants where they should use FT_* constants (this is one of the reasons why the last patches changed the filters name from LCD_FILTER_* to LCD_*, so there's more than a 2 chars prefix differentiating the constants names used by "fontconfig" with the ones used by "freetype").
Offline
Why so vague? Show a line that's supposedly wrong.
Offline
Why so vague? Show a line that's supposedly wrong.
It wasn't so vague, however if you want the code lines, I've found this:
++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT;
And http://bugs.freedesktop.org/show_bug.cgi?id=10301#c21 says:
Sylvain, your ported patch requires definitions that come from Ubuntu's
supplementary patch to fontconfig. You either need to get that patch into
fontconfig upstream or remove the added options from the cairo patch.As an added note, even after patching fontconfig and building from your patch,
the fontconfig additions don't seem to have any effect. In fact, the original
Ubuntu-modified changeset to Cairo has a significant error where they use
FC_LCD_FILTER_* definitions where they should be using FT_LCD_FILTER_* to pass
to FT_Library_SetLcdFilter. I checked the headers, and the definitions don't
correspond. This leads me to believe that their changes never did what they
were supposed to in the first place.
He talks about "cairo" however I think this issue is common to libxft (look at that line of code).
Last edited by ekerazha (2008-04-26 14:38:11)
Offline
brebs wrote:Why so vague? Show a line that's supposedly wrong.
It wasn't so vague
It was vague indeed
When you suppose there's a bug you have to give detailed description to make your reader understand what you're talking about...it'not like:
"there's a bug in this package"
"really?Where?"
"there"
don't you agree?
, however if you want the code lines:
++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT;
So..let's try to understand this problem...do you agree?
In my opinion more than the line you posted i would focus on this one (line 5041):
++ FT_Library_SetLcdFilter( _XftFTlibrary, FT_LCD_FILTER_NONE );
According to the bug report attached below i believe that this line is correct (talking about libxft-ubuntu)
And http://bugs.freedesktop.org/show_bug.cgi?id=10301#c21 says:
Sylvain, your ported patch requires definitions that come from Ubuntu's
supplementary patch to fontconfig. You either need to get that patch into
fontconfig upstream or remove the added options from the cairo patch.As an added note, even after patching fontconfig and building from your patch,
the fontconfig additions don't seem to have any effect. In fact, the original
Ubuntu-modified changeset to Cairo has a significant error where they use
FC_LCD_FILTER_* definitions where they should be using FT_LCD_FILTER_* to pass
to FT_Library_SetLcdFilter. I checked the headers, and the definitions don't
correspond. This leads me to believe that their changes never did what they
were supposed to in the first place.
Thsi one is related to cairo-ubuntu as you said:
He talks about "cairo" however I think this issue is common to libxft (look at that line of code).
So the issue seems not to be common to libxft but maybe i've misunderstood the problem so we can talk about it if you like. To be sure i've checked also the cairo-ubuntu patch and i've found at line 750:
+ FT_Library_SetLcdFilter( library, FT_LCD_FILTER_NONE );
So it seems ok, always according to the bug report and the proposed solution.
Offline
So the issue seems not to be common to libxft but maybe i've misunderstood the problem so we can talk about it if you like. To be sure i've checked also the cairo-ubuntu patch and i've found at line 750:
+ FT_Library_SetLcdFilter( library, FT_LCD_FILTER_NONE );
So it seems ok, always according to the bug report and the proposed solution.
That line is correct.
I'm talking about this line:
++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT;
Then there's:
++ FT_Library_SetLcdFilter( _XftFTlibrary, font->info.lcd_filter);
FT_Library_SetLcdFilter() needs a FT_* (FreeType) constant, not a FC_* one.
NOTE:
font->info = *fi;
Last edited by ekerazha (2008-04-26 16:01:19)
Offline
Demind wrote:So the issue seems not to be common to libxft but maybe i've misunderstood the problem so we can talk about it if you like. To be sure i've checked also the cairo-ubuntu patch and i've found at line 750:
+ FT_Library_SetLcdFilter( library, FT_LCD_FILTER_NONE );
So it seems ok, always according to the bug report and the proposed solution.
That line is correct.
I'm talking about this line:
++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT;
Then there's:
++ FT_Library_SetLcdFilter( _XftFTlibrary, font->info.lcd_filter);
FT_Library_SetLcdFilter() needs a FT_* (FreeType) constant, not a FC_* one.
NOTE:
font->info = *fi;
Ok, i've tried googleing a bit but couldn't find any issue...how can we test if your idea is correct?
Your doubt is not silly and it seems logical but how can we find if this can cause problems in fonts rendering?
Obviously we can fix it very quickly if it's worth it.
My doubt is that if this could cause problems many users would have complained here too.
i'm quite puzzled, what do you think?
Offline
Ok, i've tried googleing a bit but couldn't find any issue...how can we test if your idea is correct?
Your doubt is not silly and it seems logical but how can we find if this can cause problems in fonts rendering?
Obviously we can fix it very quickly if it's worth it.
My doubt is that if this could cause problems many users would have complained here too.
i'm quite puzzled, what do you think?
FreeType docs clearly say it is a FT_* like constant: http://www.freetype.org/freetype2/docs/ … ering.html
By chance, actually
FT_LCD_FILTER_DEFAULT
and
FC_LCD_FILTER_DEFAULT (FC_LCD_DEFAULT inside newer patches)
are both equal to 1, however this seems a bug and it should be fixed.
This code
++ /*
++ * Get lcd_filter value
++ */
++ switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) {
++ case FcResultNoMatch:
++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT;
++ break;
++ case FcResultMatch:
++ break;
++ default:
++ goto bail1;
++ }
could also cause issues trying to change filter setting. I say "could" because I'd have to do a deeper check into the code and some tests, but I'm going to study now, because I have some exams at university on next weeks (well... and I don't care very much about buggy custom Ubuntu patches). Maybe I can take a deeper look at it when I have some spare time.
Offline
Demind wrote:Ok, i've tried googleing a bit but couldn't find any issue...how can we test if your idea is correct?
Your doubt is not silly and it seems logical but how can we find if this can cause problems in fonts rendering?
Obviously we can fix it very quickly if it's worth it.
My doubt is that if this could cause problems many users would have complained here too.
i'm quite puzzled, what do you think?FreeType docs clearly say it is a FT_* like constant: http://www.freetype.org/freetype2/docs/ … ering.html
By chance, actually
FT_LCD_FILTER_DEFAULT
and
FC_LCD_FILTER_DEFAULT (FC_LCD_DEFAULT inside newer patches)
are both equal to 1, however this seems a bug and it should be fixed.
Ok that document is clear, i'm going to fix this
This code
++ /* ++ * Get lcd_filter value ++ */ ++ switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) { ++ case FcResultNoMatch: ++ fi->lcd_filter = FC_LCD_FILTER_DEFAULT; ++ break; ++ case FcResultMatch: ++ break; ++ default: ++ goto bail1; ++ }
could also cause issues trying to change filter setting. I say "could" because I'd have to do a deeper check into the code and some tests, but I'm going to study now, because I have some exams at university on next weeks (well... and I don't care very much about buggy custom Ubuntu patches). Maybe I can take a deeper look at it when I have some spare time.
You're right, it's a matter of coherence...since this patch is in AUR and can be tested by users i'll modify this part too, it won't be a great problem changing again, and since in my opinion seems logical to change this too i'll do that.
Thanks
Offline
Be careful!
As I've already said I'd have to do a deeper check of the code, but look at this line
switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) {
If you only change the name of that const, I don't think (but I could be wrong) a FT_* like constant (inside &fi->lcd_filter) will match a FC_LCD_FILTER object.
My sensation is that the whole Ubuntu custom patch has been made with the FC_*/FT_* confusion in mind.
Last edited by ekerazha (2008-04-26 17:18:38)
Offline
Be careful!
As I've already said I'd have to do a deeper check of the code, but look at this line
switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) {
If you only change the name of that const, I don't think (but I could be wrong) a FT_* like constant (inside &fi->lcd_filter) will match a FC_LCD_FILTER object.
My sensation is that the whole Ubuntu custom patch has been made with the FC_*/FT_* confusion in mind.
This should be investigated, i was just saying that changing a line and not changing the whole thing is not coherent and maybe it could make things "worse".
However put like that we can't know if there's a sort of FC_*/FT_* confusion, or if it's only a mistake and further investigations could take very long...it's weird that Ubuntu developers didn't notice this too...:/
Offline
AFAICT, the only thing wrong is "fi->lcd_filter = FC_LCD_FILTER_DEFAULT;", which will still get assigned 1 anyway, so there is no user-noticeable difference.
Setting e.g. "Xft.lcdfilter: lcdfilterlegacy" in ~/.Xresources works, with the -ubuntu packages - the rendering is clearly different.
Offline
mauud777 wrote:did anybody try cairo-newspr + libxft-newspr ... ?
I tried them and I recommend them... They look just like the -lcd ones before they got deleted.
I'm pretty satisfied with these, now
I installed them yesterday after reading this thread. I don't see any difference from the *-lcd patches... which is exactly what I wanted. Very nice. Let's hope these ones stay updated...
0 Ok, 0:1
Offline
which will still get assigned 1 anyway, so there is no user-noticeable difference.
This is already been said.
Setting e.g. "Xft.lcdfilter: lcdfilterlegacy" in ~/.Xresources works, with the -ubuntu packages - the rendering is clearly different.
Instead of the "Xft" way, try the "fonts/conf.d" way. It could work anyway, as I've already said we should try.
Last edited by ekerazha (2008-04-27 12:05:24)
Offline
For the -lcd "less buggy" packages, I've updated the wiki explaining how to change the lcd filter config: http://wiki.archlinux.org/index.php/Fon … figuration
Offline