Pour lire les liens non soulignés à partir de Nemo

Le Mercredi 19 Juin 2013 à 19h13, Olivier Miakinen a écrit :

Je ne suis pas d'accord.

Je comprends ton désaccord, sur le plan de la compatibilité avec un
client news classique. Ma réponse avait pour seul objectif de permettre
à Richard d'envoyer des articles sur Usenet avec Nemo, dans sa
configuration *actuelle*, sans infliger au lecteur des coupures de
lignes pour le moins peu conviviales.

La question est plutôt : est-ce que Nemo avait
montré, lors de la composition, qu'il couperait *avant* « coupures » et
« nemo.test ».

D'après ce que j'ai pu voir, Nemo n'impose aucune coupure au texte du
rédacteur. C'est le client news qui les formate ensuite, en fonction du
paramétrage choisi par l'utilisateur. Cela ne pose pas de problème,
sauf pour les citations (voir mes articles ultérieurs sur le sujet).

Si oui, alors Richard fait ce qu'il veut et il a le droit
de rajouter une coupure après les mêmes mots. Et sinon, c'est Nemo qui
est en tort : il doit montrer ce qui sera réellement envoyé.

Oui et non. Nemo montre bien ce qui sera envoyé, mais pas ce qui sera
formaté par le client.

Dans SeaMonkey ou Thunderbird, le logiciel coupe automatiquement lors de
la composition, et ce qui est affiché correspond à ce qui sera envoyé.

C'est donc comme dans OE et MesNews.

Après mes tests sur l'interface "lecteur" de Nemo, je commence tout
juste à en explorer l'aspect "posteur". Nous aurons donc certainement
à revenir sur ces points avec Julien.

Le Mercredi 19 Juin 2013 à 19h27, Richard Hachel a écrit :

A mon avis, ce n'est ni Nemo (et encore moins moi) qui sont en tort.

Ce n'est pas un problème de tort ou pas tort. La question est de savoir
dans quelle mesure il serait possible de rendre Usenet et Nemo
compatibles, sans priver Nemo de ses nouvelles fonctionnalités.

Si je veux envoyer des poèmes avec de la versification, je mets les phrases
et les rimes que je veux, ce n'est pas à Nemo de couper (et Nemo ne le fait pas).
Par contre, les lecteurs de news le font.

Oui et ton beau poème aura une sale tronche dans un client news
traditionnel, si tes vers et leurs rimes dépassent +/- 76 caractères
... :)

Le problème vient 100% d'eux, et je ne vois pas la solution pour ça.

Ben oui, c'est dur dur de gérer l'héritage des tubes cathodiques à 80
caractères par ligne.

Mais Nemo a un rendu qui permet aussi de voir ce qui sera envoyé,
y compris les photos et le Latex.

Sans oublier le PDF et je ne sais quoi encore dans le futur, le tout
étant malheureusement inexploitable dans un niouzerideur actuel. Faut
essayer de trouver des solutions, au lieu de s'engueuler ... :)

Le Mercredi 19 Juin 2013 à 21h20, Duzz' a écrit :

Le Mercredi 19 Juin 2013 à 19h27, Richard Hachel a écrit :

Sans oublier le PDF et je ne sais quoi encore dans le futur, le tout étant malheureusement inexploitable dans un niouzerideur actuel. Faut essayer de trouver des solutions, au lieu de s'engueuler ... :)

On s'engueule pas, on essaye de trouver des solutions.

La grande faiblesse de Nemo, c'est de ne pas être lisible en mode
Universal par les autres newswiewers.

C'est sa seule faiblesse, mais elle est de taille.

C'est dommage car l'inclusion d'images (forums de photos, de jardinage,
d'animaux), de portées musicales (musique),
de schéma, Latex (forum de science), voire de vidéos, pourraient
énormément apporter à des news moribondes.

Une solution consisterait à faire cliquer l'utilisateur sur un lien
direct en affichage Nemo, je l'ai déjà fait
plusieurs fois, mais c'est pas la panacée, car l'utilisateur ne
comprend pas trop ce qui se passe, et la raison du lien.

