Re: Why not perfect alignment?

dorayme wrote:
> Can't think of any good reason for the text not to be as crisp for both
> *visible* paragraphs at:
>
> <http://dorayme.netweaver.com.au/alt/indexAlignment.html>
>
> Here is an even purer case:
>
> <http://dorayme.netweaver.com.au/alt/indexAlignment2.html>
>
> Notice that the background is not set (the phenomena is dependent on the
> transparency of the backgrounds to the elements).
>
> It is mildly surprising that blurring occurs, that there is not perfect
> registration.
>
> The only theory that comes to my mind does not *quite* satisfy me:
> elements are on layers in a fluid which has a refractive index different
> to a vacuum.

The same thing happens if you style all three paragraphs with position:
absolute; left: 100px; top: 100px; (using 100px just to get it out of
the corner to see if that changes anything).

Harlan Messinger

In article <>,
Harlan Messinger <> wrote:

> dorayme wrote:
> > Can't think of any good reason for the text not to be as crisp for both
> > *visible* paragraphs at:
> >
> > <http://dorayme.netweaver.com.au/alt/indexAlignment.html>
> >
> > Here is an even purer case:
> >
> > <http://dorayme.netweaver.com.au/alt/indexAlignment2.html>
> >
> > Notice that the background is not set (the phenomena is dependent on the
> > transparency of the backgrounds to the elements).
> >
> > It is mildly surprising that blurring occurs, that there is not perfect
> > registration.
> >
> > The only theory that comes to my mind does not *quite* satisfy me:
> > elements are on layers in a fluid which has a refractive index different
> > to a vacuum.
>
> The same thing happens if you style all three paragraphs with position:
> absolute; left: 100px; top: 100px; (using 100px just to get it out of
> the corner to see if that changes anything).

OK. I guess the relevant bit of the browser-supplied (default)
stylesheet or even the implementation of whatever is the top left (be it
0 and O or 100px and 100px) applies to all four absolutely positioned
divs in my second URL, so this is not too surprising.

Queer business though! There is something else: on my machine and Mac
browsers, the black gets blacker, no matter if it is specified #000 for
each paragraph when layering one paragraph over another. Up to a point
though: just one makes for a black enough but *just* slightly grey text.
It looks blacker the bigger one sets the text. But at small text size,
this not-deepest of blacks really quickly goes total black after just
another spray of text via absolute positioning.

Both aspects of this phenomena (the blackness and the interference
jaggies) depends, as I said, on leaving the default transparency for the
elements. But it is curious to reflect that somehow the transparency
acts through the text paint itself.

Here is one theory that suggests itself from Upsdell's observation: I am
seeing an attempt by my OS to do smoothy things with the edges of the
type but it gets confused by doing it in one spot. Or does it do it to
two sets of identical text but somehow the browser itself gets confused
when summing the two sets?

--
dorayme

dorayme

In article <1j853jh.sfvlrn1sdzk5yN%>,
(j) wrote:
....
> Here's a theory. Text at small sizes isn't pure black due to Mac OSX
> font smoothing. Instead the pixels forming the characters have various
> degrees of transparency. When you overlay two identical characters, a
> semi-transparent pixel will become darker (like overlaying two
> semi-transparent layers in photoshop). The lighter edge pixels become
> darker and make the font look jaggy.
>
....

Yes, this is an intelligent idea. You are right that the grey comes from
small text sizes and we can sort of see why this is. Text characters are
clever little artifacts in computers and are defined by sets of
mathematical rules. When you add the factor of aliasing to fit the
technology of discrete pixel screens, at small sizes there is not much
left for the deep black bits, a lot of pixels are pressed into smoothing
services. Hence the slightly greyer look.

But there are still quite a few questions. I will come back on this very
shortly when I have more time, probably tomorrow, so don't go too far
away <g>

--
dorayme

dorayme

In article <doraymeRidThis->,
dorayme <> wrote:

