Posted by hijarian on May 18, 2015; 8:01am
URL: https://discuss.asciidoctor.org/Unit-of-measure-for-image-dimensions-tp3040p3228.html

Thank you for thorough answer, it's all a lot more clear now. I apologize that I needed to get an answer from nobody else than the author of the library to get this information, but as far as I researched, it's not recorded anywhere apart from source code and maybe some non-searchable place like some IRC chat. I didn't know that "width" and "height" attributes are just information for Asciidoctor about dimensions of the source image and the resulting dimensions can be completely different by design.

I agree that two distinct width properties seems to be the most viable option. It's a lot more complex task to make Asciidoctor automatically fit images to such different mediums like (essentially width-less) screen and printed matter.

I used LaTeX as a point of reference known to everybody - its capabilities in PS/PDF generation do not need any explanation.

When I talked about the type of images which are neither inline nor block-level I meant exactly that, I repeat it again:

* Block-level images are treated very distinctively by AsciiDoctor (and, subsequently, DocBook): they are being recorded into TOC, have a caption and have a special 100%-width block around them inside which they can be explicitly positioned using separate attribute exclusively for this positioning. This is very convenient for the time we need to actually track and reference them, no complaints here.
* Inline-level images as they are (`image:path[attrs]`, single-colon), are meant to be used as they named: inline, that is, as a in-line characters happen to be raster images. For example, smileys. This is obvious meaning stemming from the fact that by default they are being rendered exactly like that by both DocBook and HTML backends.
* Special property "float" on inline-level images converts them to what I am talking about: purely decorative images placed somewhere in the flow of the document. My personal problem was that "float" seems to not work in the DocBook backend at all: image becomes placed in its own block but is not actually "floated" - text is not wrapping it and right-aligned float does not work. My proposition is to make such images into separate explicit type (or maybe to make inline images instead a separate explicit type, because floated decorative images are a lot more common than inline ones, I totally don't understand intention of the HTML spec here at all). And to not forget to enable this feature in PDF output.