<---- template headericclude ----->
Ubuntu Hardy's LCD sub-pixel font rendering in Fedora 9 - Page 4
FedoraForum.org - Fedora Support Forums and Community
Page 4 of 11 FirstFirst ... 23456 ... LastLast
Results 46 to 60 of 161
  1. #46
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Details? What specifically? There's already quite a few useful comments in the .src.rpms - look at them using e.g. file-roller. They contain the .spec file and all patches & sourcecode.

    To extract Ubuntu's patches from Ubuntu's own package (e.g. cairo, grab their .orig and .diff files, untar them, apply the .diff, and then look in the debian/patches dir that gets created by applying the .diff.

  2. #47
    fubz Guest
    Right - thanks for the details.

  3. #48
    Join Date
    Jul 2008
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question freetype-freeworld

    Hello brebs,

    one more question.

    I am using your packages together with livna freetype-freeworld.
    It seems, that fonts are even nicer then (for me).
    My question is , is aliasing from livna freetype-freeworld allready implemented in your packages , or not? So using with freetype-freeworld is meaningfull.

    Thanks
    btw. i told it allready, but i love what you done for Fedora 9 (fonts are beautiful)

  4. #49
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dhlacik
    is aliasing from livna freetype-freeworld allready implemented in your packages
    No. But it's very similar to lcdlight and/or lcdlegacy, IIRC. Have you compared with them?

    Looking at the freetype-freeworld SRPM, it doesn't add a font-rendering algorithm.

    It's Ubuntu's "lcddefault" which I prefer.

    Edit: It's libXft that has the big rendering patches - see libXft-2.1.10-lcd-filter-3.patch in my libXft SRPM.
    Last edited by brebs; 4th October 2008 at 02:32 PM.

  5. #50
    Join Date
    Jul 2008
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question

    Brebs, and which hinting are you using : Full , Medium, or Slight?

    Me personally prefer Slight, but unfortunately bold fonts are too bold.

    When using Full , fonts are too thin , some even are not displaying correctly.

    Thanks in advance!

  6. #51
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I prefer hintmedium, although my ruleset varies the hinting.

    For info on how to customize your fonts a thousand different ways, see the link in my first post in this thread. That way, I don't have to repeat myself. And yes, my ruleset is posted in the Gentoo thread - but you're gonna have to put in some effort to find it. That way, you see all the tips, and I don't have to repeat myself. I must have answered the "bold is too bold" question a hundred times on various forums. It gets tedious. So do me a favour and read the Gentoo thread. Then, ask questions which *aren't* already answered.

  7. #52
    Join Date
    Apr 2008
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice to see that you caught that Qt4 subpixel-hintfull-or-none-only issue.

    In the meantime I was setting special conditional lines in my .fonts.conf to turn off Subpixel in Qt4 apps (when rendered in Greyscale it allows slight and full hinting -- only with Subpixel does Qt4 force full or no hinting). Thanks! And it looks like this is natively fixed in the upcoming Qt4.5, so hopefully this is the last of that issue.

  8. #53
    Join Date
    Apr 2008
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But unfortunately, your patch doesn't fix the issue. Qt4 still only allows (when subpixel/rgb rendering is on) either None or Full hinting; it still can't choose slight or medium (unless in greyscale).


    As an aside, Qt4 only seems to read settings from the .fonts.conf file. (Except for DPI, which it will pick up from the X resource database). It ignores all Xft settings for RGB, antialiasing, and hintstyle. Set whatever you want in a .Xresources file; .fonts.conf will always override it in Qt4 apps.

    This behavior is particularly annoying since GNOME relies on the xrdb to dynamically change font settings on the fly; Qt4 will never pick up on them, and the only way to alter Qt4 rendering is to manually specify options with .fonts.conf, which then limits your flexibility with GNOME's font dialog (since, in your latest patches anyway, it cannot override .fonts.conf.) Example. If .fonts.conf hinting is set to HintSlight, then no change in the GNOME font dialog will alter that -- you cannot change the hintstyle no matter what (unless you disable anti-aliasing altogether -- _that_ does work, but hintstyle cannot be overridden).

    I think this is a regression in your new patches and packages; in previous releases from September on, GNOME would read from .fonts.conf at startup, but any changes made in the Font Dialog to hintstyle afterwards could override it. I just updated with every package you've uploaded, and now GNOME obeys .fonts.conf hintstyle unflexibly.

  9. #54
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by twilightomni
    I think this is a regression
    Caused by the same cairo-respect-fontconfig.patch which wasn't fixing qt4 anyway. So the patch is now history - upgrade to my cairo-1.7.6.20081010-1

  10. #55
    Join Date
    Apr 2008
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks! Works just fine again.

  11. #56
    Join Date
    Apr 2008
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, check this, you've got mutually exclusive regressions going on.

    Your cairo-obey-fontconfig patch fixes stuff AND breaks stuff.

    Exhibit A:
    Code:
    <!-- When a font gets 10-size or up, use weaker hinting. -->
     <match target="font" >
      <test qual="all" name="size" compare="more_eq" ><double>9.5</double></test>
      <edit name="hintstyle" mode="assign" ><const>hintslight</const></edit>
     </match>
    This particular sequence _never_ worked before -- something about GTK programs ignores any Hintstyle statement that overrides from within a conditional.

    With your cairo-fontconfig patch, it is true that GNOME decided to obey .fonts.conf instead of its own Xft and xrdb settings. But this is what makes rules like this possible. So with your cairo-fontconfig patch, GNOME can no longer override fonts.conf hintstyle settings. But in exchange...GNOME will now obey specific hintstyle settings.

    You know what? I actually think I kinda like your patch. (It does reduce GNOME's flexibility, but only if you're using .fonts.conf specific settings in the first place -- something only an expert would do anyway -- and it's not like Qt4 is getting any _worse_, it still does whatever the heck it wants).

    When I turned on my PC today and I noticed that I no longer had custom size-based hinting, I thought "the patch! that was it! he took that out! darn!"

    Do you think the patch might be worth keeping? It implements what I think is very useful behavior.

  12. #57
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Haha. OK, cairo-1.7.6.20081010-2 includes cairo-respect-fontconfig.patch again

    Having flexibility in ~/.fonts.conf is important, until cairo is fixed properly.

  13. #58
    Join Date
    Apr 2008
    Posts
    70
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In truth, my initial complaint with the patch wasn't a bug; it was more of me disagreeing with the design.

    The truth is, if you want to be able to dynamically configure your font settings in GNOME, you shouldn't enumerate everything in .fonts.conf. It takes away too much flexibility. What you _should_ do, is enumerate only specific settings that can't be set elsewhere (ex, use the autohinter or the BCI), the font-substitution settings, and <test> clauses (only set feature X if condition Y is present).

    The minute you set a broad option in .fonts.conf (use Slight hinting on all fonts), you have a problem. Should GNOME override it if the user wants something different, or not? I happen to think GNOME should override all broad options in .fonts.conf, but it should never override specific <test> branch options.

    It would be a perfect world if GNOME's settings in Xft/xrdb were obeyed UNLESS there was a branch in .fonts.conf prefixed with a <test> clause. This would clue the font renderer in that this is a very specific exception to the "let GNOME have it's way" rule.



    But there's another flipside. Qt4 by default doesn't pay attention to Xft or Xrdb, it only gets font hinting style from .fonts.conf. So if you _don't_ specify a broad option in .fonts.conf, Qt4 defaults to Full hinting. But if you _do_ specify, then GNOME can't flexibly adjust hinting (with your patch -- but we've agreed that your patch fixes enough behaviors to be worth it).

    My current setup has GNOME using full hinting, and no broad hintstyle set in .fonts.conf. That means Qt4 defaults to Full hinting (so they match), and thanks to your patch, I can now use cool <test> branches to change the hintstyle in Gtk apps.

    If I wanted anything else (Qt4 to use medium style, or slight style) I'd be in trouble.

    Qt4 is actually abysmally bad at following local font settings. It messes up a lot of .fonts.conf <test> clauses and it doesn't obey any other repository of font settings (xrdb/xft, except for DPI). Qt3 behaves quite well, which is a shame. A double shame, since Qt4 actually has _better_ subpixel rendering than Qt3 -- if it would only obey your settings right.



    So your patch is actually good, but it reveals some ugly things: GNOME will follow .fonts.conf perfectly now, but _perfectly_ -- no wiggle room for a broad Hintstyle option. Qt4 won't follow anything BUT .fonts.conf, and it follows .fonts.conf _poorly!_ Qt3 does good at following whatever GNOME does; in fact, I think it has equivalent fontconfig functionality to GTK.

    C'est la vie. I'll deal with it.

  14. #59
    Join Date
    Jul 2008
    Posts
    36
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Brebs,

    please, do you still have packages patched from original ubuntu hardy's subpixel rendering? You used to have them in /old directory, but they are gone now. I believe it was from july 2008. As far i know those newer are patched from interpid.

    Thanks!

  15. #60
    Join Date
    Apr 2008
    Posts
    558
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have the old versions. What do you want them for?

    The current versions fix *loads* of bugs. The gitwebs for e.g. pixman and cairo have shown lots of "This fixes bug #blah" entries.

Page 4 of 11 FirstFirst ... 23456 ... LastLast

Similar Threads

  1. Replies: 48
    Last Post: 2nd September 2008, 07:02 PM
  2. weird font rendering in Fedora 7
    By oayfer in forum Using Fedora
    Replies: 9
    Last Post: 23rd October 2007, 10:50 PM
  3. Font Rendering - Fedora 7
    By euler2 in forum Using Fedora
    Replies: 2
    Last Post: 20th June 2007, 01:54 PM
  4. Font rendering is so bad in Fedora 7 on my LCD
    By cr4ck3r in forum Using Fedora
    Replies: 15
    Last Post: 10th June 2007, 04:19 AM
  5. Font rendering in Fedora
    By mario.lopes in forum Using Fedora
    Replies: 0
    Last Post: 17th February 2005, 12:35 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
[[template footer(Guest)]]