IrfanPaint Support Thread

[MItaly]

What do you mean? You don't know what causes it?

I have an idea of what may cause it, but I never spent much time to try to fix it since it's not very important.
---EDIT---
Whoa, it wasn't *that* difficult; just fixed with a single line of code plus one of comment.

	//Set the cancel flag to avoid problems if there is a WM_MOUSEMOVE with MK_LBUTTON without a WM_LBUTTONDOWN (the operations will be ignored)
	cancel=true;

Are you saying it won't be implemented because it would require an overhaul of the programming to make it happen?

See it in this way: in future it may be implemented (but I have to it by hand); the fact that the text tool has already antialiasing is because Windows GDI already provides me the antialiased text function.

[Skippybox]

Right, it's not that important. Like Sjef says, "CTRL+Z and it's gone". Just wondering if it was a simple fix.

Thanks for the explanation. Now that I know it is more difficult for you, it isn't critical.

[Skippybox]

Why was it so easy all of a sudden?

[MItaly]

I didn't remember right; actually I fixed that problem in a pre-0.4.7.50 beta, but after that version I rewrote all the code that manage the UI of the tools, and the bug reappeared. Investigating again on the bug made me remember how I fixed it last time, but this time the fix was a lot easier thanks to the new object-oriented code.

[Skippybox]

Why does the floodfill tool leak outside the confines of a selection box? The paintbrush and eraser do this as well.

β0.4.12.66

[Bhikkhu Pesala]

It doesn't do that here. Maybe a sample image would help, or does it happen always on all images?

[Skippybox]

I think it is different depending on the scenario. Here is a simple 50x50 solid color square. It helps if you zoom in to see what happens. If you use custom selection and make a 48x48 selection at 1,1 then fill it, there will be a leak. You can also easily paint outside this selection, too. Perhaps you understand why this is?

Original file
[ATTACH]993[/ATTACH]

Here are the errors:

[ATTACH]994[/ATTACH][ATTACH]995[/ATTACH]

[Bhikkhu Pesala]

I was able to reproduce the problem. I have no idea why it happens.

[MItaly]

It's always the same old precision problem; IV uses an algorithm to convert screen points to DIB points, IP uses another. I managed to fix it in the next version by making IP draw the image by itself with more precision (and it's also a bit faster), but some problems of this kind are still there.

[Skippybox]

It's always the same old precision problem; IV uses an algorithm to convert screen points to DIB points, IP uses another. I managed to fix it in the next version by making IP draw the image by itself with more precision (and it's also a bit faster), but some problems of this kind are still there.

How do screen points get converted to DIB points? Since zooming in makes many more screen points than image points, how can someone make an accurate selection box with the mouse? Visually, the box will be positioned incorrectly onscreen in relation to the images' pixels, resulting in an error that doesn't exist. Custom selection eliminates this problem, so how do you make the two methods equivalent in placement of the selection?

When is the next version of IP expected?

[impdf]

Toolbar in text tool

Would it be possible to use visual themes for the toolbar icons in the text tool?
All other controls in the tool do, so it looks a little bit strange in the moment...

[Bhikkhu Pesala]

Hirigana and Katikana (Japanese fonts) apparently don't work in IrfanPaint. Are they supposed to? I thought Unicode was supported? Latin Extended Additional works just fine.

Hirigana: ぁあぃいぅ

Katakana: ㄅㄆㄇㄈ

I tried to use the PMingliu font, but got nothing.

[MItaly]

How do screen points get converted to DIB points?

Quite simple (and now that IP draws the image it's also very precise):

//Converts a POINT(S) referred to the IrfanViewer window to a POINT(S) referred to the bitmap
template <class ptType> void IVWnd2DIBPoint(ptType * IVWndPoint)
{
	if(DibSect==NULL)
		return;
	POINT shift=GetShift();
	float zoom=GetZoom();
#pragma warning (push)
#pragma warning (disable:4244)
	IVWndPoint->x=(long)((IVWndPoint->x+shift.x)/(zoom/100.0));
	IVWndPoint->y=(long)((IVWndPoint->y+shift.y)/(zoom/100.0));
#pragma warning (pop)
	return;
};

.
Some time I ago made a try to have better precision leaving to IV the work of drawing, but I had to write something like this:

//Converts a POINT(S) referred to the IrfanViewer window to a POINT(S) referred to the bitmap
template <class ptType> void IVWnd2DIBPoint(ptType * IVWndPoint)
{
	if(shift.x<0)
		IVWndPoint->x+=shift.x;
	if(shift.y<0)
		IVWndPoint->y+=shift.y;
	if(zoom<=100)
	{
		IVWndPoint->x=round(IVWndPoint->x/(zoom/100.0));
		IVWndPoint->y=round(IVWndPoint->y/(zoom/100.0));
	}
	else
	{
		SIZED pxSize=GetDIBPixelSize();
		IVWndPoint->x=IVWndPoint->x/pxSize.cx+0.01; //To avoid that a 0.999999... is considered 0 instead of 1
		IVWndPoint->y=IVWndPoint->y/pxSize.cy+0.01;
	}
	if(shift.x>0)
		IVWndPoint->x+=round(shift.x/(zoom/100.0));
	if(shift.y>0)
		IVWndPoint->y+=round(shift.y/(zoom/100.0));
	return;
};

; and it still wasn't very precise!

When is the next version of IP expected?

Whenever I'll have more time to work on it.

Would it be possible to use visual themes for the toolbar icons in the text tool?
All other controls in the tool do, so it looks a little bit strange in the moment...

It seems to be a limitation of Windows XP: icon-buttons (with the BS_ICON style) for some reason are not themed.

Hirigana and Katikana (Japanese fonts) apparently don't work in IrfanPaint.

For me (with copy-paste from your message) they work (see attachment).

[Bhikkhu Pesala]

No such luck here. If I try to change the font it just goes back to Small Fonts.

[Sam_Zen]

Diff situation here.
Pasting the Hirigana string works, The Katakana string fails.