Talk:ClearType

Criticism of ClearType

If someone wants to add a "Criticism of ClearType" section, here's some sources:

• ClearType and Segoe UI - Why does Microsoft hate us?
• Joel on Software: ClearType - do you use it?
• Barry Schwartz: I hate ClearType
• Predominantly negative user comments on the Microsoft Windows 7 blog and IE7 blog and Visual Studio blog

The basic complaints:

• People with sensitive eyes can see the color fringes, and find it really annoying
• Screenshots taken with ClearType look bad when resized, rotated, or viewed on a different monitor
• ClearType doesn't work well with colored text, analog monitors, or LCD monitors that rotate
• It's difficult to disable ClearType because of scattered control panels for IE, WPF, Windows themes, etc.
• The default fonts for Vista/Win7 are designed in a way that looks blurry unless ClearType is enabled

Some informal polls showing a substantial minority who dislike ClearType:

• http://hardforum.com/showthread.php?t=837565
• http://www.msfn.org/board/topic/136059-cleartype-do-you-like-it/
• http://techreport.com/forums/viewtopic.php?f=37&t=58006

If anyone can find a rigorous study, that would be really useful. Microsoft touts various research "proving" the benefits of ClearType, but these studies always compare against old style Black&White fonts, never against standard (i.e. grayscale) font smoothing.

24.22.244.85 (talk) 12:32, 12 July 2010 (UTC)

• Anecdotal information, but now that Office 2013 has stopped using ClearType and instead is using grayscale, I get a screaming headache after an hour or so. It's funny, I'm so used to it, that when I view rendered fonts with no antialiasing, I see a yellow fringe around the letters.50.59.88.46 (talk) 19:30, 18 November 2014 (UTC)

Actually, grayscale is antialiasing, just a different kind of antialiasing. Thomas Phinney (talk) 01:33, 20 November 2014 (UTC)

I do hope someone inserts this point because I think it is important, especially since the name 'cleartype' implies that it is clear. Not everyone agrees it is. After all, it is a rasterization/anti-aliasing technique of 'smoothing' an otherwise sharp outline to a blur. I can focus on a jagged line, but I can't focus on a sub-pixel rendered edge which some see as a blur. Preroll (talk) 18:26, 7 October 2010 (UTC)

Font Hinting

I was disappointed to see no mention at all of font hinting. Sub pixel rendering is only half of the approach of ClearType. ClearType also forces fonts into the pixel grid judiciously, affecting the fidelity of the rendered font. Operating systems like Ubuntu & OS X use sub pixel rendering too, but reproduce fonts far more accurately because of a different approach to hinting information. Regardless of which one anyone prefers it is a very important and very significant difference in ClearType and I think it's essential that such a fundamental point be mentioned in the article. I've quickly added some details.

MatthewFP (talk) 00:19, 14 November 2008 (UTC)

Rewrite

I've taken the liberty of largely rewriting this article and adding two new illustrations. Since the article on subpixel rendering goes into the detail on theory and math behind this technology, I modified this article to provide a description more suitable for non-specialists, such as ordinary computer users curious about ClearType and how it works. The article now points explicitly to the Subpixel rendering article for readers who want all the details on how the technology works internally.

The additional illustrations show close-ups of ClearType effects. They are not photographs, but simulations based on the screen captures that were in the previous version of the article (and are still there, merged with the new ones).

— Agateller 12:46, 21 January 2006 (UTC)

Other

Do PDA's with vertically oriented screens have vertically stacked subpixels?--Dwedit 03:15, 14 Dec 2004 (UTC)

This article should be merged (or moved rather) into the Subpixel rendering since ClearType is simply microsoft's trademarked term for subpixel rendering. 138.89.177.98

No. ClearType is a patented type of subpixel rendering that is better than the obvious method. Notice the low-pass filter specs for example. AlbertCahalan 18:04, 25 May 2005 (UTC)

Nevertheless, most of this is an entirely generic description of subpixel rendering, and that is the heading it should be under -- with perhaps a note about Microsoft's implementation, or a link to a new page here that actually explains what allegedly sets ClearType apart. Haeleth 19:29, July 21, 2005 (UTC)

I support moving it. Someone who just followed a link to this might come away thinking that Microsoft invented sub-pixel rendering. I made that mistake at first. Algr

page

I agree with last comment. Whilst Wiki should describe that Cleartype is Microsofts trademarked term for subpixel rendering, the actual explanation and definition of subpixel rendering does not belong here. Wiki doesnt seem to do this for other trademarks e.g. the page for "Pepsi" doesnt tell you how Cola is made, so why this time?

I also agree with the above comment. This page's contents should be under subpixel rendering. 18:48, 2 May 2005 (UTC)

While I can agree, I don't agree that "this page's contents should be there". Some of it may better belong there though. -- Northgrove 21:42, 23 April 2006 (UTC)

In practice

The entire 'In practice' section is horribly mistaken.

Firstly, the image used to show off subpixel rendering is not approproate - they are spheres which your brain does not need subpixel accuracy to determine. When viewing fonts, on the other hand, you can tell if something is not just right. Therefore, the image should show off text rendering. It matters greatly how closely spaced each character is from one another. With some fonts, moving a character one pixel away from another makes it appear too widely spaced. If you move it back, it then looks too close. Having 3x the horizontal resolution helps resolve this, allowing you to move the character a fraction of a pixel. Subpixel rendering allows this, and it is noticeable. Such an image would be far more valuable in determining whether or not ClearType works - especially considering ClearType technology was created for the purposes of font rendering.

Secondly, to prove his point, the author shows actual photos of his screen. But, they are at the same resolution as the original images. That is similar to showing off the resolution of a new 21" monitor by showing a picture of it on an old 13" monitor. The image needs to be zoomed in at least 3x to see if there may be 3x the resolution. Yes, I know the images link to larger images, but this does not change the fact that the images on display on the page itself have absolutely zero value. Steve Gibson of GRC.com has done the proper thing showing off his own subpixel renderer which clearly shows that it does improve the resolution considerably: http://grc.com/ctwhat.htm (view the images under the 'Through the Looking Glass' section). In short this entire section needs to be removed, since it is completely wrong. It should be replaced with the images that Steve Gibson has produced, with his permission, that proves that subpixel technology works. 18:48, 2 May 2005 (UTC)

No where on that site does Steve Gibson mention applying a low-pass filter. This is important. It prevents all sorts of nasty color fringe effects. I suspect he chose his examples carefully to avoid color fringing. AlbertCahalan 18:04, 25 May 2005 (UTC)

In http://grc.com/cttech.htm he do something end up just like using low-pass filter.

