Numbering does not translate in MS Word Output

[TechWriter57]

RoboHelp 2019 New UI

I created a topic that contains a procedure with steps. The first three steps are snippets (since they are shared between procedures), where the <ol> item for each snippet is defned for the associated number 1-3.  The remaining steps are plain topic content, starting with <ol> = 4.

The preview and HTML5 output show the steps correctly, starting with step numbered 1 and the remaining steps numbered correctly as 2-9.

When I generate the output to PDF, all the steps appear correctly (1-9)

When I generate the output to MS Word, all the steps appear as "1."

I need to generate MS Word because I need to tell the page breaks NOT to break at each Heading 1.

[Peter Grainge]

I just created a topic with a list numbered 1 to 3, then a few normal paragraphs, then I added another list that initially was numbered 1 to 4 but I restarted the number and got 3 to 7. So far so good in that test.

In Word I got two lists 1 to 3 and 1 to 4, which is what would have happened had I created the same content in Word.

It's not quite the same test as yours but close enough, I think. If you get the same, that confirms it.

I think in your earlier thread I said something along the lines of if the Word format suits.

At least in Word, when you right click, you don't have to think about what number it should be. There's a Continue Numbering option that works it out.

[TechWriter57]

I don't understand.  The second listing should be 3-7, not starting again at 1-4.  You told the second list to start at 3 (Word should understand this in the RoboHelp output, right?).

Why would it be one way in the HTML5 and PDF outputs, but now obeyed when output to Word.

[Peter Grainge]

It did work in Classic but Classic used proprietary HTML and maybe that was used to fix things in the Word output. 2019 uses strict HTML5 and CSS3 and maybe the same "fix" is not supported with that restriction. It could be a bug but I don't see it listed.

Right now though we have both found the same thing so that's the way it is for now.

I will see if I can find out more.

[TechWriter57]

To me its a bug.  HTML5, PDF, and Classic have no issue with it.  I will log it if I should.  Thank you for checking.

[Peter Grainge]

As you wish. I was going to try to find out if it can be fixed or if it is because of what I suggested, proprietary code that was in Classic that cannot be replicated when using strict code. The strict use means the anyone can use any HTML5 or CSS3 in source view to achieve whatever they want.

Let us know what response you get to the bug report.

[TechWriter57]

Peter,
I was just trying to be helpful with a bug report. I would appreciate it if you would look into it first and advise me if it can be fixed or not.

[Peter Grainge]

It's only a bug if it is something that Adobe can fix rather than it being down to the way Word works with strict code, in other words there's nothing they can do about it. That is what I am trying to find out. That will get a quicker answer.

Once we know that, then is the time to file a bug report, or not. If you file it now, then it's duplicated effort from Adobe. 

I will let you know what I learn either way, hopefully within a day or two weekend aside.

[Peter Grainge · Accepted solution]

This is something that Adobe can fix and will. It will not be in the next update but once fixed a private build will be available for anyone who wants it.

Anyone wanting this private build, please email me via my site and I will send you a link as soon as it is available. The download will be from Adobe's site.