Maintenant, faire de Nemo un simple lecteur sans ses fonctions
géniales, c'est un peu con.




R.H.

Le 19/06/2013 19:27, Richard Hachel m'a répondu :

Je ne suis pas d'accord. La question est plutôt : est-ce que Nemo avait
montré, lors de la composition, qu'il couperait *avant* « coupures » et
« nemo.test ». Si oui, alors Richard fait ce qu'il veut et il a le droit
de rajouter une coupure après les mêmes mots. Et sinon, c'est Nemo qui
est en tort : il doit montrer ce qui sera réellement envoyé.

A mon avis, ce n'est ni Nemo (et encore moins moi) qui sont en tort.

Si je veux envoyer des poèmes avec de la versification, je mets les
phrases
et les rimes que je veux, ce n'est pas à Nemo de couper

Tant que tu ne dépasses pas la limite à laquelle le nouvelleur coupe
(Nemo ou un autre), ce ne sera effectivement pas coupé. Pour des
lignes plus longues, il faut le demander explicitement au nouvelleur.

Avec SeaMonkey, par exemple, on peut utiliser l'une des deux méthodes
suivantes :
- augmenter temporairement la longueur des lignes (72 par défaut) ;
- copier « comme une citation », auquel cas les lignes ne sont pas
coupées du tout.

Je suppose que des logiciels plus malins offrent un moyen au coup par
coup de signaler que telle ou telle ligne ne doit pas être coupée.

(et Nemo ne le
fait pas).

Bien sûr que si, il le fait. La valeur par défaut doit être quelque
part entre 70 et 76 (Julien confirmera), je ne sais pas si elle est
configurable.

Par contre, les lecteurs de news le font.

Ce n'est pas sympa de prétendre que Nemo n'est pas un lecteur de
news. Il a encore plein de manques, mais il s'améliore de jour en
jour.

Le problème vient 100% d'eux, et je ne vois pas la solution pour ça.

Dans OE et MesNews tu écris à la volée, comme je le
fais actuellement dans Nemo, et c'est le logiciel qui limite la longueur
des lignes au nombre de caractères par défaut, sans charcuter un mot
si ça tombe dessus (chez moi c'est 76 caractères pour OE et 74 pour
MesNews).

Ils devraient laisser l'utilisateur libre de couper les lignes où il
veut.

Plus exactement, ils ne DEVRAIENT pas empêcher l'envoi d'un article
avec des lignes trop longues, mais ils DEVRAIENT au moins prévenir
l'utilisateur et lui permettre de reformater.

Tiens, voici un lien vers le BBCU (traduction du GNKSA) :
<http://usenet-fr.news.eu.org/fr-chartes/gnksa.html#14>.

Nemo est mieux sur ça.

Non. Je cite une phrase de la page ci-dessus :

<cit.>
Il ne devrait pas non plus montrer à l'utilisateur une série de lignes
de 100 caractères tout en envoyant en fait alternativement des lignes de
80 et de 20 caractères.
</cit.>

C'est exactement le cas lorsque tu mets un saut de ligne après environ
80 caractères, et que Nemo envoie une ligne de 70 caractères suivie
par une ligne comportant un seul mot.

Il ne coupe pas les lignes non coupées.

Bien sûr que si. Regarde ton article dans un nouvelleur qui te permet
d'afficher les code source.

Dans SeaMonkey ou Thunderbird, le logiciel coupe automatiquement lors de
la composition, et ce qui est affiché correspond à ce qui sera envoyé.

Ca c'est bien.

Oui, même si ce n'est pas encore l'idéal.

Mais Nemo a un rendu qui permet aussi de voir ce qui sera envoyé,
y compris les photos et le Latex.

Dans ce cas, regarde ce rendu dans tes articles avant l'envoi. S'il est
vraiment fidèle, tu verras tes lignes coupées ailleurs que là où tu les
coupes.

Cordialement,
--
Olivier Miakinen

Le Jeudi 20 Juin 2013 à 00h08, Olivier Miakinen a écrit :

Je suppose que des logiciels plus malins offrent un moyen au coup par
coup de signaler que telle ou telle ligne ne doit pas être coupée.

