Wikisource:Questions techniques

Vous êtes ici : accueil >Aide >Questions >Questions techniques

Questions
Raccourci [+]
WS:S
Circle-icons-compose-light blue.svg

Choix éditoriaux
Contenu des livres, mise en page, typographie, etc.
Circle-icons-tools-light blue.svg

Questions techniques
Utilisation de Wikisource, de la syntaxe d'édition, de l'interface.
Circle-icons-gavel-light blue.svg

Questions légales
Droits d'auteurs sur les livres et questions juridiques.
Circle-icons-caracters-light blue.svg

Questions sur les Glyphes & caractères
Codage et représentation des glyphes et caractères.
Circle-icons-chat-light blue.svg

Scriptorium
(Mois en cours, Archives, discussion générale en anglais)
Pour laisser un message qui ne concerne pas les cas cités.
Communauté : Forum des nouveaux - Annonces - Projets communautaires (2020) - Actualités - Newsletter technique - Pages à supprimer



l'OCR sur la barre d'outilsModifier

Quel script est la source de l'OCR sur la barre d'outils, du l'éditeur source, de ce wiki? Je voudrais le lier à partir de la Wikisource anglaise.—Ineuw 2 janvier 2020 à 20:11 (UTC)

Erreur du bouton TModifier

Je viens de faire plusieurs fois (la dernière ici) l’expérience d’une erreur (sporadique) du bouton T : il a corrigé plusieurs occurrences de deux point (:) ou de points-virgules (;), en supprimant les espaces avant ou après, pourtant nécessaires en typographie du français ! Merci d’avance pour un conseil ou un correctif. Fabrice Dury (d) 27 janvier 2020 à 08:30 (UTC)

  Fabrice Dury :Cela arrive dans certains cas, quand on a une syntaxe utilisant des guillemets clavier (pas toujours cependant, mais quand ça se passe, c'est toujours qu'il y a quelque chose comme ça) : personnellement, j'utilise toujours le gadget avant de mettre en place ces éléments de syntaxe. --Acélan (d) 4 février 2020 à 09:45 (UTC)
Merci pour l’explication. Il serait mieux, tout de même, que le défaut soit évité inconditionnellement, donc que le bouton T soit corrigé. Cordialement. Fabrice Dury (d) 4 février 2020 à 09:52 (UTC)

Non affichage des pages d'un fac-similéModifier

Bonjour,

Les pages de l'ouvrage L’isotopie et les éléments isotopiques de Marie Curie ne s'affichent pas, c'est peut-être lié au fait que j'ai chargé l'ouvrage hier alors que certains serveurs de la Wikimedia Foundation rencontraient des problèmes (d'après ce que j'ai pu voir sur Twitter). Savez-vous comment régler ce problème ?

--George2etexte (d) 27 janvier 2020 à 18:01 (UTC)

Export pdf => changement de format ?Modifier

Bonsoir,

J'ai des différences de format sur des exports réalisés ce soir avec l'outil "Télécharger en PDF" en haut de page… En effet, la mention "Exporté de Wikisource le …" apparait deux fois de suite (la deuxième sur une page presque vide), et les marges semblent maintenant beaucoup plus importantes que précédemment…

Est-ce un bug de fonctionnement pour ce soir ? des tests en cours ? ou bien un changement définitif dû à une évolution de l'outil ?? Si c'est un changement définitif, cela ne m'arrange pas, car je formate souvent les deuxièmes de couverture, et les pages de présentation en fonction de ce que cela donne à l'export…

Y-a-t-il moyen de revenir en arrière ??? Enfin, l'idéal serait peut être de pouvoir paramétrer la marge comme on veut !?

merci si vous avez des explication sur ce phénomène  

--Lorlam (d) 3 février 2020 à 22:31 (UTC)

  Hsarrazin : Hélène, le changement de format d'export se confirme aujourd'hui… sais tu si c'est une modification définitive de l'outil ? merci --Lorlam (d) 4 février 2020 à 19:11 (UTC)
  Lorlam : pas la moindre idée... peux-tu, stp, me mettre le lien vers la page du livre sur lequel tu as ce problème ?
  Tpt : y a-t-il eu des changements sur WSexport ? --Hélène (dite ''le bot de service'') (d) 5 février 2020 à 09:10 (UTC)
  Hsarrazin : Je me suis aperçu du changement en faisant un export sur le livre sur lequel je travaille en ce moment : Michel Strogoff (théâtre 1881), mais j'ai vu après que cela impactait en fait tous les livres… D'où ma question… Pour moi, il est clair que l'export ne "marche" pas comme avant (je le constate encore aujourd'hui)… maintenant, je ne sais pas si c'est une évolution "volontaire" ou bien un bug !!! a+ --Lorlam (d) 5 février 2020 à 09:53 (UTC)
