Slashdot Mirror
Mozilla M16 Gets Alpha Channels
Snorfle writes: "In the recent Mozilla status update, there's a mention that real 8-bit alpha-channel support went quietly into Mozilla last week. Web-publishing types have been crying for this feature, provided principally through (royalty free!) PNG, though other alpha-capable formats will work too." All I want now is anti-aliased fonts for christmas.
Well.. unfortunately it's not that simple any more. Although the European Patent Convention specifically excludes software from being treated as a patentable 'invention', the European Patent Office ruled that this didn't mean what it said, and computer programs can be patented after all. It just goes to show that patent offices will try as hard as they can to increase what is patentable, without concern for whether such patentability is desirable. The EPO seems no more trustworthy than the USPTO. Following the EPO's decision, the UK patent office has revised its practice on software patents.
Anyway, it is still not certain whether such patents granted are actually enforceable. The European Commission are considering changing the law to catch up with the EPO's behaviour, so that software patents will become officially permitted (rather than de facto permitted as at present). Until then it isn't certain whether a lawsuit based on a European software patent would succeed (IANAL); big companies such as IBM are however stocking up on software patents in the hope of one day being able to use them. (Have a look at freepatents.org for more about stopping this from happening.)
Unisys claim to have a patent on LZW in several European countries, including the UK. I don't know whether they've actually tried to shake down British companies for money though. But you may not be as safe as you think.
-- Ed Avis ed@membled.com
There is a mixture of PNG and JPEG called JNG which is supposed to support JPEG compression and an alpha channel. But a short search on the PNG homepage didn't bring any results for me. Maybe if you use a search engine.
In theory, one can simply add an alpha channel to a JPEG file (a second channel for a grayscale or a fourth for a YCbCr color image) -- there is just no software that supports this. The JPEG standard also doesn't say anything about color spaces... Maybe one could wrap the alpha channel into a custom marker. This all makes sense only if it is standardized in some way (so that all major applications support it), which is a very painful and long process. But JPEG2000 is on the way, maybe it adds transparency support of some kind.
I also know Kodak Flashpix, which uses JPEG compression, I don't know about alpha channel support.
True font anti-aliasing (as opposed to just gaussain blurring the edges of the font slightly, like windoze...) requires, at some level, an abstraction similar to an alpha channe.
One simple (but imperfect -doesn't give enough attention to the destination image) implementation is (for monochrome fonts -colour fonts would require a colour alpha channel):
an outline font is rasterised at high resolution, then this black+white high-res rasterisation is reduced to, say, a 16-level geryscale bitmap - which is used, somewhat like an alpha channel, to place the letter image on the screen
eg. (somewhat contrived squat N shape -I
can't be arsed doing any more manually) :
High-res B/W rasterisation
00 00 00 00 00 00 00 00
00 11 11 00 00 01 11 10
00 11 11 11 00 00 11 10
00 11 10 11 10 00 11 10
00 11 10 01 11 00 11 10
00 11 10 00 11 10 11 10
00 11 10 00 00 11 11 10
00 11 11 00 00 01 11 10
Lower res 4-greyscale image:
02200121
04341042
04214142
04300342
This would then be merged, by
whatever method gives a decent result (here
a simple capped addition is used, more complex
formula would give clearer result..),
with the destination image, which is, for
simplicity, here also a gresycale...
Dest, Dest,
before: after:
01100200 03300321
10100010 14441042
00200000 04414142
02110110 04410442
Prior to the actual milestone release, Mozilla tends to say that they are adding to "Mx" even though that milestone may not be ready for a while. M16 is supposed to be done by the end of next week, but who knows...
~luge
IAAL,BIANLY
I would assume that the editor was referring to X11 also. Antialiased fonts on the GTK caanvas object are fine, yes, but the caanvas object does little to improve font appearance in Qt. :^) There has been a recent proposal to add antialiasing to X11, among other things. This to me is The Right Thing To Do(TM). As a consequence of the antialiasing you refer to being GTK-specific, this does little for Mozilla (or at least pure Mozilla). Mozilla moved from GTK to a platform-independent-ish toolkit a while back. :^(
Most computerized images have 3 'channels' (red, green and blue). The alpha-channel is an extra channel of information, usually used for transparency information, so this means that images can have 256 levels of transparency in them, instead of the 2 that GIF uses.
I'm not really concerned about polka-dotted scrollbars either, but there are some other areas where platform widgets tend to fall down (especially current GTK, as it turns out), and some of those are pretty important. Things like variable opacity for input widgets (this whole article is about variable-alpha, right?) and support for mixed font sets in input widgets (key for decent i18n support). The GTK i18n stuff is being improved dramatically by the Pango project, but it's not ready to deploy yet.
Pluggable toolkit support is broken in M16, but will be repaired, and it then might be possible for you to build your own libwidget_darchmare.so that uses all-native stuff. I'm not really expert on the widget-construction code.
Antialiasing font rendering is something that has existed in at least Freetype for some time. However, antialiasing is fairly worthless without decent fonts to begin with. Microsoft and Apple both have manually hinted fonts which have been adjusted to look their best at the most common point sizes. There are very few people on this planet which can do a really good job manually hinting fonts and it's a very long process.
Fonts are one of those things which have very interest protections under the law. You can legally copy underlining font outline out of a font without violating any copyright laws, however the hinting is actually a set of assembly-like instructions embedded into the font which are covered under US law.
Until someone sits down and spends a year manually hinting things like Arial/Helvitica and open sources the hinting instructions, other OS's are doomed to deal with overly thick verticals, misaligned letters and misshaped ovals.
Of course, someone who really wants to be clever can install FreeType (with the old hinting engine which will process the manual hinting correctly) under Windows and create a program which evolves your own font's hinting until the output looks like the Microsoft font output at various sizes w/o aliasing turned on. The basic idea is you render the 'M' at size 36 from Times New Roman with FreeType then you import the outline into your own font file and continually change the hinting instructions until your 'M' and the Times New Roman 'M' are the same when compared pixel by pixel. You wouldn't be copying the hinting instructions, you'd be creating your own and automating the process of checking it against the original.
That would make an interesting PhD thesis.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Maybe it can, but I just took a screen grab and
inspected it real close - and no antialiasing was evident.
There is no standard way of doing font antialiasing in X - and I suspect that the way the Gtk-antialiasing works is rather high-bandwidth, andonly works with certain outline fonts, although I haven't looked into it - I suspect it renders the glypghs with an internal library, and sends them as full bitmaps - rather intensive...
The KDE crowd are proposing an extension to the X server to handle Font antialiasing, rather like GLX or DPS, but many existing applications would have to be recoded to take advantage of it (although applications using only Qt or Gtk calls should be fine, since that's another layer of abstraction)
Why? Because in the standard X protocol, font glyphs are defined as 1-plane bitmaps. Black and White. Any antialiasing done to them at that stage just blurs the font a bit - to do proper font antialiasing, you have to produce a multi-level brightness map of the font, and merge it with the existing graphics - i.e. it has to be a two-way interaction for true antialiasing. The current X protocol makes no provsion for that, so a protocol extension would be necessary. Another thing - make provision for multicolor fonts in the protocol extension, guys! (i.e. do _colour_ antialiasing on colour outline fonts (there aren't many yet (epson supply a few with their printers), but they exist).
One other thing - I just downloaded the latest linux nightly build, and it really flies compared to earlier builds (I'm posting form it right now...), and renders 200+ comment slashdot in nested mode in a fraction of a second...