Slashdot Mirror
Anti-Aliased Text in X11 Continued
keithp sent in a bit more information about the Font stuff we mentioned yesterday. Besides a nice shot of
twm & xterm, Keith sent us proof in the form of a screenshot with
Konqueror, the KDE web browser. He also says "Most of this code is in XFree86 CVS today. The hacked Tk and Qt
libraries will be available in source form soon. Expect the latter to change; they were pretty seriously whacked.
All of the text is rendered with the fine FreeType 2 library
using 256 levels of translucency and composited to the screen
using hardware acceleration at around 200000 glyphs/sec. If
performance becomes an issue, I'm sure we can improve that.
These images are regular anti-aliased images not optimized for any particular sub-pixel geometry. With a single X resource change,
the text would be rasterized to improve quality for LCD screens
as seen here."
Now I'm just waiting for mozilla to support this.
6.54 bogomips, whee, 1 day kernel compiles :)
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
How are you measuring RAM? I would guess that you're just looking at what the monitors in Windows and Linux (such as provided from /proc via top or ps) are telling you. I have no idea how the Window's memory monitor (it does come with one, yes?) measures things, but /proc includes the frame buffer on your 64MB super-duper video card.
-Paul Komarek
If you have processor power enough to get good interactive performance with aa fonts, then yes it is worth it. If you don't have the processor power, then no, it is not worth it.
It will not affect non-interactive performance, like compiling, and since most Unix application are non-interactive, it doesn't really matter to them.
It is still worse than non-antialiased TrueType courier fonts under Windows. Look at the s'es, and the progressively worse white-on-black status bar.
This and courier is one of the better fonts under X. Try Times New Roman in an X-application.
Most of what people appear to be saying is that if you increase the screen resolution enough, and recompile the programs, suffer a performance hit then antialias, you can shrink the screen fonts and they'll be reasonable.
When you're using a 100+dpi screen with antialiasing, you approach the quality of a 150dpi printer. Isn't printing what the fonts were designed for?
By the time X gets antialiasing and reasonable fonts, we'll all be using 200dpi flatpanels, and it won't matter anymore.
This mail message to "gtk-devel" from Owen Taylor" says
(presumably meaning in the main CVS branch; i.e., it'll eventually be in 2.0, but probably not 1.2[.x]).
But why the hell can't they fix the existing Xlib calls to do antialiasing!
Certainly, add new and intelligent interfaces to draw text. But there is no excuse for not changing the existing interface to make it's output as nice as possible. Without that, all existing X programs will still produce ugly text.
And I don't give a s**t about back compatability. I know it won't color in the exact same pixels, but anybody who wrote a program that relied on that is an idiot anyway! I also don't care about this working on non-TrueColor visuals, those should have been eliminated long ago as well.
Besides coming out with antialiased text SIX YEARS AGO, MicroSoft modified their existing code so older programs got antialiased text. The fact that XFree86 seems incapable of doing the same thing is an insult to the entire Linux industry!
Your O2 did not do antialiasing. Perhaps you had a better monitor, or perhaps a better font? The very small bitmap fonts on Irix were pretty good, but they can easily be copied to another X server.
ClearType is actually a clever idea, but it is not a complex idea. The best ideas often are.
Hey: A CRT version of ClearType could be done if there was a percise way to set where the colored phosphers are in relation to the pixels, too. Perhaps a program could be used which displayed patterns and the user adjusted knobs to make those patterns as brightly colored as possible and this was used to figure the phospher position and pitch. This idea is (C)2000 ME and may not be used in commercial software by companies whose name starts with 'M'.
The steps are not Mach banding. Mach banding is the eye/brain detecting non-continuous first derivatives in a scene and making the appear to be an "edge" (since they probably are a corner in a real-world scene).
I am talking about non-continuous levels themselves (ie not the derivative). The human eye can detect these obviously, but if the two levels are close enough together it is very hard. Ideally all the steps in the gray ramp (255 of them for an 8-bit display) should be equally hard to see. This requires a logarithimic mapping from the integers to the light levels.
The reason the display on this monitor and the real world would look "identical" is that the mapping from the real-world light levels to the numbers stored in the image file is not linear either, instead it is the inverse of the monitor.
I am well aware that the human response is logarithmic and the monitor is exponential plus a constant, and that it is impossible to make these curves match exactly. However they match far better than a straight line!
But you don't want to change the DAC converters, because adjusting the monitor to be "linear" would spread the samples at the dark end out so much that the steps between them would be easily visible, while compressing the samples at the white end so close together that thye cannot be distinguished, thus wasting a lot of your intensity resolution up there.
An unadjusted monitor, through fortunate circumstances, very closely matches the non-linear response of the human eye.
There has been a long and sad history of people thinking the monitor has to be linear to be "correct", espeically in the Mac area (where they built-in a gamma correction in the software of about 1.7) and in SGI's which were often set to corrections of 2.5 or more. This was all wrong and we are finally getting away from it.
The linear/logarithmic/gamma curve I am talking about is a plot from "number put into the display buffer" (called x here, and normalized so 0.0 is the smallest number in the buffer, and 1.0 is the largest number), and the "intensity of light emmitted by the screen" (called y here, and normalized so that 1.0 is maximum the screen + d:a converters produce, and 0.0 is the minimum).
"Linear" in my terminolgy means y = x.
"Gamma" means y = pow(x,G)
"Logarithimic" means y = pow(B,x-1)
The display buffer can only store discreet values, the difference between them is Dx (1/255 for an 8-bit buffer). This will produce descreet steps in the output intensity, the size of these is (approximately) dy/dx * Dx.
My argument is that the best use of this display buffer and hardware is if the perceived steps in output intensity are about equal. This is the only way to minimize the noticability of the steps everywhere.
It is pretty well established that the perceived difference in intensity is a ratio or (y+Dy)/y-1 or Dy/y.
Setting Dy/y to a constant means that dy/dx/y = c or dy/dx = y*C. This is the derivative of a logarithmic curve, which is why I say that a logarithmic curve is the ideal way to map the values in a display buffer to display intensities.
CRT monitors naturally map the voltage level through a gamma curve to the screen intensity, this gamma exponent G is about 1.8. I also propose that this gamma curve, though not equal, is quite close to a logarithimic curve (try drawing both of them in the range 0-1), and certainly MUCH MUCH better than a straight line plotted by a linear function.
Mach banding:
My understanding of the term "Mach banding" is the perception of an "edge" caused by the eye and brain amplifying discontinuities in the first derivative of the intensity across the scene, event though the value is continuous. What I think we are talking about is a discontinuous value, or step in intensity. I have never heard the term "Mach banding" applied to this.
CCD's
Yes CCD's are linear, but you will find that the circuitly in all digital cameras forces that linear output through a lookup table to convert it to a nonlinear value. This is necessary for compatability with all existing binary data formats which are based on binary values that are passed through a gamma function before producing output intensities.
Logarithimic matching exponential
Of course these don't match outside the 0-1 range, but since the monitor is physically incapable of producing these intensities anyway, it does not matter! I know perfectly well that the eye has greater dynamic range than the monitor, though it is not as great as you say if you discount the ability of the iris to reduce/increase exposure, in fact it is only about 1000:1. Inside the 0-1 range I think you will find that the gamma curve matches the exponent much better than a straight line, it is at least curved in the right direction!
References:
Digital Video and HDTV: Pixels, Pictures, and Perception, published by John Wiley & Sons in July, 2000.
Also check Siggraph course notes for Charles Poyntons introduction to color science and color management. It was course # 21 in the New Orleans 2000 Siggraph, but he has done the same course every year for awhile now.
I totally agree that proper anti-aliasing and other compositing operators must be done in linear space, where the numerical values are equal to the light intensity multiplied by a constant. In my own work I use floating point numbers for this. This is important, as the intensity resolution must be much smaller near zero than away from it, floating point naturally does this, while using integers or fixed point results in huge waste of resolution at the bright end while making huge noticable steps at the black end. All cgi rendering programs work this way, I am working on fixing compositing software to work this way as well.
However, when I take that floating point number and put it into an 8-bit display buffer, I fully expect to "gamma correct" it, rather than do something simple like rint(x*255). (cheap or old cgi rendering software like still does this, completly ruining the realism of the result).
I was under the impression that you were arguing that the circuitry (D/A converter and display device) should be designed such that the output intensity is a constant multiplied by the value stored in the display buffer. As you seem to have a lot of knowledge about this, I must assumme that you are well aware that this is a very inefficient way to use the 8 bits. Ideally those 8-bit numbers should be used in a formula like pow(B,(x/255)-1) to get the intensity displayed on the screen, to get the limited number of intensities as evenly distributed across the "perceptual" scale, which is approximately logarithmic.
Further confusion is that the default behavior of a CRT screen and a linear D/A converter happens to be very close to the ideal for human vision, the gamma curve just happens to be the right power value so that it can be scaled to closely fit the log curve of human vision over the 100:1 or so range of intensities a CRT can display. This was entirely coincidental as it was not a design decision when television was developed.
Because of this coincidence, a good way to improve the display of an 8-bit buffer is to do nothing to the bits before sending them to the screen, this of course conflicts with the assuption that doing something complicated would be better.
Although I think it is stamped out now, around 1990-1994 or so there was a lot of belief that something complicated had to be done between the 8 bits and the CRT, so that nothing complicated had to be done when converting the floating point linear value to 8 bits. This resulted in people trying to "linearize" the monitors, such as the 1.7 gamma still built into Macintoshes, and the SGI software that set the gamma up as high as 2.5, both of these result in horrible banding in the dark areas. People then tried to solve this problem by raising the number of bits, first to 12, and then to 16, trying to get rid of the black banding. Though the extra bits are nice, they are still using them very inefficiently, 16 bits linear just equals the quality of an 8-bit 2.0 gamma display (the step between the bottom two entries is equal), while those same 16 bits used with gamma could give you 256 times as many gray levels!
I have only seen consumer CCD cameras so you may be talking about the internal circuitry or professional equipment, but certainly by the time they output a jpeg image for your photo cd, they have gamma-corrected the image. If they had not done so the display on a home pc through a non-correcting image viewer would be extremely dark. I agree that the CCD itself produces linear response. Also even the first tube cameras required adjustment circuitry, because even though they produced a gamma response, it was a different gamma than the television screens, and the engineers decided (for obvious reasons) to put the expensive adjustment circuitry in the camera rather than in every tv set.
On the eye, I was talking about the reception range of an individual cell, or two adjacent cells, simultaneously, you report this range as 100:1, though I have heard more. You are right that the cells as well as the pupil adjust, I did not know that the cells adjustment is far greater than the pupil, that is pretty interesting. However for our purposes, since all the pixels on the screen are being examined simultaneously, the range of the CRT is approaching that of the eye. My own believe is that we need to get it up to 10000:1 or so before truly realistic scenes can be displayed, as the eye adjusting to look in dark areas is quite natural and we need to stimulate that somewhat to get a fully natural feel.
Actually, I'm not talking about hinting. Hinting is another possible solution to the same problem. The one I'm talking about is having a set of fonts specifically for screens. The fonts that M$ created are only being used in a few applications, I believe, and aren't widely known (I don't know their names). But this is definitely different than hinting. Hinting modifies the display of _existing_ fonts, it does not create new ones.
Engineering and the Ultimate
...is there a way that programs will automatically render anti-aliased text, or will they have to specifically call the FreeType libraries?
-- We live in a world where lemonade is artificial and soap has real lemon.
It would be okay (with me :) if the renderer performed the correct calculation using the host's CPU instead of the wrong calculation using the display adapter's CPU. If you can turn it off, you'll make the people with slow CPUs happy as well.
The higher your resolution gets, the more pretty anti-aliasing gets... At very low resolutions it can make unreadable text readable, but it does look blurry. At middling resolutions it doesn't really improve the readability much and it certainly makes the text look blurry. At high resolutions (where even the heavily anti-aliased portions of a line have a solid center) it looks FINE.
I'm waiting very impatiently for some decent anti-aliasing.
One thing to keep in mind is that (at least IMHO) the anti-aliasing in Windows, MacOS, etc. SUCKS. Please don't base your opinion of anti-aliasing off these... Grab a FreeType library and play with the included demos, or check out the anti-aliasing in BeOS or QNX if you want to see some pretty anti-aliasing. The quality of the implementation can obviously make a big difference...
Ethan
Cheers,
It's not really fair to compare verdana to a serif font.
I'm curious as to why I should hold this with any higher regard than any other opinion piece.
Near as I can tell, he's just a programmer that doesn't like the way antialiasing looks, and
happened to write a rant about why he dislikes it...
While I appreciate a good rant, I don't see this article as being anything more than a rant.
--K
---
About goddamn time X started getting more advanced graphics features, like alpha channels and such.
;)
These features are needed in a modern graphics system.
I'm sick of people bitching about how much memory
or processor an alpha channel or AA will use - it's optional.
If it bogs down your P133, the solution is simple - don't run it.
No one is forcing this on you, and work like this
is definately not a waste of time.
Maybe now it won't be such a shock going from OSX to X...
--K
---
[...] but at a low resolution like 640x480 (or even 800x600), it looks like barf. [...]
And I use those resolutions for what? Gaming?
Before you flame me, keep in mind one thing: Autodesk has not and most likely will not implement anti-aliasing in AutoCAD.
So what? The things I do most involve text and raster graphics.
It really doens't matter what's best for CAD guys - I'm not one of them.
Not to mention line algorithms on bitmap displays are naturally lossy due to downsampling...
Don't like antialiasing? Don't use it and quit bitching.
--K
Don't mind me, I like feeding the trolls.
---
--Ben
Hmmmm. I pulled up the Konqueror snapshot of the KDE.org homepage with all this cool antialiased stuff displayed (the link provided in the article). I then pulled up the same page in my nightly build of mozilla and put the two side by side. Couldn't tell a difference. If anything, the mozilla version rendered better especially with regards to links. What have I missed here? I'm sure antialiased text support in X is pretty cool, but that particular screen shot sure doesn't show it off much to me. Anybody got a shot that actually shows what a difference one might see?
Some good technical information on exactly what sub-pixel rasterizing and ClearType is all about can be found here [Steve Gibson's Website]. (I like it because it shows that Microsoft is once again reinventing the wheel and calling it "new". :))
d ge /6664/ClearType.html">Ron
The problem is that when it comes to ClearType, Steve Gibson doesn't have a frickin' clue. If you'd like to see someone who does, try reading A
href="http://www.geocities.com/SiliconValley/Ri
Feigenblatt's website for a more balanced (and informed) view on this.
And here's what the Microsoft Research team has to say about what ClearType actually is -- be warned, except for the first link, it's highly technical:
Brief
overview
IEEE
paper on the technology
Paper for the
Society for Information Display Symposium
Try reading those. Gibson
literally does not know what he's talking about here. For a start, what the
Apple II does is NOT sub-pixel rendering. It's not even pixel-color splitting,
as all the color splitting occurs in the NTSC signal, not at the phosphor level
(you'll see more than one green phosphor per green pixel).
Simon
Coming soon - pyrogyra
They are for print... I beive tthat fonts were originally designed for use on paper, not monitors. While it may look better on the screen because of high resolutions and such, it is a bit misrepresenting of fonts if you would change them on the screen and not on paper.
That's what hinting algorithms are for -- to bridge the gap.
Simon
Coming soon - pyrogyra
If you don't use them already, I strongly recommend you the JMK fonts for X: they provide simply the best looking monospaced fonts (expecially "neep" 18 points) a developer could ever desire for his editor.
Now, if only I were able to convert them into something usable also on Windows... suggestions?
I'm old enough to remember when discussions on Slashdot were well informed.
http://www.xfree86.org/~keithp/render/translucent. png
Most people posting here haven't the first clue about anti-aliasing. AA is a DSP technique which band-limits a signal prior to sampling in order for it to be faithfully reconstructed. If this is not done the higher-frequency components "wrap around". For instance, if you sample a sound signal at 20 kHz, then you must remove all frequency components above 10 kHz (assuming perfect roll-off). If (say) a 12 kHz signal was present it would appear to be an 8 kHz signal in your digital representation of the waveform. The alias is NOT supposed to be there. It's called the Nyquist sampling theorem. One use of this is in downsampling - where you take a signal originally sampled at one frequency and generate samples at another lower frequency. To do this by an integral amount (e.g. downsample by factor of N) you firstly band-limit the signal via a digital filter to at most half of your new sampling rate, then take every Nth sample. If you wish to change to (say) 2/3 of the sampling rate you need to upsample by two and downsample by 3 (upsampling is a bit different and not all that relevant). Now, the same applies to 2-D (and 3-D) signals as well. If you are trying to view (e.g.) a 600 dpi image on a 100 dpi monitor, you are in effect down-sampling. If you wish to see what is really there (to the best ability of your display) then you MUST anti-alias. To not do so is to see artifacts which are NOT present in the original signal (remember the example of the apparently 8 kHz signal! It's not really there!). The only issue is the attributes of the anti-aliasing filter (roll-off, ripple etc.). This depends on the size and type of digital filter you choose - bigger and more complex digital filters may give better quality but be slower to execute. If you are complaining about "blurring" at some chunky coarse resolution, it's not the anti-aliasing, it's the poor resolution. The anti-aliasing is helping you. - Daniel
I'm not sure why you need Konqueror since you assert later on that you need Netscape 6. XFree86 4 is, in my experience, slimmer and faster than it's
ancestors. You do not need it for 3D support, but it makes it a lot easier. I don't see why it is a negative in the first place though. Anyway, why do you
need 3d support on a server? You don't use 3dfx administration tools do you?
>>>>>>>
I'm talking about the desktop.
If you never use them, then why do you need them?
>>>>>>
Because Linux kernel config required TK.
My servers don't need Tk, they don't even need X11. Additionally, if you are not using them, they only
take up disk space, and minimal disk space at that. The Ncurses library takes up less than 500k on my installation. Even if you have Tk 8.0, 8.2, and 8.3
installed for backwards compatability it still only takes up under 6 megabytes of disk space. If you don't use them, they do not consume RAM at all.
>>>>>>
But it's ugly. Having a library around just for one program is ass-ugly.
Another good example would be my workstation at work. It runs Gnome libraries, KDE libraries, everything you listed and more. The total running RAM
usage of that machine hovers around 20-30 megabytes, and that is using Enlightenment as my windowmanager, hardly a slim example! I figure why not,
everything else is using such a small amount of memory and I have 128 floating around to use.
>>>>>>
I have no clue how. According to ktop, my memory usage hovers at 50MB while I'm in KDE 2.0, just after having run a GNOME app.
It sounds like you are trying to compare NT 4 with Linux as a desktop solution.
>>>>
Yea, I thought I made that sufficiantly clear!
Interesting comparison, using server operating systems to do so. Why not throw OS/390 in there, why not IRIX, why stop with those two. Why not Solaris? It would be ridiculous to try and compare these for how well they play Unreal Tournament, don't you think? So why are you comparing NT4 with Linux on those grounds?
>>>>>>>
Linux IS a server OS, but I get flamed whenever I say that. Linux is a wanabee desktop OS that just isn't there yet. Have you taken a look outside slackware land lately? Everyone is trying to cram Linux into the desktop.
But even given that your entire premise has some sort of twisted merit, a lot of your generalizations and assumptions are faulty. Such as needing bleeding
edge browsers and extensive component architectures. For some setups sure, they might be a necessity, but most of those setups would be better placed on
entirely different operatings systems than either NT4 or Linux.
>>>>>>>>>>
Desktop OSs are incredibly unifrom in many of their needs. A component architecture is nice because it encourages reuse of binary code. If implemented correctly (ie NOT by Microsoft) the idea has a lot of merit. And bleeding edge browsers are an absolute necessity for desktop use, ask any BeOS user.
Just because a feature exists and looks nice, does not mean that you need that feature. Lots of ignorant people point out that MS Word has way more features than any Linux word processor.
>>>>>>
Funny, I always seem to need those features. The problem is, that feature poor stuff is usually aimed at one group of people, and people who have limited, but different needs, are left out.
I would like to ask those people to personally take a survey of everybody in the office, with a checklist on how many of those features are used. Not very many. So what if it has crazy features if you do not need them. The same goes for operating systems, desktop
setups, server setups. Install only what you need! That is what makes Linux nice.
>>>>>>>
I don't need Perl, ZSH, CSH, TK, Python, and 90% of the other stuff that the average Linux distro forces me to install. The problem is that the utility developers think that they are writing applications (they're not, utilities are OS-level apps), and indescriminantly use non-standard libraries.
A deep unwavering belief is a sure sign you're missing something...
Geez, I feel bad. Sorry for being a jackass, I guess I was persnickity that day.
A deep unwavering belief is a sure sign you're missing something...
# make menuconfig :) Or you can go the hardcore way and answer questions one by one at your terminal with only a rudimentary shell. Personally, I prefer menuconfig.
That would make two apps that need it for you.
>>>>>>>>
Yea, I guess I could do that, but I'm running X for a reason. Also, Cygnus's source navigator needs TK, and KDevelop doesn't have as good source browsing yet.
That is your opinion, which is to be respected. Most people in the *NIX world wouldn't agree with you though. Having half a megabyte of libraries isn't that big of a deal at all. What is this single application you have? On my machine there are plenty of applications I use that need ncurses. It is a pretty common library, the typical Linux machine uses it quite a bit.
>>>>>>>>
While my ncurses goes unused (I don't use many console/GUI hybrid apps) I do consider it core functionality, so my mistake if I included it in my list of useless libraries.
No offense, but I see several problems with your setup that could be causing this. One is that you are using ktop to scope your processes.
>>>>>
ktop eats up 20MB of RAM?
Which Gnome application are you running? That makes a big difference. If it is gnote then there is a problem.
>>>>>>>>>
I'm running gnibbles.
If you are going to be running both Gnome and KDE simultaniously, you need to be prepared for the usage fees.
>>>>
I thought Linux was free?
You are running two major system in tandom (and be thankful that you can do that.)
>>>>>>
I'm not
so do not be surprised when it uses a lot of hardware. To be honest with you, once I installed KDE 2 I havn't used Gnome at all. I never thought I would be saying that, but in my opinion KDE 2 surpasses Gnome as far as polish goes. Just my opinion. I don't even use KDE 2 that often, very rarely. Most of my applications do not reside in either the Gnome or KDE realm. I have them there in case I need them, dorment on my hard disk.
>>>>>>
I don't like unneeded things dormant on my harddisk. Second, several GNOME programs are nice, as are several KDE programs. I don't think my setup would be usable without both.
Maybe I should ask what you are defining as a desktop user. I'm a desktop user and I can do 90% of my browsing with lynx. I'm comfortable with the program and it only returns what I need, the information, not the fancy mouse rollovers, flash plugins, and other such glut that serve no
purpose other than to wow the user.
>>>>>
I use Lynx too, before I install X, but a graphical browser is necessary. With all the imagemaps and javascripts, etc, using Lynx is so much less efficient.
I fully realize that the average desktop computer user (in my definition) wouldn't understand or like lynx. I don't suggest the world uses it, however I consider myself to be a desktop user and do not need floating layers on my web pages! So your definition is flawed somewhere.
>>>>>>>>>>>
Not really. You're not an average desktop user, I'd go so far to say that you are in the elite realm of "UNIX grognard." It is silly to think that the mass of people that GNOME and KDE2 are aimed at will use Lynx.
A work in progress would be a much more apt and intelligent way of putting it than 'wanabee.'
>>>>>>>>
Probably
Do recall that the entire desktop movement upon which you are referring to is only two or so years old now. It is very infantile, and to assume that it is going to have every single thing you are used to with the MacOS or even Windows only displays your lack of understanding on the issues here.
>>>>>>>>>>>>>.
That's the problem. I've been using Linux (I only got BeOS a year or two ago) since the Slack 3.5 days. Admittedly its not that old, but this was before KDE and GNOME were ready, before glibc, before WordPerfect was ported. Linux has come a long way since then, but people are acting like it is all ready to take over the desktop market, and the only think keeping people from replacing Windows is the MS's dirty tricks. That's simply not true. At least somebody is willing to admit that Linux isn't nearly as ready for the desktop as everybody pretends.
Funny, I always seem to need those features.
I find that difficult to believe. You actually use every feature of the latest Word versions?
>>>>>>>>
No, I use some of the obscure features that prevent me from using a lot of free word processing packages. If most people use 10% of the features, I use 11%, and that 1% are those features that only MS bothered to put in.
Incidentally you might want to check out StarOffice from Sun. I believe it is open source now, and probably the most feature-full office suite out there under that label. If not, it is free.
>>>>>>>
Good god, I tried StarOffice, worst UI design ever concieved by man. Sadly, I'm happy to see it being ported to BeOS.
Good for you, you happen once again to be in a pretty minute minority. Most people who use Linux do in fact need those applications.
>>>>>
That's the problem. People are trying to push Linux into the group of people who are NOT "Most people who use Linux." These people don't need all this, and app developers shouldn't force them to have these installed. They should code to one set of APIs, and let the user choose what to use. If the user wants Python, the user can use Python. But the app developer should not use it, if there is a standard alternative (Perl) available.
Expecially Perl, in fact some distributions use Perl extensively for their inner workings. Even if you do not personally ever invoke a perl command line, there is a lot of stuff going on behind your back you don't know about that is very likely done with Perl.
>>>>>>>>>
When did I saw Perl was useless? An OS needs a scripting language, and Perl is quite useful. Hell, I even use it on BeOS. But take urpmi, for example. Why does it use Python?
If you really do not need these things, I suggest you switch distributions. If your distribution does not allow you to select what you install and you so irately do not want it, that is. Again, display some adaptability.
>>>>>>>>>>>>>
Why don't the app developers display adaptability? Why use Python when Perl is available?
You can very easily uninstall things you do not need too (again depending on your distribution) so even if the Beginner's Installation puts this stuff on without your knowledge, you can always take it off after install.
>>>>>>>>
I'm not an idiot, I know that. Its the Linux app developers who force me to keep stuff that I could uninstall, want to uninstall, but can't. Are you suggesting I code an urpmi alternative? Or I could switch to Debain and apt, and live with less than bleeding-edge software?
Once again, ncurses, perl, TK, these are most certainly not non-standard libraries (Perl isn't really a library, but you get the point). Whoever told you that does not have a clue what they are talking about. As for Zsh, and Csh, those are shells, not libraries. I don't know any utilities or applications that require those shells to be functional.
>>>>>>>>>
CVS requires csh, and something in either Mandrake or Slackware requires either zsh or ash.
While I agree that neither Perl nor ncurses are non-standard (which is why I didn't say they were) I would say that TK is. readline is. Python is. imlib is. fnlib is. Half the stuff installed on a Linux system is there to satisfy dependencies. That shows in the 500MB minimal, compatible (GNOME + KDE) install.
Okay, my honest opinion after hearing you talk for a bit is that you are maybe a one-year or less user of Linux.
>>>>>>>>
Sorry, been using it (off and on addmitedly) since '96.
You got into it because everybody told you it was cool.
>>>>>
When I started using it, it was still in hacker-land.
The reality is that it is a server OS that has a lot of folks working very hard to get desktop-ish features attached to it in a very short amount of time. I still only recommend Linux to developers, sys admins, and computer hobbiests. I don't try to get everyday gamers and whatnot here yet because it isn't quite ready yet.
>>>>
But it's not being hyped as such.
First impressions are important to some people, and right now it doesn't give a good first impression to somebody who has used Windows their entire life.
>>>>>>>
So why the hell is everybody on Slashdot pretending that their grandmother uses Linux?
The *NIX philosophy hardly resembles the philosophy of Windows users. Even in the way they use GUI applications. You tend to see lots of little apps spread out side by side over multiple virtual screens with X11. This is because over here, people design an application to do a few things, well.
>>>>>>>>>>>
Speaking of philisophy, that USED to be the UNIX philosophy. If you take a look at KDE, GNOME, and half of modern applications, you'll notice that that is not the philosophy anymore. (For example, X does printing. Why does GNOME do printing? Why are KDE and GNOME incomptable? The *NIX way to do it would have a consistant interface, and then let whatever you want fulfil that interface. Kinda like how the text streams provide an interface, and you use whatever you want to manipulate that text stream. The way staight *NIX does it, the way X does it, that's the way to do it. Not the way modern Linux is doing it.
other, and each of these apps are monolithically huge,
>>>>>>>>
Like X, Mozilla, KDE, and GNOME? I just heard GNOME is 4 million lines of code. Not only twice the size of the kernel, but bigger than all of BeOS!
Give it a year, trust me it will impress you more and more as time goes by.
>>>>>>>
I've been waiting for it to impress me since '96.
Continue using NT 4 for your games (Which is in itself absurd, why are you doing that? Why not use Win98ME??)
>>>>>>>>>>
Because NT4 runs OpenGL apps faster, and all the games I have are compatible. That's not even an issue, all I play is Quake3 and CorumIII anyway.
and your MS Word needs, and keep tabs on how the Linux world is growing.
>>>>>>.
90% of my documents are created in BeOS's Gobe productive.
I know the tone of this not is a bit harsh, but your outlook is a common one and needs addressing.
>>>
Really, who else is a rabid BeOS user, likes simplicity, speed, and elegance, admires the philosophy of *NIX but is disguested by its current implementation? (BTW, Quake3 and OpenGL are the only reason why NT is still on my machine)
It is part of the rift between those who have been served by the software giants all their computing life, and those who have been apart of a growing development process.
>>>>>>>>>>
Yahoo! Be is a software giant!
Look, I have nothing against Linux, nothing against *NIX, and I understand the philosophy behind it, I just can't stand the fact that Linux is being sullied by what is currently happening. UNIX was designed to be elegant. In its current state on the desktop, Linux is decidedly NOT.
A deep unwavering belief is a sure sign you're missing something...
Uh, no. BeOS anti-aliases all its fonts, and from two feet away on my 1152x864 display, even the size 10 fonts (which are a little smaller as BeOS tends to render on the small side) are perfectly legible. Its nothing special, QNX does it too.
A deep unwavering belief is a sure sign you're missing something...
What ARE you talking about? A Linux environment comparable to NT4.0 (Linux 2.4, KDE2, GNOME 1.2, and Netscape 6) takes up more RAM than does NT4. Linux may have a lot of advantages but RAM usage (at least from the GUI POV) ain't one of them.
A deep unwavering belief is a sure sign you're missing something...
Mod this up, he has a point. If the render extension uses hardware acceleration to do the alpha blit, then performance is no worse then it would be with regular TrueType fonts.
A deep unwavering belief is a sure sign you're missing something...
You are, in a word, stupid. While you may have it nice and all with your high end 133ppi display, we mere mortals are stuck at 80ppi, and for us, anti-aliased text beats the hell out of anything else out there. If you want to send me one of these 200ppi displays, I'll recant all my statements in favor of anti-aliasing.
A deep unwavering belief is a sure sign you're missing something...
My vid card is a mere 16MB, but I use ktop. With KDE 1.2-only, it gives me around 19-22MB, which is about right. Load Netscape and GNOME (running all popular GUI applications is a critereon here), and switch to KDE 2.0 (for the network and component stuff NT already includes) and it bumps about to 45+MB, which is way beyond NT's 30-something MB, and about on par with Win2K.
A deep unwavering belief is a sure sign you're missing something...
How am I exaggerating? Comparing NT 4.0 to Blackbox or FVWM is stupid. When people say Linux doesn't have XXX feature, they point to KDE2 or GNOME and say, "but it DOES!" when someone points out that Linux is bloated, they say, "so use Blackbox or FVWM!" KDE 2.0, GNOME 1.2 (both, because I need, say, gnometoaster and Konqueror or whatever, mainly because I use apps from both) are necessary because NT already includes component technolgies and other tech found in KDE2 and GNOME. XFree86 4.0 is needed for 3D support, Netscape 6 is needed to compete with IE 5.5, and you need various other libs such as TK and ncurses (which I never use, but exactly ONE important app on the system does) and when you add all these together, you've got a system that easily rivals Win2K in memory usage.
A deep unwavering belief is a sure sign you're missing something...
> Is antiailiased text really worth the extra processor/graphic cycles in most unix applications?
(I'm a long time linux user). Every time I boot linux from using windows, I see how ugly the fonts are. GNOME looks (IMHO) much nicer than windows, but the fonts really suck. I'm coding, so I spend a lot of time looking at text. The sooner this makes it into the distributions the better. First impressions count, and linux fonts just aren't as nice as on windows.
So, I think it's great.
0.02,
Mike.
Tales from behind the Lagom Curtain
Well made observations, but there are of course no rules without exceptions - either way. The biggest problem in X is however, getting good enough fonts. No free distribution packages good fonts simply because the best ones are commercial.
. html
Here's a resource to obtain fonts, free or not:
http://www.linux.org/docs/ldp/howto/Font-HOWTO-10
The easiest way is to just copy fonts from your Windows-partition or CD (if you have Windows at all, but some of them may be downloaded too).
I found this resource good when I did this on Mandrake 7.2 (before I saw the option in DraConfig->fonts to automagically install Windows fonts):
http://www.linuxdoc.org/HOWTO/mini/FDU/index.html
I got this page from this resource (containing alot of links):
http://www.kegel.com/linux/tt.html
Everybody who have Linux should do this. You will not want to barf at your screen again. You will enjoy Linux and browsing web-pages is like browsing with Internet Exploder. That's partly unfortunately since both Nutscrape and Konqueror is just as stable. However, it's free and it's improving alot!
- Steeltoe
http://www.debunkingskeptics.com/
There is only so much anti-aliasing will do to correct bad fonts.
Most of the bad fonts are bitmaps and aren't going to be affected by antialiasing unless they are rescaled bitmaps (excuse me, if you use rescaled bitmaps... I think I'm going to be sick...).
That said, there is no reason to restrict your font habits to truetype ones. Postscript Type 1 fonts can also be rendered well using antialiasing and can also give extremely good results. At the end of the day, the quality of the font on screen is limited by the quality of the hinting done to protect the important features of each glyph from being lost when rendered.
In windows, all of the true type fonts I use look great without anti-aliasing. If you want beautiful fonts in X windows use an X server that supports true type fonts.
Even at tiny point sizes? I doubt it. Antialiasing is good for increasing readability of fonts at all point sizes but especially for small fonts. Without antialiasing, small fonts become a muddle of pixels.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
I've installed the latest CVS code (to get the proper DGA mouse code for Quake 3) and it runs quite well w/nVidia's drivers.
http://linuxquake.com/news?start=20
This link provides some more info on how to install the latest CVS Xfree and get it to work w/nVidia's drivers.
Praying for the end of your wide-awake nightmare.
Is higher resolutions on monitors. I can anti-alias the text into a blur, but (for my eyes anyway) I'd rather see SHARPER text with better contrast. Most monitors are in the range .22 - .25 these days, and I can definatly see a difference between the two. If I undersand it right, anti-aliasing improves the apparent resolution (translation to "readability") of a text glyph. I'd like to see the actual resolution improved. Don't get me wrong, AA is nice and good (and I use it), but lets get those 10K x 10K monitors out the door!
}#q NO CARRIER
How much extra processing does it require? Has anyone measured it?
Talk about bang for the buck; two hours of hacking and I had a browser with anti-aliased text.
Gtk might be as easy, I just haven't looked. Plus, what I wanted was a browser and konqueror is pretty usable for basic browsing.
Windows fonts are already anti-aliased; anti-aliasing is one of the features of TTF that should have been ported to X IMNSHO at least 3-4 years ago. The current XFree server doesn't anti-alias any of the fonts, hence they look blocky. Hopefully, this means that the non Truetype fonts, some of which I love, are anti-aliased too.
Marxism is the opiate of dumbasses
Unless I'm mistaken, Mozilla makes use of Gtk for doing is GUI stuff, right? And does this include the font work? Because, if that's the case, then modifying Gtk to support font anti-aliasing (as was done to Qt to get that Konqueror screenshot we saw) could result in automatic support in Mozilla (not to mention all the other Gtk applications).
This technology is only beneficial in LCD environments with typical filter configurations.
It is a work-around for a rapidly diminishing problem. The requirement for extremely high resolutions to support very fine text rendering.
The economics of LCD displays is very similar to that of RAM chips. There are technical requirements to increase density, but, there are very few cost factors. LCD displays are currently displaying up to 200 PPI and will ultimately display 300+ PPI on consumer displays. This rivals laser quality print, on screen.
Currently available laptops from DELL and IBM display 1600x1200 on 14.x inch displays. This represent 133+ PPI! These displays really don't need sub-pixel rendering. They need scaling.
The problem which really needs to be addressed is scaling on these very high-res displays. Not dumb work-arounds for problems which don't exist. Anti-aliasing is of course always beneficial, but the perceived need for sub-pixel rendering is only being driven by Microsoft's ClearType having resurected an otherwise dead idea. Its appeal rests solely in its apparent cleverness.
I have to agree with the comment about AA on non-Linux systems. When I've turned on the font-smoothing in MacOS it turns all the beautiful system fonts into an illegible mess.
It's goddamn computer. Personally I want all my on-screen text to look like I'm using a computer. I prefer Courier and the even more classic computer type fonts. These are displayed in very clear contrast colors (like black on white) that make it simple to detect the edges of the letters.
The only time anti-aliasing is enjoyable for me is when I'm doing layout in graphics applications, or creating text in a JPG/GIF/PNG.
I do not have a signature
And waiting to go through a major XFree86 upgrade as well, right? X server upgrades are never fun.
Does anybody know if the CVS code with XRender in it is even module binary-compatible with XFree 4.0.1 (for my poor nVidia drivers... sniff)? I'm guessing that this requires some fairly major changes to the guts of X to implement.
Before you flame me, keep in mind one thing: Autodesk has not and most likely will not implement anti-aliasing in AutoCAD. Autodesk sees no reason to implement AA; or at least in the Model view. The key reason for this is because an anti-aliased picture tends to "lie" about its details. Any lies/deceptions/blurriness in CAD drawings can be fatal to a legitimate project.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
That depends entirely on the user and the role of the computer. Me, I like things pretty on my workstations, speedy on my servers; thus, I'd be inclined to take advantage of this on a workstation and ignore it (along with the rest of X, in many cases) for a server.
That said, there are apparently enough people out there that want anti-aliased fonts that they're being added to X, despite the added overhead. This is one of the great strengths of community-driven code: if enough users want something, the issue eventually gets addressed by the developer.
$ man reality
Obliteracy: Words with explosions
Anti-aliasing for black-and-white texts can work but it's worth noting that anti-aliasing of colored text is intrinsically flawed because anti-aliasing of colored texts on colored backgrounds creates linear combinations of two different hues which are perceptually different from the original hues, creating a false dark border next to the text.
To see what I mean, using xmag or xzoom look at the border area between the red text and green background color image of the anti-aliased xterm (4th column, 8th row) on Keith Packard's X rendering page.
Scroogle
Anti-aliasing isn't the only reason that Windows fonts look better than X fonts.
First of all, Win fonts are only antialiased at > 16pts or so, which is almost none of text on my screen. Second, Font Smoothing wasn't even enabled on this default Win2000 install. Third, the standard system font on older versions of Windows (98, NT4) is "MS Sans", which is a non-scalable bitmapped font anyway.
No, Windows fonts look better because they spent more time and effort designing them. Particularly, they heavily use TTF's hinting features to improve screen readability, especially for the web fonts that you can download with IE or from their Truetype page.
So, yeah, anti-aliasing can look pretty slick (especially in the XTerms in the screens), but the first step is still having a good font to render in the first place, which ever Linux install I've seen does not have.
Anti-aliasing and blending could be done using a 3D video card (such as Voodoo or GeoForce) with a X 4.01 DRI driver.
Was it ever tried?
Obvious example is to look at text broadcast on the TV verses the text displayed on the screen by your VCR or cable box. It should be obvious that you can read the TV text at sizes that are far smaller than the box will attempt. This is because the box is not antialiased, while text used by the stations is (especially if it is a video image of a printed piece of text).
I also don't know what AutoCAD is talking about. Antialiased lines are far easier to see than aliased ones, especially if there are many almost-parallel ones at angles slightly off horizontal and vertical. Antialising of thin lines has been done for 25 years in top-of-the-line CAD workstations, despite the extreme (for then) computation overhead. Take a look at any old graphics book.
Yes, dammit! Given that my old Acorn A3000 (based on an 8MHz ARM2, 2MB memory) had anti-aliased fonts switched on by default, and the desktop still flew along nicely (the rendering might have been slow, but the bitmap cache ensured that the desktop was always responsive for a fairly modest outlay of memory). Here's a nice shot of the font rendering. No, I don't use it any more, so I can't possibly be a rabid advocate, but I know from experience that anti-aliasing isn't hard to do efficiently.
Matthew @ Bytemark Hosting
sure, it's great for page layout, but that's why I have a mac.
tcd004 Tired of Election Coverage? How about some UNCOVERAGE?
There is only so much anti-aliasing will do to correct bad fonts.
In windows, all of the true type fonts I use look great without anti-aliasing. If you want beautiful fonts in X windows use an X server that supports true type fonts.
-josh
----
Sure, AA might look beautiful in higher resolutions, but at a low resolution like 640x480 (or even 800x600), it looks like barf.
Total and utter *&^*&^^.. :-)
Antialiasing improves the readability of a font at small sizes. That's why Acorn went to all the trouble of having it in Risc OS back in 1987- when your vertical resolution can be as low as 256 lines or less, keeping the fonts readable as the point size drops below 6 pts is impossible without anti-aliasing. They had this resolution because that was back in the days where people used their tellies as monitors.
Furthermore, some fonts were meant to be shown without anti-aliasing (MS Sans Serif, Times New Roman, and Arial in Windows; I'm sure there's some in X).
Thats because MS still hasn't got it's antialiasing working properly - hence MS 'font smoothing' is an appropriate title. Anti-aliasing is not just about blurring the edges - it is about increasing the apparent resolution of the text by using greyscales - the same way a truecolour phot has a higher apparent resolution than a black-and-white 2 colour image on the same display. Doing it right has a massive effect on the readability of the text on screen. Because MS's implementation doesn't cut it at small point sizes, they tweaked the truetype fonts to render more reliably to the screen instead.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.