Blending Glyph Pixels???

For the kind of sub pixel positioning that PDF and Apple OS X uses,
how are overlapping glyph pixels blended together?

PeteOlcott wrote:
> For the kind of sub pixel positioning that PDF and Apple OS X uses,
> how are overlapping glyph pixels blended together?

(Loose thoughts, vaguely remembered from experimenting with FreeType

There aren't that many different options to do this nicely. Rendering
each glyph transparently, right after scan conversion, can (and will)
introduce artefacts if pixels overlap -- they will visibly be darker. A
straight blit, not using transparency, is a no-no -- especially with
italics or script fonts, but for almost all fonts, bounding boxes can
overlap a pixel.

I think the trick is to render as much glyphs as possible into a single
grayscale buffer, using OR to blend in pixels. If you gathered enough
material -- a word or an entire display line, possibly even with
multiple fonts -- you can blit the entire buffer onto the screen, using
any coloring, copy, or transparency effect you want.

ORing the glyphs directly onto the screen may or may not always work --
suddenly success depends on your background color. For example, white
characters on a black background (0xffffff over 0x000000) always works
100% correct; the other way around, you will never see anything appear.

[Jw]

"[Jongware]" <sorry@no.spam.net> wrote in message
news:48b56439$0$192$e4fe514c@news.xs4all.nl...
> PeteOlcott wrote:
>> For the kind of sub pixel positioning that PDF and Apple
>> OS X uses,
>> how are overlapping glyph pixels blended together?
>
> (Loose thoughts, vaguely remembered from experimenting
> with FreeType
>
> There aren't that many different options to do this
> nicely. Rendering each glyph transparently, right after
> scan conversion, can (and will) introduce artefacts if
> pixels overlap -- they will visibly be darker. A straight
> blit, not using transparency, is a no-no -- especially
> with italics or script fonts, but for almost all fonts,
> bounding boxes can overlap a pixel.
>
> I think the trick is to render as much glyphs as possible
> into a single grayscale buffer, using OR to blend in
> pixels. If you gathered enough material -- a word or an
> entire display line, possibly even with multiple fonts --
> you can blit the entire buffer onto the screen, using any
> coloring, copy, or transparency effect you want.
>
> ORing the glyphs directly onto the screen may or may not
> always work --
> suddenly success depends on your background color. For
> example, white characters on a black background (0xffffff
> over 0x000000) always works 100% correct; the other way
> around, you will never see anything appear.
>
> [Jw]

This is for PDF / Apple OS X / Microsoft ClearType where
black pixels are constructed from colors other than black so
that the 1/3 pixel positioning can make glyphs 300% sharper
on LCD monitors. I need to know exactly how these pixels are
combined together when they overlap such that the 1/3 pixel
positioning and anti-aliasing are optimally maintained.

"Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
news:Iamtk.13536$Fr1.5108@newsfe03.iad...
>
> "[Jongware]" <sorry@no.spam.net> wrote in message
> news:48b56439$0$192$e4fe514c@news.xs4all.nl...
>> PeteOlcott wrote:
>>> For the kind of sub pixel positioning that PDF and Apple OS X uses,
>>> how are overlapping glyph pixels blended together?
>>
>> (Loose thoughts, vaguely remembered from experimenting with FreeType
>>
>> There aren't that many different options to do this nicely. Rendering
>> each glyph transparently, right after scan conversion, can (and will)
>> introduce artefacts if pixels overlap -- they will visibly be darker. A
>> straight blit, not using transparency, is a no-no -- especially with
>> italics or script fonts, but for almost all fonts, bounding boxes can
>> overlap a pixel.
>>
>> I think the trick is to render as much glyphs as possible into a single
>> grayscale buffer, using OR to blend in pixels. If you gathered enough
>> material -- a word or an entire display line, possibly even with multiple
>> fonts -- you can blit the entire buffer onto the screen, using any
>> coloring, copy, or transparency effect you want.
>>
>> ORing the glyphs directly onto the screen may or may not always work --
>> suddenly success depends on your background color. For example, white
>> characters on a black background (0xffffff over 0x000000) always works
>> 100% correct; the other way around, you will never see anything appear.
>>
>> [Jw]
>
> This is for PDF / Apple OS X / Microsoft ClearType where black pixels are
> constructed from colors other than black so that the 1/3 pixel positioning
> can make glyphs 300% sharper on LCD monitors. I need to know exactly how
> these pixels are combined together when they overlap such that the 1/3
> pixel positioning and anti-aliasing are optimally maintained.
>

well, what you seem to be describing would be very specific to the type of
hardware being rendered on (if the HW does something different, it may look
worse).

basic idea I have:
the glyphs themselves are rendered at a higher resolution than the actual
display (say, 2x or 4x), one then make another image, slightly downsampled
(say to 1x or 2x) to reduce aliasing (this is for use of trilinear filtering
or similar).

then, when calculating the value of each final pixel, one takes into account
the relative positions of the compoments as slight spatial shifts when
interpolating the values (ie, one writes their own trilinear interpolator,
and slightly fudges the ST coords per-component).


if using GL, there are ways to do this as well, for example, using the color
mask and rendering the glyph as multiple layers, for each component slightly
adjusting the ST coords.


whether one draws all the text into a buffer, or draws each glyph on its
own, is a separate issue.

as for combining glyphs nicely, be sure that alpha is also
included/interpolated as well (the alpha blending being calculated
per-component using the ST values for that component).


or such...

The theory for this case is that the glyphs never actually overlap
each other. If you consider that to be true, you can always use the
add blending operator instead of the over blending operator of the
porter duff model and you'll be fine. Alternatively, you could also
use ligatures to define the glyph as it should look like without any
overlap. Ultimately however, most engines I have played with simply
use the over blending operator and most fonts that I have seen
actually do not overlap, so it's really a non-issue in most cases (if
not all).

Contrary to belief, most OS actually do not use sub-pixel
positioning. Mainly because you cannot cache subpixel masks. You
would effectively have to render the glyphs given their subpixel
positions, hint them and do the whole nine yard. It's just painfull
overall, so it's often skipped.



On Aug 26, 7:02*pm, PeteOlcott <PeteOlc...@gmail.com> wrote:
> For the kind of sub pixel positioning that PDF and Apple OS X uses,
> how are overlapping glyph pixels blended together?

"ti_chris" <tiChris08@gmail.com> wrote in message
news:261df4b9-d0dc-4a08-9c52-c8c2a018cf6c@r15g2000prh.googlegroups.com...
The theory for this case is that the glyphs never actually
overlap
each other. If you consider that to be true, you can always
use the
add blending operator instead of the over blending operator
of the
porter duff model and you'll be fine. Alternatively, you
could also
use ligatures to define the glyph as it should look like
without any
overlap. Ultimately however, most engines I have played
with simply
use the over blending operator and most fonts that I have
seen
actually do not overlap, so it's really a non-issue in most
cases (if
not all).

Contrary to belief, most OS actually do not use sub-pixel
positioning. Mainly because you cannot cache subpixel
masks. You
would effectively have to render the glyphs given their
subpixel
positions, hint them and do the whole nine yard. It's just
painfull
overall, so it's often skipped.

I have very carefully examined the pixel output of both PDF
and Apple font rendering and it is completely obvious that
these systems do use 1/3 pixel positioning because each
character glyph has exactly three distinct forms.
This explains the details quite well:
http://www.antigrain.com:80/research...ion/index.html

On Aug 26, 7:02 pm, PeteOlcott <PeteOlc...@gmail.com> wrote:
> For the kind of sub pixel positioning that PDF and Apple
> OS X uses,
> how are overlapping glyph pixels blended together?