La version de Calibre utilisé pour générer les PDFs à partir de l'ePub a été mise à jour. C'est sans doute l'origine des différences. Cela devrait être possible de configurer les marges pour faire en sorte qu'elles reste les même qu'avant. Je vais creuser cela. Tpt (d) 5 février 2020 à 13:47 (UTC)
  Hsarrazin et Tpt : Oui, merci beaucoup Tpt… en effet ce serait bien de revenir aux marges d'avant   a+ Laurent --Lorlam (d) 5 février 2020 à 19:43 (UTC)
  Tpt : À propos, Tpt, en dehors du "problème" de marge, il y a aussi le fait que la mention "Exporté de Wikisource le xxx" s'affiche deux fois : une fois au bas de la page 3 de l'export (normal)… et une deuxième fois sur une page 4 qui apparaît du coup intempestivement… Tiens nous au courant des corrections si c'est possible… merci encore. Laurent --Lorlam (d) 7 février 2020 à 17:03 (UTC)
  Hsarrazin et Tpt : re-bonjour… je reviens de quelques jours de vacances et j'ai re-tenté l'export pdf => le résultat a encore changé depuis une semaine, mais les marges sont toujours très larges ! a+ Laurent --Lorlam (d) 15 février 2020 à 23:08 (UTC)
  Hsarrazin et Tpt : re-re-bonjour… Autre chose, j'ai l'impression qu'il y a quelquefois un "bug" sur l'extraction de la page de garde ; par exemple sur le livre Le Secrétaire et le Cuisinier => j'ai fait un export, mais il y a un message d'erreur quand on ouvre le fichier avec Acrobat Reader : "Données insuffisantes pour une image"… Avant, l'export de cette même page marchait très bien… a+ Laurent --Lorlam (d) 16 février 2020 à 01:04 (UTC)
  Lorlam : Calibre a été en effet mis à jour vers la version 4 depuis une semaine. Sam Wilson viens de mettre sur la version test de l'outil un correctif pour les marges. N'hésite pas à le tester. Je regarde pour la page de garde. Tpt (d) 17 février 2020 à 11:14 (UTC)
  Tpt : Tpt : oui, j'ai testé la version "test" en mode pdf A5 (la plus proche du résultat de l'ancien outil) => les marges sont "ok", par contre, la police de caractères est un peu différente d'avant (taille un tout petit peu plus grosse, mais pas plus lisible car caractères un peu moins épais)… par contre, il y a là aussi le problème d'export de l'image de première page, qui est gênant ! (voir par exemple sur cette page : Le Château de la Poularde)… s'il y a des essais de correction ultérieurs, je veux bien tester à nouveau pour aider   a+ --Lorlam (d) 17 février 2020 à 20:12 (UTC)
  Tpt : Tpt : juste pour savoir ; tu as pu reproduire et constater ce "bug" sur l'extraction de la page de garde qui donne à la lecture du fichier pdf le message "Données insuffisantes pour une image" ?… Personnellement je le constate sur tous les textes qui font partie d'un volume plus gros, comme par exemple les pièces de théatre de Scribe : Le Secrétaire et le Cuisinier / Le Coiffeur et le Perruquier / etc… a+ Laurent --Lorlam (d) 19 février 2020 à 13:22 (UTC)
  Hsarrazin et Tpt : Tpt : Désolé d'insister, mais, n'y aurait-il pas moyen de remettre "temporairement" l'ancien outil d'export, qui marchait très bien ??? (en attendant que les problèmes de celui-ci soient résolus). Car, c'est quand même dommage de ne pas pouvoir export proprement en "pdf" depuis plusieurs semaines… a+ Laurent --Lorlam (d) 23 février 2020 à 09:45 (UTC)
  Lorlam : - merci de ne pas continuer à me pinguer sur ce problème... je n’ai aucune compétence technique en la matière   --Hélène (dite ''le bot de service'') (d) 24 février 2020 à 11:01 (UTC)
  Lorlam : je viens de finaliser un correctif pour l'affichage de la première page. Il est en attente d'une seconde vérification de la part de Sam pour (re)vérifier le changement avant déploiement. Tpt (d) 1 mars 2020 à 11:37 (UTC)
  Tpt : Super Tpt, entre cette correction et celle des marges, on va bientôt pouvoir ré-exporter en obtenant un résultat satisfaisant ! c'est à mon sens important pour valoriser le travail de tous les contributeurs qui participent pour mettre à disposition des œuvres sur WS… merci beaucoup en tout cas, pour tout le travail technique nécessaire à la correction de l'outil   Et puis, je suis preneur de l'info du futur déploiement de la version ad-hoc. A+ Laurent --Lorlam (d) 1 mars 2020 à 12:53 (UTC)
  Tpt : Tpt, je viens de re-faire des exports "pdf" => le problème des marges est maintenant résolu… par contre, le problème d'affichage de la première page subsiste sur certains livres… Je suppose que ta correction n'est pas encore implémentée… y-a-t-il moyen de la vérifier quelquepart sur une version de test ??? a+ Laurent --Lorlam (d) 7 mars 2020 à 13:48 (UTC)
  Tpt : et   Lorlam : Bonjour! je pense avoir identifié une source à ce problème d’affichage de la première page de certains fichiers PDF.
Les ouvrages testés ont tous en commun une image-couverture codée sur 8 bits. Il s’agit de:
  • Histoire de Rouyn
  • Le Secrétaire et le Cuisinier
  • La région du lac Saint-Jean, grenier de la province de Québec
  • Lionel Duvernoy
