[cairo] Subpixel Positioning w/FreeType

[Freddie Witherden]

Hi all,

I am wondering about any current or future proposals for supporting
subpixel positioning with FreeType. Subpixel positioning -- not to be
confused with subpixel rendering/anti-aliasing -- allows for more
accurate glyph positioning.

Much like subpixel rendering, subpixel positioning takes advantage of
the fact that LCD screens are made up of three subpixels in a specific
order. This order is usually RGB. The predictable subpixel order
allows for three times the horizontal resolution. The same technique
can be applied to glyph positions. Instead of having to start on a
pixel boundary glyphs are instead able to start on a subpixel
boundary. This allows for spacing accurate to 1/3 of a pixel in most
cases.

It is my understanding (from looking over the source) that Cairo does
not currently support subpixel positing under FreeType. Further, I
also understand that the FreeType code has been recently re-written
(there was a note on the 1.10 roadmap) to take advantage of the
subpixel filtering API exported by FreeType.

I believe that basic, 1/3 of a pixel, subpixel positing could be
implemented in Cairo without a huge amount of work. It would of course
only be applicable when subpixel rendering is enabled. Since Cairo and
Pango both already use fractional co-ordinates this should not break
backwards compatibility.

Both Quartz (OS X) and ClearType (Windows) support this already.

Polemically yours, Freddie.

[Robert O'Callahan]

Post by Freddie Witherden
I believe that basic, 1/3 of a pixel, subpixel positing could be
implemented in Cairo without a huge amount of work. It would of course
only be applicable when subpixel rendering is enabled. Since Cairo and
Pango both already use fractional co-ordinates this should not break
backwards compatibility.
Both Quartz (OS X) and ClearType (Windows) support this already.

You mean the Windows WPF ClearType rasterizer? AFAIK GDI Cleartype does not
support this.

Rob

[Rob Arnold]

Post by Robert O'Callahan

Post by Freddie Witherden
I believe that basic, 1/3 of a pixel, subpixel positing could be
implemented in Cairo without a huge amount of work. It would of course
only be applicable when subpixel rendering is enabled. Since Cairo and
Pango both already use fractional co-ordinates this should not break
backwards compatibility.
Both Quartz (OS X) and ClearType (Windows) support this already.

You mean the Windows WPF ClearType rasterizer? AFAIK GDI Cleartype does not
support this.

I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it uses 1/3
for sub pixel positioning. Before picking a fraction, it would be good to
find out what the other rasterizers have chosen for their pixel subdivision.

-Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20091006/2cbba560/attachment.htm

[James Cloos]

Rob> I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it
Rob> uses 1/3 for sub pixel positioning. Before picking a fraction, it
Rob> would be good to find out what the other rasterizers have chosen
Rob> for their pixel subdivision.

The note about Cleartype recently posted, IIRC, to the opentype list
says that it uses 4 bits of fraction.

-JimC

[Bill Spitzak]

May want to investigate how many subpixel positions are needed so that a
diagonal line of text looks straight. I think this may have stronger
requirements than a horizontal line of text. Try using Cairo to draw
small tilted anti-aliased rectangles and see what rounding factor for
the position you can get away with before a row of them does not look
straight.

Also the number of positions needed probably goes down as the font size
gets bigger.

The 4 bits may only be some internal data storage and ClearType may be
using fewer images, ie some of the 16 possible sub-positions map to the
same glyph. 4 is the smallest power of 2 that will give 3 positions
anything close to equal weight and may explain why it was chosen.

Post by James Cloos
Rob> I'm pretty sure it's new in WPF/DirectWrite. But I'm not sure it
Rob> uses 1/3 for sub pixel positioning. Before picking a fraction, it
Rob> would be good to find out what the other rasterizers have chosen
Rob> for their pixel subdivision.
The note about Cleartype recently posted, IIRC, to the opentype list
says that it uses 4 bits of fraction.
-JimC

[Freddie Witherden]

Post by Bill Spitzak
The 4 bits may only be some internal data storage and ClearType may be
using fewer images, ie some of the 16 possible sub-positions map to the
same glyph. 4 is the smallest power of 2 that will give 3 positions
anything close to equal weight and may explain why it was chosen.

It is my understanding that three positions of subpixel precision were chosen
as most LCD screens are made up of three vertical subpixels. While it does
seem theoretically possible to have more than that by adjusting the intensity
of the pixels this is likely to cause blur glyphs further.

Regards, Freddie.

[Jonathan Morton]

Post by Freddie Witherden

Post by Bill Spitzak
The 4 bits may only be some internal data storage and ClearType may be
using fewer images, ie some of the 16 possible sub-positions map to the
same glyph. 4 is the smallest power of 2 that will give 3 positions
anything close to equal weight and may explain why it was chosen.

It is my understanding that three positions of subpixel precision were chosen
as most LCD screens are made up of three vertical subpixels. While it does
seem theoretically possible to have more than that by adjusting the intensity
of the pixels this is likely to cause blur glyphs further.

As long ago as 1994, Acorn's RiscOS supported subpixel positioning of
antialiased text. This was in the absence of any LCD-specific reasons
for doing so, as ClearType had not yet been invented. I believe it only
supported half-pixels, or maybe quarter-pixels on each axis, but that
was more due to memory constraints than anything else.

It *did* improve the appearance of text, whenever the layout was not
explicitly bound to the screen physics - and this was on a mid-1990s 15"
CRT, on a machine rarely seen outside the UK. The colour palettes were
heavily weighted towards grey-levels to support it.

With a 30MHz ARM CPU, it obviously had to pre-render and cache the
glyphs to get interactive performance. It would have been unthinkable
on a similar 486 - at the time, an ARM was considered very fast.

By 1995, Apple also supported subpixel positioning of non-antialiased
text. There was a preference option for it in ClarisWorks 3. I always
turned it on and saw the difference. I don't know how many bits were
involved, but I don't remember it causing any performance trouble on a
68K-based PowerBook.

ISTR seeing an article on ClearType which demonstrated that more than
even 4 bits of subpixel positioning could be visible even on horizontal
text. The demonstration involved sub-point increments in font size.

The "blurry" argument is fallacious. Windows users are just too used to
aggressive hinting, which distorts the glyph shapes in the name of
optical sharpness. RiscOS didn't use hinting, and it looked wonderful
even at very small sizes.

[Ian Britten]

Post by Freddie Witherden
I am wondering about any current or future proposals for supporting
subpixel positioning with FreeType. Subpixel positioning -- not to be
confused with subpixel rendering/anti-aliasing -- allows for more
accurate glyph positioning.

FYI - Dunno if you've seen this before, but here is an (older)
post from FT, which I think is covering some of this (And more).
It also has some nice screenshot examples.
http://lists.gnu.org/archive/html/freetype/2007-07/msg00007.html

Hope it helps! (Apologies if it's not relevant)
Ian

[Behdad Esfahbod]

Hi Freddie,

Adding subpixel positioning support is indeed in my longterm plan for cairo. I
have discussed it before on the list. But I'm by no way close to making a
firm commitment to a deadline right now.

Cheers,
behdad

Post by Freddie Witherden
Hi all,
I am wondering about any current or future proposals for supporting
subpixel positioning with FreeType. Subpixel positioning -- not to be
confused with subpixel rendering/anti-aliasing -- allows for more
accurate glyph positioning.
Much like subpixel rendering, subpixel positioning takes advantage of
the fact that LCD screens are made up of three subpixels in a specific
order. This order is usually RGB. The predictable subpixel order
allows for three times the horizontal resolution. The same technique
can be applied to glyph positions. Instead of having to start on a
pixel boundary glyphs are instead able to start on a subpixel
boundary. This allows for spacing accurate to 1/3 of a pixel in most
cases.
It is my understanding (from looking over the source) that Cairo does
not currently support subpixel positing under FreeType. Further, I
also understand that the FreeType code has been recently re-written
(there was a note on the 1.10 roadmap) to take advantage of the
subpixel filtering API exported by FreeType.
I believe that basic, 1/3 of a pixel, subpixel positing could be
implemented in Cairo without a huge amount of work. It would of course
only be applicable when subpixel rendering is enabled. Since Cairo and
Pango both already use fractional co-ordinates this should not break
backwards compatibility.
Both Quartz (OS X) and ClearType (Windows) support this already.
Polemically yours, Freddie.
_______________________________________________
cairo mailing list
cairo at cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo