T6x Frankenpad UXGA Darstellungsproblemchen

[Bambulator]

Hi Leute,

ich habe meinem T61 Frankenpad ein UXGA HV150UX1-100 IPS Panel gegönnt. Soweit alles klasse.

Ebenfalls wurde W7 x64 Home Premium neu installiert.

Seitdem habe ich ein paar kleinere Grafikproblemchen. Z.B. wird das Taskleistenicon des TPFanControl nicht richtig dargestellt (siehe Fotos), egal ob die TL-Symbole groß oder klein sind.

Des weiteren tritt ein Darstellungsfehler im Process Explorer auf (siehe Fotos).

Hängt die unscharfe Darstellung des TPFC-Icons mit der Auflösung zusammen? Gibt es da Abhilfe?


Process Explorer normal:

Process Explorer fehlerhaft:

TPFC-Icon unscharf:

 

[KungfuPancake]

Da ist vermutlich ein DPI-Scaling aktiv, das sieht bei Bitmaps dann schonmal scheiße aus. Kannst du enweder abschalten wenn du gute Augen hast, oder damit leben :thumbsup:

 

[think_pad]

--> https://www.microsoft.com/de-de/download/details.aspx?id=21
--> https://www.microsoft.com/de-de/download/details.aspx?id=17718

Bringt die Laufzeitumgebung und Schriftanpassung für die "alten Programme" mit.

 

[Bambulator]

Bringt die Laufzeitumgebung und Schriftanpassung für die "alten Programme" mit.

In der Diensteverwaltung habe ich den 'Programmkompatibilitäts-Assistent-Dienst' für die 'alten Programme' deaktiviert.

Hat der mit dem Problem zu tun?

 

[think_pad]

Hat der mit dem Problem zu tun?

Ganz bestimmt, deswegen heißt er ja so...

 

[Bambulator]

Inwiefern ist aktuelle Software von einem Dienst abhängig, der die Kompatibilität von u.a. 16Bit-Anwendungen gewährleisten soll?

 

[think_pad]

Inwiefern ist aktuelle Software von einem Dienst abhängig, der die Kompatibilität von u.a. 16Bit-Anwendungen gewährleisten soll?

Es geht um die Schriftanpassung und darum, dass uralte Programme mit Bitmap-Schrift auf die neue WINDOWS-Systemschrift Segoe UI mit seinen vielen Darstellungsvarianten übertragen wird. Die 16-bittigen Programme spielen dabei kaum eine Rolle, aber die Schrift ist in grauer Vorzeit mal definiert worden, und da weiß man nie...

 

[quaentchen]

Wenn Win7 ein hochaufgelöstes Display erkennt, stellt es die "falschen" Schriften für die Bitmap Fonts ein.

Für eine längere Erklärung und den benötigten Fix => klick mich.

Wer keine Angst vor .reg Dateien hat, importiert das hier in die Registry:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"Courier 10,12,15"="COURE.FON"
"MS Serif 8,10,12,14,18,24"="SERIFE.FON"
"MS Sans Serif 8,10,12,14,18,24"="SSERIFE.FON"

Also, wo vorher ein F am Ende des Dateinamenstamms stand, muss ein E stehen.

 

[Bambulator]

So, ich hocke jetzt vor meinem Frankenpad.

Es geht um die Schriftanpassung und darum, dass uralte Programme mit Bitmap-Schrift auf die neue WINDOWS-Systemschrift Segoe UI mit seinen vielen Darstellungsvarianten übertragen wird. Die 16-bittigen Programme spielen dabei kaum eine Rolle, aber die Schrift ist in grauer Vorzeit mal definiert worden, und da weiß man nie...

Die Aktivierung des Dienstes hat keinen Effekt auf die Darstellungsfehler.

Framework 3.5 und 4 sind schon installiert.

Also, wo vorher ein F am Ende des Dateinamenstamms stand, muss ein E stehen.

In der Registry steht an besagten Stellen schon jeweils ein 'E'.


Wat nu?

Fehlt vielleicht eine Schriftart?

Edit:

Schriftarten gerade wiederhergestellt, keine Änderung.

 

[der_ingo]

KungfuPancake hat es oben ja schon geschrieben: bei manchen Elementen skaliert das System und das sieht dann mies aus. Das TPFC Icon liegt nur in einer kleinen Auflösung als Bitmap vor, das sieht immer schlecht aus, wenn skaliert wird. Solange da nicht vom Entwickler selber was kommt, wirds bei der pixeligen Ansicht bleiben, sobald du die Skalierung aktivierst.

Die Skalierungsfunktionen wurden bei den aktuelleren Windows Versionen etwas besser, auch hilft bei manchen Anwendungen mal ein Update. Aber selbst bei Windows 10 bekommt Microsoft selber es noch nicht hin, alle mitgelieferten Programme so zu bauen, dass sie mit Skalierung und HiDPI Displays zurechtkommen.

Die Sache mit dem .net Framework ist in diesem Fall nutzlos, da sowohl Process Explorer als auch TPFC m.W. keine .net Anwendungen sind, sondern Win32.

 