Résultat obtenu: dans tous les cas, le message « Données insuffisantes pour une image » est lancé systématiquement à chaque ouverture du fichier exporté ou converti en format PDF
Deuxième test effectué: insertion dans MS Word des fichiers cover.jpg (8 bits) et impression avec Print to PDF. Toujours le même résultat : « Données insuffisantes pour une image »
Troisième test avec les fichiers cover.jpg rééchantillonnés en 24 bits: conversions en PDF réussies tant avec Calibre qu’avec Word (Print to PDF).
Quatrième test effectué avec les fichiers reconvertis en 8 bits => le problème revient
Cette incompatibilité avec une image codée sur 8 bits a été signalée récemment et corrigée par Autodesk et par Microsoft dans SQL Server.
Solution proposée: Je m'en remets à toi, Tpt, pour évaluer la pertinence de rééchantillonner sur 24 bits directement dans wsexport. Je ne m’y connais pas du tout en PHP mais peut-être essayer avec « Imagick::getImageDepth » et « Imagick::setImageDepth » dans la fonction « getCover( $cover, $lang ) » ?? En même temps, si possible, envisager une augmentation de la taille de cover.jpg qui doit s'étirer sur toute l'étendue de la première page d’un PDF. L'image par défaut dans Calibre a une largeur de 600px. Merci et souhaitons que cet irritant puisse être corrigé.--Denis Gagne52 (d) 8 mars 2020 à 19:03 (UTC)
  Tpt : et   Denis Gagne52 : re-bonjour à vous deux… personnellement, je n'y connais rien, mais il semble que le problème ne soit pas simple à résoudre… avez-vous une version de test quelquepart ? merci a+ Laurent --Lorlam (d) 15 mars 2020 à 13:40 (UTC)
  Tpt : pas de nouvelles ? a+ --Lorlam (d) 28 mars 2020 à 09:36 (UTC)
  Lorlam : Dans ses commentaires à Sam Wilson datées du 3 mars,   Tpt : mentionne qu’il obtient trois images couverture dans le pdf du livre « Le Secrétaire et le cuisinier » alors que, de notre côté, on reçoit plutôt un message d'erreur « Données insuff… », la première page refusant de s’afficher sur une image en ton de gris.
La correction semble donc viser l’affichage multiple qui pourrait aussi être solutionné en modifiant le fichier « content.opf » de la façon suivante :
manifest
item id="cover" href="cover.xhtml" media-type="application/xhtml+xml" properties="calibre:title-page"
.....
/manifest
spine toc="ncx"
itemref idref="cover" linear="yes"
mais ce problème me semble différent de celui que nous avions signalé. À suivre. --Denis Gagne52 (d) 3 avril 2020 à 04:27 (UTC)
Il y a en effet deux problèmes, l'affichage multiple et le "données insuffisantes" qui affectes quelques lecteurs PDFs. Pour l'affichage multiple, je viens de déployer un correctif. Au lieu de modifier le content.opf tel que suggéré par Denis Gagne52 (merci !), j'ai remplacer le fichier cover.xhtml par l'image de couverture directement. Comme cela, il n'y a pas à jouer avec le CSS pour afficher l'image en pleine page et Calibre n'a pas la tentation de placer le fichier XHTML à la fin du PDF en croyant qu'il fait partie du contenu du fichier. Pour les données insuffisantes, merci de l'idée d'utiliser Imagic, je suis en train d'écrire un patch avec. Tpt (d) 6 avril 2020 à 10:35 (UTC)
  Lorlam :. Je viens d'écrire un correctif. Est-ce que ce fichier PDF fonctionne chez toi pour confirmer que le problème est corrigé avant que je pousse le correctif ? Tpt (d) 6 avril 2020 à 10:47 (UTC
  Tpt : oui c'est bon :-) Yessssssssssss !!!!!!!! --Lorlam (d) 6 avril 2020 à 11:33 (UTC)
Coucou   Tpt : Alors, tu as pu "pousser" ton correctif ? Y-a-t-il un lien quelquepart pour pouvoir l'utiliser en version de test ??? a+ --Lorlam (d) 11 avril 2020 à 18:59 (UTC)
  Lorlam : Le correctif est déployé sur les serveurs. Notifie moi si tu vois un problème quelconque. Désolé du temps d'attente. Tpt (d) 19 avril 2020 à 07:39 (UTC)
  Tpt : Je suis vraiment désolé… j'ai essayé d'utiliser l'export… mais pour moi ça ne marche toujours pas… en fait je ne vois aucun changement… tu es sûr que ton correctif a bien été déployé sur le serveur ??? J'ai essayé sur les pages Le Codicille et Le Mystificateur et la page de garde n'apparait pas… tu peux certainement le voir par toi même !? snif……. en espérant que ce n'est qu'un contre-temps. a+ Laurent --Lorlam (d) 19 avril 2020 à 08:50 (UTC)
  Lorlam : Désolé, il y a peut-être un malentendu. En ePub l'image de couverture extraite automatiquement du PDF/DjVu n'est pas supposée être affiché lors de la lecture mais seulement dans la navigation des liseuses, de Calibre... Le convertisseur ePub vers PDF l'ajoute en première page du PDF. La page de garde avec le moine copiste doit être la première page de l'ePub lors de la lecture et la seconde du PDF. Es-ce que tu as toujours le problème de crash lors de l'ouverture du PDF ou est-ce autre chose ? Le serveur est à jour et utilise le même code que le PDF de référence que je t'ai envoyé avec seulement une version de Calibre plus récente. Tpt (d) 19 avril 2020 à 13:12 (UTC)
  Tpt : À mon tour d’être désolé, je constate aussi que la conversion de l’image couverture ne fonctionne pas avec « Imagick::setImageDepth » comme je l’avais espéré car la profondeur est de 8 bits partout. Ce qui diffère c’est uniquement le nombre de canaux ( 1 -> 3 ). Dans ce cas, il faudrait plutôt utiliser [Imagick::getImageType] pour rechercher les images de type 2 ou « Imagick::IMGTYPE_GRAYSCALE » et les convertir en utilisant [Imagick::setImageType] avec en paramètre 6 ou « Imagick::IMGTYPE_TRUECOLOR ». --Denis Gagne52 (d) 19 avril 2020 à 13:49 (UTC)
  Tpt : Je ne pense pas qu'il y ait de malentendu… en pdf, la page avec le moine copiste apparait effectivement bien en 2e page, et la première page sensée montrer l'image de couverture issue du DjVu ne s'affiche pas… par contre il y a un message d'erreur à l'ouverture du pdf : "Données insuffisantes pour une image" (le même qu'il y a deux mois). Pourtant, le pdf que tu m'avais joins le 11 avril était "ok" => il y a donc une différence entre ces deux outils !… j'avais bon espoir que ça marche, mais ce n'est pas pas encore gagné. :-( a+ Laurent --Lorlam (d) 19 avril 2020 à 17:16 (UTC)
