On Wed, Apr 7, 2010 at 10:22 AM, Hussein Shafie <[email protected]> wrote:
>
> --> ditac.bat which is basically:
>
> java com.xmlmind.ditac.convert.Converter %*
>
> works as expected. Your problem does not come from here.

>From the point of view of a user, yes, it does. This was my point of confusion.


> --> com.xmlmind.ditac.convert.Converter *internally* (that is, you
>
> cannot see it unless you read the Java source code) invokes the
> following helper applications: Apache FOP, Render XEP and XMLmind XSL-FO
> Converter.

Yes, we are not Java programmers (yet, it seems like we will have to
become Java programmers to be effective users of DITA.)


> It does so by executing something like:

> cmd.exe /s /c "fo2docx.bat foo.fo bar.docx"

> Now, in the above case, for an unknown reason, *cmd.exe*, always exits
> with a 0 (success) code whatever fo2docx.bat may return.

In my lost hours of debugging this, I found info on the net which says
that removing endlocal will fix this. In my toy little .bat file
experiments, this proved to be true. Microsoft documentation on the
command processor says that it will do an endlocal command at the end
of .bat files automatically. All the setlocal/endlocal examples that I
found on the web, few used endlocal as the last thing of the file.
Removing that might solve my problem, but I do not want to have to
tell my group that they have to modify the ditac distribution. I
suggest that you consider this change (after you have tested it to
your satisfaction) for future releases.


> Therefore com.xmlmind.ditac.convert.Converter thinks that fo2docx.bat
> ran OK and, in consequence, com.xmlmind.ditac.convert.Converter itself
> exits with a 0 (success) code.

> In summary, your problem is caused by *cmd.exe* not forwarding the exit
> code of its /c  argument, when this /c argument happens to be a .bat file.

> We currently don't see how to fix this problem.

See above. When I delete the endlocal line from fo2rtx.bat, I do get a
non-zero status 'all the way back to my wrapper. The Java code says
that the fo2docx.bat file returned an exit status of 2, but Java then
returns an exit status code of 5.


> It took me 3 hours to understand what happened and to suggest a
> workaround. Please take the time to carefully read my answer to your
> previous email.

I have. We are not ditac implementation experts.
If it took you, the authors of ditac, three hours to track it down, it
probably would have taken me a week.
Thank you for your investigation.


> PS: Such problem cannot happen on Mac OS X and on Linux. It is really
> specific to Window's cmd.exe.

Yes. I am not happy about doing this work under Windows for many
reasons, this is just one of them.

> PS 2: By design, XMLmind XML Editor and XMLmind XSL Utility, which both
> tightly integrate XMLmind DITA Converter, have no such problem.

> Moreover these graphical applications both automatically detect the case
> where the generated .docx file (or .pdf file) is already opened in
> MS-Word (or in Acrobat Reader).

Yes, for reasons you don't care about, we need to script our
invocations of ditac in a way that the GUIs are not convenient for.


I hope you will be able to reproduce and verify our success with
removing endlocal from fo2docx.bat (and the others) so that we can
avoid this problem going forward with a 'as released' version of
ditac!

Thanks,
    -Doug
 
--
XMLmind DITA Converter Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/ditac-support

Reply via email to