Commentaires du préambule

J'ai dit que j'avais été amené à faire à mon projet quelques entorses qui ont nécessité de la programmation :

Pour revenir à la fonction vectorielle, ces outils et ces services ont permis de construire simplement des illustrations au trait intéressantes puisque, dès que l'on sait tracer un tout petit vecteur, on peut en tracer des milliers plus grands qui font des dessins parfois encombrés comme pour la locomotive en bas de l'exemple ci-dessous :

qui est bien évidemment une illustration autonome à part entière de la base de données des illustrations. Éventuellement, elle pourra être appelée dans d'autres illustrations comme on pourra le voir par la suite.

En tout premier lieu, le nombre de directives graphiques (commandes en mode console) et de primitives graphiques (fonctions appelables dans les programmes) devait être le plus réduit possible. Cela n'a été possible qu'en spécifiant des attributs de fonctionnalitées assez fournis. Il s'était avéré que moins il y avait de directives et de primitives moins l'utilisateur avait besoin de chercher leur ordre chronologique d'appel que lorsqu'il y en avait une multitude, comme c'était et c'est souvent le cas des librairies publiques proposées. Quant aux attributs, il était plus aisé de les définir en se confectionnant un petit mémorandum. Il faut bien voir que, dans ma société aéronautique comme ailleurs probablement, pour des ingénieurs en structure, en mécanique, en vibration, en cinématique, en fabrication, etc..., même s'il savaient suffisamment programmer pour les besoins de leur besogne, l'informatique n'était pas du tout leur objectif ni leur préoccupation. C'était plutôt une super-calculette qui devait surtout alléger leur travail. Ils étaient en général très sensibles à l'aspect intuitif des applications et étaient donc assez critiques envers les informaticiens campés dans leur tour d'ivoire !... Ce qu'il voulaient, c'était pouvoir travailler avec leurs programmes indifféremment sur des écrans IBM 3279, des traceurs Benson ou Tektronix, des écrans à mémoire phosphorique, des imprimantes lasers ou électrostatiques.

Pour réaliser les dessins vectoriels montrés ici, issus des logiciels de dessin industriel et autres, il aurait fallu développer une interface interprétant des fichiers de type ''.dxf'', ''.svg'', ''.cgm'', au standard ''xml'', par exemple, il a le vent en poupe ou tout simplement acquérir un pilote HPGL ou un logiciel du type ''Graphic Images Converter'' qui convertissent des fichiers ''.dxf'', ".dwg'', etc... en fichiers ''.hpgl'', ''.cgm'', etc... pour ne citer que cela et vice versa. On en trouve sur la Toile. Généralement ce sont des ''shareware''. Il y en a une multitude. C'est dire à quel point le sujet est lucratif. C'est ce qui est normalement fait en environnement industriel où l'on peut plus facilement rentabiliser l'investissement soit financier, soit en programmation. Pour ma part, il m'a fallu chercher un format facile à décoder et à interpréter dans la ''pétaudière'' de tous ces formats et de tous ces standards (qui n'ont que le nom). Ils évoluent tout le temps et l'on se trouve les otages d'une perpétuelle obligation de mise à niveau. Je cherchais tout simplement un format pour un traceur de courbes à n plumes, tout ce qu'il y a de plus trivial, c'est du ''hardware'' et cela ne bouge pas beaucoup, pour ne pas sombrer dans des développements qui ne m'intéressaient pas pour la démonstration. D'ailleurs, j'ai du mal à comprendre, même à admettre, que des logiciels de dessins industriels qui débouchent sur de la fabrication, en particulier commandes numériques, n'intègrent pas en sortie, systématiquement en standard, tout particulièrement le format ''G-code'' pour machines à commandes numériques en premier lieu et/ou au format ''hpgl'' facilement compréhensible et programmable que les développeurs de HP ont réalisé avec pragmatisme et réalisme. Tous deux sont assez facilement décodables pour pouvoir être repris à des fins particulières comme dans le Noyau Graphique. Un dessin industriel est fait pour déboucher sur une fabrication dans les plus bref délais et le fabricant n'a que faire de toutes les fioritures inutiles destinées surtout aux publicitaires. Dans la vie économique, il n'y a pas qu'eux. Je ne comprends pas pourquoi les prestataires se sont concertés, je pense, pour ne pas adopter un tel type de format d'une extrême simplicité qui a peu besoin d'évoluer et qui, au minimum conviendra la plus part du temps avec pérennité.

Mais, de mon point de vue encore, la compatibilité ascendante et la pérennité ne sont pas les soucis majeurs des développeurs, me semble-t-il. A regarder l'évolution des systèmes, les efforts sont mis sur la présentation, les animations, etc.. l'écran clignote de pleins de ''petits bonhommes verts'', et l'excès de couleur en fait un ''arbre de Noël'', tout cela bien long à télécharger !... bref, ce que, pour moi, je considère comme de la frime mercantile qui attire l'oeil pour faire acheter et pour masquer les faiblesses. Sous Windows 7, ils ont même dépensé des heures de programmeurs (!!!) pour réduire des programmes à la baisse en possibilités par rapport aux systèmes de versions précédentes comme par exemple :

Je peux en citer bien d'autres encore... Bref, la robe de la mariée est magnifique, elle a couté très cher mais que dire de la mariée elle-même !... Quant au mode compatibilité !... une plaisanterie qui ne marche même pas ou rarement pour des versions d'un même type de moniteur. Il m'a fallu à regret, entre autres, renoncer à des logiciels bien intéressants comme MicroCADAM par exemple qui, de mon point de vue, est plus simple d'utilisation que ProgeCAD (compatible AutoCAD) où bien des fonctions sont utilisées dans 2% des cas par 2% des utilisateurs. Je ne suis pas certain d'exagérer. Ce vieux programme de dessin industriel, finalement assez intuitif contrairement à ceux d'aujourd'hui, proposait, lui, une interface pour produire un fichier liste d'image en ''hpgl'' version 2 pour traceurs multiplumes qui servait à l'époque à produire les dessins en documentation technique. C'était un autre temps... mais pas du tout d'un autre temps !...

Si MicroCadam n'est plus maintenu par Dassault System, un autre logiciel de dessin, plus moderne et, en principe, très abouti le remplace presque avantageusement : c'est le logiciel gratuit (pour le moment !...) de dessin industriel ''DraftSight'' de Dassault System. Et pourtant, je n'ai toujours pas réussi à trouver le moyen d'appliquer un facteur d'échelle différent sur des abscisse et des ordonnées !... (Sous ce vieux MicroCadam, l'échelle en X, en Y et même en Z est proposée d'emblée. Ils auraient mieux fait de s'en inspirer. Ce qui est vieux n'est pas forcément mauvais et ce qui est moderne pas forcément utile). Certes, on doit très certainement pouvoir le faire mais là, on ne peut pas dire que l'intuitivité est l'une de ses caractéristiques, comme celle de beaucoup de logiciels d'aujourd'hui. Les exemples de cette nature ne manquent pas par ailleurs. Sans être trop polémique, il faut peut-être entretenir artificiellement des profits par une surévaluation des coûts de service et des profits sur de la formation !...

Je balayais donc les logiciels d'aujourd'hui que je possédais, 3D, ''AutoDesk 123D'', ''Blender'', ''Rhinocéros'', 2D, ''ProgeCAD 2009'', ''DraftSight'', ''A9CAD'', ''Inkscape''. Eh bien... c'est ce dernier qui m'a fourni un format trivial ''.hpgl'' et ''.plt'' de très très bas niveau (une seule plume donc une seule couleur). Il semble avoir du reste quelques soucis avec certaines courbes et aussi avec son convertisseur ''uniconvertor'' de SK1. C'est dire le peu d'enthousiasme que ses développeurs ont mis pour proposer quelque chose de correct. Mais bon... dommage !... les quelques dessins ''.hpgl'' que MicroCadam m'a produits suffiront quand même. On peut signaler tout de même qu'il est possible d'ajouter une extension à Inkscape "THlaser Plugin'' qui produit un fichier ''.ngc'' au standard ISO G-code. Je l'ai implantée et les fichiers ''.ngc'' générés sous Inkscape me paraîssent assez simple à traiter. Il ne faut pas oublier qu'une machine à commandes numériques est un terminal graphique 2D, 3d, et même 5D. Dans cette dernière option, les 2 axes suppléméntaires sont l'inclinaisaon de la tête ou du plateau suivant les abscisses et les ordonnées pour contourner certaines difficultés de passage et effectuer des usinages tangentiels. Il y en avait une superbe à l'époque, une ''Forest'' munie d'une gigantesque rosace de 32 outils à chargement commandé. Le standard ISO G-code est fort intéressant car il peut parfaitement être utilisé comme une base d'exportation en assurant une grande pérènité. Avec le gigantesque parc de machines-outils, personne ne s'amusera à remanier profondément ses convensions sans tenir compte de la compatibilité ascendante.

Un programme ''ng_hpgl.c'' a donc été écrit pour traiter ce fichier liste-d'image ''.hpgl'' où il y a un moins de travail qu'avec le standard ISO G-code mais tout aussi facile à décoder. Bien sûr, il est surtout question de ne traiter que les fonctions les plus usitées. On voit que le dessin de la locomotive 'Big Boy' américaine est bien surchargé puisqu'il était, à l'origine destiné à être imprimé sur une imprimante format A0. La page comporte aussi le dessin d'une horloge à fabriquer en bois ou en carton et des 3 vues d'une maquette d'un avion ancien français, le ''Dalotel''.

D'une manière générale, quand on achète un produit, une voiture, une machine à laver, un ordinateur, etc... une documentation est fournie sous forme d'un petit livret dans lequel sont consignés les procédures d'installation, le mode d'utilisation et le guide d'entretien, pour les plus courants.

En aéronautique, ce n'est pas tout à fait pareil. A chaque appareil vendu, à l'époque mais je pense que c'est peut-être toujours le cas, la législation imposait de fournir un lot de manuels documentaires portant sur l'intégralité de l'appareil et, de plus, adaptées aux personnalisations demandées par le client. C'était par exemple :

Je ne m'en souviens plus très bien, même de leurs noms, mais il y en avait une bonnes dizaines par appareil et personnalisés à chaque client qui demandaient des modifications et/ou des aménagements. Cela en faisait beaucoup et une application spéciale de gestion de ces personnalisations étaient maintenue pour produire les listes de pages de tous ces manuels.

Pour accompagner ces manuels, certaines brochures, les ''Steering Guides'' (guides de pilotage), si je me souviens bien, n'avaient qu'un rôle d'explication et d'information du client sur justement l'utilisation de tous ces manuels. Pour ce faire, ces brochures faisaient référence à certaines pages des différents manuels, qui étaient alors réduites puis placées parfois les unes sur les autres en se recouvrant partiellement pour des raisons de place, le format étant le A4 avec parfois des pages A3. Toute cette composition se faisait à la main, avec photocopieuse, paire de ciseaux et colle, pour confection de masques, de calques, d'encarts, voire même d'excarts, etc... C'était fastidieux.

Avec l'aide de l'informatique, pour la partie composition graphique documentaire et non la partie gestion, un autre volet de la Documentation Technique, il fallait en réalité assurer exactement les mêmes fonctions de photocopieuse, de ciseaux, de colle et de masques. Ces pages originaires des manuels devaient donc pouvoir être réduites, tournées, manipulées avec une qualité satisfaisante. C'est pourquoi, la fonction vectorielle du logiciel graphique était indispensable.

Seulement, dans la superposition partielles des pages, le résultat aurait été un énorme gribouillage avec la seule fonction vectorielles. La fonction d'effacement avait donc la vocation :

La manipulation des pages de manuel se faisait avec l'application ''O.C.Ap.I.", (exemple ICI).

C'est dans le secteur de traitement des illustrations que le problème se posait avec plus d'acuité.

