Cairo Backend and Subpixel Rendering

Hi all,

As some of you probably know I am working on the GSoC project to externalise the Mathtex engine from Matplotlib. Today I have been toying around with the renderer using various backends.

One of the interesting things that I discovered was that the Cairo backend was making use of subpixel rendering. (Or 'ClearType' as Microsoft call it.) This is not surprising -- by default Cairo will respect a users fontconfig settings when rendering text. Since I have subpixel rendering enabled all text rendered by Cairo is subpixel rendered.

While this is fantastic for on screen text -- being significantly more pleasing to look at that the text produced by the AGG backend -- it is unsuitable for print. Now it is not too difficult to disable this, Cairo has an API call: cairo_font_options_set_antialias to deal with this.

While I could write a quick patch to always disable subpixel rendering it would be something off a loss to those who either view their graphs onscreen or export them for the web -- where using subpixel rendering is now surprisingly common.

Is it worth looking into adding subpixel rendering as a configuration option?

Regards, Freddie.

The matplotlib.lines.Line2D objects has an antialiased property -- we
could add the same property to matplotlib.text.Text to turn on/off
subpixel rendering (which could also be supported as an rc param)

JDH

···

On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <freddie@...718...> wrote:

Hi all,

As some of you probably know I am working on the GSoC project to
externalise the Mathtex engine from Matplotlib. Today I have been
toying around with the renderer using various backends.

One of the interesting things that I discovered was that the Cairo
backend was making use of subpixel rendering. (Or 'ClearType' as
Microsoft call it.) This is not surprising -- by default Cairo will
respect a users fontconfig settings when rendering text. Since I have
subpixel rendering enabled all text rendered by Cairo is subpixel
rendered.

While this is fantastic for on screen text -- being significantly more
pleasing to look at that the text produced by the AGG backend -- it is
unsuitable for print. Now it is not too difficult to disable this,
Cairo has an API call: cairo_font_options_set_antialias to deal with
this.

While I could write a quick patch to always disable subpixel rendering
it would be something off a loss to those who either view their graphs
onscreen or export them for the web -- where using subpixel rendering
is now surprisingly common.

Is it worth looking into adding subpixel rendering as a configuration
option?

John Hunter wrote:

Hi all,

As some of you probably know I am working on the GSoC project to
externalise the Mathtex engine from Matplotlib. Today I have been
toying around with the renderer using various backends.

One of the interesting things that I discovered was that the Cairo
backend was making use of subpixel rendering. (Or 'ClearType' as
Microsoft call it.) This is not surprising -- by default Cairo will
respect a users fontconfig settings when rendering text. Since I have
subpixel rendering enabled all text rendered by Cairo is subpixel
rendered.

While this is fantastic for on screen text -- being significantly more
pleasing to look at that the text produced by the AGG backend -- it is
unsuitable for print. Now it is not too difficult to disable this,
Cairo has an API call: cairo_font_options_set_antialias to deal with
this.

While I could write a quick patch to always disable subpixel rendering
it would be something off a loss to those who either view their graphs
onscreen or export them for the web -- where using subpixel rendering
is now surprisingly common.

Is it worth looking into adding subpixel rendering as a configuration
option?

The matplotlib.lines.Line2D objects has an antialiased property -- we
could add the same property to matplotlib.text.Text to turn on/off
subpixel rendering (which could also be supported as an rc param)

I haven't poked around, so this may be a stupid question, but: for cairo, can subpixel rendering simply be left on for screen display and automatically turned off when writing to a file via savefig? If this can be done, it seems like a better solution than requiring to the user to turn the parameter on and off manually, depending on whether show() or savefig() is being called.

Eric

···

On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <freddie@...718...> wrote:

JDH

John Hunter wrote:
<snip>

The matplotlib.lines.Line2D objects has an antialiased property -- we
could add the same property to matplotlib.text.Text to turn on/off
subpixel rendering (which could also be supported as an rc param)

JDH

