Jump to content

SmoothText 1.1.8


WildBill

Recommended Posts


Wow, thanks for the votes of confidence. I don't have it run on startup, but that's because I'm constantly working on it and a crash bug in the middle of making a new version would be bad for me (though I could have the previous version run on startup, I suppose).

I know about the menu issue, but haven't had time to track it down yet. Menus are definitely tricky.

Version 0.6.8 is up, and it fixes some rendering problems as well as runs faster. On my Pentium 4, page-scrolling through a document in Word 2000 is about 25% faster (about 8 seconds as opposed to 10). Your mileage may vary of course, but for me it's lightning fast now.

I still need to hunt down that bug that's making Firefox 3 setup hang if standard controls are being overridden. That's the top priority at the moment. It's definitely a problem in rendering buttons, but I don't know why yet.

Link to comment
Share on other sites

Uh oh: picture

Oo I never noticed that until now... Don't know how far back this bug goes.

Also a bug with WinRAR is fixed now: The addition/extraction process won't budge unless I rapidly move my cursor over the window. Now it just works. :thumbup

FF3.0.6 setup freezes at Choose what type of install dialog as well...

Link to comment
Share on other sites

The Firefox bug is the one I was referring to earlier. Just as a sanity check, what happens in Word 2003 if SmoothText isn't running?

I'm working on version 0.6.9 but I haven't nailed down the Firefox bug yet.

Link to comment
Share on other sites

Someone has asked me to see if I can make SmoothText work on NT4, and it might be possible. Would anyone be able to post or send me a list of all the functions that NT4's GDI32.dll exports? That way I would know which routines to exclude with compiler directives.

Link to comment
Share on other sites

0.7.0 is mostly good, but I've been forced to resort to IE and it seems to be struggling with some fonts getting squished up. I'm not sure whether it's font-specific or circumstance-specific, but as you'll see from the attached pic it does make it a bit difficult to read...

post-69830-1235284000_thumb.jpg

Link to comment
Share on other sites

Eww. That's ugly -- and weird: I'm not getting that when I run IE.

One question: are you running "large fonts" or "small fonts"? I don't think it should make a difference, but it's at least something to potentially rule out.

Link to comment
Share on other sites

Hi WildBill,

First things first, I have only been using SmoothText for a few weeks, but I find it really great.

I would like to suggest a new feature, for your consideration.

Would it be possible to add a slider, to customise the "level" of anti-aliasing rendered by SmoothText?

The slider would have 0 on one end (no anti-aliasing at all) and 100% at the other end, corresponding to a really "thick" and/or smoothed font rendering. 50% could be the current behaviour.

Not knowing the details of the present rendering algorithm, I would imagine that the slider could tune the width of the energy distribution curve around the central (sub-)pixel.

In practice, this would work in a way somewhat similar to the Advanced tab in Microsoft's ClearType Tuner PowerToy (Windows XP only):

http://www.microsoft.com/typography/ClearTypePowerToy.mspx

Or, to give an example which runs on most OSs, this would work a bit like the Tune function in this freeware little demo:

http://www.grc.com/freeandclear.htm

FYI - I'm suggesting this new feature as your very first post got me thinking: "It's not quite ClearType™, but...". Assuming it's feasible, this could virtually close the gap.

Link to comment
Share on other sites

Tabs are A-OKAY

An uhoh on the explorer menu bars. They are thinner than the others. (The menus themselves have thinner text as well.) The thin text is not unlike the IE bug posted above.

11033921.th.jpg

Any pop-up menu from explorer has the same expanding then shrinking text on hover as before. :( AND all explorer menu's have thinner text. Oo

And as for the adjustable thickness of the text: I do believe I came up with a solution (speed not guaranteed):

Whenever the weighting is changed, SmoothText would then calculate a lookup table between 0 and 255 of integers. Each R, G, B value would be then weighted accordingly. The lookup table is to make it more efficient by avoiding calculating each pixel on the fly.

formula.th.jpg

The lookup table is calculated with the formula:

y = x(1-((c(m-x))/m))

Where x is the input value, c is the scale factor and m is the maximum (255).

infinity < C < infinity,

When C = 0, the function above becomes linear, and the input value = output value. This is the standard as it appears now. When C < 0, the text is bolder, when C > 0, text is thinner. If C > 1, then the low end is cut off.

Edited by Colonel O'Neill
Link to comment
Share on other sites

Bill: I was using small fonts. I gave large fonts a go and it seemed okay but I couldn't cope with how it made the system look, so it went back and it seemed okay then. I'll keep an eye on it, though, to see if I can find something that triggers it.

Link to comment
Share on other sites

Interesting. I don't yet understand it as I've been coding all day, but I'll take a closer look at it. Is it a gamma adjustment? Speed is a real concern, though.

I've posted version 0.7.1, which has a bunch of fixes and improvements. I would especially appreciate some feedback on the NT4 feature, as the copy I bought hasn't come in the mail yet and I can't yet test it.

Link to comment
Share on other sites

It might qualify as some form of contrast adjustment... In theory it should be able to adjust the the weight of the text.

I'm assuming SmoothText has to process each pixel individually after it stretches the font 3x horizontally. As SmoothText processes each pixel from the stretched font, it would have to condense it into either an R, G or B value in one of the destination pixels. As it does this, it looks up a weighted value to use in place of the original. For example:

Original R,G,B values: 0 63 127

Look up each of the R, G, B in the table.

0 ==> 0

63 ==> 95

127 ==> 191

Resulting R,G,B valuse: 0 95 191 - (Note made up numbers)

This means the resulting pixel would be lighter.

Hope that made some sense. :)

EDIT: Oops didn't notice you introduced that feature in 0.7.1.

It does work, except at the left side it adds a lot of colours (trippy). At the right it's blurry.

My method doesn't pick processors, except it's probably not as fast as any MMX implementation.

Edited by Colonel O'Neill
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...