Jusque là, si les textes étaient saisis et mis en forme sans gros problème grâce à des terminaux semi-autonomes Honeywell Bull TTX 80, les illustrations étaient elles réalisées à la main sur table à dessin, pas toujours dans le format adapté aux pages dans lesquelles elles devaient prendre place. En effet, suivant la brochure, une même illustration pouvait avoir des taille différentes. Elles étaient alors réalisées dans le plus grand format pour être réduites si besoin, la qualité n'étant pas altérée dans la manipulation sur la photocopieuse. Cette dernière, à grande résolution, jouait là à plein son rôle pour confectionner les transparents à plaquer sur les pages de textes.

Le but du traitement informatique était alors de faciliter ces opérations coûteuses en temps. Il fut donc installés un certain nombre d'écrans graphiques de type IBM 2250 connectés au central informatique sur lesquels tournait le logiciel de dessin industriel CADAM (Computer Augmented Design And Manufacturing développé à l'origine par Lockheed). Les dessinateurs se mirent donc à entreprendre leur recyclage pour remplacer leurs planches à dessins par des écrans CAO non sans dégâts pour certains hélas ! Mais une paire d'années plus tard, le nombre de dessinateurs et de traceurs sur écrans CAO avait plus que doublé dans toute l'usine.

Si tous les dessins CADAM produits à partir de ces stations graphiques ne posaient guère de problème quant à leur insertion dans les pages, que devait-on faire pour traiter l'héritage des illustrations-papier stockées dans les archives auxquelles nous devions faire référence obligatoirement ?

Avec ma participation en qualité de conseiller informatique, il fut alors entrepris la recherche d'un scanner, périphérique qui ne courait pas les rues à cette époque et qui, de plus, était hors de prix, rien à voir donc avec ceux d'aujourd'hui, en couleur !... Notre attention fut attiré par un scanner belge, en cours de développement. Je ne me souviens pas du tout du nom de l'entreprise. Il permettait la numérisation de documents A4 en noir et blanc et il possédait un écran TTX muni d'un applicatif de traitement de texte analogue à celui des TTX 80. C'est ce qui séduisit le chef du département du Central Documentation qui fit le nécessaire pour son acquisition.

C'est ainsi que commença l'aventure des numérisations du patrimoine. C'est avec ce scanner que furent numérisées certaines des illustrations des exemples ICI.

Au départ, nous nous contentions de plaquer les illustrations digitalisées au format papier. Un programme assez simple avait pour but de surcharger ces images sur les textes au moment des impressions sur la Benson électrostatique du centre, exactement suivant le principe des calques. C'était une démarche de départ car si une même illustration était appelée dans des formats différents, nous étions contraints de numériser la même image autant de fois que nécessaire. Ces opérations avaient l'inconvénient majeur d'occuper beaucoup de place sur disque malgré le standard TIFF compressé aux normes Groupe 4 du CCITT, utilisé pour les envois de fax. Justement, parce qu'il intégrait la compression Groupe 4 du CCITT, les responsables de la Documentation technique s'intéressaient tout particulièrement au format CALS pour l'archivage d'images de points.

En ce qui me concernait, je n'avais pas d'à priori sur les formats à utiliser, je souhaitais simplement diversifier les possibilités pour que nous soyions pas, si possible, les otages de prestataires qui n'auraient pas manquer de profiter de la situation. Ce qui me préoccupait surtout à ce stade de l'avancement de l'application était avant tout la manière de réaliser les illustrations le plus aisément possible. Après, il y avait tous les moyens et les outils pour les stocker dans des formats choisis que je souhaitais pérennes en premier lieu.

Très rapidement, le besoin de les redimensionner se fit grandement sentir. Le problème auquel on se heurtait évidement découlait directement du fait que le point(raster) noir ou blanc n'est pas redimensionnable :

Le moyen le plus simple pour conserver à l'illustration une certaine crédibilité dès que l'on s'éloignait en plus ou en moins du facteur 1 de transformation était de considérer le fond blanc (raster=0) de l'illustration comme transparent et d'effectuer la transformation sur les points noirs en balayant les abscisses et les ordonnées suivant les côtés les plus grands des deux images émettrice et réceptrice. Ainsi, dans toutes réductions, un pixel donnait toujours un pixel.

