Depuis pas mal de temps, nous assistons à un retour de l’image en noir et blanc. Certains vont même jusqu’à modifier leur boîtier numérique professionnel (merci Franklin) pour ne fournir que des images dans cette veine.

Plus sobrement, quelques applications sur iPhone ou iPad procèdent de même et donnent d’excellents résultats.

Pour ma part, faute de mieux, j’apprécie de disposer de l’image source en couleurs (…et captée au format RAW par mes antiques reflex) puis la basculer en .jpg en noir et blanc via Lightroom si besoin est…

Optimisé hier pour OSX 10.9.x, Dramatic Black & White 2.05 (lien AppStore) s’avère hyper simple à employer… Et, surtout, permet de créer et conserver ses propres sets. Bref, au lieu de payer un abonnement couteux et/ou d’utiliser une application lourde, pourquoi ne pas viser des produits à des prix nettement plus abordables …?!

En partant d’une image récente enregistrée au format JPG, très facile de la basculer en noir et blanc avec la batterie de filtres proposés…

Sans oublier la possibilité de gérer son traitement au petit poil…

Et d’enregistrer ce set pour un usage ultérieur…

Notez sur les réglages sont faciles d’accès et simples à ajuster…

À 5,49 €, pas réellement l’impression de se ruiner. Plus d’informations sur le site du développeur… À noter qu’une version iPad est disponible.

Retour sur mon billet de ce midi… Je suis de plus en plus dubitatif face à la mise en oeuvre de CriticMarkup… ça se sent dans ce billet.

Je suis convaincu que Writer Pro va intégrer des options de CriticMarkup ou similaires… Quasiment tous les outils Markdown habituels pèchent — à mes yeux — sur ce plan.

Néanmoins, j’espère y découvrir une option que nombre de développeurs oublient, celle qui consiste à conserver dans le texte de labeur (…l’équivalent du Code Source…!) tous nos repentirs (annotations, suppressions, substitutions, notes, etc.).

En proposant un export — depuis ce texte de labeur — d’un fichier temporaire au format Markdown prenant en compte ce qui est validé en terme de suppressions et de substitutions, voire d’annotation et/ou de commentaire mais débarrassé de toutes ces hésitations balisées qui n’appartiennent qu’à l’auteur…? Or cela existe ailleurs…!

Tout unifier sous Ulysses…?

Le seul outil à me rendre ce service est Ulysses III sous OSX. Sauf que je ne l’utilise que pour mon flux de travail privé… Dois-je, dès lors, cesser de bosser avec MultiMarkdown Composer, avec Byword et compagnie…?

Voire oublier carrément CriticMarkup…? Je reste persuadé que Marked2 comme MultiMarkdown Composer font ajouter ces options. Pour l’heure, c’est agaçant car on sent bien qu’il y a un questionnement sur ce point.

Là, mon billet sous Ulysses III est rempli d’annotations… Il me suffit de l’exporter en Markdown depuis Ulysses III et, hop, un fichier neutre avec mes choix du moment…

À gauche, le texte original sous Ulysses III et à droite l’export depuis ce dernier vers Byword (…ou un autre traitement de texte Markdown) SANS les commentaires et en prenant en compte les Markers à base de simples ++ ou ||, ::… Bref, et si c’était simplement ça un bonne solution…? Je me répète, je sais.

À suivre

Divagations personnelles autour du Markdown et des extensions qui s’échafaudent… Billet pénible…!

La version 2.6.2 de MultiMarkdown Composer (lien iTunes) sous OSX est sortie hier et, a priori, pas de quoi fouetter un chat…

Erreur…!

Si vous lisez bien les informations à propos de cette mise à jour, vous avez noté comme moi le Rename “Mark for CriticMarkup” to “Highlight for CriticMarkup” and change key shortcut (⇧⌘H) et, surtout, le Add “Insert CriticMarkup Note” menu command (⇧⌘N), deux changements qui ne vous ont pas échappé… Entre autres.

Que vous pouvez modifier, CQFD…

Pour ma part, c’est ce dernier point qui m’interpelle car ce n’est pas hier matin que CriticMarkup s’est invité dans ce traitement de texte. La possibilité d’ajouter des informations dans mon texte Markdown en cours d’écriture est un plus.

Texte balisé et rendu en mode Changed Version…

J’utilise MultiMarkdown Composer sur mon Macintosh pour des tas de raisons qui vont de l’affichage du rendu quasi définitif de ma saisie (…avec l’option Changed Version dans la fenêtre de prévisualisation, cf. Copie d’écran précédente). Ou encore du collage de lien (URL) implicite sur sélection de texte qui me fait gagner un temps appréciable.

La vraie question que je me pose (…et se la poser est déjà y répondre…) est sur l’intérêt d’ajouter ce @jcc et la date et heure à chaque action. Après une nuit de réflexion, étant seul à écrire, ce dispositif n’a pas de sens sauf en cas d’écriture collaborative. Dont exit.

En effet, MultiMarkdown Composer possède un panneau Show Change Panel (⇧⌘V) mais il est clair que sa lecture est brouillée avec ces options qui et date…

Et donc, dans mon workflow perso…

Sans ces notes, c’est plus clair à mes yeux…

CriticMarkup se diffuse peu à peu…

