TeeChart - Zu großer Rand beim EMF-Export

[SteffenSchm]

Hallo,

ich ärgere mich jetzt schon einige Tage mit dem Export eines TChart als emf rum. Das erzeugte und über das Clipboard kopierte emf zeigt unten und rechts einen zu gro0en Rand an. Leider tritt das nicht bei jedem Rechner/Monitor auf, sondern nur bei einigen Kollegen. Dummerweise auch nicht bei meinem, was die Behebung dieses Umstands nicht einfacher macht!

Auch wenn ich den Export über das von TeeChart mitgelieferte Dialogfenster mache (siehe Anhang), zeigt die Vorschau diesen grauen Rand (siehe Markierung im Anhang), der dann auch mit exportiert bzw. kopiert wird.
Man kann das Bild dann nach dem Einfügen in Word zuschneiden, aber bei vielen Bildern wird das schnell lästig.

Mir ist bewusst, dass das ein sehr spezielles Thema ist. Aber vielleicht hatte ja jemand dieses Problem auch schon und hat evtl. sogar eine Lösung!

Schönen Abend!
Steffen

[BerndS]

Könnte das mit der Skalierung zusammenhängen. Ist da eventuell 125% aktiv?

[himitsu]

Zitat:

Zitat von BerndS (Beitrag 1509441)

Könnte das mit der Skalierung zusammenhängen. Ist da eventuell 125% aktiv?

Viele Komponenten (z.B. TChart oder auch gewisse Reports) nutzen einen "Desktop"-Canvas (DC) oder den Canvas einer TForm, um interne Dinge (z.B. für Exports) zu zeichnen ... da rutscht dann eben auch die Monitor-Skalierung schön mit rein, obwohl sie dort intern eigentlich garnichts zu suchen hätte.

Bei neueren Delphis kann man in den Projektoptionen noch mehr/anderes bezüglich HighDPI einstellen.
Dort ein bissl rumspielen und schauen, ob sich die Auswirklungen auch diesbezüglich etwas verbessern. (z.B. wenn man seine Forms nicht vom System skalieren lässt)

[Der schöne Günther]

Ich habe das entsprechende Projekt gerade nicht zur Hand, aber ich meine ja, das Problem haben wir auch - Bei DPI-Skalierung des Bildschirms fing der EMF-Export des TeeCharts dann an, dass riesige "Ränder" entstehen weil die Zeichenfläche größer gemacht wird, aber auf im gleichen Bereich gezeichnet wird.

Ich weiß nicht mehr, ob wir einen Workaround gefunden hatten oder tatsächlich ganz billig hingegangen sind, und es halt alternativ als extrem hochauflösendes Bitmap exportiert haben, damit wir wenigstens irgend etwas hatten.

[SteffenSchm]

Danke für Eure schnelle Antworten!

Export als Bitmap haben wir jetzt auch als Zwischenlösung implementiert - macht aber die Word-Dateien, in die die Charts eingefügt werden, sehr groß!

Rumspielen werde ich morgen noch etwas. Ist bloß schwierig, wenn das Problem am eigenen Monitor nicht auftritt!

[himitsu]

Du kannst doch mal probeweise deinen Monitor auf 125% einstellen.

Oder mit einem virtuellen HighDPI-Monitor arbeiten
Oder dir einen kleinen Monitor kaufen


https://www.dell.com/de-de/shop/dell...orzubeh%C3%B6r

[Fritzew]

Das Problem ist, dass Teechart als Referenz Canvas den Bildschirm nimmt, dann aber die Skalierung nicht weiter berücksichtigt.
Lösung wenn auch als "Crack". Das erzeugte Ems noch mal durch ein "neues EMF" jagen das die Skalierung berücksichtigt.
Bin erst nächste Woche wieder im Büro, dann kann ich hier unseren "Hack" dafür posten. Sind nur ein paar Zeilen.

[Der schöne Günther]

Ich habe es jetzt einmal unter Delphi 11.1 und TeeChart Pro 2017.22 probiert: Hiermit wird es auch mit DPI-Skalierung korrekt exportiert:

Delphi-Quellcode:

begin
   var isEnhanced := CheckBox1.Checked;
   var metafile := Chart1.TeeCreateMetafile(isEnhanced, Chart1.GetRectangle());
   metafile.SaveToFile('c:\users\localUser\desktop\metafile.emf');
