"And TTE2 library, used for text rendering is in very-alpha version (and it's very slow because of that). But sometime in the future it might be as fast as ibrowse currently."

The middle part of the s is very visible here, I assume you need to adjust your monitor.

I know some people absolutely want all features of their characters to be black. I don't understand why these people would want to use antialiased fonts in the first place. Antialiasing is for making characters appear in their intended shapes, not for making sure presumably "important" features are pitch black. Many people (including me) find text easier to read when characters have the shapes that have been carefully crafted by typographers during centuries, rather than some crude blocky approximation, no matter how black it is.

Quote:

And here it looks something like:
/\

\/

Quote:

Feel free to instruct me on how to adjust my CRT monitor and the LCD monitor in my laptop.

Quote:

And I know some who just want the lines in the font to be visible.

Quote:

Guess why I'm hassling Marcik to implement support for bitmap fonts? They're just so much crisper and easier to read.

Quote:

No, antialiasing will do no such thing (unless perhaps if you're blind. Or are you trying to say that an M is supposed to look like two solid vertical lines connected by two very faintly drawn diagonal lines? The two diagonal lines look MUCH fainter than the vertical lines.

Quote:

A line is not an important feature? Right...

Quote:

... carefully crafted then blurred into unreadability, right.

Quote:

Rather a crude, blocky approximation than blurry on purpose (especially when blurry only applies to some lines)

Yes, the diagonal parts of 'M's are regularly more faint than the vertical ones. And for 's', yes, the mid part may be thinner (or thicker) than the upper and lower parts, depending on font design. Check the rgb values of the midsection of the 's' if you don't believe that it is quite visible here, btw.
There's a typographic term for the line direction which is thickest, but I can't recall it at the moment.

In other words, typographic characters are not to be seen as mere 'lines', as if drawn by a child with a crayon. They are complex two dimensional shapes, where some parts are more apparent (thicker, or 'blacker' to use a typographic term..) than other parts. If some part stands out less, that does not make the character less readable, in fact there's good reason to believe it was designed this way in order to make a character more unique and thus easier to spot. It's just like people writing in all caps doesn't make things easier to read just because characters are bigger. Subtleness can be much more efficient.

And btw: it is technically wrong to call it 'blurring'. Blurring is when you reduce the amount of information in an original image by mixing adjacent colour fields. In this case, there is *more* information than in a mere b/w image of the same resolution, because each pixel is carefully shaded according to how much black is actually present in that area of the character.


[ Edited by merko on 2006/8/26 0:55 ]

Bigfoot is right, I believe it should be rendered better.
M looks like a weird |v| and the s is ghosted.

[ Edited by tarbos on 2006/8/26 1:43 ]

@merko&bigfoot

The primary reason for the text looking so bad is probably that tte2 by now is based on a rather old version of freetype, updating it should improve the rendering .. secondary reason is bad hinting instructions in the font itself, using another font might drastically improve the quality of the antialiasing...


- CISC

@ CISC, bigfoot, merko

1. TTEngine2 uses FreeType 2.1.9. Will be updated to 2.2.1 in the near future.

2. Current output module of TTE2 is AA + gamma correction. Wrong gamma setting can degrade quality. Gamma can be adjusted by user to fit his display device and personal taste.

3. Mono output module is planned. As TTE2 has TrueType bytecode interpreter turned on by default, there is no need to support bitmaps in KHTML IMHO. And BTW how do you imagine for example CSS support with bitmaps? Bitmap for every size from 8 to 24?

4. Subpixel output module is planned too. It will have user-adjustable filter.

5. There is an adjustable range of switching antialias off for given font sizes (like in KDE for example). Every font face can have its own settings (so the range may differ for regular and bold face for example).

Quote:
Sure, I'm able to see there's a little bit of blur in the middle, especially when looking at the zoom. When just reading, though, it's not visible and it's damn annoying.

Quote:
No, they're apparently not meant to be seen at all, eh? :)

Quote:
Thinner != invisible. A thin line is OK, but I'm not even sure if I'm gonna agree there's more than 2 lines in the M.

Quote:
Thinner, maybe. Invisible? No. Subtleness is not the same as invisibility

Quote:
OK, if you say so.

Quote:
So exactly a kind of blurring... If the lower part of a square is black, you mix the upper (white) and lower (black) part of the square to form a gray square. If that is not blurring, I don't know what it is.

And no matter how you look at it, a pixel based representation of a truetype font is always gonna have less "information" than the original, unless you happen to find a square font which at a specific size has edges which exactly align with pixel boundaries. The question is then how much blurring of the original font you can allow before it becomes unreadable. For me that line is well crossed on that screenshot.

Quote:
Err, what?!

There's nothing which beats a good handdrawn font at small sizes. Especially not truetype approximations, which often look just like the antialiased variants, just more clumpy.

Quote:
Use the damn nearest size?

Quote:
Is there a feature to make bitmap fonts available? :)


[edit]Oops, forgot about Targhan's lame religious fanatic filter.[/edit]

[ Edited by bigfoot on 2006/8/26 9:18 ]

@ bigfoot

Amiga bitmap fonts support in TTE2 can be done, but is low priority. About direct use of bitmapped fonts in KHTML talk with Marcik.

Using nearest sizes for missing ones will give you horrible results with pages, which layouts depend on text height.

Quote:
I don't see the point either. But you claimed anything but TTE was not necessary, but bitmap font support IS necessary.

