
PARX Software / 1992    -   Les drivers RIM

Version 2.00

Le 27/09/1992 modification pour les RIMs "total" et "partiel"
Le  01/11/1992  modification seek et data (.L au lieu de  .W)  et 
donc modification des appels.

Document relatif  la conception des drivers de lecture d'images. 
Ce document est destin  expliquer aux programmeurs  assembleurs 
dsireux de raliser de tels drivers,  la structure de ceux-ci et 
leur fonctionnement.

Ces drivers sont DOMPUB et devront tous porter l'extension .RIM
signifiant Read IMage.

BUT DE L'OPERATION
La  Multiplication  des formats d'images sur  ATARI  implique  un 
nombre grandissant de routines.  Au lieu de les inclure dans  les 
logiciels,  nous avons dcid de mettre sur pied un format prcis 
et  de  les laisser sur disque.  A  son  lancement,  le  logiciel 
chargera ces routines dont le nombre pourra voluer. Il est ainsi 
possible  de  concevoir d'autres routines une  fois  le  logiciel 
dit,  l'utilisateur  n'ayant alors qu' rajouter  ces  nouveaux 
drivers  dans le dossier avec les autres.  Il peut  mme  limiter 
volontairement le nombre de ces drivers de lecture,  pour  gagner 
de la place mmoire.
Il  est  conseill aux dveloppeurs de  logiciels  utilisant  les 
fichiers RIM,  de dfinir un chemin d'accs au dossier  contenant 
ces  RIMs,  dans les prfrences de leur logiciel,  ceci afin  de 
permettre  l'utilisateur de n'avoir qu'un seul dossier avec  ces 
RIMs, ceux-ci tant utiliss par des logiciels diffrents.


FONCTIONS
Chaque driver est compos de 3 routines qui devront:
1)  Reconnaitre  le  fichier que le PRG  veut  charger,  afin  de 
dterminer si c'est un format connu ou inconnu.
2) Traiter la palette de couleur de ce fichier.
3) Lire les donnes d'image de ce fichier (ventuellement en  les 
dcompactant).

FONCTIONNEMENT
     Puisqu'au dpart le PRG a charg plusieurs routines,  il lui 
est possible de noter leurs adresses dans un tableau.  Il  suffit 
donc  au  PRG de charger un bout du fichier   traiter,  puis  de 
boucler  pour appeler chaque routine afin qu'elle lui indique  si 
elle  reconnait  ou  non ce fichier.  Si  le  fichier  n'est  pas 
reconnu, le PRG passe  la routine suivante etc...

for x=0 to nbr de routine charges
     appel routine x en demande vrification format
          si format reconnu
           appel routine x avec demande gestion palette
           appel routine x avec demande de traitement
          fsi
     sortie si format reconnu
next x

FORMAT DES DONNES...
     Nous  abordons  ici  un  trs  gros  problme  car  99%  des 
programmeurs  en  assembleur,  donc suceptibles de  raliser  ces 
routines, n'ont aucune connaissance du GEM et le traitement devra 
justement se faire au format GEM...

     Avec  l'arrive  du  Falcon et  des  cartes  graphiques  bon 
march, il devient vident que se reprer uniquement au format et 
 la structure entrelace de l'cran,  devient chose  impossible. 
Dans  les modes True Colors du Falcon par  exemple,  l'cran  n'a 
plus cette structure entrelace que nous connaissons sur  ST.  De 
plus,  en moyenne rsolution,  l'entrelacement n'est pas le  mme 
qu'en  basse  et  tout se complique avec  les  cartes  graphiques 
puisque  le format des donnes cran dpend de la carte  et  peut 
donc tre totalement farfelu.
     Comment s'y retrouver?  C'est assez simple. Le VDI possde 2 
