Mischung MM_TEXT/MM_LOMETRIC und Bildschirm, Ausdruck, EMF-Export

[Holger Gothan]

Hi,

Mein eigentliches Problem entsteht dadurch, dass ich die Draw-Routinen
zweier Programmroutinen miteinander verbinden muss und die eine arbeitet mit
MM_LOMETRIC, die andere mit MM_TEXT.
Es würde einen erheblichen Aufwand darstellen, eine der beiden auf den
"anderen" Modus umzustellen.
Beim Ausdruck funktioniert alles, nur auf dem Bildschrim und beim EMF-Export
wird der MM_LOMETRIC-Teil ca. 25% "kleiner".

Ich habe mir mal gerade eine Beispiel-App zusammengebastelt.
Es soll einfach ein Text an der Position (10x10 cm) ausgegeben werden.
Einmal rechne ich selber im Modus MM_TEXT, einmal direkt im
Modus MM_LOMETRIC.

Der normale Bildschirm-DC schreibt den LOMETRIC bei ca. 7.5 x 7.5 cm und
meinen "manuell" berechneten (wie erwartet) bei 10x10 cm.
Die Druckvorschau und auch der "echte" Ausdruck stellt beide Texte bei 10x10
cm dar.
Der EMF-Export verhält sich ähnlich wie der Bildschirm - nur dass 2
unterschiedliche Fonts gewählt wurden.

Äh was denn nun, wieso rechnet MM_LOMETRIC anders (und dazu noch falscher)
als ich?

Hier mal das Beispiel:
void CEMFTestView::OnDraw(CDC* pDC)
{
int OldBkMode=pDC->SetBkMode(TRANSPARENT);
int LPSX=pDC->GetDeviceCaps(LOGPIXELSX);
int LPSY=pDC->GetDeviceCaps(LOGPIXELSY);
int PosXInMM=100;
int PosYInMM=100;
int x, y;
int OldMapMode=pDC->GetMapMode();

pDC->SetMapMode(MM_TEXT);
pDC->TextOut(0, 0, "top left");
x = (int)(PosXInMM/25.40*LPSX);
y = (int)(PosYInMM/25.40*LPSY);
pDC->TextOut(x, y, "MM_TEXT");

pDC->SetMapMode(MM_LOMETRIC);
x = 10*PosXInMM;
y = 10*PosYInMM;
pDC->TextOut(x, -y, "MM_LOMETRIC");

pDC->SetMapMode(OldMapMode);
pDC->SetBkMode(OldBkMode);
}

void CEMFTestView::DoExportEMF()
{
CClientDC dc(this);
CMetaFileDC MetafileDC;
MetafileDC.m_bPrinting=TRUE;
LPCTSTR pFileName="E:\\Test.EMF";
HENHMETAFILE hMetafile;
if (MetafileDC.CreateEnhanced(NULL, pFileName, NULL, "Test"))
{
MetafileDC.m_hAttribDC=dc.GetSafeHdc();
OnDraw(&MetafileDC);
MetafileDC.m_hAttribDC=NULL;
hMetafile=MetafileDC.CloseEnhanced();
if (hMetafile)
DeleteEnhMetaFile(hMetafile);
}
}

Tschüß, Holger.

[Martin Richter [MVP]]

Hallo Holger!

> Mein eigentliches Problem entsteht dadurch, dass ich die Draw-Routinen
> zweier Programmroutinen miteinander verbinden muss und die eine arbeitet
> mit MM_LOMETRIC, die andere mit MM_TEXT.
> Es würde einen erheblichen Aufwand darstellen, eine der beiden auf den
> "anderen" Modus umzustellen.
> Beim Ausdruck funktioniert alles, nur auf dem Bildschrim und beim
> EMF-Export wird der MM_LOMETRIC-Teil ca. 25% "kleiner".
>

Ich kann Dein Problem nachvollziehen.
Und ehrlich gesagt ist mir die Ursache unklar. Evtl. basiert MM_LOMETRIC
nicht auf LOGPIXSX/Y.