Re-bonjour   Tpt : c'est bon tu as pu visualiser le problème ? Apparemment tu avais pu le corriger dans un cas précis, puisque le fichier que tu m'avais transmis il y a quelques temps était "ok"… mais le soucis vient peut être des différentes versions de calibre qui ne sont pas compatibles entre elles, et qui apportent des régressions, ou du moins des fonctionnements différents !? Mais bon… je ne peux pas aider plus que ça car je ne connais rien à cet outil… je suis juste impatient de pouvoir l'utiliser   a+ --Lorlam (d) 22 avril 2020 à 17:19 (UTC)
  Lorlam : J'ai mis en place le correctif dans wexport. Il est maintenant live sur https://wsexport-test.wmflabs.org/ . Fonctionne-t-il ?   Denis Gagne52 : Merci pour le correctif ! N'hésite pas à faire des "pull request" dans le code https://github.com/wsexport/tool/ si tu en as envie. Cela serait plus que bienvenu. Tpt (d) 25 avril 2020 à 12:43 (UTC)
  Tpt : Merci beaucoup de te pencher sur le problème… celà dit, j'ai essayé d'exporter plusieurs livres en mode "pdf A5 format (in beta)"… (par exemple Le Codicille et Le Mystificateur)… et pour moi ça ne marche pas !!! :-( a+ Laurent --Lorlam (d) 25 avril 2020 à 13:33 (UTC)
  Tpt : J’aimerais bien pouvoir contribuer davantage mais ne m’y connais pas assez en PHP. Pourrais-tu apporter la modification suivante à ton correctif de ce matin: « $imagic->setImageType( Imagick::IMGTYPE_TRUECOLOR ); » au lieu de « $imagic->setImageDepth( Imagick::IMGTYPE_TRUECOLOR ); ». Merci --Denis Gagne52 (d) 25 avril 2020 à 14:05 (UTC)
  Denis Gagne52 : Merci ! J'ai apporté la modification. J'aurais dû faire attention à ce que je faisais...   Lorlam : J'ai apporté le correctif de Denis sur https://wsexport-test.wmflabs.org/ , pourrais-tu le réessayer ? Tpt (d) 26 avril 2020 à 04:48 (UTC)
  Tpt : La conversion ne se fait toujours pas. Il va falloir sortir l’artillerie lourde. Ne te décourage surtout pas. On va y arriver. Je te propose donc :
— d’élargir le filtre à « Imagick::IMGTYPE_GRAYSCALEMATTE » ou « Imagick::IMGTYPE_GRAYSCALE » ;
— on laisse tomber setImageType() qui ne semble agir que sur l’en-tête du fichier et on remplace par $imagic->transformImageColorspace( imagick::COLORSPACE_SRGB );
— prévoir libérer la mémoire après avoir sauvegardé le fichier: « $imagic->clear(); »
Tu peux me répondre sur ma page personnelle et je m’empresserai de tester. --Denis Gagne52 (d) 26 avril 2020 à 14:32 (UTC)
  Tpt : et   Denis Gagne52 : En effet ̧ça ne marche pas encore… merci à vous deux pour vos essais… et n'oubliez pas de me mettre dans la boucle si ça avance, ou si vous voulez un testeur :-) a+ Laurent --Lorlam (d) 26 avril 2020 à 21:44 (UTC)
  Denis Gagne52 : Le serveur de test a le nouveau correctif. Cela marge pour toi ? Tpt (d) 27 avril 2020 à 04:39 (UTC)
  Tpt : "Chez moi" ça ne marche pas encore… désolé… Sinon, continue à me mettre en "ping" quand tu as du nouveau, merci :-) a+ Laurent--Lorlam (d) 27 avril 2020 à 12:17 (UTC)
  Tpt : Pour ne pas décevoir   Lorlam : qui ne perd pas espoir malgré nos tentatives infructueuses, j’ai finalement installer Imagick sur mon poste de travail et mis la main sur la baguette magique pour finaliser ce travail de conversion. Sur Windows, je dois procéder par ligne de commande mais les mêmes commandes sont disponibles dans tous les environnements. J’ai testé avec l’image couverture de Le Secrétaire et le Cuisinier. La conversion sur 24 bits a réussi avec l’équivalant en ligne de commande de « Imagick::setImageType » que tu avais pourtant testé avec la bonne syntaxe. Pour m’assurer du résultat j’ai produit un pdf de l’image obtenue soit « scribe_TrueColor.jpg » et l’affichage se fait normalement. Voici quelques détails techniques qui pourraient t’être utiles.