Yes, that is correct. On the main page, Steve Gibson explains it without any low-pass filter, to make it easy to understand for beginners. But, when you read on, you'll realize he uses a low pass filter. In fact, his demo program allows you to change the filter in real-time, so you can see the color fringing that occurs when it is incorrect. 15:15, 9 August 2005 (UTC)

Illustration

Using a table to illustrate the pixel pattern is inappropriate, since different browsers can display it in different ways. Can someone make a PNG graphic, or make a close-up photo of a display? —Michael Z. 2005-08-4 17:15 Z

I think a close-up of a display is a little too much, and no camera is probably able to do such a close-up. I uploaded a schematic picture, though. - Sikon 03:30, 21 August 2005 (UTC)

Good work. Thanks. [late reply; just saw this] —Michael Z. 2005-10-26 04:56 Z

Current bottom right illustration looks incorrect. The image doesn't contain any colours. Just grey smoothing.--CrazyGoldy 05:58, 2 February 2006 (UTC)

fonts?

Some fonts (eg. Comic Sans) don't have subpixel rendering like others (eg. Arial). Is it because of the font or Windows specifically disable it to that font? Also is East Asian script render with Cleartype normally possible in windows? So far I haven't seen any one that have any anti-aliasing at all.

Subpixel order

How does the underlying software know which of the three subpixel colors should be used to render on the subpixel layer. This article assumes that subpixel are in the left-to-right order "RGB".

Subpixels

Subpixels

In the above example, the subpixel left to a character is blue, while the subpixel right to a character is red.

What if, say, the order was "BGR" - red and blue are interchanged, therefore subpixel rendering could be wrong, leading to a rather blurry font character. Either the monitor driver tells the operating system the correct subpixel order or a industry wide standard regarding subpixel order exists. --Abdull 23:00, 10 February 2006 (UTC)

There are LCD monitors where the order is BGR, and on them the default Cleartype implementation indeed looks bad. For that purpose, Microsoft has an online Cleartype Tuner, where one can soft-tune various delicate parameters of cleartype, among which is the subpixel order:

Cleartype Tuner

Cleartype and CRT Displays

The following remark appears in the main article, under "Display requirements":

displays that have no fixed pixel positions, such as CRT displays, are incompatible with ClearType

OK, this is totally wrong. Cleartype does work on CRTs. By "work" I mean "has visible effect". While it may not do exactly what it ideally should do on LCD displays, text does look completely different - it is smoother and wider. Now, some people like this effect, others don't (claim that it looks blurry), but it is there. Exact appearance may also vary between displays, which could explain the different opinions on it.

Following are two links showing the same screenshot, taken once with "standard" smoothing and once with "cleartype". Compare it on a CRT of your choice. Screenshots were taken personally by me, so there are no copyright issues.

Standard Cleartype

I agree; ClearType on my CRT looks great, and clearly as good as on an LCD. It's among the first things I turn on on a new Windows install myself. I don't really understand why it looks so good (at least as good as regular greyscale antialiasing), but it does. -- Northgrove 21:40, 23 April 2006 (UTC)

I think you are confusing Cleartype with ordinary text anti-aliasing. Cleartype includes anti-aliasing, but on a CRT, the text would look best with anti-aliasing (Grey pixels) but not Cleartype (Color fringes). BTW, those frame grabs come from your graphics memory, so they show that Cleartype is on, but don't show what effect it has on your monitor. Algr 06:01, 28 May 2006 (UTC)

Cleartype is a set of algorithms for both subpixel rendering and anti-aliasing. When used on LCDs it combines both technologies, and when used on CRTS it uses only the latter; but even in the latter case Cleartpe it is still a specific, non-generic implementation of anti-aliasing, so it is definitely meaningful to talk about Cleartype on CRT screens. Simxp 16:24, 3 January 2007 (UTC)

Subpixel rendering doesn't work on CRT's because you cannot address the individual color phosphor dots. DonPMitchell (talk) 14:23, 24 September 2009 (UTC)

I point you to the comment right above yours. -- simxp (talk) 18:35, 24 September 2009 (UTC)

As far as I've been able to find on MSDN, there's no greyscale anti-aliasing features in cleartype, so it can't work as intended on a CRT. With some settings it might give an antialiasing effect that will still be preferable to some users, but it's definitely objectively worse than you would get with greyscale antialiasing. You simply can't subpixel render without adressable subpixels. The citation to Microsoft's explanation of use on CRTS does not say anything about CRT types and the info about aperature grille CRTs in this article is incorrect. Though aperature grill CRTs have phosphor stripes similar to the pixel layout of an LCD, they're not individually adressable, so will give detatched fringes exactly as in a normal shadow mask. Nwimpney (talk) 07:47, 12 March 2015 (UTC)

Color fringing

In this magnified view, it becomes clear that, while the overall sharpness of the text seems to improve, there is some color fringing of the text. At normal viewing distances, however, only the sharpness is perceptible, and the color fringing becomes invisible.

I hope the author however realize that the point is to have this "color fringing" and NOT a greyscale antialias effect. I thought it really comes of as he/she doesn't and that it's a "problem that you don't really notice so much". -- Northgrove 21:36, 23 April 2006 (UTC)

The illustration and description of color fringing are highly misleading. The color fringing shown in the enlarged "Wikipedia" text does not exist! What this enlargement shows is erroneous color interpretation caused by the use of a screen capture or "zoom in" program that does not take individual subpixels into account. The colors shown in this enlargement do not exist in the actual displayed text; they are an artifact caused by the "zoom in" program's erroneous interpretation of the subpixels.

The following thought experiment will demonstrate this. Imagine a typical LCD display, where all the subpixels are the same size and shape, with identical borders between each of them. The subpixels are not grouped physically into "pixels". Then imagine ordinary black and white text displayed on this LCD with no anti-aliasing. It would show up as pure black and white in an enlargement. Now imagine the same text shifted to the right by one subpixel. An enlargement using a program unaware of subpixels will now show all kinds of colors. But to the human eye, the display will look identical. There will be no more visible color fringing than there was in the original display. In effect, shifting the text right has simply converted the display from an RGB subpixel display to a GBR subpixel display.

If there were actual physical boundaries between the RGB subpixel groups, separating them into discrete pixels, that would be a different story, but I've never seen an LCD display built like that.

There is color fringing that can be seen in certain cases with ClearType, but it's not the type shown by this enlargement. I will update the article when I get a chance... --Michael Geary 15:15, 21 July 2006 (UTC)

I can see the fringing - although I have to look VERY close. Algr

Yes, but any color fringing that you see is unrelated to the supposed color fringing shown in the "Wikipedia" enlargement. The colors in that enlargement are an artifact of the screen capture; they are not present on an actual physical LCD display. --Michael Geary 17:10, 30 July 2006 (UTC)

I tried making my own version and it came out exactly the same. The pic does reflect what I see on my actual LCD display. Maybe it isn't activated on your screen. Algr

