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.
Jeph Herrin <email@example.com>
Re: st: Re: st: RTF issues.
Wed, 09 Jan 2013 21:45:10 -0500
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.
On 1/9/2013 9:08 PM, Austin Nichols wrote:
Have you tried the mail merge trick?
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 <firstname.lastname@example.org> 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
On 1/9/2013 5:18 PM, Austin Nichols wrote:
Jeph Herrin <email@example.com>:
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 <firstname.lastname@example.org> wrote:
Rebecca, Billy -
Thanks for the tips.
The current context is that I want to generate reports; 1600 of them,
month, each containing data specific to one of 1600 hospitals. Thus, I
require a totally automated solution. Moreover, the original contractor
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
that I could write it out as text files and Adobe would convert 1600
to PDF all at once. In addition, there's the questionable advantage that
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
to work out otherwise. It's actually not a terrible solution, except for
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
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.
On 1/9/2013 12:30 PM, William Buchanan wrote:
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
document workflow in LaTeX via Stata (e.g., can add necessary commands
LaTeX to insert/resize graphics, tables, text, etc...). I agree with
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
doesn't solve the problem during import, but it is at least a little
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
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,
On Mon, Jan 7, 2013 at 4:11 PM, Jeph Herrin <email@example.com> 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.
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
version of a graph should NEVER be in a Microsoft proprietary format.
personally view all Microsoft documents as ephemeral things, which I
only produce because my non-technical customers want them.
* For searches and help try:
* For searches and help try: