Oxygen XML Forum

Hello,

The webhelp transformation (dita to webwhelp) now generates a index_frames.html plus and index.html. The latter redirects on the former. And it seems that standards have changed (badly for me) because I can't open most of the topic shown in my TOC. ( A workaround that seems to work: just rename index_frames.html to index.html and get rid of the original index.html.)

I do not understand yet how the redirection is done (which one of all the new js files) and what is the use of that new index.html. What does it bring useful ?

I must tell that the rendered files seem OK in normal browsers but I must show them through QT Web Kit, and for some reasons, 14.1 has trouble while 14.0 was fine. Probably all that new (and useful ?) javascript...

ALso : is there a clean way to not show the index tab (again in webhelp) apart from modifyig the transformation ? Maybe that new index.html can be modified easily ?

Hello,

index.html displays the WebHelp version without HTML framesets, that is everything is displayed in the same frame. It redirects to index_frames.html (the version with HTML framesets) only as a fallback if JavaScript is disabled in the browser because the version without framesets requires JavaScript for loading the Table of Contents and for navigation between topics, but the two versions are otherwise independent.

If you don't need one of the two versions you can remove the respective HTML file but the two WebHelp entry points (index.html and index_frames.html) can co-exist peacefully and can even be loaded in the browser at the same time (and opened at different topics) since they are independent.

We need more details for reproducing the problem with the topics shown in TOC (the Contents tab) but not opened in the right side of the page: what browser do you use (name and version), is JavaScript enabled in the browser, any error displayed by the browser when it loads the WebHelp start page. Can you send us a zip archive with a sample set of input files (a sample DITA map and the topics included in the map) and the WebHelp output files that were created from these input files and that are not opened in the browser?

Regarding the Index tab: it can be removed or hidden only by modifying the transformation, that is modifying an XSLT stylesheet, because currently there is no parameter in the transformation for toggling the generation/display of the Index tab. If you want to modify directly the output you can comment out the entire element <div id="indexBlock"> in the file index.html (or in the file toc.html if you start the WebHelp with index_frames.html).

Please note that the Index tab is generated in the output and displayed in the browser only if there is at least one indexterm in the input XML files. Would you not want to see in the output a tab that groups in categories and sub-categories all the indexterms from the input XML files? Can you tell us please why you would prefer to hide the Index tab?


Regards,
Sorin

Sorin,

Thanks very much for the answer. I already applied the (manual : ( ) workarouds and its ok for that part. For the non-working targeting of TOC objects into the right frame, I am still checking what is the problem. As I said earlier, its a a behavior inside a c++ application that uses and embedded browser, likely QT Web kit, but even the programmers are not sure (they just invoke wrappers to display the html). There is probalbly a javascript problem with that kit, but the fallback to a basic frameset doesn not seem to work.

I'll post more when I finish debug that issue.

s.

Hi,

Both the Chrome and Safari browsers are based on WebKit and we did not run into any issues in our WebHelp tests in these browsers. Please let us know what you find about running the JavaScript code in your embedded QT WebKit.


Regards,
Sorin

It looks like its the iframe you use in index.html (thenew one). Its is not supported by QT Web Kit (it's documented buggy or unfunctional).

Thank you for letting us know. I suppose you will have to wait for a bug fix in QT WebKit (or fix the bug yourselves ...)


Regards,
Sorin

i'll drop the suspiscion on the IFrame : it looks more like that a level deeper than 3 (in the TOC tree) wont open the topic. Keep you posted.

I can reproduce the behavior in the QT web kit 4.7.1 and the compiled "previewer" example. Just drop a deep enough index,html (like mine)generated under 14.1 map to webhelp in the code pane of that previewer and it behaves as I said.

Sent a zip to support.

After some debugging, i found that the new javascript (tocWDiv.js) code validates if the browser is Chrome(!?) before redirecting to index_frame. That did not happen through QT Web Kit because the browser name is ... 'Safari'. Since I need that redirection, I added a condition verifying that browser is 'Safari'.

I have my workaround.

I did not unserstand all the javascript though : why verify that file are not local ? But that's for another time.

Hi,

That check was added because if the Webhelp set is local (file://) then the Chrome browser displays unwanted warnings when executing JavaScript code that tries to load the content of an HTML file from the local disk and fill a <div> element in the DOM of index.html with that content. In this case (local index.html file and Chrome browser) the user is redirected to the old version of the Webhelp (the one with frameset) instead of the new one (with internal frames), in order to avoid unnecessarily scaring the Webhelp user. Maybe that is a protection in Chrome against malicious JavaScript code that tries to load a local HTML file, I don't know. The fact is only Chrome has this strict way of executing the JavaScript code and only for local files, this is why the condition was not imposed also for Safari, Firefox, etc.


Regards,
Sorin

OK thanks.

On the same topic, I think there is a glitch on the links generated in the "navheader_parent_path" (parent bread-crumb-style links): when there is more than one level (depth of parents) the first link has a "/" inserted before it, which results in a bad url (because the server looks at the root for that file)).

Moreover, that "permalink" always show with the linkToThis link. A pain, I have hidden it. Iguess it has uses when chunking, because i fail to get it. (This glitch is because the protocol detected from Safari under QTWebKit is "C:", which is not verified in dita2webhelpImpl.xsl [understandably]).

thanks

Hi,

What is the structure of your DITA map when you get a navheader_parent_path link that starts with a "/"? I can't get such an href value, at least not when all the topics are in the directory of the map or one of its subdirectories. Can you give a small example of the layout of the directories where the topic files are stored and which is the topic with a navheader_parent_path link that has an href attribute starting with a "/"?

If you prefer to send us some sample files (map + topic files, the WebHelp output files) for reproducing the problem, that will be great, too.


Thank you,
Sorin

You can use the ditamap and 4 levels I sent you yesterday. Behavior is visible in IE, Chrome, Safari.

i you click the 4th level in the TOC and observe the links (the 2 last enclosing parents) at the top of te topic, check the first link (outer parent): it points on root/<href>.

Hi,

Yes, I can see the wrong link in the level4.html page but we would need the source XML files for running the Webhelp transformation. I cannot get such an error by running the DITA WebHelp transformation on a test DITA map with more than 4 levels of depth.


Thank you,
Sorin

OK. the zip is sent.

Hi,

Thank you for the files. It was a bug and we just fixed it. If you need a build of Oxygen 14.1 that includes the fix just let us know.


Regards,
Sorin

I have this problem too. What I'm not clear on is why there is a setting in the transformation scenarios "Open in Browser/System Application" that is consistently ignored (index.html opens in the editor).

Hi Julia,

What is the system application associated with the *.html files on your computer (the application that is opened automatically when you double click an *.html file)? Is it Oxygen? That would explain why the index.html output file is opened automatically in the Oxygen editor when the Open in Browser/System Application option is selected in the transformation scenario.


Regards,
Sorin

That wasn't it. When I changed my default browser from Firefox to Safari, the problem disappeared.

Hi,

I just wanted to let you know that the problem regarding incorrect links from breadcrumb has been resolved in the latest maintenance build of Oxygen 14.1, 2012121012 (released on December 11th).

You can download it from our web site:
http://www.oxygenxml.com/download.html

The list of bug-fixes can be found here:
http://www.oxygenxml.com/build_history.html#2012121012

You can follow the release/build RSS feed here:
http://www.oxygenxml.com/rssBuildID.xml

Regards,
Ionela