Issues breaking strings of symbols in table cells

[shannonxtreme]

Some tables in our PDFs (DITA-CSS) have a string like the following: >>>>>>>>>>>9. In our PDF outputs, we use the overflow-wrap attribute to force long words to break within cells and not bleed. However, this doesn't force the >>>>>>>>>>9 string to break.

We use the overflow-wrap: break-word; attribute at the topic/entry level to break long words. This doesn't work on the string of symbols described above.

Code: Select all

			<row> 

				  <entry colname="col1">Record Count 

				  </entry> 

				  <entry colname="col2"> 

				  </entry> 

				  <entry colname="col3">4–13 

				  </entry> 

				  <entry colname="col4">>>>>>>>>>9 

				  </entry> 

				  <entry colname="col5">10 

				  </entry> 

				  <entry colname="col6"> 

				  </entry> 

				</row> 

Expected result:

string of symbols breaks without a hyphen (soft hyphen) and continues in the cell without bleeding

Actual result:

String of symbols bleeds into next cells without breaking

[Radu]

Hi Shannon,

I see you also asked the same question on Stack Overflow, I answered you here:

https://stackoverflow.com/questions/547 ... 6#54720236

I will also ask my colleagues who work on the XML + CSS to PDF support to look over your question and if they have extra advice they will update this forum thread.

Regards,
Radu

[Costin]

Hi shannonxtreme,

The ">" greater than is considered a special character and not performing wrap in this case is intended behavior.
For example, breaking a string where the ">" has the role of a the "greater than" operator could make more harm than good, changing the entire meaning of an equation or sentence.
The "overflow-wrap: break-word;" property works for words, but ">>>>>>>>>>>9" is not considered a word.

However, if you specifically need to use special characters in your table entries and want to perform wrapping on that strings, then Radu's suggestion should work.
As an alternative, you could also use soft hyphenation. The soft hyphen characters could be inserted (also manually, similar to the zero width space character Radu suggested), specifically where you need to break the string.
More details in the User-Guide.

I logged an improvement request for our development team to investigate if we should, or should not offer the possibility to wrap also the special characters string in a future version of oXygen.

Regards,
Costin