HackMD, à vos souhaits…

En fait c’est un éditeur de texte…

Sauf que c’est du Markdown, et en mode collaboratif simultané, et enrichi…

HackMD - HackMD

HackMD

C’est quoi ?

C’est un éditeur Markdown

• C’est super ces informaticiens, quand ils répondent aux questions… On comprend rien aux réponses !

Markdown ? kezako ?

C’est une façon de rédiger du texte enrichissable (mise en page, titres, caractères gras, italique, etc…) à partir d’un simple ‘texte’, avec un ‘Notepad’ (si t’es Windows, si t’es Mac, tu peux pas comprendre un fichier texte simple…)

On parle d’un fichier texte ‘plat’, comprenant des marqueurs simples pour indiquer à l’interpréteur d’affichage, de changer pour afficher “enrichi”, le texte simple

(et je peux inclure des images)

C’est le même principe que le Postscript (PDF) ou le language HTML (web). Et donc le même texte peut être affiché sur n’importe quel système, équipé d’un interpréteur Markdown…

HackMD, permet d’éditer à plusieurs dans le Cloud (comme Google docs)

OK, cela amuse les Geeks alors, plus simple de faire avec mon Wordpad! C’est quoi l’intérêt?

Si je prends les 989 caractères nécessaires pour faire le texte ci-dessus (sans les images, lien externe).

Extrait en MarkDown:

Le fichier RTF sans les images, comprenant uniquement le lien comme ici, pèsera 1759 caractères.
Et commence déjà à être nettement moins lisible vu comme ‘texte plat’

Format RTF: {\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang4108{\fonttbl{\f0\fnil\fcharset0 Calibri;}}
{\colortbl ;\red0\green0\blue255;}
{*\generator Riched20 10.0.15063}\viewkind4\uc1
\pard\sa200\sl276\slmult1\b\f0\fs28\lang12 HackMD\par
\fs24 C\rquote est quoi ?\par
\b0\fs22 C\rquote est un ‘e9diteur Markdown\par
C\rquote est super ces informaticiens, quand ils r’e9pondent aux questions’85 On comprend rien aux r’e9ponses !\par
\b\fs24 Markdown ? kezako ?\par

Le même fichier en format ‘docx’ pèsera 19181 cacacères (octets), sans plus d’image… Quand au contenu, il est encore plus “hermétique”, quoique dans le “standard” docx…

Format DOCX: (non il n’y a pas de bug sur l’affichage ci-dessous)
PK  ! «/,f T  [Content_Types].xml ¢( ´”ËnÂ0E÷•ú–·Ub袪‹>–-Ré{Vý’m^ß1¨ª€H6‘’™{ï™$žÁhm4YBˆÊÙŠöË%…“ÊÎ*ú5y+)‰‰[ɵ³PÑ D:ÞÞ &‘ ÚÆŠÎSòOŒE1Ãcé<X¬Ô.žð6̘çâ›Ï€Ý÷zL8›À¦"e:¼@Í:‘×5>nHÀÔ”<7}9ª¢ÊdýºÈvP@Ç?"î½V‚'¬³¥•ÈŠU‰ÊmOœ+ï°áHB®Øé>ðu%ŒyHïÜ[¹ ™tbaPYž¶9ÀéêZ hõÙÍ’ FüNF—mÅpe÷üG9bÚhˆ—§h|»ã!%\ç܉°‚éçÕ(~™w‚Ô˜;áS —Çh­;!žZh®ý³9¶6§"±sœ¸Â?ÆÞÙ¬.p!©Ó]›ˆÖgÏyH²Ùv’ ÿÿ PK  ! K E¸þ Þ _rels/.rels ¢( ¬’ÛJ1@ßÿ!Ì{7Û"Òl_Dè›Èúc2»Ü\H¦Úþ½A¼-¬E°s;œIf½Ù»Q¼PÊ6x˪A^c}¯à±½[\ƒÈŒÞà<)8P†Ms¶ ¹ åÁÆ,

Si je rajoute les 2 images, qui totalisent 115’218 octets. J’ai un docx de 231’503 octets, pour un Markdown qui lui va occuper 116’207, on passe juste du simple au double !

PDF

Si je change pour faire du PDF, c’est 714 148 octets, 6x plus ! Mais pour l’image, il y une bien meilleure compression… 7217 octets en mode “low def” (mauvaise qualité), mais c’est assez pourri, quoique, encore lisible…

Mais en format HD, l’image est tout à fait acceptable à l’écran:

Version meilleure définition, avec une excellente compression quasi x3 !

Format PDF:
%PDF-1.7
%µµµµ
1 0 obj
<</Type/Catalog/Pages 2 0 R/Lang(fr-CH) /Metadata 51 0 R/ViewerPreferences 52 0 R>>
endobj
2 0 obj
<</Type/Pages/Count 1/Kids[ 3 0 R] >>
endobj
3 0 obj
<</Type/Page/Parent 2 0 R/Resources<</Font<</F1 5 0 R/F2 9 0 R/F3 14 0 R/F4 19 0 R/F5 21 0 R/F6 23 0 R/F7 25 0 R/F8 30 0 R>>/ExtGState<</GS7 7 0 R/GS8 8 0 R>>/XObject<</Image32 32 0 R/Image33 33 0 R>>/ProcSet[/PDF/Text/ImageB/ImageC/ImageI] >>/MediaBox[ 0 0 612 792] /Contents 4 0 R/Group<</Type/Group/S/Transparency/CS/DeviceRGB>>/Tabs/S>>
endobj
4 0 obj
<</Filter/FlateDecode/Length 2078>>
stream
xœµZIoÜ6¾˜ÿ £tT®” *챝¶@P´5ÐCÓƒ‘N 7[ãhÑ_ßÇÇíI#y‘fäÅ·o¡>nŽXËüŸã¢bUŸÆ‰êv¿9úíYõ~stz¹⁹úö‚W¼«._oŽ8,b¯d×2¡+#lëtuù=ÿÕTןü†ÜªŠµR8øÔÖV·×xÛÎÜþåùæè÷úûf«ë«WÍÖÕoU¿8kþ¨.ܝ?oŽ>.åÔ3àtšÁ9¾ªe|ˆuN/âã˜1.zṳ>í·ðÍùy¿ÕðíXÏ…ÿ>é·n0&{ÿ[XÇ\œêxaÎú­ƒo}†‹àRª³~5sÎ[¾Xº¥Z–@wRËƵJ>*O¶*:Ür´(hÑ_ßÇÇíI#y‘fäÅ·o¡>nŽXËüŸã¢bUŸÆ‰êv¿9úíYõ~stz¹⁹úö‚W¼«._oŽ8,b¯d×2¡+#lëtuù=ÿÕTןü†ÜªŠµR8øÔÖV·×xÛÎÜþåùæè÷úûf«ë«WÍÖÕoU¿8kþ¨.ܝ?oŽ>.åÔ3àtšÁ9¾ªe|ˆuN/âã˜1.zṳ>í·ðÍùy¿ÕðíXÏ…ÿ>é·n0&{ÿ[XÇ\œêxaÎú­ƒo}†‹àRª³~5sÎ[¾Xº¥Z–@wRËƵJ>*O¶*:Ür´(j5¸å.¨ÔКà^k]¸‹¿ Xê•ÍOâ# Kÿ˜q/x ÷µ»l

Sans parler du format RTF: Les images embarquées ne peuvent pas être encodées au format compressé JPEG, alors le fichier fera: 2’645’437 octets, soit un facteur plus de 20 fois…

Super ! C’est écologique, et alors ?

• Et bien l’infobésité est un vrai fléau, le Cloud consomme plus de 1,5 x le traffic aérien planétaire!
• Ensuite, c’est plus rapide à charger, surtout sur un réseau mobile.
• Enfin, c’est universel; même si on peut encore avoir des surprises sur l’encodage des accentués… (pas encore au point tout cela !)

Mais du coup, on peut comprendre que cela puisse intéresser et envahir les milieux Wikipédiens, universitaires (supporte les formats et formules scientifiques LATEX), tout comme les développeurs, car c’est plus simple que de passer par un générateur html…

Mais au fait et en html ? Le dossier des images, est répété en preview et full, pèsera 318’960 octets, et la page html 48’992 octets, quand même ! (J’ai généré le HTML depuis Windows, donc on pourrait optimiser largement le code, et diviser par 2, ou 3)

Version HTML:

J’ai réduit l’en-tête, car la première apparition d’un truc lisible, c’est à la 888ème ligne!

ODT

Ceci est le format proposé par Microsoft au départ, mais très vivement découragé, car limitatif aux formats DOCX ! Mais est-ce volontairement, ou est-ce justifié ? De part mon expérience personnelle, je doute très fortement!

• ODT est le format ouvert proposé par LibreOffice et OpenOffice: Et supporté par de nombreux autres, dont Microsoft.

C’est aussi du XML comme DOCX… La partie texte sera plus optimisée, avec 13'723 octets, soit plus de 5'000 de plus que DOCX. Les images sont moins optimisées toutefois…

PK ڮЊ^Ʋ ‘ ‘ mimetypeapplication/vnd.oasis.opendocument.textPK ڮЊ  Configurations2/progressbar/PK ڮЊ  Configurations2/menubar/PK ڮЊ  Configurations2/popupmenu/PK ڮЊ  Configurations2/statusbar/PK ڮЊ  Configurations2/toolbar/PK ڮЊ  Configurations2/images/Bitmaps/PK ڮЊ  Configurations2/accelerator/PK ڮЊ  Configurations2/floater/PK ڮЊ  Configurations2/toolpanel/PK ڮЊ
styles.xmlЛ6߿ÐһԥЍϽڴ!@ѠI 4ه{*hɲڐÀRk;}ǟ¾݊v{wٛh`Ώ܏ΌgH涏烎0ĕ��ɦٌYF˃}􏏿ȷҏo��9I񮣩]ᓆB^(3ٜʝ!߇5/w “v%*јʴǪ\ۉېޓ͌ɞl봍gK|ד’+lk.ۏ筁⬌ēՉ
6
ȧl뤳qϢԕҤ#řӲ̽tԲڥʩtڟ׳Əʲܝ&۪N=Ϊ9ը,M0Ŋڈ׳eⰅר˼

Récapitulons

Une petit visuel, toujours plus explicite

Si on ne prend que la partie texte, le format PDF est le sommet de la consommation, mais il sera capable d’imprimer le texte sur un poster A0 sans broncher. C’est toutefois vrai aussi avec les autres formats, qui sont capable de générer un document ‘rastérisé’ en haute définition.

Mais si on veut intégrer les images, qui sont aussi à prendre en compte, il faut ajouter les 2 fichiers JPG des copies d’écrans…

Voici la capture de l’écran, faîte en GIF

On voit que le même le format RTF, va occuper un petit peut plus que MarkDown.

Par contre, si on y intègre une image, celle-ci est ‘rastérisée’ en ‘bitmap’, car RTF ne gère pas les formats compressés. Le résultat explose alors tous les compteurs!

Mais ce qui est ‘rigolo’, c’est que si je capture le texte et les images, comme une seule image, ci-contre, un scan: Je peux alors convertir l‘ensemble comme une image, sans aucun texte (scan).

A ce moment-là le grand vainqueur n’est pas JPEG, mais GIF…

A partir de MHT, nous n’avons plus de texte, tout est rastérisé (scan)

Si je dois faire des archives de document scannés, je peux donc utiliser PDF ou plus efficacement le format GIF, pour gagner du volume. On peut supposer que JPEG avec des options max de compression, obtiendra un ratio similaire.

Mais attention: Le texte inclus n’est plus indexé, contrairement avec les formats ‘textes’, les mots ne sont plus…

HackMD - Collaborative markdown notes