• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
WildBill

SmoothText 1.1.8

502 posts in this topic

Hmm. There were still bugs to be fixed, so here is version 0.6.6. Hopefully this takes care of them.

0

Share this post


Link to post
Share on other sites

The pop-up menu fonts are going crazy... it unsmoothes entries that I hover over, and leaves a few pixels.

screenshot

Other than that, things seem faster... What painting bug was re-introduced in 0.6.2? Didn't notice anything.

EDIT: Some menus are showing up blank until hovered over. Not present in 0.6.2 (last version I kept)

Edited by Colonel O'Neill
0

Share this post


Link to post
Share on other sites

I've posted version 0.6.7, which should have some really solid menu code. I'm even using double-buffering there, so there should be no glitches. Let me know what you think. Text painting should also be a bit faster overall for everything.

The painting bugs were really obscure. If I really beat on Delphi, for instance, it would eventually freeze. I haven't had that happen again, but for instance, the FireFox 3 setup program freezes at a certain point (which I can at least easily reproduce). I've narrowed it down to when I override buttons, but I don't know why yet.

Edited by WildBill
0

Share this post


Link to post
Share on other sites

True the painting bugs on menu's are fixed... but only when the mouse is not moving.

If you move the mouse really quickly across the menu, you'll see that the text will "jump out at you". Granted this is the same behavior as before, although in 0.6.6 it left the reminants of the text. Now, it doesn't.

Given it's kind of hard to screenshot something that only appears while in motion... I hope I've explained it well enough...

It's not interfering with anything, just kind of an eyesore.

0

Share this post


Link to post
Share on other sites

This program has matured nicely, I use it on my 2000 machine constantly.

It's configured to start upon login, and I never get any problems.

Nice work :)

0

Share this post


Link to post
Share on other sites

I never really considered SmoothText as a software in progress. The very early versions (0.4-0.5) were slow for word editing and powerpoint slide editing (slow computer ya know.)

Now it's just always there.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
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...

0

Share this post


Link to post
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.

0

Share this post


Link to post
Share on other sites

Version 0.6.9 is posted, and it fixes the Firefox 3 setup problem, as well as has a couple of other improvements.

Edited by WildBill
0

Share this post


Link to post
Share on other sites

Hmm. Word 2003 bug? I was wondering.

Anyhow, I've posted 0.7.0 which I'm hoping will fix the tab font bug. Of course, I've been trying to fix it for a while, so you never know.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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
0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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
0

Share this post


Link to post
Share on other sites

I'm not really processing each color individually. The algorithm pre-calculates a multiplier, which is broken up across three MMX/XMM registers:

(for the default setting, the distribution is 12321 for each color component)

0 - current byte position in source buffer
RABGRABGRABGRABGRABGRABGRA
1 2 3 2 1
1 2 3 2 1
1 2 3 2 1

resulting multiplier (blanks are zero):
1 12 123 232 321 21 1

This multiplier is applied to the source buffer, which results in three pairs of R,G,B values (where one of the six is zero). They are added together and divided by the total of the weights (9 in the example above) to get the final R,G,B color values. As an optimization, for the MMX and SSE implementations I perform the division by multiplying by 65536/the divisor (65536/9 in this case) and taking the high word result. 0.7.1 lets you change the weights from the default 1,2,3 values, but it still doesn't do any sort of gamma correction by treating different R,G,B brightness values differently. I could implement that, but it would slow things down since I would then have to hit a lookup table twice -- once before the multiply and once before writing the color to the destination buffer (an inverse gamma transformation and a gamma transformation).

0

Share this post


Link to post
Share on other sites

Thanks a lot for implementing the feature this quickly.

I have downloaded version 0.7.1 and I really like the results.

From a few basic tests I have run, SmoothText with a 30% setting for the energy distribution slider (0% being the leftmost setting) looks virtually identical to ClearType.

Note: I used a PC running Windows XP to get results as accurate as possible, with Firefox 3.0.6, Internet Explorer 6.0, Word 2003, and 10pt Verdana for all the tests.

Please let me know if there are other specific tests worth running and/or if you want screenshots of some sort.

0

Share this post


Link to post
Share on other sites

Agreed. The fourth position seems to provide the crispest results without introducing too much colour distortion.

EDIT

Addition: It seems the Word 2003 bug was attributed to SmoothText.

The fonts that I told to exclude did not exhibit the same behavior.

Edited by Colonel O'Neill
0

Share this post


Link to post
Share on other sites

That Word 2003 bug will have to be chased down at some point, then. Could you show me a screenshot of what it looks like with and without SmoothText, or with some fonts excluded?

I've posted version 0.7.2, which has some goodies. Also, if some kind soul could test to see if it works on NT4, I'd appreciate it.

As far as the new gamma correction, what works best for me is:

- energy slider: in the middle

- gamma: 1.3

It will depend on your monitor, of course.

0

Share this post


Link to post
Share on other sites

Word Selection Menu

I have MingLiu in the exclusion list (among other Asian fonts).

39149659.th.jpg

Unfortunately I don't have any NT4 discs... :(

Best combo for me: Energy 6/Gamma 1.40 --- No perceptible slowdowns.

Are you using the function I posted above?

I notice that the Gamma slider will affect text differently based on background color (since you gave that nifty tri-tone). Unfortunately, it won't make text crisper at all colours...

0

Share this post


Link to post
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.