Replies: 2   Views: 2885
Replacevariablebyhtml() introducing leading space and/or newlines.
Topic closed:
Please note this is an old forum thread. Information in this post may be out-to-date and/or erroneous.
Every phpdocx version includes new features and improvements. Previously unsupported features may have been added to newer releases, or past issues may have been corrected.
We encourage you to download the current phpdocx version and check the Documentation available.

Posted by jcorrao  · 19-12-2017 - 18:20

Utilizing PHPdocX 6.5, with a minimally reproducible case being a bare document with a single template variable "bio-summaries"

$docx = new Phpdocx\Create\CreateDocxFromTemplate('./bioSummary.docx');

$stylesArray = array('<p>' => 'Normal', '<h1>' => 'Heading1', '<h2>' => 'Heading2');

$docx->replaceVariableByHTML('bio-summaries', 'block', "<strong>HELLO</strong> <em>world</em>! My name is <ul><li>First</li><li>Middle</li><li>Last</li></ul>", array(
    'strictWordStyles' => FALSE,
    'downloadImages' => TRUE,
    'wordStyles' => $stylesArray,


Regardless of any of the three options being provided or not, TRUE or FALSE as well, every line has a leading space, and every bullet point has a leading space as well.

I have taken care to test it with a wrapper "<div>" and stripping out "/r" "/n" "/r/n", etc from the input as well, but to no avail.

If anyone could please assist in discerning the cause of the issue, it would be much appreciated.


It seems after further diving, that it's a problem with HTML2WordML's render functionality that renders each WordML token with a newline despite the input having no newline.

Posted by admin  · 19-12-2017 - 19:24


UPDATE: New releases of phpdocx set a very high wrapping value to prevent bugged Tidy versions (that don't recognize 0 as a valid wrapping value) adding extra line breaks when reading HTML contents that generated extra blank spaces in the DOCX.
On there's more information about this same question (Extra blank spaces added to the beginning of paragraphs section).


Posted by jcorrao  · 19-12-2017 - 20:11

Thank you for your response. I have been looking into it further and was about to update/edit my original post.

It seems that the addition of libTidy had caused the issue, and that forcing it to not use Tidy fixed our issue.

The libTidy release in question is "2017/11/25". After attempting to reproduce the issue elsewhere, it seems that libTidy "2017/03/01" works just fine and that our production libTidy is "too new" or has another issue we aren't seeing.

Right now, forcing the "_load_html()" function to take the non-Tidy branch fixes our issue.