fonctions   spcialement  tudies  pour   cela,   ainsi   qu'une 
normalisation de format. Il faut dans un premier temps mettre les 
donnes  de l'image dans ce format normalis et appeller  ensuite 
la  fonction  Transform_form().  Cette  fonction  transforme  des 
donnes au format standard VDI en format cran. Il suffit ensuite 
de  les afficher avec la fonction  Vro_cpy().  La  particularit, 
c'est qu'il est impossible de connaitre la structure de  l'cran: 
la fonction Transform_form() fait cette conversion et c'est tout! 
Nous devons donc simplement connaitre ce format standard, dposer 
nos  donnes  dans ce format et le tour est  jou!  Il  est  bien 
vidant que c'est le PRG principal qui appelera  Transform_form() 
et pas la routine assembleur, celle-ci se contenant de mettre les 
donnes des fichiers images en format standard.

LE FORMAT STANDARD
     Le  format standard est trs simple:  il y a d'abord  toutes 
les donnes du plan 1 de l'image (pour toutes les  lignes),  puis 
toutes les donnes du plan2 (pour toutes les lignes) etc...

LES PROBLEMES...
     Imaginons le traitement d'une image Degas  Compacte.  Voici 
ce qui serait idal:
1) Test de la taille du fichier (par ex 19Ko)
2) Rservation d'un buffer de 32ko en destination
3) Rservation de 19ko et chargement du fichier
4) Dcompactage des 19Ko vers les  32Ko, en format standard VDI
5)  Application de la fonction Transform_form() sur le buffer  de 
32Ko pour le mettre au format cran.
6) Libration des 19Ko
7) Affichage du bloc de 32Ko avec Vro_cpy().

Il faut  un moment donn 19+32=51Ko de mmoire libre. Dans notre 
exemple  c'est acceptable,  mais il ne faut pas oublier  que  les 
formats  d'images  sont  trs  varis:  une  image  1280*960  256 
couleurs occupe 1.2 Mo. Si une fois compacte elle n'occupe "plus 
que" 600Ko,  il faut donc 1.8Mo de libre, ce qui commence  faire 
beaucoup.
     Nous  pourrions envisager de traiter le fichier  par  petits 
bouts  puis  d'appliquer Transform_form() sur  le  rsultat  mais 
c'est  impossible:  il  faut  rserver un autre  buffer  de  mme 
taille,  le Transform_form() tant en fait une copie de l'un vers 
l'autre  avec  au  passage  modification  de  la  structure   des 
informations.  Or cette solution est totalement inacceptable, car 
si  nous avons un fichier qui,  une fois  lu,  fait  300Ko,  cela 
implique  de  rserver un second buffer de 300Ko  pour  faire  le 
Transform_form()...

     La   seule  solution  acceptable,   c'est  aussi   la   plus 
complique:  il  faut  d'abord rserver un  buffer  pour  l'image 
finale.  C'est  un buffer "cran" dans le sens ou  l'image  qu'il 
contiendra    la  fin sera au format cran  (aprs  passage  par 
Transform_form()). Ensuite, on test la place encore disponible en 
mmoire et on rserve en fonction de cette place un second buffer 
qui contiendra les donnes du fichier issu du disque.  La  taille 
de  ce buffer "source" dpend de la mmoire disponible:  si  elle 
est importante,  on rserve le plus gros possible afin de limiter 
le nombre d'accs disque.  Ensuite on rserve un troisime buffer 
qui sera la destination du traitement.  Si le buffer "cran"  est 
prvu  pour  250  lignes d'images et que la  RAM  disponible  est 
encore  importante,  pas  d'hsitation:  on rservera  un  buffer 
"standard"  de  250 lignes.  Si par contre la  place  manque,  on 
pourra rserver par exemple un buffer "standard" de 50 lignes: on 
lira donc 50 lignes,  Transform_form() de ces 50 lignes du buffer 
"standard"  vers le buffer "cran",  puis lecture des  50  lignes 
suivantes etc...
     Le cas idal c'est donc d'avoir assez de place pour rserver 
le buffer "cran" (si ce n'est pas possible,  le chargement  sera 
de  toutes  faons impossible   raliser),  rserver  un  buffer 
"standard"  de  la mme taille,  et rserver un  buffer  "source" 
pouvant recevoir d'un coup tout le fichier.  L'autre cas extrme, 
c'est de rserver le buffer "cran",  un buffer "standard"  d'une 
seule ligne, et un buffer "source" de quelques octets...
     Concernant  la taille mini de ce buffer source,  nous  avons 
