Recursive: La hauteur des paires de parenthèses/crochets/accolades semble légèrement décalée pour certaines tailles de police

Je peux confirmer, c'est la même chose pour moi dans le dernier VSCode stable sous Windows 10 2004 (19546). Semble également dépendre du poids de la police - c'est-à-dire à une taille donnée, certains poids semblent corrects (en ce qui concerne les crochets/accolades/parenthèses), d'autres - non.

Merci, @krish-r & @kamenminkov ! De bons yeux là-dessus.

Pouvez-vous s'il vous plaît essayer les polices statiques de la v1.034 et me faire savoir si vous avez toujours le même problème ?

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

Ceux-ci devraient être activés avec des noms de police comme :

RecursiveMonoLnr-Regular et RecursiveMonoCsl-Regular

(Sans numéro de version dans le nom, cette fois).

Salut @arrowtype , j'ai pu activer Recursive après avoir spécifié editor.fontFamily comme 'Recursive Mono Casual'/'Recursive Mono Linear'

Informations sur la version récursive de Windows 10 :

Malheureusement, je vois toujours la différence dans les hauteurs.

D'accord, merci d'avoir essayé ça ! Je vais regarder de plus près et essayer sous Windows.

Je suppose que les crochets droits utilisent des composants des crochets gauches, et Windows les aliase un peu différemment parce que ce sont des composants, ou parce qu'ils sont peut-être juste alignés légèrement plus bas et que la différence est amplifiée.

Je mettrai à jour cela quand j'en saurai plus, j'espère dans la semaine à venir.

Merci @thundernixon .

Et, je suis désolé, cette question sans aucun rapport, y a-t-il eu un changement dans l'apparence du "titre" sur le "i" minuscule ? Parce que j'ai pu voir que c'est légèrement différent entre mes captures d'écran originales et actuelles - Taille 17, par ex.

PS. Heureux de (re)déplacer ce commentaire si vous pensez que cela détourne le problème.

Nous avons ajouté une étape d'auto-indication au processus de construction statique, qui devrait, espérons-le, principalement aider au rendu sous Windows, mais peut avoir quelques compromis. C'est aussi pourquoi j'ai pensé que les parenthèses pourraient être différentes, cependant. Je vais également jeter un œil au point i et aux signes diacritiques en général. Merci!

Je voulais juste mentionner que je vois toujours cela à v1.052 sur Windows, en utilisant VS Code.

D'accord, j'essaie enfin de résoudre ce problème. J'essaie d'ajouter une étape dans la construction qui décompose la ponctuation d'ouverture/fermeture comme celles-ci, et cela peut aider.

En guise de note supplémentaire, j'ai remarqué que les parenthèses sont légèrement plus courtes dans les styles Sans plus audacieux :

... et les () et [] sont plus courts dans les styles Mono plus audacieux :

Donc, je vais passer en revue et m'assurer que ce sont la même hauteur.

Ajustements :

• [x] Faire ( ) [ ] la même hauteur que { }
• [x ] S'assurer que les zones bleues couvrent ces
• [x] S'assurer que les versions .case sont également alignées et correspondent aux hauteurs

J'ai reconstruit les polices avec les correctifs, et les nouveaux sont ici :

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

Quelqu'un qui a eu ce problème serait-il prêt à essayer ces nouvelles polices sur votre système ? @krish-r, @kamenminkov , @ @jkyeung , ou @jwortmann ? J'espère que cela pourrait fonctionner, mais pas totalement certain. 🤞

Les parenthèses/crochets/accolades me semblent parfaites maintenant 👍 , mais il y a toujours un décalage entre les symboles "inférieur à" et "supérieur à" <> sur toutes les tailles de police.

Testé avec RecursiveMonoLnrSt-Regular.ttf + variantes en italique et en gras sur Windows 10 v2004, Sublime Text 3.2.2.

Bonjour,

Éditeur et système d'exploitation : VS Code v1.51.1, Windows 10 v20H2

_Police statique_
Comme @jwortmann l'a mentionné, je pouvais voir un désalignement uniquement avec le support d'angle, le reste semble parfait.

RecursiveMonoLnrSt-Regular.ttf - le crochet angulaire est mal aligné pour la plupart des tailles de police

