En gros, vous pouvez casser!
@Yoknapatawpha pour info je suis de la génération d’avant les nerds (on appelle ça un dinosaure).
J’ai appris qu’il fallait mieux utiliser des balises même si leur syntaxe peut sembler compliquée plutôt que de se palucher la mise en page à la main. Et tout le monde y gagne.
Merci de m’avoir rajeuni!
Je deterre ce sujet. Je sais ce n’est pas d’actualité, mais en faisant de la relecture, j’ai noté la remarque :
En fait, les R# ça marche (et il n’y a pas besoin du |)
Bonjour,
Hier j’ai voulu imprimer quelques topo des calanques pour y grimper prochainement… J’en ai profité pour en mettre quelques uns au propre avec des L# en remplacement de toutes les autres présentations possibles et imaginables et avec des titres structurés…
Le bilan c’est que structurellement c’est bien ordonné mais visuellement, le rendu est pire car je n’arrive pas à me passer des syntaxes plus complexes comme les L#~, R#-1 (qui lui ne fonctionne pas contrairement à R#), des L#_droite ou gauche et des titres ## Titre xxx # h heures…
Ça fait maintenant pas mal de temps que la V6 est en marche et que ces structures ne sont plus prises en charge, même si les plus basiques le sont à nouveaux mais non fonctionnelles dès qu’une balise plus complexe est non décodée). Sans vouloir dénigrer le travail fait par les développeurs et avec le plus grand respect pour le développement bénévole, j’aimerai juste savoir à quel horizon ce problème sera résolu ? Et si’l n’est pas résoluble rapidement, tant pis on fait marche arrière et on ne garde que les L# simples sans syntaxes plus complexes.
Ce problème rend certains topos inimprimables voire même tout bonnement incompréhensibles et donc inutiles ! C’est mauvais pour l’image du topoguide quant à côté on se veut meilleurs que les topos papiers.
Salut Thomas_C,
Ce thread sur le forum n’a pas été inutile, puisqu’il a occasionné sur le forum interne plus de message en un mois, que depuis la mise en prod de la V6.
Le sujet a certes été retardé par d’autres ce dernier mois (le design, les cotations sur les sorties, des sujets chaud avec les organisation extérieurs), mais il fait clairement partie des top prios.
Mais c’est vrai que ce point n’est pas évident, car au dela de la grosse complexité technique, il génère aussi des points de vue très divergents sur la stratégie à adopter.
Petit état des lieux :
Voila, à ta dispo si tu as d’autres questions.
Merci de nous avoir renseigné sur l’utilité de cette discussion!
Merci @CharlesB pour cet éclaircissement.
Il existe un thread pour discuter de l’utilité et de la pertinence des balises au cas par cas ?
Je mets régulièrement en forme des itinéraires, alors même si je ne contribue pas au codage derrière, je peux aider à la discussion à ce sujet (au retour des vacances…).
Pour ta modif d’hier, c’était possible de rendre la syntaxe valide, car il y avait juste une mention d’un relai inutile. Du style : « Depuis R#-1, partir à droite » : inutile de préciser à chaque longueur qu’on part depuis un relai ni de préciser lequel ! On part forcément du relai n-1 quand on commence la longueur Ln. 
Du coup en supprimant les infos inutiles, ça marche : Camptocamp.org
Ce n’est pas toujours possible, mais on peut corriger certaines voies de cette façon.
Il y a aussi les multi longueurs (L4-L5) qu’on peut décrire une par une dans certains cas.
Oui @Bubu, c’est vrai pour ce coup là ça marche bien ! Mais pour bien faire il aurait fallu mettre des L#~ pour aligner les tableaux (même si ici ils le sont naturellement vu les données) et ça ça ne marche pas ! Cette balise est vraiment indispensable pour moi !
Si tu prends mon autre modif sur rêve de pierre je crois, il y a deux variantes dans une longueur, du coup ça casse la mise en forme !
Je ne sais plus si j’ai fait d’autres modifs ou pas hier, mais bien souvent j’ajoute un L#~qui me plombe tout…
J’ai mis en public un des documents de travail ici, mais les discussions ont lieu sur le forum accessible uniquement aux adhérents de l’association camptocamp.
Mais je milite activement (très activement même ) pour ouvrir les discussions relatives au wiki (topoguide+sorties) à tous les contributeurs, qu’ils soient adhérents ou pas.
Merci!
Si j’ai bien compris les spécifications, la description des variantes et des longueurs de jonction (à moins de les traiter comme une longueur normale), ne seront plus pris en compte?
Je veux bien envoyer 3 paquets de café au développeur!
Pardon, je n’ai pas été assez précis : ce document est une des propositions, mais ce n’est pas celle qui a été choisie.
Cela dit, quelle que soit la solution retenue, tu peux envoyer les paquets de café 
A vos avis :
C’est un robot qui va remettre tout en ordre ?
Pour les doubles pipe, les « : », les double « : » et les retours à la ligne dans la cellule, oui.
Pour L#-N (groupe de longueur, du dernier numero+1 à N), à voir le nombre d’occurence, mais je pense qu’on aura plus vite fait de le faire à la mimine.
Pour le reste, pas de migration à faire.
Quoi une voie comme Camptocamp.org pouf… ça va être bon ?
Edit : Ou dès qu’il y a un L#-+N, les autres balises ne seront pas interprétées?
Oui, cette page utilise la balise L#-**+**N qui sera (si on choisi cette proposition en l’état) recodée. C’est la balise L#-N que je pense etre inutile.
Réponse à ton edit : si le parseur trouve un L#-N, il ne fera rien : il vaut mieux pas d’interprétation, qu’une fausse interprétation.
Oui donc pour la Proposition #2
Mais il s’occupera du reste ?
Il ne fera rien pour les balises L# en général pour ne pas risquer de montrer une fausse numérotation, mais oui, le reste sera fait.
Cela laisse combien de docs a traiter manuel (à la louche) ?
