Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Creating HTML from SMCL log file including graphics - revised log2html.ado


From   "David Elliott" <dcelliott@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Creating HTML from SMCL log file including graphics - revised log2html.ado
Date   Fri, 19 May 2006 12:30:20 -0300

All well and good, but as the king said in A. A. Milne's "The King's Breakfast":

"Nobody,
My darling,
Could call me
A fussy man -
BUT
I do like a little bit of butter to my bread!"

It would be nice if SMCL supported graphics natively, but in the
meantime, -grlog2html- will do the job, even when logging an
interactive session.  Since the HTML can be imported to Word or
WordPerfect and then exported to pdf one can get the output into most
useable forms.

The most important thing is to manage the workflow in the best
possible way to reduce manual copying, reformatting and such that is
drugery and error-prone to boot.

DCE

On 5/19/06, Phil Schumm <pschumm@uchicago.edu> wrote:
On May 19, 2006, at 8:35 AM, John Novak wrote:
> It seems to me that the SMCL folks need to be talking to the XSLT
> folks.  I would not even classify myself as a novice with respect
> to XSLT, but from my very limited understanding it would seem to be
> perfectly suited to handle tasks like translating code from a
> structured markup language into viewable HTML.


XSLT would not be useful here, since SMCL is not XML.  What would be
useful, if someone wanted to undertake it, would be to write an XML
schema capable of representing all of the SMCL constructs.  Once this
was done, one could then write a utility (perhaps in Mata, but
probably in another language) capable of parsing SMCL and translating
it into this hypothetical XML document format.  At that point, people
could begin writing XSLT stylesheets to translate this into HTML,
LaTeX, PDF, DocBook, OpenDocument, etc.  Moreover, one could
programmatically manipulate the resulting XML document to do all
sorts of things.

Of course the real question is, is this worth doing?  Consider three
cases:

1) Using Stata to analyze and write papers.  While the world would be
a better place if all journals accepted submissions in an open
format, I suspect that many users are submitting to journals that ask
for Word format.  For these poor souls, doing anything more with SMCL
output would probably not be helpful.

2) Using Stata to prepare class materials, web-based instructional
materials and simple reports, etc.  Users doing such things might
benefit from more output flexibility and processing tools, however it
may be that existing approaches such as those used by -log2html-, -
grss-, -do2htm- are sufficient in most cases.

3) Using Stata as part of a larger system to programmatically
generate reports and other types of documents.  This is where a
comprehensive approach would be most useful, however users doing this
have probably already put a lot of investment into established
procedures, and so such an approach would have to be flexible and
modular to be of value to them.

My only point is that I think a serious discussion of use cases
should proceed the making of grand plans to write additional
processors for Stata output.


-- Phil

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/


--
David Elliott

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index