Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Help selecting font with collect style putdocx

    Hi,

    I am trying to export a collection to an MS Word document where the entire table uses the "Times New Roman" font. I am able to select this font for the table. But, when I use the collect style putdocx command to add a title, the title shows up in a different font and I can't determine how to get the fonts to match.

    Here is an example:

    Code:
    collect clear
    webuse nhanes2
    collect: regress bpsystol age weight
    collect: regress bpsystol age weight c.age#c.weight
    collect: regress bpsystol age c.weight##c.weight
    collect style autolevels result _r_b _r_se
    collect layout (colname) (cmdset#result)
    collect style cell, font(Times New Roman,)
    collect style putdocx, title(Models for systolic blood pressure) layout(autofitcontents)
    collect style cell, font(Times New Roman, size(11))
    collect export regression2.docx, replace
    The line containing collect style putdocx, title(Models for systolic blood pressure) layout(autofitcontents) sets the title, but it is in the Calibri (Body) font, not Times New Roman.

    Has anyone run across this and found a solution to display the table with one font?

    Sincerely,
    Alan

  • #2
    The 17nov2021 update to Stata 17 included many updates to the collect system. Relevant here, I think, is -collect style title- which now supports a font() option. This seems like it will solve your problem.

    Comment


    • #3
      Leonardo,

      Yes, thank you. I saw this update yesterday and am trying to see if some of the new commands address my particular issue. I think that the new collect title command might be useful as well:
      Code:
      collect title "string" [, options]

      Comment


      • #4
        I am writing to follow up on my initial post about controlling the font used in tables exported to MS Word files or Adobe pdf files. I was unable to find a solution to my issue so I contacted Stata technical support who responded quickly. Nobody seemed willing to label my issue as either a "bug" or a "feature", it just is what it is.

        In short, there is currently not an easy way to get the table font and the title font to match when reporting a collection of results to MS Word or Adobe pdf files. Here is a part of the support response:

        Please See page 4 of https://www.stata.com/manuals/tables...styletitle.pdf
        "These font style properties are applicable when publishing to Microsoft Excel, HTML, and LATEX files."
        .
        .
        .
        Also, notice that -collect export- is limited by the features supported in the -putdocx- and -putpdf- commands
        I wrote back asking for clarification:

        Thank you for your quick and thorough response. For clarification, it seems that it is impossible to match the font used for the title and the contents of a table when exporting a collection to an MS Word or Adobe pdf document.

        Is that correct? I find that a strange outcome.
        And, I received the following message with a suggested workaround and hope for future updates.

        I talked to the developers, who say that it is possible but not simple right now. They are seriously considering making this easy ASAP. At this time, they cannot say exactly when it will be available.

        In the example that you sent, the workaround would be adding a -dofile()- option to -collect export- like

        collect export regression.docx, dofile(mydofile)

        After executing the code, manually open mydofile.do and insert

        putdocx table tbl1(1, .), font("Times New Roman",11)

        below the command located near the top of the do-file, which looks like

        putdocx table tbl1 = (16,4), title(Models for systolic blood pressure)

        Finally, you would save the do-file and execute it.

        In the case of pdf, it should be similar as above.
        I hope that this is useful to others.

        Sincerely,
        Alan

        Comment


        • #5
          Thank you, Alan, for closing the loop on this issue and reporting a possible workaround. Let's hope the developers can work some magic and make this easier.

          Comment

          Working...
          X