dcid qu'elle serait de 512 octets. S'il est possible d'avoir un 
buffer  source plus grand,  c'est trs bien mais en tout  cas  sa 
taille devra TOUJOURS tre PAIRE!!!!!  A noter aussi qu'il  devra 
toujours commencer  une adresse paire,  l'idal c'est donc de le 
rserver avec Malloc() (GEMDOS 72)

Etant  donn  la  complexit  de  ralisation  d'un  fichier  RIM  
pouvant recevoir les donnes  traiter "par petits  bouts",  deux 
types  de  fichiers RIMs sont prvus:  les  premiers  ne  peuvent 
recevoir  les donnes  traiter que dans leur totalit.  Ce  sont 
les RIMs "total".  Les autres sont plus "malins" et acceptent les 
donnes par morceaux, ce sont les RIMs "partiel". Au dpart, vous 
pouvez  vous  exercez   faire des RIMs  en  commencant  par  les 
"total"  cause de leur simplicit, mais la taille des images qui 
seront  traits dans un futur proche (768*480 en  65000  couleurs 
par exemple!) rend invitable la conception des RIMs "partiel".


EN-TETE DES RIMS

Chaque driver RIM commencera par:
     DC.B        "READ_IMG"     ;driver de lecture d'image
     DC.B        "_VDI"         ;qui les traite au format VDI
     DC.W        0              ;0->RIM Total, 1-> RIM Partiel
     DC.B        "DEGA_PAC"     ;Ici c'est du Degas compact
     DC.W        100            ;numro de version
* 30 caractres dcrivant la fonction de ce
* fichier RIM, suivis de 2 octets nuls. 
     DC.B        "Image Degas Compact          ",0,0
     BRA         test_fichier  ; vrification du fichier
     BRA         extrait_palette
     BRA         traite_fichier

Viennent  ensuite les routines dans l'ordre de l'en-tte c'est   
dire  d'abord le test du fichier,  l'extraction de la palette  et 
enfin le traitement de l'image.

Les  deux  descripteurs ASCII (READ_IMG et  _VDI)  permettent  au 
programme principal de savoir s'il doit charger ou non ce fichier 
en  tant  que  driver.  Nous avons en effet  en  prparation  des 
normalisations  pour  les  drivers  d'criture,  de  pilotage  de 
scanner etc...

L'identificateur suivant (dans l'exemple,  DEGA_PAC indiquant que 
nous  traitons  du Degas Compact) lui permet de ne  pas  charger 
deux fois le mme driver.  S'il trouve plusieurs drivers  portant 
ce mme identificateur, il ne gardera que celui dont le numro de 
version  est le plus lev.  Ce numro de version commence   100 
(ce n'est pas la notation ASCII).
Les  30 caractres qui dcrivent la fonction du fichier,  ont  un 
intrt  assez  spcial:   On  peut  trs  bien  envisager  qu'un 
utilisateur  sache qu'une image est un Degas Compact,  mais  que 
l'image   n'en   possde   ni   l'extension,    ni   les   octets 
d'identification:  le fichier RIM ne la reconnaitra donc pas. Par 
contre, en utilisant ces 30 caractres descriptifs, le PRG pourra 
demander  l'utilisateur quel fichier RIM choisir afin de  forcer 
la  lecture  malgrs la non-reconnaissance de  l'image  (rsultat 
non-garanti!).

En  admettant  que le fichier soit charg    l'adresse  driver%, 
c'est  dire que la rservation a t faites par:
driver%=GEMDOS(72,L:taille_de_ce_driver)
les appels se feront comme ceci:
(nous gardons une notation Basic: %=4 octets, &=2 octets)

** Test_file() **
retour%=C:driver%+56(code&,     L:adr_source%,    L:size_source%, 
L:size_file%, L:extension%, L:adr_MFDB%)
Avec le saut de 56 on saute sur la routine test_fichier.

retour%  contiendra  divers  valeurs au  retour  de  la  routine, 
suivant le rsultat des tests.  Pour retourner cette valeur  (que 
le  programme  appelant soit en GFA ou en C) il  faut  placer  la 
valeur en D0 dans la routine assembleur.