(et Nemo ne le
fait pas).

Bien sûr que si, il le fait. La valeur par défaut doit être quelque
part entre 70 et 76 (Julien confirmera), je ne sais pas si elle est
configurable.

Le client Nemo ne coupe pas automatiquement les lignes, ce travail est
réalisé par la passerelle lors du transfert d'un article dans le sens
JNTP -> NNTP pour être conforme aux usages usenet.

Le 19/06/2013 20:56, Duzz' a écrit :

Je ne suis pas d'accord.

Je comprends ton désaccord, sur le plan de la compatibilité avec un
client news classique. Ma réponse avait pour seul objectif de permettre
à Richard d'envoyer des articles sur Usenet avec Nemo, dans sa
configuration *actuelle*, sans infliger au lecteur des coupures de
lignes pour le moins peu conviviales.

D'accord. Tu t'adressais à Richard, et effectivement c'est un conseil
qui peut lui être utile (s'il supporte cette façon de faire).

Pour ma part, je souhaite surtout que Julien me lise, et à ce propos
je remets le lien vers la traduction française du GNKSA :
<http://usenet-fr.news.eu.org/fr-chartes/gnksa.html> (le point dont
on discute en ce moment est le numéro 14).

La question est plutôt : est-ce que Nemo avait
montré, lors de la composition, qu'il couperait *avant* « coupures » et
« nemo.test ».

D'après ce que j'ai pu voir, Nemo n'impose aucune coupure au texte du
rédacteur. C'est le client news qui les formate ensuite, en fonction du
paramétrage choisi par l'utilisateur.

Quand tu dis « le client news », si tu veux dire celui du lecteur qui
recevra l'article sans nécessairement passer par Nemo, alors c'est faux.
Les lignes sont coupées avant envoi, ce qui est effectivement une
fonctionnalité requise, mais cela ne suffit pas.

[...] Nemo montre bien ce qui sera envoyé, mais pas ce qui sera
formaté par le client.

Visiblement, Nemo (client + serveur) ne montre pas ce qui sera
envoyé, sinon Richard n'aurait pas eu de problème.

Cordialement,
--
Olivier Miakinen

Le 20/06/2013 00:15, Julien Arlandis a écrit :

Je suppose que des logiciels plus malins offrent un moyen au coup par
coup de signaler que telle ou telle ligne ne doit pas être coupée.

(et Nemo ne le
fait pas).

Bien sûr que si, il le fait. La valeur par défaut doit être quelque
part entre 70 et 76 (Julien confirmera), je ne sais pas si elle est
configurable.

Le client Nemo ne coupe pas automatiquement les lignes, ce travail est
réalisé par la passerelle lors du transfert d'un article dans le sens
JNTP -> NNTP

Alors c'est encore pire que ce que je croyais, malheureusement. Parce
que dans ce cas l'auteur d'un article perd tout contrôle sur le rendu
de son article qui traverserait une telle passerelle, en effet son
aspect après envoi et avant la passerelle sera transformé après la
passerelle !

pour être conforme aux usages usenet.

Alors là c'est complètement raté. :-(

Le Jeudi 20 Juin 2013 à 00h19, Olivier Miakinen a écrit :

Le 19/06/2013 20:56, Duzz' a écrit :

Je ne suis pas d'accord.

Je comprends ton désaccord, sur le plan de la compatibilité avec un
client news classique. Ma réponse avait pour seul objectif de permettre
à Richard d'envoyer des articles sur Usenet avec Nemo, dans sa
configuration *actuelle*, sans infliger au lecteur des coupures de
lignes pour le moins peu conviviales.

D'accord. Tu t'adressais à Richard, et effectivement c'est un conseil
qui peut lui être utile (s'il supporte cette façon de faire).

Pour ma part, je souhaite surtout que Julien me lise, et à ce propos
je remets le lien vers la traduction française du GNKSA :
<http://usenet-fr.news.eu.org/fr-chartes/gnksa.html> (le point dont
on discute en ce moment est le numéro 14).

Je vais étudier ça.

