nice hm... any other way getting this info ? through the printer handle from OpenPrinter ?

hmm...i've searched a bit - is MCI_STATUS what i should be interested in ?

thanx, Roger, i didn't notice anybody replied to the post. i found a solution, check my previous post. i guess your idea is close to what i finally implemented - thanx !

As I mentioned before, it could be your DPI (dots per inch, or PPI for pixels per inch in some other countries/regions). Check your monitor settings. Since you're using pixels for both GraphicsPaths I don't see how this would be a problem, though, so long as you have no form border. The Framework itself is agnostic to the platform (for those classes - like most - that are supported by every Windows platform) so its settings on the machine that are affecting your Form. Without being there on your computer it's hard to say. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]

thank you WideCharToMultiByte is exactly what i used

thank you agan. i decided not to detect if it is unicode programmatically, but still a have a small problem left - when i display unicode string there is some garbage at the beginning of the text (1-2 bytes, "FF FE" usually), any idea how to avoid it? may be i should start reading the file with StreamIn from the first ASCII code ?

thanx, Jörgen i think i found the cause - its actually not the IStream, but the GIF image data inside of it that makes the Image constructor fail. When i exported the GIF image and saved it anew (in acdsee) - the new file is slightly different and Image aquires it without problems. I'll be digging it some more, but its a different matter now :) thanx again see you around

thank you very much thats seems exactly like it