HUB text/PAO une syntaxe pour différentes cibles input et output (backends, targets ou writers), de manière à obtenir du HTML du LaTeX, page de man: pandoc

hexadécimal

Au départ si on a que du texte sans mise en forme, on peut écrire en hexadécimal comme dans ma jeunesse des années 70 (en ASCII ou étendue pour les caractères français par exemple). Il suffisait de connaitre par coeur la table ASCII de 128 correspondances qui est une norme informatique de codage de caractères des années 60. Et tout cela avec un clavier de 0-9 et A-F soit 16 touches (même pas une touche carriage return  car c'est le code #D ni même une touche espace car c'est #20)!
http://ascii.cl/
Et pour l'histoire:
https://fr.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange

C'était clair, il y avait celui qui tapait ses idées au kilomètre puis celui qui mettait en forme.

que du text mis en forme (et un peu de "PAO") et comparaison des softs

Si on a que text (par exemple ASCII ou UTF-8) c'est assez simple.
Avec du balisage léger et des transcodeurs, on a du Hub-text.
voir une liste partielle des output formats:
https://en.wikipedia.org/wiki/Lightweight_markup_language

https://en.wikipedia.org/wiki/Comparison_of_document_markup_languages

https://en.wikipedia.org/wiki/Comparison_of_documentation_generators
(and  programming languages).
example: ROBODoc is a documentation tool similar to Javadoc and licensed under the GPL. It is used to extract API documentation from source code. It can be used with any language that supports comments and works by extracting specially formatted headers. These are then reformatted into HTML, DocBook, TROFF, ASCII, LaTeX, PDF, or RTF.
It can be used to document any programming artifact, such as: classes, functions, tests, makefile entries, etc.
ROBODoc works with C, C++, Fortran, Perl, shell scripts, Assembler, DCL, DB/C, Tcl/Tk, Forth, Lisp, COBOL, Occam, Basic, HTML, Clarion, and any other language that supports comments.
https://en.wikipedia.org/wiki/ROBODoc

Une analyse que je partage

Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile:
http://fgallaire.flext.net/comparaison-langage-balisage-markup-lightweight-leger-txt2tags-pandoc-docutils-asciidoc-deplate-stx2any-aft-markdown-textile/

La bureautique est la principale utilisation de l’informatique depuis sa création. Pourtant, les outils majoritairement utilisés dans ce domaine, les logiciels de traitement de texte WYSIWYG comme LibreOffice ou MS word, laissent la majorité des informaticiens et des ergonomes totalement désespérés.
Ces logiciels ont en effet un nombre de défauts très important : ils font se concentrer sur la forme et non sur le fond, leur résultat final ne correspond souvent pas à ce qui est affiché, ils sont incompatibles entre eux, ce sont d’énormes usines à gaz, ils ne fonctionnent qu’en mode graphique, etc.

Il a donc fallu penser à une manière de donner ces instructions de mise en forme au sein du fichier texte lui-même, et c’est ainsi que sont apparus les langages de balisage (markup), dont les plus connus sont HTML (inventé en 1991 par Tim Berners-Lee) et LaTeX (créé en 1985, et basé sur TeX, inventé par le grand Donald Knuth en 1977), et dont la première grande figure fut Roff, un programme Unix historique développé à partir de 1961, et dont la version GNU, Groff, est installée par défaut sur toutes les distributions GNU/Linux, puisqu’on l’utilise encore pour les pages de man des logiciels.

Ces langages représentent une nette amélioration, mais ont tous un gros problème : ils sont gênants ! On ne retrouve plus aussi facilement son contenu au milieu de toutes ces balises supplémentaires, sans parler du fait que les syntaxes complexes ouvrent la voie à de nombreuses erreurs de compilation.

C’est en 1995 que l’on trouva la solution de ce problème, avec la création du premier langage Wiki, dont le but principal était de permettre l’édition facile de pages web par tout un chacun, et dont l’utilisateur actuel le plus célèbre est l’encyclopédie libre Wikipédia. S’il y a presque autant de syntaxes différentes que de logiciels Wiki, elles ont toutes la caractéristique d’utiliser des caractères textuels simples et intuitifs pour donner les indications de formatage du texte.
http://www.wikicreole.org/wiki/Reasoning

https://www.mediawiki.org/wiki/Help:Formatting
https://fr.wikipedia.org/wiki/Aide:Syntaxe_(wikicode)
https://fr.wikipedia.org/wiki/Aide:Ins%C3%A9rer_un_tableau_(wikicode,_avanc%C3%A9)
https://fr.wikipedia.org/wiki/Mod%C3%A8le:BUtilisateur
https://www.mediawiki.org/wiki/MediaWiki/fr

J'ai toujours aimé le principe du "folding editor".
le premier fut STET  'STructured Editing Tool' de 1977
https://en.wikipedia.org/wiki/STET_(text_editor)
A folding editor is a text editor which supports text folding or code folding, a mechanism allowing the user to hide and reveal blocks of text—usually named. Typically this is done to allow the user to better picture the overall structure of a document or program.
Folding is provided by many modern text editors, and syntax-based or semantics-based folding is now a component of many software development environments...
https://en.wikipedia.org/wiki/Folding_editor


Mais pourquoi limiter ces langages de balisage léger à la seule génération de HTML ? Pourquoi ne pas utiliser la même syntaxe pour différentes cibles (appelées backends, targets ou writers selon les logiciels), de manière à obtenir aussi bien une page web en HTML, qu’un document en LaTeX pour l’impression, ou qu’une page de man pour un logiciel ? Ce sont les logiciels qui poursuivent ce but qui m’intéressent, ils constituent pour moi l’avenir de la bureautique informatique, et j’ai été amené à les comparer pour en choisir un dans lequel m’investir comme développeur.

Trois d’entre eux, Docutils, Deplate et Pandoc, ont un design évolué, avec une machine à états finis pour laquelle on peut écrire de nouveaux readers et writers de manière parfaitement propre. Cependant, malgré leurs grandes qualités, Deplate est un projet trop confidentiel (ainsi il n’est incompréhensiblement pas présent parmi les pourtant si nombreux paquets Debian), et je ne me sentais pas à la hauteur pour m’investir dans un projet comme Pandoc, totalement écrit en Haskell, qui est un langage de programmation complexe que j’aimerais beaucoup utiliser.
Je détaillerai Pandoc ci-dessous.

Txt2tags

J’ai rajouté dans ce comparatif Markdown et Textile, puisqu’ils ont chacun une implémentation en Python, mais ne générant que du HTML, ils ne m’intéressaient pas vraiment. AsciiDoc et Txt2tags ont un peu la même architecture, avec un gros fichier principal faisant tout le travail, que l’on peut configurer, respectivement avec un fichier .conf et deux dictionnaires Python (un pour les Tags et l’autre pour les Rules), pour créer de nouvelles cibles. AsciiDoc et Txt2tags sont donc plus aisés à prendre en main et à modifier rapidement que Docutils, qui est une très belle et très bien architecturée machine à états objet, mais aussi plus difficile à appréhender.
De plus, comme je désapprouvais totalement la politique de licence domaine publique de Docutils, il ne me restait plus qu’à faire mon choix entre Txt2tags et AsciiDoc. C’est principalement l’orientation très DocBook (un format ne m’intéressant personnellement pas du tout) d’AsciiDoc, et d’autres détails, comme la localisation en de nombreuses langues de Txt2tags et sa plus grande simplicité, qui m’ont finalement fait choisir Txt2tags.

Ce choix est confirmé par une étude plus avancée des différentes syntaxes. Ainsi alors que la syntaxe reST de Docutils ne dispose que de :

*italique* et **gras**

Txt2tags est beaucoup plus riche :

//italique// **gras** __souligné__ et --barré--

Le codage visuel est bien meilleur, et le compréhension instantanée avec la syntaxe de Txt2tags, puisque les slashs donnent l’impression penchée de l’italique, les étoiles imitent la surcharge du gras, les underscores donnent l’impression de soulignement, et les moins apparaissent comme une barre. De plus, l’utilisation généralisée des caractères de balisage en doubles, permet de lever à peu de frais un maximum d’ambiguïtés syntaxiques.

insertion d'une image est beaucoup plus simple Txt2tags
[[picture.png] http://fgallaire.flext.net]

Leur implémentation en Python permet à Txt2tags, reST (par Docutils) et AsciiDoc d’être utilisables à la fois comme logiciels de bureautique multiplateforme (Linux, Mac OS X, Windows et *BSD) et pour le web côté serveur. Depuis 2012, une implémentation de txt2tags en PHP est disponible, développée par Petko Yotov (le mainteneur et principal développeur de PmWiki) et sponsorisée par Eric Forgeot. Grâce aux nombreux efforts de ce dernier, il existe maintenant plusieurs implémentations de la syntaxe Txt2tags en JavaScript, avec une démo parfaitement fonctionnelle des possibilités de rendu côté client en temps réel. Et Matthew Pickering a quant à lui écrit un reader Txt2tags pour Pandoc.

En face, Markdown est représenté par une armada d’implémentations dans tous les langages utilisés sur le web côté serveur, et aussi en JavaScript côté client pour des prévisualisations efficaces sans Ajax, mais seul Pandoc, qui n’est pas si facile à compiler sur toutes les plateformes, propose autre chose qu’un rendu en HTML.

Je vais bien sûr continuer à travailler sur le logiciel Txt2tags, mais une implémentation de la syntaxe Txt2tags dans un parser Docutils, pour toucher directement toute la communauté des développeurs Python qui documentent leurs projets, et pouvoir bénéficier ensuite du sublime Sphinx, est un projet qui me motive de plus en plus.

Enfin, je suis toujours un peu nostalgique devant ce screenshot, parce que c’est en le voyant, avec en haut à gauche le fichier avec les balises, et en bas à droite celui avec le résultat texte brut, que j’ai pris conscience que Txt2tags faisait bien ce que j’espérais, et que comme en plus il était en Python, ce serait probablement le logiciel auquel j’allais contribuer !

Pandoc

Pandoc is a command-line tool. There is no graphic user interface. 

Pandoc is a Haskell library for converting from one markup format to another, and a command-line tool that uses this library. It can read Markdown, CommonMark, PHP Markdown Extra, GitHub-Flavored Markdown, MultiMarkdown, and (subsets of) Textile, reStructuredText, HTML, LaTeX, MediaWiki markup, TWiki markup, Haddock markup, OPML, Emacs Org mode, DocBook, Muse, txt2tags, Vimwiki, EPUB, ODT, and Word docx; and it can write plain text, Markdown, CommonMark, PHP Markdown Extra, GitHub-Flavored Markdown, MultiMarkdown, reStructuredText, XHTML, HTML5, LaTeX (including beamer slide shows), ConTeXt, RTF, OPML, DocBook, OpenDocument, ODT, Word docx, GNU Texinfo, MediaWiki markup, DokuWiki markup, ZimWiki markup, Haddock markup, EPUB (v2 or v3), FictionBook2, Textile, groff man, [groff ms], Emacs Org mode, AsciiDoc, InDesign ICML, TEI Simple, Muse and Slidy, Slideous, DZSlides, reveal.js or S5 HTML slide shows. It can also produce PDF output on systems where LaTeX, ConTeXt, pdfroff, or wkhtmltopdf is installed.

Pandoc's enhanced version of Markdown includes syntax for footnotes, tables, flexible ordered lists, definition lists, fenced code blocks, superscripts and subscripts, strikeout, metadata blocks, automatic tables of contents, embedded LaTeX math, citations, and [Markdown inside HTML block elements][Extension: markdown_in_html_blocks]. (These enhancements, described further under Pandoc's Markdown, can be disabled using the markdown_strict input or output format.)

In contrast to most existing tools for converting Markdown to HTML, which use regex substitutions, pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document, and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer.

Because pandoc's intermediate representation of a document is less expressive than many of the formats it converts between, one should not expect perfect conversions between every format and every other. Pandoc attempts to preserve the structural elements of a document, but not formatting details such as margin size. And some document elements, such as complex tables, may not fit into pandoc's simple document model. While conversions from pandoc's Markdown to all formats aspire to be perfect, conversions from formats more expressive than pandoc's Markdown can be expected to be lossy.

This document is for people who are unfamiliar with command line tools. Command-line experts can go straight to the User’s Guide or the pandoc man page:

http://pandoc.org/getting-started.html

https://pandoc.org/MANUAL.html

Modules 

In contrast to most existing tools for converting Markdown to HTML, pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document, and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer.

• Text
  • Text.Pandoc
    • Text.Pandoc.CSS
    • Text.Pandoc.Error
    • Text.Pandoc.MediaBag
    • Text.Pandoc.Options
    • Text.Pandoc.PDF
    • Text.Pandoc.Pretty
    • Text.Pandoc.Process
    • Readers
      • Text.Pandoc.Readers.CommonMark
      • Text.Pandoc.Readers.DocBook
      • Text.Pandoc.Readers.Docx
      • Text.Pandoc.Readers.EPUB
      • Text.Pandoc.Readers.HTML
      • Text.Pandoc.Readers.Haddock
      • Text.Pandoc.Readers.LaTeX
      • Text.Pandoc.Readers.Markdown
      • Text.Pandoc.Readers.MediaWiki
      • Text.Pandoc.Readers.Native
      • Text.Pandoc.Readers.OPML
      • Text.Pandoc.Readers.Odt
      • Text.Pandoc.Readers.Org
      • Text.Pandoc.Readers.RST
      • Text.Pandoc.Readers.TWiki
      • Text.Pandoc.Readers.TeXMath
      • Text.Pandoc.Readers.Textile
      • Text.Pandoc.Readers.Txt2Tags
    • Text.Pandoc.SelfContained
    • Text.Pandoc.Shared
    • Text.Pandoc.Templates
    • Text.Pandoc.UTF8
    • Writers
      • Text.Pandoc.Writers.AsciiDoc
      • Text.Pandoc.Writers.CommonMark
      • Text.Pandoc.Writers.ConTeXt
      • Text.Pandoc.Writers.Custom
      • Text.Pandoc.Writers.Docbook
      • Text.Pandoc.Writers.Docx
      • Text.Pandoc.Writers.DokuWiki
      • Text.Pandoc.Writers.EPUB
      • Text.Pandoc.Writers.FB2
      • Text.Pandoc.Writers.HTML
      • Text.Pandoc.Writers.Haddock
      • Text.Pandoc.Writers.ICML
      • Text.Pandoc.Writers.LaTeX
      • Text.Pandoc.Writers.Man
      • Text.Pandoc.Writers.Markdown
      • Text.Pandoc.Writers.MediaWiki
      • Text.Pandoc.Writers.Native
      • Text.Pandoc.Writers.ODT
      • Text.Pandoc.Writers.OPML
      • Text.Pandoc.Writers.OpenDocument
      • Text.Pandoc.Writers.Org
      • Text.Pandoc.Writers.RST
      • Text.Pandoc.Writers.RTF
      • Text.Pandoc.Writers.TEI
      • Text.Pandoc.Writers.Texinfo
      • Text.Pandoc.Writers.Textile
      • Text.Pandoc.Writers.ZimWiki
    • Text.Pandoc.XML

Ref.

https://hackage.haskell.org/package/pandoc

Pandoc’s enhanced version of Markdown 

Pandoc’s enhanced version of Markdown includes syntax for footnotes, tables, flexible ordered lists, definition lists, fenced code blocks, superscripts and subscripts, strikeout, metadata blocks, automatic tables of contents, embedded LaTeX math, citations, and Markdown inside HTML block elements. (These enhancements, described further under Pandoc’s Markdown, can be disabled using the markdown_strict input or output format.)

http://pandoc.org/MANUAL.html#pandocs-markdown

Tricks

you have a long markdown file in GitHub and want to have a TOC, you can use 

pandoc -t markdown_github --toc -o example-with-toc.md example.md

Using Markdown Templates

Math in Pure Markdown

https://github.com/jgm/pandoc/wiki/Pandoc-Tricks

HDR high dynamic range, problem avantages and photo, raw, DRO, video, game, science, computer, screen, camera, web platform, understanding SONY auto-HDR

Intro

https://en.wikipedia.org/wiki/High-dynamic-range_imaging

I will focus on the example of the Sony alpha 77 and 65 (the first with built-in auto-HDR).

Tone mapping

The method of rendering an HDR image to a standard monitor or printing device is called tone mapping. This method reduces the overall contrast of an HDR image to facilitate display on devices or printouts with lower dynamic range (LDR), and can be applied to produce images with preserved local contrast (or exaggerated for artistic effect).
https://en.wikipedia.org/wiki/Tone_mapping

The main problem is the dynamic ranges of common devices:

Dynamic ranges of common devices

Device	Stops	Contrast
LCD	9.5	700:1 (250:1 – 1750:1)
Negative film (Kodak VISION3)	13	8000:1
Human eye (static)	10–14	1000:1 – 15000:1
High-end DSLR camera	14.8	28500:1
Human eye (dynamic)	20	1000000:1

https://en.wikipedia.org/wiki/High-dynamic-range_imaging

In our case (camera), the CMOS sensor and its electronic is limited. For example:

The dynamic range is typically limited by the readout process of the CMOS imager pixel. Techniques have been developed in the past to cope with this, usually by non-linear compression of the signal.
ams Sensors Belgium developed a new CMOS image sensor pixels that allows readout of a photodiode with a wide dynamic range, which maintains a linear response to light. After exposure, the photodiode is read out via two transfer gates to two sense nodes. Two signals are then read from each pixel. The first signal only reads charge transferred to the first sense node, with maximal gain. This sample is used for small charge packets and is read with with low read noise. The second sample reads the total charge transferred to both sense nodes, with a lower gain. Pixels with a read noise of 3.3 electrons and a full well charge of 100,000 electrons have been demonstrated, resulting in a linear dynamic range of 90 dB.

http://www.cmosis.com/technology/technology_overview/high_dynamic_range_pixels

DRO, auto-HDR, Raw

In fact you have 5 possibilities:

• DRO (how DRO works: https://www.dpreview.com/articles/3798759501/apical)
• auto-HDR
• shooting a bracket 3-5 exposures (well within the camera's reach) and RAW then doing the HDR work on the computer (function "Merge to HDR"),
• research domain with you own software (macro photo, fluorescent photo, photo with very high contrast, 3D photo)
• one Raw and manual or semi-automatic processing with specialized software (raw converters):

• lightroom, 
• https://fr.wikipedia.org/wiki/Darktable, 
• https://en.wikipedia.org/wiki/DigiKam, 
• http://rawtherapee.com/, 
• https://en.wikipedia.org/wiki/LightZone, 
• https://www.hdrsoft.com/, 
• https://fr.wikipedia.org/wiki/DxO_OpticsPro, 
• http://alternativeto.net/software/photomatix-pro/

see Merged HDR with many Preset
https://www.hdrsoft.com/

HDR auto from Sony

in french: Le mode HDR automatique des Sony Alpha 450, 500 et 550 (2010)
http://www.alpha-numerique.fr/index.php/technique/elements-techniques/426-le-mode-hdr-automatique-des-sony-alpha-450-500-et-550

Auto HDR of alpha 65 and 77 (2012)
http://blog.william-porter.net/2012/01/sony-a77-expanding-dynamic-range-with.html
This excellent post shows the difference of DRO, HDR, and raw.
The best is to select HDR with you own contrast decision.

In-camera HDR ("high dynamic range") is a different way to solve the problem. Like on-the-computer HDR, in-camera HDR starts with several different exposures of the same scene, then combines them into a single output file in which the well-exposed bright areas from one shot have been combined with the best-exposed dark areas from another, and the composite file has been adjusted to make things look natural. Sony's programmers have written programs that seem to do a very good job — sometimes — of combining the exposures. But a key factor in getting good results, is providing the processor with good source images. The new fixed-mirror (SLT) cameras from Sony are especially well suited to gathering the multiple exposures because, lacking a moving mirror, these cameras can take more shots per second than their traditional reflex (moving) mirror competitors.

Raw file, unprocessed. and clipping region  (no contrast)

The red is where the scene is brighter than the camera could capture (with these settings) 

and the blue is where the scene is too dark for the camera (with these settings) to retain detail.

It's when you turn on Lightroom's "show clipping" feature.

 Raw file, unprocessed.

 Sony auto-HDR

The HDR AUTO has preserved detail outside well 

but surrendered detail in the shadows.

It's the choice of Sony's programmers.

 Sony auto-HDR 

with knowing that the dynamic range of this scene 

was fairly extreme, I set HDR to its max (6 EV). 

The raw data file has a lot more latitude than a jpeg. To compare what I can get from the raw file with what Sony's in-camera DRO and HDR offer, I reshot the scene, saved the raw file, and processed it myself in Lightroom or other software.
I used an adjustment brush to bring the bright areas (the windows) down 1.5 stops, and a separate brush to bring the shadow areas up 1.5 stops. Even so, the result was pretty good. See the original RAW file at the beginning.

Morever, because in-camera HDR takes multiple exposures and then processes them, achieving a single HDR result in the camera takes about five or six seconds. And you simply can't use it if anything in the scene is moving quickly. Finally, the A65 or A77's processor saves the HDR file as a jpeg, by necessity. The HDR file is a composite, a processed result. There is no raw original of the HDR result.

And if you really want to hedge your bets, shoot RAW + JPEG with DRO AUTO enabled. You may find that the raw file is badly exposed but the jpeg is usable and you won't have to fuss with the raw file on the computer.

 sony auto-DRO

sony DRO LV5;
Sensing that there was at least a five to six stop gap between the darks
and the lights here, I then changed the DRO setting from Auto to "Lv5".

 The feature is called "Auto HDR" and it has seven possible options: levels 1-6 plus an option called, confusingly, "auto." Sounds tautological to say "put the Auto HDR feature on auto," but it's not.

But a word or two further about raw might be pertinent here.

There is never a question about shooting raw or not. We all shoot raw always, willy nilly. Raw is how the camera works. The question is simply, where does the raw data get processed? Your choices are

• (a) let the little processor with the no-choice software in your camera do it and hope you're happy with the results, because you lose the chance to do it over; or 
• (b) keep the raw data, then process and reprocess as many times you like on a full-blown computer, using as many different raw converters as you like or as many different programs as you can afford. If you put it this way, it's not hard to see that, if you really need to get it right, you're better off shooting raw and shooting a bracket 3-5 exposures (well within the camera's reach) then doing the HDR work on the computer.

That said, while in-camera HDR might not produce the best results possible, I will readily admit that is that its results are pretty darned good. I'm still not quite sold, but I do acknowledge that Sony's done a tremendous job here and with MFNR multi frame noise reduction.
HDR image has less noise in the shadows.
One of the downsides to shooting and processing HDR in-camera is that you have no control over the tone-curve applied. 

See also

https://www.dpreview.com/reviews/sonyslta77/12
https://www.dpreview.com/reviews/sonynexc3/7
The Complete Guide to Sony's Alpha 65 and 77 SLT Cameras B&W Edition Volume II:
https://books.google.fr/books?id=R_mWAwAAQBAJ&pg=PA456&lpg=PA456&dq=HDR+automatic+Sony+Alpha+65&source=bl&ots=-ajGH13gZg&sig=UkvJtQ1KE5laUZ7vKgPGtd0KTcc&hl=en&sa=X&ved=0ahUKEwiap-Gw4o3VAhWBB8AKHVuzAmIQ6AEIYjAJ#v=onepage&q=HDR%20automatic%20Sony%20Alpha%2065&f=false

Process

The 'HDR' mode can be set to Auto, or can be manually set from 1 stop to 6 stops EV. This is the mode that takes 3 frames quickly, and merges them together in camera to deliver a single HDR merged photo.

This is different than bracketing, and manually taking your own set of photos to merge in software after the fact, which is what most other folks on the web are talking about. For this, you need to see what the maximum bracketing range is for the camera in the exposure bracketing mode...with most Sony cameras, it is indeed only + -0.7 EV. The A77 being an exception. Also of note: you don't HAVE to use bracketing mode to take manual HDR exposures to blend - if you set up the camera on a tripod and take a series of photos where you manually adjust the exposure by a stop or two at a time, you can take any EV range you want and any number of photos you want - bracketing is what people use when they are trying to eliminate motion blur between a series of shots from handheld action, as it takes 3 photos relatively quickly. Sony's HDR mode does the same, but also does the blending of the HDR in the camera so the output is a single, final HDR photo.

Page 129 of the A65 Handbook states, You cannot use the Auto HDR function on RAW images. And, when the exposure mode is set to

• AUTO, 
• AUTO+, 
• Sweep Panaroma, 
• 3D Sweep Panaroma, 
• Continuous Advance Priority AE 
• Scent Selection, 
• when Multi Frame Noise Reduct. is selected...

you cannot select Auto HDR.

I think that the delay between the 3 photos is around 150ms (frequency 1.6 Hz; or "speed process"=1/6.6), "speed of all the shooting process"=1/3.3) then be careful when you have a moving part in your photo. The sound between the 3 photos indicates this tempo...
After the computer processing is around 5s and your camera is blocked.

JPEG, RAW and high iso.

http://www.photographyblog.com/reviews/sony_a65_review/image_quality/

List of all cameras and Auto Exposure Bracketing option

Auto Exposure Bracketing Settings by Camera Model
list of all cameras
https://www.hdrsoft.com/resources/aeb.html
Camera Model Auto-bracketed frames Max EV step increment Max EV range in AEB Max burst rate
Sony Alpha A65 3 0.7 1.4 10 fps
Sony Alpha A77 3 or 5 3 (3 frames), 0.7 (5 frames) 6 12 fps

Many digital cameras include an Auto Exposure Bracketing (AEB) option. When AEB is selected, the camera automatically takes three or more shots, each at a different exposure.
Auto Exposure Bracketing is very useful for capturing high contrast scenes for HDR. However, AEB wasn't intended for HDR initially, but for ensuring that one of the shots taken is correctly exposed. This means that some camera models only offer a maximum of 1 EV spacing, or even less, in just three auto bracketed shots.
Unfortunately, three shots spaced by one EV are often not sufficient for capturing high contrast scenes.

comparison of XML editors and import/export. HTML, DITA, Docbook

Introduction

En anglais: comparison of XML editor and a small selection.
En français: un long développement sur la vision et les outils quark.

XML editor

https://en.wikipedia.org/wiki/XML_editor

An XML editor is a markup language editor with added functionality to facilitate the editing of XML. This can be done using a plain text editor, with all the code visible, but XML editors have added facilities like tag completion and menus and buttons for tasks that are common in XML editing, based on data supplied with document type definition (DTD) or the XML tree.
https://en.wikipedia.org/wiki/Document_type_definition
 DTD is associated with an XML or SGML document by means of a document type declaration (DOCTYPE).

There are also graphical XML editors that hide the code in the background and present the content to the user in a more user-friendly format, approximating the rendered version or editing forms. This is helpful for situations where people who are not fluent in XML code need to enter information in XML based documents such as time sheets and expenditure reports. And even if the user is familiar with XML, use of such editors, which take care of syntax details, is often faster and more convenient.

comparison of XML editor

https://en.wikipedia.org/wiki/Comparison_of_XML_editors

an iframe of a google spreadsheet (copy/paste from wikipedia @janv 2017):

a selection

open CAM

https://en.wikipedia.org/wiki/Content_Assembly_Mechanism

http://camprocessor.sourceforge.net/wiki/index.php/Main_Page

open JEdit

https://en.wikipedia.org/wiki/JEdit

https://fr.wikipedia.org/wiki/JEdit (low)

not open oXygen

You must pay!

From Guided Authoring To Advanced XML Development

Now You Have It All!

http://www.oxygenxml.com/

some plug-in:

https://github.com/oxygenxml

web app

Quark Author est un logiciel Web de création de contenu qui, associé à Quark Publishing Platform, permet aux responsables commerciaux et informatiques de rationaliser et d'automatiser les communications client à haute valeur ajoutée sur tous les canaux de publication. 

http://www.quark.com/fr/Products/Quark_Publishing_Platform/

L'expérience de création en ligne intuitive permet aux experts techniques – où qu'ils soient – de créer, prévisualiser, publier et réutiliser rapidement des contenus. Prenez de l'avance sur vos concurrents, charmez vos clients. Quark Author – Des contenus intelligents pour les entreprises innovantes.

http://www.quark.com/Products/Quark_Author/#1
https://en.wikipedia.org/wiki/Quark_Author

Création de contenus intelligents

Une fois le contenu verrouillé dans un document avec un formatage, il est très difficile et coûteux de le dissocier C'est là le principal obstacle pour les organisations souhaitant créer et actualiser efficacement des communications à forte valeur ajoutée sur tous les canaux de publication. 

Quark Author a été conçu spécifiquement pour les utilisateurs professionnels afin de leur permettre de créer des contenus structurés (XML) au sein d'un environnement familier de type traitement de texte. Les rédacteurs peuvent créer et organiser des composants de contenu au moyen de types de contenu standard comme des sections, des paragraphes, des listes, des tableaux, des graphiques et des figures. Ces composants de contenu peuvent être assemblés dynamiquement pour tout type de sortie. 

Quark Author est basé sur le schéma de contenu intelligent de Quark.

http://www.quark.com/fr/Solutions/Dynamic_Publishing/Smart_Content.aspx

Qui d'autre utilise le XML pour la production de documents ?

Il existe de nombreux schémas XML pour la création et la publication sur le marché. Certains sont très génériques et certains sont spécifiques à une industrie. Chose intéressante, même le HTML4 et les versions ultérieures sont en fait des mises en œuvre d'un schéma XML appelé "XHTML". Parmi les autres schémas XML populaires, on citera :

• DITA
  http://www.quark.com/fr/Solutions/Applications/DITA.aspx
  L'un des schémas XML les plus populaires pour la création et la publication de documents techniques. Il avait été développé à l'origine chez IBM puis transféré à OASIS comme norme de l'industrie pour les publications techniques. Nous reviendrons sur DITA ultérieurement
  https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
• Docbook
  http://www.docbook.org/
  Un précurseur de DITA fortement utilisé dans les publications techniques et les ouvrages de référence.

Et il en existe bien d'autres, y compris chez certaines sociétés qui définissent leur propre schéma personnalisé à partir de zéro, ce qui représente BEAUCOUP de travail, difficile et coûteux pour bien le faire.

Sachant qu'il existe de nombreux schémas de documents XML disponibles, pourquoi Quark a-t-elle créé un nouveau schéma de contenu intelligent ?

Quel est le problème avec le XML?

Le XML pour la production de documents a été adopté en premier par l'industrie des publications techniques. Il est largement utilisé dans la documentation informatique (matériel et logiciel), la fabrication discrète complexe et certaines industries par process où le contenu est publié à terme aux formats papier et PDF, HTML, et dans plusieurs formats de système d'aide tels que HTMLHelp, MSHelp, EclipseHelp, WebHelp, ainsi que d'autres types de sortie. Les schémas de document XML les plus largement utilisés ont été créés par et pour l'industrie des publications techniques, y compris le très populaire schéma DITA.

Le résultat est que ces schémas sont des outils extrêmement puissants, mais aussi extrêmement complexes. Pour emprunter une citation d'un partenaire de services professionnels de Quark, « le DITA est formidable si vos rédacteurs sont capables de penser comme des programmeurs ». C'est parfait pour les rédacteurs techniques qui sont, de par la nature de leur travail, très techniques et bien formés. Ce sont aussi des rédacteurs à plein temps.

Qu'est-ce qui rend ces schémas de création si difficiles ? Ils sont souvent trop restrictifs. Chez Quark, bon nombre de nos premiers adeptes qui utilisaient l'un de ces schémas se plaignaient de ce que le simple fait de couper/coller du contenu d'une zone d'un document vers une autre était bloqué par l'application. Pourquoi était-ce bloqué ? Prenons l'exemple simple suivant d'un titre et d'un paragraphe (nous montrons les balises XML, mais souvenez-vous que la plupart des outils de rédaction XML tentent de masquer les balises) :

<title>Comment faire</title>

<para>Commencez avec les ingrédients de la <keyword>recette pour Thanksgiving</keyword>.</para>

Si l'utilisateur sélectionne et copie la phrase "<keyword>recette pour Thanksgiving</keyword>." et la colle après Faire dans le <title>, l'outil de rédaction pourrait bloquer le collage car le schéma de contrôle ne permet pas <keyword> à l'intérieur d'un élément <title>. C'est frustrant et pire encore, car la raison pour laquelle le collage a échoué est souvent masquée aux yeux de l'utilisateur – lequel ne peut pas comprendre pourquoi c'est bloqué et pense que l'outil ne fonctionne pas correctement.

Détails du schéma de contenu intelligent

Pour les utilisateurs "calés" en XML, le schéma de contenu intelligent emprunte des idées de nombreuses autres implémentations XML incluant, et c'est important, l'idée de types de contenu – parfois appelés classes de contenu ou formes architecturales de contenu. L'idée centrale est relativement simple : il existe un ensemble de types de contenus fondamentaux et tous les autres contenus peuvent être décrits comme appartenant à l'une des classes racine. Pour ceux d'entre vous qui sont familiarisés avec DITA, une autre manière de décrire ceci serait la "spécialisation" de l'une de ces classes racine. Le concept de classes racine et de hiérarchies de classe est commun en programmation informatique, biologie, physique, mathématiques et plus encore.

La valeur des classes racine et des hiérarchies de classe est qu'un système qui sait comment traiter l'élément racine peut assurer un traitement de base de toute spécialisation de cette racine sans connaître quoi que ce soit auparavant de la spécialisation spécifique.

Ceci est moins compliqué que vous pourriez le penser. Prenons un exemple simple, si le système sait que tous les éléments <para> doivent être présentés avec une ligne vide au-dessus et en dessous, si le système traite un contenu qui inclut <para type="blockquote">, il saura au moins qu'un Block Quote doit comporter une ligne vide au-dessus et en dessous. Il existe de nombreuses autres règles de traitement, règles de présentation et interactions utilisateurs pouvant être appliquées à tout contenu de type similaire. La "spécialisation" est créée car un système pourrait aussi ajouter un traitement nouveau et unique comme les retraits droite et gauche pour la présentation d'un Block Quote.

Quelles sont certaines des classes racine ? Le contenu intelligent les représente dans différentes catégories, et voici un tableau qui compare une partie de la terminologie que le contenu intelligent, DITA et le HTML utilisent :

Dans le HTML, la spécialisation d'une balise HTML racine est généralement effectuée pour entraîner le formatage CSS ou pour déclencher un javascript spécifique à une balise et est le plus souvent codée en utilisant un attribut de classe tel que :

<div class="Navigation">…</div>

Toutefois, dans le HTML, il existe très peu de règles concernant où et comment vous pouvez utiliser <div> et il n'existe aucune règle quant à la valeur de l'attribut “class”, de sorte que le HTML est de fait fortement à structure libre et inutile pour la rédaction de contenus de communication à haute valeur ajoutée – bien qu'il soit excellent pour une présentation dans une page Web ou une application mobile.

Dans DITA, la spécialisation d'un élément DITA racine comme <topic> est codée comme suit :

<concept class="- topic/topic concept/concept">…</concept>

Il est au-delà de la portée de ce document d'expliquer pourquoi l'attribut de classe possède une telle valeur apparemment redondante, mais il est facile d'identifier le but, qui est que l'élément "concept" est de la classe "topic" et doit par conséquent être traité comme "topic", sauf lorsqu'un traitement spécifique pour "concept" a été défini.

Dans le contenu intelligent, la spécialisation est codée comme suit :

<section type="purpose">

Ceci est très similaire à la méthode HTML pour spécialisation, mais possède des règles d'implémentation très spécifiques de sorte que, par exemple, la rédaction d'un document de procédure opérationnelle normalisée peut limiter chaque document à un seul "Purpose" et que celui-ci doit être après le titre du document. Le HTML ne limite pas l'utilisation ou même ne valide pas la valeur des attributs de classe.

Il est important de souligner que, dans le HTML et le Contenu intelligent, le nom de l'élément est toujours la racine de la classe. Il s'agit de :

<section type="mySection">, ce n'est pas <mySection class="section">.

Publication multicanal automatisée

Le schéma de contenu intelligent utilisé par Quark Author a été développé avec deux idées en tête : la facilité d'utilisation pour les experts techniques et la sortie multicanal. Quark Author génère des fichiers XML à riche contenu sémantique pouvant être utilisés pour piloter la publication multicanal automatisée de Quark Publishing Platform afin de toucher les employés, les partenaires et les clients. Contenu, mise en forme et image de marque peuvent être personnalisés pour chaque canal, zone géographique, division, etc. afin de maximiser l'efficacité de vos communications à haute valeur ajoutée, que ce soit pour le support papier, les fichiers PDF, le Web ou les apps mobiles.

word et XML et outils quark

Quark XML Author for Microsoft Word
Lancé en 2002, Quark XML Author™ for Microsoft Word est un outil de création XML de nouvelle génération. Il se présente sous la forme d'un module complémentaire pour Microsoft Word qui permet à tout utilisateur de créer facilement des documents XML, sans connaissance de ce langage ni formation.
Création de documents XML dans Microsoft Word
Quark XML Author for Microsoft Word permet à tout utilisateur de créer facilement des documents XML, sans connaissance de ce langage ni formation. Quark XML Author est un module d'extension pour Microsoft Word qui permet aux rédacteurs de créer des composants d'information utilisables directement dans Quark Publishing Platform, qui les combine automatiquement de manière appropriée pour produire des documents imprimés de grande qualité ou des versions numériques pour le Web ou d'autres supports électroniques.
http://www.quark.com/fr/Products/Quark_XML_Author/