Quote:
That's what I'm doing :)

Quote:
Sucks to be that layout, then. There are plenty of reasons why you might not use the font dictated by the website, especially when said website is designed someone who thinks that 6 pixel high antialiased fonts is the best thing ever.

Speaking of which, I hope Marcik implements some option to set minimum allowed font size.

Quote:
For these kind of pages, you just use the zoom function that any moderm browser has...

@Marcik: what about zooming ? :) Is there anything like this in KHTML ? Or should it be added by hand ? I know Opera, IE7 and FireFox (Gekko) all have it...

Leo.

> So exactly a kind of blurring... If the lower part of a > square is black, you mix the upper (white) and lower > (black) part of the square to form a gray square. If
> that is not blurring, I don't know what it is.

It's shading. You know, when the left part of a wall in Quake is darker than the right part, that's not because it is 'blurred'.

> And no matter how you look at it, a pixel based
> representation of a truetype font is always gonna
> have less "information" than the original,

Of course. But the AA representation will have much more information than the black/white representation. And since there is no "original" bitmap anyway, there is nothing to blur.

> unless you happen to find a square font which at a
> specific size has edges which exactly align with pixel > boundaries. The question is then how much blurring > of the original font you can allow before it becomes > unreadable.

I disagree. The question is how small you can make the representation until the information contained in the shaded pixels is not enough to make the eye recognise the intended shape. Shading makes the shape more defined, blurring would make it less defined. But that would make no sense anyway unless you're some ANR special effect or something.

@bigfoot
Quote:
It's already there.

@Leo
Quote:
And that is also already there

I tried looking at the pages in the screenshots with both IE (crisp fonts) and Safari (antialiased fonts).. And both look very good. Personally I prefer non-AA since I think it has better readability, but it really comes down to a matter of taste. I agree that the lines looks bad in the shots, but as discussed a new font or an updated renderer will solve that problem..

If bitmap fonts would mean using the closes matching size, that would be fine by me, most pages are built to cope with changed font size.

The best thing would be if it was user-selectable wether you want AA fonts or not. Personally, I would vote for non AA.

will Sputnik be able to print?

Hi all,

Yes, will Sputnik be able to print? and in color? as this IMHO would be an important feature.

Looking forward to see this app out for MorphOS. Seems to be really GREAT.

Regards

Christoph

Quote:

That's because a lightmap has been applied to it. Are you applying lightmaps to fonts now to imitate the fact that a desk lamp will not light each part of a paper equally much? :)

But does applying a lightmap "add information"? Sure, it does. Does it make the texture any easier to see, though? Nope, it doesn't. It's kinda the same with AA fonts.

Quote:

And "more information" automatically makes it easier to read?

And of course it's blurred. You're scaling someting with infinite resolution to a finite resolution and blurring the edges while you're at it.

Quote:

Without AA, the shape is clearly defined. You can see each line and the space between a line and the next. With AA, you might end up with a block where almost every pixel is coloured. Noticing the lines and spaces inbetween them becomes much harder that way, as nothing is really all that clear anymore.

Quote:

There's some code in KHTML for printing support, but i never looked into that to see if/how is it working. As it also has rather low piority so don't hold your breath for printing support in first betas

You thought to all. Good job

Quote:
I (partially) agree with bigfoot here. Generally speaking, bitmap fonts do look better at smaller sizes (where width of lines are generally around 1, more or less)

BUT obviously a properly antialiased font would still look better. Yes, even at small sizes. But the problem is, any automatic antialiasing usually makes things worse (of course non-aa scaled font will usually look bad aswell). Making it look good (as in "better than monochrome bitmap") would likely mean antialiasing it (carefully) by hand and take care to not overdo it.

But as was pointed out already, results could also be significantly improved by using newer & better routines.

And about "having to do a bitmap font for every size 8-24": As was pointed out, the problem is JUST with the small fonts. Therefore, it's (imho) no use bothering with fonts >14 (or-so)

For me and most people using other then iso1 code page TTE is most nececery then bitmap font.

bigfoot wrote:
> But does applying a lightmap "add information"?
> Sure, it does. Does it make the texture any easier
> to see, though? Nope, it doesn't. It's kinda the
> same with AA fonts.

The shading doesn't make the texture easier to see, it makes the *shape* easier to see. Same with AA fonts.

> You're scaling someting with infinite resolution to a
> finite resolution and blurring the edges while you're
> at it.

We're not comparing the one with infinite resolution to an AA font though, we're comparing a crude blocky b/w font to a rendering that uses shading to provide as much shape information as possible within the given resolution.

> Without AA, the shape is clearly defined. You can
> see each line and the space between a line and the
> next.

Typographic characters aren't a set of 'lines' though. You're still thinking in terms of child-writing-with-crayon.

> With AA, you might end up with a block where
> almost every pixel is coloured.

Certainly. What is wrong with that?

> Noticing the lines and spaces inbetween them
> becomes much harder that way, as nothing is really
> all that clear anymore.

Why should you want to notice 'lines'? I really doubt you read by checking for 'lines'. Rather, the brain stores images of what characters typically look like, and then matches the visual input to the database. Because AA characters are closer to what fonts usually look like, they are easier to read.

Hm, KHTML gets better and better (Wikipedia looks very nice), but I think it still needs some improvements... What do you working on now, marcik? Are the forms already working?

How is javascript support going? Is it complete now? (For example are complex pages like gmail working now?)

Is the release date (end of September/October) still actual? :)