La question est plutôt : est-ce que Nemo avait
montré, lors de la composition, qu'il couperait *avant* « coupures » et
« nemo.test ».

D'après ce que j'ai pu voir, Nemo n'impose aucune coupure au texte du
rédacteur. C'est le client news qui les formate ensuite, en fonction du
paramétrage choisi par l'utilisateur.

Quand tu dis « le client news », si tu veux dire celui du lecteur qui
recevra l'article sans nécessairement passer par Nemo, alors c'est faux.
Les lignes sont coupées avant envoi, ce qui est effectivement une
fonctionnalité requise, mais cela ne suffit pas.

[...] Nemo montre bien ce qui sera envoyé, mais pas ce qui sera
formaté par le client.

Visiblement, Nemo (client + serveur) ne montre pas ce qui sera
envoyé, sinon Richard n'aurait pas eu de problème.

Nemo formate les articles au format JNTP-Strict, c'est seulement lors du
transfert de l'article vers un serveur NNTP que les lignes sont
coupées. Quand on affiche le rendu avant l'envoi de l'article, on
obtient le rendu tel qu'il apparaitra sur un client JNTP et non pas sur
NNTP.

Le Jeudi 20 Juin 2013 à 00h29, Olivier Miakinen a écrit :

Le 20/06/2013 00:15, Julien Arlandis a écrit :

Je suppose que des logiciels plus malins offrent un moyen au coup par
coup de signaler que telle ou telle ligne ne doit pas être coupée.

(et Nemo ne le
fait pas).

Bien sûr que si, il le fait. La valeur par défaut doit être quelque
part entre 70 et 76 (Julien confirmera), je ne sais pas si elle est
configurable.

Le client Nemo ne coupe pas automatiquement les lignes, ce travail est
réalisé par la passerelle lors du transfert d'un article dans le sens
JNTP -> NNTP

Alors c'est encore pire que ce que je croyais, malheureusement. Parce
que dans ce cas l'auteur d'un article perd tout contrôle sur le rendu
de son article qui traverserait une telle passerelle, en effet son
aspect après envoi et avant la passerelle sera transformé après la
passerelle !

L'utilisateur de Nemo formate ses articles pour un usage
préférentiellement orienté vers le web dans un format optimisé pour
le web. La coupure des lignes réalisée par la passerelle ne sert qu'à
satisfaire le confort de lecture sur NNTP, c'est le meilleur compromis
pour assurer l'intéropérabilité des deux protocoles.

pour être conforme aux usages usenet.

Alors là c'est complètement raté. :-(

--
Ce message a été posté avec Nemo : <http://news.julien-arlandis.fr/?ID5528>

Le 20/06/2013 00:37, Julien Arlandis a écrit :

L'utilisateur de Nemo formate ses articles pour un usage
préférentiellement orienté vers le web dans un format optimisé pour
le web. La coupure des lignes réalisée par la passerelle ne sert qu'à
satisfaire le confort de lecture sur NNTP, c'est le meilleur compromis
pour assurer l'intéropérabilité des deux protocoles.

Dans ces conditions, je crois qu'il va falloir réenvisager le format
flowed. Ça devrait limiter un peu la casse (du moins pour ceux qui
ne l'ont pas désactivé en lecture).

Par exemple, ça pourrait être un truc comme ça, à faire sur la
passerelle JNTP -> NNTP) :

- Si toutes les lignes de texte font moins que 100 caractères
(ou si les lignes de texte plus longues ne comportent aucune
espace) alors ne couper aucune ligne et laisser en format
standard (fixed).

- Sinon, c'est-à-dire s'il existe au moins une ligne de plus
de 100 caractères comportant au moins une espace, alors
couper les lignes de plus de 76 caractères comportant au
moins une espace en insérant le CR+LF *après* l'espace
(et en laissant l'espace, donc), et déclarer le format
comme flowed.

Ne pas oublier ce dont j'espère que tu le fais déjà :

- Si avant envoi il reste une ou plusieurs lignes de plus
de 998 octets, les couper à la sauvage, même si elles
ne comportent pas d'espace, ou tout simplement décider
de ne pas les transmettre sur NNTP.