"Garry R. Osgood" <[EMAIL PROTECTED]> 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.


> 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

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

Salut, Sven

Reply via email to