This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IMFApp Office


>On Wed, 11 Aug 2004, Hans Ronne wrote:
>
>> I noticed this. I would say that what really happens is that those units
>> (not all of them) that have an 8x8 image for some reason is using it at
>> 16x16 magnification, too, instead of scaling down the 32x32 image.
>
>Really? At least in my closeups, it appeared that the top left
>corner of the 44x44 was appearing unscaled, and with the
>transparency colors unsuppressed) in the "16x16" (22x24?) view
>box.

This is an aspect of another problem (failure to scale some images
correctly on the first attempt) that we already discussed for the emblems.
After you click on the image, however, it will be scaled correctly from
32x32 to 16x16. But the 8x8 images override the scaled image at this point,
which they should not do (at least not at 16x16 resolution).

>>I don't
>> think IMFApp is to blame for this, but rather the general image scaling
>> code (best_image) which is used by both Xconq and IMFApp. It is unusal to
>> provide 32x32 and 8x8 images, but not 16x16, so the code may get confused.
>
>Then this is even more bothersome to me, because I would like to
>provide an actual family of images which have distinct images (but
>same name) for each view size, and if the code that handles this
>is used in Xconq, then things could get ugly.

If you provide an entire family you should be safe. It is only if you leave
a hole in the middle that the code apparently gets confused. The fix is
probably trivial, like changing a < to a <=, but I haven't had time to look
into this since I assigned the path-finding bug a higher priority.

Hans



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]