dokuwiki-plugin-dw2pdf
dokuwiki-plugin-dw2pdf copied to clipboard
right float of images has limited support in mPDF
Hi,
it seems that the orientation of images - left / center / right - in relation of the text isn't completely supported by the plugin. So the syntax {{ picture.png}}
with the leading spaces generates the picture on the right side. But the text isn't written left besides the picture but below of it.
What can I do? Maybe, is there a workaround that I can use?
Best regards Juergen
Please check how the print preview in your browser is layouted. The print-layout is used for the pdf export, not the screen-layout. If this print layout is flawed, you could try to fiddle with the printing css (see css development page at dokuwiki.org) to improve this print preview. Suggestion here are welcome.
I'm sorry, but the print preview is correct
The mPDF library used by dw2pdf plugin, does only support float at block elements. https://mpdf.github.io/what-else-can-i-do/floating-blocks.html
And limited support for images https://mpdf.github.io/what-else-can-i-do/images.html#float-and-text-wrapping
The float is working, but the containing element, in this case the <p>...</p>
is extended at the bottom to enclose the last image.
Example:
Text text
{{ :picture.jpg?400|}} Text Section A text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text
Section B Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text Text text text text text
Section A is shown next to the image. But because the <p>
element closes at bottom of image, the Section B is moved to below the image, and whitespace is created between section A and B.
Text text
{{ :picture.jpg?400|}}
Text Text
If you put a picture not in text, it is wrapped in a separate <p>
element. This further empty paragraph closes also at bottom of images, so therefore you see no text next to the image.
Solution 1: add a workaround for images, I have no idea what. Suggestion welcome. Solution 2: mPDF has to improve this behaviour. Long term future, I guess.
I think this may work now with the latest version:
Tried it like this
or non-characteristic words etc.
{{ :testpages:3com.png?400|}} Why do we use it?
It is a long established fact that a reader will be dis
and like this
or non-characteristic words etc.
{{ :testpages:3com.png?400|}}
Why do we use it?
It is a long established fact that a reader will be dis
and got the same
No, not fixed.
and got the same
A test example should include an empty line:
{{ :testpages:3com.png?400|}}
Why do we use it?
It is a long established fact that a reader will be dis
P.S. First mentioned by The Creator 8 years ago: https://gist.github.com/splitbrain/1594388
This might be a temporary hack. Can't say, what does it break (hope, nothing). Any better ideas are appreciated!
Patch \plugins\dw2pdf\vendor\mpdf\mpdf\src\Tag\P.php like this:
<?php
namespace Mpdf\Tag;
class P extends BlockTag
{
public function open($attr, &$ahtml, &$ihtml)
{
parent::open($attr, $ahtml, $ihtml);
}
public function close(&$ahtml, &$ihtml)
{
}
}
As I can see it, our parent BlockTag inserts something that breaks floating in close() function. So, we tell mPDF not to call close() after P tags.
Okay, it does break WRAP boxes :(
Here. This one's better and doesn't break WRAPs. Still it's a hack, not a good patch. What we do is inherit P from an inline tag class instead of BlockTag and then add two BR elements to simulate margins.
<?php
namespace Mpdf\Tag;
class P extends InlineTag
{
public function open($attr, &$ahtml, &$ihtml)
{
parent::open($attr, $ahtml, $ihtml);
}
public function close(&$ahtml, &$ihtml)
{
parent::close($ahtml, $ihtml);
$this->mpdf->_saveTextBuffer("\n");
$this->mpdf->_saveTextBuffer("\n");
}
}
Unfortunately, the Imagebox plugin uses DIV, so patching P does not help. DokuWiki lists are also DIVs.