Forums Bug Reports The Trouble with Times New Roman

I'm drawing (asin /drawtext) a Times New Roman message into a custom picture window.

I use a /drawtext to write the text and then /drawtext with the color of the background to erase the text and write over it.

Here is a demonstration of what happens if /drawtext is used several times in this manner. Look carefully.



In this window, whose function is similar to a nicknames' list (in this particular case, it HAS to be a picture window), my nickname has been moved up one slot and replaced with another. Basically, several pixels from the original message/text is left over after one such erase attempt.

I may be mistaken, but by drawing the SAME message with the SAME size in the SAME font with the background color would normally completely erase the previous word.

Here is a sample of the code that seems to be "exposing" this issue.

/drawtext @Paradigm 1 "Times New Roman" 12 7 272 121 15 MegaZeroX
/drawtext @Paradigm 0 "Times New Roman" 12 7 272 121 15 MegaZeroX

To be honest, I wouldn't think this is a coding error at all. I'm more worried that this is a "Times New Roman stinks" kind of error that can only be corrected with multiple erases to insure the previous text is completely gone. If there was another way to quickly erase text (preferrably without /drawrect or /drawfill because I think those are slower), I'd be happy to listen.

If anyone has any suggestions on how I might be able to fix this problem or make a simple ERASE function as such work more efficiently, I would be grateful. (one last note: I am using mIRC 6.03.)

Just checking: are you using font smoothing?

I believe that font smoothing uses the information in the surrounding pixels to determine what colour pixels to set where - so with font smoothing, ur very likely to get the effects mentioned

If your not using font smoothing... then uhhh
uhhh

does it happen with other fonts? :P

Font smoothing should not effect it since he is drawing with a background color.. because in that case, windows uses the background color as the "surrounding pixels" instead of what its drawing on top of.

Font smoothing should not effect it since he is drawing with a background color.. because in that case, windows uses the background color as the "surrounding pixels" instead of what its drawing on top of.

what I ment was...
I thought that the way font smoothing worked was by examining the contrast between the font ur using and the surrounding pixels...

high contrast --> more smoothing
low contrast --> less smoothing

so by plotting black on white, then white on white over it, there may be pixels set in light grey first time round and left second time round

No.. because a BACKGROUND COLOR IS BEING USED which erases all previous pixels..and the text starts from a new slat.

Perhaps I'm not explaining it correctly...

have a look at the following three images...

The process I used to determine the colour of the surrounding pixels is a mid-way between the existing pixels, THEIR surrounding pixels, and the new one, to give the smoothed effect when zoomed out

Note that this is only a theory for windows font smoothing... I know that it happens like this in other smoothing situations, but I dont know whether it happens with windows font smoothing (but I'm not sure what other algorithm type they would use)
He's plotting the text in black (say) then again in white to try to erase it

Initial grid


Plot the text(/pixel) in black. The smoothing option changes surrounding pixels (anti-aliasing I think is the right word to use in this situation) to make it look better and smoother


Plot the text(/pixel) in background colour

Note that although the shade of the surrounding pixels has whitened further due to the new background colour pixel, their still just visible

The residue left over might cause the effect experienced by the reporter (a ghosting effect)

If that is the reason, then a box is the only real way to get rid of the text...

It smooths according to the surrounding pixels. When a background color is used instead of TRANSPARENT background, ALL OF THE SURROUNDING PIXELS ARE THE BACKGROUND COLOR GIVEN, THEREFORE EACH TIME IT STARTS ON A NEW SLATE EVERYTIME..THERE IS NO "RESIDUE" LEFT OVER.

This problem is caused by font smoothing, as fraggle explained. And is easily reproduced:

alias test {
window -podC @test 1 1 200 100
drawtext -r @test $rgb(255,0,0) "Times new roman" -19 10 10 Test Test Test
drawtext -r @test $color($color(background)) "Times new roman" -19 10 10 Test Test Test
}

Try that alias with font smoothing disabled and then try it enabled. The undesired results are exactly what the user described. I presume Font Smoothing and 'Cleartype' are the same. As i'm running Win2K im not able to test if this could be caused by 'Cleartype' on XP aswell.

You can't say that Font Smoothing leaves no residue under these conditions as i have provided an alias above that proves that it does.

You can see from the users example picture that font smoothing of some kind is enabled.

Oh God.. I just realized I misread the guy's post. I thought he said that the second time he was using a background color.. which should have completely gotten rid of the old text. Obviously this is not the case.

fraggle, I apologize, you are absolutely correct.

And MegaZero, this is not a bug, it's just how font-smoothing works.

If technically possible, i think Khaled should add a switch to /drawtext that overrides font smoothing settings. Or atleast an identifier that returns $true or $false if they are enabled.

Yes it is very possible.. and I agree, it should be added.

I would like to thank you gentlemen for contributing your ideas.

I'd also like to request that a $true / $false identifier be added to indicate whether or not Font Smoothing is being used. It would save scripters six or seven lines of dialogue code that would be used to ask the user whether or not font smoothing was being used on their computer.

I do not seem to be encountering the same problem with FIXEDSYS font. It is probably... invulnerable to "font smoothing" techniques. I hadn't thought about that before I started writing this post. "FIXED" SYS *wonders if its a coincidence* I would imagine this is not the only fontstyle that is not "smoothed."

A temporary solution is to simply /drawrect with the color of the window's background in order to erase the line before you start writing again. Thats what I'm doing. Still, it is noticeably slower than a successful /drawtext with the background color.

I think Font smoothing is only applied to True-Type fonts, at certain size. Which happen to be some of the nicest looking fonts..