end;

Der Stolperstein war der zweite Parameter in TeeCreateMetafile(..): Mit

Delphi-Quellcode:

Chart1.BoundsRect

hatte es links oben dicke Ränder und rechts unten abgeschnitten. Mit stattdessen

Delphi-Quellcode:

Chart.GetRectangle()

kommt eine vernünftige Grafik raus, so wie auf dem Bildschirm

[SteffenSchm]

Danke an alle, dass Ihr Euch mit dem Thema befasst - Die Delphi-Community ist echt großartig!

@Der schöne Günther:

Delphi-Quellcode:

GetRectange

hatte ich auch schon probiert, hat aber bei mir (bzw. bei meinen Kollegen, die das Problem an ihren Bildschirmen haben) auch nicht geholfen.

Dass es an der Skalierung der Monitore liegen könnte, hatte ich auch schon gedacht. Allerdings habe ich drei parallele Monitore. Der erste (der Laptop) ist auf 150% skaliert, die beiden anderen auf 100% - Bei mir gibt es auf allen drei Monitoren kein Problem
Mein Kollege, der das Problem mit den Rändern hat, hat den ersten Monitor auf 125% und den zweiten auf 100% und sagt, dass das Problem bei beiden Monitoren auftritt. (Überprüfung ist aber schwer, da wir alle im HomeOffice sind)

Wir werden wohl erst einmal beim Export als Bitmap bleiben.

@Fritzew
Ich wäre Dir sehr dankbar, wenn Du nächste Woche Deinen "Hack" zeigen könntest!

Besten Dank!
Steffen

[Der schöne Günther]

Hallo-

Falls euer Word nicht mehr Word 1997 oder so ist wäre vlt. SVG auch eine Option? Auch wenn bei mir jetzt der Farbverlauf nicht mit rausgekommen ist, wäre das eigentlich ein universelles, platform-unabhängiges Format das man auch problemlos in Word einbetten kann.
Der Graph ließ sich in Word sogar noch nachträglich bearbeiten (Beschriftungen anpassen, Achsen verschieben, ...)

https://www.steema.com/docs/teechart...ortFormat.html

[hotrs02]

Wir hatten ein ähnliches Problem in Zusammenhang mit der Skalierung in Delphi 5. Die Skalierung des primären Monitors beeinflusste die Darstellung, auch wenn die Grafik auf einem anderen Monitor angezeigt wurde.

Ich habe das dann so gelöst, dass ich in einem Thread mittels SetThreadDpiAwarenessContext die DPI Awareness auf per Monitor (V2) stelle, anschließend mittels GetDpiForMonitor die tatsächlichen DPI des primären Monitors ermittle und daraus zwei Skalierungsfaktoren berechne, die letztendlich das Ausgaberechteck skalieren.

Allerdings verwenden wir bei der Erstellung des Metafiles nicht das Rechteck des Diagrams, sondern Abmessungen eines Ausgabebereichs innerhalb eines anderen Metafiles, in der das Diagramm dann mittels StretchDraw ausgegeben wird. Das ganze ist Teil einer auf Metafiles basierenden Druckvorschau.

In Delphi 10 / Delphi 11 wurde diese zusätzliche Skalierung bis auf weiteres wieder entfernt. Allerdings sind unsere Anwendungen bislang auch noch nicht als DPI Aware gekennzeichnet.

[himitsu]

Die ersten APIs hatten nur eine DPI, also Die des Hauptmonitors.

Später wurde dann erst hinzugefügt, dass es JE Monitor anders skalieren kann
und zuletzt auch noch Teilweises Skalieren.

Zuerst kamen mehrere DPI, aber die Form nutzt nur jene, wo sie am Meisten drauf ist, also wo jeweils von Höhe und Breite mehr als die Hälfte liegt.
Und Zuletzt ist es so, dass bei Multimonitor jeder Fensterteil einzeln skaliert werden kann, damit die Fensterteile auf beiden Monitoren gleich groß sind.


Aber natürlich muß das erstmal Windows können, also 10+/11 und dann natürlich auch das Programm und dessen Manifest.



Gestern hatten wir bei einem Kollegen den Fall, da war Windows durcheinandergeraten.
Hatte die falsche DPI auf dem flaschen Monitor verwendet.
Dachten erst es liegt am RDP, aber es war lokal schon so falsch.

