Noyau Graphique d'Images Structurées

--ooOoo--

     Durant ma carrière, j'ai été confronté maintes fois aux problèmes liées à la diversité des bibliothèques graphiques livrées avec les moniteurs d'exploitation des différentes machines dont l'équipe-système à laquelle j'appartenais avait la charge. Ces librairies étaient des librairies propriétaires comme :

     A l'époque, toutes ces bibliothèques s'appuyaient sur une norme "GKS" (Graphic Kernel System) qui étaient censées simplifier l'écriture des programmes. En fait, au Bureau d'Études en particulier, les ingénieurs rencontraient pas mal de problèmes quand ils devaient travailler sur plusieurs machines de marques différentes ayant les matériels graphiques différents.

     Il s'en suivi alors le besoin d'écrire une bibliothèque de primitives graphiques (fonctions de base appelables dans des programmes) et de directives graphiques (commandes en mode console), en nombre le plus restreint possible, capables de prendre en compte tous les types de terminaux graphiques existant sur les différentes machines de l'usine. Au sein de l'équipe-système, j'ai donc été responsable de l'écriture d'une bibliothèque graphique nommée initialement "Noyau Graphique" au début des années 1970 et qui évolua au fil des années. Fallait-il suivre les recommandations "GKS" ? Pas spécialement, la bibliothèque était vouée à un usage interne sans aucune intention de commercialisation. Par ailleurs, la normes GKS proposait des primitives pour gérer des images à un seul niveau ce qui ne simplifiait pas, en particulier dans des environnements temps réels, la programmation des mises en page des affichages fixes et animés simultanés de paramètres de surveillance.

     Cette rubrique expose l'une des approches du traitement graphiques sur ordinateur. Une de plus me direz-vous ? très humblement, je crois, ou du moins je l'espère, elle présente une petite originalité que je n'ai pas encore vu moi-même durant mon activité, que j'avais mis en application à l'époque et qui n'est restée qu'un exercice de style puisqu'elle n'est jamais sortie du périmètre de l'usine où je travaillais.

     Ce traitement graphique sur ordinateur était mis à la disposition des programmeurs et des utilisateurs. Cette bibliothèque était écrite principalement en assembleur et en langage C sur les stations de travail Unix. Seulement, aujourd'hui, je suis sur Internet et, pour l'exposer, j'avais projeté de la programmer en langage PHP pour simplement l'illustrer mais cela ne s'avérait pas très évident quand même. Il m'est apparu qu'utiliser JAVA me semblait trop lourd pour le besoin. Au bout du compte, pourquoi pas en C après tout ?... en réadaptant les sources C de l'époque tout au moins ceux qui ont échappé aux secteurs défectueux de mes disquettes 3,5 pouces vieilles de plus d'une vingtaine d'années. Les autres, irrécupérables, seraient alors à réécrire complètement.

     On verra bien ce que cela donnera... et puis ... cela vaudra ce que cela vaut !... On ne perdra pas de vue toutefois que ce logiciel essentiellement orienté vers des sorties papier sera alors reconstitué dans son jus d'origine, ou presque, des années 1980-1985 c'est à dire bien antérieur aux traitements graphiques et de textes que l'on connaît aujourd'hui et qui ont commencé à apparaître avec l'arrivée sur le marché des stations Unix et des premiers PC IBM sous DOS repris ensuite par Microsoft avec son MSDOS et son Windows 3.1. On pourra alors avoir une idée de l'évolution du progrès des techniques graphiques depuis cette époque que j'ai trouvée assez exaltante.

     Il sera souvent fait référence à la Documentation Technique dont j'avais eu la charge informatique dans le domaine graphique à Marignane. Cette fantastique application, d'une grande richesse, est un centre de focalisation de tous les problèmes en matière d'illustrations informatisées que l'on peut rencontrer car, par vocation, elle est en contact permanent avec tous les secteurs d'étude et de production de l'usine. Mémoire de l'entreprise, la documentation technique devrait en être le ''noyau'' autour duquel devraient graviter tous les départements qui composent la société.

     Il faut bien voir que la Documentation Technique d'un produit a valeur de ''cahier des charges'' de ce dernier et que, logiquement, elle devrait être réalisée avant sa fabrication pour être peaufinée par la suite. Malheureusement, cette manière de voir a souvent été considérée comme du temps perdu avant vente.

     Pour information, le coût du premier jeu de brochures d'un hélicoptère correspond au coût réel d'un appareil. C'est quand même financièrement très lourd mais juridiquement obligatoire.

--ooOoo--