Ici, les pixels ne sont pas codés sur 1 bit mais sur 32. Il faut donc indiquer aux primitives de traitement de transformation (''ngi_getimg.c'' ou ''ngi_cpyim.c'') un tableau des composantes des couleurs à considérer comme transparentes. J'ai été obligé de réécrire ces dernières : impossible de les récupérer à partir des disquettes.

L'illustration ci-dessous a été générée uniquement au trait dans une structure du Noyau graphique (qui sera la source) comme si elle avait été numérisée avec le scanner de l'époque. Je n'ai pas utilisé mon scanner personnel car, sa résolution étant très fine (600dpi), il m'aurait fallu présenter des images trop grandes, en restant à l'échelle 1, pour percevoir les effets parasites des transformations et de plus, il traite les images pour en améliorer le rendu ce qui n'était pas le cas à l'origine :

l'horloge est dessinée en noir et blanc. En imprimant cette page, le résultat me paraît assez proche de ceux que nous avions.

j'en ai profité pour montrer que les résultats sont indépendants de la couleur en plaçant la locomotive.

ng_erse ^c ; au_trait_01.prc ^c

Il s'agit maintenant d'extraire à partir de l'image de la structure-source ci-dessus des zones à placer dans une image d'une structure destinataire du Noyau graphique. Ici c'est un shell tout simple qui lance les différents transferts pour élaborer l'illustration résultat ci-après :

ng_erse ^a ; au_trait_02.prc ^c ^a

Les phénomènes sont bien visibles à l'écran alors qu'à 200 ou 300 points au pouce sur l'imprimante, le résultat est tout à fait exportable mais les calculs sont beaucoup plus longs et augmentent en fonction du carré du rapport d'échelle. Que constate-t-on ?

les images 1 et 1' sont transférées à l'échelle 1. Elles sont parallèles à elles-mêmes. Mais les calculs de transformations sont cependant effectués. Il y a une légère différence entre la source et la destination,

les images 2 et 2' sont grossies dans le rapport 1,333 et pivotées. Le bruit qui grossit et s'amplifie avec le rapport de grossissement car des pixels sont ajoutés, ne dépend pas de la taille de la pixelmap.

les images 3, 3', 4, 4', 5, 5' sont réduites progressivement. Aucun pixel n'est supprimé. La transformation les surcharge éventuellement et les pixels de fond d'images doivent être ignorés. C'est pour cela que l'illustration noircit ou fonce de plus en plus.

l'image 6 est une transformation de fantaisie simplement ajoutée ici puisque la fonction est native. Sans grand intérêt la plupart du temps, elle est quand même parfois utilisée, pour plaquer, par exemple, des illustrations sur les faces d'un polyèdre.

Si on peut tirer profit de ce genre de manipulation avec des résultats corrects sur imprimante, j'avoue ne pas voir comment faire pour améliorer les traitements sur écran. Le problème ne doit pas être très aisé, même avec des traitements d'anticrénelage, car beaucoup de logiciels se retrouvent dans le même cas.