RecursiveMonoCslSt-Regular.ttf - l'équerre est mal alignée pour les tailles 16 et 17 (correspond aux autres tailles ex. 14)

_Police variable_
Et quand j'ai essayé la police variable, tout (y compris les chevrons) s'aligne parfaitement pour moi.

Recursive_VF_1.067.ttf



(Linéaire)

Salut @jwortmann & @krish-r, merci beaucoup pour ces tests et réponses rapides !

Je note en partie cela, donc je me souviens quand je reviens pour résoudre ce problème bientôt, mais...

Je suppose que les différences de hauteur proviennent du fait que les équerres sont verticalement asymétriques. Ils imitent les coups de pinceau, qui auraient tendance à être asymétriques. Mais cela signifie que même lorsqu'ils sont visuellement alignés verticalement, le rendu Windows voit probablement la différence de hauteur de coordonnées et les aligne différemment sur les pixels verticaux. Cela se produit lorsque l'indication est présente, ce qui signifie que les polices statiques (qui ont une indication automatique) le montrent, tandis que la police variable (qui n'a pas d'indication) ne produit pas la différence. Donc, je devrais les modifier pour avoir des formes plus symétriques, un peu similaires à la façon dont j'ai traité les flèches.

J'espère pouvoir y arriver en début de semaine prochaine. Je mettrai à jour cela dès que possible !

Hé @jwortmann & @krish-r, si vous en avez l'occasion, l'un de vous pourrait-il confirmer que les dernières polices (dans la version 1.068) résolvent le problème pour vous ? Si c'est le cas, nous pouvons clore le problème. Merci!

Bonjour @arrowtype ,

Merci, j'ai essayé la v1.068, les crochets angulaires sont maintenant correctement alignés. Malheureusement, j'ai pu voir de légers désalignements dans le reste des crochets à certaines tailles de police.

Éditeur et système d'exploitation : VS Code v1.52.0, Windows 10 v20H2

Code_récursif :
_Rec Mono Linéaire :_

_Rec Mono Décontracté :_

@krish-r merci beaucoup d'avoir aidé à tester cela ! Hum, deux choses :

1. facepalm J'avais apporté les correctifs précédents dans une branche, puis je ne les avais pas fusionnés dans la branche principale avant de travailler sur de nouveaux problèmes. Plus précisément, j'avais décomposé la ponctuation de fermeture et (je pense) légèrement ajusté les hauteurs verticales. Donc, je vais apporter ces correctifs et faire une autre nouvelle version dès que possible.
2. Il semble que vous ayez utilisé les polices "Code", qui ont une nouvelle ligature pour <> - donc celles-ci n'affichent maintenant qu'un seul glyphe, ce qui peut fausser le résultat. Pour obtenir un résultat précis, nous devrons tester ce combo avec un espace entre eux.

J'étais trop confiant ici, pensant que j'avais réussi avec la nouvelle version. Désolé ! Je vais spécifiquement tester cela dans une machine virtuelle Windows avant de créer une nouvelle version et de demander confirmation.

Toujours heureux de tester ! Et oui, tu avais raison, j'ai oublié d'éteindre les ligatures.
Je les ai réessayés avec "editor.fontLigatures": false .

_Rec Mono Linéaire :_

_Rec Mono Décontracté :_

Agréable! Oui, en testant, je me suis souvenu que VS Code permet de désactiver facilement les ligatures de code. Mais merci aussi de l'avoir signalé ici !

Dans mes tests, la ponctuation n'était pas _complètement parfaitement symétrique_, mais semble éviter le problème de pixellisation totale.

Si vous avez le temps, @krish-r, pourriez-vous essayer la dernière version, https://github.com/arrowtype/recursive/releases/tag/1.069 ? Il ajoute l'étape de décomposition qui semblait aider dans les tests précédents.

J'ai essayé la v1.069. Et, les parenthèses semblent alignées pour moi aussi ! 👌

Merci @arrowtype !

_Rec Mono Linéaire_

_Rec Mono Casual_

Génial, merci beaucoup pour toute votre aide pour tester cela!

Heureux que nous ayons réglé cela.

Je peux confirmer qu'avec la version 1.069, tous les types de parenthèses et les symboles < et > sont également alignés correctement pour moi. Merci beaucoup pour la mise à jour !

Merci d'avoir confirmé, @jwortmann !