Reply To: XMetaL stops responding when trying to generate a file

[Derek Read]

Sounds like we have two completely different issues here, we might even have different products (XMetaL Author Enterprise vs Essential).

carmstrong is discussing generating output from DITA files. It does not use CSSToXSL.dll at all, it uses the DITA Open Toolkit. The XSLT is fixed (never changing) and it is never generated by CSSToXSL.dll. Various moving pieces can cause this issue, and which problem it is invariably depends on which of the over 1 dozen or so output formats being generated and the current state of the system (locked files by 3rd party software — most commonly an Adobe tool) and possibly other factors. In this case the product must be XMetaL Author Enterprise.

gcrews is talking about generating either HTML or PDF using functions defined in the multipleOutput.mcr file in Startup (nothing to do with DITA or the DITA OT). This is done via XSLT fed into either MSXML or Apache FOP and is configured to mostly work out of the box but by writing a little bit of additional script. The XSLT can be auto-generated for you by CSSToXSL.dll but you don't have to do it that way. That process can be modified by changing multipleOutput.mcr or by implementing your own transform process (and removing that MCR file). If you really think it is CSSToXSL.dll that is getting stuck you could confirm that by debugging to check that the XSLT is not being generated each time output is produced. The way it was designed to work (long long ago) is that once the XSLT has been generated once the code in multipleOutput.mcr is supposed to notice that the XSLT files are already there and not do it again. The multipleOutput.mcr should be fairly easy to debug if you can find a reproducible case.

Reply