What are the supported combinations of subpixel rendering and antialiasing? Are they mutually exclusive? If Cairo supports both at the same time, I don't think it would be a good idea to enable subpixel rendering using a property called "antialiased".

Gary R.

I'm with Eric on this -- let's try to do the right thing without requiring any user intervention. I actually can't think of a use case that would require a subpixel argument on text... am I missing something?

Mike

Eric Firing wrote:

···

John Hunter wrote:
  

On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <freddie@...718...> wrote:
    

Hi all,

As some of you probably know I am working on the GSoC project to
externalise the Mathtex engine from Matplotlib. Today I have been
toying around with the renderer using various backends.

One of the interesting things that I discovered was that the Cairo
backend was making use of subpixel rendering. (Or 'ClearType' as
Microsoft call it.) This is not surprising -- by default Cairo will
respect a users fontconfig settings when rendering text. Since I have
subpixel rendering enabled all text rendered by Cairo is subpixel
rendered.

While this is fantastic for on screen text -- being significantly more
pleasing to look at that the text produced by the AGG backend -- it is
unsuitable for print. Now it is not too difficult to disable this,
Cairo has an API call: cairo_font_options_set_antialias to deal with
this.

While I could write a quick patch to always disable subpixel rendering
it would be something off a loss to those who either view their graphs
onscreen or export them for the web -- where using subpixel rendering
is now surprisingly common.

Is it worth looking into adding subpixel rendering as a configuration
option?
      

The matplotlib.lines.Line2D objects has an antialiased property -- we
could add the same property to matplotlib.text.Text to turn on/off
subpixel rendering (which could also be supported as an rc param)
    
I haven't poked around, so this may be a stupid question, but: for cairo, can subpixel rendering simply be left on for screen display and automatically turned off when writing to a file via savefig? If this can be done, it seems like a better solution than requiring to the user to turn the parameter on and off manually, depending on whether show() or savefig() is being called.

Eric

JDH
    
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,

I'm with Eric on this -- let's try to do the right thing without
requiring any user intervention. I actually can't think of a use case
that would require a subpixel argument on text... am I missing something?

Cairo has an image backend, which is usually used for both on-screen rendering and which also supports saving to a file. When displaying on-screen the default is most probably fine -- Cairo gets its subpixel rendering settings from the OS (fontconfig on Linux) so all is well.

However, when saving to a file, depending on its intended use one may either want to enable/disable subpixel antialiasing/rendering. If it is intended for print you probably want to disable it, however, for web graphics subpixel rendering is extremely common.

Furthermore Cairo also has provisions for subpixel antialiasing for line art. (So the same techniques which are applied to text are also applied to polygons, curves &c.) While none of the backends currently make use of it, it is quite likely that in the future the image backend will support it. Therefore a general subpixel antialiasing setting might be a better bet.

I would therefore suggest having two options: one for when printing and another for displaying on screen. The default for printing/saving should probably be off, while the displaying should be got from the system.

Regards, Freddie.

···

On 11 May 2009, at 12:43, Michael Droettboom wrote:

That plan makes sense to me.

The argument I was trying to make was against subpixel rendering as a property of each Text object in matplotlib -- but later realised that's not really applicable to what you're doing with the external math tool anyway.

Cheers,
Mike

Freddie Witherden wrote:

···

Hi all,

On 11 May 2009, at 12:43, Michael Droettboom wrote:
  

I'm with Eric on this -- let's try to do the right thing without
requiring any user intervention. I actually can't think of a use case
that would require a subpixel argument on text... am I missing something?
    
Cairo has an image backend, which is usually used for both on-screen rendering and which also supports saving to a file. When displaying on- screen the default is most probably fine -- Cairo gets its subpixel rendering settings from the OS (fontconfig on Linux) so all is well.

However, when saving to a file, depending on its intended use one may either want to enable/disable subpixel antialiasing/rendering. If it is intended for print you probably want to disable it, however, for web graphics subpixel rendering is extremely common.

