Recursive: Die Höhe der Klammern/Klammern/Klammern sieht bei bestimmten Schriftgrößen leicht abweichen

Kann bestätigen, bei mir ist es im neuesten stabilen VSCode unter Windows 10 2004 (19546) genauso. Scheint auch von der Schriftstärke abhängig zu sein - dh bei einer bestimmten Größe sehen einige Gewichte in Ordnung aus (in Bezug auf Klammern/Klammern/Klammern), andere - nicht.

Danke, @krish-r & @kamenminkov! Gute Augen dabei.

Können Sie bitte die statischen Schriftarten in v1.034 ausprobieren und mich wissen lassen, ob das gleiche Problem immer noch besteht?

https://github.com/arrowtype/recursive/tree/e882954365d4fafdf2fb43abeff99a28d615f32e/fonts_1.034

Diese sollten mit Schriftnamen aktiviert werden wie:

RecursiveMonoLnr-Regular und RecursiveMonoCsl-Regular

(Diesmal ohne Versionsnummer im Namen).

Hallo @arrowtype , ich konnte Recursive aktivieren, nachdem ich editor.fontFamily als 'Recursive Mono Casual'/'Recursive Mono Linear' angegeben hatte.

Windows 10, rekursive Versionsinformationen:

Leider sehe ich immer noch Höhenunterschiede.

Okay, danke fürs Ausprobieren! Ich schaue mir das mal genauer an und probiere es unter Windows aus.

Ich vermute, dass die rechten Klammern Komponenten der linken Klammern verwenden, und Windows verwendet diese entweder ein wenig anders Pixel-Aliasing, weil es sich um Komponenten handelt, oder weil sie vielleicht nur etwas niedriger ausgerichtet sind und der Unterschied vergrößert wird.

Ich werde dies aktualisieren, wenn ich mehr weiß, hoffentlich innerhalb der kommenden Woche oder so.

Danke @thundernixon .

Und es tut mir leid, diese völlig unabhängige Frage, gab es eine Änderung daran, wie der "Titel" auf dem kleinen "i" aussieht? Weil ich sehen konnte, dass es zwischen meinen ursprünglichen und aktuellen Screenshots etwas anders ist - Größe 17 z.

PS. Gerne können Sie diesen Kommentar (erneut) verschieben, wenn Sie der Meinung sind, dass dies das Problem übernimmt.

Wir haben dem statischen Build-Prozess einen Autohinting-Schritt hinzugefügt, der hoffentlich hauptsächlich beim Rendern in Windows helfen sollte, aber einige Kompromisse haben kann. Deshalb dachte ich auch, dass die Klammern anders sein könnten. Ich werde auch einen Blick auf den i-Punkt und die diakritischen Zeichen im Allgemeinen werfen. Vielen Dank!

Ich wollte nur erwähnen, dass ich dies immer noch bei v1.052 unter Windows mit VS Code sehe.

Okay, endlich versuchen, das durchzuarbeiten. Ich versuche, einen Schritt in den Build hinzuzufügen, der öffnende / schließende Satzzeichen wie diese zerlegt, und das kann helfen.

Als zusätzliche Anmerkung habe ich bemerkt, dass Klammern in den fetteren Sans-Stilen etwas kürzer sind:

...und die () und [] sind in den fetteren Mono-Stilen kürzer:

Also werde ich durchgehen und sicherstellen, dass diese die gleiche Höhe haben.

Anpassungen:

• [x] Macht ( ) [ ] dieselbe Höhe wie { }
• [x ] Sicherstellen, dass die blauen Zonen diese abdecken
• [x] Stellen Sie sicher, dass die .case Versionen auch ausgerichtet und in der Höhe übereinstimmen

Ich habe Schriftarten mit den Korrekturen neu erstellt, und die neuen sind hier:

https://github.com/arrowtype/recursive/tree/4b59fd2f5ce78c342418c894d3a7e620819cac23/fonts_1.067

Wäre jemand, der dieses Problem hatte, bereit, diese neuen Schriftarten auf Ihrem System auszuprobieren? @krish-r, @kamenminkov , @ @jkyeung oder @jwortmann? Ich hoffe, es könnte funktionieren, aber nicht ganz sicher. 🤞

Die Klammern/Klammern/Klammern sehen für mich jetzt perfekt aus 👍 , aber es gibt immer noch eine Fehlausrichtung zwischen den "kleiner als" und "größer als" Symbolen <> bei allen Schriftgrößen.

Getestet mit RecursiveMonoLnrSt-Regular.ttf + kursive & fette Varianten unter Windows 10 v2004, Sublime Text 3.2.2.

Hallo,

Editor und Betriebssystem: VS Code v1.51.1, Windows 10 v20H2

_Statische Schriftart_
Wie @jwortmann erwähnte, konnte ich nur mit der spitzen Klammer eine Fehlausrichtung sehen, der Rest sieht perfekt aus.

RecursiveMonoLnrSt-Regular.ttf - spitze Klammer ist bei den meisten Schriftgrößen falsch ausgerichtetalign

RecursiveMonoCslSt-Regular.ttf - spitze Klammer ist bei Größe 16 & 17 falsch ausgerichtet (passt zu anderen Größen z. B. 14)

_Variable Schriftart_
Und als ich die variable Schriftart ausprobiert habe, ist alles (einschließlich spitzer Klammer) für mich perfekt ausgerichtet.

Recursive_VF_1.067.ttf



(Linear)

Hey @jwortmann & @krish-r, vielen Dank für so schnelle Tests & Antworten!

Ich schreibe das teilweise auf, damit ich mich daran erinnere, wenn ich zurückkehre, um das bald zu beheben, aber...

Meine Vermutung ist, dass die Höhenunterschiede darauf zurückzuführen sind, dass die spitzen Klammern vertikal asymmetrisch sind. Sie ahmen Pinselstriche nach, die dazu neigen, asymmetrisch zu sein. Dies bedeutet jedoch, dass das Windows-Rendering wahrscheinlich den Unterschied in den Koordinatenhöhen erkennt und sie unterschiedlich an vertikalen Pixeln ausrichtet, selbst wenn sie visuell vertikal ausgerichtet sind. Dies geschieht, wenn Hinting vorhanden ist, was bedeutet, dass die statischen Schriftarten (die über Autohinting verfügen) dies zeigen, während die variable Schriftart (die kein Hinting hat) den Unterschied nicht erzeugt. Also sollte ich diese so bearbeiten, dass sie symmetrischere Formen haben, ähnlich wie ich Pfeile behandelt habe.

Ich werde hoffentlich Anfang nächster Woche dazu kommen. Ich werde das so schnell wie möglich aktualisieren!

Hey @jwortmann & @krish-r, könnte einer von euch bitte bestätigen, dass die neuesten Schriftarten (in Version 1.068) das Problem für euch beheben? Wenn ja, können wir das Problem schließen. Danke!

Hallo @arrowtype ,

Danke, Versucht v1.068, die spitzen Klammern sind jetzt richtig ausgerichtet. Leider konnte ich bei bestimmten Schriftgrößen leichte Fehlausrichtungen in den restlichen Klammern feststellen.

Editor und Betriebssystem: VS Code v1.52.0, Windows 10 v20H2

Rekursiver_Code:
_Aufnahme Mono Linear:_

_Aufnahme Mono Casual:_

@krish-r vielen Dank für die Hilfe beim Testen! Hm, zwei Dinge:

1. facepalm Ich hatte die früheren Fixes in einem Branch vorgenommen und sie dann nicht in den Haupt-Branch zusammengeführt, bevor ich an neuen Problemen arbeitete. Insbesondere hatte ich das Schlusszeichen zerlegt und (glaube ich) die vertikalen Höhen leicht angepasst. Also werde ich diese Fixes einbringen und so schnell wie möglich eine weitere neue Version veröffentlichen.
2. Es sieht so aus, als ob Sie die "Code"-Schriften verwendet haben, die eine neue Ligatur für <> – also zeigen diese jetzt nur eine einzelne Glyphe, die das Ergebnis möglicherweise verfälscht. Um ein genaues Ergebnis zu erhalten, müssen wir diese Kombination mit einem Leerzeichen dazwischen testen.

Ich war hier zu selbstsicher und dachte, ich hätte es mit der neuen Veröffentlichung genagelt. Entschuldigung! Ich werde dies speziell in einer Windows-VM testen, bevor ich eine neue Version erstelle und um Bestätigung bitte.

Immer gerne testen! Und ja, du hattest Recht, ich habe vergessen, die Ligaturen auszuschalten.
Versuchte sie noch einmal mit "editor.fontLigatures": false .

_Aufnahme Mono Linear:_

_Aufnahme Mono Casual:_

Schön! Ja, beim Testen fiel mir ein, dass VS Code es einfach macht, Code-Ligaturen zu deaktivieren. Aber danke auch für den Hinweis hier!

In meinen Tests war die Interpunktion nicht _völlig perfekt symmetrisch_, scheint aber das Problem des Ganzpixel-Offs zu vermeiden.

Wenn Sie Zeit haben, @krish-r, könnten Sie die neueste Version ausprobieren, https://github.com/arrowtype/recursive/releases/tag/1.069? Es fügt den Zerlegungsschritt hinzu, der in den früheren Tests zu helfen schien.

Versuchte v1.069. Und die Klammern sehen auch auf mich ausgerichtet aus! 👌

Danke @arrowtype!

_Aufnahme Mono Linear_

_Rec Mono Casual_

Super, vielen Dank für deine Hilfe beim Testen!

Glücklich, dass wir das sortiert haben.

Ich kann bestätigen, dass mit Version 1.069 alle Arten von Klammern und die Symbole < und > für mich korrekt ausgerichtet sind. Vielen Dank für das Update!

Danke für die Bestätigung, @jwortmann!