[quaentchen]

Ich hab jetzt nochmal bei mir in der Registry geschaut und da sieht es so aus:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"MS Serif 8,10,12,14,18,24"="SERIFF.FON"
"MS Sans Serif 8,10,12,14,18,24"="SSERIFE.FON"
"MS Sans Serif 8,10,12,14,18,24 (VGA res)"="sserifeX.fon"

Wichtig ist wohl eher der Eintrag für "MS Sans Serif 8,10,12,14,18,24 (VGA res)".

Der "sserifeX.fon", der bei mir steht, ist eine Kopie von SSERIFE.FON, in dem ich als Win95 UI Fan die fehlenden Sonderzeichen eigenhändig eingepflegt habe. Was die Geometrie anbelangt, ist der aber ansonsten identisch mit dem Original.

Also,

"MS Sans Serif 8,10,12,14,18,24 (VGA res)"="SSERIFE.FON"

muss funzen.

Allerdings erst nach einem Reboot.

 

[think_pad]

Die Sache mit dem .net Framework ist in diesem Fall nutzlos, da sowohl Process Explorer als auch TPFC m.W. keine .net Anwendungen sind, sondern Win32.

Nein, ist nicht nutzlos. In dem Augenblick, in dem die uralte SansSerif zur "Systemschrift" erklärt wird, wird sie in zwei Schritten ("Systemschriftfamilie"; Bitmap-Schrift -> Win32-Types -> TrueType) in die brillante WIN10-Segoe UI umgewandelt, und selbst uralte Programme mit katastrophalen Schriften sehen aus wie neu. Diesen Schriften-Transformierungsprozess, der manchmal oft erst nach einer Stunde ernsthaften Benutzens alter Stand-Alone-Programme ohne Ankündigung nach Reboot plötzlich dargestellt wird, leisten NET Framework 2.0, 3.5 und 4.x, also jene Versionen, in der das Programm seinerzeit erstellt wurde. Außerdem sollten die WINDOWS-Updates für NET.Framework immer mit eingespielt werden, die helfen auch viel...

 

[Bambulator]

So, das Frankenpad habe ich gestern abend ausgeschaltet, habe vorher alle hier empfohlenen Massnahmen umgesetzt (inkl. anschließendem Reboot).

Keine Änderung. Leicht frustriert dem Rechner ne 24h Pause gegönnt.

Gerade gestartet, die Fehler sind verschwunden...

???

Verstehe ich nicht. Egal, ich danke allen Beteiligten für die informativen Tipps.

 

[think_pad]

Gerade gestartet, die Fehler sind verschwunden... ??? Verstehe ich nicht.

Heinzelmännchen-Sonderdienst...

 

[der_ingo]

Nein, ist nicht nutzlos. In dem Augenblick, in dem die uralte SansSerif zur "Systemschrift" erklärt wird, wird sie in zwei Schritten ("Systemschriftfamilie"; Bitmap-Schrift -> Win32-Types -> TrueType) in die brillante WIN10-Segoe UI umgewandelt, und selbst uralte Programme mit katastrophalen Schriften sehen aus wie neu.

Segoe UI ist seit Windows Vista die Standard-Systemschrift und wurde für Windows 8 leicht überarbeitet. Davor war seit Windows 2000 Tahoma die Windows Standard-Systemschrift. MS SansSerif wird weiterhin für einige Darstellungen des Systems verwendet, aber auch unter Windows 10 noch - und auch nach der Installation des aktuellsten .net Frameworks.

Diesen Schriften-Transformierungsprozess, der manchmal oft erst nach einer Stunde ernsthaften Benutzens alter Stand-Alone-Programme ohne Ankündigung nach Reboot plötzlich dargestellt wird, leisten NET Framework 2.0, 3.5 und 4.x, also jene Versionen, in der das Programm seinerzeit erstellt wurde.

In Windows werden keine Anwendungsschriften plötzlich nach stundenlanger Nutzung eines Programmes "transformiert".

Die Änderungen in den neueren .net Framework Versionen, die z.B. HiDPI Displays und Skalierung betreffen, sind definitiv sinnvoll und wichtig. Sie wirken sich aber ausschließlich auf Programme aus, die auch auf dem .net Framework basieren. Anwendungen, die Win32 oder ein anderes Framework nutzen, profitieren davon rein gar nicht. Die oben genannten Anwendung sind - wie oben schon geschrieben - keine .net Anwendungen.

Außerdem sollten die WINDOWS-Updates für NET.Framework immer mit eingespielt werden, die helfen auch viel...

In der Hauptsache sorgen sie dafür, dass man Anwendungen ausführen kann, die für neuere .net Framework Versionen erstellt wurden. Nutzt man keine solchen Programme, ist die Installationen neuer Versionen des .net Frameworks nicht zwingend notwendig.
Wichtiger ist das Installieren von Sicherheitsupdates für bereits installierte Versionen. Aber das sollte eigentlich logisch sein.

 

[think_pad]

Segoe UI ist seit Windows Vista die Standard-Systemschrift und wurde für Windows 8 leicht überarbeitet.