ClearType is definitely enabled on my display. It's the first thing I do whenever I get a new notebook computer. :-) When you said you made "your own version", what exactly did you mean? Did you use a screen enlargement or "zoom in" program, or load a screenshot into a photo editor and enlarge it there? Any of those techniques will result in the same sampling error seen in the "Wikipedia" enlargement. Most screen enlargement programs work at the pixel level only - they do not take subpixels into account at all. But an LCD display does not have pixels. It only has subpixels, and a screen enlargement based on pixels cannot give an accurate rendition of subpixel rendering. The colors it displays are not present on the actual display, because your eye does not group the subpixels into pixels in the same way that a screen enlargement does. That is what makes subpixel rendering possible in the first place. --Michael Geary 16:33, 31 July 2006 (UTC)

I can see it every way. Screen zoom makes it most obvious, but the same fringes are there when I use a magnifying glass. I also took a shot of my screen with a digital camera, and it is there. Algr

A screen zoom doesn't make color fringing more obvious. It shows colors that aren't there. It creates fringing that doesn't exist on the actual display as seen by the human eye.

I prepared a couple of images that illustrate the point. First, the letter "W" as enlarged (misleadingly) by a program that works with whole pixels only:

Now, the same letter "W", this time enlarged with a program that correctly displays the individual subpixels as they appear on an RGB LCD:

As you can see, the two images don't even resemble each other except for the basic letter shape. The first image has tan and brown pixels to the left of each stroke, and shades of blue to the right of each stroke. These are the false colors I've been talking about. They are an artifact of the sampling error caused by the whole-pixel enlargement.

Those colors do not appear at all in the second image, and they don't appear when the normal-size W is viewed with the eye. Your eye does not lock itself to whole-pixel boundaries as a naive screen enlargement does.

I'm not saying there isn't any color fringing. What I'm saying is that a typical whole-pixel enlargement shows color fringing that doesn't exist on a real display. If you look closely at the second image, you can see where there will be some color fringing, but it is nothing like the false colors shown in the first image. Does that help clear things up? --Michael Geary 06:57, 1 August 2006 (UTC)

OK, now for some real color fringing. Here is the same letter W, rendered with no antialiasing, and enlarged to show the subpixels:

As you can see, each vertical stroke has a blue fringe on the left and a red fringe on the right. This of course is caused directly by the subpixel layout of the display. It's interesting how the fringing is more apparent in the enlargement of this non-antialiased text. --Michael Geary 09:19, 1 August 2006 (UTC)

I can see those colors it WITHOUT screen zoom. Algr

>>> If that's the case, Algr, either there's something wrong with your screen, or you're not running it at native resolution / there's some other mismatch occurring. I'm staring at a cleartyped display right now, with a resolution of about 90dpi, putting my face rather closer to it than normal, and I can just about discern the faintest of fringing on some letters, but nothing at all on others. The primary offenders, oddly enough, are entirely vertical lines - suggesting either hinting has failed, or I'm seeing something that would persist even with CT turned off - and straight lines at a relatively shallow angle compared to that, which are amongst the features that are meant to get the greatest benefit from CT (and we might expect to show a little bit of artefacting when examined closely). Returning to a normal viewing distance, there's basically nothing, save for maybe the tiniest bit of reddening in the inner top left corner of the capital N's, strangely. However, given that it doesn't otherwise exhibit (certainly nothing like the pictured examples!) and the alternative would be egregiously jagged lines at the text sizes in use, I'm happy with it.

The thing is, to use it properly, you shouldn't employ narrow stroke widths OR too many narrow spaces between strokes. The best thing to do is to keep to integral full-pixel sizes (ie 3 subpixels wide for landscape/tall for portrait) or only slightly above or below (2 to 4 at the extreme, preferably 2.5 to 3.5 if at all possible). This means that in the great majority of cases, your black strokes will uniformly darken a strip of 3 subpixels, knocking out a red, a green, and a blue, and so achieving colour neutrality across that small space. Even if the repositioning and subpixel-based greyscale antialiasing means it's not actually doing RGB any more, but GBR or BRG, or (half R)-G-B-(half R), etc, the overall light output across that single-pixel-equivalent space should remain chromatically neutral and appear with no more fringing that would be seen with pixels all aligned to RGB triplets alone. The lower colour resolution of the human eye also helps with this, as the parts which detect brightness will be attuned to the finer progression of the line from side to side across the individual subpixels, whilst those that detect hue will generally merge the entire pseudo-pixel's output together, and that of the neighbouring ones, using the colour-insensitive brightness information as a cue as to where the actual edges of a coloured object lie. It's the reason why, for example, we don't see the white background as a pattern of a few thousand vertical primary-coloured stripes, or sky-blue items as consisting of a tightly repeating gradient going black-dark green-intense blue over and over.

Using narrower strokes (and to a lesser extent wider ones that are not integer multiples) is what carries the big risk of chroma artifacting, as you are then *actually* introducing additional colour information, and unless the line is moving laterally at a decided (and non-integer...) pace from one row to the next, that imbalance will accumulate both vertically as well as horizontally, and your colour receptors will pick up on it even with both horizontal and vertical blurring. Two-subpixel isn't too bad, as those are the lighter colours (yellows, magentas, cyans), and 2.5 is decidedly pastel, which gives a good chance of vertical cancelling-out. Lower than that and the colours get very obvious. After all, that's essentially the way the screen deliberately produces small dots of colour in the first place.

Beyond a couple of pixels all bets are off anyway - so long as there's a reasonable amount of white on either side of the black stroke (or whatever your ink and paper colours are), and the stroke itself is thick enough, the terminal subpixel at each end should be perceptually blurred into its neighbours as if it's the first or last of a non-cleartyped pixel, and the boundary between it and the contrast will stand out more because of the brightness difference than the differing colours, which will offer more of a sharpening than a tinting effect.

Which does sort of fit with the effects observed by myself just now - the lines which showed any kind of detectable colour don't quite look to be the same width as their untinted neighbours, like they're a little adrift of 3 subpixels wide at each vertical position, and the tight corners are naturally the places where the "white" gap between "black" strokes is unavoidably crunched down to less than a full pixel. Dealing with that could probably be considered a stylistic effort, e.g. reshaping and re-hinting the font so that there are effectively no extra-sharp junctions, with the lines coming together either in a parallel or perpendicular (or 45 degree) fashion after a short, subtle curve away from the angle they were otherwise following - essentially making the confluence as close to a non-cleartyped version as possible - which for one thing is likely one of the contributors to the characteristic mix of boxiness and swoops making up the Tahoma and Verdana fonts. There might also be an argument for deliberately over-blurring the rendering at the subpixel level so that it returns to more of a greyscale type effect in these, ahem, corner cases...

