Image width doesn't modify the container width only the image

[pbrentlinger]

my code:

image::timestudy2019.png["Patrick Brentlinger 2019 Time Breakdown", 50%, pdfwidth="50%", scaledwidth="50%", float="right", align="right"]

I have been working to build our content management strategy up.
I had a setback that took me back to the drawing board, but we are on track once again.

[ggrossetie]

Hello @pbrentlinger

I guess you would expect the paragraph to be on the left of the image?
For reference, I get more or less the same output with Asciidoctor PDF (Ruby):

$ asciidoctor-pdf --version
Asciidoctor PDF 1.5.0.beta.8 using Asciidoctor 2.0.10 [https://asciidoctor.org]
Runtime Environment (ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]) (lc:UTF-8 fs:UTF-8 in:UTF-8 ex:UTF-8)

The width attribute is applied to the image not the block. So if your image has a width of 1200px, the block will still take 1200px but your image will only take 600px width.

So it really depends on your image width.
Here's an example when the image width is 640px:

As you can see there's not enough space for the text to be on the left of the image. As a consequence, the text is pushed above the image.

Now, the image width is 320px:

In this case, the text can fit of the left of the image.
Anyway, I think it's better to create an explicit two columns layout (Flexbox):

== Section

[.columns-2]
--
The exploded pie chart example "Europe browser usage share" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Pie Charts solution of the Graphs and Charts area in ConceptDraw Solution Park.

image::pict-exploded-pie-chart-europe-browser-usage-share.png["Europe browser usage share"]
--

== Section 

Some text.
Some text.
Some text.

.columns-2 > .content {
  display: flex;
}
.columns-2 > .content  > * {
  flex: 0 0 50%;
  padding-right: 2rem;
}

And here's the result:

Using a SVG image is probably another way to fix this issue.
Anyway, I am willing to accept a built-in feature if Asciidoctor PDF (Ruby) and/or the built-in HTML 5 supports it.

[ggrossetie]

Keep in mind that I might be wrong in my analysis. I'm not really familiar with the width, pdfwidth, or scaledwidth attributes so I'm ready to be proven wrong 😅

[pbrentlinger]

Ok, so I wasn't aware of the [.columns-2] thing. Clearly that is new with this web tech stack, and a useable workaround. (thanks for that)

However, from a plain text file, it doesn't seem rational that defining the width of the image would not also define the width of the generated content box's made by asciidoctor-pdf.js.
It seems likely that we'd want to use the pdfwidth for this tool. As of now, it does not use that at all (using instead the width only) but is used by the ruby version.

I've included the defined behavior from the user manual for reference.

29.3
29.3.2. pdfwidth

The pdfwidth attribute accepts the following units:

Unit	Definition
px	Output device pixels (assumed to be 96 dpi)
pt (or none)	Points (1/72 of an inch)
pc	Picas (1/6 of an inch)
cm	Centimeters
mm	Millimeters
in	Inches
%	Percentage of the content width (area between margins)
vw	Percentage of the page width (edge to edge)

Asciidoctor recognizes the following attributes to size images when converting to PDF using Asciidoctor PDF:
pdfwidth - The preferred width of the image in the PDF when converting using Asciidoctor PDF.
...
If pdfwidth is not provided, Asciidoctor PDF also accepts scaledwidth, or width (no units, assumed to be pixels), in that order.

This floating-issue is a known problem in the ruby version. This web version is meant to deal with problems like this (this is how I found this project). For reference:
asciidoctor/asciidoctor-pdf#353 (comment)

[ggrossetie]

However, from a plain text file, it doesn't seem rational that defining the width of the image would not also define the width of the generated content box's made by asciidoctor-pdf.js.

Maybe but that's not how it's currently working in the built-in HTML 5 converter. The width attribute only applies to the image width (not the content box). Not sure if it's intended or not...

Ok, so I wasn't aware of the [.columns-2] thing. Clearly that is new with this web tech stack, and a useable workaround. (thanks for that)

It depends on what you want to achieve. If you apply a 50% width on a 320px width image, it will produce a 160px width image. Even if the content box has a 160px width that's not the same as a two columns 50% width layout.
On one hand, the width of your "image column" depends on the image width and on the other hand, the width of your columns will always be 50% of the page width.

It seems likely that we'd want to use the pdfwidth for this tool. As of now, it does not use that at all (using instead the width only) but is used by the ruby version.
I've included the defined behavior from the user manual for reference.

Looking at the code of Asciidoctor PDF, I believe that the following definition are equivalent:

image::timestudy2019.png["Patrick Brentlinger 2019 Time Breakdown",50%,pdfwidth=50%,scaledwidth=50%]

image::timestudy2019.png["Patrick Brentlinger 2019 Time Breakdown",50%,pdfwidth=50%]

image::timestudy2019.png["Patrick Brentlinger 2019 Time Breakdown",50%]

From the code documentation:

Resolves the explicit width, first considering the pdfwidth attribute, then the scaledwidth attribute and finally the width attribute. If the specified value is in pixels, the value is scaled by 75% to perform approximate CSS px to PDF pt conversion.

In your case, the value is the same (and not in pixels), so a width of 50% will be applied.

This floating-issue is a known problem in the ruby version. This web version is meant to deal with problems like this (this is how I found this project). For reference:

Actually, it does work if you use the following definition:

image::image.jpg[role="right"]

But the width of your image must be lower than the width of the page. Here's an example with a 320px width image: