#693 DOCX: empty space

[Mark Grimshaw]

With the following example HTML code from tinyMCE:
<sup>Blah</sup> <sub>Blah</sub>

there is a space between the closing sup tag and the starting sub tag. In DOCX, this should be converted to:
<w:r><w:t xml:space="preserve"> </w:t></w:r>
in libs/docx/format/TEXT::text().

However, in attempting to write the space the DOCX code above is never written and the resulting document crasheds in Word.

The way around it, to create a document Word can open, is to detect the space then not write anything (but this, of course, means the space is not written).

Rather puzzling . . .

Mark

[Stéphane Aulery]

And if you try to compose this directly in Word, what code is generated?

[Mark Grimshaw]

What I've noted above:
<w:r><w:t xml:space="preserve"> </w:t></w:r>

As far as I can tell, the code I generate is identical. It may be that there is some other code in another .xml file that needs to be in place and that I have overlooked.

Mark

[Stéphane Aulery]

And this space character is indeed ASCII 32 in both cases?

[Mark Grimshaw]

On 9 Dec 2024, at 17.43, Stéphane Aulery lkppo@users.sourceforge.net wrote:

And this space character is indeed ASCII 32 in both cases?

I'm not really sure how to check that but, in BBEdit, showing invisible characters for both the Word-generated document and the WIKINDX-generated document gives the same invisible character ( a horizontally centered dot).

I’m beginning to suspect that the problem might lie elsewhere because, if I test for only spaces in the input (libs/docx/format/TEXT::text()), detect it, then change the input to normal text characters, I still get the problem.

[Stéphane Aulery]

Yes, probably

[Stéphane Aulery]

I verified that this is not a side effect of \UTF8\mb_trim() that would modify $input by reference. One less track.