And also covers, in a way, why it becomes hugely noticeable when scaled to a non-native resolution; the subpixels don't match up any more, are spread over multiple real pixels, and the effective width is definitely non-integer, wrecking the smoothing effect and the luminance:chrominance spatial correlation, making the fringing hugely noticeable.

Incidentally, the lack of vertical smoothing in early versions isn't that much of a handicap, really, although it does interfere with portrait displays; the vast majority of fonts, even including stocky ones like Courier, have glyphs that are taller than they are wide (hence why old textmode displays had fonts that were e.g. 9x14 or 8x16 pixels), and far fewer diagonals that form shallow angles with the horizontal, or towards the horizontal from 45 degrees, than is the case in the vertical quadrants. Thus having coarser resolution in that direction and no smoothing is less of an issue, as we are at least smoothing off how the vertical and near-vertical lines interact with the rest of them, even if those others are still stuck to a blocky grid and look a lot more rigid as a result. Even with smoothing the difference would persist, just as it does with all smoothing removed and nothing but pure 3x1 subpixel addressing in use. There's simply more resolution in that direction... same as there was with 640x200 (240, 256), 512x256, 480x160 and 720x350 displays of old (depending on your device...), which were typically stretched to give a squarer image with relatively tall pixels - in the case of 640x200, 2.4 times taller than they were wide if expanded to fill a 4:3 screen. So it could be thought of as something of a return to that kind of display technique. Similar also to fax and non-square printer resolutions... generally the rez "across" the portrait page is greater, usually by about 2x, than that running down it... more due to physical challenges than anything else, but it does match coincidentally well with the demands of reproducing type or typical handwriting, where a bit of jagginess in the non critical direction may still be less noticeable than much finer but still discernible jaggies in the critical one.

What would be interesting to see is how things come out if you zoom it by separating a screengrab into its RGB components, upscaling by 3x (or 6, 9...), then shifting the red to the left by one (2, 3) pixel(s), and blue to the right similarly, before recombining the channels. The result won't match what appears on your screen under strong physical magnification, but it should be closer to what your eye records and sends to the brain for further processing and reconstruction... with a duplicate of that result put through a channel-weighted greyscale conversion producing the effective black-and-white detail outcome. At least, theoretically.

As well as running the entire OS rendering engine on that basis, with everything internally rendered at 3x the width (or maybe 9x width, 3x height, for a moderately decent 2D anti-alias?), through some on-the-fly filtering engine (ie something that's "black", "white", "grey" gets to affect all pixels, something "pure green" only affects every third pixel with a +1 offset...), to a (3x1 size) greyscale plane with the data for each subpixel in strict order, red followed by green followed by blue followed by red. With a simple change of how that monolithic plane is interpreted, it changes from a wide greyscale field, or three tightly interleaved ones, into normal width truecolour RGB, without even needing any further work, and can be sent straight to the screen. That would effectively mean *everything* rendered on screen other than maybe 1:1 readymade bitmaps would be able to enjoy the same subpixel positioning, rendering and smoothing effects, even strongly coloured ones (which would only really benefit from something analogous to regular full-pixel antialiasing), not just black/white/relatively dark coloured text. And I bet once it wasn't just some of the text exhibiting the effect and standing out from everything else on screen as a result, people would stop noticing it, just as they never really noticed the inherent and fairly strong colour fringing on coarse-dotmask CRTs of old...

(this, after all, is essentially how the dithering of old worked, and how it works with printers and some LCD TVs still - taking advantages of imprecision in the human visual system - except it mainly shies away from trying to create an illusion of finer tonal graduations between the only available light(er) and dark(er) colours and instead aims to output a false grey tone by combining locally equal amounts of contrasting colours... Much like making a sort-of-grey on a computer that could only output primaries by rapidly alternating blue with yellow...) 193.63.174.254 (talk) 16:08, 15 March 2017 (UTC)

---

I can explain the above confusion as follows: First, it should be clarified that "antialiasing" (i.e. using varying brightnesses to smooth the edges) is a separate technique from "subpixel rendering". Image #2 above (called "W-enlargement-subpixel-rendering.png") combines both techniques, whereas Image #3 above (called "W-enlargement-subpixel-no-antialias.png") uses neither technique. Since antialiasing doesn't affect colors, Michael Geary's argument would have been less confusing if he had omitted the antialiasing from Image #2, as done in example #4 from the article:

Now, subpixel rendering DOES cause normally white or black pixels to have color artifacts (let's call this "color drift"), but this phenomenon is UNRELATED to the colored pixels seen when a screenshot is enlarged (referred to by the article as "color fringing"). Rather, this "color drift" occurs because the total count of red, green, and blue subpixels is no longer enforced to be exactly equal, which it would have been in a normal grayscale image. An extreme example would be a vertical line of width 1.3333 pixels: If it's rendered as a column of 4 subpixels RGBR, then there will be twice as many red pixels. Of course, for typical font curves, these imbalances will be very localized, and many people will not notice them at all (whereas more obsessive people can definitely see them). Similar differences of opinion arise with JPEG artifacts.

That said, I agree with Michael Geary that "color fringing" as described in the article only occurs when screenshots are enlarged. But I also agree with Algr that ClearType's "color drift" looks like dogshit from an artistic standpoint, regardless of whether it's easier for people to read.  :-) Loqui 05:14, 19 November 2006 (UTC)

Yikes! I wouldn't be that harsh about it. I can usually see the color fringing, but only by leaning into the screen and looking VERY closely. It isn't something that bothers me in normal use - it seems to work well. Of course I'm on a Mac, so maybe the windows version is different. (Or gets misaligned on certain monitors.) Algr 17:51, 21 November 2006 (UTC)

This was analyzed early on at Microsoft. The frequency response for cleartype is illustrated here: http://www.mentallandscape.com/Papers_00sid_fig3.htm —Preceding unsigned comment added by DonPMitchell (talk • contribs) 22:17, 6 July 2008 (UTC)

There is real color fringing going on in any subpixel rendering, however the "Wikipedia" example is not showing it correctly. That type of fringing won't occur, and looks more like simulated chromatic abberation, or misconvergence. Assuming we went with that type of pixel representation, the fringing should alternate colours along the diagonal edges. (subpixel aliasing) The vertical lines will have solid fringes of a single colour, which will be decided by the subpixel alignment. Of course, even without subpixel rendering on a standard RGB stripe they will have fringing which is always the same colour on the same side. Nwimpney (talk) 08:18, 12 March 2015 (UTC)

ClearType on Macs

I'm surprised to read that this is a Microsoft technology. Cleartype (or some tech doing the same thing) is ubiquitous on all Macintoshes, but most windows programs still lack even basic anti-aliasing. Why is MS behind on something they invented? Do windows users all have to know to turn the thing on? Algr 06:05, 28 May 2006 (UTC)

ClearType is off by default in Windows XP. This is because the vast majority of displays that were being sold and used at the time of its release (five years ago) were CRTs. There are still a very large number of CRTs out there, but the transition to LCDs and portable computers has been ongoing for a couple of years, so in the future (ie. Windows Vista) ClearType will be enabled by default. Warrens 16:20, 28 May 2006 (UTC)

Please don't confuse ClearType and sub-pixel rendering. Sub-pixel rendering has been around for a long long time and was not invented by Microsoft. ClearType is just Microsoft's implementation of sub-pixel rendering. AlistairMcMillan 19:34, 28 May 2006 (UTC)

But sub-pixel rendering (I called it anti-aliasing.) is always a large improvement on any monitor - especially TV sets. (It's only bad for print, and it is rare to directly print screen data.) It's only ClearType that is exclusive to LCDs because on a tube, you can't know where any given pixel is relative to the color stripes. Algr 02:28, 1 June 2006 (UTC)

You say "sub-pixel rendering (I called it anti-aliasing.)" -- but sub-pixel rendering and anti-aliasing are two completely different technologies. Anti-aliasing works on all types of monitor; sub-pixel font rendering only works on LCDs. Cleartype is *both* -- when turned on on LCDs it combined sub-pixel font rendering with anti-aliasing; when turned on on CRTs it uses only anti-aliasing. Simxp 16:27, 3 January 2007 (UTC)

Algr -- The subpixel rendering & anti-aliasing implementation on Mac OS is a very different implementation to Cleartype. Mac OS discards all hinting information, in stark contrast to Cleartype which was built to take as much advantage of hinting as possible. In my opinion, Cleartype's method provides superior legibility for small font sizes, but of course, opinions vary; this guy has some high-res comparison photos a few screens down, have a look and decide for yourself. Simxp 16:46, 3 January 2007 (UTC)

Generic name?

Is there a generic name for what is done on LCDs to improve sharpness by activating individual color stripes? It's not "cleartype" or "quartz" because those names can also apply to grayscale subpixel rendering. I've made a new illustration of this, but now I don't know what to call it. BTW, it appears that plasma displays also do this with _images_ when given HDTV signals that are beyond their stated resolution. This is why I've observed that a 480p plasma display can look much sharper when given HDTV then when given DVD input. Algr 17:56, 21 July 2006 (UTC)

Added drawing. Algr

Here, it would seem that subpixel rendering is that generic name. But you seem to use this term to mean antialiasing in general - does anybody else? Anyway, antialiasing is a quite independent concept from spatially separating the colour components for rendering. I suppose one possible name for the latter is "componentwise rasterisation" or something like that.... -- Smjg 00:29, 4 April 2007 (UTC)

How ClearType works

Hmm... The "How ClearType works" section starts out OK, but the business about ClearType only working with lines less than one pixel wide is wrong, and the "Wikipedia" enlargement is misleading (as discussed above). I'll rework this section when I get a chance to do it justice, unless someone else gets to it first. --Michael Geary 09:51, 1 August 2006 (UTC)

No, I think it's a good idea to show the "Wikipedia" enlargement for two reasons: I can see the color fringing on some letters at certain sizes, and it helps the reader understand how the technology works. --Crashie 15:15, 22 March 2007 (UTC)

I think it might actually be useful to include an image made from smoothly-enlarged, offset and overlapped copies of each colour channel, along with the "this is what's in the video memory" and "this is how your screen would look if you turned the brightness down by about 50% and aimed a 40x magnification microscope at it" ones, to demonstrate how your brain actually perceives what comes out of the LCD. Which would ultimately be a mostly B/W letter, with triple the resolution of an unsmoothed or full-pixel antialiased one (which could be put alongside, having received the same treatment, to demo how some of the same effects are inherent to all text on an LCD), and some fringing that's actually considerably thinner, softer edged, and far less saturated even compared to what's in the nearest-neighbor, merged-subpixels example. If I can whip something up in Gimp I'll try uploading it to imgur or something, but I've never really had any luck posting images to Wikipedia, especially as it would essentially class as OR. 193.63.174.254 (talk) 17:13, 15 March 2017 (UTC)

Tuner

Is it worthwhile mentioning the online tuner by Microsoft?
Sclozza 02:40, 8 September 2006 (UTC)

Apple Typography in See Also?

The see also section of this article has a reference to Apple typography. However, the referenced article deals with the fonts and typography of the various incarnations of the Apple logo, and the fonts on the original Macintosh.

Shouldn't we really be linking to Fonts on the Mac?

Arun Philip 14:57, 23 October 2006 (UTC)

removed image

I removed the image Image:ClearTypePixels2.jpg in the 'Illustrated comparison' section on the right because it is misleading.. It shows antialiased text as a 'simulated' version of cleartype. First of all, it should have make clear in the caption that it was a simulation, and not actual cleartype (it only said so in the text). But anyway, it is a useless and even misleading image since the point of cleartype is the improvement over antialiasing, which the image misses completely. I also moved the other image in that section. BlankAxolotl 04:40, 25 November 2006 (UTC)

Not every human has the same sight

I f.ex. seems to see more colors than "normal" people does. So when I Upgraded to Office 2007 (cleartype) and opened my outlook, I couldn't read my emails - everything seems very very blurred and moving around..strange - but calling number of my co-workers to read it, they told me it looked exceptionaly sharp and very readable - this seems to make cleartype more of a problem for some people —The preceding unsigned comment was added by 194.144.69.161 (talk) 21:12, 21 January 2007 (UTC).

Agreed. I find cleartype almost unreadable as it is all blurred and out of focus to my eyes. I know for a fact I have certain sensitivities to particular colours, it is why my glasses all come with a red tint to compensate, otherwise natural light causes me pain. I'm guessing people whose eyes lean more towards a certain end of the spectrum will be more likely to experience "foggytype". —The preceding unsigned comment was added by 82.39.188.60 (talk) 02:04, 8 February 2007 (UTC).

I do have the same problem as you guys and call it blurtype since that's the effect it has for me. The changes in Office 2007 just about made me crazy until I figured out how to turn it off, AND switch to a more legible font to boot. I'm not sure it's sensitivity to certain colors that's the problem, but what I do know is that it's particularly bad on smaller fonts. Larger ones are readable but still noticeable - in the article itself the lower text in the blown up "exerc" picture looks way blurrier than the upper one, even though the lines are smoother. I also see some mild color fringing if I have cleartype turned on (and before anyone asks, I have set the correct pixel matrix.) Anyone have any idea as to what to add/change to the main article to reflect this? 85.166.251.158 00:00, 12 May 2007 (UTC)frode

Here's a simple explanation of the phenomenon: Imagine a white vertical line that is 1/3 pixel wide, on a black background. On a normal antialiased display, this line would be 1 pixel wide but 33% gray (because it's thinner than a pixel). But on a ClearType display, it would be 1/3 pixel wide (i.e. 1 subpixel), but a random color, e.g. entirely red (or green, or blue). Let's add a 2/3 pixel wide vertical line to this hypothetical scene -- it's color will be yellow (i.e. red+green), or cyan (green+blue) or magenta (red+blue). So instead of varying shades of grey lines, what you've got is obvious color errors. ClearType "works" because typical fonts aren't made from perfectly vertical lines, but instead squiggly curves whose errors will be much more noisy. But "noisy errors" isn't the same as "no errors" -- people who can see small details see small errors everywhere. My question is why an incremental improvement in horizontal-only resolution is sooo important that Microsoft is willing to sacrifice color fidelity, screw up people's ability to take screenshots, break support for swiveling monitors, etc. Why? Who asked for this feature? Loqui (talk) 19:30, 20 March 2008 (UTC)

Nice explanation, except that it's wrong. Pure, unfiltered subpixel rendering would indeed give, e.g. a 1/3 pixel vertical line being either red, green, or blue; and text rendered using this would exhibit heavy colour fringing -- example. The explanation you give as to why Cleartype works despite this with fonts is not correct: lots of fonts do indeed have many vertical and horizontal lines as part of lots of letters. The reason Cleartype works is that it isn't just unfiltered subpixel rendering. Have a read through [1] for an explanation. -- simxp (talk) 16:23, 21 March 2008 (UTC)

Wow, I stand corrected. That information should really be incorporated into the Wikipedia article somehow. I've read several articles about ClearType, but none of them acknowledged this issue or mentioned any low-pass filter stage. So... how do you explain the people who see blurry colors around the text? Is the low-pass filter an imperfect approximation? Loqui (talk) 16:52, 7 April 2008 (UTC)

Yeah... I just re-enabled ClearType and ran the ClearType Tuner utility, but I still see very conspicuous green and red discolorations around the edges of the text. (I also noticed that whereas normal font-smoothing reverts to crisp black+white below about 9 points, ClearType smooths the small sizes as well.) So it seems that the low-pass filter reduces errors, but does not completely remove them. If subpixel rendering really worked, why is it only used for fonts? Why doesn't Windows use it for everything? Loqui (talk) 17:19, 7 April 2008 (UTC)

I think that everyone would see the lower "exerc" as fuzzier - It looks that way to me, and sub-pixel rendering works for my eyes. The image seems to have antialiasing that is excessive to what is really needed Is it a real image, or a simulation? It is news to me that some people react badly to cleartype. Your theory sounds reasonable, but we'd need a source to include it in the article or else it is original research. I think it's Google-time again. Algr 07:30, 20 May 2007 (UTC)

Unsubstantiated opinions on ClearType

The section containing the words "Nobody likes ClearType" and a decription of a "humanoid dog" going crazy after staring at a CRT monitor with ClearType have been deleted. Not only was the fact that "Nobody Likes ClearType" unsubstantiated, but the idea of a crazed humanoid dog(?) is patently ridiculous. —Preceding unsigned comment added by 71.162.64.130 (talk) 21:42, 23 October 2007 (UTC)

That was vandalism. Fixed it. --soum ^talk 04:32, 24 October 2007 (UTC)

Although it does raise a point - why isn't there a "Criticisms of Cleartype" section? I mean, there are tons of people who loathe it - surely this warrants mention? 153.108.64.1 (talk) 15:07, 17 December 2008 (UTC)

Only if it's notable enough to have garnered some real press coverage that we can cite, not just individual opinions on blogs or message boards or whatever. —mjb (talk) 17:21, 17 December 2008 (UTC)

How about Steve Gibson's whole section dedicated to how Microsoft did not actually invent sub-pixel font rendering? 76.179.147.161 (talk) 23:21, 18 January 2009 (UTC)

Well, there's nothing in this Wikipedia article on ClearType that says Microsoft invented subpixel font rendering. It merely says Microsoft invented ClearType, an implementation of subpixel font rendering, a topic for which there's another article: subpixel rendering. Gibson's op-ed piece and the comparing-apples-to-oranges shortcoming of his argument are already addressed there (and despite having been a Beagle Bros. Flex Text user in the mid-'80s, I'm inclined to agree Gibson is reaching a bit).

Maybe we could say something about how Microsoft's initial press release about ClearType had some bluster about it being "an unprecedented innovation," but that's the way press releases are. A much better reference about this topic is this New York Times article, which could be simply summarized with a single sentence about how there was debate about whether ClearType was as original as its early hype seemed to imply. However I wouldn't characterize Gibson's piece or the NYT article as criticism of ClearType itself. —mjb (talk) 00:43, 19 January 2009 (UTC)

Good catch, mjb. There's a lot in there, though - what should be incorporated?188.60.14.168 (talk) 16:51, 4 May 2009 (UTC)

Cleartype in Windows XP and Vista

Nowhere in the article it is mentioned that Windows Vista cleartype technology substantially differs from its XP counterpart. It looks likes that MS engineers put a great effort into its improvement, alas, some users argue that XP's cleartype AA looks better than in Windows Vista - the cause of this problem is related to the fact that Vista offers new fonts which don't look like the basic Core fonts for the Web which are used from Windows 98 to Windows 2003 Server. // Artem S. Tashkinov 29 November 2007 —Preceding unsigned comment added by 87.226.226.210 (talk) 15:09, 29 November 2007 (UTC)

On top of that: I am currently using Windows Vista Home and it definitely does not use CLeartype out-of-the box - I just now checked it with a loupe. Thus, that claim is false (How do I switch it on?).

Harald88 (talk) 22:27, 6 January 2008 (UTC)

Strategic ClearType implementation?

MS has implemented ClearType as default in Internet Explorer, but not in Windows. Thus, other browsers do not have the same effect unless users select the ClearType effect in Windows. With the ground Internet Explorer is losing in the market, I have to wonder if this is a strategic effort. M) (talk) 21:54, 29 January 2008 (UTC)

Cleartype *is* the default in the latest version of Windows (Vista), for IE and all other Windows programs, including Firefox, Opera etc. -- simxp (talk) 00:11, 30 January 2008 (UTC)

User Opinion section

I don't think it can meet the Wikipedia standards for references. I will eventually remove this section unless someone finds some statistics to back it up. Linking to some message board posts is not sufficient. Besides, the expert opinions in the "human vision" section already cover the same ground. VasileGaburici (talk) 22:01, 28 August 2008 (UTC)

There are a few papers (Dillon et al, etc...) that show individual preference is a much more important than the presence of ClearType. Plus, hundreds of blogs complaining about how blurry it is. I'm too lazy, but someone should at least mention that there's been a (noisy?) minority of users that get headaches, eyestrain, etc... Google can give examples. 188.60.14.168 (talk) 16:55, 4 May 2009 (UTC)

Cleartype makes my eyes feel like they're being raped. —Preceding unsigned comment added by 85.5.106.209 (talk) 03:33, 9 August 2009 (UTC)

Vertical display orientation

The article section Sensitivity to display orientation states that:

Vertical sub pixel structures are fully supported in . . . Windows Vista (referred to as "Y-direction anti-aliasing" in the section on the Windows Presentation Foundation).

The reference in the Windows Presentation Foundation that I believe was intended to support this claim is to this page. However, that article discusses Y-directional anti-aliasing of horizontally sub-pixellated displays, optimizing redering of horizontally shallow curves on such displays. While Vista may have support for rotated monitors, the reference provided does not give authority for that proposition.

Does anyone have any current information on this?

Bongomatic 02:37, 1 February 2009 (UTC)

People really do use Wikipedia--so incorrect information here propagates. Look at this [forum discussion]. Bongomatic 12:16, 2 February 2009 (UTC)

Headaches

The following line was removed by Bongomatic:

Additionally, some users have reported headaches when using ClearType.

For reasons of being POV and not having reliable sources. I included several sources, to point out this seemed to affect multiple people. Given that the previous sentences cite MS (POV?) or are citationless, I think one sentence mentioning this is not out of line.

ClearType and similar technologies work on the theory that variations in intensity are more noticeable than variations in color. Thus, when ClearType sacrifices color accuracy in order to increase luminance detail, the overall effect—as seen by human eyes—should be an improvement for most people.

According to MSDN website, Microsoft acknowledges that "[t]ext that is rendered with ClearType can also appear significantly different when viewed by individuals with varying levels of color sensitivity. Some individuals can detect slight differences in color better than others."

Any thoughts? 92.105.96.90 (talk) 10:09, 28 October 2009 (UTC)

Additional comments - the MSDN link has at least 4 users specifically commenting on headaches, with others complaining about usability. There is also an official MS solution. There are also various blogs cited mentioning headaches (I *know*), which, while not notable, don't have any particular axe to grind with MS (ie: they are not POV, but are perhaps lack reputability). Is all this not enough to warrant mentioing that "Some users have reported headaches"? 92.105.96.90 (talk) 10:24, 28 October 2009 (UTC)

"Some" in a universe of however many hundreds of millions of Windows users is inherently non-NPOV unless some reliable source reports it as a statistically significant issue. ^Bongo_matic 10:28, 28 October 2009 (UTC)

How about Sheedy 2007 (ClearType sub-pixel text rendering: Preference, legibility and reading performance)? 92.105.96.90 (talk) 10:54, 28 October 2009 (UTC)

What does it say on the topic? ^Bongo_matic 12:28, 28 October 2009 (UTC)

Printers

"Most printers already use such small pixels that aliasing is rarely a problem"

Is there any documentation for that statement?

The HP printer I have uses sub-pixel anti-aliasing. It does it by creating smaller-than full size dots. At a resolution of 1000 dpi, you have large dots in the centre of a letter, and small dots at the edges, so that the edges do not show quantisation errors. — Preceding unsigned comment added by 120.148.53.251 (talk) 04:20, 4 December 2011 (UTC)

In any case, no need to make that claim in an article on ClearType rather than one on subpixel rendering, where it would be on-point. ^Bongo_matic 05:30, 4 December 2011 (UTC)

Microsoft Surface and "ClearType" display

Looks like MS is redefining this: http://jtkuwar.com/446/microsoft-introduced-microsoft-surface-combination-of-tablet-and-pc — Preceding unsigned comment added by 70.74.176.247 (talk) 15:46, 27 June 2012 (UTC)

Copyedit removed.

I removed the copyediting tag, but I take no credit in the July 2013 GOCE drive, as there was nothing to be done.--DThomsen8 (talk) 21:04, 3 July 2013 (UTC)

Do you really think that sentences like "ClearType was invented in the Microsoft e-Books team by Bert Keely and Greg Hitchcock." don't sound awkward? JMP EAX (talk) 10:28, 8 August 2014 (UTC)

I've already changed phrasing like "The hinting expert Beat Stamm" to "Hinting expert Beat Stamm". Not that I have anything against him, but he's probably not the only "hinting expert" on the planet, as the original phrasing might have suggested. And the same goes for another expert cited. JMP EAX (talk) 10:37, 8 August 2014 (UTC)

Stepping

Subpixel AntiAliasing applied to the text "iaQRS@" by two rendering engines. The top one does not support vertical antialiasing, but the bottom one does.

Why doesn't this note the obvious stepping created by the fact that ClearType doesn't support vertical antialiasing, whereas other methods (such as used by Ubuntu, OS X, and Firefox) do both, leading to a much smoother effect? — Supuhstar * — 05:11, 7 July 2013 (UTC)

tags

A lot of the article uses "ClearType" rather generically, and while that may be more or less ok when it's just a stand-in for "subpixel rendering", in many other cases it's not clear about which implementation it is talking about. JMP EAX (talk) 09:47, 8 August 2014 (UTC)

I have done a bit of work to date some of the statements, particularly on the empirical studies cited. But I think a better solution is to diffuse the "ClearType and human vision" section into the implementation ones because specific criticism addresses (and empirical tests were conducted on) specific implementations. It makes no sense for example to cite Stamm about his criticism of some WPF "method C" before the reader is even aware that there are multiple implementations of ClearType and how they might actually differ from each other in technical terms, which is something that the article also does a poor job at explaining as a whole. JMP EAX (talk) 10:17, 8 August 2014 (UTC)

Frankly the whole "How ClearType works" section should probably be deleted. It has zero refs, it's not clear which implementation it is describing, and a detailed expose of the generic concept/idea is much better left to subpixel rendering. JMP EAX (talk) 09:51, 8 August 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on ClearType. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.microsoft.com/iplicensing/productDetail.aspx?productTitle=ClearType

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:57, 30 March 2016 (UTC)

Dropped in Word 2016... seemingly because of performance concerns?

OK, so, riddle me this.

Basically all new computers now have graphics systems *baked into their CPUs*, never mind what they might have present on the peripheral bus, that would make dedicated renderstations of old (like, from the introduction of Win7, and certaintly anything from the initial debut of Cleartype in XP / the plugin version that could be hacked into Win98/ME/2k) give up and lie crying in the corner curled up in the foetal position. They can make amazing 3D worlds that spread across three monitors or appear with subtle differences to each eye in a pair of goggles, and, if you're conservative with the detail settings, truck along at a solid 60 frames per second with no bother. Or if that's not your bag, you can instead hook up to a 3840x2160 HDR/HFR large format TV and play gorgeous high-motion videos without it hardly stressing them at all.

