On Mon, Jan 19, 2009 at 10:27:17PM +1000, Andrew Roach wrote: > > >I've pinned down the problem, but I'm not quite sure why the code is > >written the way it is. > > > >The problem arises in src/plfreetype.c in FT_PlotChar. There are two > >different code paths depending on whether the pixel mode is mono (i.e. > >no anti-aliasing) or not. However, the first path is also taken if icol0 > >= 0, i.e. the background colour. I can't quite see the logic for this. > >Normally is is not a problem since you wouldn't display text in the > >background colour. Example 24 however plots 4 coloured bands so you > >can't see the background, then switches to the background colour to > >print the text. The crazy fonts arise because the code assumes a mono > >font - i.e. each pixel is represented by one bit. This is not the case > >for the anti-aliased text in the background colour. I've just commented > >out this special case for icol0 = 0. I don't quite see why it was > >there in the first place. This fixes example 24. Perhaps someone better > >familiar with the freetype code could say why this was done originally? > > My recollection, late at night and a few years down the track, is that with > the "original anti-aliasing technique" (i.e. not the "BLENDED ANTIALIASING" > which 24bit supports, but the ugly anti-aliasing which also works with > 8bit), when the text colour had an index of "0", there were either > infrequent division by zero errors or some distracting psychedelic > anti-aliasing effects/artifacts. I can not remember which for sure, but > regardless dropping background coloured text back to non-antialiasing was > the quick way to fix the problem which had minimal impact since drawing > text with the background colour was virtually never done. In short, it was > a quick "design compromise" to fit the original simplistic code used for > anti-alaising when working with limited colours like 8 bit palettes used by > GIFs or the lower-resolution drivers of the day.
Andrew, This makes sense, except that the quick-fix doesn't actually work because the freetype bitmap is not 1-bit. This could probably be fixed, but it may no longer be necessary in all cases anyway from what you say. Anti-aliasing doesn't work well with GIF's anyway for several of our examples, even before I made the change. A quick run of ctest on the png and gif drivers gives no division by zeros and the results for png at least look fine. Gif looks no worse. I am tempted to suggest turning off smoothing by default for 8-bit devices. We've already done this in the test suite for gif, but we could actually do it in the driver code. If you really want it you can still turn it on. An example where things go wrong with anti-aliasing on is example 2 (where a lot of colours are used anyway, so there are not enough left for anti-aliasing.) Andrew ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