Als Lösung fällt mir nur ein, dass Du MM_ANISOTROPIC verwendest und die
Extents entsprechend setzt. Dann liegen die Daten korrekt übereinander,
was keinen wundert.
pDC->SetViewportExt(LPSX,LPSY);
pDC->SetWindowExt(254,254);

--
Martin Richter [MVP] WWJD http://blog.m-ri.de
"A well-written program is its own heaven; a poorly written
program is its own hell!" The Tao of Programming
FAQ: http://www.mpdvc.de Samples: http://www.codeproject.com

[Martin Richter [MVP]]

Hallo Holger!
>
>> Mein eigentliches Problem entsteht dadurch, dass ich die Draw-Routinen
>> zweier Programmroutinen miteinander verbinden muss und die eine
>> arbeitet mit MM_LOMETRIC, die andere mit MM_TEXT.
>> Es würde einen erheblichen Aufwand darstellen, eine der beiden auf den
>> "anderen" Modus umzustellen.
>> Beim Ausdruck funktioniert alles, nur auf dem Bildschrim und beim
>> EMF-Export wird der MM_LOMETRIC-Teil ca. 25% "kleiner".

Also die Ursache ist ziemlich simpel.
Du arbeitest mit LOGPIXELSX/LOGPIXELSY um die Größenverhältnissen zu
berechnen.

Für MM_LOMETRIC etc. verwendet GDI aber HORZSIZE und VERTSIZE als Basis.
Und dieser Wert ist "angeblich" die physikalische Größe des Screens in
mm! Angeblich, weil es z.B. bei mir in keiner Weise stimmt. Ich hätte
gerne einen Screen mit 59,3cm und 37cm Höhe ;).
Für MM_LOMETRIC werden einfach die Werte von HORZSIZE und VERTSIZE (mal
Faktor 10/100) in den Window-Extent geladen und die Werte von HORZRES
und VERTRES in den Viewport-Extent.

Und da der Quotient aus HORZSIZE und HORZRES (bzw. VERT...) eben nicht
identisch zu LOGPIXELSX ist ergibt sich hier eine Differenz.

Dieser Größen-Verzerrungs-Effekt scheint aber bei einem Drucker nicht
gegeben zu sein. Denn hier ist die physikalische Größe wirklich fest
vorgegeben.

Also bleibt nur der Weg MM_ANISOTROPIC zu verwenden basierend auf
LOGPIXELSX / SY!

[Holger Gothan]

Hi,

"Martin Richter [MVP]" <martin....@mvps.org> schrieb im Newsbeitrag
news:hq1iol...@news.grutzeck.de...

Vielen Dank für diese Analyse. Wobei ich eher gleich auf MM_TEXT umstellen
würde. Der nötige Aufwand erscheint mir gleich zur Umstellung auf
MM_ANISOTROPIC.
Aber ich habe ja auch eine Zoom-Funktion eingebaut. Den nötigen Faktor
könnte ich mir ja aus dem aktuellen HORZSIZE/HORZRES bzw. LOGPIXELSX etc.
berechnen...
Mal schauen, ob ich damit weiterkomme.

ps:
Scheinbar gibt es einige "Treiber/Grafikkarte/Monitor/was auch
immer"-Kombinationen, wo es stimmt. Leider gehörte wohl mein alter
Entwicklungsrechner zu dieser Kategorie...

Tschüß, Holger.

[Martin Richter [MVP]]

Hallo Holger!

> Vielen Dank für diese Analyse. Wobei ich eher gleich auf MM_TEXT
> umstellen würde. Der nötige Aufwand erscheint mir gleich zur Umstellung
> auf MM_ANISOTROPIC.
> Aber ich habe ja auch eine Zoom-Funktion eingebaut. Den nötigen Faktor
> könnte ich mir ja aus dem aktuellen HORZSIZE/HORZRES bzw. LOGPIXELSX
> etc. berechnen...
> Mal schauen, ob ich damit weiterkomme.

Gerade wenn Du Zoom einbauen willst hilft MM_ANISOTROPIC doch ungemein.
Man rechnet intern mit LPs die man haben möchte und lässt den Rest
MM_ANISOTROPIC machen um die entsprechenden DPs zu bekommen. Man muss
keinen Font umrechnen. Keine neuen Objekte erzeugen. Alles gut ;)