Display PostScript

Tu t’es déjà demandé pourquoi t’arrivais pas à imprimer un document exactement comme tu le voyais à l’écran ?

Avant, c’était pas du tout évident.

Un affichage d’un côté.
Une impression de l’autre.
Deux mondes séparés, qui parlaient pas la même langue.

Et c’est là qu’arrive Display PostScript, ce petit bijou trop souvent oublié.

On est à la fin des années 80.
Adobe a déjà posé les bases avec PostScript : un langage de description de page, ultra précis, pour piloter les imprimantes laser.
Mais à l’écran ? Nada. Chaque OS faisait son petit tambour dans son coin, avec des APIs maisons, pas de standard, pas de preview fidèle, et beaucoup de frustration.

C’est NeXT (oui, la boîte de Steve Jobs après Apple) qui va changer le game.
Ils veulent un OS élégant, moderne, orienté développeur, mais surtout avec un rendu graphique WYSIWYG : What You See Is What You Get.

Ils prennent donc PostScript, et l’adaptent pour l’écran :
Display PostScript était né.

Pour la première fois, ce que tu dessinais à l’écran, c’était exactement ce qui sortait de l’imprimante.
Même moteur, même langage, même qualité vectorielle.
Tu pouvais zoomer, transformer, animer des éléments graphiques avec une précision de malade — dans les années 90 !

C’était lourd, pas toujours rapide, mais tellement en avance sur son temps.
Une vraie vision d’ingé.

Et guess what ?
Quand Apple rachète NeXT pour créer macOS, c’est cette vision graphique qui va poser les bases de Quartz 2D.
Aujourd’hui encore, ton PDF, ton écran Retina, ton antialiasing clean ? C’est l’héritage direct de ça.

Comme souvent dans l’histoire de l’informatique, c’est une frustration de dev qui déclenche une révolution.
Et ça me parle.

Toi aussi t’as eu ce moment où tu t’es dit “pourquoi ça marche pas comme ça devrait” ?
T’as déjà eu envie de recoder tout un bout de stack juste pour pas avoir à subir une limitation débile ?