Furthermore Cairo also has provisions for subpixel antialiasing for line art. (So the same techniques which are applied to text are also applied to polygons, curves &c.) While none of the backends currently make use of it, it is quite likely that in the future the image backend will support it. Therefore a general subpixel antialiasing setting might be a better bet.

I would therefore suggest having two options: one for when printing and another for displaying on screen. The default for printing/saving should probably be off, while the displaying should be got from the system.

Regards, Freddie.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Jouni K. Seppänen wrote:

http://en.wikipedia.org/wiki/ClearType

Reading that web page, I'm not convinced MS made the right decision here -- on my monitor (which is a ViewSonic LCD, probably pretty standard), I'm not sure the ClearType examples really look any better, and they certainly could look worse on other displays.

Also from that page:

"""
Additionally, when images are prepared to be display-independent (that is, when they are prepared for distribution, and not just for display on the computer with which they were prepared), ClearType should be turned off if rendered text is part of the image. For example, screenshots should always be prepared with ClearType turned off. Image-editing programs such as Adobe Photoshop or Corel Paint Shop Pro bypass ClearType when rendering text directly, for precisely this reason.
"""

I say just turn it off everywhere, it's the safer bet.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

Hi,

Jouni K. Seppänen wrote:

http://en.wikipedia.org/wiki/ClearType

Reading that web page, I'm not convinced MS made the right decision here
-- on my monitor (which is a ViewSonic LCD, probably pretty standard),I'm not sure the ClearType examples really look any better, and they
certainly could look worse on other displays.

I -- personally -- am not a fan of Microsoft's implementation of subpixel rendering either. I feel that it applies far too heavy hinting to glyphs in order to force them into the pixel grid. However, studies have shown that people like what they're used to. (E.g., when Safari 3 was released for Windows Apple ported their own font rendering engine -- which uses almost no hinting -- provoking many complains from Windows users, who had gotten used to their well hinted glyphs.)

I say just turn it off everywhere, it's the safer bet.

If adding a configuration option is not viable (complexity of doing so, potentially confusion to users, not enough scope, &c) then yes -- disabling it is the safest option. But for those who do have it enabled for their desktop it would be good if Matplotlib was able to respect that for onscreen rendering.

Regards, Freddie.

···

On 11 May 2009, at 19:56, Christopher Barker wrote:

Freddie Witherden wrote:

I -- personally -- am not a fan of Microsoft's implementation of subpixel rendering either. I feel that it applies far too heavy hinting to glyphs in order to force them into the pixel grid.

actually, that's a separate issue. the one in that wiki page is taking advantage of the fact that a single rgb "pixel" is really three pixels, one of each color, and, if you now how those are arranged (and apparently they are mostly arranged the same on LCD monitors), you can turn on more or less of a color to get a third of the pixel.

studies have shown that people like what they're used to.

yup. Though I think that MPL is not rendering big blocks of text, the there is less "used to" in this case.

Safari 3 was released for Windows Apple ported their own font rendering engine -- which uses almost no hinting -- provoking many complains from Windows users, who had gotten used to their well hinted glyphs.)

And this is the trick that MS uses to shift glyphs right or left to line vertical lines up with the pixel grid. This is nice commentary on a bunch of this:

http://www.antigrain.com/research/font_rasterization/

I wonder how the MS tricks do for math -- I'd expect kind of a mess.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...236...

That could be because you have an unusual RGB subpixel layout, or because the implementation of subpixel rendering on your system yields color fringes. I don’t have these problems on my ubuntu or gentoo systems, and text looks much better on my LCDs when I have subpixel rendering enabled. I think the users settings should be respected, if possible.

Darren

···

On Mon, May 11, 2009 at 2:56 PM, Christopher Barker <Chris.Barker@…236…> wrote:

Jouni K. Seppänen wrote:

http://en.wikipedia.org/wiki/ClearType

Reading that web page, I’m not convinced MS made the right decision here

– on my monitor (which is a ViewSonic LCD, probably pretty standard),

I’m not sure the ClearType examples really look any better, and they

certainly could look worse on other displays.