I'm trying to avoid updating the base plugin. However, I did try this without success. I'm wondering whether the fact that the page appears to be generated by js may be what's hampering getting the logo on that version.

That worked, Sorin but the other version of the webhelp (index_frames) doesn't get the logo. How can that be fixed?

I tried this:
This didn't work at all. I did try using div#productTitle with the same result. The other problem is that this won't work for the other format of webhelp because that div doesn't exist.

I used the div id for productTitle and did manage to add the logo as a repeating background image, but it did not work when I set it as no-repeat. So you were able to get multiple background-images but not a single image? Not exactly what's needed, is it. I will confess to not being very conversant...

I tested with the h1:before solution added in the CSS stylesheet com.oxygenxml.webhelp\oxygen-webhelp\resources\skins\desktop\toc.css and I confirm that it works in version 15.0 too. If it doers not work for you please send us your customization for the Webhelp transformation and your output direct...

Hi Sorin,

Finally got this right but the logo's being placed in the content pane and not in the area above, where the titles are.

Closer but not the right place.

I tried the same thing using the css file pointed to by args.css and it didn't work on oXygen 15. When I examined the index.html file, there was no img element prior to the h1.

Is it possible something's missing from the sample code?

Is there any conflict caused by running different versions of oXygen on the same machine?

I'm running XP Professional Service Pack 3. The problem is now consistently occurring, even after reinstalling. I I downloaded the 32-bit version but I can download and reinstall again. I'm getting this error on both new_hp_styles.ditamap and the second test document I sent you, testy.ditamap. I eve...

The problem came back. It's unclear why. I don't get the issue with these same files in 13.2.

Reinstalled and the problem went away but I'm now wondering if it'll return. Not sure why this is happening but I ran a number of WebHelp builds before it occurred again.

This is strange. I was able to run for quite a while and now it's failed again with the same problem. I'm not sure what's happening but something seems to get corrupted after a while. Going to try reinstalling again to see what happens.

Just downloaded and installed the latest build and problem is gone.

Even with the images in the same folder, the transform dies in 14.2. Do I need to download the package again?

The last test I ran was with the base transforms. Not sure why this is happening and am going to restructure the references so that all the image references are to the same folder as an attempt to minimize any other folders in the build.

I tried a different set of files in 13.2 and 14.2 with the base WebHelp transform with no modifications. 13.2 runs, 14.2 fails. I'll package up this set of test files along with the images used (though you'll probably have to redo the image references) into a single package for your use and send via...

Unfortunately, I do not have those other files. I will say that for this same set of files the WebHelp builds in 13.2 but does not in 14.2. I tried a different set of files and ran into the same issue - builds in 13.2 but fails in 14.2. I also have users who report that WebHelp doesn't build in 14.2...

I've already sent the sample files. I'll run the transform again and send the results of the log shortly.

Sorry. I should have remembered to add that information. The version of oXygen is XML Author 14.2, build 2013021115. There are no modifications to the OT bundled with the product. args.copycss = yes args.css = (path to css). args.hide.parent.link = no, args.xhtml.classattr = yes, webhelp.footer.incl...

Hi, Not quite sure why but when I try to build a DITA map to WebHelp, the transform fails even though I can successfully build to XHTML and CHM. In the result log, I get this message, which seems strange as I am successful with other DITA2HTML transforms. dita.inner.topics.webhelp: [xslt] Transformi...

Just sent the log.

I took a look at this thread thinking it might help in my case, but it's not quite what I need. I'm trying to integrate OT1.5.4 with version 12.2 of oXygen for some of my team. I've changed the OT directory and the libraries mentioned here, but I'm still getting a failure. What am I missing? Julio J...

Hi, As far as I know, there is no order restrictions on the sections within a task. However, oXygen seems to want <example> after <result> which does not make sense. The editor should allow <result> after <example>. (The only section restriction that makes sense is <prereq> before <steps> and <postr...

Hi Radu,

I'll be happy to participate once I acquire a version 13 license. It's on my list of things to do.

Thanks for the offer.

Julio J. Vazquez
SDI Global Solutions

Hi Sorin, It appears that the filetype must be lowercase for the OT. I am currently discussing this with the development team to see why it's so (other than the fact that XML is case sensitive) and if there's any valid reason to respect the case of the file for the transform. Would you like me to re...

Hi, I just tried transforming a ditamap that had its file extension in upper case (EXAMPLE.DITAMAP for example) to PDF. The transform failed. The case of the filetype should not cause this error. When I changed the extension to lower case, the transform worked. This occurred on Author 12.2, build 20...

Hi Sorin,

Understood. Thanks for your response.

Julio

Hi Sorin, The dir command only shows the directories on the C drive in XP. In any case, looking at Explorer shows that it does not have a drive letter assigned. This is as you expected. Opening the files is not the problem here, but building a document requires accessing all the files referenced by ...

I mapped the drive successfully, but when I tried to open it in oXygen, it never saw past the top level of the drive, even though I was able to see the files in Windows Explorer. I would think that I should just be able to click Open and open any of the files in the connected folder. Any ideas of wh...

I think it would make sense to have the Data Source Explorer map any resource to the local file system when the resource is connected through the interface. Doing this allows the user to build locally without requiring the manual mapping, which the user might forget causing frustration.

Thanks.