Contribuer à Postext

Construire ensemble le moteur de mise en page éditoriale que le Web n’a jamais eu.

Postext est un projet open source porté par sa communauté. Il veut résoudre un problème ignoré depuis des décennies : apporter au Web une mise en page éditoriale de niveau professionnel. C’est une grande ambition, et elle demande plus d’une personne.

Le projet est jeune, mais ce n’est plus une page blanche : la chaîne de mise en page, le format de document et le système de configuration sont tous livrés. Beaucoup de décisions de conception restent pourtant ouvertes, et les personnes qui contribuent dès maintenant ont une vraie influence sur la direction du projet. Si vous attendiez le bon moment pour nous rejoindre, c’est maintenant.

Pas besoin d’être programmeur pour contribuer. Que vous écriviez du code, conceviez des maquettes éditoriales, connaissiez la typographie, testiez sur plusieurs navigateurs, rédigiez de la documentation, traduisiez des contenus ou ayez simplement des idées sur la façon dont le contenu éditorial devrait fonctionner sur le Web, il y a une place pour vous ici.

#Pourquoi contribuer

Tous les ateliers de développement éditorial du monde se heurtent au même problème : CSS n’a pas été conçu pour la mise en page éditoriale. Il n’offre aucune prise en charge native de l’équilibrage des colonnes, de la prévention des veuves et des orphelines, de l’habillage du texte autour d’obstacles ni du placement des notes de bas de page. Chaque équipe résout ces problèmes en partant de zéro, avec des solutions fragiles et ponctuelles, coûteuses à maintenir et impossibles à partager.

Postext veut changer cela. Pas comme un outil propriétaire, mais comme un standard ouvert et partagé : un moteur de mise en page unique et de haute qualité que les éditeurs, les magazines, les journaux, les plateformes de livres et les équipes de développement du monde entier peuvent adopter et enrichir.

Un tel standard ne peut pas être construit par une seule personne ni par une seule entreprise. Il a besoin du regard de typographes issus de traditions différentes, de spécialistes du PDF, d’experts en accessibilité, de développeurs qui travaillent avec les écritures de droite à gauche, de maquettistes de magazines et d’ingénieurs qui optimisent les performances du rendu. La diversité du monde éditorial exige une communauté tout aussi diverse derrière l’outil qui le sert.

#Comment nous travaillons

Toute la coordination se fait sur GitHub. Pas de canaux privés, pas de listes de diffusion fermées, pas de décisions prises à huis clos. Tout est public, consultable et ouvert à la participation.

• Issues : pour les signalements de bogues, les demandes de fonctionnalités et les tâches précises. Si vous voulez travailler sur quelque chose, commencez ici.
• Pull Requests : pour les contributions de code. Ouvrez d’abord une issue pour discuter de l’approche avant d’écrire du code.
• Discussions : pour les idées, les échanges de conception, les questions et tout ce qui n’est pas un bogue ou une tâche précise. C’est l’endroit où réfléchir à voix haute.

C’est un choix délibéré : quand tout vit au même endroit, chacun peut retrouver le contexte de n’importe quelle décision, et les nouveaux venus peuvent lire l’historique.

#Domaines où vous pouvez aider

Le projet a besoin de compétences très variées. Voici quelques domaines où les contributions sont particulièrement précieuses :

#Code et algorithmes

• Algorithmes de mise en page typographique : le moteur de justification Knuth-Plass, l’équilibrage des colonnes, la coupure optimale des paragraphes, la numérotation typée des ressources et le placement des flottants.
• Génération de PDF : construction bas niveau du PDF, incorporation des polices, gestion des couleurs et traitement des octets de ressources pour les figures en une seule encre.
• Rendu du texte : rendu sur canvas, sortie SVG, recoloration des SVG en une seule encre (diagramStyle.singleInk), métriques des polices.
• Optimisation des performances : la couche de cache des mesures, et un moteur de mise en page assez rapide pour un usage en temps réel à chaque redimensionnement.

#Sandbox et interface

Le Sandbox est devenu une interface React conséquente à part entière : un panneau Ressources avec un éditeur de tableaux interactif et l’import d’images et de SVG, un panneau des polices et un panneau Maquette dont les douze groupes couvrent tous les recoins du moteur. Ses contrôles reposent sur les primitives Base UI (packages/postext-sandbox/src/ui/) et sont vérifiés avec axe-core pour WCAG 2.1 AA ; les nouveaux contrôles doivent donc les réutiliser et garder chaque champ nommé par son libellé et décrit par son texte d’aide. Chaque chaîne de l’interface suit une convention d’i18n stricte, câblée par des libellés à travers cinq fichiers répartis entre le paquet du Sandbox et les catalogues de langues de l’application web. Si vous contribuez au frontend ou à l’UX, c’est ici que votre travail atterrit.