> In article <1j853jh.sfvlrn1sdzk5yN%>,
> (j) wrote:
> ...
> > Here's a theory. Text at small sizes isn't pure black due to Mac OSX
> > font smoothing. Instead the pixels forming the characters have various
> > degrees of transparency. When you overlay two identical characters, a
> > semi-transparent pixel will become darker (like overlaying two
> > semi-transparent layers in photoshop). The lighter edge pixels become
> > darker and make the font look jaggy.
> >
> ...
>
> Yes, this is an intelligent idea. You are right that the grey comes from
> small text sizes and we can sort of see why this is. Text characters are
> clever little artifacts in computers and are defined by sets of
> mathematical rules. When you add the factor of aliasing to fit the
> technology of discrete pixel screens, at small sizes there is not much
> left for the deep black bits, a lot of pixels are pressed into smoothing
> services. Hence the slightly greyer look.
>

In an image editor like Fireworks or PS or even Illustrator, you can
produce a black and set the layer opacity to less than 100% and have
multilple <100% opacity *layers*. This deepens the black. We can
understand why this would be wanted. How quite it is achieved is a very
technical question, it is not like spray painting which keeps filling in
bits that are missed. In spray painting this is possible because there
is randomness. But there is no randomness in the image editor case or
the HTML case. In the image editor case, they simply code for it look
blacker! It is to mimic painting and glass layers and things in the real
world. If this happens in the webpage context as well, then that would
explain the phenomena.

And indeed, it does seem to fit the case of text. But it does not fit
the case of a transparent gif of a letter, such inline elements happily
pile up, laying *exactly* on top of each other. There is no summing or
any such interaction between the pixels on the 'indexed layers'.

Interesting things, fonts! Given what we have observed, it looks like it
is not something that anything of the CSS 2.1 or HTML standards has much
to say about. It seems an interaction between platforms, platform
options or preferences and positioning. I leave the matter for now with
less niggles than I had before. <g>

--
dorayme

dorayme

In article <1j88xln.wtfbvd1lhlunuN%>,
(j) wrote:

....

> What gets really confusing is how these semi-transparent overlaid
> colours are calculated. And whether the same process is used in browsers
> as in graphics programs.
>
....
>
> ...after seeing this video I no longer trust my eyes:
>
> http://tinyurl.com/ydlhfb2

I have not examined the CSS 3 opacity facilities but I imagine that
there are complex algorithms employed to implement those facilities with
perhaps many similarities to image editor ones. In the case we were
discussing, not employing any opacity rules, it seems that fonts alone
get this odd interaction... anyway, ...

The thing that I found particularly interesting in the last URL, thanks
for giving it, was the suggestion of sensing via sound for blind people.
I think this is quite fascinating!

--
dorayme

dorayme

"dorayme" <> wrote in message
news:doraymeRidThis-...
> In article <1j88xln.wtfbvd1lhlunuN%>,
> (j) wrote:
>
> ...
>
>> What gets really confusing is how these semi-transparent overlaid
>> colours are calculated. And whether the same process is used in browsers
>> as in graphics programs.
>
> I have not examined the CSS 3 opacity facilities but I imagine that
> there are complex algorithms employed to implement those facilities with
> perhaps many similarities to image editor ones. In the case we were
> discussing, not employing any opacity rules, it seems that fonts alone
> get this odd interaction... anyway, ...

This caught my interest so I had a bit of a play around:

http://nrkn.com/opacityExperiment

If you click through the links and it doesn't look like it's changing then
the overlaid colours are being calculated the same.

Looks like the browsers agree with not just with Photoshop in how to
calculate the overlaid colours, but with each other too.

Well, Firefox/Safari/Chrome/Opera. IE8 doesn't support any of the CSS3 that
I used for the last 3 variants.

The opacity relationship is:

One layer at 75% = 75%
Two layers overlaid @ 75% ea = 94%
Three layers overlaid @ 75% ea = 98%

