>About 5 years ago we logged an issue with Microsoft as we were able to
recreate the issue in a few lines of code using .NET.
>As I recall they got back to us saying the video drivers were at fault and
it wasn't a problem with Windows or .NET.
> Can you believe it? a Metafile, which is independent of device, is
dependent on the device driver?
I don't know the particular issue, but this can be true. Recording a
metafile only collects the
GDI calls together with their parameters. When playing the metafile, the
recorded API calls will
be performed (and the destination DC will execute the GDI calls).
Many GDI functions rely heavily on the display driver. Without a display
driver GDI is disfunctional.
A DC has a table of functions that will provide the implementation of the
GDI api functions.
If you create a DC without requesting a specific driver it defaults to the
display driver.
My assumption is, that if a device driver does not implement a function, the
default implementation of
the display device driver is used. So even if your destination DC is a
printer, it may be that functions
of the display device will be used. This may be specific to the printer
driver. Cheap printers
(also called GDI printers) will do rasterisation inside the driver, which is
pretty much low level bitmap
stuff, similar to screen output. It's understandable, that people try to
reuse such implementations.
I'm now expert regarding the windows driver model, but thats what I learned
reading the MSDN and
looking into WINE sources sometimes.
The WINE source code can be very helpful in such cases. It may not be
exactly the implemenation like
MS has done it. But the need to be as compatible as possible, will force the
WINE coders to use very similar
solutions.
Regards
Andreas
-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:
[hidden email]]On Behalf Of Derek Renouf
Sent: Donnerstag, 21. April 2011 01:46
To:
[hidden email]
Subject: Re: Enhanced MetaFiles and Remote Desktop
Hi Nicolas,
This was particularly an issue when wide screen PCs first started coming
out. Unfortunately, with remote desktop, as well as Virtual PC, if the
screen is not square then the text can look odd. Whilst we alleviated this
by updating client machine video drivers, it doesn't seem to work with
servers.
About 5 years ago we logged an issue with Microsoft as we were able to
recreate the issue in a few lines of code using .NET. As I recall they got
back to us saying the video drivers were at fault and it wasn't a problem
with Windows or .NET. Can you believe it? a Metafile, which is independent
of device, is dependent on the device driver? Go figure...
I'd sure like to know if people find a solution to this.
-- Derek
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:
[hidden email]] On Behalf Of Nicolas Bryant
Sent: Thursday, 21 April 2011 12:19 AM
To:
[hidden email]
Subject: Enhanced MetaFiles and Remote Desktop
This probably isn't a VisualSmalltalk question so much as a Windows
question, but I just wondered if anyone had previously stumbled across
anything similar....
There are a couple of places in my application where I use an Enhanced
MetaFile. Typically it's opened as an in-memory file, using the Display
device context as the reference DC, and not specifying a size. Various GDI
drawing operations are done (treating it like a standard GraphicsMedium).
The result is then displayed in a pane on a window, or sent to the printer,
or copied to the clipboard, etc.
Everything works fine under normal circumstances, but it all starts to go
wrong when you're running the application via a Remote Desktop connection.
The problem (I think) is that under Remote Desktop the OS has no way of
knowing what the physical dimensions of your monitor are; if you ask for the
Display width and height in millimetres (using GetDeviceCaps) it thinks the
display is 320mmx240mm - in other words, it thinks that you have rectangular
pixels.
The effect of this is that when the EMF is played back to display it, text
comes out looking weird: the horizontal width of any given word is correct,
but each character is wider than it should be. See the two attached
screenshots called "local" and "remote": the same code generated both.
There is a way around the immediate problem, which is that instead of using
the Display device context when calling CreateEnhMetaFile, one can pass in
the display context of the default printer instead. However, this works fine
on screen, but it makes things even worse when you try and copy the EMF to
the clipboard and paste it into Microsoft Word; inside Word the picture
comes out shrunk by an amount equivalent to the difference between the
resolution of the printer and the resolution of the display. (So if it's a
300 dpi printer the picture ends roughly a third of the size it's supposed
to be). See other two attached screenshots.
Is there any way around this?
*** this signature added by listserv *** *** Visit
http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing
and VSWE-L membership management ***
*** this signature added by listserv *** *** Visit
http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing
and VSWE-L membership management ***
*** this signature added by listserv ***
*** Visit
http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management ***
Locked
local.png (2K) Download Attachment