Discussion :

[boboss123]

Bonjour,

Je suis entrain de bosser sur une console en VT100.
Toutes les commandes spéciale commence donc par le caractère '\033'.

Comment faire pour connaitre la fin de la commande car le nombre de caractères après le caractère d'échappement ('\033') n'est pas fixe et le dernier caractère n'a pas toujours la même valeur.
=> je pose cette question car je veux supprimer ces commandes de ma chaine de réception

[Melem]

Il n'y a pas de caractère fin de commande comme tu l'as toi-même remarqué. Si tu veux créer une fonction void RemoveAnsiSequences(char * text), il n'y a pas d'autre moyen que de connaître la syntaxe de chaque commande, de parcourir la chaîne et d supprimer tout ce qui est reconnue comme commande valide.

[boboss123]

Il n'y a pas de caractère fin de commande comme tu l'as toi-même remarqué. Si tu veux créer une fonction void RemoveAnsiSequences(char * text), il n'y a pas d'autre moyen que de connaître la syntaxe de chaque commande, de parcourir la chaîne et d supprimer tout ce qui est reconnue comme commande valide.

arf, c'est vraiment mal foutu.
En plus j'ai l'impression que par exemple une console TELNET sous Linux ne gère pas les mêmes commandes spéciales que sous windows => il existe une lsite exhaustive de toutes les commandes à quelque part (je n'ai pas trouvé) ? ... lire les normes c'est un peu galère, il y en a 50 pour définir le TELNET (et les commandes spéciales ne sont même pas réunie dans une)

[Melem]

existe t-il une liste exhaustive de toutes les commandes à quelque part (je n'ai pas trouvé) ?

http://ascii-table.com/ansi-escape-sequences.php

[Mac LAK]

arf, c'est vraiment mal foutu.

Tu as conscience que c'est un standard âgé de TRENTE ET UN ANS ? Qu'il était conçu pour des terminaux reliés par liaisons RS-232, qui ne dépassaient sûrement pas 1200 bauds à l'époque, d'où une nécessité de transmettre le moins d'octets possibles ?

Faut pas s'étonner de limites apparemment incompréhensibles lorsque l'on utilise un truc aussi vieux, il suffit de se remettre dans le contexte...

[boboss123]

C'est pas parce que c'est vieux que ce n'est plus utilisé ... les consoles TELNET l'utilisent donc je suppose que le SSH (qu'on voit de partout) aussi, non ? Est-ce que le SSH, c'est juste du TELNET avec une couche d'encryptage par dessus ou c'est plus compliqué que ça ?


Merci pour le lien Melen (il y a des commandes que je ne connaissais pas et qui sont très intéressantes.... mais qu'elle idée d'avoir inventé le "Set Keyboard Strings" => c'est la galère à gérer ... si je croise celui qui l'a inventé, je lui casse les dents lol), mais il n'y a apparemment pas toutes les commandes pour le TELNET (il y en a que j'utilise et qui n'y sont pas) ... mais j'avoue que c'est un peu confu dans ma tête, j'ai l'impression qu'il faut différencier les commandes spéciales en deux types : les commandes TELNET et les commandes VT100 => ça doit être pour ça que dans ton lien, il n'y a pas tout ... d'ailleurs est-ce que le TELNET utilise forcement le VT100 (si ça se trouve il peut utiliser autre chose aussi) ?

Et le pire dans tout ça, c'est que les consoles TELNET ne fonctionnent pas toutes de la même façon => J'ai par exemple Putty qui interprète un "\r\0" comme un retour à la ligne alors que dans la norme il est noté qu'il devrait l'interpréter comme un "\r" (je suppose donc que ça doit être Micro$oft qui a du pondre la norme ...). Il y a aussi le positionnement des curseurs en fin de ligne qui est différent entre console TELNET windows et Putty (il y a l'un des deux qui positionne le curseur à la fin de la ligne alors que l'autre le positionne au debut de la ligne suivante) ... c'est vraiment galère à tout gérer ... sans parler de la compatibilité avec HyperTerminal (alors là, c'est le fin du fin lol)

=> d'ailleurs vous savez si c'est possible d'identifier le type du terminal distant utilisé je suis preneur...

[souviron34]

une remarque en passant :

Les terminaux VT100, puis VT220, ont été les PREMIERS terminaux graphiques (avec les Tektronix à balayage)

Comme le dit Mac Lak, avant de critiquer et de les prendre pour des fous/c.ns, etc, se renseigner..


Ces terminaux permettaient de faire des lignes (verticales, horizontales, en diagonale) pour faire des menus, des highlights, quelques graphiques (même assez poussés).

Ce sont les premiers terminaux à adressage "pixel" (comme les Tektro)..


C'est bien la raison pour laquelle un certain nombre sont toujours en activité, et le standard est toujours d'actualité pour certaines choses..

Maintenant, telnet est venu en //.. et ce que tu considères comme "naturel", que ce soit le Web ou les terminaux graphiques et le fait de pouvoir faire des IHM N'EXISTAIT PAS tout simplement...

Les programmes étaient en lignes de commandes uniquement, et les "menus", "choix", "pages", "IHM", sont justement apparus grâce aux capacités de ces terminaux...

J'ai des programmes graphiques (par exemple surveillance de charge d'ordi ou de réseaux, ou des programmes de DAO) de 1982 à 1987, fonctionnant comme cela, et c'était la pointe de la technologie..

Alors un peu de retenue et de respect, SVP...



Ce que tu prends pour acquis avec ton écran que tu allumes et qui t'affiche des icônes et de permet de cliquer, et d'avoir une fenêtre, c'est "très" récent.. Moins de 20 ans...

[Mac LAK]

C'est pas parce que c'est vieux que ce n'est plus utilisé ... les console TELNET l'utilise donc je suppose que le SSH (qu'on voit de partout) aussi, non ? Est-ce que le SSH, c'est juste du TELNET avec une couche d'encryptage par dessus ou c'est plus compliquer que ça ?

Ne confonds pas Telnet et commandes VT100 : ce sont deux choses aussi différentes que peuvent l'être TCP/IP et les balises HTML.

Telnet, c'est un protocole plutôt simple (et finalement pas si mal fait que ça d'ailleurs), rapide à implémenter et qui se contrefiche de savoir si tu es en 150 colonnes par 50 lignes ou sur du 80x25. Tu peux avoir du VT100 sans Telnet, et du Telnet sans VT100.

Et le pire dans tout ça, c'est que les consoles TELNET ne fonctionnent pas toutes de la même façon

Sauf que ce n'est pas au serveur de s'adapter, mais au client... A toi de respecter un standard, et de configurer ensuite les clients pour qu'ils s'adaptent au standard du serveur.

=> d'ailleurs vous savez si c'est possible d'identifier le type du terminal distant utilisé je suis preneur...

A part utiliser une commande particulière supportée par le client et très certainement spécifique au client, cela m'étonnerait beaucoup... Et je n'en vois d'ailleurs pas vraiment l'intérêt : comme je te l'ai dit, c'est au client de s'adapter aux standards utilisés par le serveur, pas le contraire.

[boboss123]

merci pour ce petit cours d'histoire souviron34

Sauf que ce n'est pas au serveur de s'adapter, mais au client... A toi de respecter un standard, et de configurer ensuite les clients pour qu'ils s'adaptent au standard du serveur.

Je n'ai vraiment pas l'impression que ça soit vrai : par exemple pour mon histoire de "\r\n" => lorsque je fais des tests, Putty envoie "\r\0" lorsqu'on appuie sur la touche entrée : or si je lis la norme :

http://abcdrfc.free.fr/rfc-vf/rfc854.html :

La séquence "CR LF", ainsi définie, provoquera un déplacement du curseur d'impression du NVT à la marge gauche de la ligne suivante (de même, la séquence inverse "LF CR"). Cependant, de nombreux systèmes et terminaux ne traitent pas les caractères CR et LF indépendamment, mais peuvent simuler leur effet au prix de certains efforts. (Par exemple, certains terminaux ne savent pas traiter l'effet du CR sans y adjoindre celui du LF, mais il reste possible de simuler l'effet du CR seul par une suite de Backspace). C'est pourquoi la séquence "CR LF" devra être traitée comme un caractère unique de signification "nouvelle ligne" à utiliser chaque fois que l'action combinée des deux caractères de base est souhaitée ; la séquence "CR NUL" devra être utilisée lorsque seul l'effet du CR est désiré ; l'usage du CR seul devenant de ce fait déconseillé. Cette règle permet d'assurer à un système devant faire le choix de l'effet "nouvelle ligne" ou "Backspace multiple" la présence systématique d'un deuxième caractère après le CR qui permet de lever le doute dans tous les cas.

=> donc Putty (console sous linux fonctionne pareil) ne devrait pas envoyer "\r\0" lorsque j'appuie sur la touche entrée, non ? donc s'il existe une option TELNET pour que le terminal gère correctement le retour à la ligne, j'aimerais bien la connaitre...

[Mac LAK]

Je n'ai vraiment pas l'impression que ça soit vrai

Qui t'a fait croire que les clients Telnet étaient 100% exempts de bugs et/ou de mauvaises implémentations ?

donc s'il existe une option TELNET pour que le terminal gère correctement le retour à la ligne, j'aimerais bien la connaitre...

Soit tu "joues" avec des commandes de type ^E pour essayer d'obtenir une chaîne plus ou moins discriminante du client (déconseillé, sauf à vouloir absolument faire une usine à gaz), soit tu règles le client.
Sur Putty, tu as par exemple "Implicit CR in every LF" dans la partie "Terminal" des options. Dans la partie "Connection", section "Telnet", tu as une option "Return key sends Telnet New Line instead of ^M".
Bref, suffit de chercher un peu dans les options du client...

[boboss123]

Qui t'a fait croire que les clients Telnet étaient 100% exempts de bugs et/ou de mauvaises implémentations ?

c'est bien pour ça que qu'il me semble que ta phrase est utopique :

Sauf que ce n'est pas au serveur de s'adapter, mais au client... A toi de respecter un standard, et de configurer ensuite les clients pour qu'ils s'adaptent au standard du serveur.

Pour moi, soit il faut créer un serveur dont on puisse configurer plusieurs modes de fonctionnement, soit il faut que le serveur fonctionne avec un mode hybride qui fonctionne "à peu près" (qui ne respecte donc intégralement aucune norme) avec tous les clients (cette solution n'est pas jolie mais quand on n'a pas le choix...).

Par exemple j'ai un client qui se plaignait que ma console TELNET était pourrie par ce qu'elle ne fonctionnait pas avec hyperterminal : et pourquoi ça ? ... parce que par défaut hyperterminal envoie "\r" au lieu de "\r\n" pour la touche entrée => j'ai eu beau lui dire qu'on pouvait configurer hyperterminal pour qu'il envoie "\r\n", il n'en a pas voulu... pour lui ma console devait fonctionner avec n'importe quelle console TELNET (windows, linux, putty, hyperTerminal,...) avec la configuration par défaut (car les produits concurrents le faisaient) ... et malheureusement, le client est roi.

[Mac LAK]

c'est bien pour ça que qu'il me semble que ta phrase est utopique

Que ton serveur soit tolérant aux fautes, OK (typiquement, c'est le fait de gérer indistinctement CR, LF ou CR+LF comme fin de ligne par exemple).
Après, quelle que soit la communication client / serveur désirée, c'est le serveur la référence de la norme, et non pas le client. Ton client HTTP, par exemple, s'adapte au serveur et non pas le contraire.
Rien ne t'oblige à faire un serveur "idiot" qui ferme la connexion à la première commande invalide, bien sûr, mais tu ne dois pas tenter de faire un serveur qui "devine" la nature du terminal d'en face, ce serait une très grossière erreur.

Par exemple j'ai un client qui se plaignait que ma console TELNET était pourrie par ce qu'elle ne fonctionnait pas avec hyperterminal : et pourquoi ça ? ... parce que par défaut hyperterminal envoie "\r" au lieu de "\r\n" pour la touche entrée => j'ai eu beau lui dire qu'on pouvait configurer hyperterminal pour qu'il envoie "\r\n", il n'en a pas voulu... pour lui ma console devait fonctionner avec n'importe quelle console TELNET (windows, linux, putty, hyperTerminal,...) avec la configuration par défaut (car les produits concurrents le faisaient) ... et malheureusement, le client est roi.

C'est ce que je te dis quand je te parle de tolérance à la faute sur le serveur. Mais ça ne veut pas dire pour autant que tu dois faire n'importe quoi n'importe comment, ou pire : prévoir du code "adaptatif" au client !!!

Si le terminal client ne respecte pas la norme, les fonctions "évoluées" de type déplacement de curseur et autres commandes VTxxx peuvent foirer. Et si un jour tu trouves un serveur Telnet qui supporte intégralement tous les clients possibles avec toutes les extensions possibles, tu m'appelles : ce serait étonnant que les tests aient été faits intensivement avec TOUS les clients possibles.

[boboss123]

oki, on est d''accord

[Jean-Marc.Bourguet]

Bonjour,

Salut.

Je suis entrain de bosser sur une console en VT100.

J'en doute. Tu utilises vraisemblablement un émulateur de terminal émulant tout ou partie des séquences reconnues par un VT100 et ou celles définies par ECMA-48.

Toutes les commandes spéciale commence donc par le caractère '\033'.

Ça commence mal, ce n'est pas le cas. Quelques ressources:
- sur le VT100: http://vt100.net/ en particulier le manuel
- sur ECMA-48: [ame]http://en.wikipedia.org/wiki/ANSI_escape_code[/ame] et la norme est disponible http://www.ecma-international.org/pu...T/Ecma-048.pdf
- sur les émulateurs de terminaux: il te faut chercher ce qu'ils comprennent exactement, et pas mal ne prennent pas la peine de le documenter. Pour les xterms.

Il n'y a pas de caractère fin de commande comme tu l'as toi-même remarqué. Si tu veux créer une fonction void RemoveAnsiSequences(char * text), il n'y a pas d'autre moyen que de connaître la syntaxe de chaque commande, de parcourir la chaîne et d supprimer tout ce qui est reconnue comme commande valide.

Il y a quand même une structure permet de filtrer sans tout connaître.
http://vt100.net/emu/dec_ansi_parser

une remarque en passant :

Les terminaux VT100, puis VT220, ont été les PREMIERS terminaux graphiques (avec les Tektronix à balayage)

Sans quitter DEC, les VT05 date de 8 ans avant les VT100 d'une part, d'autre part les VT100 et VT220 ne sont pas graphiques (de mémoire les VT220 avait la possibilité de recevoir des fontes bitmap mais ça n'allait pas au-delà, toujours de mémoire, le premier terminal de DEC à permettre des graphiques, c'était dans la série VT300, 10 ans après le VT100).


Bon, essayons de remettre les choses en place pour boboss123, parce qu'il y a effectivement de la confusion.

Revenons à l'époque d'avant les micros...
- un terminal, c'est un clavier et un dispositif d'affichage ou d'impression. On en a qui ressemble aux machines telex -- c'est leur origine, au début de l'informatique on a utilisé le matériel qui existait déjà -- d'autres ont un écran. Les possibilités de ceux-ci sont limitées, certains ne font qu'afficher les lignes les unes après les autres, d'autres permettent plus. Il communiquait généralement avec les ordinateurs à travers des liaisons séries (RS232), parfois par l'intermédiaires de modem. La manière dont on controle les terminaux, c'est en envoyant des séquences de caractères commencant avec un caractère de controle. Il y a eu une énorme variété, mais les séquences du VT100 ont été utilisées par pas mal d'autres -- avec des extensions et des omission -- et ont été normalisées par l'ANSI puis l'ECMA (cette dernière normalisation a été adoptée par l'ISO et donc par l'ANSI).

- la console, c'est le terminal principal de l'ordinateur. Celui où les informations de boot et de diagnostique sont affichés. Elle est parfois intégrée à l'ordinateur.

Unix en général et même Linux ont toujours des traces de cette époque. On peut par exemple les booter avec un terminal connecté sur une sortie série comme console par exemple. Mais la console, c'est généralement le clavier et le système vidéo intégré à l'ordinateur. Les informations de diagnostique sont maintenant souvent dirigées ailleurs que vers la console, mais on peut toujours le faire. Et la console est un concept un peu plus abstrait, xterm -C par exemple permet -- avec des droits suffisant -- d'avoir les messages dans une fenêtre.

On arrive aux émulateurs de terminaux. Ce sont des programmes qui font comme s'ils étaient un terminal. Parfois pour lui donner des capacités supplémentaire -- screen permet d'avoir des processus détachables et de simuler plusieurs terminaux en n'ayant qu'une connection, et d'interpréter les séquences VT100 quelque soit celles qui sont comprises par le terminal physique --, le plus couramment pour avoir des terminaux dans un environnement graphiques (xterm, gnome-terminal, konsole). Les émulateurs de terminaux comprennent rarement d'autres séquences de celles du VT100 (plus ou moins modifiées, avec parfois des bugs ou des incompatibilités assumées); l'exception la plus commune est l'xterm qu'on peut placer dans un mode émulant un modèle de tektronix cher à Souviron34.

Finalement, il y a des programmes de connection, les plus connus devant être telnet et kermit (qui comporte aussi un protocole de transfert de fichier). Sous Unix, on les utilises à partir d'un terminal (émulé ou non).

Il me semble que les programmes de connections sous Windows ont tendance à implémenter leur propre émulateur de terminal en plus que de gérer la connection (ce qui rend parfois les choses confuses). En prime, Windows appelle console quelque chose qui se rapproche plutôt des notions d'émulateur de terminaux et de terminal controlant d'unix (cette dernière notion étant totalement hors de mon propos ici).

Pour revenir à ton problème, la technique habituelle pour s'affranchir des particularités des terminaux est d'utiliser une base de donnée les rassemblant. Il y en a deux qui dominent dans le monde Unix (j'en n'ai jamais vu d'autres): termcap et terminfo. Leur utilisation est un peu compliquée, on passe généralement par une couche d'abstraction (curses, et sa réimplémentation ncurses).

Si comme j'en ai l'impression est que tu écris un programme pour Unix et que tu veux l'exécuter quand tu est connecté d'une machine windows, utilise une telle bibliothèque, il suffit avant d'exécuter ton programme d'indiquer quel type de terminal il faut utiliser avec la variable d'environnement TERM, au pire tu auras dû complèter la base de donnée pour décrire tes émulateurs.

En passant, toujours chez Thomas Dickey, il y a un programme de test de qualité d'émulation de vt100: http://invisible-island.net/vttest/vttest.html

[Melem]

Il y a quand même une structure permet de filtrer sans tout connaître.

Mais justement pour parser il faut connaître la syntaxe des commandes .

[souviron34]

Sans quitter DEC, les VT05 date de 8 ans avant les VT100 d'une part, d'autre part les VT100 et VT220 ne sont pas graphiques (de mémoire les VT220 avait la possibilité de recevoir des fontes bitmap mais ça n'allait pas au-delà, toujours de mémoire, le premier terminal de DEC à permettre des graphiques, c'était dans la série VT300, 10 ans après le VT100).

OK les VT05 datent (peut-être, je ne suis pas spécialiste) de 8 ans avant..
J'aurais dû mettre "parmi les premiers"..


Mais tes infos sont fausses concernant le reste..

Exemple pour VT220 :

VT220 Programmer Reference Manual

1.2.1 Display Features
The VT220 uses a monochrome monitor with the following features.

24 rows × 80/132 columns
7 × 10 dot matrix in a 10 × 10 cell for 80 columns
7 × 10 dot matrix in a 9 × 10 cell for 132 columns

800 (horizontal) × 240 (vertical) pixels (80 columns)
1188 (horizontal) × 240 (vertical) pixels (132 columns)

1.2.2 Text Features
This list summarizes the major VT220 text features.

Five character sets of 94 characters each (including the DEC multinational character set)
Down-line-loadable character set
User-definable function keys
Reverse video characters
Underline characters
Bold characters
Blinking characters
Double-height/double-width lines
ANSI-compatible control functions
VT52 mode

4.6.11 Scrolling Mode (DECSCLM)
Scrolling is the upward or downward movement of existing lines on the screen. There are two methods of scrolling, jump scroll and smooth scroll (6 lines per second).

4.6.13 Origin Mode (DECOM)
Origin mode allows cursor addressing relative to a user-defined origin. This mode resets when the terminal is powered up or reset. It does not affect the erase in display (ED) function.

Alors bien sûr c'est le début , et on faisait des menus, ce que je mentionnais :

Ces terminaux permettaient de faire des lignes (verticales, horizontales, en diagonale) pour faire des menus, des highlights, quelques graphiques (même assez poussés).

Mais dès les VT240 (et il me semble me souvenir les VT220 pouvaient accèder à ce mode) on avait accès aux graphiques :

VT 240 Series
Programmer Pocket Guide (PDF)


(p. 53) :

V Vector Draws vectors (straight lines) between screen locations specified within the command
C Curve Draws circles, arcs, and/or curves using screen locations specified within the command

J'ai même mis en freeware pour DECUS Graphics en 1988 une bibliothèque basée sur GKS prenant en compte les VT240.. ainsi que 2 programmes, un de DAO, et un permettant de surveiller la charge de N ordis d'un réseau VMS, y compris sur des Tektro ou des VT240..

c! JSGKSLIB.For - Librairie graphique basee sur GKS
c!**********************-***********************************************!
c! Thomson-CSF/Laboratoire Central de Recherches - Service Informatique !
c!------+-------+-------+-------+-------+-------+-------+-------+-------!
c! Application : Tous graphiques Version : 2.0 !
c! Ecrit le : 18/10/88 Par : J.Souviron !
c! Nom complet : JSGKSLIB.FOR !
c!------+-------+-------+-------+-------+-------+-------+-------+-------!
c! Description : !
c! Ceci est une librairie de subroutines graphiques basees sur !
c! le standard GKS , ayant des fonctions evoluees du style trace !
c! de boites avec labels et echelles , copie automatique , !
c! fenetres pour menus deroulants , etc .... !
c!------+-------+-------+-------+-------+-------+-------+-------+-------!
c! Produits : !
c! VMS 4.7 / FORTRAN 4.6 / JSGKSLIB 2.0 !
c!------+-------+-------+-------+-------+-------+-------+-------+-------!
c! Modifications : !
c! J.Souviron le 18/10/88 --> Mise en service reelle derniere version!
c! J.Souviron le 25/02/88 --> Creation de la librairie !
c!**********************************************************************!
c!

Code Fortran :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
c*********************************************************c
c       cette routine definit la station de travail       c
c       reference de base a  partir de quoi sont faits    c
c       les calculs                                       c
c*********************************************************c
        SUBROUTINE SETREF(TYPE)
c------------------------
        character*1 devjs
        character*(*) type
        common/refdevjs/devjs
        common/jsgks/xmax0,ymax0,irasx,irasy,refx,refy,
     +ratioxw,ratioyw,ratxref,ratyref,
     +ifill,icolor,iactif,ipasjsgks,ifont,xleft(11),xright(11),
     +yleft(11),yright(11),xlog,ylog,iseg(11),iseg0(11),itransf,
     +portxmin,portxmax,portymin,portymax,angrot,iexactcopy,
     +iplo,igraph,ilin,weig,itypfill,iflagcopy(17),rarr(121)
c------------------------
        devjs='O'
        if(TYPE.eq.'VT240'.or.type.eq.'vt240')go to 1
        if(TYPE.eq.'VT340'.or.type.eq.'vt340')go to 1
        if(TYPE.eq.'VT330'.or.type.eq.'vt330')go to 1
        if(TYPE.eq.'VT125'.or.type.eq.'vt125')go to 4
        if(TYPE.eq.'V2000'.or.type.eq.'v2000')go to 6
        if(TYPE.eq.'VII'.or.type.eq.'vII')go to 6
        if(TYPE.eq.'T4014'.or.type.eq.'t4014')go to 7
        print *, 'Sorry ! this station is not supported for reference'
        print *, ' '
        print *, 'Supported stations: VT125,VT240,VT330,VT340'
        print *, '                    Vax stations II et 2000'
        print *, '                        (V2000 and VII)'
        print *, '                    Tektronix 4014 (T4014)'
        print *, ' '
        print *, '  Assumed reference station : VT240  !!!!!!' 
        print *, ' '
        devjs='U'
1       refx=799.
        refy=479.
        ratxref=1.
        ratyref=479./799.
        if(devjs.ne.'U')devjs='V'
        return
4       refx=767.
        refy=479.
        ratxref=1.
        ratyref=479./767.
        return
6       refx=1010.
        refy=833.
        ratxref=1.
        ratyref=833./1010.
        devjs='A'
        return
7       refx=4095.
        refy=3071.
        ratxref=1.
        ratyref=3071./4095.
        devjs='T'
        return
        end