Re: st: Re: st: RTF issues.

[Austin Nichols <austinnichols@gmail.com>]

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/