But the act of running a word processor and font engine that, at the core functional level, has changed little in the last QUARTER OF A CENTURY (at which point it was entirely usable on teen-Mhz 386SXes and, theoretically at least, 286s and maybe even 8088s if enough additional memory was installed and therefore, for the purposes of this comparison, can be discounted as the source of any kind of meaningful CPU load, if it's been programmed right), whilst performing local on-the-fly ops to each generated letter that essentially amount to "render at 3x the normal width on a stretched offscreen copy of the underlying page, with low-grade subpixel multisampled anti-aliasing, then copy one colour channel from each pixel in a set of three into the actual screen memory" - not even doing what the OS really should now be capable of, IE drawing everything to that stretched buffer and making a similar decimation-by-thirds copy into screen memory during every Vblank where a "something's changed" flag is set, which would use as much overall VRAM for the buffers at 1920x1080 as would a single-page, non-double-buffered 3840x2160 image (ie about 24mb, which is pocket change these days) and therefore be absolutely no trouble at all - is so punishing to the average computer that Microsoft have had to disable it completely (not even "offer it as a disabled-by-default option for users that want it", nor "monitor system performance at first use and determine whether to use Cleartype or not") in order to maintain a sufficiently smooth-seeming typing experience?!

What. The absolute. Hell.

Come on. Either they are bullshitters of the HIGHEST order, or whoever's working on that bit of the project is an abject failure. If it's not possible to deliver smooth, responsive performance with, say, a 2.4ghz machine at 1080p and 2D cleartype, then it shouldn't have been possible with plain 2D greyscale smoothing at that rez on an 800mhz one. Or at 800x600 with anything less than a 200mhz processor of identical processing efficiency and built in graphical complexity.

Which is, to be frank, completely unbelievable. Not least because I got entirely satisfactory, no-lag, smooth-scroll performance from just such a system (eg a PR166 Cyrix, actually running at 133mhz, and with Pentium-equivalent performance closer to 150mhz, limited VRAM, and practically bugger-all effective graphics acceleration beyond the very general) at 1024x768 truecolour with that selfsame 2D greyscale antialiasing, waybackwhen. And any slowdown I've ever encountered with Word hasn't struck me as being in any way due to the rendering engine... at least, not since the last time I used a 486SLC laptop with a plain VGA chipset, clocked down to a storming fast 8mhz (yes, eight... MEGAhertz) for battery saving, from its usual 33. It's been all the ancilliary crap they load onto it outside of the core keyboard-input and letter-drawing functionality, which causes a momentary hiccup even with an SSD and a deeply pregnant pause if you're still using a platter HDD as your system disc, whilst it stops to think about and then load some enormous module from the far, darkest, dusty reaches of the filesystem. Or then has to take thirty seconds dragging what should be a few tens of kilobytes of font data out of the swapfile because you dared present it with the onerous task of turning some of the text from Regular to Bold or Italic. Or changing its colour from black to red (I REALLY can't understand THAT one). What exactly is it even doing that requires so much memory that either it can't afford to immediately load critical things like font variation and colour value data into RAM at startup, or that said data gets dropped into the swapfile (and not only that, but into a swapfile that seems to be so full and fragmented it that clearing some space in RAM for the needed data, then transferring it, appears to be, on a 4GB machine, a trial equivalent to those of Hercules, or maybe that of attempting to run Windows 95 on an 8mb Toshiba Satellite onto which which some idiot has installed DOS Smartdrv and a load of taskbar junk)?!

(scrolling, btw, being something CT really shouldn't interfere with much, as once the glyphs are rendered it should be possible to move them vertically, and with a bit of care horizontally, with no additional system load whatsoever vs any other prerendered bitmap that needs blitting around; OK, anything completely new appearing on screen will need rendering from scratch, but if you can't draw a line or two of text at a decent speed with resolution on the order of what's used in a low end laser printer, in 2017, then you need help... and when they've actually been drawn, all you need to do is make sure to move them, and all the other scrolling elements from the page upwards, by multiples of 1.00000 pixel only, and cache at least a page or two's worth of offscreen content in each direction, at the humongous cost of a megabyte or six... both of which are generally the standard, I believe?)

Why do I get the feeling that it was licensed from someone else - IIRC the original demos weren't Microsoft at all but someone else they then rapidly bought the rights from - and that the license has now expired, or been specifically withdrawn because that person tried an Office 2016 beta and thought it was a rancid pile of dingo's kidneys, and they're a little bit hamstrung until they can come up with their own version of the idea that doesn't use any of the prior art they've been leveraging for the last 18+ years?

2010s computer not able to render typed text with subpixel smoothing fast enough to avoid the resultant motion looking choppy. Come on, pull the other one, it's got bells on.

(I'll tell you what IS choppy - a Windows 10 tablet with only 1GB of RAM installed. What idiot thought that was a good idea? It should be a framed example hung up in the school of How To Ruin An Otherwise Perfectly Competent And User Friendly Device, along with the way they've set up the touch controls and the abominations that are Facebook For Windows Tablets (avoid like the plague, use a web browser instead) and the overly heavy-handed OS/Microsoft Account integration that you get no warning about. Give it 2 gigs, fix the touch controls, rewrite from scratch or completely withdraw that app, and viciously assault the very idea of your ability to sign into your own mobile, non-3G-equipped computer being dependent on whether you can get internet access with the sharper end of a heavy duty claw hammer, and it'd be a pretty sweet deal. As is, it's regularly unpleasant for straight up boneheaded reasons, primary of which is that they've managed to create a machine intended for lightweight web browsing / social networking / email / basic document hacking / playing solitaire which is forever hung up being it's continually thrashing the swapfile, on an internal, non-replaceable/upgradable (as is the RAM) SSD that was probably never designed for that kind of intense frequent-overwrite usage and will therefore fall into an early grave along with its host machine. Dammit, Microsoft. You know, maybe the cleartype removal is nothing more than a convoluted attempt to cover over just how unbelievably sluggish some of their hardware products have proven in use...) 193.63.174.254 (talk) 16:58, 15 March 2017 (UTC)

Expired patents

I think the following ClearType patents have expired in 2018-2019: 6188385, 6219025, 6225973, 6239783, 6243070, 6307566, 6393145, 6421054

Two more will expire in July 2019: 6282327, 6624828

At least two patents are valid until 2025: 6973210, 7085412

IANAL, but these can be verified using patent databases and calculators.

2001:14BA:1AFC:72F0:0:0:0:E18 (talk) 01:52, 26 February 2019 (UTC)