retour% :
0 -> Format inconnu
1  ->  Quantit de donnes insuffisante pour aller  au  bout  des 
tests.  Le PRG appelant rechargera un autre bout du fichier  afin 
que la routine puisses continuer sa vrification.  Etant donn la 
perte de temps du chargement,  le PRG principal a tout intrt   
charger le plus possible de donnes. Rappel: la quantit minimale 
de donne est de 512 octets.
2  -> Fichier reconnu contenant une palette
3 -> Fichier reconnu, ne contenant PAS de palette

     Dans tous les cas,  le fichier RIM rempli la structure  MFDB 
pour le PRG, ceci afin de prvoir le cas ou le PRG voudrais quand 
mme forcer la lecture de l'image  par ce fichier, mme si celui-
ci   ne  le  reconnait  pas  (d'o  intrt  des  30   caractres 
descriptifs  d'en-tte du RIM).  Si le fichier RIM peut lire  des 
images de plusieurs rsolutions, il testera celle-ci en regardant 
le  nombre  de plan de la structure MFDB pass  en  paramtre  et 
remplira cette MFDB en consquence.

code&: Indication pour que la routine sache si on est en train de 
l'appeler  pour  la  premire fois,  ou si on  est  en  train  de 
l'appeler  aprs avoir recharg quelques donnes (ce qui peut  se 
passer  si  la routine  rpondu par retour%=1) Dans  ce  dernier 
cas,  la  routine reprendra  l'endroit ou elle  avait  abandonn 
lors de l'appel prcdent.  Si code&=0 c'est un premier appel, si 
code&=1 ce n'est pas un premier appel.

Adr_source%  Adresse des donnes du fichier.  Le PRG  appelant  a 
charg  cette adresse le dbut du fichier.