Commandes Imagick utilisée pour la conversion et résultats obtenus
magick "scribe_Grayscale.jpg" -type "TrueColor" "scribe_TrueColor.jpg"
Magick identify –verbose "scribe_Grayscale.jpg" Magick identify –verbose "scribe_TrueColor.jpg"

Image: scribe_Grayscale.jpg

 Format: JPEG (Joint Photographic 
         Experts Group JFIF format)
 Mime type: image/jpeg
 Class: PseudoClass
 Geometry: 400x565+0+0
 Units: Undefined
 Colorspace: Gray
 Type: Grayscale
 Base type: Undefined
 Endianness: Undefined
 Depth: 8-bit
 Channel depth:
   Gray: 8-bit
 Channel statistics:
   Pixels: 226000

 Colors: 256

Image scribe_TrueColor.jpg

 Format: JPEG (Joint Photographic 
         Experts Group JFIF format)
 Mime type: image/jpeg
 Class: DirectClass
 Geometry: 400x565+0+0
 Units: Undefined
 Colorspace: sRGB
 Type: Grayscale
 Base type: Undefined
 Endianness: Undefined
 Depth: 8-bit
 Channel depth:
   Red: 8-bit
   Green: 8-bit
   Blue: 8-bit
 Channel statistics:
   Pixels: 226000
    ….
 Colors: 256
