Circumvented: DIV -> LI + Word Target = LI -> newline

[Phlawm53]

For Flares 10 or 11, Word (2007) Target.

If you have time to perform an experiment, try this:

1. Create a topic with an OL or UL.
2. Wrap one or more LI s in a DIV so that the LI is the first element in the DIV.
3. Gen the topic as a Word Target.

What happened to me is that in the Word Target, all the LIs were generated as "li_n", where "n" is an integer, followed immediately by a paragraph mark (a.k.a. newline) followed by a "p_n" that contained the LI's text. The result being that there was an empty list item with its contents on the next line of the Word document ala:

Code: Select all

4.

   LI 4's text is here.

PDFs and online outputs were unaffected.

After a bit of investigation, I noticed that all of the LIs that behaved this way were wrapped in a DIV. I was using a DIV that specified "page-break-inside: avoid" to, among other things, keep a LI on the same side of a page break as, say, a screenshot that illustrated the results of performing a numbered step.

So I tried removing a few DIV -> LI constructs and voila -- those formerly malformed list items in the Word document were now properly formed.

Having isolated the source of the behavior, I went through the project and removed the DIVS from all OL and UL list items. In the Word Target, the affected LIs no longer were immediately followed by a newline. But I missed a few instances. And when I reviewed the Word Target, I spotted those missed instances because they were still malformed as described above. I un-DIV'ed those overlooked DIV -> LI constructs and those items immediately joined the ranks of the properly formed.

So for me, this is a solid cause-effect linkage: Wrap a LI in a DIV to create an empty LI with its contents on the next line of the Word (but not PDF or HTML5) output.

I thought I'd describe this should anyone else be in the process of trying to deal with this issue.

I'd also be curious if anyone else can replicate the behavior in their Flare+Word NNNN environment (where NNNN is in my case 2007).

Cheers & hope this helps,
Riley
SFO

[Nita Beck]

Riley, I speed-read (sped-read?) your post so perhaps I'm missing the nuances (likely). But I just wanted to make sure that you understand that DIVs are not supported in Word output at all. If one of your targets (for anything other than a review draft) is going to be Word, then don't use divs. And for those Word targets used for review drafts, you may just need to inform your reviewers not to fret about any formatting anomalies. For example, I use divs for "extended notes", those having a nice blue shaded background, so say I'll have a Note paragraph followed by a list, image, or even table, all enclosed within the div. But in the Word review draft that I send out, we end up losing the blue background. I've rapped my reviewers over the head enough that they know to ignore the shading (or lack thereof).

[Phlawm53]

Hey Nita:

I figured out early on that Word doesn't "understand" DIVs from a positioning standpoint. I didn't realize that DIVs in general confounded Word in non-positioning ways.

If that's the case it gets in the way of using DIVs to, for example, manage page breaks in PDF Targets. I can accept that Word doesn't understand DIV positioning, but to need to create a separate...well, what exactly? A separate Word CSS stylesheet? Or?

Perhaps the "plan", such as it is, is that Flare ignores DIVs in Word Targets but otherwise doesn't introduce the behavior I described. That is, that a DIV affects a paragraph style's simple behavior of keeping its contents on the same line.

Cheers, thanks, & take care,
Riley
SFO

[Nita Beck]

I don't believe that it's that Word doesn't understand divs.

Rather, because Word does not support divs, I am fairly certain that when Flare generates a Word doc, it unbinds whatever is in a div from the div, that it, it strips the div tag outright.

[Phlawm53]

Rather, because Word does not support divs, I am fairly certain that when Flare generates a Word doc, it unbinds whatever is in a div from the div, that it, it strips the div tag outright.

That's perfectly acceptable.

But it does then affirm the problem I saw wherein LIs that were the first item in any sort of DIV were generated as:

Code: Select all

3. 

   Number 3's text is down here.

That is, the existence of the DIV caused a "li_n" to contain nothing but a paragraph break followed by a "p_n". If Flare simply ignores / strips out the DIV, that should not (he said) result in that demonstrably cause-and-effect behavior?

As stated in my original post, I am able to cause or suppress that behavior simply by wrapping a LI in a DIV then generating the content as a Word Target. I think that's a product defect, especially if Flare is simply ignoring DIVs(?)

By the by, in troubleshooting the problem I ended up finding an oddly malformed LI that was contained within a large P element. That too demonstrated the same behavior. So the malformation evidently occurs if a LI immediately follows any sort of container(?)

Cheers, thanks, & hope this helps,
Riley
SFO

[Phlawm53]

------

A quick update: Madcap support suggested that my use of a DIV to manage page breaks in lists could be supplanted by creating a LI class that included the page-break-inside: avoid attribute.

Cheers & hope this helps,
Riley

[dorcutt]

A quick update: Madcap support suggested that my use of a DIV to manage page breaks in lists could be supplanted by creating a LI class that included the page-break-inside: avoid attribute.

Thanks for sharing this Riley. I had been meaning to help confirm this bug, but got deadlined.

That's a great alternative implementation, and I'll convert over to this method myself.