http://bugzilla.rpmfusion.org/show_bug.cgi?id=547
--- Comment #8 from Kevin Kofler <[email protected]> 2009-04-15 10:48:47 --- > My idea was to have completely same experience as on Ubuntu Jaunty. > Because of that, i have dropped all the Fedora/Upstream patches and added > those > from Ubuntu. IMHO this is not acceptable. Fedora is not Ubuntu. Fedora's patches fix actual bugs (e.g. the memcpy patch you dropped from freetype definitely fixes a serious bug). Please readd the Fedora patches. Adding Ubuntu's subpixel rendering patches makes sense, removing the Fedora patches doesn't, and whether adding patches other than subpixel rendering from Ubuntu makes sense or not has to be decides on a case by case basis (but in most cases the patches should go into the Fedora package and/or upstream, not be specific to the RPM Fusion package! E.g. I don't see what sense it makes to carry an armel fix in freetype-lcd/freeworld, we don't even support that architecture in RPM Fusion. If anybody cares, it would be the Fedora ARM team, and they'd want it in the Fedora freetype first of all. And that's just one of the patches you added, similar arguments may apply to others). > I have used same sources of freetype/cairo/libXft as in Ubuntu Jaunty as well. You most likely have to use the same version used in the Fedora release you're targeting to guarantee 100% binary compatibility (which is necessary because we're not going to rebuild all of Fedora against your patched packages). You may get away with a newer one (though I wouldn't recommend it - try to find a package with a matching version in Ubuntu and apply the patches from there instead), but not an older one. You'll also have to check any patches you apply for binary compatibility issues. (Note that the freetype version already matches Rawhide, but I haven't checked the other libs.) > mainly visible when M$ fonts are used - fonts are missing some glymphs. Which patch is fixing that? The enable-full-bytecode-interpreter patch? According to the comment in the header file it patches, it should have no effect at all (when the bytecode interpreter is already enabled): it turns off TT_CONFIG_OPTION_UNPATENTED_HINTING, for which the header file says: > Note that the TT_CONFIG_OPTION_UNPATENTED_HINTING macro is *ignored* if you > define TT_CONFIG_OPTION_BYTECODE_INTERPRETER The other patch (freetype-2.1.10-enable-ft2-bci.patch in freetype-freeworld, freetype-bytecode-interpreter.patch in your SRPM) enables TT_CONFIG_OPTION_BYTECODE_INTERPRETER, so disabling TT_CONFIG_OPTION_UNPATENTED_HINTING is useless, it already happens automatically. So I don't see how that patch would make any difference. I don't see anything in your freetype-lcd.spec which is 1. related to subpixel rendering in any way and 2. not already in freetype-freeworld. So I think freetype-freeworld should stay as it is (possibly modulo the 99-DejaVu-autohinter-only.conf file for which I still don't know what to do with it, whether we use that or not, we'll always make somebody unhappy). -- Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You are the assignee for the bug.