CriticMarkup commence inexorablement à rentrer dans les applications ainsi notamment dans la version 2 de Marked — cf. Le lien vers le site de cette application.

Rappel : la version 2 de Marked n’a plus grand chose à voir avec la version 1 toujours disponible sur l’AppStore.

Il est vrai que chaque équipe de développeurs a tendance à mettre en place ses propres balises (…relire cette autre chronique sur urbanbike).

Mais, peu-à-peu, cet ensemble de balises dédiées à la correction CriticMarkup semble prendre sa place et à se retrouver dans des applications Markdown ou MultiMarkdown. Et son usage est loin d’être inintéressant même si des solutions comme l’excellent Draft Control (voir cette chronique sur urbanbike) se multiplient…

Au début, je me suis pas mal mélangé les pinceaux et quelques échanges par Mail avec Fletcher m’ont convaincu que je faisais fausse route et, surtout, que je devrais apprendre à m’en servir de manière plus précise.

Ensuite, si les deux commandes indiquées sont pratiques, c’est plus les options de substitution qui me semblent clés et méritent du coup quelques équivalents, non dans Raccourcis mais bien dans TextExpander.

Idem, partie à sauter si pas utilisateur de TextExpander…

L’idée est d’emblée d’associer à chaque option une note %snippet:,kn% en y associant un snippet qui fait appel à l’équivalent…

Sauf que…! À l’usage, c’est bien encombrant (voir plus haut)…

Et du coup, j’ai viré tous les snippets Qui + date, ajouté juste une version plus light de cet ajout de note avec balises CriticMarkup… D’ailleurs, décision qui reprend de précédentes réflexions…! Oui, je tourne parfois en long…

Alors, fort de tout cela, MultiMarkdown Composer permet d’écrire et de réviser son texte, avec les simples commandes du traitement de texte ou en associant ses propres équivalents forgés à ses besoins dans TextExpander.

…Et Marked2 dans tout ça…?

Mais le plus intéressant reste l’emploi concomitant de Marked2 qui intègre les mêmes options et permet de voir en situation le résultat de ces repentirs… Certes, MultiMarkdown Composer le permet aussi (et c’est un mode efficace en relecture) mais je lui préfère Marked2 qui fait appel à une CSS proche du résultat final.

En appelant Marked via (⌥⌘P)…

Il est possible de voir en rose les termes avant substitution et en vert, ceux après… Ou opter pour deux autres affichages…

Avant corrections, après corrections (rendu final)

Pas clair…? Hop, résumé…!

Enfin, et c’est bien entendu la force de Marked2, des tas d’options (j’y reviendrais car cela a pas mal bougé depuis le toute première présentation du produit — relire cette chronique sur urbanbike) en bas de fenêtre.

Dont…

L’accès au sommaire ou aux options d’export du fichier ainsi traité.

Il me manque une option très simple, celle de l’export du fichier en… Markdown et/ou MultiMarkdown… Mais débarrassée de toutes les balises et notes CriticMarkup par reconnu partout.
Pourquoi…? Mais pour exporter mon texte markdowné (sic !) tout propre dans un blog sans utiliser du HTML mais bien du Markdown. CQFD.

…Et sous iOS ?

Pour le moment, rien. Mais rien ne vous empêche d’employer vos équivalents dédiés via TextExpander.

Sauf que je suis convaincu (…avec 99 % de chances de me tromper…!) que nombre de développeurs bossent sur de nouvelles versions de les traitements de texte avec l’idée à terme d’intégrer des options CriticMarkup ou, en tous cas, dans le même esprit…

Et c’est pourquoi j’attends la version Pro de iA Writer de main ferme…! Entre autres…! La version 1.7 de Daedalus touch (mais plus une 2.0) devrait ajouter ce même type de balisage mais à la sauce Ulysses III.

Et c’est là le risque, se retrouver face à des options étendues du Markdown qui ne soient pas standards entre traitements de texte Markdown… Un comble…

À suivre…

Note de fin… Je ne me relis pas, là c’est une note de faim… Faut que j’aille faire quelques courses…!!

Tu termines à peine ton billet et tu trouves que tout cela est quand même un poil lourd…

Il manque une option d’export dans un second fichier MultiMarkdown en prenant en compte ces ajouts, suppressions et substitutions de manière automatique et sans les notes CriticMarkup…!

Sauf que cela ne fonctionne pas de manière simple… Même avec Marked2 puissant mais lui-même, etc.

Deux solutions ?

En désespoir de cause, on en revient à des trucs simples…

Première option

• exporter depuis MultiMarkdown Composer le fichier dans un nouveau fichier .md avec une nom clair (genre -notes en sus)
• Éditer le fichier en cours via le panneau Show Change Panel (⇧⌘V) en validant ce qu’il y a à valider…
• Enregistrer et employer cette version clean

Mais un dispositif pour exporter directement une version Changed Version allégée depuis le fichier bourré de notes CriticMarkup me semble nettement plus simple…

Seconde option

Bref, après tout cela, je me dis que l’on est en train de réinventer l’usine à gaz et j’en reviens au <!-- commentaire --> qui lui reste en place sans souci.

Bon, j’attends des outils pensés pour les auteurs et pas des trucs de dév…