Dernier commentaire : il y a 14 ans15 commentaires3 participants à la discussion
Bonjour Verdy p,
Pour corriger un texte dans l’espace Page, il faut disposer d’un fac-similé de ce texte à mettre en double affichage pour que tout lecteur puisse le vérifier. Disposes-tu d’une source scannée de ce document ? Si oui, indications suivront... Amicalement, et merci de tes apports ! --Zyephyrus26 septembre 2009 à 10:08 (UTC)Répondre
Yann parlait me semble-t-il de l’utilisation du mode page avec fac-similé comme nous le faisons habituellement : exemple et s’attendait je crois à ce que tu scannes la source papier (ou te procures un scan quelque part) pour l’afficher en face de ton texte. De toutes façons je voterai pour que ton merveilleux travail soit conservé tel qu’il est mais peut-être que cela sera contesté, il serait plus simple de mettre le scan. De plus en cas de vandalisme nous ne pouvons pas sans scan savoir si le vandale a raison ou tort de faire une correction. --Zyephyrus26 septembre 2009 à 13:19 (UTC)Répondre
Le lien vers le PDF est fourni, mais si on a eu l'autorisation d'importer le texte, ce n'est pas évident qu'on puisse importer le fichier PDF lui-même (ou même seulement un scan !) tel qu'il est sur le site de l'Académie française... Verdy p (d) 26 septembre 2009 à 13:23 (UTC)Répondre
J'ai tout de même un autre problème : en divisant l'article en sous-pages, il n'est plus possible de faire de liens correctement d'une page à l'autre, car l'espace "Page:" ne supporte pas les sous-pages (c'set à dire par exemple sur Page:Rapport de 1990 sur les rectifications orthographiques/18, les syntaxes {{BASEPAGENAME}} et {{SUBPAGENAME}} retournent encore la même valeur que {{PAGENAME}}, c'est à dire le nom complet (sans l'espace de nom "Page:"), ce qui est incorrect.
Le support des sous-pages faciliterait énormément la navigation d'une page à l'autre quand on a des renvois dans le texte lui-même, ou pour reproduire les sommaires originaux.
Un administrateur doit activer les sous-pages pour l’espace de noms "Page:".
...sauf que je ne sais pas sous quelle licence je peux le faire : sais-tu si ce que l’Académie française autorise ? Si tu ne le sais pas, nous pourrons poser cette question sur le scriptorium. --Zyephyrus26 septembre 2009 à 13:57 (UTC)Répondre
Il faudrait savoir dans quelle condition le texte brut a été initialement importé dans Wikipédia ou ailleurs avant d'atterrir ici... C'est bien pour ça que je n'ai pas importé le PDF, ni fourni de scan.
si le PDF ne peut pas être importé, c’est que la mise en page est protégée. Dans ce cas, le fait que tu as scrupuleusement reproduit cette mise en page est une violation de copyright. il faudrait revenir à une mise en page plus neutre, et faire sortir ce texte de l’espace page puisque les scans ne sont pas disponibles. ThomasV27 septembre 2009 à 07:42 (UTC)Répondre
Il n'y a rien à changer du tout, tout est prévu pour avoir la lecture en mode complet non paginé (le mode paginé m'a servi aussi à valider le texte). De plus le même PDF, et différentes conversions en HTML, est reproduit sur plein de sites de différents pays francophones. L'import fait ici a été fait par quelqu'un qui a dit "libre de droit" dans son commentaire, le problème c'est qu'on a rien d'autre. Si je me fie aux sites qui référencent ce texte, ils ont différentes définitions du "copyright" mais ne s'attribue pas la propriété. C'est ce qui est fait ici. Et ce texte est copié sur d'autres wikis aussi. Verdy p (d) 27 septembre 2009 à 07:51 (UTC)Répondre
Il faudrait te décider ! TU m'avais demander de le faire plus haut !
Est-il réellement génant là-bas, maintenant que les sous-pages ont été renommées ? Je ne peux pas faire de renommage inverse (enfin si, peut-être, car je suis le seul auteur des sous-pages, je pourrais tout écraser, mais il restera des pages (ou des redirections?) dans l'espace "Page:", qu'il faudra ensuite nettoyer. Verdy p (d) 27 septembre 2009 à 09:31 (UTC)Répondre
désolé, c’est parce que je pensais que les scans étaient disponibles et libres de droits. Peut être que la première chose à faire serait de clarifier les aspects légaux. si on n’a rien d’autre que quelqu’un qui a dit "libre de droits" dans son commentaire, alors je pense qu’il faut demander une autorisation à l’Académie. Sinon on sera obligé d’effacer le texte.
l'espace page ne fonctionne pas correctement sans scans; c’est pour ça que tu as été obligé de créer un modèle pour naviguer entre les pages. je te conseille fortement de participer à un projet de transcription déjà existant, afin de te familiariser avec les fonctions de l’espace page.
Dernier commentaire : il y a 14 ans4 commentaires2 participants à la discussion
Il existe la typographie traditionnelle… et celle d'internet. L’usage de   est à déconseiller avec la ponctuation. Cette espace fine n’est pas insécable. L’espace fine insécable est définie dans l’Unicode mais non encore gérée par les navigateurs. En mettant   tu empêches le parser de Mediawiki de remplacer l’espace qui précède le signe de ponctuation par une espace insécable. Cordialement. – Philippe – 27 septembre 2009 à 07:29 (UTC)Répondre
Justement, si j'ai utilisé la fine c'est parce qu'elle est insécable, et mieux que ça, elle est non justifiable (et en plus c'est une fine moins large que l'espace normal, ou l'espace insécable). C'est tout à fait volontaire et bien normal ! Et tout à fait correct dans la typographie. a le TRES GROS DEFAUT d'être non seulement trop large, mais en plus il peut encore s'élargir avec la justification. Merci donc de ne pas remplacer les   tout à fait exacts par qui ne sont que des approximations grossières. Bref, bien au contraire la fine est à conseiller maintenant, d'autant qu'elle est très bien supportée aujourd'hui. Verdy p27 septembre 2009 à 07:37 (UTC)Répondre
En Unicode :
  |   |   est l’espace fine sécable (de mieux en mieux gérée par les différents navigateurs)
&nnbsp; |   |   est l’espace fine insécable (non encore gérée)
Même si   n’est pas (encore) ajustable en justification, elle reste une espace sécable. Je ne changerai rien à ton texte, à toi de voir. – Philippe – 27 septembre 2009 à 08:05 (UTC)Répondre
je ne connais aucun navigateur ou moteur de rendu qui utilise thinsp en y autorisant la césure. Il faudrait que tu regardes les propriétés Unicode concernant le line-break. C'est assez clair.
tu confonds peut-être avec les fines 1/8 ou 1/4 de cadratin (cette dernière étant un peu préférée par les typographes français). Ici on emploie celle de taille approximative d'un demi-espace, ce qui ne fait pratiquement aucune différence à l'écran et d'une différence invisible à l'impression. Les anglophones utilisent le 1/6 de cadratin, qui est en pratique invisible sur l'écran, c'est pour ça qu'ils n'en mettent pas du tout. Notre fine est juste un peu plus large.
enfin Mediawiki ne prend pas en charge tout seul la conversion des espaces avant toutes les ponctuations : il y a plein de cas où il ne le fait pas, ou bien ou il le fait en les déplaçant de façon incorrecte (dans la mauvaise direction) en croyant que ces espaces sont justement ajustables (la fine ne doit pas l'être).
De toute façon ce que je voulais c'était moins la question de la largeur exacte, que celle que cette espace ne se justifie pas (car le résultat est désastreux quand on a des éléments qui sont sensés être alignés verticalement (après une puce, après un titre commun... Et avoir une espace géante entre un mot et les deux-points est carrément inacceptable pour une mise en page conforme. — Verdy_p (d) 27 septembre 2009 à 08:22 (UTC)Répondre
Liens rouges dans les préférences utilisateur... Ce sont des pages à commenter plus avant pour expliquer les préférences.
Dans l'immédiat cela ôte les deux pages de la lsite des liens rompus. On peut mettre plus de texte, mais le texte mis là est minimum et devrait suffire
Tu verras aussi que sur Wikipédia, cela donne accès aux pages d'aide sur les droits des utilisateurs, sur BabelMap, sur les différents groupes Babel, etc. — Verdy_p (d) 1 octobre 2009 à 21:42 (UTC)Répondre
Merci, c'est plus clair sur cet exemplaire. J'avais bien noté les ligatures mais je ne parvenais pas bien à les lire, ton autre référence où le texte est imprimé est nettement plus facile à lire. Note: il n'y a pas d'abréviations dans ce texte grec, hormis un tau souscrit qui peut très bien se reproduire, et des ligatures optionnelles (venant de l'écriture manuscrite qui emploie aussi l'ancienne forme du kappa) dont on peut se passer... — Verdy_p (d) 19 octobre 2009 à 14:20 (UTC)Répondre
Note ces ligatures n"existent dans aucune police grecque, car elles ne sont pas optionelles. Elle proviennent uniquement de la façon d'écrire de Du Bellay (ou de ses contemporains chez qui il a appris le grec). J'ai regardé même dans les polices grecques des médiévalistes, et ces ligatures sont absentes (on ne les trouve que dans les manuscrits, pas dans les impressions des imprimeurs, même ceux de l'époque).
En revanche on a bien les formes alternatives de pi (en forme d'oméga coiffé d’un toit), et de kappa. On n'a pas en revanche la forme alternative de êta (sauf peut-être en petite capitale, au lieu de notre n actuel avec une jambe)
Les ligatures sigma-tau, sigma-chi, double-tau, sont difficiles à reproduire, on ne peut que faire une petite simulation à l'aide d'indices (car les lettres descendent alors sous leur position normale). — Verdy_p (d) 19 octobre 2009 à 18:17 (UTC)Répondre
Dernier commentaire : il y a 13 ans18 commentaires2 participants à la discussion
Bonjour,
Ce livre est définitivement très intéressant. De plus je vois que tu respecter strictement la typographie d’origine (j’adore, j’essaye de faire aussi mais ce n’est pas toujours facile, notamment le cas les ligatures comme tu le dis ci-dessus ;)).
Deux petites remarques : 1. (la plus importante) pourrait tu importer le fichier sur Commons ? (sous le même nom pour ne pas casser les liens)
Tu saurais comment créer des ligatures ? J’aurais besoin de ſt, ff, fi, fl, etc. Vu que tu m’a déconseillé ces caractères Unicode, je suis bloqué (et pour ct, il n’existe rien à ma -faible- connaissance). Cdlt, VIGNERON * discut.27 octobre 2009 à 12:34 (UTC)Répondre
Pour les ligatures, le codage recommandé est d'utiliser le caractère de contrôle ZWJ (zero width joiner) entre les lettres (celles qui existent préencodées dans Unicode ne sont pas recommandées et de toutes façon n'existent que pour compatibilité avec d'anciens codages avant Unicode, et Unicode n’en ajoutera aucune autre, sauf si la ligature prend la valeur de lettre autonome avec ses propres propriétés sémantiques dans une langue donnée). Il y a le modèle ad hoc{{ligat}} pour le faire (doc incluses) que j'ai créé pour ça (car le code est difficile à retenir, et le taper directement le redrait invisible la plupart du temps à l'édition). Certaines polices de caractères (de plus en plus nombreuses) supportent ces ligatures, et les logiciels commencent à ne tenir compte. Mais sinon cela affichera les lettres séparées (de la façon attendue), si le moteur de rendu ou la police sélectionnée ne supporte pas la ligature voulue. — Verdy_p (d) 27 octobre 2009 à 12:42 (UTC)Répondre
Attention, ce modèle ne concerne 'que les ligatures optionnelles, pas les signes utilisés comme abréviations qui sont des caractères séparés (et feront l’objet d’une codification dans Unicode à usage des médiévalistes et nos usages dans les textes utilisant la typographie du XVIe siècle et d’avant), ni les formes alternatives de lettres (comme le s long) : les accents sont un peu border-line dans nos textes car nos accents sont issus d’anciennes marques d'abréviations qui se sont placées ou collées aux lettres (y compris la cédille), et on les code séparément ou sous forme précomposée (forme normale canonique dite NFC en terminologie Unicode) quand ces combinaisons existent.
Le document sur lequel j'ai commencé la transcription est maintenant entièrement en version OCR (généré localement par l'OCR de Wikisource) seulement afin d'éviter d'oublier des mots ou éviter de se tromper de ligne (car leur contenu similaire est difficile à repérer) : c'est un guide servant à la transcription effective, et j'avance sur les pages qui doivent entièrement être révisées.
Pour l'instant je ne m'y occupe pas trop des ligatures, je préfère avancer sur le texte.
Note: mon pilote clavier a une touche facile pour taper les s long : je tape AltGr+s, il est totalement compatible avec le clavier français et supporte bon nombre d'autres lettres et combinaisons lettre+accent, je l'utilise depuis plusieurs années (et il est dispo sur Internet à la base prévu pour taper différentes langues européennes, pan-sahéliennes et d'autres à base d'alphabet latin : regarde http://www.rodage.org/pub/French-Sahel.html : ça s'installe tout seul ou se désinstalle normalement, puis tu remplaces le clavier français standard par celle-ci dans les options de la barre de langue de Windows XP, Vista ou Seven ; il est fait avec l'outil gratuit MSKLC de Microsoft). — Verdy_p (d) 27 octobre 2009 à 13:01 (UTC)Répondre
Ok, merci infiniment.
J’avais essayer MSKLC mais il me semblait trop compliqué. Encore plus simple, on a un gadget sur la Wikisource, ^s donne un ſ (et aussi œ, Œ, æ, Æ, ff, fi, etc. ce qui explique je j’utilise/utilisait autant ces caractères). Cdlt, VIGNERON * discut.27 octobre 2009 à 16:48 (UTC)Répondre
Ceci dit, je songeais peut-être inclure dans le modèle {{ligat}} la génération des caractères de compatibilité suivant une préférence de l'utilisateur: il aurait généré les deux, dans des classes CSS séparées, une étant visible, l'autre invisible. L'utilisateur pourrait choisir d'afficher les caractères de compatibilité dans sa feuille de style perso. Mais j'ai aussi remarqué qu'il y avait un gadget activé par défaut qui permettait d'afficher le "texte modernisé" (il bascule automatiquement ces caractères ligaturés en caractères simples, mais il remplace les s longs par les s finaux qu'on utilise aujourd'hui partout.)
Je ne sais pas si c'est une bonne idée, j'ai renoncé à le faire en pensant que cela modifiait le texte vu par les moteurs ou par les navigateurs sans support de CSS (ou dont CSS est désactivé). Il me semble qu'à plus long terme, ce serait plus une gène qu'autre chose.
Note que mon clavier inclue aussi œ, Œ, æ, Æ, ſ, ß, ø, Ø, ɩ, et aussi plus de touches mortes pour les diacritiques (par exemple É, È, Ù, Ç, Ÿ, etc. qui manquent sur le clavier français habituel). Bref j'y ai tous les caractères nécessaires au français, et pour la quasi-totalité des langues européennes à écriture latine, ainsi que les caractères pour les romanisations de langues asiatiques comme le japonais (par ex. ā, Ā, ē, Ē, ī, Ī, ō, Ō, ū, Ū), et encore d'autres pour les langues africaines (comme ɔ, Ɔ, ɑ, Ȃ, ƶ, Ƶ, ɽ, ƭ, Ƭ, ƴ, Ƴ, ɨ, Ɨ, ƥ, Ƥ, ɣ, Ɣ, ʃ, Ʃ, ɖ, Ɖ, ƒ, Ƒ, ɠ, Ɠ, ɦ, ƙ, Ƙ, ʈ, Ʈ, ɱ, Ƈ, ʋ, Ʋ, ɓ, Ɓ, ŋ, Ŋ, ...) qui se combinent aussi avec les diacritiques. Cependant le clavier ne convient pas au vietnamien.
Si tu ne vois pas comment utiliser MSKLC, le lien que je t'ai donné contient le pilote clavier tout prêt, ainsi que les représentations du clavier. Je ne fait évoluer de temps en temps pour inclure des caractères manquants (certains ont été ajoutés dans Unicode depuis que je l'ai fait initialement). Ce n'est pas compliqué à utiliser: au pire si tu ne te sors pas avec l’interface de MSKLC, il peut très bien fonctionner juste pour compiler le fichier source fourni qui est éditable avec un éditeur de texte normal et utilise une syntaxe facile à comprendre. Une fois MSKLC utilisé, installer le pilote généré est simplissime, car on ne voit plus de différence avec le pilote clavier par défaut, et ça marche dans tous les logiciels (même les éditeurs externes, au contraire du gadget que tu indiques). — Verdy_p (d) 28 octobre 2009 à 01:48 (UTC)Répondre
Pour le moment, je n’en ressent pas le besoin mais je garde ça dans un coin de ma tête.
Sinon, je continue la validation du Traitté du jeu royal des échets. Je suis un peu surpris par certaines de tes solutions. À la page 11, tu utilises iome. pour ce qui me semble être des chiffres elzéviriens, du point de vue sémantique ça me gêne un peu, ne pourrait-on pas utiliser quelque chose comme 10me (moins proche esthétiquement mais plus proche sémantiquement). Ces chiffres minuscules me posent souvent problème (cf. Questions techniques), connaitrais-tu une solution CSS ou Unicode ? Dommage que le small-caps ne fonctionne pas sur le chiffre, dommage aussi que peu de police les possèdent (donc impossible de forcer la police, ce qui me semble une fausse bonne idée de toute façon).
Unicode a clairement unifié ces chiffres avec les chiffres usuels (donc la seule solution resterait l’utilisation d’une police avc le style indiqué. Certaines polices contiennent les deux glyphes, qu'on peut sélectionner avec un feature, mais ce feature n’est pas encore standardisé en CSS (il faudrait un truc du genre "font-feature:alt-glyph"). Bref, pas d'appoximation possible pour l’instant.
C’est vrai qu’on pourrait faire diverses émulations (pour réduire la taille de certains chiffres et abaisser leur ligne de base), mais ce serait spécifique chiffre par chiffre (mais on n'aurait pas de zéro rond, ni de 1 en forme en petite capitale I romaine).
Le texte fait un usage très limité des zéro et des un (dans les numéros de pages et les titres de sections), et c'est le seul endroit où j'ai utilisé ça, ce qui est facile à corriger plus tard quand on aura le support des features de polices (ces features font par exemple partie de la police Times New Roman de Microsoft, et Word les utilisait (je ne sait pas s’il le encore quand on sauve un document en HTML avec Word 2009, il faudrait que je regarde s’il inclut un code pour activer ce feature, car ce que font les traitements de texte se reporte souvent que un autre et finit dans la norme CSS ; j'ai regardé dans le site W3.org sur le développement de CSS v3, et je n'ai pas trouvé). — Verdy_p (d) 29 octobre 2009 à 15:48 (UTC)Répondre
Je me demande aussi si cela ne vaudrait pas le coup de carrément créer une classe de texte avec empattement (text-serif par exemple) plutôt que de remettre un div à chaque fois en plus de la classe.
Note: les div sont pour les entêtes de page, on se fiche pas mal de ce qu'il y a dedans. Mais le problème est que le code n'est pas systématique, car cela dépend du fait que la page débute ou non au milieu d’un paragraphe.
De plus il faut jouer avec cerains paramètres d'alignements des lettrines, de l'interlignage (car les polices serif sont trop petites par défaut, et si on laisse l'interlignage 1.5 par défaut, le texte est bien trop grand et non conforme (l’original utilise un interlignage normal).
Ce que j'ai fait dans un autre document c'est de créer une feuille de style incluse dans une sous-page propre au texte, utilisée comme un sous-modèle inclus, et qui contient toutes les options de mise en page partagées d'une page à l'autre. Mais chaque document original a son style, ses préférences, c'est difficile de généraliser ça, donc je n'avais pas crée cela dans l'espace modèle. — Verdy_p (d) 29 octobre 2009 à 15:48 (UTC)Répondre
Note : le moteur texte/graphique Adobe FLEX supporte ces chiffres dans une extension de CSS avec le style "digit-case: (lining|old-style|inherit);" (la valeur par défaut est "lining" dans la plupart des polices)... Je ne sais pas s'il fonctionne dans les navigateurs... Il supporte aussi "digit-width: (proportional|tabular|inherit);" (la valeur par défaut est généralement "tabular" dans la plupart des polices). — Verdy_p (d) 29 octobre 2009 à 17:05 (UTC)Répondre
Essayons "digit-case:old-style" : 0123456789
Essayons "digit-case:oldStyle" : 0123456789
Essayons "digitCase:old-style" : 0123456789
Essayons "digitCase:oldStyle" : 0123456789
Ca ne marche pas chez moi sur aucun parmi: Safari, Mozilla, IE8, Chrome. Mais peut-être dans le navigateur d’Adobe (qui utilise son moteur de rendu FLEX, avec un préfixe expérimental de vendeur comme "-adobe-" ou "-flex-" ?) ? — Verdy_p (d) 29 octobre 2009 à 17:12 (UTC)Répondre
Microsoft Office utilise en fait le style: "mso-number-form:oldstyle" (mais avec un préfixe "mso-" non privé car il ne commence pas par un "-" donc non conforme HTML). — Verdy_p (d) 13 septembre 2010 à 12:37 (UTC)Répondre
Je ne parle pas de modèle mais de class ! Plus spécifiquement, je propose de remplacer <div class="pagetext"><div style="font-family:serif;font-size:120%;line-height:1.4;text-align:center"> par <div class="text-serif"><div style="font-size:120%;line-height:1.4;text-align:center"> pour « factoriser » le code, et plus exactement « factoriser » l’empattement (qui lui est commun a presque tout les livres) et pas les interlignages et autres mises en forme (qui elles diffèrent effectivement). Mais je me rends compte que tu as modifié le code, ma solution n’est donc probablement plus pertinente.
C'est vrai que les classes "text" (et "pagetext" pour le mode page) imposent un interlignage excessif. Alors que dans bien des textes, c'est la hauteur de ligne 1.2 (interlignage 0.2) qui est utilisé.
Cela ne résoud pas tout malgré tout car le pire n'est pas là mais dans le fait que la hauteur de ligne 1.5 est définie par défaut sur toutes les pages de ce wiki pour toutes les éléments HTML <p>, sans tenir compte d'aucune classe d'un élément englobant, alors que cet élément est généré implicitement après un simple saut de ligne.
C'est le principal défaut de la feuille de style par défaut le style appliqué sur toutes les occurences de l'élément <p>, qui n'a pas lieu d'être (y compris la définition de ses marges en haut et en bas de paragraphe) : je veux bien que ce soit défini pour ces éléments dans un div.text ou dans un div.pagetext, mais pas plus !
Bref ce problème ne vient pas du tout du navigateur (même le plus respectueux de tous), mais des feuilles de style CSS de Wikisource (qui ne sont pas assez sélectives). — Verdy_p (d) 1 novembre 2009 à 20:46 (UTC)Répondre
Ok, là tu m’a un peu perdu niveau technique.
Pour le respect, je parlais des chiffres minuscules.
J’ai quelques réflexions par rapport aux modèles {{ligat}}, pourrais-tu me dire ce que tu en penses ? Plutôt que d’avoir un modèle {{ligat}} (assez lourd en mode édition). Tout d’abord, ne faudrait-il pas interdire (au minimum déconseiller) ce modèle pour les ligatures obligatoires ? (æ, Æ, &, œ, Œ en français) En effet, ces ligatures ont une valeur orthographique (selon l’Académie française) et le caractère œ est courant (il a presque le statut de lettre indépendante, presque comme le IJ néerlandais). Les classes .ligature et .nonligature sont-elles vraiment nécessaire ? Si oui, il faudrait mettre cette classe dans le CSS de la Wikisource et un gadget serait mieux que d’avoir à modifier son CSS perso.
(Attention idée hasardeuse) ne vaudrait-il pas mieux un simple modèle {{ZWJ}} qui insère le caractère correspondant ? (pas de paramètres donc plus simple à utiliser et plus léger dans le code). (Attention idée encore plus hasardeuse) est-on vraiment obligé de passer par un modèle ? N’existe-t-il pas une solution qui pourrait faire les ligatures toutes seules ? (comme les espaces insécables qui sont automatiques gérées par MediaWiki).
Si tu connais la typographie, tu sauras que toutes les ligatures produites de façon automatique (sans recours à un dictionnaire d'exceptions) produisent des anomalies. Si une ligature est souhaitée il vaut mieux l'indiquer explicitement. Aucun moteur HTML ne fera de ligature automatique (même si certaines polices de caractères le font et c'est pour ça qu'on a aussi ZWNJ pour indiquer à ces polices de ne pas le faire). Je pense qu'un modèle ZWNJ ou ZWJ serait pire que l'indication correcte des ligatures là où on en veut.
Concernant les ligatures à caractère orthographique, il n'y a aucun mal au modèle: il génère toujours le bon caractère (et non la paire de lettres avec ZWJ) qui est encodé en tant que tel dans Unicode, et pas de façon obsolète (comme les ligatures "fi" ou "ffl" qui ne sont là que pour compatibilité avec d'anciens codages non Unicode). Les caractères "fi" ou "ffl" ou "ſt" ne doivent pas être utilisés (ils sont très hautement dépréciés, très mal supportés en fait dans les polices même les plus récentes et de qualité, et la façon standard est de coder chaque lettre avec ZWJ qui est pris en charge par le moteur de rendu, et qui a aussi une valeur orthographique dans des langues asiatiques, mais aussi en allemand).
C'est le cas par exemple de la ligature "ij" qui n'est plus considéré comme une lettre à part entière en néerlandais moderne mais comme un digramme, mais pour laquelle toute ligature automatique du digramme produit des anomalies. En néerlandais moderne, on code donc le digramme "i,j" ou "i,ZWNJ,j" (pour marquer les exceptions) sans aucune ligature de compatibilité, l'ancienne ligature "ij" n'ayant valeur de lettre qu'en néerlandais traditionnel où on la code distinctement. On a des cas similaires en allemand avec le esstsett (et ses exceptions). — Verdy_p (d) 13 septembre 2010 à 10:33 (UTC)Répondre
Dernier commentaire : il y a 13 ans3 commentaires2 participants à la discussion
Bonjour,
J’ai vu que tu avais fait pas mal de test sur mon essai de modèle lettrine. Comme tu as pu le constater, il y a quelques défauts pour les lettres avec diacritiques. Le problème est que en composition typographique, le placement d’une police se fait vraiment au cas par cas. Le modèle {{lettrine/2}} choisit une taille de police adaptée au nombre de lignes voulu, ce qui permet de répondre à presque tous les cas de figure, mais le défaut est un grand vide autour des lettres surtout pour les lettrines sans cadre. Mon approche est de choisir une taille de police volontairement trop grande, en adaptant pour les cas avec diacritiques. Pour l’instant je fais juste un cas particulier pour le Ç, le J et le Q (ces deux dernières, bien que sans diacritiques sont considérées comme dépassant du cadre de la baseline). Peut-être que mon approche est irréaliste vu le nombre de cas particuliers. Mais comme je disais plus haut, pour les lettrines, c’est toujours du cas par cas. Peut-être que l’approche du modèle lettrine/2 est plus saine, plus propre et plus réaliste et il est sans doute plus simple de rester comme cela. Bref j’aimerais avoir ton avis à ce sujet, sur le scriptorium serait aussi bien, pour que tout le monde puisse en profiter. Cordialement, Zaran (d) 3 septembre 2010 à 22:06 (UTC)Répondre
En effet, et d'ailleurs c'est en voyant ta page que je me suis aperçu que le calcul de la taille de police devait encore être affiné un peu. J'ai aussi simplifié un peu le modèle lettrine/2 (en réduisant le code HTML généré et le nombre de tests).
Ta page d'essai permet de mettre en lumière les cas (note: j'ai modifié les couleurs irréalistes pour des gris/noirs/blancs, pour des cas plus concrets). Avec CSS2/CSS3 on peut encore améliorer le rendu des lettrines avec un fond au format SVG (je vais voir s'il n'y a pas des motifs SVG de type lianes, feuillages ou arabesques...).
Les lettrines ont des métriques assez précises, quand tout est blanc, ce n'est pas vraiment une lettrine, mais l'espacement blanc doit rester là quand même : la lettrine se place comme une indentation (fixe) du paragraphe et ne doit pas dépendre de la lettre inscrite. Elle est traditionnellement carrée dans tous les textes soignés. — Verdy_p (d) 3 septembre 2010 à 22:26 (UTC)Répondre
Si l’on souhaite avoir des lettrines carrées, c’est plus compliqué. En effet, actuellement, le modèle lettrine règle la hauteur du span conteneur en fonction du nombre de ligne voulu, puis la taille de la police pour tenir dans le span : déjà ceci n’est pas parfait pour le Ţ ou les lettres avec diacritiques supérieurs. De plus pour les lettres plus larges que hautes (comme le W), le conteneur est étiré en largeur, il faudrait donc réduire dans ces cas là la taille de la police. En conclusion, j’ai l’impression que les limitations actuelles du css empêchent d’avoir une méthode propre et générale pour dessiner une lettrine conforment aux règles de la typographie quel que soit le cas de figure. Les modifications que tu as faites sur le modèle {{Lettrine/2}} me semblent bien. Crois-tu qu’on puisse encore beaucoup améliorer ce modèle ?
Une dernière remarque, ce que je n’aime pas trop du modèle {{Lettrine/2}} c’est le paragraphe <p> ouvrant, qui n’est pas fermé par le modèle. On compte donc, ou bien sur l’utilisateur pour le fermer, ou bien sur le parseur de wikisource pour détecter la fin du paragraphe, mais ce n’est pas parfait. J’avais choisi l’option de mettre un <br/> au début du modèle, ce qui a l’avantage de toujours commencer sur une ligne sans indentation. Penses-tu que ce soit une solution à garder ? Zaran (d) 4 septembre 2010 à 08:31 (UTC)Répondre
C'est simple : le conseil introduit un saut de ligne visible dans le texte complet, et le nowiki l'évite tout en maintenant la possibilité de débuter un paragraphe. L'exemple donné dans la doc le démontre !
D’ailleurs je viens de l’expliquer plus en détail dans cette page d’aide en ajoutant une phrase d’explication sur la différence et pourquoi un <nowiki/> et mieux qu'un <br/> pour produire le même effet sur les indentations horizontales de début de paragraphe mais sans modifier l’espacement vertical du paragraphe... L’astuce du "nowiki" est utilisé dans de nombreux endroits chaque fois qu’on veut éviter des suppressions automatiques de blancs par MediaWiki (par exemple dans des modèles, mais pas seulement). — Verdy_p (d) 13 septembre 2010 à 07:29 (UTC)Répondre
Peux-tu me montrer quel est le problème avec <br> ?
à quel endroit un saut de ligne en trop est-il introduit ?
Exactement à l'endroit qui était mentionné dans l'exemple de la page d'aide : tu peux comparer la page avant le remplacement du "br" par "nowiki" et après... Ce "br" rompt l'harmonie des espaces verticaux entre paragraphes. — Verdy_p (d) 13 septembre 2010 à 08:27 (UTC)Répondre
Pour simplifier voici l'effet du "br" entre deux paragraphes (et tu peux voir aussi comment le javascript positionne mal les numéros de page):
Je n'ai strictement rien dans mon CSS qui produit cela. Le fait est que le "br" persiste dans le code affiché et qu'il n'est pas sans effet. L'exempel donné dans la page le montrait, mais il y a d'autres endroits où cela se produit. Mais on n'est dans l'espace de discussion et le javascript ne fonctionne pas de la même façon ici... — Verdy_p (d) 13 septembre 2010 à 08:48 (UTC)Répondre
Tu noteras tout de même que l'interlignage entre paragraphes est de toute façon indésirable si les paragraghes sont indentés. Toutes les publications utilisant des paragraphes indentés (positivement ou négativement) n'imposent aucun interlignage supplémentaire entre paragraphes : c'est l'indentation qui joue déjà le rôle de séparation. Soit on indente les paragraphes, soit on les sépare par un interlignage plus important, mais pratiquement jamais les deux en même temps (il n'y a qu'ici qu'on fait ça de façon redondante, et c'est assez gênant pour le mode page dont le rendu s'allonge inutilement). — Verdy_p (d) 13 septembre 2010 à 08:53 (UTC)Répondre
je suis d’accord pour ce qui est de l’interlignage, mais c’est une propriété de style du wiki, qui n’a rien à voir avec la question du "br". il est possible de changer cela avec le CSS.
je répète ma question : peux-tu me montrer un exemple où le "br" induit un saut de ligne en trop ?
J'ai tenté de reproduire plus exactement ici ce qui est produit effectivement en HTML (les numéros de pages sont en fait générés dans un double span, l'un dans l'autre, on se demande pourquoi ce code inutile !). Je ne parviens pas à le faire dans une page de discussion. C'est visible dans l'espace principal, ou si on désactive le javascript et qu'on consulte en mode HTML simplifié (sans feuilles de style), ou en mode d'accessibilité WAI pour lecteurs Braille, et en rendu audio (le br provoque une courte pause en plus avant la lecture du paragraphe suivant, les aveugles ayant l'ouïe très fine et pouvant écouter et comprendre un texte parlé beaucoup plus rapidement que nous, souvent 2 à 3 fois plus vite que nous, même et surtout lorsqu'il est prononcé en voix de synthèse). Par prudence, il vaut mieux ne pas le mettre. Personnellement je vois très bien la différence, même ici. Essaye d'autres navigateurs : un br en fin de paragraphe n'est pas totalement sans effet visible (il est de plus lui-même sensible au CSS concernant l'interlignage qu'il produit lui-même), et il vaut mieux ne pas le mettre si on peut s'en passer, le but étant seulement de limiter l'effet des blancs ôtés automatiquement par MediaWiki en début et fin de zone d'édition dans le formulaire, un nowiki (qui ne fait rien en lui-même) suffit à éviter cette suppression de blancs et a le rôle voulu sans introduire de code supplémentaire dans la page générée. De plus il est insensible à la façon dont la page est transclue dans une autre page. — Verdy_p (d) 13 septembre 2010 à 09:16 (UTC)Répondre
le double span est présent pour des raisons historiques et sera supprimé plus tard. mais là encore, tu changes de sujet, ça n’a rien à voir avec le br.
si tu penses que le problème est lié aux pages de discussion, peux-tu me montrer un exemple dans l’espace principal ?
Avec Opera 9 le problème est visible (et tous les numéros de pages sont mal placés par le Javascript bogué qui tente de créer une colonne parallèle au lieu de positionner simplement les numéros de page comme des éléments flottants à gauche, positionnés en marge avec "float:left;left:-3em"... sans avoir besoin de modifier le layout, opération très dangereuse et ultra-compliquée en Javascript, quand ça peut fonctionner même sans aucun Javascript qui ne doit être là que pour afficher ou non les pages avec "display:none" ou "display:block"). Ce code "historique" est plus perturbant qu'autre chose, et la "nouvelle" façon de faire en Javascript a en fait cassé le Wikisource anglophone dont les numéros de page sont tous mal positionnés (quel que soit le navigateur utilisé d'ailleurs, et qui casse complètement toutes les pages affichées ou imprimées en multicolonne). Un javascript ne doit pas modifier le layout sans raison et sans intervention explicite de l'utilisateur.
les numéros de pages sont positionnés avec javascript afin de ne pas introduire d’éléments étrangers dans le texte; sinon les numéros de page interfèrent avec les moteurs de recherche.
je vois en effet qu’Opera positionne mal le numéro de la page dont tu parles, mais pour autant que je puisse voir, ce problème est présent que l’on utilise "br" ou "nowiki".
Tout à fait, mais on peut de toute façon positionner les numéros de ligne sans casser le layout, et sans déplacer le texte de la section de classe "text". Il suffit de générer les flottants exactement à l'endroit où sont les span "pagenum" (et pas besoin d'ajouter non plus des span "my-ct", "my-ss", ou autres div du même acabit id="text-container"). De plus il manque la délimitation correcte de la fin de texte que le javascript identifie mal, alors qu'il devrait se limiter à la fin du div "text". J'avais bien compris que le but était que les numéros de page n'apparaissent pas dans le texte brut, il n'empêche que le javascript ne doit PAS toucher au layout de façon aussi dangereuse et compliquée.
Enfin l'id généré n'est pas unique comme tu le crois (tu as supposé que le numéro de page ne sera utilisé qu'une seule fois, ce qui n'est pas nécessairement le cas, les pages pouvant reprendre la numérotation d'une section à l'autre du livre et ces numéros n'étant pas non plus nécessairement des identifiants valides (par exemple avec des ponctuations spéciales j'ai vu le cas avec des pages nommées "—" ou "Ire") ; pour indiquer le numéro de page, il vaut mieux utiliser un autre attribut (privé) de données tel que x-page="..." au lieu de id="..."). Ça explique pourquoi certaines délimitations de page disparaissent (quand un même numéro de page apparaît plusieurs fois).
Et si le javascript doit indiquer des numéros de page en marge, il vaut mieux qu'il calcule correctement la largeur de marge nécessaire en corrigeant les marges des éléments de classe "text" (on a parfois des noms de page plus long que "3em", par exemple "Préface", "Introduction", "Avertisssement", et parfois aussi des espaces interdits dans un id="..." valide, ou d'autres caractères, tel que: id="Page 3", id="1.a", id="II/2" ; l'id est une valeur opaque qui ne doit jamais être utilisé pour le rendu, et s'il faut mettre un texte affichable, on a l'attribut standard title="", ou bien un attribut HTML privé dont le nom commence par "x-", comme recommandé en HTML5, tel que x-page="..."). — Verdy_p (d) 13 septembre 2010 à 10:04 (UTC)Répondre
en attendant, pouvons-nous éviter de changer de sujet ? ma question est : pourquoi remplacer "br" par "nowiki"?
je t’ai demandé de fournir un exemple qui illustre l’intérêt de ce changement.
Je l'ai déjà dit dès le début : la page donnée en exemple de la page d'aide le montre clairement, d'ailleurs pour que tu le voies j'ai remis le br dans cette page à la place du nowiki qui corrigeait le problème. — Verdy_p (d) 13 septembre 2010 à 12:39 (UTC)Répondre
merci de te calmer, et de fournir un exemple descriptif du problème.
il se peut que le saut de ligne en trop que tu as constaté vienne de la page d’avant, et pas de la page contenant le "br". c’est pour cela que je voudrais avoir un exemple.
Je ne me suis pas énervé, j'ai juste répété ce que j'ai dit, puisque tu ne l'as pas lu.
C'est vrai que le document cité en exemple a des problèmes de sauts de lignes lors des sauts de page. Il faut voir cet exemple dans l'affichage du texte complet et non de la page seule (donc cliquer sur "Pages liées" pour remonter au texte qui inclue la page.) Je ne dis pas que la solution avec br ne marche pas pour l'indentation du premier paragraphe de la page, mais que cela produit des effets indésirables, et que nowiki fait la même chose sans ces effets, c'est aussi simple d'ailleurs (4 lettres de plus rien de méchant). — Verdy_p (d) 13 septembre 2010 à 12:58 (UTC)Répondre
tu as écrit plus haut "le conseil introduit un saut de ligne visible dans le texte complet, et le nowiki l'évite"
cela veut dire que le "br" introduit un saut de ligne en trop, non ? je voudrais voir ce saut de ligne en trop. où est-il ?
Il est dans le HTML généré... C'est suffisant pour produire l'effet indésirable, alors qu'un nowiki vide ne génère strictement rien (et ne dépendra d'aucun navigateur ou de sa façon d'interpréter ou présenter les ruptures forcées en fin de paragraphe, ni d'aucune feuille de style CSS, quelle que soit la façon dont elle est conçue : les feuilles CSS de Mediawiki sont déjà très compliquées, et on a de nombreux effets de bord et autant éviter celui-là). Tu ne comprends pas la différence ? Je ne vois pas ce qui te choque là-dedans : est-ce si compliqué à faire ou à comprendre ? — Verdy_p (d) 13 septembre 2010 à 13:28 (UTC)Répondre
Je cherche juste à comprendre ce que tu écris. Tu as écrit pour commencer que "br" introduit un saut de ligne visible. Or maintenant tu sembles dire le contraire, que le saut de ligne est "dans le html généré", ou bien qu’il apparaît si on utilise une interfaces pour malvoyants, ce qui n’a rien de "visible". Ce n’est pas cohérent. J’ai de bonnes raisons de penser que tu as vu un saut de ligne induit par la page précédente (c’est le cas avec certaines pages créées anciennement), et j’ai pensé que c’est à cause de cela que tu as changé br en nowiki.
Oui dans le HTML généré, donc produisant un résultat visible dépendant du navigateur ou des feuilles de style ou de l'interprétation du contenu par un indexeur. Chez moi c'est clairement visible à l'écran sur plusieurs de mes navigateurs. Il n'y a pas contradiction. — Verdy_p (d) 13 septembre 2010 à 15:30 (UTC)Répondre
Utiliser "nowiki" au lieu de "br" me semble plutôt une bonne idée. Mais la manière dont tu t’y prends est mauvaise. Il aurait été plus productif d’en discuter avant, et d’exposer clairement tes raisons, au lieu de modifier une page d’aide sans donner d’explications, puis de me réverter, et enfin de donner des réponses qui passent du coq à l’âne (tantôt le changement est "visible", tantôt il ne l’est pas).
Justement j'en discute avec ceux qui sont intéressés. Mes explications ne passent pas du coq à l'âne, puisque l'effet est bel et bien visible (et en fait attendu par le comportement même de la balise br, dont rien en HTML ne garantit qu'elle sera sans effet en fin de paragraphe, et justement ce n'est pas le cas dès qu'on en met plusieurs...). — Verdy_p (d) 13 septembre 2010 à 15:30 (UTC)Répondre
ça fait plusieurs années que nous utilisons un "br" pour marquer le début d’un paragraphe, et ce "br" est sur un très grand nombre de pages. Si nous décidons de changer de méthode, cela va introduire de la complexité : certains utilisateurs vont se demander pourquoi certaines pages utilisent "br" et d’autres "nowiki". Il eut été plus judicieux d’utiliser un modèle.
Pas la peine de tout changer. Mais on peut revenir sur une pratique et corriger là où on verra le problème. Il n'apparaît pas partout (et il y a aussi les effets de bord du Javascript qui insère les numéros de page et modifie le DOM HTML, donc avant ça on ne va pas tout changer...) — Verdy_p (d) 13 septembre 2010 à 15:30 (UTC)Répondre
si tu as des améliorations à proposer au javascript, je suis tout à fait prêt à les prendre en considération. par exemple, tu peux réécrire la fonction qui ajoute les numéros de page et me montrer le résultat, si tu penses pouvoir mieux faire.
J'ai essayé, mais dans l'état actuel il est totalement impossible de désactiver le script actuel (notamment celui qui modifie le layout, les fonctions "init_page_layout()" ou "init_page_numbers()" ne peuvent pas être inhibées du tout et leur ordre de chargement est imprédictible (varie selon le temps de réponse du serveur pour voir si les scripts ont changé ou si la version en cache peut-être utilisée).
Pour moi, la seule façon de tester ça sera dans un javascript chargé hors de Wikisource (par exemple sur une sous-page de ma page perso Wikipédia, et chargé via mon monobook.js ou vector.js qui l'inclueront ; j'ai déjà des scripts persos là-bas et sur d'autres wikis pour gérer diverses autres choses comme la correction du tri des tableaux, et quelques scripts utilitaires, en général je rapatrie tous mes scripts sur Wikipédia, et je les inclue indirectement depuis les autres wikis avec un monobook.js ou vector.js minimal se contentant de les inclure indirectement, afin d'éviter des copies partout : maintenance plus facile à un seul endroit).
Ce serait bien que le script inclue une variable javascript testée (ou teste un cookie, comme le fond les autres extensions ou une variable des préférences utilisateur), qui permet de le désactiver, et de ne pas charger les fonctions correspondantes. Ensuite on peut essayer un autre script de remplacement. Cette extension n'est pas non plus désactivable non plus dans les préférences utilisateur. Cela m'empêche donc de vouloir tester un autre script alternatif corrigeant les problèmes actuels. Dans l'immédiat, le "double span pour pagenum" est inutile et peut déjà être supprimé, et l'espace placé avant ce span devrait être plutôt placé après, pour qu'il soit éliminé automatiquement en fin de paragraphe si la coupure de page a lieu en fin de paragraphe, sinon il s'affiche parfois avant la fin de paragraphe sur la ligne suivante, si un paragraphe est assez long, avec certains navigateurs (alors qu'il ne serait pas gênant du tout s'il était juste avant la balise </p>), cet espace étant là pour seulement séparer les mots d'un même paragraphe coupé par une coupure de page). — Verdy_p (d) 13 septembre 2010 à 14:06 (UTC)Répondre
Note: cela ne permet pas de réécrire cette fonction, puisque tu fais le test DANS la fonction plutôt qu'en dehors. Normalement il faudrait ne pas définir la fonction du tout et ne pas appeler cette fonction (avec OnLoadHook) si la variable de débogage est présente, afin de pouvoir en fournir une version alternative. Il serait en fait préférable que tout le script soit désactivable (avec tout ce qu'il définit) en testant cette variable, ce qui permet d'en faire une version de remplacement.
Essaye de désactiver le script toi-même avec cette variable définie dans ton monobook.js perso, tu verras que ça ne marche pas la plupart du temps.
En fait, il n'y a aucun moyen de prédéfinir la variable testée car on ne peut garantir que notre monobook.css ou vector.css perso se chargera avant (en fait il est chargé après, la plupart du temps, la façon propre serait que le script soit désactivable dans les préférences de Gadgets afin même qu'il ne se charge pas du tout, comme les autres extensions Mediawiki, ce que confirme le panneau développeur de Chrome qui permet de pister et déboguer l'ordre de chargement et d'exécution des ressources): place un point d'arrêt dans la première ligne de ton monobook.js, et dans la première ligne de ton script : tu verras que celui de ton script est atteint en premier, avant celui de ton monobook.js perso, presque tout le temps, mais qu'en revanche l'ordre est modifié si on accède à la page via la fonction retour arrière du navigateur (via l'historique). — Verdy_p (d) 13 septembre 2010 à 15:30 (UTC)Répondre
En fait j'ai mis "debug_page_layout=true;" dans mon monobook.js, et ça marche une fois sur 4 (les numéros de pages ci-dessus apparaissent ou pas...), ça marche seulement la première fois puis tout dépend de l'ordre de rafraichissement et d'exécution des scripts par le navigateur et des temps de réponse du serveur sur les diverses requêtes qui s'exécutent en parallèle dans un ordre indéfini pour OnLoadHook()... Les scripts ne devraient jamais dépendre d'un ordre d'exécution précis, mais ce n'est pas le cas, ils s'exécutent dans un ordre aléatoire (ce qui explique que de nombreux scripts redéfinissent les mêmes fonctions utilitaires). Normalement, on doit juste définir les fonctions et variables nécessaires, puis seulement exécuter les fonctions dans OnLoadHook() seulement, mais OnLoadHook ne fait pas toujours ça, et exécute souvent la fonction directement, selon qu'une variable interne de MediaWiki est définie ou pas. Chaque script devrait aussi définir tout ce dont il a besoin dans sa propre classe avec une variable objet unique, ou bien utiliser un préfixe de nommage unique (ce n'est pas le cas ici non plus, le script n'est pas propre), la première solution étant bien meilleure pour éviter les collisions de noms. — Verdy_p (d) 13 septembre 2010 à 15:43 (UTC)Répondre
J'en reviens donc à mon idée initiale: je vais faire un script modifié sur mon compte Wikipédia où je ne serai pas gêné par le script actuel qu'il n'y a pas moyen de désactiver proprement avec un ordre de chargement et d'exécution prévisible. — Verdy_p (d) 13 septembre 2010 à 15:49 (UTC)Répondre
Désolé, la désactivation marche : je n'avais pas vu que tu avais défini deux variables de débogage, je n'en définissais qu'une seule. Ça va me permettre de faire le test avec des fonctions renommées (car je crains qu'elles soient écrasées par le chargemetn du script qui teste les variables mais force la définition de ces fonctions). — Verdy_p (d) 13 septembre 2010 à 16:17 (UTC)Répondre
Ce que tu écris est assez bizarre… si je faisais le test à l’extérieur de la fonction, comme tu le préconises, alors oui, le test serait dépendant de l’ordre de chargement des scripts. Mais ce n’est pas le cas : la variable est testée dans la fonction, ce qui permet de la désactiver de manière fiable. J’aimerais un peu plus de détails sur les difficultés que tu rencontres. ThomasV (d) 13 septembre 2010 à 16:24 (UTC)Répondre
Ce que tu ne comprends pas est que même si tu fais le test DANS la fonction, cela a pour effet de définir malgré tout cette fonction. De fait elle va écraser toute autre version de cette fonction. Cela dépend donc de l'ordre de chargement. Les variables utilisateur en revanche sont bien chargées avant les autres scripts, donc tu peux tester HORS de la fonction si la variable est définie pour NE PAS définir (et écraser) la fonction.
J'ai commencé à faire une version en classe (prototypée) de ce Javascript (toutes les fonctions utilisées et définies sont dans le même objet et pas dans l'espace de nommage global "window", un unique nom est défini dans l'espace global pour l'extension elle-même, et il contient TOUT ce qui est nécessaire à ce script).
Je travaille actuellement sur le CSS permettant d'aligner correctement les numéros de page. Le javascript ne fait plus aucun déplacement de pour positionner les numéros de page, les "layouts" sont pris en charge, mais ne sont pas absolument nécessaires.
Cela va séparer en deux la fonction de gestion des "layouts" (maquettes) et celle des numéros de page qui sera totalement indépendante dans une extension séparée ne demandant pas l'activation des maquettes. Cela devrait aussi corriger le problème majeur existant sur Wikisource anglophone qui est complètement cassé depuis que tu as inclus les "layouts" dans le même script.
De plus je corrige le code incorrect dans les layouts (il suppose qu'il n'y a qu'un seul div de classe "text" dans la page, ce qui n'est pas toujours vrai, et le layout de toute façon ne fonctionne pas correctement pour les numéros de page quand le texte est en plusieurs colonnes : le javascript sur lequel je travaille ne supprime plus ces classes, qui sont nécessaires, mais les remplace par une classe unique "text-layout", mais ça pourrait être le "text-wrapper" existant si je travaille un peu plus. — Verdy_p (d) 17 septembre 2010 à 15:09 (UTC)Répondre
pourquoi tiens-tu à donner le même nom à ta fonction ?
j’ai hâte de voir le résultat. Peux-tu me montrer ce qui est cassé sur en.ws ?
Note : Je suis d’accord avec ta remarque plus haut : on pourrait utiliser "float:left;left:-3em;" pour positioner les numéros de page. Cependant, ça ne résout pas le problème de l’alignement horizontal, causé par la longueur variable des numéros de page. Une solution pourrait être de placer le numéro de page dans un span qui flottant à droite, placé lui même à l’intérieur d’un span "float:left" de largeur fixe. ThomasV (d) 17 septembre 2010 à 22:40 (UTC)Répondre
hmm, je viens de faire le test (avec position:absolute), mais le résultat n’est pas concluant: ça casse la recherche sous Firefox (une des raisons pour lesquelles nous sommes passé au javascript), et ça impose de positionner les numéros de page à une distance fixe du texte, où ils risquent de recouvrir des notes latérales. ThomasV (d) 17 septembre 2010 à 23:23 (UTC)Répondre
Je ne dis pas qu'il ne faut pas de Javascript, juste que le code qu'il génère n'est pas correct. De plus "float:left;left:-3em" doit être positionné dans un conteneur relatif: ce conteneur est la colonne de texte qui a une marge gauche de 3em minimum. J'ai fait le test aussi et ça marche de façon excellente.
Que veux-tu dire par « ça casse la recherche » ? Les flottants sont hors flux, et peuvent être placés même dans un span (dans le span "pagenum" vide par le javascript).
Placer ces flottants hors du cadre ne fonctionne pas: les numéros ne suivent pas, même avec la fonction pour rafraichir les positions, et en plus soit ils se superposent au mauvais endroit, soit ils sortent de la page quand on a du texte multicolonnes (typiquement, dès la seconde colonne, ces numéros de page apparaissent sous la première colonne au delà du bas de page). La colonne des numéros de page ne sait pas faire la différence puisque tu positionnes les numéros de page horizontalement à une position fixe (mais incorrectement pour ce qui est de la position verticale, comme on le voit dans Opera 9 et sur Wikisource anglophone). Ton code dépend entièrement de la présence ou non de l'attribut "position:relative" dans TOUS les blocs conteneurs (ce qui n'est pas toujours le cas, et explique aussi pourquoi quand la coupure de page a lieu au milieu d'un paragraphe, le numéro de page est calculé à la position du haut de ce paragraphe, et le bas de page est toujours un peu trop haut (si la coupure de page est en fin de paragraphe, le span "pagenum" est en bas de cette page à la droite de la fin du paragraphe, au lieu d'être positionné immédiatement après, sachant qu'il y a aussi une espace séparatrice de mots générée entre les deux pages transclues). — Verdy_p (d) 17 septembre 2010 à 23:43 (UTC)Répondre
Par "ça casse la recherche", je veux dire qu’il faut que la recherche d’une phrase (control-F) puisse se faire même aux endroits où il y a des numéros de page. Si tu peux résoudre ce problème avec un float, merci de faire une démonstration. ThomasV (d) 18 septembre 2010 à 06:23 (UTC)Répondre
Dernier commentaire : il y a 13 ans29 commentaires4 participants à la discussion
Depuis les dernières modifications sur le modèle, la visualisation n'est plus correcte. En effet, maintenant les pointillés ne commence plus juste après le titre mais sur une seconde ligne ce qui est une erreur. Je ne sais pas laquelle des nombreuses modifications a introduit l’erreur donc pourrais-tu corriger le modèle ? Merci. Loïc Mottier (d) 13 septembre 2010 à 10:49 (UTC)Répondre
Tu peux me dire quel navigateur tu utilises ? Car j'en ai testé de nombreux (IE6, IE7, IE8, Firefox, Opera, Chrome, Chromium, sous Windows et Linux) et dans les deux thèmes Vector et Monobook. En mode HTML4 de compatibilité, HTML strict, XHTML de compatibilité et strict, et HTML5. J'ai fait très attention à la sémantique exacte du CSS et au dimensionnement très précis de l'ensemble, et à la sémantique du texte brut (affichage sous Lynx par exemple, et test avec un émulateur WAI pour les lecteurs d'écran).
Le problème qui existait avant ne marchait pas non plus de façon attendue : des caractères étaient tronqués en bas (notamment les minuscules avec jambes, ce qui faisait confondre j comme i, ou g comme q, voire a dans certaines polices, et selon les tailles de police utilisées).
Et si ce problème est spécifique à une page, sur quelle page tu vois le problème ? Il est possible que ce soit normal qu'il apparaisse sur une seconde ligne si la première est trop longue. L'important étant que les pointillés soient sur la même ligne que le numéro de page: selon la maquette d'affichage utilisée, on peut avoir différentes largeurs de pages.
De plus des simplifications ont été faites dans le code pour l'optimiser dans le cas où il n'y a pas de pointillés (paramètre 1=nodots), et pour les positionner de façon très stricte. — Verdy_p (d) 13 septembre 2010 à 11:14 (UTC)Répondre
J’utilise FireFox 2.0.0.20 et je vois déjà le problème dans la page de documentation du modèle. Je peux confirmer qu’avec FireFox 3.5.3 la page documentation se voit correctement. Loïc Mottier (d) 13 septembre 2010 à 11:21 (UTC)Répondre
Je n'ai pas testé les anciennes versions (Firefox n'installe-t-il pas des mises à jour automatiquement ? C'est hautement recommandé pour d'évidentes raisons de sécurité, Firefox ayant de nombreux trous de sécurité si on ne le met pas à jour). Il va falloir que je regarde en installant Firefox 2 dans une machine virtuelle Windows (VirtualBox), pour en expliquer l'origine. C'est peut-être un bogue de Firefox 2, mais je ne peux l'expliquer comme ça, d'autant que les pointillés sont repositionnés verticalement avec une marge négative, comme c'était déjà le cas avant. J'ai suivi les spécifications CSS à la lettre. — Verdy_p (d) 13 septembre 2010 à 11:31 (UTC)Répondre
En attendant que j'installe une version vierge de Windows dans une VM pour y installer Firefox 2, as-tu une copie d'écran (pas nécessairement sur Commons, un lien vers une page perso sera aussi bien c'est pour un usage temporaire afin de voir ce que tu obtiens) ? Note j'en suis à Firefox 3.6.9 sur mon installation principale.
Les seuls navigateurs non testés sont ceux sur MacOSX, mais j'ai testé Safari pour Windows : les utilisateurs de MacOSX préfèrent souvent Safari puisqu'il est installé par défaut par Apple (même si d'autres utilisent aussi Firefox voire une vieille version d'IE pour Mac, une version d'IE que Microsoft a abandonnée depuis longtemps en passant un accord commercial avec Apple pour promouvoir MS Office sur les Mac; sinon Apple aurait promu OpenOffice, suite à ses accords avec IBM et Oracle/Sun pour Java dont Apple produit sa propre version dérivée de celle de Sun, mais avec des ajouts de librairies faits par IBM pour son interface Cocoa et qu'Apple a fournies aussi à IBM pour son excellent atelier open-source Eclipse, concurrent, mieux fichu et plus intelligent que l'atelier de Microsoft...). — Verdy_p (d) 13 septembre 2010 à 14:25 (UTC)Répondre
Je viens de rajouter un "position:relative" dans les élements qui utilisent "z-index:". Normalement ce n'est pas nécessaire car tous les éléments sont positionnés en profondeur par le navigateur dans un ordre, que z-index vient seulement modifier. Mais j'ai lu ans un article que Firefox 2 ignorait "z-index" si l'élément n'était pas positionné (avec "position:absolute" ou "position:relative"). J'espère que ça corrige le problème chez toi, sur les autres navigateurs ce positionnement n'aura pas d'autre effet, car en fait les éléments ne sont pas positionnés, mais le second avec "z-index:1" (pour qu'il s'affiche en arrière-plan) a seulement une marge supérieure négative.
Si ça corrige le problème dis-le moi. La modif que je viens de faire je viens de la tester dans 8 navigateurs et les 2 thèmes Vector et Monobook (et j'ai encore simplifié un peu le code avec un z-index:1 superflu qui trainait). — Verdy_p (d) 13 septembre 2010 à 15:00 (UTC)Répondre
Article intéressant à lire montrant les bogues des vieilles versions de navigateurs par rapport à leur façon de gérer le "stacking order" et les positionnements:
Merci de t’occuper du modèle Table, il en a bien besoin. Par contre, j’ai la même visualisation défaillante que Loïc mais sous IE7.0 (et Windows XP SP3, config de travail). Autant pour Firefox 2, je peux comprendre que cela ne vaille pas la peine, mais pas pour IE7 (18,16% de part de marché en octobre 2009, le chiffre doit être plus bas maintenant mais toujours pas négligeable - malheureusement). Cdlt, VIGNERON * discut.14 septembre 2010 à 13:32 (UTC)Répondre
Merci pour la capture, le problème n'est pas là où je le pensais, car les pointillés sont bien sur la même ligne que le numéro de page (ce que vous ne m'aviez pas dit). J'ai eu beau tester 8 navigateurs sur 2 plateformes et 2 thèmes cela n'a pas suffit à détecter le problème. En fait le problème n'est pas sur les pointillés ou z-index mais sur le saut de ligne qui intervient entre le titre et le numéro de page (vous ne l'aviez pas dit... Je vais voir pourquoi ça se produit car le code ne contient aucun saut de ligne entre les deux.
Vizarre tout de même que vous ayez ça sous IE7, car chez moi IE7 (ni IE6 non plus) ne produit pas ça... Le code CSS et HTML généré est pourtant parfaitement propre. — Verdy_p (d) 15 septembre 2010 à 03:38 (UTC)Répondre
Oui, désolé, j’ai débarqué sans prévenir ni préciser tout les détails. Donc pour information, cela me le fait que je sois sous Vector ou Monobook (et "pour rire", idem sous toutes les autres apparences comme "Bleu de Cologne", "Moderne", "Nostalgie" "Poussin", "Simple", "Standard").
J’ai testé quelques trucs (retiré les paramètres du modèle "inutiles" largeurp, indentation, espace pour garder le minimum, retirer la classe pagetext pour avoir une plus grande largeur, etc.) mais rien n’y fait. En regardant le code source, et je ne vois étrangement pas de br (par contre il y a un div style="clear:right" serait-ce ça ? j’avoue ne pas comprendre tout le code).
Les paramètres "inutiles" sont testés dans le modèle : si on ne les précise pas, leur effet est annulé par des tests de manière à simplifier le code HTML/CSS généré au strict minimum. C'est pour ça que ça ne change rien pour toi ! Ils ne sont pas si inutiles que ça, je les ai gardés tous pour compatibilité, même si je critique les paramètres "largeurp" et "largeurs" (en pixels et non en "em" comme ça devrait l'être... Je pense mettre un autre paramètre optionnel pour autoriser un changement d'unité ici, car c'est nécessaire pour l'accessibilité avec un agrandissement des polices seulement dans le navigateur, ce qui est différent du zoom qui agrandit toutes les unités y compris les pixels, "em", "en", "mm", "in", "%"...). — Verdy_p (d) 15 septembre 2010 à 11:53 (UTC)Répondre
J’imagine bien que le problème vient plus de IE7 que de ton code... Je ne connais pas de solution.
Justement je regardais l'effet de ce clear que j'ai rajouté plus tard pour certains cas où le numéro de section ou de page était plus large que la largeur prévue. C'est de là que vient le problème. J'ai trouvé le moyen de tester pour IE7 (le bogue n'intervient que dans son mode dit "de compatibilité", mais pas dans le mode de compatibilité de IE8 ou IE9. — Verdy_p (d) 15 septembre 2010 à 10:48 (UTC)Répondre
Je crois que c'est corrigé : cette fois j'ai testé avec 30 navigateurs ! (et diverses versions, y compris MacOSX, Linux et smartphones)... Il m'a fallu du temps pour installer les machines virtuelles. Le code fonctionne cette fois dans:
IE4/Win, IE5/Win, IE/OSX, Netscape 4/Win
IE6/Win, IE7, IE8, IE9, (Y compris aussi dans le mode de compatibilité de toutes les versions IE qui l'ont !)
Firefox 2/Win, Firefox 2/OSX, Firefox 2/Linux,
Firefox 3/Win, Firefox 3/OSX, Firefox 3/Linux,
Chrome 2/Win, Chrome 3/Win, Chrome 4/Win,
Safari 3/Win, Safari 3/OSX,
Safari 4/Win, Safari 4/OSX,
Opera 8/Win, Opera 9/Win,
KHTML/Linux
WebTV (noyau Opera, testé sur téléviseur Phillips), IE/Smartphone (émulation), Ericson (smartphone), Sony (smartphone)
et même bien que ce soit en mode texte seul (mode dégradé):
Lynx/Linux
Simulateur WAI pour lecteurs braille
ainsi que dans un navigateur désactivant tout javascript et CSS avec un rendu HTML4 de base)
Le clear:right était bien responsable, je n'ai enlevé car il n'est pas nécessaire à l'endroit où il était (le numéro de page est en "nowrap", il ne peut pas descendre), mais j'ai modifié le clear final tout en bas pour un clear:both afin qu'il agisse à la fois sur le numéro de section et le numéro de page. — Verdy_p (d) 15 septembre 2010 à 11:14 (UTC)Répondre
En fait la page de test que tu utilises précise une largeur trop petite pour les numéros de page flottants, c'est pour ça qu’ils descendent (car ils n'ont pas la place pour s'afficher dans la largeur indiquée). C'était aussi pour ça que j'avais mis le "clear:right", afin de s'assurer que les pointillés soient toujours sur la même ligne que le numéro de page. Voyant cela je vais voir comment ajuster la largeur du numéro de page. J'ai fait mes tests sur des index correctement formatés avec une largeur suffisante pour le numéro de page. Je vais les refaire dans le cas où la largeur est insuffisante (ce qui se produit avec largeurp=0)...
Grrrr.... Qui a mis des largeurs en pixels ? Ca ne fait que compliquer le modèle pour le calcul des marges, et c'est incohérent car cela dépend des polices du navigateur ou des préférences d'affichage des polices pour l'utilisateur, là où il aurait fallu des largeurs en "em". Ca m'a déjà causé bien des difficultés pour éviter que des caractères soient tronqués (et c'est aussi pour ça que j'avais voulu le corriger.
Note: pas la peine de charger plein d'images sur Commons: écrase-les sous le même nom (Commons peut stocker différentes versions de la même image), afin de ne pas polluer trop l'espace de nommage de Commons. — Verdy_p (d) 15 septembre 2010 à 11:46 (UTC)Répondre
J’utilise FireFox 2.0.0.20. Le système est Windows 7 en italien. J’ai essayé d’augmenter le paramètre largeurp, de l’enlever, sans que cela change quoi que ce soit. Peux-tu me passer un morceau de code HTML qui fonctionne chez toi ? Je pourrai le mettre dans une page HTML et voir comment elle vient chez moi pour vérifier sile problème est ma configuration de FireFox. Loïc Mottier (d) 15 septembre 2010 à 12:04 (UTC)Répondre
La page de doc du modèle elle-même fonctionne. Le problème est sur "largeurp" (un flottant DOIT avoir une largeur, mais s'il ne tient pas dans la largeur indiquée de son conteneur, il va descendre sous ce conteneur. C'est ce qui provoque cet effet. La largeur du conteneur dépend des marges qu'on lui a laissé pour s'étendre. C'est bien pour ça que le "clear:right" était là, car cela arrive que le numéro de page ne tienne pas dans la ligne après le titre qui reste prioritaire. On a deux effets qui se combinent ici). Je vois le problème et j'ai déjà une page HTML séparée de test que j'ai utilisée pour tester les 30 navigateurs. Je suis en train de compléter cette page pour le cas des numéros de page trop larges par rapport à la marge réservée à droite. — Verdy_p (d) 15 septembre 2010 à 12:17 (UTC)Répondre
J'ai fait de très nombreux tests, il m'a fallu plusieurs jours pour trouver la solution en utilisant des machines virtuelles. J'ai testé 35 (!!) versions de navigateurs/systèmes différents (pas que Windows, mais aussi Linux, MacOSX, plusieurs modèles WebTV (testé sur ma télé Philips) et de smartphone (avec des émulateurs en ligne fournis par Nokia par exemple), toutes celles listées ci-dessus, et d'autres encore.
En revanche, pas moyen de trouver de solution portable pour rétablir les pointillés sur IE6 (ils disparaissent pour une raison que je ne m'explique pas encore, mais le reste du rendu est correct et bien présenté), mais ça fonctionne sur IE7, IE8, IE9 y compris dans leur mode de "compatibilité". — Verdy_p (d) 17 septembre 2010 à 14:22 (UTC)Répondre
Bonjour Verdy p,
Je suis contributeur sur les Œuvres complètes de Voltaire, éd. Garnier. Depuis peu, l’attribut 'largeurp' du modèle 'Table' ne fonctionne plus du tout. Par ex., cette page 615 du tome 17 des Œuvres complètes de Voltaire (mais c'est pareil sur toutes les pages où j’ai utilisé cet attribut). Le rendu des 'points de suite' a aussi changé, il me semble moins fin. Il y a quelques jours encore, tout cela marchait très bien. Est-ce réparable ?
Merci par avance de bien vouloir me donner ton avis. Bien cordialement, Yland (d) 17 septembre 2010 à 21:53 (UTC).Répondre
Le paramète largeurp est pourtant bien pris en compte, je l'ai testé sur des tas de pages. Je ne vois pas pourquoi ça ne marche pas sur ta page.
Les points de suite devraient être proportionnés aux tailles de polices (comme aussi le point normal de ponctuation), et grossir aussi avec le zoom du texte.
J'ai essayé différentes combinaisons mais avant on avait d'autres problèmes, donc j'ai laissé leur taille de côté, pour m'intéreser d'abord et en priorité aux positionnement et aux tailles correctes de tous les éléments.
J'ai réglé plusieurs problèmes sur toutes les versions d'IE et récemment sur Firefox2, WebTV, les smartphones, et l'accesibilité WAI (lecteurs d'écrans).
Je vais regarder (j'ai testé plus de 35 navigateurs, sur des systèmes différents Window, Linux, Mac, et systèmes embarqués) pour avoir un rendu correct : il n'y a plus que IE6 qui a un gros problème pour afficher les points de suite (ils sont au mauvais endroit, toujours trop haut, hors du cadre dans lequel ils sont contraints et donc masqués plutôt que d'avoir ceux-ci affichés au mauvais endroit par dessus un autre texte) et il n'y a aucune façon de le faire de façon portable avec les autres navigateurs qui marchent très bien (y compris IE7, IE8 et IE9), je pense que le bogue restera pour IE6 à moins que d'ici là je trouve un palliatif, car IE6 a trop de bogues et est en phase d'obsolescence rapide !). Initialement j'avais mis 0.125em puis testé 0.135em (qui me paraissait idéal avec toutes les polices) mais pendant les tests je les ai mis à 2 pixels avec une couleur de fonc non transparente rouge afin de vérifier le positionnement, j'ai oublié de rétablir la taille, je vais régler ça.
Je vais regarder, mais crois-moi c'est réellement très compliqué d'obtenir des choses portables (et conformes aux normes les plus actuelles avec le moins possible de verrues de compatibilité, l'ancien code de toute façon avait de gros problèmes ! Il tronquait le bas des caractères ce qui était très génant. Maintenant le texte est transparent à si les points de suite sont absents, et n'est blanc ou dans une autre couleur que si les points de suite sont présents (dans ce cas le fond du texte ne peut pas être transparent, et c'est le cas pour lequel il est essentiel que les lignes de texte ne se recouvrent pas partiellement (comme c'était le cas avant).
De plus il n'y a plus de tableau (inaccessible aux lecteurs WAI, à cause de l'ordre de lecture incorrect), et les pages d'index sont aussi lisibles par les robots indexeurs de page (Google Search par exemple qui ignore les tableaux dans de trop nombreux cas (notamment ne présence de certains attributs CSS), alors que ces tables ont un contenu essentiel avec des liens vers les pages à indexer (seuls les points de suite sont positionnés de façon absolue (et donc pas indexés et hors du flot des pages). — Verdy_p (d) 17 septembre 2010 à 22:35 (UTC)Répondre
Correction: Le paramètre largeurp fonctionne, mais ce sont les points de suite qui sont trop longs (il leur manque la marge droite). Ce paramètre est bien pris en compte par le titre qui ne dépasse pas cette marge. Les points de suite sont les derniers éléments que j'ai testés (alros avec un fond transparent pour vérifier où ils étaient positionnés verticalement. Je vais régler ce dernier problème, cette fois c'est facile. — Verdy_p (d) 17 septembre 2010 à 22:39 (UTC)Répondre
Bonjour Verdy p. J'utilise (sur PC) Opera v10.62 ou Firefox 3.6.2 ou Safari-pour-iPhone. Aujourd'hui l'attribut 'largeurp' fonctionne très bien sur ces 3 navigateurs, merci beaucoup pour le rétablissement ! Et bravo pour le travail avec compatibilité multi-navigateurs, je sais que c'est une vraie gageure. Bien cordialement, Yland (d) 18 septembre 2010 à 08:28 (UTC).Répondre
Dernier commentaire : il y a 13 ans9 commentaires2 participants à la discussion
Je viens de regarder le travail fait pour avoir un document à la fois en transclusion et correctement affiché. Je salue la performance mais, si c'est ça qu'il faut faire pour avoir un affichage juxtalinéaire, je renonce. Ce qui m'intéresse, c'est de publier des textes, dans une forme qui ressemble à ce que voulaient l'auteur et l'éditeur, et qui convient au lecteur. S'il faut mettre plus d'instructions techniques que de texte dans une page, je m'égare. Ma solution était quand même plus facile à utiliser, et plus claire pour celui qui veut relire en confrontant au fac-similé; j'accepte ça pour une page de table des matières à qui on donne une fonction d'aiguillage, pas pour une page de texte courant. Je préfèrerais la correction du bug loufoque qui fait que l'espace principal ne fonctionne pas comme l'espace utilisateur où on fait des essais. --Wuyouyuan - discuter19 septembre 2010 à 01:36 (UTC)Répondre
Tu as bien vu que le texte n'étiat pas seulement un texte en breton ou un texte en français mais que c'était un extrait montrant que c'est une traduction, pour laquelle le traducteur voulait absolument montrer l'original en vis à vis : il a bien utilisé une table.
Mais je ne vois pas de quel bogue tu parles ici. La mise en forme je l'ai voulue minimaliste mais c'est le minimum qu'une tavble wiki peut avoir (hormi le fait que j'ai ajouté le balisage des langues, pour la conformité plus stricte du contenu
C'est vrai que les strophes sont alternées entre leur version originale en breton et la traduction en français, mais c'est bien comme cela que ce présente la traduction (la preuve étant sa mise en forme qui introduit des sauts de ligne pour aligner les strophes).
Mettre des <br> ne résoud pas le problème d'affichage sur le web (c'est affreux si les polices sont plus grandes que ce que tu as ou si l'écran n'est pas assez large.
C'est aussi pour ça que j'ai supprimé le balisage des sections pour chaque langue, pour simplifier le code.
Créer une table n'est pas hors de portée. Tu peux très bien contribuer le texte et demander de l'aide pour la mise en forme si tu n'y arrives pas.
Le bogue d'alignement qui avait été signalé n'a pas de solution simple immédiatement (mais valign="top" reste nécessaire ici pour aligner les strophes verticalement, quellques que soient les polices, indépendamment du bogue).
J'ai aussi réduit la police parce que c'était aussi le cas dans l'original pour faire tenir les deux colonnes. C'est conforme à l'original.
note que le tableau wiki se prolonge s'une page à l'autre (pour éviter que l'entête soit inclus deux fois, le bas de tableau en fin de page 1 est hors de la section transclue, de même que le haut du tableau en haut de la page 2 : cela n'ajoute pas plus de code car la délimitation des sections à transclure reste nécessaire).
Note que j'ai aussi corrigé le texte latin en haut de la page 1.
Ne renonce pas trop vite : le site est collaboratif, fais ce que tu peux au mieux, d'autres passeront pour finir, ton travail était utile de toute façon, et révèle un problème pour lequel on devrait chercher une meilleure solution, mais en attendant je ne vois pas comment faire mieux : les tables (en wiki comme en HTML) ont toujours été compliquées, mais on peut chercher des outils pour aider à leur création. — Verdy_p (d) 19 septembre 2010 à 01:50 (UTC)Répondre
Certes, sauf que je peux compter sur les autres pour deux pages, pas pour 300. Mais j'oubliais: à part le plaisir de publier un petit texte qui fait partie de l'histoire de la littérature celtique, je faisais un essai en vue d'une future publication de livres où le breton et le français sont sur des pages différentes (la page paire à gauche en breton, la page impaire qui suit à droite en français). Je supposais que la transclusion inter-wiki fonctionne, ce qui sera peut-être vrai un jour. Dans un lointain passé, j'avais copié la solution de quelqu'un (je ne sais plus qui) pour un livre en latin et français, Satires (Horace, Raoul). L'affichage en parallèle qui fonctionnait encore correctement en juin est actuellement broyé par des modifications récentes quelque part. --Wuyouyuan - discuter19 septembre 2010 à 01:57 (UTC)Répondre
Pour des pages dans des langues séparées, aucun problème spécial ni complication : édite les pages dans l'ordre où elles sont dans le livre. C'est en transcluant les pages qu'on peut modifier l'ordre. Ceci-dit, on peut vouloir aussi présenter les pages en vis-à-vis aussi dans le texte complet (mais alors comment gérer les sauts d'une page à l'autre ? Ces pages ne sont pas forcément complètement alignées, hormis peut-être aux frontières de chapitres où il y a un saut de page forcé des deux côtés.
Ce n'est pas simple car le français a tendance a être plus long que le breton. comment gérer le vis-à-vis pour le mode texte intégral du livre ? A mon avis il sera plus simple dans ce cas de présenter deux textes successifs, en transcluant ensemble les pages paires, puis les pages impaires (ou l'inverse)... — Verdy_p (d) 19 septembre 2010 à 02:05 (UTC)Répondre
La transclusion dans des colonnes défilantes (que ce soit des div ou des iframes; peut importe) est une très mauvaise idée pour l'espace principal : pas moyen d'imprimer ça. On doit trouver une mise en forme ne nécessitant pas le défilement, ou sinon présenter les deux textes successivement ou dans des pages séparées. Voire peut-être créer un affichage en double page en vis-à-vis dans un autre espace que l'espace principal (qui ne contiendra que les textes dans chaque langue). Je pense que ce serait l'idéal dans ce cas (et la mise en forme en une seule colonne serait remplacée par une autre permettant d'inclure les deux pages. Note que le texte défilant n'est PAS compatible avec les numéros de page (dans aucune maquette) : il faudrait que les numéros de page défilent aussi avec le texte transclu, et fasse donc partie de la colonne défilante.
Ce serait pas mal d'ailleurs d'avoir un espace permettant d'afficher deux textes en comparaison (y compris d'un autre wiki) en fournissant simplement les liens wikis vers les textes à comparer (éventuellement plus de deux : une liste dont le deux premiers éléments seraient affichés par défaut, et un menu dynamique permettant de choisir d'autres versions, et des options comme l'affichage soit d'une seule version, soit côte-à-cote, soit l-un sous l'autre), dans cette page créée spécialement dans un espace comme "Comparaison:". Une idée à creuser... — Verdy_p (d) 19 septembre 2010 à 02:12 (UTC)Répondre
J'ai vraiment du mal à faire comprendre mon besoin, le mot juxtalinéaire étant de l'étranger. Pour illustrer, je cherche à avoir sur Wikisource un équivalent (selon le génie propre au site) de ce qu'on peut voir dans l'édition de 1846 du Barzaz Breiz, à comparer avec les mêmes pages de l'édition de 1867. Le problème de l'alignement du vis-à-vis des textes est presque toujours déjà résolu dans les éditions bilingues, au moins au niveau de la page. IRL, l'édition du Barzaz Breiz de 1867 (non juxtalinéaire mais cohérente par page) a été rééditée récemment sur papier en juxtalinéaire, sans changement du contenu. (A part ça, l'instabilité dans le fonctionnement de l'affichage me parait difficile à accepter.) --Wuyouyuan - discuter19 septembre 2010 à 04:17 (UTC)Répondre
J'avais parfaitement compris ton besoin. Je comprend aussi qu'ffectivement on peut résoudre assez facilement la synchronisation verticale au niveau des pages, tant qu'elles ne sont pas trop longues (ce qui n'est pas le cas des articles de Wikipédia par exemple qui nécessitent une telle synchro, mais aussi des textes qui initialement n'ont pas (dans leurs éditions respectives) été synchronisés au niveau de la page (mais qu'on peut tout de même synchroniser avec un balisage explicite des points de synchronisation).
Je connais le problème (et Google le fait déjà sur son Kit Google Translate pour aider à la traduction des articles Wikipédia ou d'autres documents en ligne...)
De plus, le besoin de synchronisation peut s'étendre à plus de 2 versions (je travaille par exemple sur une traduction française du Coran, qu'il serait bon de pouvoir synchroniser avec une version arabe affichable en vis à vis, ou avec d'autres traductions pour les comparer, les points de synchronisations étant les chapitres/sourates, et les numéros de versets moyennant certains ajustements car certaines traductions ne comptent pas les versets de la même façon).
Je propose un système dans le scriptorium qui pourrait aider à faire ça, y compris avec n'importe quelle autre version, le but étant alors de composer simplement les pages dans une version, et ensuite de les assembler uniquement dans le rendu final, soit en juxtaposition (avec défilement synchronisé par script et aidé par le balisage éventuel des points de synchro verticale), soit l'un sous l'autre (dans la limite de la hauteur d'écran, avec également défilement synchronisé par script), soit simplement par transclusion simple des textes (sans synchro ni défilement dans des cadres parallèles, ni besoin de javascript) présentés dans la même page les uns sous les autres (comparaison difficile à l'écran, mais possible une fois imprimé).
Mais l'affichage côte à côte ne doit pas être la seule option, surtout si il nécessite des défilements (car le document ne sera pas accessible. Ce mode doit rester réservé à la demande expresse de l'utilisateur de comparer les textes (qui d'ailleurs peuvent être plus nombreux que seulement deux et peuvent comprendre des parties absentes dans une version mais présentes dans une autre, selon le découpage des pages référencées...)
Je pense que c'est possible d'expérimenter cela. Mais l'ancien système avec transclusion côte à côte ne peut pas marcher, et ne doit pas être le seul mode accessible pour le texte complet, et en tout cas pas le mode par défaut, sauf si les textes sont juctaposés dans l'ouvrage original comme c'était le cas dans ton exemple où la traduction française proposée n'a pas de sens toute seule sans le texte breton juxtaposé et synchronisé dans l'ouvrage original : pour ça on a le tableau (voulu par le traducteur pour présenter la version française, alors que le texte breton reste possible présenté isolément (et a sa place dans le Wikisource bretonnant à moins qu'il choisisse aussi de présenter une traduction française, à condition de pouvoir la choisir car une traduction n'est pas le travail de l'auteur original...). — Verdy_p (d) 19 septembre 2010 à 04:50 (UTC)Répondre
Dans l'exemple que tu cites, c'est simple: crée un livre sur le wikisource breton pour les pages paires, un autre livre sur le wikisource français pour les pages impaires du même document (chargé en .djvu ou PDF sur Commons et contenant toutes les pages).
Utilise le mode page de la façon normale sur chaque wiki. Ensuite propose pour l'instant l'affichage du texte complet en français ou du texte complet en breton (l'affichage en vis-à-vis des deux livres demandera un travail spécifique), et inclue les interwikis entre les deux versions. On verra plus tard comment afficher en juxtaposition les deux textes... Si travailler sur deux Wikisources te semble délicat, crée les deux livres séparés sur l'un ou l'autre des wikis (pour éviter la duplication inclue une page de référence sur l'autre wiki, ou utilise la transclusion interwiki sur l'autre wiki). — Verdy_p (d) 19 septembre 2010 à 04:57 (UTC)Répondre
Dans le second exemple, où les traductions sont sur la même page (l'une sous l'autre), on peut créer aussi deux livres, mais le mode page devra effectivement découper explicitement les sections en français et celles en breton, afin de pouvoir réassembler le texte complet en français ou celui en breton.
Mais dans le cas d'un texte isolé extrait d'un livre qui n'a pas cette disposition logique, si on se base sur la source, les deux textes doivent rester toujours sur la même page si on présente la traduction française (dont on ne sait pas de qui elle vient et est liée seulement à l'ouvrage en français, latin, breton, et d'autres langues peut-être où cette traduction fragmentaire a été proposée et où le texte français tout seul n'a pas de sens). — Verdy_p (d) 19 septembre 2010 à 05:04 (UTC)Répondre
Pour le mode page cela facilite les comparaisons, comme je compose le texte, c'est plus facile à lire comme ça. Pour le mode texte intégral j'oterais cete agrandissement plus tard... — Verdy_p (d) 21 septembre 2010 à 15:56 (UTC)Répondre
Tu n’es pas le seul à utiliser ce wiki, et d’autres que toi peuvent ne pas partager tes préférences. Il est préférable que tous les textes soient présentés dans la même taille, afin que chaque utilisateur puisse choisir la taille qui lui convient dans les réglages de son navigateur (control +/- sous Firefox),
Ctrl +/- sous aucun navigateur ne permet de régler la taille des caractères. C'est un zoom qui agrandit toute la page (et active souvent le défilement horizontal. Tu confonds avec l'option d'agrandissement du texte qui n'agit que sur les tailles de polices et tailles indiquées en em ou en en mais pas celles indiquées en pixels ou pourcentages. De fait, le zoom respecte la mise en page (et s'avère ne fait moins pratique pour l'utilisateur à cause de son effet sur le défilement horizontal), mais pas nécessairement l'agrandissement de texte qui justement permet de garder la mise en page (si on fait attention en composant les pages pour éviter les effets de bords de certaines tailles indiquées incorrectement en pixels). — Verdy_p (d) 21 septembre 2010 à 16:51 (UTC)Répondre
sans devoir modifier ce réglage à chaque fois qu’il visite un texte formaté par toi.
si tu ne veux agrandir le texte qu’en mode page, je te suggère de modifier les attributs de .pagetext dans tes préférences.
OK, ok, ok... mais Mediawiki affiche le texte par défaut beaucoup trop petit, et c'est très génant pour les corrections ! En plus en mode page il est agréable d'avori des lignes qui correspondent à peu près à la présentation numérisée en vis-à-vis : c'est bien plus facile de comparer et repérer les différences. Le mode page servant à la relecture et aux corrections, cela ne gêne pas les autres qui pour la plupart n'iront pas voir dedans et de toute façon ne verrons pas en quoi c'est gênant à cet endroit alors que cela aide considérablement le travail du relecteur ou correcteur. (moi en l'occurence puisque personne d'autre pour l'instant ne travaille sur le texte qui a été laissé en plan en 2006 et alors pas en mode page, et avec des fautes non corrigées ou non sourcées). — Verdy_p (d) 21 septembre 2010 à 16:46 (UTC)Répondre
Le fait que tu arrives à afficher le texte à la même taille que sur le scan ne garantit absolument pas que cette égalité a aussi lieu pour les autres utilisateurs; la taille du scan qui est affiché dépend de la largeur de ton écran.
Est-ce que ton navigateur ne te permet pas d’agrandir le texte ?
Si si, mais le zoom a un défaut énorme : il active le défilement horizontal qui est encore plus gênant ! Bref je n'utilise que l'agrandissement par défaut, qui est le seul cohérent d'un navigateur à l'autre (et j'en ai maintenant 35 versions installées à disposition pour tester tout ça...) — Verdy_p (d) 21 septembre 2010 à 16:52 (UTC)Répondre
pas si tu choisis le niveau de zoom d’abord, et charges la page après. (en général on choisit un niveau de zoom et on y reste. Toute page chargée une fois le niveau de zoom choisi est affichée sans scrolling horizontal.) ThomasV (d) 21 septembre 2010 à 16:57 (UTC)Répondre
M'emmerde pas avec ça (désolé de te le dire, mais je ne vois pas qui ça gêne d'autre : que voulais-tu faire ?). Je suis celui qui travaille sur ce texte (personne n'a rien fait d'autre dans les pages dans le suivi), je ne gêne pas les autres pendant leur travail. La mise en forme finale peut attendre, et pendant le travail on peut faire des ajustements pour voir ce qu'on veut voir... — Verdy_p (d) 21 septembre 2010 à 17:00 (UTC)Répondre
Quand je prends la peine de t’expliquer que la taille de l’image est adaptée à la fenêtre de ton navigateur, ce n’est pas dans le but de récolter des insultes. Merci de changer de vocabulaire. ThomasV (d) 21 septembre 2010 à 17:22 (UTC)Répondre
Quelle insulte ? Le terme que j'ai mis ne s'adresse qu'à moi...
Et je ne parle pas seulement de la taille de l'image mais bien de la longueur des lignes (le nombre de mots moyen par ligne est respecté sur la taille d'écran nécessaire pour ne pas afficher l'image en taille ridicule ne permettant pas le travail : on ne travaille pas sur le mode page avec un smartphone...). Le mode page c'est pour celui qui saisit le texte et fait le gros du travail de correction. Les autres vont sur le texte complet. Je fais ce que je ceux sur le mode page tant que je travaille dessus.
Tu as fait quelque chose sur ce texte ? Tu as envie de contribuer ? Personne ne s'est manifesté pour ça mais si ton but est de seulement gêner un contributeur, je ne vois pas l'utilité de ton intervention. — Verdy_p (d) 21 septembre 2010 à 17:26 (UTC)Répondre
C'était un peu par hasard que je suis tombé sur ta page. Je me demande si le fait que le lien ne bouge pas quand on défile est volontaire, après la correction, j'ai rétabli la fonction, mais si ce n'est pas le cas, enlève seulement "position:fixed;top:50%;left:3em" et ce sera alors un flottant en tête de page... — Verdy_p (d) 14 octobre 2010 à 13:23 (UTC)Répondre
Dernier commentaire : il y a 13 ans2 commentaires2 participants à la discussion
Je viens de regarder le Coran de Savary. Il s'affiche dans un autre caractère que la banalité de Wikisource. J'ai cherché le nom de la fonte, et donc l'endroit où on l'indique. Je n'ai pas trouvé (et pas trouvé non plus dans les aides). J'ai cherché aussi dans traité des échets. Quel est le truc ? --Wuyouyuan - discuter6 novembre 2010 à 04:23 (UTC)Répondre
Parmi les polices avec empattements de qualité, j'ai mis "font-family:Constantia,Georgia,Candara,'Heofler Text',Junicode,'FF Scala',serif"
La police Constantia est une des nouvelles polices fournies avec Windows 7, elle est très bien adaptée aux textes anciens et d'une grande lisibilité, les autres sont extraites de listes de polices sélectionnées par des infographistes, pour compatibilité avec Mac OSX, ou Linux. Certaines sont plus spécialisées mais plus rares, enfin "serif" est indiquée en dernier pour sélectionner la police à empattement par défaut du navigateur.
Le style est codé dans Le Coran (Traduction de Savary)/En-tête qui est inclus au début de toutes les pages (je ne l'ai pas mis dans l'espace modèle car cet entête ne concerne qu'une seule œuvre, et contient plein d'instructions liées à la pagination et au chapitrage des deux volumes). Toutes les pages, tous les chapitres et les sommaires et sous-modèles spécifiques sont dans une catégorie propre à l'œuvre complète.
Je n'ai pas fini la couche texte des deux tomes, mais les entêtes de chapitres et la première et dernière page de chacun est présente, et tous les chapitres de 3 pages sont faits (principalement en fin de volume 2). Je fais les chapitres par ordre de taille (en nombre de pages), au fur et à mesure...
Il y a encore des petites détails que je règle mais avec une structure commune cela mâche le travail pour le gros de l’oeuvre qui a près de 1000 pages.
Le traité sur les échets a été mon premier essai de ces polices (je cherchais des polices assez complètes pour correctement afficher les ligatures).
Note: la taille de police est adaptée pour l'instant au travail sur le texte à numériser, et est donc plus grande dans le mode page. Cela pour faciliter les comparaisons. Mais comme je ne suis que le seul à travailler dessus, cela ne devrait pas être gênant. Il y a encore bien du travail à faire (car l'OCR ne marche pas du tout, et je ne suis pas convaincu de son utilité étant donné la quantité enorme d'erreurs qu'il fait, et qui en fait rend le travail encore plus long et plus pénible à corriger...) — Verdy_p (d) 10 novembre 2010 à 03:00 (UTC)Répondre
Dernier commentaire : il y a 13 ans8 commentaires2 participants à la discussion
Bonjour
Coïncidences significatives ? Le sujet précédent parle du même ouvrage. J'ai eu l'idée de participer à l'ouvrage. J'ai chez moi un texte à peu près correct de la même édition de 1821, et je pourrais le poser dans les pages à créer. Mais quelque chose me fait hésiter pour l'instant: les numéros de versets ne figurent pas dans mon exemplaire, et pas non plus dans celui qui est en ligne ici. Ils viennent donc d'ailleurs. Est-ce Le Koran (Traduction de Kazimirski) ? D'après une comparaison rapide, c'est la même. --Nyapa (d) 24 novembre 2010 à 06:02 (UTC)Répondre
Non, rien à voir avec la version de Kazimirski (d'ailleurs la traduction en est très différente). Il s'agit des nombres et numéros tirés de la version imprimée (celle éditée en 1821 utilise l'orthographe post-révolutionnaire, la première édition est identique à l'orthographe près, mais utilise exactement la même numérotation). Donc aucune coïncidence, et aucun doublon non plus (dans ta « comparaison rapide » tu as très mal regardé).
Si ton édition affiche d'autres numéros, c'est une révision qui n'a rien à voir avec l'édition de 1821 (ni celle de 1782-1783 avec l'orthographe prérévolutionnaire). Note que même si l'orthographe est modernisée, elle est surtout stabilisée en 1821, là où elle ne l'était pas encore en 1782-1783, et régularise la conjugaison et met fin aux anciennes ligatures très variables d'un éditeur à l'autre (et alors d'ailleurs au seul bon vouloir des imprimeurs qui ne le faisait que selon leur décision et selon les compétences du typiste composant les cadres de page, sans tenir compte très souvent de la volonté des auteurs, mais uniquement pour gagner de la place sur le papier bien souvent, puisque le papier a longtemps été cher, et les imprimeurs s'arrangeaient systématiquement pour n'avoir à imprimer que le minimum de pages, même si les auteurs payaient leur service pour faire imprimer leurs manuscrits ; durant l'empire, cette pratique des imprimeurs a été bannie, les imprimeurs devant respecter les consignes données par leurs commanditaires et adopter une graphie uniforme, stable et non ambiguë, et reproduire les mots in extenso : on a vu apparaitre ainsi durant l'Empire le bon à tirer qui permet au commanditaire de demander des rectifications sans être obligé d'accepter et payer l'ouvrage imprimé en l'état, et devant aussi donner un coût à la page conforme et respecté dans le prix demandé, qui dès lors n'était payé qu'à la recette de l'ouvrage et non à la commande comme cela se faisait avant et permettait aux imprimeurs de faire ce qu'ils veulent).
Voir le mode page pour les aperçus des fac-similés (tirés d'ouvrages effectivement imprimés à cette époque, l'imprimeur étant cité, et la date certifiée, conservés dans des bibliothèques nationales les plus réputées) où le texte indique explicitement le nombre de versets. Cette numérotation est totalement identique entre toutes les éditions correctes du texte de Savary qu'on peut trouver sur Internet (c'est pour ça que la date de l'éditon et l'éditeur sont précisés explicitement). J'ai d'ailleur vérifié dans un scan de la version manuscrite (de 1764, celle citée par le docteur égyptien qui l'a eu en main et dont la lettre d'approbation est reproduite à la fin de la préface, lequel manuscrit n'est paru sous forme imprimée qu'en 1782-1783 quand Savary a demandé à un imprimeur d'en tirer quelques dizaines d'exemplaires destinés au roi et quelques décideurs politiques et gens de lettre de l'époque).
Je n'ai donc strictement rien changé ni copié de la version de Kazimirski ! Je ne me base que sur le facsimilé pour le reproduire exactement tel qu'il est (et tu peux le vérifier toi-même en regardant mieux).
Sache qu'il n'y a pas universalité des numéros de versets, selon les traditions. Le texte de Savary s'appuyait sur la tradition égyptienne (au Caire, où a longtemps vécu Savary qui y a écrit divers autres ouvrages sur la société égyptienne et les traditions arabo-musulmanes). Par la suite il a publié une version très « abrégée » du Coran (une fois revenu en France) pour en expurger tout ce qui était contraire à la morale chrétienne et dénoncer le texte qu'il avait pourtant fait approuver par des docteurs musulmans dans son manuscrit initial, et en dénaturer le texte volontairement (cette version abrégée ne reprend plus du tout la versification, mais contient des « résumés » de chaque sourate complètement réinterprétée par lui seul (et faisant l'impasse de l'essentiel du texte puisque cet ouvrage tombe à 80 pages environ en un seul volume contre plus de 600 dans sa première œuvre en deux volumes).
La numérotation des versets a bougé et n'a été uniformisée dans les traductions modernes que très récemment vers les années 1980 (après des décisions de la ligue islamique mondiale), en cherchant les copies les plus anciennes (même si le texte en arabe n'a pas changé), cette numérotation moderne ne touchant que le texte en langue arabe tel qu'il est lu actuellement...
Oui il y a des différences avec la numérotation approuvée actuellement, mais cette numérotation n'était pas connue au temps de Savary.
Donc merci de ne pas toucher à la numérotation, elle est calée strictement sur le texte original.
Ton texte n'est certainement pas l'édition de 1821 (tu parles d'un « à peu près » qui n'est pas de mise ici, il s'agit d'une édition modernisée et modifiée, certainement non libre de droit), regarde mieux ton livre, qui doit d'ailleurs même ne pas être le texte de Savary !
D'ailleurs, il n'y a qu'un seule exemplaire complet connu dans le monde de la première édition de 1782-1783 (à la bibliothèque du Congrès de Washington), et seulement 3 ou 4 de la seconde édition de 1821 (hors collections privées non référencées). La BnF n'a aucun exemplaire de l'une et de l'autre, on trouve l'ouvrage de 1821 à la Bibliothèque duccale de Monaco, dans une bibliothèque universitaire aux Etats-Unis et une autre aux Pays-Bas. Ici c'est l'exemplaire conservé à Monaco (scanné et mis en ligne par Google books), et j'ai cru lire qu'il y en avait un dans une bibliothèque royale au Royaume-Uni et peut-être en Suède (copies non disponibles en ligne). Ces éditions sont aujourd'hui des livres dits « rares » et précieux. Bizarrement je n'en ai pas trouvé dans l'inventaire de l'Université francophone du Caire.
Il n'est pas impossible que des exemplaires soient à la bibliothèque Méjeanne d'Aix-en-Provence, vu la dizaine de milliers de références sur le seul Coran détenu là-bas (c'est le apparemment plus important corpus du monde sur les traductions du Coran, puisque sur les livres anciens avant 1900, on compte en gros 25 000 références dans le monde entier toutes traductions confondues, la plupart des bibliothèques n'ayant qu'une dizaine de références, parfois guère plus de 200). Mais si on peut consulter en ligne leur index de références, les ouvrages eux-mêmes ne sont pas en ligne (il faudrait leur écrire ou se rendre sur place). On peut s'étonner que cette bibliothèque n'ait pas encore bénéficié de subventions ou donations pour les aider à numériser son corpus et le mettre en ligne (question à poser au Ministère de la Culture...). — Verdy_p (d) 24 novembre 2010 à 06:45 (UTC)Répondre
Quelque chose m'échappe. Quand je regarde la page à droite 2e page du chapitre 2, je ne vois pas de numéros de versets imprimés. Même chose ici, des numéros à gauche, pas à droite. Avec ta permission, je vais garnir les pages 101 à 110 (283 à 292) du premier tome avec mon texte. Si c'est mauvais, le dégat ne sera pas grand. Je ne fais rien avant d'avor une réponse. --Nyapa (d) 25 novembre 2010 à 02:13 (UTC)Répondre
Les numéros de versets sont activables/désactivables dans les options de présentation de la boîte à outils. Ils sont systématiquement au début de chaque verset, lui-même toujours au début du paragraphe. S'ils sont visibles, ils apparaissent en exposants et en couleur verte. Ils sont introduits par un appel de modèle (regarde les pages déjà en jaune, la syntaxe est {{verset|chapitre=5|verset=11}}). Effectivement ces numéros ne sont pas dans cette édition, mais figurent dans d'autres pour le même texte. Ces numéros sont là pour référence et sont d'une usage très commun (et sont toujours présents dans les éditions en arabe. Il est donc préférable de les indiquer. On les différencie très bien du texte par leur présentation mais l'utilisateur peut aussi choisir de ne pas les afficher grace au modèle utilisé.
Comme je travaille depuis la fin de l'ouvrage (puisque j'ai fait pour l'instant d'abord les chapitres les plus courts), aucun problème de collision avec les pages du chapitre 1: j'ai créé déjà toutes les pages de début de chapitre avec les titres, il ne manque "que" les autres pages.
Attention : utilise le mode page ! Mais fais attention à ce que les paragraphes s'enchaînent correctement en visualisant le chapitre qui inclue les pages (toutes les pages de chapitres sont déjà créées : il suffit de cliquer "Suivi des pages liées" pour trouver la page de chapitre correspondante incluant la page que tu viens de modifier et visualiser). Utilise aussi les modèles {{tiret|début-de-mot|fin-de-mot}} pour introduire en bas d'une page une césure, et {{tiret2|début-de-mot|fin-de-mot}} au début du paragraphe de la page suivante.
De plus, pour les notes de bas de page, on ne peut les placer pour l'instant que dans des balises "<ref>...</ref>" : ne met pas de numéro, juste le texte de la note dans ces balises, le tout à l'endroit de l'appel de la note. Le numéro dépendra du mode de visualisation : en mode page, les notes sont numérotées à partir de 1 sur chaque page, mais dans le texte d'un chapitre complet, tous ces numéros sont changés et la totalité des notes d'un même chapitre sera visible en fin de chapitre. Ces notes sont affichées sous le filet horizontal noir de fin de page. Pour l'instant on n'a pas moyen d'en changer la présentation. Attention aussi, certaines notes commencent en bas d'une page et se prolonge en bas de la page suivante : on ne peut actuellement que placer la totalité de la note dans la première page, il n'y a pas moyen pour l'instant de fusionner plusieurs parties d'une même note éditée sur des pages différentes. En aucun cas ces notes ne peuvent rester dans le texte comme sur le mode page (sinon le mode chapitre les disséminera en plein milieu du texte, sans en différencier la présentation (et sans prendre en compte les césures correctes).
Le premier lien que tu me donnes en exemple est une page pas encore créée (il n'y a pas de texte dessus), c'est normal que tu n'y voies rien (le statut de cette page dans l'index est d'ailleurs en rouge, et non en jaune pour les pages complètes ou vert pour les pages relues par quelqu'un d'autre).
Tu noteras que si j'ai choisi l'édition de 1821, c'est parce que c'est la seconde jamais parue pour cette traduction et que la première a été très peu diffusée. La seule différence étant la normalisation moderne de l'orthographe (à quelques exceptions près qui ont été conservées dans toutes les très nombreuses éditions ultérieures chez divers éditeurs). Cette édition a été faite par les ayant-droits de l'auteur et donc respectait le texte original sans en changer un seul terme, mais a régularisé les accents. Elle a aussi ôté les anciennes ligatures d'origine médiévale, bannies sous l'Empire puisque la plupart n'étaient jamais de la volonté des auteurs mais uniquement à la discrétion des imprimeurs qui faisaient ce qu'ils voulaient pour réduire le nombre de page, des abréviations et ligatures d'ailleurs souvent inconsistantes d'une page à l'autre ou sur la même page de nombreux ouvrages). De fait, cette édition est restée parfaitement lisible pour un lecteur actuel même si on note quelques particularités orthographiques.
Si j'ai choisi cette édition et non celle de 1782-1783, c'est qu'elle est bien plus lisible et plus facile à corriger (les facsimilés de 1782-1783 sont souvent difficiles à interpréter car dans une impression à l'origine de mauvaise qualité pleine de tâches d'encre avec des caractères mal dessinés, et la résolution est parfois trop faible pour décider, notamment quels accents étaient présents). Et c'est sur celle-ci que se sont basées visiblement toutes les nombreuses rééditions ultérieures (partielles ou totales).
Fais attention à l'orthographe : il ne faut pas la moderniser davantage, les différentes éditions sont d'accord là-dessus. (Donc on laisse écrit « les enfans » ou « les croyans » sans le t muet au pluriel : ce n'est pas une faute, ni une coquille c'est conforme à l'orthographe de l'époque et c'est consistant partout dans l'ouvrage).
De même la typographie utilise encore une capitale pour le premier mot de la phrase après un deux-points (contrairement à ce qu'on utilise aujourd'hui): j'ai choisi de laisser ces règles en place sans y toucher.
Cependant on trouve par endroit des coquilles dans cette édition (absentes d'autres éditions), il n'est pas inutile de regarder alors dans les autres éditions qu'on trouve sur Google Books en cas de doute (et on peut éventuellement vérifier dans l'édition de 1782-1783 pour voir quelle était la volonté de l'auteur), et si une coquille est présente il faut signaler cette correction (je l'ai fait pour 2 pages actuellement, regarde les pages de discussion de la page "Livre:" de chaque tome qui contient les liens vers ces pages, les corrections étant elles-mêmes insérées par un modèle inséré dans la page de discussion du mode page pour la page concernée). — Verdy_p (d) 1 décembre 2010 à 05:27 (UTC)Répondre
Si tu as des problèmes avec certains formatages demande-moi, je pourrai t'aider. Sinon aucun problème pour ce que tu a commencé à créer en couche texte (je vais juste remettre en forme les notes de bas de page pour qu'elles s'insèrent bien dans la page du chapitre correspondant, et mettre les modèles de numérotation de versets).
Note : dans 2 chapitres pour l'instant (sur la soixantaine que j'ai finis) j'ai trouvé que le nombre de versets indiqués dans l'entête de chapitre ne correspond pas au nombre de versets comptés effectivement dans les fac-similés (il est probable que deux versets ont été parfois fusionnés en un seul paragraphe mais impossible de dire où pour l'instant, même en consultant l'édition de 1782-1783 ; il faudrait un examen scrupuleux ligne par ligne en comparaison avec d'autres traductions « conformes », ou en arabe que je ne peux pas lire, pour corriger ça, à condition que ces traductions s'appuient sur la tradition égyptienne de l'époque pour retrouver le nombre de versets indiqués par l'auteur). — Verdy_p (d) 1 décembre 2010 à 06:23 (UTC)Répondre
Au fait, j'oubliais de te dire merci : le travail le plus long est de produire la couche texte corrigée, et non la mise en forme qui demande moins d'attention. Donc si même tu continues comme ça, ce sera très bien. Je vois que tu as compris l'utilisation des modèles d'en-tête et pieds de page (ils gèrent tout seuls la numérotation et les titres de pages) pour le mode page, ainsi que le placement des notes de bas de page (à condition d'utiliser le balisage wiki avec "ref", à défaut de pouvoir utiliser autre chose pour leur mise en forme). — Verdy_p (d) 1 décembre 2010 à 06:28 (UTC)Répondre
Je ne suis pas sûr d'avoir tout compris au sujet des versets. Je viens de faire un test plus étendu, en collant mon texte dans les pages 30 à 50 du tome 1 avec l'automatisme split. J'ai essayé aussi de mettre les notes dans les pages 49 et 50, sans effacer le texte original des notes. Pour l'instant, je crois que je vais me limiter à mettre le texte dans les pages, et faire les corrections, italiques etc., sans m'occuper de mise en forme ni de transport des notes à leur place (je crois qu'il vaut mieux traiter les notes après. quand une note se prolonge sur deux pages, on se perd). --Nyapa (d) 1 décembre 2010 à 06:49 (UTC)Répondre
C'est pas grave, fais ce que tu sais faire le mieux ou préfères faire, je ferai le reste (moi ou un autre). L'important c'est d'avancer sur ce texte. Je fais le tout en même temps (texte, corrections, recherches des typographies à problème, mise en forme) mais si tu préfères pour l'instant ne t'occuper que de l'importation de la couche texte, c'est bon et conforme à l'état actuel des livres qui indique "ajouter une couche texte". Continues donc comme ça, je repasserai pour mettre les modèles d'entête et peids de page et numéros de versets.
Note : laisse l'état de la page en rouge, afin de pouvoir suivre où on en est (je ne passe une page en jaune que quand elle est complète et prête à être importée dans le chapitre). — Verdy_p (d) 1 décembre 2010 à 06:55 (UTC)Répondre
Dernier commentaire : il y a 13 ans10 commentaires2 participants à la discussion
Bonsoir,
Il ne faut pas modifier l’apparence d'un modèle aussi utilisé que celui de la boîte de titre.
Par ailleurs, sur le scriptorium, Thomas a soulevé le problème de la police utilisée pour le Coran.Marc (d) 4 décembre 2010 à 21:08 (UTC)Répondre
Il faudrait d'abord que vous vous mettiez d'accord notammenet avec les changements faits par ThomasV justement dans ce qu'il impose maintenant dans les pages... — Verdy_p (d) 5 décembre 2010 à 02:41 (UTC)Répondre
Quel problème ? Franchement il n'y en a aucun (et ce n'est pas pire que ce qu'impose déjà Wikisource dans ses feuilles de style, plus les feuilles par défaut de MediaWiki (qui utilise des polices réduites illisibles que ce soit sur un PC ou sur un smartphone).
Et attention aux contradictions et incompatibilités que Thomas veut imposer aux pages, car justement son Javascript qui a de nombreux bogues (et pas qu'ici mais sur toutes les éditions de Wikisource pour l'intégration du mode page et des layouts, qui ne marche pas encore comme il le voudrait, et qui pourtant nous impose déjà des changements dans des pages, et prétend que cela corrige les problèmes (mais en en ajoutant d'autres) ?
L'argument ne tient pas pour l'instant, il y a trop de choses à corriger en amont. Car justement ces polices ne sont pas imposées, mais si elles sont utilisées elles sont d'une grande qualité graphique et d'une parfaite lisibilité aussi bien à l'écran qu'imprimées, et sont nettement plus proches de ce qu'on trouve dans les livres et notamment celui-là. — Verdy_p (d) 5 décembre 2010 à 02:41 (UTC)Répondre
Tu n’as pas à changer l’apparence des boîtes de titre et c’est tout. S’il y a un problème, tu en parles d’abord sur le scriptorium.
Pas d'accord pour le Coran (d'ailleurs Thomas que tu cites n'a rien dit de tel), je suis le seul à tout faire dedans (sauf un robot qui produit un peu de couche texte de temps en temps, sur lequel reste à faire tout le travail de correction que je fais avec patience), donc je ne « change » rien du tout et je respecte le livre au maximum. Ton message ne sert à rien de productif c'est juste une critique qui ne concerne que toi selon tes préférences, et j'ai le droit d'avoir aussi les miennes pour travailler de façon agréable (merci surtout pour mes yeux !) sans gêner personne ici.
D'aileurs si tu regardes plus haut tu verras que d'autres ont trouvé cet aspect particulièrement agréable.
Le but ici c'est de produire les textes avant tout, c'est ce que je fais. Et ensuite en assurer la promotion par leur référencement dans les moteurs de recherche afin de donner le texte à lire au plus grand nombre même sans avoir à l'acheter, et aussi pour servir de référence. Il n'y a rien que je fasse qui soit contre cet objectif.
De plus, s'agissant de textes anciens et respectable, utiliser des polices très bas de gamme systématiquement n'est pas rendre servir aux textes. On peut aussi vouloir les rendre agréables à lire même en ligne. Quel dédain vous faites de la typographie soignée, je me demande bien pourquoi. Alors qu'une bonen typographie a toujours été voulue par les auteurs et les lecteurs. — Verdy_p (d) 5 décembre 2010 à 13:49 (UTC)Répondre
Merci je connais, et j'y ai déjà écrit. D'ailleurs personne n'aurais remarqué que je travaillais sur ce texte si je n'avais pas écrit là-bas. OK tu n'aimes pas la police mais ça fait un seul avis contre plusieurs dizaines d'autres qui n'ont rien trouvé à y redire ou qui ont aimé. Laisse moi-donc travailler en paix sur ce texte, je ne dérange personne, et personne ne m'aide. Alors, en attendant je ferai ce qu'il faut pour me rendre ma tâche (la plus ingrate et la plus longue et délicate) agréable et m'éviter trop d'oublis et d'erreurs, et sans me causer trop de fatigue occulaire pour relever tous les plus petits détails comme un accent ou une ponctuation oubliée)... — Verdy_p (d) 5 décembre 2010 à 15:24 (UTC)Répondre
Il y a un malentendu. Je n’ai jamais dit que je n’aimais pas cette police. Je t’indique qu’une discussion a été ouverte sur ce sujet dans le scriptorium parce que visiblement cela te concerne. Et je ne vois d’intervention de ta part dans la section [2]. Marc (d) 5 décembre 2010 à 15:36 (UTC)Répondre
Il s'agit d'une réouverture de discussion (il faut revenir aux mois passés, j'en en parlé encore en novembre). Je ne vois pas pourquoi quelqu'un se plaint maintenant. Je n'ai pas fait ça sans rien dire à personne (et même Thomas était au courant depuis longtemps puisqu'il a répondu déjà à plusieurs messages concernant ce texte dans les mois passés). Je pense que derrière ce brusque changement d'attitude (sans même m'avoir prévenu au passage), il y a une part de mauvaise foi.
Tant que je travaillerai tout seul sur ce texte (hormis quelques robots qui font du travail automatique de temps en temps), et sachant que j'ai déjà fait beaucoup de travail dessus, merci de me laisser travailler en paix pour finir le travail. De temps en temps je noterai certaines choses et j'aide divers contributeurs quand je vois leurs questions sur des problèmes qu'ils ont avec leur travail, mais je ne vais pas loin et je les laisse continuer. On a tous bien assez de travail à faire chacun de son côté pour ne pas polémiquer sur ce que font les autres (on n'est déjà pas bien nombreux sur Wikisource, et la tâche est immense)
L'objet de Wikisource ne doit normalement pas poser de polémique (en dehors du respect du droit d'auteur, on s'est donné juste comme objectif de rendre fidèlement les textes, du mieux qu'on le peut pour les rendre exploitables par le plus grand nombre, et aussi les inciter à lire (donc dans une présentation également agréable si possible, sans dénaturer les documents).
De toute façon ce que j'ai mis n'impose pas de police. Ceux qui n'ont pas les jolies polices mentionnées (réputées, très bien travaillées, et particulièrement utiles aux textes anciens car elles supportent un jeu latin étendu et même bon nombre de ligatures traditionelles) ne verront pas la différence avec la police par défaut de leur navigateur. Si j'ai mis ça c'est aussi pour me faciliter la lecture à l'écran (car les polices par défaut de Wikisource sont beaucoup trop petites pour être lisibles notamment pendant la phase de correction des textes). Et chaque texte a ses préférences, les polices mentionnées sont conformes à la tradition typographique du XIXe siècle (une tradition qu'on recommence à découvrir pour ses mérites après des débuts difficiles sur nos ordinateurs très pauvres, et les ravages de la dactylographie qui a fait croire que c'était inutile alors que c'était seulement une containte technique avec les technologies de l'époque ; on n'en est plus là...). — Verdy_p (d) 5 décembre 2010 à 15:55 (UTC)Répondre
Mais nous sommes d’accord sur le but de Wikisource ; je pensais seulement qu’il était normal de t’informer de ce point. Maintenant, je comprends mieux la situation grâce à tes éclaircissements. Bonne continuation. Marc (d) 5 décembre 2010 à 16:06 (UTC)Répondre
Dernier commentaire : il y a 13 ans7 commentaires2 participants à la discussion
Que de choses dans le message. Pour éviter la crainte devant mes futures interventions:
les numéros dans les notes: non, je n'en ai pas mis, j'ai seulement recopié le texte complet de la note telle qu'elle était en bas de page, et le texte commence par un numéro. J'aurais pu aussi laisser le numéro entre parenthèses, très voyant dans le corps du texte, mais là j'ai vu que ça fait un peu idiot.
les chapitres complets: comme tout être pensant, j'agis selon une logique. Après avoir fait un essai "n'importe où", je me suis appliqué à garnir des chapitres complets. Actuellement la biographie de Mahomet et les sourates de la Vache, Aram, les Femmes, la Table, sont complètes, et rien d'autre.
Si l'utilisation d'un robot pour mettre le texte dans les pages n'est pas hallal, alors je ne continue pas. La recherche des césures de pages est un travail astreignant. S'il faut ensuite les copier-coller une à une, c'est trop de dévouement pour moi.
Quand j'ai commencé ce travail (avant que tu viennes y participer), je n'ai utilisé aucun robot au départ. Ce n'est pas un problème, mais la relecture s'impose quand même ; ce texte demande assez d'attention pour qu'on ne se fie pas à un seul robot, car il fait tout de même des erreurs, aussi bon soit-il. De toute façon j'ai tout manuellement pour corriger les derniers problèmes. Pour les coupures de page, oui c'est astreignant, mais ça se fait avec de la patience (j'ai cherché une autre solution basée sur l'inclusion sélective de sections, mais c'est trop lourd pur l'instant, mais surtout ça pose des problèmes avec les modèles de mise en page et qui insère les positions de numéros de page, le javascript qui fait ça a encore des problèmes pour gérer ça correctement). Au vu des bogues ou limitation actuelles, il vaut encore mieux ne pas scinder le texte des notes à cheval sur deux pages, et les regrouper, même si ç demande un travail en plus et ne facilite pas la relecture. — Verdy_p (d) 25 février 2011 à 12:26 (UTC)Répondre
En général, je sens un malaise dû au fait de ne pas être seul sur le sujet. Je vais donc me limiter à mettre le texte dans les pages, sans autre intervention. "Mon" texte, produit par un très bon OCR, et débarrassé mécaniquement des hyphénations et des titres courants, n'est pas parfait; je n'en ferai pas plus.
Pas de problème. Je fais les choses doucement mais soigneusement. Mais l'aide pour l'OCR est bienvenue et me facilite la tâche, même si je dois tout relire. Mais c'est vrai que ça m'arrange que les chapitres soient plutôt remplis en commençant par le début (ça limite le nombre des modifications à faire, et ça facilite les recherches). — Verdy_p (d) 7 décembre 2010 à 05:33 (UTC)Répondre
Au fait, je n'ai jamais abandonné ce livre, il a seulement progressé doucement, car je préférais faire des chapitres entiers et totalement prêts à valider que de faire les choses à moitié. La seconde partie est maintenant finie, il ne me reste plus que 4 chapitres d'une dizaine de pages chacun à mettre en forme. Ce sera vite terminé. — Verdy_p (d) 25 février 2011 à 12:26 (UTC)Répondre
Il y a un problème sur les chapitres 17, 20, et 22, qui se terminent en bas d'une page, le chapitre suivant commençant au début de la page suivante. La dernière page est liée au chapitre, mais son texte ne s'affiche pas chez moi. --Nyapa (d) 25 décembre 2010 à 12:46 (UTC)Répondre
Effectivement, c'est comme ça que ça fonctionne, avec des sections nommées : mais il ne faut pas se tromper de numéro de chapitre ! J'avais pourtant fait attention à ce que tous les chapitres commencent et finissent au bon endroit en créant la structure au moins pour leur première et dernière page. Je fais très attention aux transitions de pages. — Verdy_p (d) 25 février 2011 à 12:26 (UTC)Répondre
Dernier commentaire : il y a 13 ans8 commentaires2 participants à la discussion
Thanks for your efforts! Especially for the appendix – that is a nasty piece of work, isn’t it? I have some queries, though:
The transition from page 11 to 12 doesn’t work properly in transclusion; it introduces a superfluous paragraph break. Do you intend to fix that?
I was looking at those transitions. Unfortunately, this is a bug of the javascript, because the HTML generated is correct (as it introduces a span in the middle od theparagraph for noting the page break position, but then the javascript breaks it. I was already checking those breaks to find solutions (the most complex case being in tables). I've tried several solutions, but visibly, it's impossible to fix : there's no line break before or after the noinclude-section at end of page 11, and no line break before or after the noinclude-section at start of page 12 ; the transcluded text is correct and is one paragraphe (with an automatically inserted invisible span between each part, for marking the position of the page break and the value of the page number); ask for a bug correction in the complex Javascript that positions and displays page numbers in the left margin (it incorrectly changes the page data model, because it incorrectly assumes that a page break can only occur in the middle of a paragraph at the outter level, and is not prepared to the situation of text in a table cell without any "p" element container). — Verdy_p (d) 25 février 2011 à 11:53 (UTC)Répondre
The longer abbreviations are now being justified (e.g. irr. (suivi de chiffres romains)) – how about re-inserting text-align:left in these cells?
The justifications are part of the default CSS, I have not introduced it, but I may force the left alignment, unfortunately, it's not possible to ensure that the page width will be enough to fit all on one line, line wraps are unrpredictable on the web, and the fonts are already very small and I can't devently reduce them further. — Verdy_p (d) 25 février 2011 à 11:53 (UTC)Répondre
You replaced o᷍u and o͝u by oû and oŭ. I think it is beyond doubt that the former was intended by Foucauld. And seeing that Unicode provides codepoints for these diacritica, I think we should use them. (Although I have to admit that I am mystified – a week ago the ‘double’ circumflex was displayed correctly, but now it’s gone again!?!) Please be so kind to discuss this before making further changes on that point. Or perhaps you know a better solution?
Foucould used digraphs for the transliteration as "ou", even if it is a single vowel in the Tamashek script. Diacritics still apply to the digraphs, because there's no confusion. Double diacritics are not needed and are still a hack in Unicode, for pure academic purpose. But they have large display problems with many fonts for now. If you look at the manuscript, in fact it does not make any visible difference, as these diacritics are clearly written above the "u" and not really centered on top of both (and they don't have a doubled width). I tried to fixe them because you had used a blue status (without expliaining what was the problem). — Verdy_p (d) 25 février 2011 à 11:53 (UTC)Répondre
Thanks a lot, anyway! I hope to get around to working a bit on the dic soon. And pardon my English, I hope that’s OK for you; writing in French is very laborious for me. — Linus(disc)24 février 2011 à 17:46 (UTC)Répondre
I don't think I will file a bug report, because I have no idea of js. I am a little perplexed, though, because I had figured out a way to display it correctly.
Of course line breaks are unpredictable, but one can safely guess that the longer abbreviations will always be in danger of being distorted by justification. It seems advisable to me to suppress justification in these cells.
‘there's no confusion’ – I think that would remain to be seen, and to be concluded from recipient’s reactions, not decided offhand. ‘clearly written above the "u"’ – I think they’re clearly centered on the digraph. Therefore I am afraid the two of us might not reach an agreement on this point; I propose that we involve more users to find a solution. (Re the blue status: I had transcribed the first pages in order to find out which problems there would be in working on the dict, and problems there were – hence the status. After that I didn’t do anything for a long time. My fault, my apologies.)
« No has has ? ». All French people have it on their keyboard, as it's standard for French, everyone working in this wiki should be using a keyboard supporting it ; it is definitely not special, and at least not in this French wiki.
And anyway, to work with the many Touareg transliteration to Latin, you'll still need an extended keyboard or charmap. I use one such extended keymap since long (built for Windows with Microsoft Keyboard Layout Creator, aka MSKLC).
I'm not convinced anyway that the author wanted circumflex and breve as double diacritics. They are diffinitely not double-width, and the centering is well above the u. If you think this causes an amiguity, then the digraph "ou" without any accent is already ambiguous as well. It is not, notably in the French context where this transliteration was created (the additional "o" is there due to French pronunciation of "ou" (as a single phoneme similar to English "oo" or German "u"), and distinct from "u" (which is read like German "ü"). Even the use of accents on "e" confirms that the tranliteration was created for reading by French. Other transliterators for English would have not written the "o" but only "u", as there's no such sound like the French "u" or German "ü" in English. Visibly, the Touareg language also as no distinctive diphtong like English "ow". The "o" is then just helping the reding of the following "u" (and the accent is there only for altering the lenght/stress of this "u". Using a double diacritic is really overkill in this context (And after reading some books produced in Morocco, no one has ever used doule diacritics there for Touareg languages, even before the revival of the Tifinagh script. — Verdy_p (d) 25 février 2011 à 19:27 (UTC)Répondre
Dernier commentaire : il y a 12 ans2 commentaires2 participants à la discussion
Bonjour,
J'ai vu que tu avais récapitulé les paramètres de ce modèle, mais apparemment il y manque le paramètre lh=nb de ligne (ou pourcentage) qui permettait de l'espacer automatiquement. Je l'ai beaucoup utilisé, car il est très pratique, et il ne fonctionne plus. Serait-il possible de le remettre, STP. Merci d'avance, --Hsarrazin (d) 17 avril 2011 à 11:56 (UTC)Répondre
Je n'ai pas touché à ce paramètre qui fonctionne encore comme avant; je n'ai fait que réduire la syntaxe et la simplifier en interne. Il génère toujours le style "line-height:{{{lh}}}, mais seulement quand le paramètre lh est précisé avec une valeur non vide (note ce n'est pas un nombre de lignes mais un rapport de proportion de l'interlignage avec la taille de corps de la police, sa valeur par défaut étant 1.5).
Note: il y a une différence entre "line-height:1.5", et "line-height:1.5em", car le premier est hérité dans les sous-éléments si leur taille de police uniquement est modifiée (par exemple avec les balises <big> et <small> ou un style CSS "font-size:...;" explicité, ou via des indices et exposants), au contraire du second. En revanche line-height ne s'exprime normalement pas en pourcentage (s'il l'est, c'est en proportion de la hauteur de ligne actuelle de l'élément englobant, donc en relatif, mais là encore sans héritage dans les sous-éléments si leur taille de police change).
Note encore: line-height sert à déplacer veritcalement la TOTALITE de la ligne de texte rendue (quelle que soit la taille des polices contenue dans cette ligne). Quand il y a plusieurs tailles de polices avec chacune un "line-height" effectif final différent, c'est la valeur maximale de toutes les "line-height" calculées qui est prise en compte. Etant donne que les différents éléments d'une même ligne sont alignés relativement entre eux en fonction de leur "ligne de base" avant de déterminer la hauteur de ligne minimale effective, la valeur de line-height est utilisé pour recentrer verticalement cette hauteur minimale dans une hauteur maximale, par un simple décalage vertical (positif ou négatif : le line-height prévaut est est bien une hauteur totale de ligne qui ne peut pas être dépassée, même si les polices dans la ligne (avec leur alignement sur leur ligne de base) sont trop grandes (ans ce cas, cela peut aboutir, à des superpositions partielles de lignes, qui sont affichées avec la ligne du dessous dessinée par dessus celle du dessous qui peut être cachée partiellement si la ligne du dessous a un fond non transparent, les lignes étant dessinées dans l'ordre de haut en bas tant qu'on ne modifie pas le "z-order:" ou qu'on n'emploie pas de positionnement absolu).
Comme je n'ai absolument pas changé la logique du style généré (qui est toujours la, donc je ne peux pas le « remettre » ! La seule chose est qu'il n'était pas documenté dans la page de doc, je peux l'y ajouter dans la doc mais rien n'a changé), il est fort probable que tu ne donne pas la bonne valeur au paramètre lh= dans ta page. Peux-tu montrer où il y a un problème ??? — Verdy_p (d) 24 avril 2011 à 18:14 (UTC)Répondre
Dernier commentaire : il y a 10 ans3 commentaires2 participants à la discussion
Bonjour. Et bienvenue au revenant. Je croyais que vous ne viendriez jamais finir le Coran de Savary que nous avons corrigé ensemble. Je vois que mon travail "concurrent" ne vous agrée pas. Y a-t-il un droit d'auteur sur les pages de Wikisource ? --Nyapa (d) 13 décembre 2013 à 02:12 (UTC)Répondre
Non mais pourquoi le recréer en doublon alors que pratiquement tout est déjà numérisé (le seule chose qui manque c'est la finalisation des numéros de versets, et un peu de mise en forme des notes, avec assez eu de corrections restantes à vérifier).
En revanche l'import du fichier DejaVu n'est pas conforme à la licence de Boogle Books d'où tu l'as créé. Google Books demande cette attribution pour l'aspect technique de la numérisation et demande qu'on la préserve (ce qui n'ôte pas le caractère domaine public du contenu de l'oeuvre elle-même, mais ne retire pas la propriété de l'ouvrage original). La conversion en DejaVu n'apporte strictement rien de plus par rapport au PDF qui est un format géré de façon équivalente. Le format PDF n'est plus propriétaire depuis longtemps, c'est même une dégragtion de l'original dont il est extrait puisque les pages sont coupées pour cacher un filigrane dont la conservation est pourtant demandée, et parce que des pages sont supprimées à mauvais escient.
Les pages de Wikisource ont bien un droit d'auteur pour leur contenu OCR corrigé ou les annotations (dont tu n'as tenu aucun compte en refaisant une copie où tu les as carrément purgées, y compris du signalement des coquilles et d'autres élements de comparaison).
En plus puisque c'est le fait qu'une vingtaine de pages n'avaient pas été relues, pourquoi avoir perdu du temps à tout refaire (en ignorant la première partie aussi...). Je ne suis pas seule propriétaire, et je ne revendique rien et ta paternité a été conservée je ne l'ai pas remise en cause comme tu l'as fait "en douce" (en important un doublon non conforme, et au titre encore plus mal fichu et ambigu).
Si le fait que ce n'était pas assez complet à ton goût te gênait, rien ne t'empêchait de continuer. Le principe étant qu'ici on ne travaille pas tout seul et personne n'est non plus contraint à finir quoi que ce soit. Wikisource est collaboratif et tu l'as complètement oublié en travaillant comme ça dans l'ombre sans rien dire à personne (et même sans me demander ce que je comptais faire). Tu n'en as parlé nulle-part avant de te lancer dans cette copie qui ne garde QUE ta seule paternité, ce qui est un abus manifeste de ta part des règles des projets Wikimedia...
Il y a des tas de choses non terminées dans Wikisource, et si jamais il venait à l'idée de quelq'un de reprendre n'importe quel contenu pour en refaire un doublon ce sera inacceptable. Wikisource n'a clairement pas besoin de ça. — Verdy_p (d) 17 décembre 2013 à 17:50 (UTC)Répondre
Idée : fork du module Table pour imiter des lignes de pointsmodifier
Dernier commentaire : il y a 10 ans2 commentaires2 participants à la discussion
Bonjour,
je rencontre actuellement des difficultés pour reproduire des lignes de pointillé. Or j’ai remarqué que le modèle Table donne un résultat très proche de ce que je désire reproduire. J’ai laissé un message dans Questions techniques, où j’explique tout ça.
Comme ce modèle appelle le module Table et que je n’y connais rien en Lua, je viens vers toi — je crois en effet comprendre que c’est toi qui as créé ce module. Penses-tu qu’il serait possible de créer un nouveau module sur la base du module Table modifié afin de créer ces lignes de points ?
Les lignes de "pointillés" (points de suite) sont réalisées avec des bordures de rectangle, en jouant sur les superpositions d'éléments et la transparence.
Ce modèle a été très compliqué à créer et tester pour que cela marche sur à peu près tous les navigateurs: j'en ai testé plus d'une quarantaine sur différents OS, y compris les navigateurs intégrés pour mobiles et tablettes Android, iPhone et Windows Phone, et les navigateurs "embarqués" (comme Opera Embedded qu'on trouve dans les téléviseurs récents avec connexion Internet ou dans les décodeurs TV de nos box Internet). De plus je voulais que cela respecte la structure des éléments afin de ne pas perturber la recherche en plein texte, ou le copier-coller vers un éditeur de texte.
Je me suis mis à Lua quand il est apparu sur Wikimédia, mais les titres du sommaire ont été réalisés bien avant ça uniquement avec des modèles.
Pour l'instant je n'ai encore rien fait ici sur Wikisource en Lua, mais surtout sur d'autres sites (Commons, Meta-Wiki, Wikipédia en français et anglais, un peu dans le Wiktionnaire en français).
Je ne sais pas trop ce que tu demandes: il faudrait un exemple.
Note: je ne suis pas avisé des messages qu'on poste ici car ce n'est pas mon wiki principal (je l'aurais été si tu avais notifié ma page Wikipédia). Je viens de voir ton message par hasard, désolé pour la réponse tardive. — Verdy_p (d) 17 février 2014 à 22:19 (UTC)Répondre
Je n'ai pas dupliqué, mais le sujet initial portait sur l a forme d'un document sur lequel il était nécessaire de soulever le point, mais c'est bien entendu un sujet qui intéresse la section "légal" et qui devait y être signalé.
Je crois que tu devrais te renseigner 1. sur le droit d’auteur, 2. sur les règles applicables sur les projets Wikimedia, avant d’écrire des erreurs ici. Cordialement, Yann (d) 19 février 2014 à 10:17 (UTC)Répondre
Avant de m'accuser de faire des erreurs, note que ce n'est qu'une discussion qui justement demande des avis et contre-avis. Ca se discute, mais en matière de droit d'auteur, j'ai avancé assez d'arguments crédibles pour justifier ce que j'écris (et je n'ai pas dit que c'était des violations, j'ai juste dit que je le pensais selon les arguments que j'évoque. Je fais une interprétation beaucoup moins "libérale" que ceux qui lisent seulement le droit américain en le survolant et oubliant de voir ce qu'il ne couvre pas. Le domaine public américain n'est pas le domaine public français et il ne couvre pas du tout les œuvres étrangères (sinon les autres pays membres de la Convention de Berne auraient demandé des dédommagements aux USA pour violation de la Convention de Berne, et des tas de procès auraient eu lieu aux USA et des tas d'amendes prononcées). C'est vrai que Wikisource publie une alerte sur la question de ces droits hors des USA, mais faire des restrictions d'usage selon le pays n'est pas du tout dans l'esprit d'un projet "libre" qui veut des contenus utilisables partout et par tous. Est-ce le rôle de Wikimedia de faire prendre des risques légaux à ses utilisateurs ? — Verdy_p (d) 19 février 2014 à 10:27 (UTC)Répondre
Pour le droit d'auteur, regarde le tableau Hirtle, dans le bas du tableau, qui est une copie de [3].
Pour les règles utilisées sur les projets Wikimedia, le Wikisource en anglais, par exemple, publie des textes d’origine anglaise qui ne sont pas dans le domaine public au Royaume-Uni, mais qui le sont aux États-Unis. Cordialement, Yann (d) 19 février 2014 à 11:10 (UTC)Répondre
Et pour info, regarde en:Uruguay_Round_Agreements_Act (URAA) qui (enfin) mets les USA en conformité totale avec la Convention de Berne.
Commons depuis cette loi est tenu de l'appliquer et respecter le copyright des œuvres étrangères qui ne sont pas (ou ne peuvent plus être) dans le domaine public américain) puisque le droit américain reconnait totalement le copyright des œuvres étrangères (et ne permet plus de placer ces œuvres protégées dans le domaine public américain (ce qui avait été fait unilatéralement en 1989 à l'encontre même de l'accord la convention de Berne de 1989: les USA ont cédé car ils risquaient de lourdes amendes (un procès était sur le point d'être lancé par l'OMPI/WIPO devant une cours internationale, avec le fort appui de tous les autres pays membres de la convention) et aussi de perdre leur droit à réclamer la protection de ses œuvres dans les autres pays membres de la convention).
Bref, c'est toi qui n'es pas au point question droit ! Et Commons a commencé à appliquer cette loi américaine (la Fondation Wikimedia n'a pas le choix) : suppression de tas d’œuvres (notamment des photos et des facsimilés de livres) qui sont encore protégées par le droit d'auteur du pays d'origine.
Bref, c'est toi qui n'es pas au point question droit ! Et Commons a commencé à appliquer cette loi américaine (la Fondation Wikimedia n'a pas le choix) : suppression de tas d’œuvres (notamment des photos et des facsimilés de livres) qui sont encore protégées par le droit d'auteur du pays d'origine.
Et cela fait débat maintenant à la Fondation (Wikimedia Espagne et Wikimedia Israël dénoncent dans une lettre ouverte cette suppression, mais il n'y a pratiquement aucune chance que cela passe (le risque légal encouru par la Fondation est trop élevé)! Le droit américain s'impose sur Commons (et probablement aussi sur tous les autres projets, même Wikipédia ou Wikisource en espagnol ou hébreu) : même Wikipedia Espagne ou Wikimedia Israel ne pourraient pas non plus héberger ces contenus eux-mêmes sur des pays dans leur pays, puisque ces pays sont également membres de la Convention et renforcent aussi le droit des œuvres étrangères issues de, et protégées dans, les autres pays membres de la Convention. S'ils voulaient garer ces œuvres; ils devraient les faire héberger en dehors des pays membres de la Convention (aujourd'hui l'OMPI/WIPO) et ils auront du mal à trouver un service performant dans les pays non-membres (qui sont aussi ceux les moins équipés en Internet et qui aussi ne reconnaissent pas non plus le droit des licences libres utilisées sur Commons et peuvent s'approprier ces contenus et les censurer à loisir !) — Verdy_p (d) 20 février 2014 à 20:22 (UTC)Répondre
Je sais tout cela, mais ça ne change pas d'un iota ce que j'ai écris ci-dessus. L'URAA ne s'applique qu'aux œuvres publiées après 1922. Cordialement, Yann (d) 20 février 2014 à 20:25 (UTC)Répondre
Pas du tout ! Cela concerne toutes les œuvres dont le droit d'auteur est protégé dans leur pays d'origine membre de la convention. 1922 est la mauvaise date : ce ne sont pas les USA qui fixent la date mais le pays d'origine du droit d'auteur protégé. — Verdy_p (d) 20 février 2014 à 20:29 (UTC)Répondre
Tu es libre de ne rien comprendre malgré les liens que je t'ai donnes ci-dessus, mais ne vient pas donner des leçons de droits ici. Et tu devrais VRAIMENT te renseigner avant de dire des âneries. Merci, Yann (d) 21 février 2014 à 17:52 (UTC)Répondre
Tu n'es pas libre d'être insultant. Désolé pur toi, ta "conclusion" discrédite complètement la totalité de ton discours d'autant plus que tu réponds complètement hors sujet n faisant un jugement personnel au lieu de t'en tenir à la question. Et non je ne suis pas là pour faire des leçons de droit : Wikimedia n'est pas un tribunal et tu n'es pas un juge ici (ni moi non plus). — Verdy_p (d) 13 juin 2014 à 19:02 (UTC)Répondre
Dernier commentaire : il y a 8 ans4 commentaires2 participants à la discussion
Bonjour,
Ce modèle est très utilisé, donc merci de ne pas modifier son comportement sans en discuter un minimum... Seudo (d) 30 mars 2016 à 14:13 (UTC)
Pour être plus précis, je suis intervenu suite à une remarque sur le Scriptorium. J'ai vu que le comportement du modèle ne correspondait pas à sa documentation, donc j'ai annulé les modifications apportées à l'un et l'autre pour repartir, s'il y a lieu, sur de bonnes bases. Seudo (d) 30 mars 2016 à 14:22 (UTC)Répondre
Ce modèle est faux à la base dans sa documentation. De plus un saut de ligne standard (au sein d'un même paragraphe) mesure 1.5em (et non 1em) avec l'interlignage standard du texte (class="pagetext").
Comme il insère un "div", celui force une fin du pagraphe précédent (et implique que tout texte suivant, s'il n'est pas lui-même débuté par un div, forme un nouveau paragraphe) : il induit donc des marges supplémentaires (en plus des prétendus "sauts lignes" qui n'en sont pas car l'élément "br" inclus dans le modèles est trop petit d'un tiers par rapport au "nombre de lignes" indiqué).
La doc n'était pas plus convaincante (et ne l'est toujours pas).
Bref dans la façon dont il est écrit (avec un "div") il ne génère jamais des sauts de ligne dans un paragraphe, il crée toujours un saut de paragraphe (c'est MediaWiki qui le fait automatiquement avant et après tout "div"), avec un espacement interne faux (trop petit) et des espacements externes (marge de fin du paragraphe précédent et marge de début du paragraphe suivant), ainsi qu'une indentation du texte qui suit (début de paragraphe). Il a aussi pour conséquence de rompre une liste (normal car il y a bien rupture de paragraphe), ou un bloc indenté (avec ":").
Je comprends les critiques sur le code. Il me semble toutefois préférable d'adapter la documentation au code que de modifier celui-ci. Pour l'utilisateur moyen, il fait en gros ce qui est attendu (insérer un espace paramétrable, sans avoir à se soucier si on le précède ou pas d'un ligne vide). Éventuellement, on pourrait le renommer pour marquer qu'il vaut pour son effet visuel et non pour la structuration du texte. Seudo (d) 30 mars 2016 à 17:15 (UTC)Répondre
L'effet le plus gênant est qu'en premier lieu ce n'est pas un simple saut de ligne mais bien un saut de paragraphe (d'où l'indentation qui suit sur la première ligne de texte et la rupture des listes ou des blocs indentés). Rien d'équivalent avec le nombre attendu d'éléments "br" (qui n'interrompent pas un paragraphe quels qu'en soit le nombre), en en fait plus proche du comportement de plusieurs lignes blanches (qui ferment un paragraphe avant puis crée un nouveau paragraphe qui commence éventuellement par des "br", un de moins que le nombre de lignes blanches).
Quant au "en gros", c'est plutôt "vaguement" car la mesure indiquée n'a rien à voir avec celle d'un saut de ligne (brn|5 produit ici un espacement de 5em+les petites marges éventuelles des paragraphes juste avant et après, dont pas du tout les 7,5em attendus). — Verdy_p (d) 30 mars 2016 à 17:50 (UTC)Répondre
Dernier commentaire : il y a 6 ans14 commentaires3 participants à la discussion
Bonjour,
Je trouve sincèrement que la version de Hsarrazin : correspond mieux à ce qu’on attend des textes sur wikisource ! tu parles de saccage, je parle d’amélioration, tout ton pataquès avant et après le texte devrait être en pdd et non sur la page principale. De plus merci de ne pas enlevé l’icone scan qui permet d’avoir un lien facile vers le Fac-similé qui nous est utile pour la maintenance. Maintenant je ne comprends pas bien pourquoi tu crées des pages vides qui ne servent strictement à rien !
Je dis bien saccage, il n'y avait besoin de rien supprimer sans savoir ce qui était utilisé, il y a eu destruction gratuite. — Verdy_p (d) 17 août 2017 à 17:56 (UTC)Répondre
Non ce ne sont pas des pages vides, mais des modèles spécifiques à ce document pour sa mise en forme, ils sont transclus et indépendants des sous-pages, et qui ne polluent pas du tout l'espace des modèles génériques, ils sont en sous-page du "livre" principal qui lie le tout.
De plus je n'ai enlevé aucune "icône" vers les pages ce retrait a été fait bien avant. Toutes les pages avaient avant leur aperçu depuis le début, et tout était validé avant que certains s'amusent à virer des modèles utilisés sans regarder la liste des utilisations. — Verdy_p (d) 17 août 2017 à 18:01 (UTC)Répondre
Le problème est surtout que ces modèles en sous pages parraissent dans les pages sans fac-similé que nous essayons désespérement de réduire. D’autres part, en pratiquant ainsi, personne n’est capable de comprendre comment vous travaillez, et si quelqu’un repasse derrière vous parce qu’il aurait vu une erreur, il est incapable de modifier quoi que ce soit, je me suis déjà cassé les dents sur le coran fait par vos soins. Votre pratique fait que vous êtes le seul à comprendre ce que vous faites, et cette méthode est pour moi anti-collaborative, mais il est vrai pourquoi faire simple quand on peut faire compliqué. --Le ciel est par dessus le toitParloir17 août 2017 à 18:13 (UTC)Répondre
Il y avait un fac-similé mais le fichier a été supprimé ici sous prétexte que c'était un PDF et pas et DjVu...
Non il n'y avait besoin d'aucune rectification, tout avait été validé depuis très longtemps. Maitenant je suis en train de réparer tout ce qui manque: quel besoin y avait-il à casser ce qui était fini ??? — Verdy_p (d) 17 août 2017 à 18:16 (UTC)Répondre
Fini ??? Le "rabot" qui est passé a juste tout cassé, il n'y avait plus rien du tout ! Je ne peux pas revenir facilement sur la suppression du facsimilé qui était ici, donc pas moyen de rétablei la navigation en mode page avec le vis-à-vis. Mais même le texte validé ne fonctionnait plus du tout. Je remet le minimum qui rend le texte lisible à nouveau et dans l'état où il était avant le massacre. Et au passage, j'avais totalement fait ce document ici. Personne d'autre n'avait aidé, et il est resté valide depuis 2009. Pas la peine de revenir tout massacrer 8 ans après ! Alors qu'il n'y avait plus rien à faire sur ce document terminé et validé qui ne nécessitait aucune retouche. — Verdy_p (d) 17 août 2017 à 18:31 (UTC)Répondre
Et non, ces modèles sont de la mise en forme. Ce wiki en est plein avec des tas de modèles incohérents et instables, et pas plus évidents que les 3 ou 4 qui sont dans le document et pallient justement l'absence du facsimilé en vis-à-vis et respectent la mise en forme. Tout y était au départ. Ce wiki en plus impose la mise en forme des paragraphes qui n'est pas conforme au document, il fallait donc y palier, et je n'ai pas touhcé aux modèles génériques pour le faire, cela restait complètement cantonné à l'espace de nommage de ce seul document et pas ailleurs. — Verdy_p (d) 17 août 2017 à 18:44 (UTC)Répondre
Stop !
Même si c’est moi qui ait initié cette conversation, je ne m’y attarderai plus, puisque vous semblez être seul à détenir la vérité. Mais je ne doute pas que dans un plus ou moins proche avenir d’autres contributeurs s’interrogerons sur votre façon de contribuer.
Euh!! Merci de ne pas dégrader encore ce document. Que je restaure dans sont état. J'ai mis comme tu voulais certaines parties dans la page de discussion comme tu sembles le vouloir, mais le doc doit être lisible. Et je confirme que depuis 2009 ce document avait bien un facsimilé ici (le PDF lui-même non altéré) et était totalement conforme, validé par plusieurs, et terminé depuis des années et que donc tu as décidé seul de continuer à le massacrer au point qu'il n'était plus lisible du tout par personne. Bref c'est plutôt toi qui commence à faire cavalier seul et revenir sur les contributions de plein de monde avant (mais surtout moi qui avait fait tout le boulot, les autres ayant des détails mineurs sui à l'évolution du wiki mais sans casser. Je ne suis pas responsable de la suppression du facsimilé. — Verdy_p (d) 17 août 2017 à 19:01 (UTC)Répondre
Bonsoir,
Il restait bel et bien des corrections à apporter, et j’ai dû batailler pour trouver comment corriger la bête coquille qui comportait un 1’ à la place d’un l’…
nul, jamais, ne peut prétendre n’avoir laissé aucune erreur… et organiser son travail sur un wiki, qui est par définition collaboratif, de matière à empêcher tout autre que soi de faire une modification, est un abus…
aucun travail fait ici, par quiconque, ne lui appartient, et tout contributeur doit s’attendre à voir son travail repris et modifié par d’autre... s’y opposer est contraire à l’esprit même du wiki contributif.
que tu aimes faire de belles typographies, je peux le comprendre, mais quand ce travail n’est pas lisible sur un portable, et encore moins exportable en epub, c’est problématique ; et le but premier de wikisource est de mettre en ligne des textes, pas de monter des typographies qui sont peut-être jolies sur un écran d’ordinateur, mais absolument pas adaptées à un écran plus petit (et plus des 2/3 de nos lecteurs sont sur mobiles, désormais…).
si tu retrouves le pdf original, on peut parfaitement le remettre dans l’espace Livre, car les pdf sont désormais acceptés (même si on préfère les djvu), et ainsi remettre le texte en espace page, ce qui permettra de travailler de manière plus conforme aux pratiques actuelles de contribution sur wikisource. --Hélène (d) 17 août 2017 à 21:03 (UTC)Répondre
Le PDF était là à l'origine (avec son extension PDF). J'ai du batailler pour restituer un pseudo-mode page (en renommant les pages de l'espace "Page:" où c'était à l'origine, vers l'espace article dans des sous-pages "/numéro".), et restituer une version imprimable et une version complète à lire en ligne. cela marchait en 2010. Mais tout avait été validé en 2009.
Je n'ai jamais prétendu que j'étais le seul à pouvoir faire des corrections. J'avais pris grand soin pourtant à relever même les coquilles présentes dans l'original. Mais je maintiens qu'à l'époque cela avait été validé en mode page de la façon normale et très scrupuleusement (il a pu échapper à ce moment là) un "1" à la place d'un l, mais je trouve cela étonnant vu le nombre de trucs qui ont été cassés successivement et de plus en plus depuis 2010. Difficile en plus de voir qui a fait quoi quand il y a eu des suppressions sauvage (certains historiques ne sont même plus disponibles, y compris les historiques de l'ancien espace de nom "Page:" quand le PDF a été supprimé ici). — Verdy_p (d) 17 août 2017 à 21:11 (UTC)Répondre
