Re: [Plplot-devel] Status of release testing
Hi Arjen: The current set of shell scripts for testing have had constant maintenance and improvement as long as I can remember. So I think taking a windows batch file approach to do the same thing would create a substantial maintenance issue that we should avoid if at all possible. So I suggest you try using win-bash instead. As far as I know (but I hope Werner comments further), that is completely supported by our build system. For example, that build system searches for bash in the following way (in plplot.cmake): ... Note that all ctest does is run plplot-test.sh with various options (if you exclude the comparison test as above). That (and a run of test_diff.sh at the end) is exactly what happens at a fundamental level in the install tree as well. That means once you have ctest working for Windows, then the potential exists to get the install-tree tests to work as well on Windows. Of course, in the install tree you would have to find some windows equivalent of the Makefile that organizes all those plplot-test.sh runs with various options, but that is a much smaller maintenance issue then duplicating the detailed functionality of plplot-test.sh. Well, that does sound as a reasonable and little-work solution. As CMake warns about not being able to find bash and therefore ctest won't work, I thought that using MinGW might get me around this problem. But undoubtedly that introduces new ones and it changes the platform in subtle ways. I will have a look at win-bash. Regards, Arjen -- 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
Re: [Plplot-devel] plfreetype smooth=1 bug for example 24
On Fri, Jan 16, 2009 at 10:06:29PM -0800, Alan Irwin wrote: On 2009-01-16 23:43- Andrew Ross wrote: If it is any consolation I can confirm your report on my Ubuntu system. Example 24 has not been updated since mid 2006 other than for a const char * tidy-up. The cookbook in in the example does say to use -drvopt smooth=0 so I suspect this is an old bug. Sorry, my eyes somehow missed that -drvopt smooth=0 in the instructions, but now that I am up to speed on those instructions, I agree it must be a longstanding workaround for a bug since the smooth=1 case works everywhere else we have unicode test. I am still at a loss though as to the cause. Looking in gd.c and plfreetype.c the smooth_text variable appears in very few places - principally in the call to FT_Load_Char. There is nothing obviously wrong to me. Thanks for taking a look. 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? 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
[Plplot-devel] Support only octave 3.0 ?
We've said that we will drop support for octave 2.1.x from this release. Are people really happy for me to go and remove the legacy code which is in place to support this? This would make life easier and also remove some slightly irritating warnings for octave 3.0. Octave 3.0 seems pretty stable now and all distributions for the last year or so that I have been coming with it. In general I don't like removing backwards compatibility, but we have announced that we will do this. 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
Re: [Plplot-devel] plfreetype smooth=1 bug for example 24
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 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
Re: [Plplot-devel] plfreetype smooth=1 bug for example 24
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
Re: [Plplot-devel] Status of release testing
On 2009-01-19 11:01+0100 Werner Smekal wrote: Hi, Well, that does sound as a reasonable and little-work solution. As CMake warns about not being able to find bash and therefore ctest won't work, I thought that using MinGW might get me around this problem. But undoubtedly that introduces new ones and it changes the platform in subtle ways. I will have a look at win-bash. Regards, Arjen We had this discussion already: http://sourceforge.net/mailarchive/forum.php?thread_name=4567655A.7000101%40iap.tuwien.ac.atforum_name=plplot-devel We were (at least) partly successful using one of the bash executables available for Windows (or sh executables, can't remember). You shouldn't use sh.exe since then CMake assumes you are using the MSYS enviroment. In addition to bash/sh you also need some unix tools ported to Windows, which I think you'll find at gnuwin32.sf.net - in comparison to other toolsets available is this project still being worked on, and works very well - I use it all the time. You need to install them, but there will be only a handful of persons who want to test on Windows anyway And I agree to Alan, it's better to use the existing solution and modify it a little bit so that it works on Windows with bash.exe and gnuwin32 tools as well, as trying to write a Windows batch file - the latter one is really limited I tried to code something in the last months and it's really a PIA. Better alternative is kixtart, which is also easy to install, but still we would need to do the work twice. Thanks, Werner, for drawing our attention to that important thread from more than two years ago. I barely remembered it so I read through it again, but it appears you had ctest success back then using the combination of win-bash and gnuwin32.sf.net. I looked at http://gnuwin32.sourceforge.net/packages.html, and it appears they supply both DiffUtils and TextUtils packages. I don't know for sure what is in those packages, but hopefully diff is supplied by the first one and tail by the second one so that we a bit of CMake magic to configure test_diff.sh (which uses both diff and tail) it should be possible to get ctest working again on windows. Would you please follow up on that, and (assuming you have success) write down a clear cookbook in our wiki for Arjen to follow for each of the windows platforms accessible to you? ctest is a really important tool for our developers so I hope you both end up using it on a routine basis. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [Plplot-devel] plfreetype smooth=1 bug for example 24
On 2009-01-19 10:08- Andrew Ross wrote: The [example 24 smooth=1] 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. From this and subsequent posts by you and Andrew Roach it appears you have figured out a solution that works reasonably well in most cases. Thanks! Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [Plplot-devel] Support only octave 3.0 ?
On 2009-01-19 10:12- Andrew Ross wrote: We've said that we will drop support for octave 2.1.x from this release. Actually, as stated in README.release we dropped support for 2.1.x in the 5.9.1 release, but I wanted to leave the notice in for this release and subsequent ones up to and including our next stable release for those users who just skip from one stable release to the next or skip some of the development releases. Are people really happy for me to go and remove the legacy code which is in place to support this? This would make life easier and also remove some slightly irritating warnings for octave 3.0. Octave 3.0 seems pretty stable now and all distributions for the last year or so that I have been coming with it. In general I don't like removing backwards compatibility, but we have announced that we will do this. Go for it. Cruft removal is a good thing to do, and besides the octave download page doesn't even give directions for downloading 2.1.x any more. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
