Words breaking in export

[K Kelly]

Does anyone know how I might correct this issue with PDF exports?

If I input text that has any formatting (underline, bold, indentation, etc.), upon export to PDF, the word breaks. For example, the text THE would have TH on one line and E on another (see my attachment where the word LIVE is breaking).

We spend hours changing formats/text/etc trying to avoid this. Recently, had a very bad experience where someone didn't check ALL of their content on a client facing doc and it went out with a few occurrances of this. Then, our VP spent 2 hours trying to modify the text to recreate the doc, apologize, and send a new doc. -- Not a good customer experience or management experience.

This doesn't seem to be a priority to resolve. Logged an issue 2 months ago; they related it to CONF-24533 which really isn't my problem. I don't want to force wrapping of words. I don't want words to wrap.

I would appreciate any possible solutions to this.

I'm an OnDemand user, so I don't have access to much except to update the PDF Stylesheet.

[Karie Kelly · Accepted solution]

The following workaround was provided by Atlassian and it does work - however, the consequence is that long URLs will not wrap.

{code}

body, p, li, td, table, tr, .bodytext, .stepfield {word-wrap: normal;}

.wiki-content p word-wrap: normal;}

{code}

[K Kelly]

Thank you for the reply. I tried that as well as several other options I found when googling, especially those geared towards different browsers since the property isn't always supported across IE, Firefox, Safari, and Chrome. None of them, including this one, has any effect on the export.

It seems that the pdf generator is doing an override to whatever is actually being set in the CSS - the only time I could get a different outcome is when I applied a property to not wrap within table cells - that was an interesting outcome as it only applied the style to the first row of a table. All other table rows ignored the CSS and wrapped the content.

Anyway, it appears to be an issue in the generator. And, a major issue for us since you have to proofread all of your documentation in such detail and then rewrite and go outside of your doc standards (e.g. I cannot italicize a menu selection, for example), to try and get it to work - this requires exporting numerous times testing changes (e.g. for one doc that is 10 pages long, we might have to go through 50 rounds of this to get it to work).

We had been using it to create 100's of PDF pages because we *want* it to be our source for all customer and prospect facing materials. And, this solution worked prior to the RTE switch. As an OnDemand user, we had no control about upgrading, but also not given any forewarning of the lost functionality, lost solution value, and all of the problems since the PDF export has several problems and cannot be considered a working solution. Unfortunately, based on what I've seen in the plans, there are also no near-term plans to consider these fixes in the roadmap.

It puts us in a real predicament as we are forced to now consider other wiki solutions that do provide this critical feature and often touted value proposition for creating a single collaborative source for generating documentation.

If Atlassian creates PDF documentation using Confluence, how are they getting around this because I encounter this issue on practically every export I do?

[SimonS]

Definitely feel your pain KKELLY and I would hate to have this make you move to a different wiki. I don't think we use the PDF export option too much internally since we prefer to keep all of our documentation online.

In any case, the best place for you to voice your concerns is CONF-24553. I saw that you already left a few comments stating your concerns but we haven't replied to them. Let me see what I can do from my end.

Sorry I can't provide a clear route forward right now. Please keep tabs on the issue to see our updates to it.

-Simon

[Felicity Chapman]

Just found a workaround to this issue in JIRA. Anyone else who's suffering from this may want to vote for this issue and may find the workaround posted there useful.

CONF-26230

[Anna McDonald]

I upvoted this issue as it is still a problem in v5.6.6.

[DavidH]

We have seen this same problem. It's terrible. It causes multiple typos in our manuals; it looks like the writing was done by a monkey.

The suggested CSS fix "might cut off long words." That's a workaround?

[Karie Kelly]

There are many issues associated with the PDF export. It seems there is minimal interest from Atlassian in resolving; I guess it's not a core product feature given that stance....

Personally, I wish they would spend some time on some stabilization sprints instead of new features. If we got features to work, we would feel like we have new features because they can then be used and rolled out!

[SimonS]

It is not a full workaround, but it may work for some cases. In any case, we hope to have this fixed in the next version of Confluence.

[SimonS]

Hi KKELLY,

Sorry for the trouble with this. The problem comes down to the CSS3 word-wrap Property. The original problem we tried to fix was that long words were getting cut off in a PDF export. So, by default, we added the word-wrap:break property to the PDF Stylesheet. This helps to not cutoff words, but it doesn't help with the problem you described.

Try adding this to the PDF Stylesheet:

div {  
    word-wrap: normal;  
}

This may cutoff long words though, I'm not sure.

The linked issue (CONF-24553) is related to your issue, but not quite the same. In any case, it is a bug that we will have to resolve on our end, probably.

-Simon

[Steffen Heller]

Hello,

although it might not be the exactly same topic I would like to mention something similiar.

I recently witnessed strange word breaks in my tables, something like

Lumino
us flux
at 3,0
00 K

I also tried the workarounds discussed here. In this specific case (word breaks in a table cell) I could resolve it with a

table {
table-layout: auto;
}

These word breaks started to show after our upgrade from confluence 3.x to 4.2x so I guess the old version already had an "auto" setting whereas the new version must have changed to "table-layout: fixed".

Is this possible?

[Karie Kelly]

This issue was definitely introduced with the new RTE; we had no issues in 3.x

If you have upgraded to 4.x, you'll find the export has several issues that have already been communicated and logged - however, there's been no update or progress.

You cannot rely on it to make professional documentation. Or, if you try to, you'll spend HOURS rewriting and reformatting in an attempt to create something that only took minutes in 3.x (whether it was first time worked, or you could easily make modifications in the wiki markup that the RTE doesn't allow you to do). This was a core feature for us and had to move it out of the wiki. Nothing like having to create documentation twice.

You're best solution is to not use Atlassian's export and to purchase a plugin if you are not in OnDemand

[DavidH]

And to expand on my comment above:

I tried the workaround posted here by Simon. On the first page of the first chapter, the phrase "Log In" had a line break at "Lo"

[Steffen Heller]

I witnessed the same problem. In my PDF documents I often found word breaks in automatically generated cross section texts like "...xyz (see chapter "soandso", p
age 12)..." So I thought it had to do with this.

But reconsidering I figure that the common denominator is that it is linked text. I also tried a few things with the "word-wrap" attribute but couldn't solve it.