bonjour,
actuellement (dans les chaînes de langue entre autres), les protocoles :
http, https, mailto et ftp
sont 'protégés', dans le sens où la fonction typo() ne s'exerce pas
sur eux :
'http://tartopom.net' n'est pas transformé en 'http ://tartopom.net'
(noter l'espace avant le 
je propose d'ajouter à cette liste le pseudo-protocole 'webcal'
de sorte que 'webcal://example.com/calendar.ics' reste cliquable.
Salut Denis
actuellement (dans les chaînes de langue entre autres), les protocoles :
http, https, mailto et ftp
sont 'protégés', dans le sens où la fonction typo() ne s'exerce pas
sur eux :
'http://tartopom.net' n'est pas transformé en 'http ://tartopom.net'
(noter l'espace avant leje propose d'ajouter à cette liste le pseudo-protocole 'webcal'
de sorte que 'webcal://example.com/calendar.ics' reste cliquable.
Bonne idée, mais tant qu'à faire il faudrait unifier autour de ça.
Il existe une constante _EXTRAIRE_LIEN (sans S final) qui n'est utilisée
que dans traiter_lien_explicite, mais qui ne contient pas toute la liste que tu mentionnes
(qui est dans en dur dans typographie_fr). Il y a aussi vider_url qui elle aussi à une liste en dur,
encore différente.
Je serai d'avis que "_EXTRAIRE_LIEN" contienne les 5 protocoles en question,
et qu'elle soit utilisée systématiquement.
Committo,Ergo:Sum
Pour être exhaustif, il y a beaucoup plus que cinq protocoles (schémas d'URI) légitimes, rapidement je pense à ssh, ldap, news, nntp, view-source...
Ou bien, encore moins "exotique" et de plus en plus utilisé pour les téléphones mobiles : <a href="tel:+31123456789">
De nouveaux schémas plus ou moins propriétaires se créent aussi régulièrement (services de cartes par exemple)
y a-t-il un cas où “XXX:Y” doive être converti en “XXX :Y” si Y n’est pas un espace, tab ou saut de ligne ?
Dans une phrase en français sans mention de protocole informatique,
par exemple:cette ligne-ci
pour autant que l'objet de typo soit de retourner une phrase où la typo est respectée,
même si cette dernière est incorrecte dans la phrase reçue.
(enfin, plus précisément il faudrait un espace après le : aussi).
JLuc
le fonctionnement de typo() n'est pas des plus clair pour ce qui
touche à la gestion des espaces insécables et espaces simples.
normalement, dans tous les cas ci-dessous, typo() devrait ajouter
—dans les textes relevant de typographie française— un espace insécable
devant la ponctuation double et un espace simple après.
par exemple:quand je claviote trop vite.
et là:c'est mal
pourtant:ça le fait
autre exemple?une faute de frappe.
et encore!par inattention.
actuellement, pour ces cas là, typo() retourne
par exemple:quand je claviote trop vite.
et là:c’est mal
pourtant :ça le fait
autre exemple ?une faute de frappe.
et encore !par inattention.
comme on le voit, l'espace simple n'est jamais ajouté *après*
la double ponctuation et les 2 points ne sont traités *que*
s'ils sont suivis par une 'non-lettre ascii'.
(oui je sais : _une_ espace)
typo() n'est pas un *correcteur* typographique, mais un moteur permettant
d'aller plus vite ; pour moi si ces exemples sont les seuls, on pourrait
très bien n'appliquer l'insécable-avant QUE si les deux-points sont suivis
d'un espace (au sens large : insécable, tab, saut de ligne, fin de texte…).
-- Fil
Je ne crois pas qu'on puisse éviter de l'arbitraire.
Meme si on disposait en PHP de la liste officielle de l'IANA:
http://www.iana.org/protocols
ça ne suffirait pas car dans un texte pédagogique, on peut écrire des choses comme
"définition du protocole ftp: bla bla bla".
et donc là il faut le   de la règle de typographie française.
C'est pourquoi je pense qu'on n'échappera pas à une constante PHP qui énonce les exceptions à cette règle,
sachant qu'il faudra intervenir manuellement pour les cas tordus comme celui ci-dessus.
Committo,Ergo:Sum
safehtml (v 1.3.7) utilise 2 tableaux.
les protocoles à ne pas accepter :
'about', 'chrome', 'data', 'disk', 'hcp',
'help', 'javascript', 'livescript', 'lynxcgi', 'lynxexec',
'ms-help', 'ms-its', 'mhtml', 'mocha', 'opera',
'res', 'resource', 'shell', 'vbscript', 'view-source',
'vnd.ms.radio', 'wysiwyg'
les protocoles à accepter :
'ed2k', 'file', 'ftp', 'gopher', 'http', 'https',
'irc', 'mailto', 'news', 'nntp', 'telnet', 'webcal',
'xmpp', 'callto'
(je parle de safehtml, parce que la lib est fournie avec spip)
je suis d'accord et c'est bien pourquoi je parlais d'ajouter des
exceptions (d'autres protocoles à protéger donc) à la règle.
on pourrait déjà convenir que tout :// ne doit pas être précédé
d'un insécable (le tableau 'protocoles à accepter' de safehtml
que je cite dans mon post précédent).
un truc comme :
[:?!;](\s|$)+
ça me va oui.
Attention il faut aussi intégrer le cas du capitaine Haddock :
moule à gaufres!??! Bachi-bouzouk!! phlébotome!???! troglodyte!!!
preg_replace(",\s*([:?!;]+)(\s|$)+,Uims", "~\\1 ", $texte)
¡sera mon dernier mot!
2013/10/1 denisb <denisb@a-working-class-hero-is-something-to.be <mailto:denisb@a-working-class-hero-is-something-to.be>>
par exemple:quand je claviote trop vite.
typo() n'est pas un *correcteur* typographique,
Ah, je suis déçu.
Même si sur le web il est difficile de reproduire la typographie fine
recommandée pour le papier, pourquoi ne pas bien faire quand on peut ?
Je croyais que c'était une marque forte de l'identité de spip,
et un élément qui le distinguait des autres CMS.
JL
typo() n'est pas un *correcteur* typographique,
Ah, je suis déçu.
ah bon ?
Même si sur le web il est difficile de reproduire la typographie fine
recommandée pour le papier,
on essaie de bosser sur les espaces fines etc, ce n'est pas si facile, mais
ça donne quand même de jolies choses
pourquoi ne pas bien faire quand on peut ?
Je définirais plutôt typo() comme un *moteur* typographique, qui permet
de bien faire, rapidement et sans complications. Mais il ne faut pas lui
faire manger n'importe quoi. Corriger, au sens où on enverrait n'importe
quoi (exemple type : des ponctuations non suivies d'espaces), et le rendu
serait toujours parfait, c'est trop compliqué.
Je croyais que c'était une marque forte de l'identité de spip,
et un élément qui le distinguait des autres CMS.
ça l'est !
Dans la white list je ne vois pas "tel" par exemple, alors que c'est tout à fait légitime et de plus en plus utilisé (même si très récent).
Chacun sur son propre site, on pourrait enrichir cette liste autorisée dans une constante selon ses besoins, comme la liste des documents autorisés en upload.
Mais si j'ai bien suivi, typo() est aussi appliqué sur les chaines de langues par salvatore. Là ce n'est plus de l'individuel à chacun sa sauce.
Comment présager des usages futurs ?
Chacun sur son propre site, on pourrait enrichir cette liste autorisée
dans une constante selon ses besoins, comme la liste des documents
autorisés en upload.
pourquoi pas ? oui.
Mais si j'ai bien suivi, typo() est aussi appliqué sur les chaines de
langues par salvatore. Là ce n'est plus de l'individuel à chacun sa sauce.
1- toute chaîne débutant par un des éléments de _EXTRAIRE_LIEN
et finissant au premier espace rencontré (ou au premier ] dans
le cas d'un raccourci spip) est protégée (typo n'y est pas appliquée)
2- ailleurs, toute double ponctuation suivie de quelque espace que
ce soit et non précédée directement d'une double ponctuation est
traitée par typo()
il faut lire cela comme un but (pas comme ce qui est fait aujourd'hui).