One layer at 50% = 50%
Two layers overlaid @ 50% ea = 75%
Three layers overlaid @ 50% ea = 88%

One layer at 25% = 25%
Two layers overlaid @ 25% ea = 44%
Three layers overlaid @ 25% ea = 58%

This is classic alpha compositing, nothing too complex to implement, which
is why it looks the same everywhere:

new alpha = source alpha + ( 1 - source alpha ) * destination alpha

The colours are therefore likely calculated in a similar fashion

Nik Coughlin

In article <hc8i47$o4$>,
"Nik Coughlin" <> wrote:

> "dorayme" <> wrote in message
> news:doraymeRidThis-...
> > In article <1j88xln.wtfbvd1lhlunuN%>,
> > (j) wrote:
> >
> > ...
> >
> >> What gets really confusing is how these semi-transparent overlaid
> >> colours are calculated. And whether the same process is used in browsers
> >> as in graphics programs.
> >
> > I have not examined the CSS 3 opacity facilities but I imagine that
> > there are complex algorithms employed to implement those facilities with
> > perhaps many similarities to image editor ones. In the case we were
> > discussing, not employing any opacity rules, it seems that fonts alone
> > get this odd interaction... anyway, ...
>
> This caught my interest so I had a bit of a play around:
>
> http://nrkn.com/opacityExperiment
>
> If you click through the links and it doesn't look like it's changing then
> the overlaid colours are being calculated the same.
>
....
> ...classic alpha compositing, nothing too complex to implement, which
> is why it looks the same everywhere:
>
>
> The colours are therefore likely calculated in a similar fashion

An interesting exercise and a nice bit of work Nik! I guess it is not
too surprising that when it comes to conscious use of opacity in
browsers that the makers would have borrowed heavily from the
algorithmic resources developed in image software.

--
dorayme

dorayme

On Oct 25, 12:31*pm, j...@macunlimited.net (j) wrote:
> dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
> > Here is one theory that suggests itself from Upsdell's observation: I am
> > seeing an attempt by my OS to do smoothy things with the edges of the
> > type but it gets confused by doing it in one spot. Or does it do it to
> > two sets of identical text but somehow the browser itself gets confused
> > when summing the two sets?
>
> Here's a theory. Text at small sizes isn't pure black due to Mac OSX
> font smoothing. Instead the pixels forming the characters have various
> degrees of transparency. When you overlay two identical characters, a
> semi-transparent pixel will become darker (like overlaying two
> semi-transparent layers in photoshop). The lighter edge pixels become
> darker and make the font look jaggy.
>
> To see this more clearly (on a Mac), press Cmd-Opt-8 to switch on Zoom,
> then press Cmd-Opt-+ repeatedly to zoom in (you may need to alter the
> zoom settings in the Universal Access control panel).

<quote src="http://www.imagemagick.org/Usage/antialiasing/">Anti-
aliasing involves using a mix of colors and transparences to try and
smooth the 'stair case' or 'jaggies' effect of slanted lines and color
boundaries. If only two colors are available no anti-aliasing can NOT
happen! </quote>
Is that only true concerning ImageMagick?
Or anywhere?

Jan C. Faerber

On Nov 5, 10:40*pm, Ben C <spams...@spam.eggs> wrote:

> ><quote src="http://www.imagemagick.org/Usage/antialiasing/">Anti-
> > aliasing involves using a mix of colors and transparences to try and
> > smooth the 'stair case' or 'jaggies' effect of slanted lines and color
> > boundaries. *If only two colors are available no anti-aliasing can NOT
> > happen! </quote>
> > Is that only true concerning ImageMagick?
> > Or anywhere?
>
> Anywhere.

Oh - great!
Just the imagemagick manual is so huge that I will finish learning in
about 2021.
Just wanted to find a way to resize my pics from a digi cam.
But it should work.
I pressed 'Ctrl + D' at that page!

Jan C. Faerber