Mein lieber Ingo, bei allem Respekt, ich habe mich jahrelang mit diesem unfassbar komplizierten Thema beschäftigt.

Es gibt grundsätzlich fünf Schriftartenfamilien: Serifen, Serifenlose, Monospaced (Nichtproportional), Zierschriften und Sonderzeichen wie €, spezielle Icons etc.

Und das jeweils als normal, kurviv, bold in Hunderten von Fragestellungen:
Systemschrift, Text im Browser, Text im Textverarbeitungsprogramm, Text in Druckdokumenten wie PDF, ... etc.

Die einzige Frage, die immer wieder auftaucht: Wie kann ich eine Schriftartenfamilie der anderen zuordnen?
Und darüber kann man sich dann ernsthaft unterhalten, alles andere ist Gelaber...

Wie kann ich also einem alten Programm mit einer alten WINDOWS-Systemschrift aus z.B. WINDOWS 95 eine neue Schrift in WINDOWS 10 zuordnen?
Ich installiere die Laufzeitumgebung des alten Programms im moderneren System, und das System wird die alte Systemschrift der neuen Systemschrift in der richtigen Größe zuordnen.

 

[der_ingo]

Das Thema ist doch ganz einfach und überhaupt nicht kompliziert: installierst du ein neueres .net Framework, betrifft das nur Programme, die auch auf .net Framework aufbauen. Ist das so schwer zu verstehen?

Dein Ausflug in die Grundlagen der Schriften ist schön, aber ändert nichts an dieser ganz einfachen Tatsache.

 

[think_pad]

Das Thema ist doch ganz einfach und überhaupt nicht kompliziert: installierst du ein neueres .net Framework, betrifft das nur Programme, die auch auf .net Framework aufbauen. Ist das so schwer zu verstehen?

Und wir sind uns aber einig, dass die meisten der "uralten, unschlagbaren WINDOWS-Programme" ursprünglich in Visual Basic und Visual C++ geschrieben wurden. Manchmal blieben diese für immer so mit ihrer spezifischen Laufzeit-DLL erhalten, viele wurden unter dem Nachfolger NET.Framework neu compiliert. Alle diese alten Programme basieren letztlich auf NET.Framework-Versionen, selbst das Lenovo Systemupdate (TVSU, Entwicklungszeitraum 2005-2016, siehe Bilder) basiert auf einer solchen Entwicklungsumgebung. 2005 gab es noch kein WINDOWS Vista, kein Segoe UI und demzufolge werden die allerersten Versionen des TVSU noch unter Tahoma oder noch älteren Schriften dargestellt worden sein.

In all diesen "uralten, unschlagbaren WINDOWS-Programmen" wurden zu Beginn der Programmierung Menüs, Anzeigen und Schriften definiert, meistens noch im SansSerif-Bitmap-Format. Und diese müssen jetzt, selbst wenn sie zwischenzeitlich neu compiliert wurden, auf die Segoe UI (User-Interface) übertragen werden, um eine knackscharfe Darstellung auf den FHD- und UHD-Bildschirmen zu gewährleisten.

Installierst du ein neueres .net Framework, betrifft das nur Programme, die auch auf .net Framework aufbauen. Ist das so schwer zu verstehen?

Es geht nicht um neuere NET.Frameworks, sondern um die alten Versionen 2.0 und 3.5. Sind diese Versionen installiert, kann WINDOWS 10 mit diesen Programmen umgehen und auch die Schrift anpassen. Neuere NET.Frameworks sind nichts weiter als Updates alter NET.Frameworks, und alte NET.Frameworks sind nichts weiter als Updates der ursprünglichen Entwicklungsumgebungen Visual Basic, Visual C++ und was es noch so gab.

So what? Gib Dir 'nen Ruck...

 

[quaentchen]

@Bambulator: könntest du das "Erledigt!' aus dem Thread Titel wieder entfernen? Selbst wenn das eigentliche Problem gelöst ist (worum ging's noch mal?), heißt das ja nicht, dass nicht noch Diskussionsbedarf besteht...

 

[der_ingo]

Und wir sind uns aber einig

Wir sind uns selten einig. Du diskutierst leider lieber bis in alle Ewigkeit, um von deiner ursprünglichen, falschen Aussage abzulenken, bis niemand mehr weiß, worum es eigentlich geht.
Problematisch ist dabei halt nur, dass andere Forenteilnehmer das glauben könnten, weil es von dir so völlig überzeugend vorgetragen wird. Hilfreich ist es aber leider nicht.

Was du da oben beschreibst, ist ganz einfach nur, dass ein Programm unter verschiedenen Windows Versionen die jeweilige Systemschriftart des darunterliegenden Systems benutzt und diese zwischendurch mal geändert wurde. Somit nutzen jetzt alte Programme unter neuen Windows Versionen logischerweise auch neuere Schriftarten. Das ist logisch. Das machen sie aber auch sofort und immer und nicht erst nach einiger Zeit der Benutzung. Und das hat noch gar nichts mit dem .net Framework zu tun.