Et ma dernière proposition : soit tu procèdes par ligne de commande, solution moins élégante mais qui fonctionne ou tu persistes avec setImageType en t’inspirant de l’exemple 5 sur cette page qui décrit un subterfurge pour forcer la main au récalcitrant Imagick. Croisons-nous les doigts. --Denis Gagne52 (d) 27 avril 2020 à 21:33 (UTC)
  Denis Gagne52 : J'ai mis ta dernière proposition en place. J'espère que cela va marger maintenant   Lorlam :. Tpt (d) 28 avril 2020 à 04:47 (UTC)
  Tpt : et   Denis Gagne52 : Encore désolé, mais pour moi ça ne marche pas mieux :-( --Lorlam (d) 28 avril 2020 à 09:17 (UTC)
  Tpt : Que se passe-t-il ? Je n’arrive pas à trouver tes derniers changements sur Github. Les changements à la « branch jpeg » semblent remonter à 3 jours. Peux-tu m’orienter ? Merci. --Denis Gagne52 (d) 28 avril 2020 à 12:50 (UTC)
  Denis Gagne52 et Lorlam : J'avais oublié de pousser mes dernières modifications... J'aurais dû faire attention. Le serveur de test devrait être maintenant à jour. Tpt (d) 29 avril 2020 à 06:04 (UTC)
  Tpt : et   Denis Gagne52 : J'ai donc ré-essayé ce matin… c'est pas mieux :-( --Lorlam (d) 29 avril 2020 à 09:39 (UTC)

  Tpt : J’ai regardé les changements que tu as apportés sur Github et effectué les mêmes opérations dans Powershell en ligne de commandes. J’obtiens une image Truecolor avec un beau petit point rouge dans le coin supérieur gauche. Donc tu es vraiment très prêt du but. Je remarque que tu n’as pas intégré le début de l’exemple 5 fourni par pawansgi92 (qui est aussi actif sur Github). Peux-tu changer le début de ta fonction et contrôler avec un log autrement que les fichiers passent bien par toutes les étapes ?

		$imagic = new Imagick( $fileName );
		if  ( $imagic->getImageColorspace() == Imagick::COLORSPACE_GRAY ) {
   //  Log : Trying to convert $filename to sRGB
           $imagic->setImageColorspace( Imagick::COLORSPACE_SRGB );
       // important: HACK to force grayscale images to be real RGB - truecolor, 
       // some PDF's readers do not support "real" grayscale JPEGs or PNGs
       // special thanks to pawansgi92
   // log : Trying to Draw a red point on $filename
         etc.

Faut persister, tu vas réussir !!! --Denis Gagne52 (d) 30 avril 2020 à 01:08 (UTC)

Merci   Tpt : et   Denis Gagne52 : pour vos efforts… j'espère bien en effet que vous êtes prêts du but… Juste une question générale : je suppose que cet outil d'export est aussi utilisé dans la Wikisource anglophone… Nous sommes les seuls à avoir remonté le problème ?? En attendant, bon courage pour la recherche de solution. a+ Laurent --Lorlam (d) 3 mai 2020 à 17:23 (UTC)
  Denis Gagne52 : J'ai changé la condition en if ( $imagic->getImageColorspace() === Imagick::COLORSPACE_GRAY ) {. Le fichier est bien convertie de grayscale à srgb.   Lorlam : Est-ce que cela marche maintenant ? Tpt (d) 4 mai 2020 à 18:17 (UTC)
Merci   Tpt : Ben… je regrette vraiment, mais… non !!! :-(   Denis Gagne52 : Tu vois quelquechose ? a+ --Lorlam (d) 4 mai 2020 à 19:08 (UTC)
  Tpt : Selon ce que je vois sur Github, tu as effectivement changé la première ligne mais pas la suivante : « $imagic->setImageColorspace( Imagick::COLORSPACE_SRGB ); ». Donc le code ne reproduit pas tout à fait ce qui est illustré dans l’exemple et l’image ne s’affiche pas. --Denis Gagne52 (d) 4 mai 2020 à 19:14 (UTC)
  Denis Gagne52 :. En effet, je n'avais pas fait attention au fait qu'il y a deux fonctions différentes. C'est corrigé. Tpt (d) 5 mai 2020 à 05:57 (UTC)
  Tpt : et   Denis Gagne52 : Désolé je n'ai pas vu tout de suite le message… malheureusement, il doit y avoir autre chose, car l'image ne s'affiche pas encore sur la page de garde du pdf… a+ --Lorlam (d) 6 mai 2020 à 07:07 (UTC)
  Denis Gagne52 : J'espère encore… toi qui a l'air de t'y connaître, tu n'a plus d'idée de ce qu'il est possible de faire ? a+ --Lorlam (d) 8 mai 2020 à 14:51 (UTC)
  Lorlam : Désolé du retard à te répondre. Je ne vois rien à modifier dans ce que   Tpt : a inscrit sur Github. J’ai testé Imagick en mode « ligne de commande » et la conversion a réussi. Il faudrait que je le fasse aussi en utilisant PHP mais cela implique une autre installation sur mon poste de travail. Le temps me manque pour le moment. Tpt est-ce que les contrôles post-installation de Imagick sur le serveur de test ont été concluants ? Je ne comprend pas que le jpg nous revienne sans le moindre petit changement et qu’aucune erreur ne soit signalée. --Denis Gagne52 (d) 15 mai 2020 à 00:15 (UTC)

  Tpt : et   Denis Gagne52 : Bon… pas de solution ? même pas celle de revenir à ce qui marchait bien "avant" ?… a+ Laurent --Lorlam (d) 18 mai 2020 à 21:40 (UTC)

  Lorlam : Bon voilà ! Le lecteur PDF que nous utilisons pour la plupart n’accepte pas les images 8 bits, il gère mal les images 32 bits qu’il pivote de temps à autres. À l’occasion, il tranche en deux la dernière ligne de caractères au bas des pages. Revenir en arrière n’est définitivement pas une solution, il faudrait plutôt encourager l’utilisation d’un autre format que le PDF. Entre temps voici comment régler le premier problème constaté.   Tpt : N’ayant pas trouvé de solution simple sur le WEB, j’ai tenté l’approche « ouvrir… et sauvegarder sous… » et la conversion réussit. Salutations à vous deux.

<?php

   // Fichiers  source et destination
     $originalFileName    = 'D:\Outils\Script\Scribe_08bits.jpg';
     $destinationFileName = 'D:\Outils\Script\Scribe_24bits.jpg';
   // chargement de l’image en mémoire
     $sourceImage = imagecreatefromjpeg($originalFileName);
   // lecture de ses dimensions
     $img_width  = imageSX($sourceImage);
     $img_height = imageSY($sourceImage);
   // création d’une image couleur ayant les mêmes dimensions
     $destinationImage = ImageCreateTrueColor($img_width, $img_height);
   // copie de l’image dans son nouveau contenant
     imagecopy($destinationImage, $sourceImage, 0, 0, 0, 0, $img_width, $img_height);
   // sauvegarde de la nouvelle image sur disque
     imagejpeg($destinationImage, $destinationFileName);
   // libère la mémoire
     imagedestroy($destinationImage);    
     imagedestroy($sourceImage);

?> --Denis Gagne52 (d) 27 mai 2020 à 18:44 (UTC)

Re-bonjour   Denis Gagne52 : Je ne comprend pas de quoi tu parles avec l’approche « ouvrir… et sauvegarder sous… »… tu proposes une astuce de traitement de l'image lors de l'export ? Si ça donne le résultat escompté, ma fois, pourquoi pas ? Mais bon… personnellement je n'y connais rien dan ce domaine…
Concernant l'utilisation d'un autre format que le "pdf", je sais bien que le "epub" a plus la côte maintenant pour les ebooks, mais le "pdf" reste tout de même un format standard pour les documents… a+ Laurent --Lorlam (d) 28 mai 2020 à 20:16 (UTC)
Bonjour   Lorlam : Jusqu’à présent je n’avais fourni que des pistes de solution à Tpt sans avoir pu les tester. J’ai donc installé PHP sur mon ordinateur et réalisé que la librairie standard GD2 qui vient automatiquement avec PHP permet d’effectuer la conversion nécessaires pour compenser le bug du lecteur Acrobat. Il est important de préciser que c’est Acrobat qui est à l’origine de ton problème et nullement l’outil rédigé par Tpt. Je n’ai rien contre le format PDF mais si on souhaite exporter dans ce format, il faudra rédiger des documents qui tiennent compte de ses limitations. Quoiqu’il en soit le code que j’ai fourni permet de produire avec PHP 7.4.6 une image 24 bits qu’Acrobat sera en mesure d’afficher. --Denis Gagne52 (d) 28 mai 2020 à 21:11 (UTC)
re-Bonjour  Tpt : et   Denis Gagne52 : : et du coup… il est possible de mettre en place ces solutions dont parle Denis dans l'outil d'export ??? a+ Laurent --Lorlam (d) 2 juin 2020 à 23:14 (UTC)
  Denis Gagne52 : Denis, saurais tu expliquer en quelques mots (plus techniques que moi) ce que tu as compris du problème d'export de l'image de première page, suite aux tentatives que vous avez essayé de faire avec Tpt… sur la page https://meta.wikimedia.org/wiki/Talk:Community_Tech/Ebook_Export_Improvement
si on peut avoir de l'aide de l'équipe technique Wikimedia, c'est toujours bon à prendre, a+ Laurent --Lorlam (d) 26 juin 2020 à 12:12 (UTC)
Bonjour   Lorlam :, Tpt a déjà fait part sur Github de cette rebuffade d’Acrobat qui s’attend à recevoir une image couleur puisque Calibre lui a accolé l’étiquette DeviceRGB au lieu de DeviceGray. L’équipe technique peut prendre connaissance du traitement déjà prévu dans Ws-Export pour convertir les images « Grayscale » en image « True Color » et ainsi contourner ce problème. En remplaçant le code par celui que j’ai testé ou par celui qui leur conviendra, cela va régler la question. --Denis Gagne52 (d) 26 juin 2020 à 14:51 (UTC)
  Denis Gagne52 : Ok parfait, a+ --Lorlam (d) 26 juin 2020 à 15:53 (UTC)

AstérismeModifier

Bonjour, Il semblerait que le "fs" dans l'Astérisme ne fonctionne pas. Merci de votre intervention.--Kaviraf (d) 4 février 2020 à 08:29 (UTC)

Cela fonctionne, mais sous cette forme : {{***|200%}} --Acélan (d) 4 février 2020 à 09:40 (UTC)
Merci   Acélan :--Kaviraf (d) 4 février 2020 à 09:53 (UTC)
{{Astérisme|200%}} "marche" aussi. --*j*jac (d) 4 février 2020 à 12:08 (UTC)
Oui, j'ai remarqué qu'avec "200%" l'astérisme fonctionne sans toutefois montrer sa réelle valeur, mais on ne peut pas moduler le "fs". On s'en contentera donc. Merci à vous deux. :))--Kaviraf (d) 4 février 2020 à 15:33 (UTC)

  Kaviraf : Je ne sais pas si j'ai bien compris mais sache qu'on peut faire varier la valeur de grandissement :

150%
200%
350%

--*j*jac (d) 4 février 2020 à 17:16 (UTC)

Merci  
  • j*jac : de porter intérêt à ce questionnement. Oui, j'ai tout à fait compris qu'il fallait moduler la valeur du "fs". Toutefois, sur mon ordinateur, il n'y a que "200%" qui fonctionne. Snif... --Kaviraf (d) 4 février 2020 à 19:32 (UTC)
  Kaviraf : Tu as essayé avec d’autres navigateurs ? V!v£ l@ Rosière /Murmurer…/ 14 février 2020 à 03:36 (UTC)

Nouveaux messages d'erreur pour l'attribut "follow" dans les balises référenceModifier

Bonjour à toutes et à tous,

De nouveaux messages d'erreur ont été ajoutés pour les cas où l'attribut "follow" est incorrectement utilisé dans la balise <ref>.

L'attribut follow dans la balise <ref> permet aux utilisateurs de fusionner des documents sources qui s'étendent sur plusieurs pages. Il a été utilisé pour la première fois sur la Wikisource en français et n'existe que sur Wikisource. Il fonctionne ainsi : vous pouvez fusionner le contenu de deux références en une seule note de bas de page, par exemple : <ref name="a">Texte pour la source 1</ref> [...] <ref follow="a">Texte pour la source 2</ref>. Dans la section de références, la note de bas de page sera affichée comme ceci : Texte pour la source 1 Texte pour la source 2. Vous trouverez plus d'informations sur cet attribut ici.

 
Message d'erreur pour l'attribut "follow".

Pour que l'attribut follow fonctionne, il est important que l'attribut name de la référence soit défini dans le texte avant que l'attribut follow ne soit appelé. Malheureusement, si ce n'est pas le cas, la référence figurera en haut de la liste des références, sans marqueur de note de bas de page et sans lien avec la précédente référence qu'elle est censée suivre. Auparavant, il n'y avait pas de message d'erreur pour ce cas de figure. Cela va bientôt changer : pour améliorer l'intégration à l'extension Cite, un message d'erreur sera affiché pour ce cas (voir l'image ci-jointe). Si vous voulez trouver toutes les pages de votre wiki qui utilisent l'attribut follow, vous pouvez utiliser cette requête.

Ce changement a été réalisé dans le cadre du développement de l'attribut extends, ce qui a amené l'équipe Technical Wishes de WMDE à retravailler de grandes parties de l'extension Cite. Le nouveau message d'erreur sera activé le 5 février.

Si vous souhaitez en savoir plus sur ce changement, vous pouvez trouver des informations plus détaillées dans ce ticket Phabricator : T240858. Si vous avez des questions ou remarques, n'hésitez pas à nous en faire part sur cette page (en anglais ou en français, comme vous préférez).

Pour l'équipe Technical Wishes de WMDE, Max Klemm (WMDE) (d) 4 février 2020 à 11:45 (UTC)

Informations actuelles : Il n'y aura pas de nouveaux messages d'erreur après tout.Modifier

Contrairement à ce qui a été annoncé, le changement ci-dessus n'aura pas lieu. Il y a un risque qu'à la suite de ce changement, des messages d'erreur soient affichés sur de nombreuses pages Wikisource, même s'il n'y a pas d'erreur. Vous trouverez de plus amples informations sur Phabricator (T240858). Un grand merci à tous ceux qui l'ont remarqué !
À l'heure actuelle, on ne sait pas si le changement annoncé peut être supprimé de l’actualisation générale du logiciel (prévue pour ce soir) ou si l'équipe des Technical Wishes de WMDE le supprimera rapidement par la suite. -- Pour l'équipe Technical Wishes de WMDE, Max Klemm (WMDE) (d) 5 février 2020 à 10:52 (UTC)

  Max Klemm (WMDE) :J'ai regardé un texte que j'ai corrigé et qui comporte des milliers de notes, souvent courant sur plusieurs pages comme Page:Taine - Les Origines de la France contemporaine, t. 2, 1910.djvu/140 et le problème est bien présent alors que la syntaxe me semble correcte. Je ne me vois pas reprendre les 11 volumes des Origines (6 mois de travail de correction), + les 7 volumes de L’Histoire de l’Affaire Dreyfus qui comprends également des milliers de notes, pour corriger des notes sans même comprendre comment il faut faire pour que cela fonctionne (la page en anglais citée plus haut est loin d’être explicite pour moi - faut-il mettre la partie de la note follow, sur la même page que la partie name ? à ce moment cela ne correspond plus au fac-similé. Bref que doit-on faire concrètement pour les ouvrages déjà corrigés et parfois validés ? En tout état de cause, il me semble essentiel de sécuriser le travail réalisé par les contributeurs sous peine de les décourager et de les faire fuir.--Cunegonde1 (d) 6 février 2020 à 06:55 (UTC)
  Cunegonde1 : Bonjour et merci pour la réponse. Le changement annoncé ci-dessus n'a pas été mis en œuvre à court terme, il n'y a donc pas de nouveaux messages d'erreur et il n'est donc pas nécessaire d'ajuster les pages avec l'attribut follow du côté communautaire. Ou bien quelque chose a changé sur vos pages après tout ? Il serait alors très utile que vous puissiez décrire cela plus en détail. En plus, puis-je vous demander de laisser votre réponse sur cette page centrale ? Nous y recueillons tous les commentaires afin que rien ne nous échappe. -- Salutations distinguées, Max Klemm (WMDE) (d) 7 février 2020 à 08:38 (UTC)
  Max Klemm (WMDE) : Le message d’erreur apparaît toujours à la place de la seconde partie de la note introduite par follow à la page mentionnée plus haut Page:Taine - Les Origines de la France contemporaine, t. 2, 1910.djvu/140, alors qu’elle apparaît correctement reconstituée dans l’espace principal Les Origines de la France contemporaine/Tome 2/Livre IV/Chapitre 2, p. 123 n. 4. Je comprends que l’erreur ne devrait plus apparaître dans les nouvelles notes, mais quid des milliers de notes affectées par le problème et qui apparemment ne sont pas réparées ? Cordialement.--Cunegonde1 (d) 7 février 2020 à 08:52 (UTC)


Affichage chamboulé des numéros de page pour certains textes transclusModifier

Bonjour,

Peut-être que le sujet a été traité ou est en cours de traitement quelque part déjà (désolé du coup si c'est le cas), mais j'ai remarqué que, pour certaines pages, l'affichage des numéros de page de textes transclus qu'on peut retrouver à gauche des textes est tout chamboulé. Par exemple ici, ou encore . Le seul point commun que je leur ai trouvé est l'utilisation des modèles Bloc centré/o et Bloc centré/f mais ce n'est cependant pas forcément une bonne piste n'ayant moi-même qu'une connaissance superficielle là-dedans. Quelqu'un aurait une idée ?--Gwendal (d) 1 avril 2020 à 15:06 (UTC)

  Gwendal : Le problème est discuté ici: Scriptorium. BrainslugClaptrap (d) 8 avril 2020 à 10:44 (UTC)

Années précédentesModifier

Voir ici.

Remarques : 1. Les catégories affichées au bas de la page d'archives sont fautives.

2. L'ordre chronologique inversé a cédé la place à l'ordre chronologique tout court, date incertaine.


Small caps dans le CSS mobileModifier

Bonjour, j’utilise Firefox Android pour accéder à Wikisource. J’ai vu que le modèle {{sc|}} n’était pas rendu avec le thème mobile : les lettres apparaissent en minuscules plutôt qu’en petites capitales. Voir par exemple cette page, dont le texte « Victor Hugo » est bien rendu dans la version bureau, mais pas dans la version mobile.

La classe CSS .sc n’est pas définie dans la feuille de style mobile. Où dois-je m’adresser pour rapporter ce problème ?

(J’ai déjà ouvert ce sujet ici, mais la page n’a pas été mise à jour depuis plusieurs années et je ne sais pas si elle est active.)

--Maulor (d) 4 avril 2020 à 10:40 (UTC)

  Maulor : bonsoir ! Je vous conseille d'ouvrir directement un sujet dans le Scriptorium, c'est le meilleur moyen de trouver un interlocuteur. Les pages plus spécialisées sont assez peu suivies. --Jahl de Vautban (d) 4 avril 2020 à 18:30 (UTC)

Problème réglé suite au message sur le scriptorium. VIGNERON (d) 7 avril 2020 à 13:50 (UTC)