Direct unicode representation for table and figure display

[Girish Venkataraman]

I use StataNow/SE 19.5 and have been using this process of loading the needed unicode characters via local macro from a do file holding all of these within local macros (in an include do file) for downstream use in dtable docx outputs, inline putdocx results and figures.
Is this the best way, or, can unicode characters be represented directly somehow end to end within Stata?

I was planning on storing variable level labels and levels in an excel file which supports unicode symbols and culling from that instead of a do file. I generate some figures in R and was thinking excel->json->R with direct unicode is feasible but for tables and survival graphs I use Stata. See below for current workflow which is working otherwise.

 local    le     =  ustrunescape("\u2264")
local    gt     =  ustrunescape("\u003E")

cap label drop age60lab
label define age60lab      0 "`le'60 yrs"                  ///
                           1 "`gt'60 yrs"  

labelbook

-----------------------------------------------------------------------------------------------------------------------------------------------
Value label age60lab
-----------------------------------------------------------------------------------------------------------------------------------------------

Values Labels
Range: [0,1] String length: [7,9]
N: 2 Unique at full length: yes
Gaps: no Unique at length 12: yes
Missing .*: 0 Null string: no
Leading/trailing blanks: no
Numeric -> numeric: no
Definition
0 ≤60 yrs
1 >60 yrs

[Leonardo Guizzetti]

Do files are text files, and Stata understands UTF-encoded text files.There's nothing wrong with the current approach of using locals to define Unicode characters/strings. You can do this by unescaping the Unicode sequences as you have done, or just using a string that directly contains the symbol(s) you want in the definition of the local macros. If you define many of these, it can become a little clunky. However you could also directly use those characters in your labels and remove the need to define these locals at all.

I won't comment on your R workflow except to say that using JSON as the middle step between Excel and R is unnecessary.

[Girish Venkataraman]

Thanks much, Leonardo Guizzetti You are right. I did not need this convoluted process to load unicode chars into macros to pass them in. Earlier I did not have a good way to type them into do files as they should display. I guess everyone just copy/pastes unicode chars into do files? As you said, direct unicode chars did work in tables (dtable) and graph labels. I pasted one directly here into my custom km plot ado -grsurve-and it worked like a charm as seen in panel A. I only do a little finagling for superscripts, subscripts and italics on the backend in that program. The R workflow is mostly for mirrored bar plots and oncoprint. Nothing beats Stata for inline putdocx code and table construction.

local stratvar who_mh
local rt yes
local commonopts plot(km) ciband(yes) relab0() relab1() subtitle(" ") risktable(`rt') ///
    switchcol(no) scale(months) note() nodraw

grsurve `stratvar', `commonopts'     ///
    title(TP53 allelic state‡-Entire cohort)     ///
    sups(‡) subs() ital(TP53)             ///
    pan(A) name(A, replace)

grsurve b20, `commonopts'     ///
    title(Blast count-Entire cohort)         ///
    sups() subs() ital()    ///
    pan(B) name(B, replace)

grsurve `stratvar' if inlist(b20,0), `commonopts'     ///
    title(TP53 allelic state in MDS subgroup)         ///
    sups() subs() ital(TP53)    ///
    pan(C) name(C, replace)

grsurve `stratvar' if inlist(b20,1), `commonopts'     ///
    title(TP53 allelic state in AML subgroup)     ///
    sups() subs() ital(TP53)            ///
    pan(D) name(D, replace)

gspanel 4 yes horizontal "km4" "Figure 2"

[Leonardo Guizzetti]

I guess everyone just copy/pastes unicode chars into do files?

I can't speak to how most people work with Unicode, though I suspect many don't ever need to. Many years ago I found a very helpful and free Windows utility called WinCompose that allows for keyboard shortcuts to enter Unicode characters. It easily handles symbols, accents and other languages (including emojis).

[Stephen Jenkins]

Leonardo Guizzetti thanks for the WinCompose tip! Girish Venkataraman Can you please tell us more about your -grsurve- and -gspanel- programs, including whether they are publicly available? (I can't find them with -search-). Thanks

[Girish Venkataraman]

Thanks for asking Stephen Jenkins about this wrapper. I have been meaning at some point to streamline the program and write some help for it. At this time, it is a poorly documented set of backend scripts that run KM or (FPM with stpm2) with nested smaller scripts to finagle p-value and text/unicode format displays at desired locations on plot region and outputs single plots with labels. gspanel then accesses all these from memory outputting a PNG and/or PDF with panel numbering.

Has served me well for 3-4 good publications so far. Many options and paths may be hardwired for my use cases, so they need cleaning up in those portions. My dream was to present this as a poster in an upcoming Stata conference although folks might laugh at how poorly it is written. I would like for a real biostatistician to review and comment on improving this wrapper making sure the math is right and to get it to an SSC ready state. I have never contributed to the SSC and am happy to share whatever backend I have offline if you want to play with it and make it robust from a statistical and cosmetic perspective. Perhaps reach out to my university email at [email protected] and I am happy to share in a stable way hopefully not dumping a virus with unstable code.

[Stephen Jenkins]

Girish Venkataraman I am definitely not a biostatistician. However, I would encourage to you to take courage and "go for it". Tip #1: existing code (and help file text), especially that written by StataCorp, can be a great source of inspiration -- and direct borrowing (with appropriate acknowledgement) is fine. Tip #2: if you are developing a new estimator, get it 'validated' -- e.g. by citing the relevant source article in an approprriate peer-reviewed jjournal (and/or doing your own Monte Carlo simulations to validate) -- and try and replicate published results from someone else (assuming you can get hold of their data). Good luck

[Girish Venkataraman]

Yes. I am now inspired to do it. Both tips are very useful, Stephen Jenkins No fancy estimators on backend. Just the usual stcox and stpm2 by Paul Lambert. I do not know enough statistics to confidently try validations with MCMC methods (and too reluctant to use AI blackbox methods).