Kompletter Windowsneustart nicht mehr gemacht (aber leider im RDP schon alles geschlossen), da es dann schon reichte den Hauptmonitor mal kurz zu ändern und danach stimmte es wieder.
Wir hatten früher im RDP öfters schon andere Probleme, welche erst bei einem Serverneustart, oder zumindestens nach Abmeldung (nicht Trennen) des Nutzers, wieder richtig waren.



Ein kleines Surface auf HighDPI mit 200% an zwei großen FullHD mit 100%.
Der eine Monitor war der Hauptbildschirm, aber auf ihm war plötzlich ALLES doppelt so groß, bis auf ein Programm, was kein HighDPI konnte und bei 200% größtenteils nur noch halb so groß aussah.

[SteffenSchm]

Danke Günther - das SVG-Format schau ich mir an!

Danke auch an alle anderen für die Hinweise. Da muss ich mich erst einmal durcharbeiten. War bis jetzt in einer Besprechung gebunden.

[Redeemer]

SVG wird von Word gerastert ausgegeben. Die Qualität leidet und/oder eine PDF-Ausgabe wird sehr groß. EMF wird hingegen als Vektordaten ausgeben, egal ob als PDF oder an den Drucker. Ich hab mir sogar extra eine Klasse geschrieben, die SVG verlustfrei nach EMF konvertiert, um Word und andere Programme dazu zu bringen, meine Grafiken als Vektor auszugeben.

[SteffenSchm]

Das SVG-Format gibt es bei meiner TeeChart-Installation nicht!

Ich habe nur die standardmäßig mit Delphi 10.3 mitgelieferte Version. Das wird zwar SVG in der TeeChart-Hilfe beschrieben, die unit TeeSVGCanvas ist aber gar nicht mitgeliefert.

Werde ich wohl doch erst einmal bei Bitmap bleiben und mir die Sache mit den Bildschirmauflösungen noch einmal anschauen.

Besten Dank für Eure Hinweise!

[Der schöne Günther]

Ok, ich bezog mich auf "TeeChart Pro", nicht die kostenlose Version. Da sind bei mir ca ein Dutzend Export-Formate.

[SteffenSchm]

Ich habe das Problem zumindest mal eingrenzen und auch auf meinem Arbeitsplatz sichtbar machen können.

Die Ränder in der exportierten emf-Datei treten immer dann auf, wenn der Hauptmonitor (der mit den Windows-Symbolleisten) auf mehr als 100% skaliert ist. Die Ränder werden auch umso größer, je höher die Skalierung dieses Monitors ist (z.B. bei 150% Skalierung des Hauptmonitors beträgt der Rand des emf 50% des Diagramms - also Gesamtgröße 150%).

Das hilft erst einmal, um das Problem über entsprechende Windowseinstellungen zu umgehen.

Jetzt muss ich nur noch suchen, wie man das im Delphi-Programm bei der Erstellung des emf berücksichtigen kann.

[himitsu]

Jupp, wie schon erwähnt, ist das Hauptproblem hier, dass TeeChart eben den Desktop als Referenz für die Ausgabe nutzt und dann halt die MonitorSkalierung sich dort böswillig rein hängt. :wall:

Die "richtige" Lösung wäre ja, wenn es im TeeChart repariert würde.

Nachträgelich das so hinzubiegen, dass es jetzt erstmal geht, gibt dann wieder Probleme, wenn Windows erneut an der MonitorAPI rumbspielt, was garantiert bald passiert.



Dein Programm läuft noch auf einer alten MonitorAPI-Version, bzw. auf Garkeiner/derErsten (wenn das Mainfest fehlt) ... über das Manifest kann man einstellen, welche Einstellungen Windows verwenden soll.
Dementsprechend ändert sich dann das Verhalten, aber grundsätzlich wird das auch nicht anders lösen, seöbst wenn mit PerMonitoDPI, weil das Fenster kann dann ebenfalls auf einem Monitor mit höherer DPI laufen.

[SteffenSchm]

Naja, auf eine Reparatur in TeeChart zu warten hat für mich eher keinen Sinn, zumal ich nicht die aktuelle Version von Delphi und TeeChart habe!

