Asciidoctor :: Discussion
Login  Register

Re: Unit of measure for image dimensions

Posted by mojavelinux on May 19, 2015; 12:55am
URL: https://discuss.asciidoctor.org/Unit-of-measure-for-image-dimensions-tp3040p3234.html

On Mon, May 18, 2015 at 2:01 AM, hijarian [via Asciidoctor :: Discussion] <[hidden email]> wrote:
Thank you for thorough answer

You're very welcome.
 
, 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.

We're hard at work getting the information that's in my head, as well as various channels, into the user manual <http://asciidoctor.org/docs/user-manual). There's a lot to document, so it's taking some time.

Thanks for raising this topic because now it's clear what we need to document.
 
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.

That's sort of what this discussion is about...figuring out exactly what they are and documenting it.

 

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.

The more I think about it, the more I think this is the way to go. If these extra attributes aren't provided, we'll do our best to make sense of the width and height alone (or the native size of the image).
 
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.

Thanks for clarifying. So it isn't supported by DocBook after all. We don't maintain the DocBook toolchain, so our best bet is to address this requirement in Asciidoctor PDF.
 
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.

I don't think we need a special type. The existing macro is capable of capturing the necessary information. As far as I understand it, we just need to handle floating images correctly in Asciidoctor PDF. It will likely become a follow-up issue to https://github.com/asciidoctor/asciidoctor-pdf/issues/9.

Cheers,

-Dan


--
Free forum by Nabble Edit this page