1)	Le Noyau Graphique d'Images Structurées présenté ici travaillait d'abord au tout début, sur des pixelmaps de 8 bits par pixel (256 couleurs) alors que celle d'origine travaillait sur des bitmaps, deux couleurs, donc noir et blanc. Les imprimantes laser et électrostatiques de l'époque ignoraient la couleur d'une part et, d'autre part, la puissance des machines et leurs capacités mémoire vive et de masse n'avaient rien à voir, en comparaison, avec celles, pour moi, pléthoriques des ordinateurs d'aujourd'hui. Je suis loin de m'en plaindre, bien au contraire car j'ai eu le privilège d'avoir travaillé sur ces machines d'antan et d'avoir vu de mes propres yeux l'évolution pas à pas de l'informatique et des nouvelles technologies. Pour donner une petite idée de l'évolution, sans parler de la mémoire vive, mon PC actuel de moins de 1000 € est équipé :
	a)	de deux disques internes de 600 Go, c'est à dire :
		-	3 fois la capacité de mémoire de masse de l'ordinateur central IBM 390/OS390 de mon entreprise qui était de 400 Go raid juste avant que je parte en retraite,
		-	100 fois la capacité de mémoire de masse de l'ordinateur MINI 6/DSP 6 Honeywell Bull du département de la Documentation Technique qui était alors de l'ordre de 12 Go pour rester au dessus de la vérité et sur lequel fonctionnait l'application ''O.C.Ap.I.'' (Organisation et Composition d'Applications Interactives), application-fille, écrite en assembleur et en Fortran sur DPS 6, de l'application équivalente, écrite en langage C, ''S.C.Ap.In'' (Système de Composition d'Applications Interactives) sur Apollo, reconduite ici
	b)	de deux microprocesseurs d'une vitesse de 1,60 GHz chacun :
		-	je n'ai pas de point de comparaison avec le central IBM sur lequel je travaillais,
		-	alors que, sur le DSP 6 sous ''O.C.Ap.I.'', sans mémoire virtuelle et 2 mégaoctets de mémoire vive, le traitement uniquement vecteur (!!..) d'un support de composition comme celui des fichiers ''sca_compo_02.sc'' ou ''sca_compo_03.sc'' aurait duré 2 à 3 minutes sur un Tektronix 4015, si ce n'est plus, en partie à cause de la liaison série 9600 bauds avec l'ordinateur, le calcul de ce même type de page à 200 points par inch durait au moins 5 ou 6 minutes à réaliser puis à imprimer ensuite en batch différé sur une imprimante électrostatique Benson. Sur mon PC, il dure tout juste une dizaine de secondes à générer, c'est-à-dire 30 à 50 fois plus rapide... Quel confort !... Il faut tout de même dire que 95% des pages des manuels étaient beaucoup plus simples que les pages données ici en exemple. Mais il y en avait quelques-unes tout de même. L'ordinateur travaillait chaque nuit entière. La petite vidéo ci-dessous de 20 secondes illustre la rapidité avec laquelle le shell ''sca_compo_05c.prc" réalise cette page en s'appuyant sur le programme 'S.C.Ap.In'' et en s'appelant lui_même par récursivité. Derrière toutes ces images, il contraint la CPU à effectuer pas mal de besogne. Il pousse, à mon sens, le concept du Noyau Graphique dans ses derniers retranchements. Je puis assurer que la programmation n'est pas des plus optimisée. Sur Apollo, c'était des bitmaps et non des pixelmaps 32 bits. Le temps d'exécution était bien plus long tout en étant largement plus rapide que sur le DPS 6 avec des bitmaps de taille analogue. - L'affichage de la vidéo nécessite le codec Flash (.flv) - Simulation du ''feed back vidéo'

			La génération de cette même page avec une pixelmap de 3300 pixels par 2200 pixels de hauteur correspondant à un A4 (280 mm x 190 mm à 300 pixels par inch) dure tout juste une minute et on remarquera que les pages des derniers niveaux sont réduites pratiquement à un point avant l'arrêt sur erreur (plus de place dans le chemin d'accès à l'image). Si la page affichée sur l'écran est de médiocre qualité à cause du crénelage, la sortie sur imprimante donne un document tout à fait correct et parfaitement diffusable, aux polices près car je n'ai malheureusement pas pu toutes les récupérer, une dizaine (à cause des disquettes vieilles de plus d'une vingtaine d'années que j'avais conservées). L'objectif et la vocation du Central Documentation était de produire sur papier tous les manuels des hélicoptères construits par la société.
			En aparté : mais, pourquoi alors ne pas avoir utilisé les stations Apollo, me direz-vous ? Personnellement, mon objectif était de lâcher complètement le MINI 6/DSP 6 qui, tout en étant une excellente machine avec son système GCOS MOD 400 (sans mémoire virtuelle), était loin de rivaliser avec les stations Unix. Mon but affiché était de considérer le réseau comme le support d'une base de données distribuées des illustrations (textes, images et programmes) et de migrer toute l'application de la Documentation technique sur les stations Apollo (réseau ''token ring'') en liaison avec le réseau ''Ethernet'' dont l'installation était bien avancée pour l'utilisation de stations Sun et RS6000 un peu plus tard et éventuellement de stations Silicon Graphics. Je voyais l'application de gestion tourner sous les systèmes de gestion relationnelle de bases de données, ''Oracle" ou ''Ingres''. J'avais une certaine préférence pour cette dernière car, s'appuyant intégralement sur le système de fichiers de l'OS, nativement, toutes les tables étaient réparties en dossiers et fichiers contrairement aux autres qui utilisaient de volumineux fichiers monolithiques pour les héberger. Mais je préférais de loin intégrer la gestion des manuels dans ''l'application de gestion de montage des appareils personnalisés'' (je crois qu'elle s'appelait comme cela si je me souviens bien). Elle tournait sur le central et ressemblait en tout point fonctionnel à l'application de gestion de la Documentation Technique pour piloter en couplage le ''montage'' des hélicoptères et le ''montage'' des manuels associés afin que ces derniers soient sur les sièges des appareils au moment de la livraison.... ce qui était loin d'être le cas avec bien entendu les pénalités juridiques qui s'en suivaient !... La liaison réseau avec le central ne posait aucun problème. Malheureusement, cette option était loin de faire l'hunanimité au niveau des hiérarchies concernées. Cependant, à terme car c'était encore un peu trop tôt, je voyais une application documentaire sur un serveur Internet d'entreprise pour une consultation en temps réel par les clients. Les petites maquettes que j'avais réalisées avec des "cgi" (description actualisée ICI et LÀ) avaient été, pour moi, assez concluantes mais les différentes hiérarchies avaient catégoriquement refusé de les regarder (!). Aujourd'hui, il y a le langage PHP et la gestion de bases de données MySQL. Autant dire que c'est autrement plus simple, bien entendu avec les concepts de l'époque car je ne sais pas du tout comment l'application a évolué depuis. Probablement que cette manière de voir maintenant est obsolète et peut prêter à sourire !... Mes propositions avait suscité tellement de réticences qu'en 1990, je cessai à regret de m'occuper de la Documentation Technique pour laquelle j'avais donné tout mon enthousiasme et ma passion d'autant plus que j'étais tout seul et qu'on refusait systématiquement de m'associer un ou deux collaborateurs pour progresser un peu plus vite. Je rejoignais alors l'équipe-système du central informatique de l'entreprise. Le problème était tout simplement étranger à la technique. Il me dépassait assurément. Seul l'aspect technique et financier m'intéressait. J'étais prêt à me lancer, pratiquement ''assez sûr de mon coup''. C'est pourquoi je considère ce moment de ma carrière comme un demi-échec.
