Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Re: st: RTF issues (and Stata 13 wish list)


From   "Roger B. Newson" <r.newson@imperial.ac.uk>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Re: st: RTF issues (and Stata 13 wish list)
Date   Thu, 10 Jan 2013 12:20:34 +0000

As it happens, my RTF reports also frequently contain text. And it happens, even more frequently, that I would like to include a block of text in a generated RTF document, and am deterred from doing so by the fact that this presently involves a lot of laborious -file write- commands.

What I would like to see (in Stata 13 or maybe 14) would be a version of the -input- command, which inputs a single unquoted string variable, one observation per line, from an in-stream text block inside a Stata do-file. Or, more generally, a version of the -input- command, which inputs a list of string variables of set length, in fixed-width format, from an in-stream text block inside a Stata do-file. Either way, the in-stream text would be terminated by a terminator string, which could be set by the user, and Stata would then return control to the next command in the do-file. That way, I could include, in my do-file, a block of RTF text, stored in a temporary Stata dataset in memory, which I could then output to my generated RTF output file.

I am sure other users could also find uses for such a facility.

Best wishes

Roger

Roger B Newson BSc MSc DPhil
Lecturer in Medical Statistics
Respiratory Epidemiology and Public Health Group
National Heart and Lung Institute
Imperial College London
Royal Brompton Campus
Room 33, Emmanuel Kaye Building
1B Manresa Road
London SW3 6LR
UNITED KINGDOM
Tel: +44 (0)20 7352 8121 ext 3381
Fax: +44 (0)20 7351 8322
Email: r.newson@imperial.ac.uk
Web page: http://www.imperial.ac.uk/nhli/r.newson/
Departmental Web page:
http://www1.imperial.ac.uk/medicine/about/divisions/nhli/respiration/popgenetics/reph/

Opinions expressed are those of the author, not of the institution.

On 10/01/2013 02:45, Jeph Herrin wrote:
I looked at it, but my reports involve lots of results embedded in text,
as well as a number of tailored tables. Mail merge can't help with this.

thanks,
Jeph

On 1/9/2013 9:08 PM, Austin Nichols wrote:
Jeph--
Have you tried the mail merge trick?
http://www.stata.com/statalist/archive/2004-06/msg00301.html
There is usually some magic with F9 or Alt-F9 required, but it can
easily produce 1600 Word files. You make a list of graph file names,
and whatever other report specific fields, in Stata, then make your
template in Word and mail merge away.

LaTeX is better of course, but if you must have Word docs...

On Wed, Jan 9, 2013 at 7:33 PM, Jeph Herrin <stata@spandrel.net> wrote:
I tried working with -png2rtf-, but I wasn't happy with the resolution I
could get. I also found it difficult to embed in the output in a
larger RTF
file. These may have been the same problem, though, as RTF is uniquely
obtuse.

thanks,
Jeph



On 1/9/2013 5:18 PM, Austin Nichols wrote:

Jeph Herrin <stata@spandrel.net>:
You can use -png2rtf- (SSC) to write out automated files in RTF format
with a .doc extension that Windows users can double-click and see
images of a fixed size. Might take some trial and error with height()
and width() options on -graph export- and -png2rtf- before you get an
example that looks good to you.

On Wed, Jan 9, 2013 at 3:52 PM, Jeph Herrin <stata@spandrel.net> wrote:

Rebecca, Billy -

Thanks for the tips.

The current context is that I want to generate reports; 1600 of them,
every
month, each containing data specific to one of 1600 hospitals. Thus, I
require a totally automated solution. Moreover, the original
contractor
who
was going to do this pulled out with only a few weeks notice (a few
weeks
which included the end of year holidays) and I volunteered to do
what I
could, since I do maintain the various datasets. What I knew about RTF
was
that I could write it out as text files and Adobe would convert 1600
files
to PDF all at once. In addition, there's the questionable advantage
that
one
can export a Word file as RTF and insert the text directly into the
generated reports to achieve various images and effects that might
take
days
to work out otherwise. It's actually not a terrible solution,
except for
the
image size problem.

Still, I think if I had to do it again - and had a bit more lead
time - I
would move to LaTeX, having been a heavy TeX user a few decades
ago. RTF
had
the immediate advantage that the various parties that need to sign
off on
the reports could mark up the RTF versions (in Word, alas) and send
them
back to me.

Otherwise, I agree with Roger and Billy regarding the value of MS
Office
products, and MS Word in particular.

cheers,
Jeph



On 1/9/2013 12:30 PM, William Buchanan wrote:


Rebecca,

I would assume that if anyone was going to change the platform
they plan
on using they might choose instead to move to LaTeX.  Several
users have
already contributed programs that would allow someone to manage their
entire
document workflow in LaTeX via Stata (e.g., can add necessary
commands
in
LaTeX to insert/resize graphics, tables, text, etc...).  I agree with
Roger
on the position of the use of MS products.

However, the other solution would be to use some VBA Script to call a
macro that would reshape things automatically in the documents; this
still
doesn't solve the problem during import, but it is at least a little
time
saving.

HTH,
Billy

On Jan 9, 2013, at 9:23 AM, Rebecca Pope wrote:

Jeph & Roger,
I can't answer the question about fixing the size of the graphic in
RTF, but I can offer solutions to the enforced use of MS Word as a
precursor to obtaining a PDF and to Word altering the import size of
graphics.

1. My husband is a tech writer & he introduced me to Scribus (open
source alternative to Adobe InDesign, which to be fair I should also
mention as an option) to make PDFs. If you are composing your
text in
Word, it can be copied directly into Scribus & then you can add your
graphics there. Indeed, you can compose in any text editor or
even in
Scribus itself. Thus, you can bypass Word altogether if you want.
Scribus imports graphics with whatever dimensions you've saved them
but you can edit freely after that. You'll get better results in
terms
of resolution with the .eps files Roger mentioned.

2. If you are working entirely within MS Word and you want to
constrain the size of the graphic before you import it, you need to
insert a "drawing canvas" that is the dimensions of the existing
file
and then "fill" that canvas with your picture rather than importing
the picture. I'm not sure that is any better than just importing the
graphic and changing the size ex post. The one major advantage
that I
see is that you can put the canvas in as a place holder while you
are
adding your text and then insert the images after you've composed
the
text. My experience with MS Word is that it is rather crash-prone if
you are moving text around with a large number of images. Either
method will give you poor resolution because of the format of the
graphic you are constrained to.

Hope this helps,
Rebecca


On Mon, Jan 7, 2013 at 4:11 PM, Jeph Herrin <stata@spandrel.net>
wrote:


I always archive figures in GPH format, but I will see how .eps
looks
compared to .emf; I find .tif and .png to have poorer resolution
when
embedded, at least when converted to PDF, for some reason.

cheers,
Jeph



On 1/7/2013 4:03 PM, Roger B. Newson wrote:



Now you mention it, this is something I too would like to know. I
personally tend to use the .eps format, but the code generated by
-rtflink- does not preserve the specified sizes for that,
either. The
only recommendation I can think of is that, in general, the
definitive
version of a graph should NEVER be in a Microsoft proprietary
format.
I
personally view all Microsoft documents as ephemeral things,
which I
only produce because my non-technical customers want them.
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index