Overriding Html View

[gcrews]

I noticed in the journalist doctype when you change to the html view it just applies an xsl and CSS without running the toolkit. I poked around in the Xmetal folders but could not figure out how it overrides that. Do you need Xmetal developer to do that?

[Derek Read]

All of this is controlled via the file <XMetaL author install path>\Startup\multipleoutput.mcr

This stuff is documented in XMetaL Developer under the topic "Formatting Object" if you wish to implement something for other document types. To get the same functionality as the Journalist demo all you should need to do is implement one method in a script:

previewHTML()

PDF via Apache FOP (which we continue to install a very old version of) is also available via a similar API.

I have not had a look at this functionality with the 6.0 release which has been modified to attempt to play nicely with Windows UAC, so implementing this might require some additional mucking around to get files into the right location so that XSLTs (and MSXML in particular which multipleoutput.mcr uses) can write files out, etc.

See these topics (and the ones they reference) if you don't have XMetaL Developer:
http://na.JustSystems.com/webhelp/en/xmetaldeveloper/cg/6.0/cg.html#PDF%20and%20HTML%20previewing%20and%20printing
http://na.JustSystems.com/webhelp/en/xmetaldeveloper/pg/6.0/pg.html#Formatting%20Object

[gcrews]

Thanks for the feedback. I saw that function and poked around but wasn’t finding what I was trying to edit. What I was talking about was how when you’re in a journal file and go to the preview mode it opens up in about 1 second using journalist_Style.xsl. However when you go to preview a DITA file, it fires up the toolkit and takes about 10 seconds. I was hoping I could enable the same thing for DITA files and make some xsl and CSS files that would create a near match to the actual output without going through the toolkit and generating it quickly. Thinking about it now though, that’s not going to work well because of all the conrefs and filtering that the toolkit does but a single xsl transform could not very easily

[Derek Read]

Ah, I see. No, the whole system for generating output from DITA is configured to use the DITA OT.

I suppose in theory what you are asking for could be done but we don't have any plans to support it. Our Professional Services team might be contracted to cook something up for you, but the requirements would need to be quite specific (ie: non-localized phrases in one language like English, probably no importing of reusable content, no importing of conrefs of any kind, no conditional text, etc).

Is the main complaint here that you need to wait too long for the DITA OT to give you an HTML file?

[gcrews]

Not a complaint. I was just wondering if it was possible after seeing how the Journalist file works, but I see now that it would not work with dita. I didn’t want to have to completely change the Tag and Normal view CSS to get a close to accurate WYSIWYG view without having to full render it.
I noticed the Journalist DocType has a multiple CSS styles with buttons to switch between them.  That’s only for the Structure though and on Journalist files. I tracked that button down to the call ActiveDocument.RefreshCssStyleDoc.RefreshCssStyleToAppend(); but could not get it to work on a dita call. RefreshCssStyleDoc come back as null and I can’t find any info on it. Do you know if it’s possible to have multiple CSS files like that but for tag and Normal view with a similar call? I could probably make a macro button that would write a topic_ditabase.css that imports another CSS for each button and then just call the standard RefreshCssStyle() function. This way there can be one  CSS  for tag an normal view that shows the conrefs in gray, meta data, ect… and then have another CSS with it as close to output  format as possible.