Skip Menu |

This queue is for tickets about the Prima CPAN distribution.

Report information
The Basics
Id: 67909
Status: resolved
Priority: 0/
Queue: Prima

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: BMP XHotSpot,YHotSpot
Date: Tue, 03 May 2011 09:45:50 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
While nosing around codec_bmp.c I saw } else { /* Windows */ ... word xHotspot = 0; word yHotspot = 0; I think those variables might shadow the ones picked out by pget_i() earlier in the func, so writing zero always. Is that intentional? I noticed also xpm/xbm has "hotSpotX" but the bmp has "XHotSpot". Is there meant to be a common name for the hotspot, when it exists, among the codecs?
thanks, fixed! btw hotspot names weren't meant to be same across codecs, they were rather meant to reflect file format API known to a programmer, but in this case I renamed windows properties anyway
Subject: Re: [rt.cpan.org #67909] BMP XHotSpot,YHotSpot
Date: Sat, 14 May 2011 11:44:43 +1000
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > hotspot names weren't meant to be same across codecs, > they were rather meant to reflect file format API known to a programmer, > but in this case I renamed windows properties anyway
Beaut. It's good to have the same name for something with the same purpose, for a little bit of generic-ness in a save call. You can pass hotspot values and if the format knows them it can use them. Conversely a different name for a different thing is good too. There's an irritating bit in gdk-pixbuf where a "compression" parameter has completely different meanings between png or tiff :-(. -- Some people say cricket is like watching grass grow. That's not true, it's like watching grass die as the wicket turns into a dust bowl.