langage de balisage leger mentor

Langage de balisage léger mentor

Retour à l'accueil du site

version disponible en : en it ru zh es ja de nl pt

crée le : 20240514- mis à jour le : 20240514- généré le: 20240613_105900

1.Lbl mentor

Ce document est la spécification du langage de balisage léger du système Mentor - dit LBL Mentor.
La conception de ce langage est de François_Xavier_Pincemin concepteur-développeur du système Mentor.

2.Présentation du Langage de balisage léger mentor

  • le langage de balisage léger mentor est un langage de balisage minimal pour gérer un hypertexte via le module utags du système mentor dans un environnement gvim/vim - cf vim_org.
  • le module mt_to_htm du système mentor permet de générer un document HTML à partir du texte source mentor.
  • donc si vous lisez ce texte dans une page HTML vous pourriez tout aussi bien lire le texte source dans un simple éditeur.
  • mais évidemment ce n'est que l'éditeur gvim/vim qui vous fera bénéficier des fonctions de utags, pour plusieurs raisons :
  • La forme globale du texte est une encapsulation de bloc de texte ou bloc structurel.
  • Le bloc structurel définit les étiquettes et les références de l'hypertexte.

    2.1.Présentation de la forme de l'hypertexte

    2.1.1.Bloc de texte

    Le bloc de texte est la structure sous laquelle est enregistré un texte.

    - Il est composé de quatre type d'éléments délimités par les couples de délimiteurs < >, ( ), { } et [ ]

  • une étiquette hypertexte ou tag mise entre les délimiteurs "<" et ">", dite Etiquette mentor qui ne peut contenir que des caractères alphanumériques avec comme séparateur le caractère underscore "_"

  • un éventuel Résumé de bloc ou Commentaire mentor mis entre parenthèses "( )",

  • le texte proprement dit, mis entre accolades "{ le texte }" qui est le bloc de texte proprement dit.

  • les références hypertextes (aux étiquettes mentor) de la forme [une_reference] qui émaillent le texte contenu dans les blocs de texte

    2.1.1.1.Bloc structurel

    On a donc une forme générale:

    <etiquette_de_bloc>(titre) [une_reference]
    {
    ...
    ... [une_reference] ...
    ...
    <etiquette_de_sous_bloc>()
    {
    ...
    ... [une_reference] ...
    ...
    ... <etiquette_dans_texte> ... ... ... <une_reference>(c'est l'étiquette de l'exemple d'une référence en fait)
    ...
    ... [une_reference] ...
    ...
    etc...
    }
    }

    qui peut donc être imbriquée: Un bloc de texte peut contenir d'autres blocs de textes.

    Un bloc particulier est le bloc du fichier entier dont la ligne d'étiquette contient:

  • l'étiquette du nom du fichier
  • le titre du fichier dans le commentaire de bloc
  • une référence vers le sommaire du fichier. La forme de l'étiquette du fichier est donc <>()[] .

    
    - par exemple pour un fichier nommé nomfichier.ext on a : 


    <nomfichier_extension>(titre fichier)[nomfichier_extension_som]

    la macro pour générer cette ligne est &fnt fnt pour un fichier texte.
    Il existe d'autres macros &fn pour les types de fichiers sources courant: fnc pour un source C, fns pour un shell unix, etc...

  • un Commentaire de bloc où la parenthèse ouvrante est suvie d'un caractère deux-point ":" indiquera que l'on concaténera l'étiquette mentor et son commentaire dans l'étiquette HTML.

    exemple : <nomfichier_extension>(: titre fichier) ce qui donne dans le html:

    2.1.1.2.Nomfichier extension: titre fichier

    Sinon c'est le commentaire seul qui est édité dans le HTML:

    exemple : <nomfichier_extension>(titre fichier) ce qui donne dans le html:

    2.1.1.3.Titre fichier

    Mentor développe le concept d'infixe qui est généralement un code à 3 lettres qui s'il est présent dans une étiquette sera interprété lors de la génération html comme un texte à remplacer si l'infixe est présent dans le fichier des infixes nommé infixe.lst et présent sous le répertoire de travail du programme utags.

    L'infixe est la généralisation des concepts de préfixe et suffixe.

    Par exemple : <nom_spe>() ce qui donne :

    2.1.1.4.Spécification de nom 

    Le remplacement se fait de telle manière que le texte remplacé est placé en début de titre pour la version française et en fin pour la version anglaise.

    spécialisation des blocs de texte

    Le caractère suivant la parenthèse ouvrante d'un bloc de texte, s'il existe, spéficie le type de bloc.
    Ce type sera utilisé par différents modules qui complète le module de gestion de l'hypertexte.

    2.1.2.Tableaux des caractéres spécifieurs de bloc

    caractèrenom  signification bloc de texte (accolades)  commentaire (parenthèses)  
    :  deux-point  placé au niveau du bloc principal : le prochain bloc spéficie les balises META  concaténation de l'étiquette et du commentaire dans le titre HTML
    =  signe égal  préservation de la forme du texte source, si doublé == code source lbl    
    !  point d'exclamationle texte affiché dans le HTML est le source du lbl en police largeur fixe    
    -  tiret  puces    
    `  backcote  puces numérotés    
    |  pipe  commentaire HTML, si doublé absent de la page HTML    
    %  pourcent  texte généré en tableau bicolonne pour exercice d'orthoptie    
    #  dièse  spécification de traduction par l'API Deepl    
    ~  tilde  lecture aidée en langue étrangère (infobulle mot traduit)    
     point-virgule  bloc CSV    
    .  point  met en commentaire la spécification de bloc qui ne sera pas affichée dans le HTML  
    nbr        
    caractère      
    10.000000      

    Types de bloc utilisés par le module générateur de page HTML.


    - Les blocs générant des puces seront définies par le caractère tiret : {- ... }.
    Le niveau de puce est défini automatiquement par le niveau de bloc.
    Les puces numérotées sont définies par des blocs dont le code est backcote {` ... }.
    exemples:

    
    {- niv1 lib1
     - niv1 lib2
       {- niv2 lib1
        - niv2 lib2
          {- niv3 lib1
           - niv3 lib2
          }
        - niv2 lib3
       }
     - niv1 lib3
    }
     et
    {` niv1 lib1
     - niv1 lib2
       {` niv2 lib1
        - niv2 lib2
        - niv2 lib3
        - niv2 lib4
       }
     - niv1 lib3
     - niv1 lib4
    }
    
    Ce qui donne dans le HTML :

    et

    1. niv1 lib1
    2. niv1 lib2

      1. niv2 lib1
      2. niv2 lib2
      3. niv2 lib3
      4. niv2 lib4
    3. niv1 lib3
    4. niv1 lib4



    - Un bloc avec un code égal à "=" générera un texte avec conservation de la forme du bloc (balise HTML PRE). La police reste la police par défaut qui est proportionnelle.

    - Un bloc avec un code égal à "==" générera aussi un texte avec conservation de la forme du bloc (balise HTML PRE) et également avec aucune interprétation des autres balise du LBL,
    le texte du bloc sera copié sans aucune analyse lexiquale. C'est le cas du présent bloc. De façon à pouvoir présenter dans une page HTML la structure même du langage.

    - Un bloc de type {! } générera un texte avec conservation de la forme du texte du bloc. ( balise PRE ) avec en plus l'usage d'une police fixe (courrier)
    ceci pour préserver l'alignement du texte dans le cas de copie écran par exemple. Cas des niveaux plus haut et du tableau des planètes plus bas.

    - Un bloc de type underscore {| |} sera interprété comme un commentaire HTML. Voir le source HTML à cet endroit du texte.


    - Un bloc de type double underscore {|| ||} sera supprimé de la génération HTML


    - Un bloc de type CSV sera défini par {; ... } , ce bloc contient tableau de données ou le séparateur de colonne est le point virgule.
    Une table HTML sera généré et l'entête définie par la spécification "CSV_COL:" en début de la première ligne contenant les noms des colonnes
    sera affichée dans le HTML dans un couleur particulière (blue steel par défaut).

    exemple :

    
    <planète_tab>()
    {;
    CSV_REG:0        ;1         ;                  2;           3;4          ;
    CSV_COL:Planètes ;revolution;Distance_Soleil Mkm; Diamètre km;Rotation   ;
    CSV_TYP:sN       ;s         ;                 n0;          n0;s          ;
    Soleil           ;          ;                  0;     1392684;26 heures  ;
    Mercure          ;88 j      ;                 58;        4878;59 jours   ;
    Vénus            ;225 j     ;                108;       12104;243 jours  ;
    Lune             ;28 j      ;                149;        3474;           ;
    Terre            ;365.25 j  ;                149;       12756;24 heures  ;
    Mars             ;687 j     ;                228;        6794;24 h 1/2   ;
    Jupiter          ;12 ans    ;                778;      142800;10 heures  ;
    Saturne          ;29 ans    ;               1427;      120000;10 h 1/4   ;
    Uranus           ;84 ans    ;               2870;       52400;15 h 1/2   ;
    Neptune          ;164.86 ans;               4497;       48000;16 heures  ;
    Pluton           ;247.74 ans;               5913;        2400;6 jours 1/3;
    }
    
    Ce qui donne dans la page HTML :

    2.2.Tableau planète 

    Planètes  revolutionDistance_Soleil Mkm Diamètre kmRotation  
    Soleil     0 139268426 heures  
    Mercure  88 j   58 487859 jours  
    Vénus  225 j   108 12104243 jours  
    Lune  28 j   149 3474  
    Terre  365.25 j   149 1275624 heures  
    Mars  687 j   228 679424 h 1/2  
    Jupiter  12 ans   778 14280010 heures  
    Saturne  29 ans   1427 12000010 h 1/4  
    Uranus  84 ans   2870 5240015 h 1/2  
    Neptune  164.86 ans 4497 4800016 heures  
    Pluton  247.74 ans 5913 24006 jours 1/3

    2.3. Types de bloc CSV utilisés par le module de gestion des données structurées sous forme de tableaux CSV du système mentor.


    - Le bloc de type CSV vu précédemment {; ... } est traité par un module assurant la mise en forme du tableau. Lors de l'édition du tableau, on se sert de la commande
    affectée à ce module pour remettre en forme le tableau, ainsi on ne s'occupe que d'insérer les données.

    - le traitement des données stucturées devient possible dans ces blocs de tableaux CSV par l'intermédiaire d'un module de calcul des tableaux qui est donc un tableur.

    Dans ce tableur les commandes sont spécifiées par des lignes de spécifications en début de tableau qui débute par une chaine qui indique la nature de la spécification exemple: "CSV_SPE: ; ; ;" ou SPE est la spécification.

    Des fonctions d'import (CSV_IMP) et d'export de données (CSV_EDT). Le tout permettant, par exemple, de construire un ETL.


    Ce module de calcul pourra générer selon les spécifications de calcul du tableau des blocs d'édition {@ } avec la spécification CSV_EDT
    ou des blocs de journal (fiche détail) {& } (colonne de type journal).

  • ce module mettra à disposition des opérations de SGDBR interconnectant différents blocs CSV :

  • Enfin un langage inclu dans des blocs CSV "procéduraux" permettra de créer des applications. Ces applications peuvent être exécutées comme des batchs en dehors d'une cession d'édition gvim ou bien dans une session d'édition gvim où gvim tient lieu d'interface graphique.

  • ce module de traitement des données structurées est en cours de développement et sera mis en ligne dés que possible.

    3. Types de bloc applicatif. Ces blocs sont associés à des applications émergeant naturellement de la conception du système mentor.

    3.1.. lecture orthoptique  convergence ou divergence


    - Un bloc de type 0énérera une page HTML avec tableau bicolonne avec le texte affiché dans chacune des colonnes pour permettre sa lecture conjointe avec exercice orthoptique de convergence ou de divergence.

    Cette page présente le texte en double afin qu'en même temps de la lecture, on puisse faire un exercice de convergence ou divergence occulaire similaire à ceux que l'on fait chez un orthoptiste.

    Avec l'avantage que l'on peut dimensionner la fenêtre et donc l'effort de convergence, sans avoir besoin d'une série de prisme de convergence progressive.

    Si la largeur de la page est réduite il est facile de faire fusionner les deux images plus on l'élargit plus on demande un effort aux muscles occulaires.

    Il est possible de faire fusionner les deux images de deux manières: en convergence et en divergence. La convergence contracte les muscles et la divergence les étire (muscles en extension).

    En combinant les deux manières ont obtient une séance complète d'orthoptie : le travail de renforcement des muscles (musculation) et leur relaxation (stretching).

    La modulation de la largeur de la fenêtre correspond à la succession des séances où l'on utilise des prisme de plus en plus convergent ou divergent, il faut donc y aller progressivement.

    J'ai remarqué que la modulation de la largeur se faisant de manière continue, elle permet des performances plus grande du système occulaire particulièrement dans la divergence (relaxation des muscles).

    Voir dans le HTML généré :

    Cette page présente le texte en double afin qu'en même temps de la lecture, on puisse faire un exercice de convergence ou divergence occulaire similaire à ceux que l'on fait chez un orthoptiste.

    Avec l'avantage que l'on peut dimensionner la fenêtre et donc l'effort de convergence, sans avoir besoin d'une série de prisme de convergence progressive.

    Si la largeur de la page est réduite il est facile de faire fusionner les deux images plus on l'élargit plus on demande un effort aux muscles occulaires.

    Il est possible de faire fusionner les deux images de deux manières: en convergence et en divergence. La convergence contracte les muscles et la divergence les étire (muscles en extension).

    En combinant les deux manières ont obtient une séance complète d'orthoptie : le travail de renforcement des muscles (musculation) et leur relaxation (stretching).

    La modulation de la largeur de la fenêtre correspond à la succession des séances où l'on utiliser des prisme de plus en plus convergent ou divergent, il faut donc y aller progressivement.

    J'ai remarqué que la modulation de la largeur se faisant de manière continue, elle permet des performances plus grande du système occulaire particulièrement dans la divergence (relaxation des muscles).

    Il faut commencer par la largeur la plus petite de la fenêtre puis élargir progressivement.

    Cette page présente le texte en double afin qu'en même temps de la lecture, on puisse faire un exercice de convergence ou divergence occulaire similaire à ceux que l'on fait chez un orthoptiste.

    Avec l'avantage que l'on peut dimensionner la fenêtre et donc l'effort de convergence, sans avoir besoin d'une série de prisme de convergence progressive.

    Si la largeur de la page est réduite il est facile de faire fusionner les deux images plus on l'élargit plus on demande un effort aux muscles occulaires.

    Il est possible de faire fusionner les deux images de deux manières: en convergence et en divergence. La convergence contracte les muscles et la divergence les étire (muscles en extension).

    En combinant les deux manières ont obtient une séance complète d'orthoptie : le travail de renforcement des muscles (musculation) et leur relaxation (stretching).

    La modulation de la largeur de la fenêtre correspond à la succession des séances où l'on utiliser des prisme de plus en plus convergent ou divergent, il faut donc y aller progressivement.

    J'ai remarqué que la modulation de la largeur se faisant de manière continue, elle permet des performances plus grande du système occulaire particulièrement dans la divergence (relaxation des muscles).

    Il faut commencer par la largeur la plus petite de la fenêtre puis élargir progressivement.

    3.2.Traduction de texte avec l'api deepl

    - Un bloc de type dièse "#" {#fr:en: } provoque la traduction dans le source du texte lui-même.

  • Les codes langues utilisés sont les codes à deux lettres, le premier est la langue initiale et le second la langue de traduction.
  • La traduction est assurée par un utilitaire qui appelle l'api_deepl.
  • La traduction peut se faire pour un bloc de texte au sein d'un fichier (le texte initial est remplacé)
  • ou pour un fichier entier, dans ce cas un nouveau fichier est créé dont le nom est le nom du fichier initial auquel le suffixe de la langue est ajouté.
  • Les étiquettes ne sont pas traduites et le suffixe de la langue de traduction est ajouté.
  • Si il n'y a pas de commentaire d'étiquette alors on se sert de l'étiquette pour générer un texte qui lui sera traduit.
  • De cette manière on garde le lien (avec la déclinaison de différent suffixe de langue de traduction) entre le fichier dans la langue initiale et les différents fichiers en langue de traduction.
  • Une fois la traduction effectuée, la spécification de traduction est commentée avec l'insertion d'un point "." comme modifieur de bloc.
  • exemple, la ligne suivante est toujours en anglais :

    3.2.1.. lecture aidée  langue Ã©trangère


    - Un bloc de type tilde "~" est utilisé pour l'aide à la lecture en langue étrangère.

    - La spécification de la traduction suit le caractère tilde exemple : {~es:fr: hola el mundo }
    <lecture_aidée_en_langue_étrangère>()
    Ce qui donne dans la page html, des mots soulignés en pointillés qui possèdent une infobulle contenant le mot traduit.

    hola el mundo

    dictionnaire inverse : {~fr:es: bonjour le monde }

    bonjour le monde

    Un dictionnaire espagnol-français d'environ 26000 mots est fourni comme exemple. D'autres dictionnaires peuvent être instanciés par l'utilisateur mentor.
    Ils peuvent être partagés par l'utilisateur en les faisant remonter à l'éditeur pour intégration dans le package utags.
    En l'absence de dictionnaire on peut créer le dictionnaire d'un texte par une commande mentor et ensuite faire traduire la liste des mots du dictionnaire par un traducteur tel deepl

    3.2.2.Exemple les paroles de la chanson la cucaracha

    
    
    

    la cucaracha, la cucaracha que ya no puede caminar porque no tiene porque le falta la marijuana que fumar

    en la misa y en la feria todo el mundo ya lo sabe los que llegan al gobierno porque se puede comprar

    del partido comunista ya no queda casi nada ahora todos van buscando como hacerse millonadas

    fue la junta de naciones pa' poner sus opiniones todos no estaban de acuerdo donde y cuando bombardear se sientan los presidentes en la silla del gobierno luego mandan a la guerra a la gente de su pueblo

    la cucaracha, la cucaracha que ya no puede caminar porque no tiene porque le falta la marijuana que fumar

    huaracha muchacha que vamoa huarachar va una cucaracha que quiere comerciar, toca, loca ábreme la boca, buscame una coca que no quiero trabalear, mica, rica para zapatear,

    pido a victor jara no me vaya a doblegar, Cha-ma Chama Che Guevara una petición, una cucaracha, por culpa y omisión,

    la cucaracha, la cucaracha que ya no puede caminar porque no tiene porque le falta la marijuana que fumar

    todos se pelean la silla que les deja mucha plata en el norte pancho villa y en el sur viva Zapata!

    ya murió la cucaracha ya la llevan a enterrar entre cuatro zopilotes y un ratón de sacristan

    3.3.Types d'etiquette particulière


    - Une étiquette de type <_file> générera une référence HTML vers un fichier.
    - exemple :
    <lien_document_local_file>(/home/me/Documents/document.pdf)

    - Une étiquette de type <_web> générera une référence HTML vers le net.
    - exemple :
    <alwaysdata_nweb>(www.alwaysdata.com)

    - si l'infixe est "nweb" au lieu de "web", cliquer sur le lien ouvre un nouvel onglet dans le navigateur.

    <alwaysdata_nweb>(www.alwaysdata.com)
    ce qui donne dans le html : alwaysdata ou lien_vers_alwaysdata_dans_un_nouvel_onglet

  • si l'infixe est "webs" ou "nwebs" le lien sera en https au lieu de http.


    - Une étiquette de type <_hil> pour "html_inline" indique qu'il faut prendre le code html contenu dans le bloc et l'ajouter
    directement à la page html. Ceci est utilisé pour des cas particulier afin générer automatiquement des pages HTML plus spécialisée qu'un simple texte
    ou pour inclure des feuilles de style.

    3.4.. gestion des caractères  gras

    - Un texte entre parenthèse suivi d'un point d'exclamation (! apparaîtra ) en gras.
    - exemple : (! texte en gras ) :
    texte en gras