J'ai déjà testé les liens obliques et rectangulaires, mais je trouvais ça terriblement laid … et y'a déjà parfois quelques incohérences sur les liens courbes… Puis le but premier, c'est quand même d'avoir un fichier html simple, léger, hébergeable partout. J'ai déjà quelques personnes qui râlent parce que ça s'affiche mal sur leur smartphone (quelle idée aussi) et qu'il y a trop de boutons …
oui, ces 2 points concernant les associations (cardinalité, verbe de relation) m'ont manqué : j'imagine que c'est pour l'itération suivante :D
Tu avais presque tout vu juste : un bouton "⋈ cardinalités" vient d'apparaître sur tous les diagrammes ;) Mais ce n'est pas activé par défaut. Par contre, pour les verbes de relation, ça ne se trouve pas dans les .sql, .dbm, etc. L'info n'y est pas, donc ce n'est pas possible, et ce n'est pas le but de cet outil.
J'ai regénéré tous les diagrammes du site, donc sur ton modèle aussi ça fonctionne maintenant.
Par contre, le stockage des emplacements des tables, c'est pas faisable dans le fichier html en lui même… ou alors faudrait produire un autre html avec les nouvelles positions en dur. Mais ça complique beaucoup l'outil et on perd l'attrait d'un fichier html unique. Je pense qu'il faudra se contenter de l'export SVG pour ça :D
Good job ! Merci de me confirmer que ça marche bien :D
Annuler la/les dernières actions seraient top en effet … faut que j'y réfléchisse, les positions déplacées sont déjà mémorisées en localStorage par visiteur, c'est devrait être assez facilement faisable sans alourdir le single file html. Je me le todolist.
Pour la case à cocher, je suppose que tu parles de "FK d'audit" ? C'est la possibilité de cacher/afficher les FK de traçabilité (créateur, modificateur… qui servent pour l'historisation et qui relient toutes les tables à une table "utilisateur modificateur") qui brouillent le diagramme. Ca se configure dans la page de gestion juste après l'import du fichier sur le site (on peut cocher/décocher les fk) et les plus reconnaissables sont normalement détectées par défaut. Ou configurable par regex par l'API aussi.
Un truc qui surprend dans la time-lapse : pendant des années, les tables flottent sans aucune relation. C'est fidèle au dépôt : jusqu'en 2018, LinuxFr ne déclarait aucune clé étrangère au niveau de la base (les associations vivaient côté modèles Rails). Elles arrivent d'un coup le 24 mars 2018, 29 FK dans le même commit.
Le diff que je préfère : le passage à Doorkeeper pour OAuth2 en septembre 2014. Deux tables maison retirées (client_applications, access_grants), trois tables Doorkeeper (oauth_*) ajoutées : https://mcdview.dev/d/iLZLe1NA40nAHy6Wdk7x8A/41
C'est reconstruit depuis le schema.rb public : la structure (tables, colonnes, FK), pas les index ni les types exacts, et rien n'est branché sur la base de prod. schema.rb étant du Ruby, mcdview ne le parse pas encore nativement, je suis passé par une petite moulinette schema.rb vers SQL.
Oui, bien sur, les briques existent, mais chacune traîne son runtime. fonttools (pyftsubset) subsette très bien, mais c'est du Python à installer. woff2_compress compresse, mais ne subsette pas et ne lit que le TTF/OTF. Et pour extraire le sous-ensemble depuis tes fichiers, on ajoute souvent glyphhanger, en Node. Il n'y avait pas de binaire unique, sans dépendance,sans runtime, pour toute la chaîne. Et c'est l'utilité de woffify.
Convertir, subsetter, et même scanner tes CSS/textes pour ne garder que les glyphes utilisés (-subset-scan), le tout dans un binaire statique unique, sans Python ni Node, pensé pour un CI léger (build de ton site) ou un conteneur. Un ordre de grandeur, sur ma Fedora, le binaire woffify fait 6 Mo. dnf install python3-fonttools réclame 19Mo une fois installé. Et il faut ajouter l'installation de Python. Plus d'autres outils pour faire le reste…
Sur les octets tu as raison,sur du TTF/OTF sans subsetting, la sortie est byte-for-byte identique à woff2_compress (même encodeur, Brotli 11), et le subset passe par le même HarfBuzz(hb-subset). Je ne prétends pas faire plus petit. woffify ajoute juste la couverture d'entrée dans ce même binaire : le WOFF 1.0, et l'EOT non compressé (le vieux format IE, un besoin que nous avions) que ni woff2_compress ni fonttools n'ouvrent.
Si ce besoin « un binaire, zéro dépendance, tous formats, dans un CI/docker » n'est pas le tien, fonttools reste parfait, garde-le. Si tu n'y vois pas de valeur, c'est sans doute que tu n'es pas la cible ;-)
En deux temps :
- WOFF2 seul : −64 % médian (22 Mo → 7 Mo sur les 40)
- WOFF2 + subsetting latin : 22 Mo → ~1 Mo, soit 95 %
Et c'est là la nuance avec woff2_compress : il fait le premier temps (la conversion WOFF2, le −64 %), mais pas le subsetting. Le gros de la surprise est dans le second (7 Mo → 1 Mo) : une police Google traîne du cyrillique, du grec, du vietnamien, des symboles qu'un site latin ne rend jamais. woffify enchaîne les deux dans un seul binaire (subsetting via hb-subset de HarfBuzz). Sur la conversion WOFF2 pure, il ne fait pas mieux que woff2_compress, c'est le même conteneur Brotli.
fontcompressor.com fait aussi compress + subset, mais en ligne et à la main (upload, interface). woffify, c'est un binaire local qu'on glisse dans un build ou une CI, et rien ne quitte ta machine.
woffify subsette selon ce que tu lui donnes, soit des plages Unicode (-subset-unicodes), soit directement le texte utilisé (-subset-text, il garde les glyphes qui le couvrent). Il ne crawle pas le site lui-même : tu lui passes le texte réellement rendu (un -subset-text "$(cat contenu.txt)" dans le build suffit), et il ne reste que tes caractères. Pour un site multilingue, tu élargis les plages ou tu sers plusieurs subsets via unicode-range dans @font-face. Je te laisse imaginer ce que tu peux gagner sur tes fonts avec ça ;)
Et bien, nous utilisons jpegli, tiré de libjxl, justement ! le machin lent de Google.
Chez nous il tourne côté serveur, au moment de l'optimisation, pas à la livraison : on encode une fois et on met en cache. Le visiteur récupère ensuite le fichier déjà encodé depuis le CDN, il n'attend jamais l'encodeur. Et comme on vise une qualité perçue mesurée à la ssimulacra2 (pas un -q à l'aveugle), on fait une petite recherche de qualité par-dessus, ce qui rajoute encore du CPU en amont.
En mode « stored », c'est encore plus net : le POST renvoie tout de suite un 202 avec l'URL finale, un worker encode derrière, et l'URL sert l'original en repli tant que la version optimisée n'est pas prête.
Sur nos mesures, jpegli sort 16 à 32 % plus petit que libjpeg-turbo (mozjpeg) à score ssimulacra2 égal, parce que son modèle psychovisuel place les bits là où l'œil est moins sensible au lieu des tables de quantification fixes. mozjpeg (quantif trellis) joue dans la même cour, un cran au-dessus de la baseline, mais on a tranché pour jpegli. En repli, si cjpegli tombe, on repasse sur libjpeg-turbo via libvips.
Cela dit, pour beaucoup d'images on ne sort même pas de JPEG : AVIF ou WebP quand le navigateur suit, JPEG en filet de sécurité. Les chiffres à qualité perçue égale sont là si ça t'intéresse : https://patu.dev/blog/avif-vs-webp-vs-jpeg (la baseline JPEG y est en libjpeg-turbo).
Oui, tu peux forcer ton firefox chéri (parce que l'autre, il va juste te tracer) à utiliser les fonts que tu veux à la place des choix des webmasters ! Tu es libre !
Mais tu peux toujours compresser tes fonts favoris avec woffify :-) C'est magique ! le choix ET la légèreté.
C'est pas moi qui hallucine, c'est toi qui as croqué dans la pomme qui t'est tombée sur la tête ;)
On peut avoir envie d'un peu plus de fun que les polices du système … qui ne sont pas les mêmes suivants les systèmes/distros voire même desktop !
Mais la police du LLM … faudrait demander à Linus ce qu'il en pense : pcinpact.com/247523/linus-torvalds-sagace-une-nouvelle-fois-sur-lia-cette-fois-pour-la-defendre/
Bien vu. En moyenne sur la semaine, « il est vendredi quelque part » n'est vrai qu'environ 50h sur 168 : les fuseaux extrêmes (UTC-12 et UTC+14) sont à 26h d'écart, donc un jour donné existe 24+26 = 50h. Soit ~30% du temps, tu as raison.
Sauf que là je poste un vendredi en début d'après-midi heure de Paris (UTC+2 en été), soit ~13h UTC : à cet instant c'est vendredi de UTC-12 à UTC+10, environ 85% des fuseaux. Mon CQFD est donc sauf… jusqu'à ce que quelqu'un relise ce journal un mardi. Merci pour le rapport de bug, je passe la note en 0.8-stable !
[^] # Re: schéma technique
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 3 (+3/-0).
J'ai déjà testé les liens obliques et rectangulaires, mais je trouvais ça terriblement laid … et y'a déjà parfois quelques incohérences sur les liens courbes… Puis le but premier, c'est quand même d'avoir un fichier html simple, léger, hébergeable partout. J'ai déjà quelques personnes qui râlent parce que ça s'affiche mal sur leur smartphone (quelle idée aussi) et qu'il y a trop de boutons …
[^] # Re: schéma technique
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 2 (+2/-0). Dernière modification le 04 septembre 2026 à 18:48.
Tu avais presque tout vu juste : un bouton "⋈ cardinalités" vient d'apparaître sur tous les diagrammes ;) Mais ce n'est pas activé par défaut. Par contre, pour les verbes de relation, ça ne se trouve pas dans les .sql, .dbm, etc. L'info n'y est pas, donc ce n'est pas possible, et ce n'est pas le but de cet outil.
[^] # Re: cool
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 3 (+3/-0).
Bon … Ne jamais dire jamais… Surtout quand on a la nuit devant soit…
Le bouton "Export" a vu apparaître un export html qui reprend les emplacements des tables…
[^] # Re: cool
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 2 (+2/-0).
Ctrl+Z fait !
J'ai regénéré tous les diagrammes du site, donc sur ton modèle aussi ça fonctionne maintenant.
Par contre, le stockage des emplacements des tables, c'est pas faisable dans le fichier html en lui même… ou alors faudrait produire un autre html avec les nouvelles positions en dur. Mais ça complique beaucoup l'outil et on perd l'attrait d'un fichier html unique. Je pense qu'il faudra se contenter de l'export SVG pour ça :D
[^] # Re: Bonus méta : le schéma de LinuxFr.org lui-même, en time-lapse
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 1 (+1/-0).
A 5min prêt, ça peut marcher … ou pas !
En effet, j'avais une version du parseur déjà dans mcdview pour les .rb, mais je ne l'avais pas bien testé et elle ne fonctionnait pas correctement. Le dernier commit sur le sujet date de 20 min avant ton commentaire :D https://github.com/Gheop/mcdview/commit/82e88c2b0aea7fe9493ac091af1df4334e49f0ab
Et je suis entrain de me faire un jeu de modèles largement plus conséquent en .rb, donc va surement y avoir encore de nombreuses corrections.
[^] # Re: cool
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 2 (+2/-0).
Good job ! Merci de me confirmer que ça marche bien :D
Annuler la/les dernières actions seraient top en effet … faut que j'y réfléchisse, les positions déplacées sont déjà mémorisées en localStorage par visiteur, c'est devrait être assez facilement faisable sans alourdir le single file html. Je me le todolist.
Pour la case à cocher, je suppose que tu parles de "FK d'audit" ? C'est la possibilité de cacher/afficher les FK de traçabilité (créateur, modificateur… qui servent pour l'historisation et qui relient toutes les tables à une table "utilisateur modificateur") qui brouillent le diagramme. Ca se configure dans la page de gestion juste après l'import du fichier sur le site (on peut cocher/décocher les fk) et les plus reconnaissables sont normalement détectées par défaut. Ou configurable par regex par l'API aussi.
# Bonus méta : le schéma de LinuxFr.org lui-même, en time-lapse
Posté par Patu . En réponse au journal MCDView : un schéma SQL en diagramme entité-association interactif, en un fichier HTML statique. Évalué à 2 (+2/-0).
Petit bonus méta pour ce journal : j'ai passé le schéma de LinuxFr.org lui-même dans mcdview.
Le dépôt linuxfrorg/linuxfr.org versionne db/schema.rb. Je l'ai converti en SQL (tables, colonnes, clés étrangères) et donné à mcdview :
Un truc qui surprend dans la time-lapse : pendant des années, les tables flottent sans aucune relation. C'est fidèle au dépôt : jusqu'en 2018, LinuxFr ne déclarait aucune clé étrangère au niveau de la base (les associations vivaient côté modèles Rails). Elles arrivent d'un coup le 24 mars 2018, 29 FK dans le même commit.
Le diff que je préfère : le passage à Doorkeeper pour OAuth2 en septembre 2014. Deux tables maison retirées (client_applications, access_grants), trois tables Doorkeeper (oauth_*) ajoutées : https://mcdview.dev/d/iLZLe1NA40nAHy6Wdk7x8A/41
C'est reconstruit depuis le schema.rb public : la structure (tables, colonnes, FK), pas les index ni les types exacts, et rien n'est branché sur la base de prod. schema.rb étant du Ruby, mcdview ne le parse pas encore nativement, je suis passé par une petite moulinette schema.rb vers SQL.
[^] # Re: Efficacité, gains réels
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 2 (+5/-3).
Oui, bien sur, les briques existent, mais chacune traîne son runtime. fonttools (pyftsubset) subsette très bien, mais c'est du Python à installer. woff2_compress compresse, mais ne subsette pas et ne lit que le TTF/OTF. Et pour extraire le sous-ensemble depuis tes fichiers, on ajoute souvent glyphhanger, en Node. Il n'y avait pas de binaire unique, sans dépendance,sans runtime, pour toute la chaîne. Et c'est l'utilité de woffify.
Convertir, subsetter, et même scanner tes CSS/textes pour ne garder que les glyphes utilisés (-subset-scan), le tout dans un binaire statique unique, sans Python ni Node, pensé pour un CI léger (build de ton site) ou un conteneur. Un ordre de grandeur, sur ma Fedora, le binaire woffify fait 6 Mo. dnf install python3-fonttools réclame 19Mo une fois installé. Et il faut ajouter l'installation de Python. Plus d'autres outils pour faire le reste…
Sur les octets tu as raison,sur du TTF/OTF sans subsetting, la sortie est byte-for-byte identique à woff2_compress (même encodeur, Brotli 11), et le subset passe par le même HarfBuzz(hb-subset). Je ne prétends pas faire plus petit. woffify ajoute juste la couverture d'entrée dans ce même binaire : le WOFF 1.0, et l'EOT non compressé (le vieux format IE, un besoin que nous avions) que ni woff2_compress ni fonttools n'ouvrent.
Si ce besoin « un binaire, zéro dépendance, tous formats, dans un CI/docker » n'est pas le tien, fonttools reste parfait, garde-le. Si tu n'y vois pas de valeur, c'est sans doute que tu n'es pas la cible ;-)
[^] # Re: Rangez les fourches ?
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 4 (+5/-1).
Tout est faisable et … facturable, très cher mécène ;-)
[^] # Re: Efficacité, gains réels
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 2 (+3/-1).
Ça tombe bien, on a mesuré sur 40 polices réelles (des TTF Google Fonts) et publié les chiffres : https://patu.dev/fr/blog/fonts-woff2-and-subsetting
En deux temps :
- WOFF2 seul : −64 % médian (22 Mo → 7 Mo sur les 40)
- WOFF2 + subsetting latin : 22 Mo → ~1 Mo, soit 95 %
Et c'est là la nuance avec woff2_compress : il fait le premier temps (la conversion WOFF2, le −64 %), mais pas le subsetting. Le gros de la surprise est dans le second (7 Mo → 1 Mo) : une police Google traîne du cyrillique, du grec, du vietnamien, des symboles qu'un site latin ne rend jamais. woffify enchaîne les deux dans un seul binaire (subsetting via hb-subset de HarfBuzz). Sur la conversion WOFF2 pure, il ne fait pas mieux que woff2_compress, c'est le même conteneur Brotli.
fontcompressor.com fait aussi compress + subset, mais en ligne et à la main (upload, interface). woffify, c'est un binaire local qu'on glisse dans un build ou une CI, et rien ne quitte ta machine.
woffify subsette selon ce que tu lui donnes, soit des plages Unicode (-subset-unicodes), soit directement le texte utilisé (-subset-text, il garde les glyphes qui le couvrent). Il ne crawle pas le site lui-même : tu lui passes le texte réellement rendu (un -subset-text "$(cat contenu.txt)" dans le build suffit), et il ne reste que tes caractères. Pour un site multilingue, tu élargis les plages ou tu sers plusieurs subsets via unicode-range dans @font-face. Je te laisse imaginer ce que tu peux gagner sur tes fonts avec ça ;)
[^] # Re: quel algo jpeg ?
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 3 (+4/-1).
Et bien, nous utilisons jpegli, tiré de libjxl, justement ! le machin lent de Google.
Chez nous il tourne côté serveur, au moment de l'optimisation, pas à la livraison : on encode une fois et on met en cache. Le visiteur récupère ensuite le fichier déjà encodé depuis le CDN, il n'attend jamais l'encodeur. Et comme on vise une qualité perçue mesurée à la ssimulacra2 (pas un -q à l'aveugle), on fait une petite recherche de qualité par-dessus, ce qui rajoute encore du CPU en amont.
En mode « stored », c'est encore plus net : le POST renvoie tout de suite un 202 avec l'URL finale, un worker encode derrière, et l'URL sert l'original en repli tant que la version optimisée n'est pas prête.
Sur nos mesures, jpegli sort 16 à 32 % plus petit que libjpeg-turbo (mozjpeg) à score ssimulacra2 égal, parce que son modèle psychovisuel place les bits là où l'œil est moins sensible au lieu des tables de quantification fixes. mozjpeg (quantif trellis) joue dans la même cour, un cran au-dessus de la baseline, mais on a tranché pour jpegli. En repli, si cjpegli tombe, on repasse sur libjpeg-turbo via libvips.
Cela dit, pour beaucoup d'images on ne sort même pas de JPEG : AVIF ou WebP quand le navigateur suit, JPEG en filet de sécurité. Les chiffres à qualité perçue égale sont là si ça t'intéresse : https://patu.dev/blog/avif-vs-webp-vs-jpeg (la baseline JPEG y est en libjpeg-turbo).
[^] # Re: Encore un journal généré par un LLM...
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 2 (+5/-3).
Oui, tu peux forcer ton firefox chéri (parce que l'autre, il va juste te tracer) à utiliser les fonts que tu veux à la place des choix des webmasters ! Tu es libre !
Mais tu peux toujours compresser tes fonts favoris avec woffify :-) C'est magique ! le choix ET la légèreté.
[^] # Re: Encore un journal généré par un LLM...
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 1 (+5/-4).
C'est pas moi qui hallucine, c'est toi qui as croqué dans la pomme qui t'est tombée sur la tête ;)
On peut avoir envie d'un peu plus de fun que les polices du système … qui ne sont pas les mêmes suivants les systèmes/distros voire même desktop !
Mais la police du LLM … faudrait demander à Linus ce qu'il en pense : pcinpact.com/247523/linus-torvalds-sagace-une-nouvelle-fois-sur-lia-cette-fois-pour-la-defendre/
[^] # Re: Dredi
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 3 (+4/-1).
Wouah, fallait la trouver celle là !!
[^] # Re: Dredi
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 3 (+4/-1).
Bien vu. En moyenne sur la semaine, « il est vendredi quelque part » n'est vrai qu'environ 50h sur 168 : les fuseaux extrêmes (UTC-12 et UTC+14) sont à 26h d'écart, donc un jour donné existe 24+26 = 50h. Soit ~30% du temps, tu as raison.
Sauf que là je poste un vendredi en début d'après-midi heure de Paris (UTC+2 en été), soit ~13h UTC : à cet instant c'est vendredi de UTC-12 à UTC+10, environ 85% des fuseaux. Mon CQFD est donc sauf… jusqu'à ce que quelqu'un relise ce journal un mardi. Merci pour le rapport de bug, je passe la note en 0.8-stable !