2)	La couleur n'était possible qu'avec les traceurs de courbes multiplumes et certains écrans. Les écrans des stations Apollo étaient monochromes. L'application ''scapin'' présentée ici traite d'office le graphique en couleur, mais ne supporte pas les traceurs de courbes.
3)	La présente application ne traite pas les accès concurrentiels en réseau,
4)	Finalement, la modification était tellement facile que je n'ai pas résisté à la tentation de traiter le graphique en couleurs codées sur 32 bits pour permettre une meilleure approche du traitement des images et celui, très probablement, de l'anticrénelage (''antialiasing''). Cette dernière fonctionnalité n'était pas possible sur des périphériques-bitmap monochromes et, sur les écrans, nous nous contentions du résultat semblable à celui de ''scapin'' aujourd'hui sous MinGW car la finalité était de produire des pages-papier pour les manuels d'hélicoptères. On retrouve d'ailleurs cette qualité dans les logiciels de dessins d'aujourd'hui qui ne prennent pas en compte l'anticrénelage pour des raisons de performances principalement. C'est le cas, par exemple, de DraftSight, ProgeCAD, A9CAD, Rhinocéros, QCAD. Par contre, Inkscape affiche ses dessins avec l'option anticrénelage, d'une qualité remarquable soit dit en passant.