size_source%  Taille des donnes que le PRG Appelant  a  charges 
(donnes se trouvant  l'adresse adr_data%)

size_file% Taille totale du fichier sur disque.  Indication utile 
pour  certaines  type  de  fichier (NEOCHROM=32128 par ex.)

extension% Extension du fichier sur le disque. Cette variable sur 
4  octets  contiendra  l'extension  avec  le  "."  de  sparation 
(".NEO",  ".IFF" etc...). Attention, dans le cas d'un test sur un 
fichier Degas (par ex.),  on peut imaginer que la routine ne test 
que  les 3 premiers caractres de cette extension,  c'est   dire 
".PC"  puisque le fichier peut-tre du type PC1,  PC2  etc...  Or 
cela peut prter  confusion, car il existe un format d'image sur 
compatible PC,  dont l'extension est ".PCX" En ne testant que les 
3  premires lettres,  un tel fichier risque d'tre pris pour  un 
fichier Degas compact.

adr_MFBD%  Adresse  de  la structure MFDB que  la  routine  devra 
remplir si elle reconnait le format du fichier qu'on lui propose.

     La structure MFDB est une liste de quelques octets dcrivant 
l'image.  Cette structure est utilise dans les oprations GEM de 
copie  d'image  et son remplissage doit tre fait  avec  le  plus 
grand  soin.  Notre routine devra donc remplir  cette  structure, 
afin de communiquer au PRG appelant le maximum d'informations sur 
l'image  telle qu'elle sera une fois lue.  Voici par  exemple  la 
structure  MFDB qui devra tre renvoye par une routine  traitant 
des images au format Nochrome:
     DC.L      4       ; seek palette   
     DC.W      320     ; largeur de l'image en pixels
     DC.W      200     ; hauteur de l'image en pixels
     DC.W      80      ; largeur d'un plan en mot
     DC.W      0       ; les donnes sont au format standard
     DC.W      4       ; nombre de plans
     DC.L      32      ; nbr d'octets de la palette     
     DC.W      0       ; rserv
             
Normalement,  la MFDB ne doit pas donner le "seek" pour atteindre 
la palette,  ni la taille des donnes de celle-ci. Normalement le 
premier  long  mot devrait contenir l'adresse  de  l'image,  mais 
comme  c'est au PRG Appelant de rserver un bloc mmoire et  donc 
de  connaitre cette adresse,  nous en profitons pour  communiquer 
des informations. La connaissance du saut ncessaire pour pointer 
dans le fichier sur les donnes de la palette,  permettra au  PRG 
appelant  de  faire un SEEK sur ce fichier,  et donc  de  ne  pas 
charger de donnes inutiles.  S'il n'y a pas de palette,  il faut 
mettre 0 pour le seek et la taille puisque le code de retour sera 
3 au lieu de 2.

     Il  faut  faire trs attention  l'indication de  la  taille 
d'un  plan en mot.  Dans le cas d'images qui sont normalement  au 
format  cran  (Degas,  No,  etc...) le problme  est  facile   
rsoudre:  il  suffit  de diviser la taille du  fichier  par  son 
nombre  de  lignes pour obtenir la taille d'une  ligne,  puis  de 
diviser cette taille par le nombre de plans pour avoir la  taille 
d'un  plan  et finir en divisant par 2 pour avoir  le  nombre  de 
mots.  Mais tout se complique avec les images de taille  variable 
(IMG, TIFF, IFF, GIF etc...). Si par exemple nous avons une image 
de 125 pixels de large sur 8 plans, chaque ligne fera 125 octets, 
ce qui n'est pas divisible par deux pour obtenir un nombre  juste 
de mots!  Idem pour une image de 375 pixels de large sur 4 plans: 
cela fait 381*4=1524 bits par lignes, c'est  dire 190,5 octets!! 
L,  nous n'arrivons mme pas  avoir un nombre juste en octet et 
si nous arrondissons,  nous trouvons 191 octets, ce qui n'est pas 
divisible par deux. Dans tous ces cas, il faut aller au nombre de 
mot juste au dessus.  Ainsi pour 125 octets on donnera 63 mots et 
pour 190,5 octets, 96 mots.

** Get_palette() **
retour%=C:driver%+60(code&,     L:adr_source%,    L:size_source%, 
L:adr_destination%, L:nombre_couleurs%,L:adr_MFDB%)
Avec le saut de 60 on saute sur la routine de rcupration de  la 
palette.

Valeurs de retour%:
0  ->  Erreur.  Donnes ne correspondant pas    la  palette,  ou 
palette absente de ce fichier.
1 -> Quantit de donnes trop faible.  Rappel:  l encore le  PRG 
Appelant doit charger au moins 512 octets. Pour un RIMs total, il 
faut envoyer le totalit des donnes.
2 -> Succs.

code&  Comme pour Test_file() 

adr_source%  Adresse    laquelle le PRG Appelant    dpos  les 
donnes.

size_source% Taille de ces donnes

adr_destination%  Adresse   partir de laquelle la  routine  doit 
dposer la palette aprs traitement.

nombre_couleur%  c'est le nombre de couleurs que le PRG  Appelant 
veut  voir traiter par la routine.  Il est ainsi possible que  le 
PRG  ne demande que les premires couleurs de la palette.  Si  le 
PRG  veut une couleur sur deux,  il est de sa  responsabilit  de 
demander toutes les couleurs et de les traiter ensuite.

A  l'appel le PRG doit remplir a nouveau la MFDB en placant  dans 
le  premier  long  mot de celle-ci la taille du  fichier  sur  le 
disque.  En  retour,  le  RIM aura rempli cette MFDB  comme  pour 
l'appel  TEST_FILE(),  c'est  dire dans le premier long  mot  le 
"seek"  pour les donnes de l'image et dans les octets  14-17  la 
taille de ces donnes.
     Si  le fichier ne comporte pas de palette ou bien si le  PRG 
ne veut pas de traitement de celle-ci,  il doit nanmoins appeler 
cette routine afin de connaitre le seek et la taille des  donnes 
composant  l'image.  Il  suffit  pour cela de  faire  l'appel  en 
donnant 0 comme nombre de couleurs  traiter.

     Le format des couleurs est trs important:  tant donn  que 
nous  travaillons au format VDI,  la routine devra  dposer  dans 
adr_destination%,  les  couleurs dans l'ordre et avec  le  codage 
VDI.  Ce  codage est du type RGB,  mais avec des valeurs de  0   
1000,  tenant  chacune sur un mot.  Ainsi un vert 362 devra  tre 
cod comme ceci:
(3*1000)/7=428
(6*1000)/7=857
(2*1000)/7=285
Donc au format VDI: 428-857-285
     Il  faut  galement  faire attention au  fait  que  certains 
fichiers peuvent contenir un codage de palette prvu pour le STE, 
et donc avoir des composantes notes de 0  F et pas de 0  7. Il 
faudra alors faire:
(valeur_composante_system*1000)/15=valeur composante.VDI
     L'adresse destination pointera donc sur une zone destine   
recevoir  les couleurs au format VDI c'est  dire avec un  codage 
sur 3 mots (6 octets) par couleur.

** Do_file() **
retour%=C:driver%+64(code&,     L:adr_source%,    L:size_source%, 
L:adr_MFDB%)
Avec le saut de 64 on saute sur la routine traite_fichier

Valeur possible pour retour%:
0 -> Erreur (fichier abim, mauvais type etc...)
1  -> Toutes les donnes fournies ont t traites,  il  faut  en 
recharger d'autres.  Mais attention,  toutes les lignes du buffer 
"standard"  n'ont  pas t remplies,  le PRG Appelant  doit  donc 
recharger   des   donnes,    mais   ne   doit   pas   faire   de 
Transform_form().
2 -> Toutes les lignes du buffer "standard" ont t remplies.  Le 
PRG Appelant doit donc faire un Transform_form() mais ne doit pas 
recharger  de  donnes  dans le buffer "source"  car  toutes  ces 
donnes n'ont pas t lues.
3 -> C'est le cas de 1 ET de 2 en mme temps:  toutes les donnes 
ont t lues,  et en plus toutes les lignes du buffer  "standard" 
ont   t  remplies.   Le  PRG  Appelant  doit  donc   faire   un 
Transform_form() et en plus il doit recharger des donnes dans le 
buffer  "source".  C'est le seul cas qui doit normalement  arriv 
avec  les RIMs "total" puisque ceux-ci reoivent la totalit  des 
informations.

code& 0->Premier appel, sinon code&=1.

adr_source%  Adresse  des donnes  du  fichier.

size_source%  Taille de ces donnes.

adr_MFBD%  Adresse  de la structure MFDB  dfinissant  le  buffer 
"standard" dans lequel on doit tranfrer les donnes de l'image.
Cette  structure a t modifie par le PRG Appelant  et  contient 
dsormais  l'adresse du buffer "standard" dans les deux  premiers 
mots:
     DC.L      adresse du buffer standard
     DC.W      320     ; sa largeur en pixels
     DC.W      200     ; son nombre de ligne
     DC.W      80      ; la largeur d'un plan en mot
     DC.W      0       ; inutilis par la routine
     DC.W      4       ; nombre de plans
     DC.W      0       ; rserv     
     DC.W      0       ; rserv     
     DC.W      0       ; rserv

     La  routine  va donc devoir dposer les donnes  de  l'image 
dans  le  buffer "standard",  en faisant attention au  nombre  de 
ligne  de  celui-ci,  et  sa largeur en mot,  qui  permettra  de 
sauter  du lieu de dpot des donnes plan1 au lieu de  dpot  des 
donnes plan2 etc...  Ainsi,  si le buffer standard fait 5 lignes 
de haut et que la largeur d'un plan en mot est de 40, la distance 
sparant  le dbut de la premire ligne plan1,  du dbut  de  la 
premire ligne plan2 sera de (40*2)*5=400 octets. Il faut refaire 
ce  calcul  aprs chaque Transform_form()  du  PRG  Appelant.  En 
effet,  si l'image fait par exemple 250 lignes,  et que la  place 
mmoire  disponible permet de rserver un buffer standard de  120 
lignes,  le PRG Appelant demandera  la routine, 2 oprations sur 
120  lignes  et pour terminer une opration  sur  10  lignes.  La 
structure  MFDB  dfinissant  le  buffer  "standard"  sera   donc 
diffrent lors du troisime appel. Cela ne vaut que pour les RIMs 
partiel.  En  effet,  le  PRG  appelant   la  responsabilit  de 
rserver  un  buffer assez gros pour recevoir  l'image  une  fois 
traite.  Il est interdit (bien que ce soit possible en  thorie) 
de  demander  par exemple  une routine Degas de  dcompacter  un 
fichier  sur  seulement  150  de  large  et  80  de  haut.   Cela 
compliquerait  inutilement les RIMs,  alors qu'il suffit  au  PRG 
appelant de faire un vro-copy pour ne garder par la suite que les 
"morceaux" qui l'interesse.

Note:  les  appels sont les mmes pour les RIMs "partiel" et  les 
"total".  Bien videment,  un RIM total ne rpondra jamais  qu'il 
faut   lui  redonner  des  donnes  pour  qu'il  poursuivre   son 
traitement;

LE FUTUR
     Nous sommes en train de travailler sur une normalisation  de 
fichiers WIM (Write IMage) destines  sauver des fichiers images 
dans diffrents formats. Lorsque ce principe sera devenu courant, 
nous pensons dvelopper aussi des fichiers RTX (Read TeXt) et des 
fichiers  WTX (Write TeXt) ainsi que des fichiers de pilotage  de 
Scanner etc... 

CONCLUSION
     Avec ce principe de lecture de fichier,  il devient possible 
de  raliser des PRG volutifs:  en cas de nouveaux  formats,  il 
suffit  de concevoir le fichier RIM en suivant  la  normalisation 
dcrite  ci-dessus,  et ce nouveau format sera alors reconnu  par 
les  PRG  utilisant  les RIM.  Il est  d'ailleur  interessant  de 
dfinir  dans  les "Prfrences" de  votre  logiciel,  le  chemin 
d'accs  aux  fichiers RIMs.  Ainsi l'utilisateur peut  tous  les 
placer  dans un mme dossier,  et tous les PRG se  serviront  des 
mmes.

     Pour vous entrainer,  vous trouverez ci-joint une routine en 
GFA  Basic qui utilise ces fichiers RIM.  Pour la  conception  de 
ceux-ci,  le  plus  simple est de commencer par des RIM  de  type 
Nochrome,  Doodle,  Degas non-compact, DALI, pour aller ensuite 
vers les STad,  les Tiny etc...  et si le coeur vous en dit, vers 
le TIFF...

     N'oubliez  pas de nous prvenir lorsque vous raliserez  des 
RIM, afin que nous puissions les inclures dans la bibliothque.

Bonne programmation


REMARQUES
     Afin  de permettre une bonne diffusion et une  programmation 
relativement  aise  des  RIMs,  quelques points  sont  a  noter: 
d'abord  le  PRG appelant doit imprativement rserver  une  zone 
mmoire et construire une structure MFDB telle que celle  dcrite 
par le RIM ayant reconnu le fichier. Il est interdit de crer une 
structure pour une grande image et de demander au RIM d'y dposer 
le  fichier par exemple dans le coin  gauche.  Cela  aurait  t 
possible  mais aurait normment compliqu la cration des  RIMs. 
Idem  dans  l'autre sens,  interdit de rserver  une  image  trs 
troite  et  de demander au RIM de ne recopier qu'une  partie  du 
fichier.
     De mme, ne multipliez pas les tests dans vos fichiers RIMs: 
c'est au PRG appelant de vrifier l'tat du fichier,  la validit 
des zones mmoires rserves etc... Les RIMs doivent tre simple, 
c'est  cette simplicit qui engendrera leur nombre,  et c'est  ce 
nombre qui fera qu'ils seront utiliss.

     Une  remarque assez importante:  il est parfois  souhaitable 
que  la premire routine d'un RIM note des informations  qui  lui 
seront  utiles  lors de l'appel de la seconde  routine.  Il  faut 
faire trs attention  ne pas utiliser ce principe pour noter des 
adresses. En effet il existe une bibliothque de routines appele 
MEMORY-MANAGER qui permet de faire des Malloc() "lastiques".  Ce 
systme  dplace sans arrt les blocs mmoire et vous courrez  le 
risqsue  de noter une adresse qui quelques instants plus tard  ne 
correspondra  plus    rien de valable!  Notez  donc  plutt  des 
offsets!