Mir würde es schon helfen, das Ganze nachträglich so hinzubiegen.
Als Nebenbei-Programmierer weiß ich aber nicht
- wie ich in Delphi die Skalierung des primären Monitors abfragen kann und
- wie ich die Größe der Zeichenfläche für das EMF beeinflussen kann

[himitsu]

zum Ersten:

Einfach TForm.PixelsPerInch bei der Form, wo der Chart drauf liegt,
bzw. bei Screen in den jeweiligen Monitor schauen.

hier noch paar mögliche Stellen uvm.

Delphi-Quellcode:

// Self = die aktuelle Form

Self.PixelsPerInch
Self.CurrentPPI // bzw. Self.GetCurrentPPI
Self.ScaleFactor

Self.Monitor.PixelsPerInch
Self.DefaultMonitor.PixelsPerInch

Screen.PixelsPerInch
Screen.DefaultPixelsPerInch
Screen.PrimaryMonitor.PixelsPerInch

...

https://en.delphipraxis.net/topic/63...ays-identical/


das Zweite ... gute Frage

[SteffenSchm]

Hi himitsu,

danke für Deine Antwort!
Aber bekomme ich aus dem Wert "PixelPerInch" des Monitors tatsächlich die Skalierung des Monitors (z.B. 125%) raus?
Und der Rand des TChart hängt nicht vom Monitor ab, auf dem das Chart gerade liegt, sondern immer vom Hauptmonitor!

Und dann wäre ja auch noch der zweite Teil :?

Ich habe als schnelle Lösung die Kopie-Funktion jetzt umschaltbar zwischen EMF und Bitmap gemacht. Wenn der Hauptmonitor nicht auf 100%-Skalierung steht, muss man eben als Bitmap kopieren.

Ich glaube, so schnell bekomme ich da keine bessere Lösung hin!

[himitsu]

Ganz sicher bin ich da auch nicht, weil mußte mich so jezt noch nicht damit beschäftigen.

Ich glaub 96 DPI kannst du als 100% ansehen und dann das mit den aktuellen DPI/PPI vergleichen.
Und vom Namen her würde ich mal denken, dass ScaleFactor der passende Wert sein könnte. ( 1.0 = 100% )

[Redeemer]

Man kann sich auch die Datei mal ansehen, die da erstellt wird, und dann im PENHMETAHEADER selbst rumschreiben.
Mehr Informationen könnte man dir geben, wenn du eine richtige und eine falsche EMF desselben Bildes hochladen würdest.

Hintergrund ist ein ähnlihches Problem bei mir: Windows unterstützt RDP-Clients nicht vernünftig, die Bildschirme mit anderen Seitenverhältnissen als 4:3 haben, also praktisch alle aktuellen Arbeitsplätze. Grund dafür ist, dass

Delphi-Quellcode:

GetDeviceCaps(Handle, HORZSIZE)

und

Delphi-Quellcode:

GetDeviceCaps(Handle, VERTSIZE)

hardcoded 320 bzw. 240 sind. GDI erstellt daher schwachsinnige EMFs, die ein falsches Seitenverhältnis haben oder bei denen horizontale Linien viel dicker sind als vertikale (wenn du einen Breitbild-Bildschirm verwendest). Wie genau der Fehler zustandekommt, ist zudem von der Windows-Version abhängig. Ich hab mir dafür im PENHMETAHEADER rumgeschrieben. Du kannst die Methode gerne auch einfach mal probieren, das könnte sogar reichen. Der Code dort gehört zu einem Erben von TMetaFile. Da du keinen hast, solltest die abgespeicherte EMF-Datei von der Festplatte in den Stream laden und wieder speichern.

[SteffenSchm]

Danke für Eure Hinweise und Unterstützung.

@himitsu

Zitat:

Und vom Namen her würde ich mal denken, dass ScaleFactor der passende Wert sein könnte. ( 1.0 = 100% )

Da hast Du recht - das liegt auf der Hand

@Redeemer
Danke für die Hinweise, aber das wird mir jetzt zu aufwendig. Wollte das Chart einfach nur mit

Delphi-Quellcode:

CopyToClipboardMetafile

schnell ausgeben und hatte gehofft, dass es vlt. doch eine schnelle Lösung für mein Problem gibt.

Ich werde erst einmal bei meiner einfache Lösung (emf wenns klappt, sonst Bitmap) bleiben.

Besten Dank!