Hi, "Garry R. Osgood" <gosgood@xxxxxxx> writes: > > I can successfully use pepper.gbr. File->Open loads it in just fine > > and I can select the brush in File->Dialogs->Brushes. > > > > FYI, I have no problems with Solaris 8/SPARC nor Tru64 UNIX 4.0D/5.0. > <snipped...> > Just this evening (GMT -5.00) I've observed this phenomenon, on the > same brushes that gave Al problems. Not on the Linux laptop, but on > the SGI O2 and Indigo (Irix 6.5.8 and 6.5.4 respectively). > > I can spend some time isolating it, but not until this weekend. If I don't > obtain resolution, I'll make summary comments in a bug report. I think the problem is that we seek backwards in the file since we try to read in a pattern header after we have read a grayscale brush. This is to remain backward compatibility (something we should probably not have done). If no pattern can be found, we seek back to read the data again as the next brush. Obviously something goes wrong here on some platforms. The best way to solve this problem is most probably to drop backward compatibility in the core. For the plug-in, I can think of a way to avoid the seek, but retain the possibility to read old brushes: Parse the data in the pattern header struct to recreate the brush header from it and continue reading the next brush. I wouldn't want this hack in the core however. The question is: can we afford to drop the backwards compatibility of the core when it comes to read old .gpb and .gih files? And can we do this in the 1.2 branch? Remember: Users can always use the gbr and gih plug-ins to convert old brushes into the new format. Salut, Sven