#Maquette et typographie

• Expertise en maquette éditoriale : si vous avez l’expérience de la mise en page de magazines, de journaux ou de livres, votre connaissance de ce qui fait fonctionner (ou échouer) une mise en page est inestimable, sans écrire une ligne de code.
• Traditions typographiques : le projet doit respecter les conventions typographiques de langues et de systèmes d’écriture différents, pas seulement des écritures latines.

#Documentation et communauté

• Documentation : améliorer, étoffer et entretenir la documentation. Une documentation claire fait la différence entre un projet que l’on adopte et un projet que l’on abandonne.
• Traductions : la documentation est actuellement bilingue (anglais et espagnol). D’autres langues sont les bienvenues.
• Tests : tester sur différents navigateurs et systèmes d’exploitation, et sur les cas limites. Trouver les mises en page qui cassent vaut autant que construire celles qui fonctionnent.

#Conception du format et du schéma

Le format n’est plus une page blanche : les blocs ::resource, les références en ligne :ref et les sections de configuration tableStyle, captionStyle et diagramStyle sont tous livrés. Le travail consiste désormais à faire évoluer un format établi sans le casser :

• Grammaire du document : les notes marginales et les renvois au-delà des ressources restent des questions ouvertes, chacune autant un problème de conception qu’un problème technique.
• Schéma de configuration : garder le système assez puissant pour les professionnels et assez simple pour les débutants à mesure qu’il grandit.

#Premiers pas

La mise en place pratique (cloner le dépôt, installer les dépendances, lancer les tests) est documentée dans CONTRIBUTING.md. Commencez par là pour les étapes mécaniques.

Une fois votre environnement prêt, voici trois actions concrètes, de l’engagement le plus léger au plus lourd :

1. Présentez-vous dans les Discussions : dites sur quoi vous travaillez et ce qui vous amène. Aucune question n’est trop simple, et c’est le moyen le plus rapide pour que la communauté sache que vous êtes arrivé.
2. Prenez une good first issue : elles sont choisies pour être un point d’entrée réaliste, sans contexte historique caché à connaître.
3. Traduisez la documentation dans une nouvelle langue : aujourd’hui, la documentation existe en anglais et en espagnol. Toute troisième langue est un cadeau pour les lecteurs actuellement laissés de côté.

Si vous comptez écrire du code, ouvrez d’abord une issue pour discuter de l’approche : cela évite le travail en double, et une courte conversation en amont fait gagner du temps à tout le monde.

#Que lire ensuite

Pour vous repérer avant de vous lancer :

• Architecture : comment la chaîne de mise en page est structurée et où vit chaque sous-système.
• Format de document : la grammaire Markdown enrichie que les contributeurs étendent.
• Sandbox : le bac à sable où la plupart des modifications sont les plus faciles à voir et à tester.

#La communauté

Postext en est encore à ses débuts, et c’est précisément ce qui rend ce moment particulier. Les personnes qui contribuent maintenant n’écrivent pas seulement du code : elles façonnent les conventions, les priorités et la culture du projet.

Le projet privilégie :

• La réflexion plutôt que la vitesse. Trouver les bonnes abstractions compte davantage que livrer vite. La typographie s’est affinée au fil des siècles ; nous pouvons prendre le temps de bien faire.
• La clarté plutôt que l’astuce. Un code facile à lire et à comprendre vaut plus qu’un code impressionnant mais opaque.
• La collaboration plutôt que les territoires. Personne ne possède une partie du code. Les idées sont jugées sur leur mérite, pas sur la personne qui les propose.

Toutes les contributions sont reconnues. Ce projet existe parce que des gens choisissent de consacrer leur temps à l’améliorer.

#Vision

Postext veut devenir le moteur de mise en page de référence pour le contenu éditorial sur le Web : l’outil vers lequel se tournent les éditeurs, les magazines, les journaux et les plateformes de livres quand ils ont besoin d’une typographie professionnelle.

Si vous travaillez dans le développement éditorial et que vous résolviez jusqu’ici ces problèmes de mise en page seul, voici votre invitation à les résoudre une fois pour toutes, correctement, avec d’autres.