Vertical text in Word document doesn't convert to PDF

[fryguy700]

I have the following simple Word document that has vertical text:
simple_vertical_text.docx (24.6 KB)

I need to convert this Word document to PDF on Ubuntu via the command line interface. I used this command:
libreoffice --headless --convert-to pdf simple_vertical_text.docx
The libreoffice version is 6.0.7.3 00m0(Build:3).

This is the resulting PDF:
simple_vertical_text.pdf (56.2 KB)

Note how the vertical text is now horizontal and at the top of the page.

Any help would be greatly appreciated.

Thanks!

[erAck]

I don’t even see vertical text when opening the document. Though some odd misplaced (to the top right but below the Header area) header content, which seems to be a regression since LO 7.1, does not happen in LO 7.0 but even there the header is displayed belo the Header area, just not to the right. But that and earlier versions also don’t display any vertical text.

[fryguy700]

When you open the Word document, the vertical text is on the right side of the document. If you double click the footer, it allows you to edit the vertical text. This screenshot clearly shows the text on the right side of the page:

[erAck]

As said, I don’t see that, only the vertical frame but the actual content is horizontal in every release I tried, in current releases to the right of the vertical frame flowing out of the page border, in older releases across the top of the page but below the document title. Which I both consider to be bugs.

[mariosv]

Opening with 'Microsoft® Word para Microsoft 365 MSO (versión 2209 compilación 16.0.15629.20152) de 64 bits ’ shows the right box with vertical text.
But LibreOffice 7.5 shows like a horizontal line with the text at the top of the vertical box. Looks like a bug.

[mikekaganski]

@fryguy700 You never tell if you see the expected vertical text in LibreOffice or in Word.
And anyway: what you describe is definitely a bug.

I guess @Regina (the expert in shapes in OOXML documents) could clarify which issue is that.

[ajlittoz]

Independently from the possible vertical text bug, your document needs first a conversion from DOCX to internal format. Contrary to your assertion, your document is not “simple”. The vertical text lies in some “box” (not having M$ Word, I can’t tell which brand of “box” it is) which is translated as a Writer text box. A text box is a graphical object which is handled differently from text. The situation might be better with a text frame which is a full fledged sub-document but this requires that your document is saved as .odt. Text direction in frames is controlled by a setting in Options tab.

In addition, your document references Word-specific field names. Syntax {{ … }} is not interpreted in Writer.

[Grantler]

@fryguy700
I’m afraid that you have entirely to rebuild the document on Writer (following @ajlittoz’s arguments). At the moment a conversion doesn’t make sense.

[Regina]

The object has a horizontal text. The object itself is rotated by 270°. Shape are imported in Writer so, that the shape gets an attached frame. That is named “add text box” or “remove text box” in the UI, but it is in fact a frame. And frames cannot rotate. So you get a rotated shape with a not rotated frame.

Frames are able to render text in bt-lr (bottom-to-top then left-to-right) writing mode. You can try to use a not rotated shape in Word and set the Text Direction to “Rotate all text to 270°” in Word, see
ASK 2022_10_13 simple_horizontal_vertical text.docx (33.4 KB). But the text seems to contain some fields. I don’t know, whether bt-lr works with fields too.

[fryguy700]

Thanks for everyone’s feedback. The {{ … }} are plain text Jinja2 tags. I use python-docx-template to replace these tags with dynamic text.

The Word document that @Regina provided is certainly an improvement. However, when I convert the Word document to PDF the vertical text is pushed further to the right:
ASK_2022_10_13_simple_horizontal_vertical_text.pdf (56.8 KB)

[ajlittoz]

@fryguy700

The {{ … }} are plain text Jinja2 tags.

If you work totally in Writer (no idea how large your real file is to evaluate the manual conversion task), these tags can be replaced with File>Properties items. They are a built-in feature in Writer and their values are inserted with fields.

IMHO your present procedure is doomed to fail because you use Writer to convert between two external formats: DOCX which is not fully document (proprietary closed-source format), thus not fully understood by Writer, and PDF which also causes approximations to be made.