Sylvain,
I'm glad you brought this up as it needs to be addressed by the spec.
What we know to be undoubtedly true is that, with the exception of verbatim blocks, sequential space characters (which includes ASCII spaces, tabs, and line feeds) are normalized to a single space in the output format produced from AsciiDoc. Some converters, such as the built-in HTML and DocBook converters in Asciidoctor, rely on the viewer (e.g., browser) to perform this normalization. Other converters, such as the PDF converter, take on the work of performing this normalization since the viewer does not offer this feature. As far as what the reader sees, runs of space characters should only show up as a single space.
I have long wrestled with whether this normalization should be performed eagerly when the document is parsed. As Lex points out, AsciiDoc Python did not do so, and Asciidoctor retained that behavior. It's debatable whether the spaces are valuable to keep. However, removing them would certainly make the sourcemap more complicated since it would have to account for their absence.
I don't think the spec needs to mandate whether or not spaces should be normalized. What it should do, however, is mandate that the spaces should be normalized when the converted document is viewed. This allows converters to rely on functionality of the viewer application, only stepping in when that functionality isn't available. And even then, it should probably always be the responsibility of the converter.
Best Regards,
-Dan
p.s. I ask that you use the term "spaces" rather than "whitespace". The color specifier serves no purpose and isn't relevant anyway for people who use a dark theme.
