[Bug 547] review request: LCD patches from Ubuntu finally in Fedora

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=547





--- Comment #8 from Kevin Kofler <kevin.kofler at chello.at>  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.