registry team mailing list archive

[Bug Watch Updater <164640@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 94 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=10301.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-03-15T01:29:19+00:00 Stanislav Brabec wrote:

Here is a patch for LCD filtering from SuSE builds.

The patch is from David Turner, one of the freetype2 upstream
developers.

David Turner says: "...my final understanding is that the MS patents
pretty cover *all* cases of LCD-specific rendering we're interested in
(there are ClearType patents that clearly don't affect us). And by the
way, this includes the original LCD-specific code found in libXft,
Cairo, and probably the XRender implementation of your X11 Server, even
without my FIR-filter patch."

David Turners mails concerning the LCD filtering and the Cairo patch
are all on a public mailing list and they explain the problem
in detail:

http://lists.gnu.org/archive/html/freetype/2006-09/msg00064.html
http://lists.gnu.org/archive/html/freetype/2006-09/msg00069.html
http://lists.gnu.org/archive/html/freetype/2006-09/msg00081.html
http://lists.gnu.org/archive/html/freetype/2006-10/msg00004.html
http://www.mail-archive.com/freetype@xxxxxxxxxx/msg00981.html

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/0

------------------------------------------------------------------------
On 2007-03-15T01:30:08+00:00 Stanislav Brabec wrote:

Created an attachment (id=9148)
cairo-1.2.4-lcd-filter-1.patch

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/1

------------------------------------------------------------------------
On 2007-03-15T01:37:14+00:00 Stanislav Brabec wrote:

It seems, that following URL may contain updated version of attached patch.
http://lists.gnu.org/archive/html/freetype/2006-10/msg00004.html

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/2

------------------------------------------------------------------------
On 2007-03-15T01:45:18+00:00 Stanislav Brabec wrote:

No, checking mail dates, cairo-1.2.4-lcd-filter-1.patch seems to be the
latest I can find: http://www.mail-
archive.com/freetype@xxxxxxxxxx/msg01028.html

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/3

------------------------------------------------------------------------
On 2007-06-29T03:05:34+00:00 Bugzilla-namtrac wrote:

The patch gives impressive results when LCD filtering is enabled in
Freetype, but it won't apply to 1.4.10 cleanly.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/4

------------------------------------------------------------------------
On 2007-07-04T06:23:37+00:00 Stanislav Brabec wrote:

Created an attachment (id=10583)
cairo-1.4.10-lcd-filter-1.patch

My attempt to update patch for cairo 1.4.10.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/5

------------------------------------------------------------------------
On 2007-07-04T06:42:41+00:00 Bugzilla-namtrac wrote:

Removing  _cairo_error (CAIRO_STATUS_NO_MEMORY); from the code doesn't
sound right :-/

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/6

------------------------------------------------------------------------
On 2007-11-28T21:50:05+00:00 Bugzilla-namtrac wrote:

Behdad,

Is there any chance you are gonna apply this patch? This patch improves
rendering a lot but its once again out of sync with cairo 1.5.2.

Please comment.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/8

------------------------------------------------------------------------
On 2007-11-29T18:29:21+00:00 Freedesktop wrote:

Looks good to me generally.  Can go in 1.6 after testing.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/9

------------------------------------------------------------------------
On 2007-11-29T20:13:20+00:00 Bugzilla-namtrac wrote:

Very good news, David Turner will like this news :-)

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/10

------------------------------------------------------------------------
On 2007-11-29T20:38:35+00:00 Freedesktop wrote:

Well, he has a much larger chunk of code rewriting cairo-ft that is
awaiting review...

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/11

------------------------------------------------------------------------
On 2007-11-29T20:40:22+00:00 Bugzilla-namtrac wrote:

(In reply to comment #10)
> Well, he has a much larger chunk of code rewriting cairo-ft that is awaiting
> review...

Must be private as I haven't seen it but his patches are always quality
anyway, maybe its a good time to review it? :)

With this patch GTK+ apps looks really sharp.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/12

------------------------------------------------------------------------
On 2007-11-29T20:54:09+00:00 Freedesktop wrote:

It's been sent to cairo list multiple times (improved versions).  Yes,
his patches are very good, but it completely rewrites cairo-ft.c, so can
use a review still.

I really like to get that in 1.6.  Will see.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/13

------------------------------------------------------------------------
On 2007-11-30T03:02:02+00:00 Stanislav Brabec wrote:

Please review carefully, porting of this patch was not trivial and I
could make any mistake.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/14

------------------------------------------------------------------------
On 2007-12-02T16:43:28+00:00 Sylvain Pasche wrote:

The Ubuntu developers slightly enhanced the patch:
"debian/patches/02-cairo-1.4.8-lcd-filter-2.dpatch:
    - Restore patch that uses the new FreeType LCD colour filtering features,
      with additional modification that the specific LCD Filter can be
      changed."
(you can get the source from http://packages.ubuntu.com/gutsy/libs/libcairo2)

I tried porting that patch on the trunk (as expected, it doesn't apply
cleanly). However, glyph positioning is broken. I'll try to debug this
when I have time.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/15

------------------------------------------------------------------------
On 2007-12-02T16:45:03+00:00 Sylvain Pasche wrote:

Created an attachment (id=12910)
text-rotate testcase after ported patch

Compare with reference:
http://gitweb.freedesktop.org/?p=cairo;a=blob;h=b2273989263552c3bb8ddb7d27a2eb319857da4a;hb=9c732594039b164a1e08125c35ec9d04278f0cbf;f=test
/text-rotate-ref.png

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/16

------------------------------------------------------------------------
On 2007-12-02T16:53:50+00:00 Sylvain Pasche wrote:

I forgot to add:

I looked at the freetype rewrite patches from David Turner
(http://david.freetype.org/cairo/fix-freetype-usage-4.patchset), but
they do not seem to have the lcd-filtering enhancement proposed here (I
saw no FT_Library_SetLcdFilter call). So these two changes should be
independent (of course, the patch here might need large adaptations to
by applied on top of the freetype rewrite).

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/17

------------------------------------------------------------------------
On 2007-12-04T23:23:22+00:00 Brandon Wright wrote:

I would like to see this go into 1.6 as well. It seems many packagers
are already using it, so it wouldn't hurt, and it makes sub-pixel
rendering much better looking.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/18

------------------------------------------------------------------------
On 2007-12-04T23:34:31+00:00 Brandon Wright wrote:

Created an attachment (id=12955)
Incorrect glyph positioning on 1.5 branch

I've applied the patch to cairo 1.5.2 after some fuzzing, but it seems
I've run into the same glyph layout issue Sylvain encountered.

I've attached a screenshot from my GNOME appearance pane. It was the
only location I could find where the the labels are large enough to
avoid completely clipping the text. It appears from this that the
vertical positioning is significantly off, but the horizontal
positioning is only wrong by a few pixels on some glyphs.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/19

------------------------------------------------------------------------
On 2007-12-05T17:51:09+00:00 Sylvain Pasche wrote:

Created an attachment (id=12971)
patch for 1.5

The patch needed to be updated according to
31f5aafa36015ee6ea8ff769c2e1d5841f62642f.

This is now running quite better.

Tests will need to be updated / completed.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/20

------------------------------------------------------------------------
On 2007-12-07T02:30:29+00:00 Sylvain Pasche wrote:

Behdad,

Do you prefer to wait for the freetype rewrite before dealing with this
bug? As I said in comment 16, the freetype rewrite will not
automatically solve this issue.

Otherwise, I can help with the test update or cleanup if you think you
can make it for 1.6.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/27

------------------------------------------------------------------------
On 2007-12-08T00:28:29+00:00 Brandon Wright wrote:

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.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/29

------------------------------------------------------------------------
On 2007-12-08T02:23:21+00:00 Brandon Wright wrote:

Created an attachment (id=12997)
Silvain's patch against 1.5, modified to use correct definitions.

Some definitions needed editing to make the filter configuration from
Ubuntu work. This patch contains those modifications.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/30

------------------------------------------------------------------------
On 2007-12-08T02:39:58+00:00 Brandon Wright wrote:

I've created bug 13566 with the modification patch to fontconfig that
allows the cairo patch to apply.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/31

------------------------------------------------------------------------
On 2007-12-08T04:38:52+00:00 Bugzilla-namtrac wrote:

(In reply to comment #23)
> I've created bug 13566 with the modification patch to fontconfig that allows
> the cairo patch to apply.

Tested with cairo 1.5.4 and fontconfig 2.5.0 with patches for each,
works fine.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/32

------------------------------------------------------------------------
On 2007-12-08T06:58:41+00:00 Sylvain Pasche wrote:

Thanks Brandon for making this Ubuntu independent. I didn't know
Ubuntu's fontconfig was also patched.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/33

------------------------------------------------------------------------
On 2007-12-20T11:26:11+00:00 Brandon Wright wrote:

I'd like to add that the Cairo patch doesn't seem to include support for
setting the filtering type in the fontconfig configuration files. It
only reads the value from the X resource database. If this were to to be
committed, it'd probably be a good idea to have that config file
support. Someone more familiar with cairo's font options than me would
have to do this.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/42

------------------------------------------------------------------------
On 2008-01-20T15:02:10+00:00 Sylvain Pasche wrote:

Created an attachment (id=13825)
patch v2 for 1.5

This new versions adds LCD filtering to the public API as discussed on
the mailing list. I also added support to read the filtering
configuration from Fontconfig.

This patch is the merge of a series of smaller patches which are visible
at http://spasche.net/hg/cairo-patches/file/. A description of each
patch, in queue order:

lcd-filtering-david.diff
  This is the original patch that David wrote, slightly modified for 1.5 compatibility.

lcd-filtering-david-style-fix.diff
  This contains modifications for matching Cairo coding style more closely.

lcd-filtering-font-options.diff
  This contains the modification for adding the lcd filter option to the public API and the cairo_font_options_t type.

lcd-filtering-fc-compat.diff
  This adds define for compatibility when without the new lcd filtering constants (Fontconfig patch not yet applied, see bug 13566).

lcd-filtering-xlib-screen.diff
  Adds support to retrieve the lcd filter from the Xrm database (from the previous patch).

lcd-filtering-handle-fontconfig-fontoptions.diff
  The interaction with Fontconfig to deal with the lcd filter type.

lcd-filtering-doc.diff
  Update in the documentation files for the public API change


I hope this splitting can help you for the review, to understand the patch evolution. Maybe I could publish this as a private git repository, but I was familiar with mercurial queues already.

I'm using the legacy filter as a default when nothing is specified in
Xrm or Fontconfig. This is the "less surprise" choice as the appearance
won't change after being applied. Distributions can change the default
in the global fontconfig configuration. I think this choice goes in the
same direction as what was discussed on the mailing list.

The lcd-filtering-fc-compat.diff patch could be removed if we force the
dependency on Fontconfig 2.6 (after the needed changes are in). But I
guess this can be too much requirements.

The tests remain to be updated and added.

Of course the biggest part of this patch is the part from David.
Unfortunately he seems not to have much time for Freetype/Cairo these
days. I can try to help if you need some digging in that part.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/49

------------------------------------------------------------------------
On 2008-01-21T21:46:31+00:00 Freedesktop wrote:

Can you create and publish a git tree with these patches?

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/50

------------------------------------------------------------------------
On 2008-01-22T15:11:12+00:00 Sylvain Pasche wrote:

(In reply to comment #28)
> Can you create and publish a git tree with these patches?

I've setup a tree there:
http://spasche.net/git/cairo.git/

The patches can be found in the lcd-filter branch

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/51

------------------------------------------------------------------------
On 2008-01-22T15:49:31+00:00 Freedesktop wrote:

- In cairo_lcd_filter_t docs, both FIR's are documented as 5x5.

- Maybe put them in this order: DEFAULT, NONE, INTRA_PIXEL, FIR3, FIR5.

+    /* XXXsyp is this needed? */
+    if (other->base.lcd_filter == CAIRO_LCD_FILTER_NONE)
+	options->base.lcd_filter = CAIRO_LCD_FILTER_NONE;

Well, this is one of the controversial areas in the current cairo-ft
code.  I'm not sure, but following neighboring code, seems like this is
correct.  Remove the XXX.


Looks good to me.  Can be merged!  Just fixed the above as a followup patch in your tree and I'll fetch and push!

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/52

------------------------------------------------------------------------
On 2008-01-22T16:02:20+00:00 Bugzilla-namtrac wrote:

Does this still need a Fontconfig patch?

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/53

------------------------------------------------------------------------
On 2008-01-22T16:20:04+00:00 Freedesktop wrote:

Fontconfig patch is upstreamed, will be in 2.6.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/54

------------------------------------------------------------------------
On 2008-01-22T16:21:29+00:00 Bugzilla-namtrac wrote:

(In reply to comment #32)
> Fontconfig patch is upstreamed, will be in 2.6.

Good news, thanks.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/55

------------------------------------------------------------------------
On 2008-01-22T17:05:39+00:00 Sylvain Pasche wrote:

Thanks for the review. I pushed a new commit with comments addressed.

On Fedora 8 grayscale antialising is used instead of subpixel because
freetype is not compiled with FT_CONFIG_OPTION_SUBPIXEL_RENDERING. Would
be good to find a solution for this. This may regress the subpixel
antialiasing test as a side effect.

I'll write some new tests for the API, something close to text-
antialias-XXX.c tests.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/56

------------------------------------------------------------------------
On 2008-01-26T19:37:04+00:00 Sylvain Pasche wrote:

Patents related to subpixel antialiasing are listed on
http://david.freetype.org/cleartype-patents.html and
http://www.microsoft.com/about/legal/intellectualproperty/search/details.mspx?ip_id=IDARAQHD&techType=Any&ipCat=Any&feeStructure=Any&keywords=cleartype&ipVenture=false

They were filled between 1998 and 1999 and have an issue date from 2001
to 2003. Adding 20 years to the latest issue date makes them expire
around 2023 (if they are not renewed). Not quite in time for Cairo 1.6
;-)

I tried to search for the filtering algorithms in these patents (intra-
pixel or FIR), but didn't see the specific filter algorithms or FIR
kernels described. They seem to cover the whole subpixel process rather
than specific algorithms (which is what is quoted from David in comment
0).

I checked an OpenSuse live-cd. They patch Cairo with this patch and do
not compile FreeType with subpixel support. The fonts are rendered in
gray-antialiasing even when you choose subpixel in the font properties
dialog.

My feeling is that applying this patch this is the safest way to go for
Cairo regarding patents. Unfortunately, not having subpixel antialiasing
available by default is the price to pay for avoiding patents
infringements (in the countries where software patents apply). OpenSuse
is already in this situation today, so that may be an example that a
major distribution can ship without this feature by default.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/57

------------------------------------------------------------------------
On 2008-01-27T10:56:34+00:00 Bugzilla-namtrac wrote:

Patch once again doesn't apply to latest git :/

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/58

------------------------------------------------------------------------
On 2008-01-27T12:14:00+00:00 Sylvain Pasche wrote:

(In reply to comment #36)
> Patch once again doesn't apply to latest git :/

You should merge from my git tree:

> git remote add spasche.net http://spasche.net/git/cairo.git
> git fetch spasche.net
> git merge spasche.net/lcd-filter

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/59

------------------------------------------------------------------------
On 2008-01-27T12:20:06+00:00 Bugzilla-namtrac wrote:

Great thanks that works.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/60

------------------------------------------------------------------------
On 2008-02-16T05:25:39+00:00 Brandon Wright wrote:

What is the status on this being committed? Are politics posing a
problem, or is it just that nobody has had any time to review it yet?

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/61

------------------------------------------------------------------------
On 2008-02-16T05:29:48+00:00 Sylvain Pasche wrote:

I guess it more about politics right now. Behdad told me he has to
discuss this with other developers to decide what direction to take.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/62

------------------------------------------------------------------------
On 2008-04-04T12:05:28+00:00 Brandon Wright wrote:

Behdad, are you still hesitant to commit this or haven't you got to it
yet?

As a note, I don't really think the patents are a concern in this case.
As David Turner says, they apply to all subpixel decimation (they would
affect what's already in Cairo if they're valid, so not committing isn't
saving any trouble), and the issue is already being taken care of by
disablement at the source--FreeType.

I'd really like to see this go in before the 1.6 release.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/63

------------------------------------------------------------------------
On 2008-04-04T12:12:08+00:00 Freedesktop wrote:

We are waiting to get 1.6 out before committing this.  As a matter of
principle, we don't commit patches of this size this late in the release
cycle.  This is the kind of stuff that sshould go in early in the devel
cycle and that's what we are going to do.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/64

------------------------------------------------------------------------
On 2008-04-13T01:45:56+00:00 Arkadiusz Miśkiewicz wrote:

(In reply to comment #37)
> (In reply to comment #36)
> > Patch once again doesn't apply to latest git :/
> 
> You should merge from my git tree:
> 
> > git remote add spasche.net http://spasche.net/git/cairo.git
> > git fetch spasche.net
> > git merge spasche.net/lcd-filter
> 

Could you update your repository to latest stable release? (1.6.4)

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/65

------------------------------------------------------------------------
On 2008-04-13T10:35:35+00:00 Sylvain Pasche wrote:

I prefer to work again on this when things are ready for inclusion (in
the next release cycle). Behdad, you can ping me if I can help.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/66

------------------------------------------------------------------------
On 2008-04-13T11:46:38+00:00 Arkadiusz Miśkiewicz wrote:

(In reply to comment #44)
> I prefer to work again on this when things are ready for inclusion (in the next
> release cycle). Behdad, you can ping me if I can help.
> 

Oh, too bad. Next release cycle (1.8 line) won't happen soon afaik
(another year maybe).

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/67

------------------------------------------------------------------------
On 2008-04-14T11:13:47+00:00 Carl Worth wrote:

(In reply to comment #44)
> I prefer to work again on this when things are ready for inclusion (in the next
> release cycle). Behdad, you can ping me if I can help.

Just for reference, "next release cycle" is now, now that 1.6.0 (and
1.6.2... and 1.6.4) are out.

(In reply to comment #45)
> Oh, too bad. Next release cycle (1.8 line) won't happen soon afaik (another
> year maybe).

1.8 is currently scheduled, (in a wild-guess fashion), for November
2008. I would like to have major releases be closer than a year apart.

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/68

------------------------------------------------------------------------
On 2008-05-07T12:25:14+00:00 James H. Cloos Jr. wrote:

Now that Keith commited the fontconfig support I’ve been testing out
this patch, using this snippit in my fonts.conf:

<?xml version="1.0"?>
<fontconfig>
 <match target="font">
  <test name="fontformat" compare="eq">
   <string>TrueType</string>
  </test>
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
  <edit mode="assign" name="hintstyle">
   <const>hintfull</const>
  </edit>
  <edit mode="assign" name="lcdfilter">
   <const>lcdlegacy</const>
  </edit>
 </match>

 <match target="font">
  <test name="fontformat" compare="eq">
   <string>CFF</string>
  </test>
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
  <edit mode="assign" name="lcdfilter">
   <const>lcdlight</const>
  </edit>
 </match>

 <match target="font">
  <test name="fontformat" compare="eq">
   <string>Type 1</string>
  </test>
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
  <edit mode="assign" name="lcdfilter">
   <const>lcdlight</const>
  </edit>
 </match>
</fontconfig>

to get native hints and the legacy filter for sfnt/glyf fonts and light
hints with the light filter for sfnt/cff and type1 fonts.  I’ve also
experimented with lcddefault for the latter two.

Most of the apps I use heavily are still libXft-based, but for those I
generally end up with well-instructed sfnt/glyf fonts anyway.  The cairo-
using apps I’ve tested, though, look better with the varying filtering
than without.

When merging the branch to master¹ there are two conflicts in:

        src/cairo-font-options.c
        src/cairo-ft-font.c

Both are pretty obvious given a look at their history in Sylvain’s
branch.

There are a couple of minor style nits:  there may be some tab-vs space
ambiguity and the single-line if blocks have braces (the removal of such
braces on master causes one of those two conflicts), but otherwise nothing
stood out in a quick look.

The cairo ebuild in my personal Gentoo overlay² has the (single file)
patch³ from master to the merged lcd_filer branch, in case any other
Gentoo users want to try it out.

1] as of commit b7272e9e
2] git://people.freedesktop.org/~cloos/overlay.git
3] http://cgit.freedesktop.org/~cloos/overlay/diff/x11-libs/cairo/files/lcd-filter.patch

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/69

------------------------------------------------------------------------
On 2008-06-03T01:20:44+00:00 Brandon Wright wrote:

Carl or Behdad: Since Cairo is still fairly early in the pre-1.8 cycle,
can you push this to git master now? I'd hate to see this miss the
feature-freeze again.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/70

------------------------------------------------------------------------
On 2008-07-27T17:48:15+00:00 Nicolaus Hepler wrote:

Allo Gentlemen,
I'm a gtk/cairo user with a particular interest in this bug & patch.
Before this series of patches went into Debian, I kept some of Mr. Turner's patches around for my own use.
The development that has gone into these patches has __greatly__ increased the usability of gtk & gnome for me, and I'd hate to see the work done lost in the 1.8 development cycle.
If the remaining patches around need some sprucing up, I wouldn't mind testing my understanding of cairo innards to tidy them up a bit, given all the new and cool changes Behdad has put into the font layers.
Consider this a gentle >>poke<< then gentlemen.

Thanks,
Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/71

------------------------------------------------------------------------
On 2008-07-29T11:26:37+00:00 Freedesktop wrote:

Thanks for the comments.

Actually current plan is to get 1.8 out in about a month.  Yes!

It would be nice if someone could test and update the patch to git
master.  I can commit after that then.

I also want to see what kind of filtering control, if any, Windows and
OS X native APIs provide.  Is there any hope of even implementing these
new APIs for those font backends or it will remain a FreeType-only
thing?  Not that it's a deal breaker, not at all.  Just want to know.

Cheers,

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/72

------------------------------------------------------------------------
On 2008-07-29T13:06:17+00:00 Sylvain Pasche wrote:

Hi Behdad,

I can get at it after the summit (early next week) if nobody hasn't
updated it yet.

I can't answer for the Windows/OSX question yet, but I'll have a look.
Thanks.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/73

------------------------------------------------------------------------
On 2008-07-29T13:39:47+00:00 James H. Cloos Jr. wrote:

Created an attachment (id=17973)
Update of patch to cleanly apply to git master

In reply to comment #50)
> It would be nice if someone could test and update the patch to git master.
> I can commit after that then.

Here is the version I’ve been applying in my local ebuild.

It works fine for me.  I’ve tested the differences between the cairo and
xft backends to pango-view and have configured fontconfig to prefer
different hinting and filtering options for different font techs as well
as for different font qualities.  All w/o any issues.

I originally created the patch in git, and have just updated its offsets
by applying it with patch and re-creating it with git-diff.

Attached here for review purposes.

(My uplink is a bit flakey, so I gzip(1)ed it to make sure it would
upload.)

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/74

------------------------------------------------------------------------
On 2008-07-29T13:43:15+00:00 James H. Cloos Jr. wrote:

Created an attachment (id=17975)
Non-gzip(1)ed version of attatchment 17973

(Uplink being what it is, this may not work, but just in case.....)

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/75

------------------------------------------------------------------------
On 2008-07-29T15:22:07+00:00 Freedesktop wrote:

Sylvain, oh, we should meet at the summit!
I'm sitting in the lobby downstairs hacking.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/76

------------------------------------------------------------------------
On 2008-08-05T07:12:18+00:00 Sylvain Pasche wrote:

I've pushed an updated version on http://spasche.net/git/cairo.git
(thanks James for the updated patch, that helped me for merging).

I've added a new patch with tests (text-lcd-filter-*). I had to update
the text-antialias-subpixel reference image now that the subpixel
antialiasing uses FreeType. (I didn't update/add quartz reference image,
should I do that?).

I had a quick look for the Windows / OS X story, I didn't find APIs for
controlling the LCD filter but it is possible I missed something.

On Windows, the LCD filtering is handled by ClearType. The ClearType
settings are stored in the registry (HKCU/Control
Panel/Desktop/FontSmoothing* entries). The LOGFONT structure which
defines the attributes of a font has a lfQuality member to select if
ClearType should be used for the font. So it doesn't look like to be
possible to change the LCD filtering algorithm through the font API.

For OS X, outside of the
CGContextSetAllowsAntialiasing/CGContextSetShouldAntialias methods, I
didn't find something that looks like to control the type of LCD filter.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/77

------------------------------------------------------------------------
On 2008-08-05T13:39:05+00:00 Freedesktop wrote:

Counting objects: 82, done.
Compressing objects: 100% (63/63), done.
Writing objects: 100% (63/63), 15.12 KiB, done.
Total 63 (delta 51), reused 0 (delta 0)
refs/heads/master: acdc306905b4a39911fd58e9d72aa3db5e1b8760 -> 221599ab0fc1a2fa878659fe5bef88104e56a07c
To git+ssh://git.cairographics.org/git/cairo

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/78

------------------------------------------------------------------------
On 2008-10-01T22:26:15+00:00 Nicolaus Hepler wrote:

Hello Gentlemen,

With the recent release of 1.8.0, all of the lcd_filter checks back into
fontconfig and Xft have been removed.  For me, this is a (rather
tremendous) regression in usability.  I would like this bug to be
reopened so that the re-addition of the code can be followed.  There
might need to be some debate as per Carl Worth's notes to the regression
in lcd filtering ability (which might be the correct way to proceed
anyway -- freetype defaults lcd filtering ability to off in case of
possible violation of MS Cleartype patents).  Providing redundant (and
inferior*) functionality in cairo again might once again jeopardize the
stack.

I would appreciate public updates on the debate around lcd_filtering
ability, since this particular set of additions to cairo significantly
impacts my usability of gnome and cairo on linux.  I have been following
this particular set of patches for many _years_, keeping patched
versions of my own.  I do think these additions would be of benefit to
all users of cairo.

Thank you gentlemen,
If you need anything from me, or would like to see some involvement from me, just ask.  I just need to find time away from the pursuit of my doctorate.

Nicolaus Hepler

* I do apologize to whomever made cairo's filter in the first place, but
in my opinion it _is_ inferior to freetype's filters -- the current
pixel-clipping code in cairo lcd filtering results in yellow-blue halos
that are quite evident to me on any screen I've used.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/79

------------------------------------------------------------------------
On 2008-10-01T23:03:43+00:00 Carl Worth wrote:

(In reply to comment #57)
> Hello Gentlemen,

Hi Nicolaus,

> With the recent release of 1.8.0, all of the lcd_filter checks back into
> fontconfig and Xft have been removed.  For me, this is a (rather tremendous)
> regression in usability.

Yeah, sorry about that. I know that some people really wanted these new
filtering options, and it had always been my intent that they be present
in 1.8.0. It was just that I didn't notice until *very* late in the
release cycle that I couldn't accept how this had been implemented.

>  I would like this bug to be reopened so that the
> re-addition of the code can be followed.

Done. (Did the bugzilla interface not allow you to re-open it yourself?
I'd generally prefer people just throw the switches they want in bugs,
rather than asking for others to throw them.)

> Providing redundant (and inferior*) functionality in cairo again might once again
> jeopardize the stack.

No debates on patents, please. That's not cairo's concern.
 
> I would appreciate public updates on the debate around lcd_filtering ability,

It seems easy to me. Just use the freetype APIs if they are present
*and* they are actually functional, (not the "you asked for subpixel,
but I'll give you gray" thing). And if not, use the code that's already
in cairo.

We should even be able to make a change like that for a minor release,
(1.8.2 or 1.8.4).

> If you need anything from me, or would like to see some involvement from me,
> just ask.

Just need somebody to code that up.

> * I do apologize to whomever made cairo's filter in the first place, but in my
> opinion it _is_ inferior to freetype's filters

Well, it's really just a matter of what assumptions it was coded
against.

>  -- the current pixel-clipping
> code in cairo lcd filtering results in yellow-blue halos that are quite evident
> to me on any screen I've used.

The filters in cairo were written with the assumption of strong hinting.
And with that hinting, I still haven't seen any better filters,
(freetype provides a "LEGACY" filter that's supposed to be similar---
it's not identical but I don't know if one or the other would be
"better" in my opinion). I do agree that there are really bad color
fringes if you use this filtered sub-pixel rendering without good
hinting. I think "just don't do that" would be that reaction of the
original filter's author. :-)

So that's not to disagree with you at all, just to explain how this code
actually can function quite well.

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/80

------------------------------------------------------------------------
On 2008-10-02T01:00:15+00:00 Nicolaus Hepler wrote:

Hi Carl,

Sorry about asking about the bug switch.  I don't like being pushy, and
some people are very protective of their bug tracking systems.  Glad to
know you're not so overly-protective. ~ grin ~

As for the patent thing, you're probably right.

And again for cairo's built-in filtering -- I usually never use strong
hinting.  Slight hinting almost always produces better shapes (well for
me at least -- I still find Windows users not using Cleartype, but then
again this is a preference thing.)  So that explains my usage case at
least.  Thanks for letting me know.

I'll get on coding up a piece of that switch, then.

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/81

------------------------------------------------------------------------
On 2008-10-02T09:51:20+00:00 Belshazzar wrote:

> (In reply to comment #57)

Hello Carl. I very much agree with Nicolaus. I also understood that you
were not against the Turnerian FIR filters but against possible
distributors’ choices affecting what Cairo can promise to render or not.
Still I want to point something out regarding which filter is better for
Cairo.

> The filters in cairo were written with the assumption of strong hinting. And
> with that hinting, I still haven't seen any better filters, (freetype provides
> a "LEGACY" filter that's supposed to be similar---it's not identical but I
> don't know if one or the other would be "better" in my opinion). I do agree
> that there are really bad color fringes if you use this filtered sub-pixel
> rendering without good hinting. I think "just don't do that" would be that
> reaction of the original filter's author. :-)

But strong hinting is the wrong assumption to begin with. Full hinting —
or worse, byte-code superhinting — is so 1990’s!

Sure, a lot of coder/UNIX types still prefer high contrast on-screen
text, but for Cairo an algorithm that is so robust that it can
accomodate both full hinting and light autohinting is much a much better
match.

Cairo is general purpose, so one thing it’s used for is on-screen text
in UI and, e.g., webpages. This is a setting where full hinting makes
some sense, because integer point sizes are used and the Cairo filter
then has to deal with 1px stems only. No big deal, as only the curves
and bowls and diagonals need attention.

But Cairo is also used for freely scalable canvases, for rich graphics
using serif, script, or decorative typefaces. For animation. Strong
hinting makes no sense here. On a general image surface nice autohinted
text blends in a lot better. Autohinting /is/ »good hinting«. And the
FIR filters are the best match for it. Even better, the FIR filters even
give very good results for strongly hinted UI text. It’s just more
versatile.

Please see the AB comparison page I made: http://www.alice-dsl.net/towolf/cairo/
(Weakness: It only presents one case, one text setting, unlike the huge comparison that Sylvain presented.)

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/82

------------------------------------------------------------------------
On 2008-10-02T17:09:34+00:00 Carl Worth wrote:

(In reply to comment #60)
> Please see the AB comparison page I made:
> http://www.alice-dsl.net/towolf/cairo/
> (Weakness: It only presents one case, one text setting, unlike the huge
> comparison that Sylvain presented.)

I'm interested in replying to more of what you've written, but first I
wanted to point out that I can't get your comparison page to work.
(Nothing changes when I move the mouse on and off the images. I can
right-click and do "open image" and then I will get a different image,
but I can't even do that for both images for switching back and forth
between two tabs.)

This is with gecko, (either Debian's iceweasel 3.0.1 or Debian's "GNOME
Web Browser" 2.22.3 "powered by gecko-1.9).

Any ideas? I'm curious to see the images.

-Carl

PS. And I'm delighted to see so much commentary with the images. So
often in the past I've seen people trying to advocate for these patches
with things like "look at these two images! Obviously you see why I want
this patch", and then I'm just lost as to which is supposed to look
better or why, etc.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/83

------------------------------------------------------------------------
On 2008-10-03T03:17:43+00:00 Nicolaus Hepler wrote:

Created an attachment (id=19349)
First attempt to keep default cairo lcd rendering when freetype can't do it.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/84

------------------------------------------------------------------------
On 2008-10-03T03:19:12+00:00 Nicolaus Hepler wrote:

(From update of attachment 19349)
Carl,

I'm also interested in seeing these examples, but I too can't view the hoversrc
image -- Firefox 3.0.2 here.

I thought this shouldn't be too difficult to fix since " ... [the]
`FT_Library_SetLcdFilter' function returns the FT_Err_Unimplemented_Feature
error code."

Attached is a preliminary patch.  I apologize for my newbieness with C, I've no
formal training in it.  Doubtlessly I have a "paper bag issue" somewhere in my
code.  Comments extremely welcome.

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/85

------------------------------------------------------------------------
On 2008-10-03T06:25:44+00:00 Belshazzar wrote:

(In reply to comment #61)
> (In reply to comment #60)
> I'm interested in replying to more of what you've written, but first I wanted
> to point out that I can't get your comparison page to work. (Nothing changes
> when I move the mouse on and off the images. I can right-click and do "open
> image" and then I will get a different image, but I can't even do that for both
> images for switching back and forth between two tabs.)

Ja, let me say ›oops‹. In a rush to get it out the door I neglected to
test with Firefox. It seems I followed the wrong mouseover tutorial.
Should work now.

But I’ve figured I must also add an example of large display type, so
you get added value now.

> PS. And I'm delighted to see so much commentary with the images. So often in
> the past I've seen people trying to advocate for these patches with things like
> "look at these two images! Obviously you see why I want this patch", and then
> I'm just lost as to which is supposed to look better or why, etc.

There’s certainly an inherent danger in pointing to screenshots and
shouting: »See? See? It’s so much better!« because that’s not
necessarily true for everybody. Someone might just have gotten new,
sharp spectacles, or she is myopic and sits 20cm from the screen — loupe
effect!.  Or someone’s screen is really low-res, rotated to portrait, or
whatnot.

The point here is that configurability is a necessity due to taste
differences. So with the patch we can have GRAY, LEGACY, FIR3 and FIR5.
Importantly the FIR filters are the most versatile and robust. They work
well across the board, LEGACY doesn’t. Thus they are the best candidates
for the LCD_FILTER_DEFAULT designation.

A future font appearance configuration panel should offer more options
to tweak this. But it should probably only make sensible combinations
possible. That is, if native TrueType instructions are enabled then
LEGACY or monochrome make sense. If slight hinting is enabled, then FIRx
and GRAY make sense.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/86

------------------------------------------------------------------------
On 2008-10-03T17:24:36+00:00 Nicolaus Hepler wrote:

Created an attachment (id=19362)
Fallback to cairo lcd filtering if freetype cannot.

Gentlemen,

This is my second attempt, minus several "paper bag" sort of incidents.
I've compiled, tested, and am using this version now, switching between +/- lcd-filtering versions of freetype freely and having cairo lcd filter in all cases (although preferring freetype filtering when available).

Hope this helps!

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/87

------------------------------------------------------------------------
On 2008-10-11T08:33:37+00:00 Belshazzar wrote:

Hello again. I was curious, so I added a new section to my comparison page juxtaposing Vista and Cairo:
http://www.alice-dsl.net/towolf/cairo/#vista

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/88

------------------------------------------------------------------------
On 2008-10-11T09:25:38+00:00 Carl Worth wrote:

(In reply to comment #66)
> Hello again. I was curious, so I added a new section to my comparison page
> juxtaposing Vista and Cairo:
> http://www.alice-dsl.net/towolf/cairo/#vista

Hello again,

While you're adding new images, I'd like to write up a couple quick
thoughts based on your presentation so far.

First, you seem to be largely arguing for a change in the default
filtering, beyond just adding code to allow for the freetype filtering
to be used. That's certainly a useful discussion to have. But oddly, the
images on the page don't actually show direct comparisons of the
different choices we have here for a default. I'd like to see the
results of cairo's current code compared to freetype's LEGACY and that
compared to FIR3 and FIR3 compared to FIR5. Things like that.

You also limit the presentation by saying "This is not a test of the
boring canonical high contrast scenario with bytecode hinted DejaVu
Sans, 8pt text, and pixel-fitted stems.". As "boring" as that scenario
might be, it's a terribly important one, so I would really like to see
some examples of that added if you would. I'd like to ensure a "do no
harm" situation here.

Meanwhile, another problem I had with the original patch series was that
it simply exported all of the freetype filters as-is up to the user
level through cairo's public API. One problem with this is that the
filters are all obviously freetype-specific while cairo provides a
cross-platform API. An argument for providing the API is for someone
like Behdad to be able to write a font-preferences dialog that presents
(unnamed) font-rendering samples to the user and lets them simply click
on which one they prefer.

But for that kind of font-preferences dialog, we already have 3
different ANTIALIAS font options and 4 different HINT_STYLE options. So
that's 12 different necessary samples now, and adding 4 different
filters expands that to 48, which seems to go way beyond what any user
could ever want to see.

Meanwhile, the descriptions on your page seem to argue for specific
filters being best in specific situations. For example, there seems to
be an implicit preference for FIR5, (no FIR3 examples, and a link to an
Ubuntu poll favoring FIR5). So is there any reason to provide FIR3 at
all? Also, you argue that LEGACY doesn't do well in anything but the
strongly-hinted case, but does it (or cairo's code?) actually do best
there?

I'm wondering if we shouldn't automatically choose a filter based on the
HINT_STYLE option. I'm also wondering that if we do decide to expose
these in the API whether we should just export two options absed on
their general characteristics, (INTER_PIXEL and INTRA_PIXEL ?), rather
than so much about their details implementation, (FIR3 and FIR5, etc.).

Well, this is all a little bit off-topic for the specific bug here, and
it's getting into API discussion that really needs to take place on the
cairo list.

Let's move the discussion there. Feel free to quote my stuff liberally
or completely if you'd like to reply on the list.

Thanks,

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/89

------------------------------------------------------------------------
On 2008-10-11T13:42:49+00:00 Freedesktop wrote:

Carl, you really should try maintaining a distro's text stack for a
couple years before you get it:  There is no sensible defaults.  People
file bugs about their text rendering where it looks perfectly fine to
me.  Certainly much better than what they call the unbuggy version.
Choosing filters based on hintstyle, or exposing some but not other
filters is simply not cairo's business.  Smple as that.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/90

------------------------------------------------------------------------
On 2008-10-16T07:19:18+00:00 Brandon Wright wrote:

Nicolaus, what source tree is your patch based on? I can't get it to
apply to either 1.8.0 or master.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/91

------------------------------------------------------------------------
On 2008-10-16T08:05:15+00:00 Brandon Wright wrote:

(In reply to comment #69)
> Nicolaus, what source tree is your patch based on? I can't get it to apply to
> either 1.8.0 or master.
Ok, I see it applies well enough against master with commit 5d887ad5dca5af0f8216830d1b04d08a5aba9bee reverted.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/92

------------------------------------------------------------------------
On 2008-10-17T22:11:11+00:00 Nicolaus Hepler wrote:

Yea, it applies to a revert of the revert of the lcd_filtering
functionality.  There's still some stupid crap in that code, I realize,
so I'm going to  go over it again.  But at least it works.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/93

------------------------------------------------------------------------
On 2008-10-18T09:46:25+00:00 Carl Worth wrote:

(In reply to comment #68)
> Carl, you really should try maintaining a distro's text stack for a couple
> years before you get it:  There is no sensible defaults.  People file bugs
> about their text rendering where it looks perfectly fine to me.  Certainly much
> better than what they call the unbuggy version.  Choosing filters based on
> hintstyle, or exposing some but not other filters is simply not cairo's
> business.  Smple as that.

I don't buy it, Behdad.

Certainly, you have experience that I don't here. I don't content that.
And users often do want text-rendering results that seem hard to believe
---I've seen that.

But as for the details of which kind of LCD filtering---your
distribution has never made that available as an option, right? So what
evidence do you have that people won't be satisfied here? Just that
"they're never satisfied"?

I'd really like to do something very much like "strong
hinting"->"current filtering" and "slight/medium hinting"->"freetype's
FIR5 filtering" and see if that satisfies people. And best would be to
do that experiment by way of the new text-preferences dialog where
people choose the version that they like the best. I really can't
imagine many people saying "none of the above". (I think most hard-to-
understand complaints come from people not being able to achieve a
result that they are accustomed to---and that's precisely part of the
reason that led to the revert of the freetype-filter using code during
1.7.x.)

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/94

------------------------------------------------------------------------
On 2008-11-14T15:35:11+00:00 Brandon Wright wrote:

Sorry for bringing this bug up again, but I noticed cairo 1.8.4 is now
out, and I was wondering what else needed to be done to put filtering
back into the next point release (if it's still possible). What are
everyone's opinions of Nicolaus's patch, and is something else required
that his patch doesn't handle?

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/95

------------------------------------------------------------------------
On 2008-12-14T22:28:40+00:00 Nicolaus Hepler wrote:

Created an attachment (id=21150)
Fallback to cairo's original LCD filtering if freetype lacks the capacity

Here's an updated patch for mainline, applies directly to HEAD.
I've compile-tested it, and a derivative of the patch on a VirtualBoxed Ubuntu Intrepid System. It works, but it's not HEAD.
If anyone finds any bugs, please let me know.
Now that classes are in remission and I'm no longer over-taxing myself, I'd really like to get this issue resolved.
There's been some discussion from Carl on what he'd like to see, but nothing really decided upon. If we could have a discussion and lay down what needs to be done to get these Freetype filtering patches upstream, that'd be a step in the right direction.

Thanks everyone!

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/96

------------------------------------------------------------------------
On 2008-12-30T18:23:21+00:00 Nicolaus Hepler wrote:

This is a gentle >>nudge<<.
Behdad or Carl, can either one or both of you suggest a plan of action?
I would like to get the ball moving on this one.
We currently have downstream distros differing on this issue greatly, the situation could easily be improved.

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/97

------------------------------------------------------------------------
On 2008-12-30T22:13:58+00:00 Brandon Wright wrote:

Nicolaus, I tested your latest patch against HEAD, and it has a bug
where grayscale or monocolor fonts are extra-wide. I've also tested HEAD
with just reverting 5d887ad5dca5af0f8216830d1b04d08a5aba9bee and fixing
the conflicts, and the bug isn't there. It looks like something in your
patch is multiplying a number against the width/pitch when it shouldn't
be, or not dividing it out when it should. Since both your original
patch and HEAD with the revert work fine, I figure you'll know if you
changed something along these lines that might be causing it.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/98

------------------------------------------------------------------------
On 2008-12-30T22:15:38+00:00 Nicolaus Hepler wrote:

Thanks Brandon, I'll take a look.
There's probably some thinko somewhere.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/99

------------------------------------------------------------------------
On 2009-01-24T07:24:06+00:00 Bob+freedesktop wrote:

Ubuntu has included this patch, for some reason, and it causes a problem
with drawing black-on-black text sometimes when VRGB subpixel smoothing
is selected.  The ubuntu bug is:

https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/145604

It appears there might be a byte-shift problem in this patch.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/100

------------------------------------------------------------------------
On 2009-01-25T22:31:56+00:00 Nicolaus Hepler wrote:

Brandon,

Sorry for taking so long to get back. I poured over my changes, and
didn't notice anything out-of-ordinary, save for a single function call
that was unnecessary, and probably wasn't the root of the problem. Could
you tell me your use case, where you see this problem in the patch?

Lance

(In reply to comment #76)
> Nicolaus, I tested your latest patch against HEAD, and it has a bug where
> grayscale or monocolor fonts are extra-wide. I've also tested HEAD with just
> reverting 5d887ad5dca5af0f8216830d1b04d08a5aba9bee and fixing the conflicts,
> and the bug isn't there. It looks like something in your patch is multiplying a
> number against the width/pitch when it shouldn't be, or not dividing it out
> when it should. Since both your original patch and HEAD with the revert work
> fine, I figure you'll know if you changed something along these lines that
> might be causing it.
>

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/101

------------------------------------------------------------------------
On 2009-01-25T23:09:24+00:00 Nicolaus Hepler wrote:

Bob,

Can you open up and look at the version of cairo used by ubuntu, and
apply the 04_lcd_filter.dpatch?

In _fill_xrender_bitmap, look at the section near the end, where it
converts vertical RGB into ARGB32. There is a weird #if 1 #else #endif
block in this particular section, and I think this is where the problem
is. I think the code in the #else block is the correct code, and
changing the #if 1 to #if 0 in the 04_lcd_filter.dpatch might fix it.
(you'll need either a copy of the libcairo2-2ubuntu1 source to compile
from or you'll need to revert the patch. There's some other stipulations
about compiling that you might already know, like you can't have the
original gzipped or bzipped tars of the source in the parent directory,
or the devscipts will use them to build from.)

If anyone else is enlightened as to the math this is trying to perform,
and can tell me for sure that I'm wrong about this particular section
screwing up, I will gladly listen (and learn).

Sylvain, can you look into this? I don't have a platform handy for
looking up their most obvious use case in Compiz, and I can't get
Firefox to do what they say on a couple handy examples.

It would be nice to have this fixed as well as getting a working version
of the fallback patch finally upstream. I wish my time wasn't so spotty,
but it would also be encouraging to hear from either Behdad or Carl. I
know Cairo is a cross-platform tool, and these guys have to worry about
other things cropping up elsewhere, but these patches really help
usability for some of the linux guys. I know Behdad isn't fired up about
this issue, but you, Brandon, and I at least see a point to getting
these patches upstream in some acceptable form.

Nicolaus (Lance)

(In reply to comment #78)
> Ubuntu has included this patch, for some reason, and it causes a problem with
> drawing black-on-black text sometimes when VRGB subpixel smoothing is selected.
>  The ubuntu bug is:
> 
> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/145604
> 
> It appears there might be a byte-shift problem in this patch.
>

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/102

------------------------------------------------------------------------
On 2009-01-26T03:15:49+00:00 Sylvain Pasche wrote:

You seem to be right, the code in "#if 1", sets the alpha channel to full opacity (0xff), so the background behind the glyph won't be visible.
The else sets the alpha to the value of the green channel (same thing as horizontal RGB).

I don't have time right now for looking at this, but could someone test
with that change?  That may be an easy fix.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/103

------------------------------------------------------------------------
On 2009-01-26T16:35:25+00:00 Carl Worth wrote:

(In reply to comment #80)
> It would be nice to have this fixed as well as getting a working version of the
> fallback patch finally upstream. I wish my time wasn't so spotty, but it would
> also be encouraging to hear from either Behdad or Carl. I know Cairo is a
> cross-platform tool, and these guys have to worry about other things cropping
> up elsewhere, but these patches really help usability for some of the linux
> guys. I know Behdad isn't fired up about this issue, but you, Brandon, and I at
> least see a point to getting these patches upstream in some acceptable form.


I still feel the some way about the API issues as I did when I wrote comment #67 above. Has anyone written a patch to address my concerns there?

Also, Behdad's latest review identified some bugs in the patch he saw as
well. Have those been addressed?

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/104

------------------------------------------------------------------------
On 2009-01-27T13:04:44+00:00 Nicolaus Hepler wrote:

(In reply to comment #82)

I will initiate an API discussion later today on the cairo mailing list,
then. I was hoping Behdad's short quip (comment #68) was enough to
convince you, but a discussion is probably for the best.

Latest review? I went hunting around the mailing lists looking for said
review, but could not find it. At least nothing after it was removed
prior to 1.8.0. Are you talking about something before? I should hop
onto the irc channel. I would relish the opportunity to dig in and learn
more about these APIs.

Nicolaus

> (In reply to comment #80)
> > It would be nice to have this fixed as well as getting a working version of the
> > fallback patch finally upstream. I wish my time wasn't so spotty, but it would
> > also be encouraging to hear from either Behdad or Carl. I know Cairo is a
> > cross-platform tool, and these guys have to worry about other things cropping
> > up elsewhere, but these patches really help usability for some of the linux
> > guys. I know Behdad isn't fired up about this issue, but you, Brandon, and I at
> > least see a point to getting these patches upstream in some acceptable form.
> 
> 
> I still feel the some way about the API issues as I did when I wrote comment
> #67 above. Has anyone written a patch to address my concerns there?
> 
> Also, Behdad's latest review identified some bugs in the patch he saw as well.
> Have those been addressed?
> 
> -Carl
>

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/105

------------------------------------------------------------------------
On 2009-01-27T14:02:01+00:00 Carl Worth wrote:

(In reply to comment #83)
> (In reply to comment #82) 
> I will initiate an API discussion later today on the cairo mailing list, then.
> I was hoping Behdad's short quip (comment #68) was enough to convince you, but
> a discussion is probably for the best.

You can see my reply to that above. But I'd already asked for this
discussion to happen on the list, not in this bug report. So, I think
it's great you'll be taking it up there.

> Latest review? I went hunting around the mailing lists looking for said review,
> but could not find it.

I was talking about comment #76. But I misread that---it was from
Brandon, not Behdad. But I still would like to know if those issued have
been fixed.

> Are you talking about something before? I should hop onto the irc channel. I
> would relish the opportunity to dig in and learn more about these APIs.

I'll look forward to chatting with you there.

-Carl

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/106

------------------------------------------------------------------------
On 2009-01-27T16:38:41+00:00 Brandon Wright wrote:

Created an attachment (id=22299)
Screenshot showing error from latest patch

Nicolaus, here's a screenshot showing the problem I'm getting. When
grayscale or no smoothing is used, all the font metrics seem to be
scaled horizontally. Also, it seems that even when disabling
antialiasing, it still ends up using grayscale smoothing.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/107

------------------------------------------------------------------------
On 2009-01-27T23:47:04+00:00 Brandon Wright wrote:

Created an attachment (id=22302)
Revised version of "Fallback to cairo's original LCD filtering if freetype lacks the capacity"

Ok, I've discovered the problem for my issues. Referring to a patched
version of master, On line 1431 of src/cairo-ft-font.c it tests against
the variable ft_can_filter. However, this variable is only initialized
on line 1367 if it's performing subpixel antialiasing, otherwise it's
always false. It ends up using the internal glyph rasterizer, while it
has everything set up for the external one. Moving the line 1431 testing
block to the top level fixes the problem, with the addition of an extra
line to put FT_SetLcdFilter back to normal.

Attached is a version of the patch with said changes made. While I was
modifying it, I noticed that there are some tab/space formatting issues
with the patch that might need to be cleared up.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/108

------------------------------------------------------------------------
On 2009-01-28T18:11:34+00:00 Nicolaus Hepler wrote:

Created an attachment (id=22336)
Revised Revised version of the Freetype Filtering with Fallback patch

Hi Brandon,

Thanks for catching that! I clearly had a thinko in there. But I don't
think that bug was causing the behavior you saw. I'm also curious how
your changes fixed it for you. I recreated the effect you saw, and your
patch didn't fix it for me. Although it clearly fixes a bug that would
have cropped up otherwise.

I did a more thorough review, and discovered a code block that had been
lost. I've stuck it back in, and it fixes the problem for me. I've also
tried to clean up as many of the spacing issues as I could see.

Nicolaus

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/109

------------------------------------------------------------------------
On 2009-01-29T03:02:23+00:00 Brandon Wright wrote:

(In reply to comment #87)
> Created an attachment (id=22336) [details]
> Revised Revised version of the Freetype Filtering with Fallback patch
> 
> Hi Brandon,
> 
> Thanks for catching that! I clearly had a thinko in there. But I don't think
> that bug was causing the behavior you saw. I'm also curious how your changes
> fixed it for you. I recreated the effect you saw, and your patch didn't fix it
> for me. Although it clearly fixes a bug that would have cropped up otherwise.
> 
> I did a more thorough review, and discovered a code block that had been lost.
> I've stuck it back in, and it fixes the problem for me. I've also tried to
> clean up as many of the spacing issues as I could see.
> 
> Nicolaus

It was hitting the correct code path everywhere but in that function,
and the change I made ensured the FT_SetLcdFilter path was used properly
there as well. Your missing code block caused another separate mixed
code path error, and you had the right config to trigger it.

I tested your latest patch, and it works correctly.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/110

------------------------------------------------------------------------
On 2010-06-17T01:24:50+00:00 Chris Wilson wrote:

I've applied the internal interface to pass the LCD filter option from
fontconfig/screen resources to freetype. The interface is not ready to
be made public yet, and I am uncertain about the removal of all fallback
filtering for Cairo.

commit 7a023a62f7517ad0d54f4d59c99909fadcc05e82
Author: Nicolaus L Helper <nlhepler@xxxxxxxxx>
Date:   Thu Jun 17 08:56:30 2010 +0100

    ft,fc,xlib: LCD filtering patch.
    
    This adds internal API to retrieve the LCD filtering parameters from
    fontconfig, or as set on the Screen, and feed them to FreeType when
    rendering the glyph.
    
    References:
      Bug 10301 - LCD filtering patch
      https://bugs.freedesktop.org/show_bug.cgi?id=10301
    
    Tested-by: Brandon Wright <bearoso@xxxxxxxxx>
    Forward-ported-by: Robert Hooker <sarvatt@xxxxxxxx>
    
    ickle: The API is clearly not ready for public consumption, the enum are
    poorly named, however this stands by itself as enabling system wide
    properties.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/111

------------------------------------------------------------------------
On 2010-06-17T01:25:38+00:00 Chris Wilson wrote:

*** Bug 27721 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/112

------------------------------------------------------------------------
On 2010-06-17T02:37:00+00:00 Nicolaus Hepler wrote:

I think the patch you applied should really be credited to whomever did
the original patch (David Turner and Sylvain Pasche?), as all the
fallback code I jimmied with is gone (also, it was mostly just playing
with others' code).

Also, in _fill_xrender_bitmap in the FT_PIXEL_MODE_LCD_V part of the
switch, there's an #if 1 ... 0xFF000000 ; #else ... #endif which makes
it fully opaque. I would remove everything in the #if 1 ... #else
section, and keep what's in the #else ... #endif.

N

> I've applied the internal interface to pass the LCD filter option from
> fontconfig/screen resources to freetype. The interface is not ready to be made
> public yet, and I am uncertain about the removal of all fallback filtering for
> Cairo.
> 
> commit 7a023a62f7517ad0d54f4d59c99909fadcc05e82
> Author: Nicolaus L Helper <nlhepler@xxxxxxxxx>
> Date:   Thu Jun 17 08:56:30 2010 +0100
> 
>     ft,fc,xlib: LCD filtering patch.
> 
>     This adds internal API to retrieve the LCD filtering parameters from
>     fontconfig, or as set on the Screen, and feed them to FreeType when
>     rendering the glyph.
> 
>     References:
>       Bug 10301 - LCD filtering patch
>       https://bugs.freedesktop.org/show_bug.cgi?id=10301
> 
>     Tested-by: Brandon Wright <bearoso@xxxxxxxxx>
>     Forward-ported-by: Robert Hooker <sarvatt@xxxxxxxx>
> 
>     ickle: The API is clearly not ready for public consumption, the enum are
>     poorly named, however this stands by itself as enabling system wide
>     properties.

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/113

------------------------------------------------------------------------
On 2010-06-17T16:30:24+00:00 Nicolaus Hepler wrote:

Created an attachment (id=36349)
fix alpha mapping in vertical RGB to ARGB32 conversion

Fixes the alpha mapping for vertical RGB in _fill_xrender_bitmap in
cairo-ft-font.c

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/114

------------------------------------------------------------------------
On 2010-08-10T01:04:42+00:00 Ranma42 wrote:

commit a150371a5d10e03d6c0d781c6fac950a9ac6be18
Author: Nicolaus L Hepler <nlhepler@xxxxxxxxx>
Date:   Tue Aug 10 09:34:39 2010 +0200

    ft-font: Make alpha mapping consistent
    
    Vertical RGB mapping previously forced opaque pixels.
    To be consistent with horizontal RGB/BGR and vertical BGR it
    should use an alpha equal to the mid channel (green).

Reply at: https://bugs.launchpad.net/fontconfig/+bug/164640/comments/115


** Changed in: libcairo
   Importance: Unknown => Medium

-- 
Build Firefox 3 against a subpixel-patched cairo
https://bugs.launchpad.net/bugs/164640
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Fontconfig.