So I went and created the $CHAR wrapper utility function and got it to work; It wasn't *quite* as simple as I thought it would be (couldn't simply pass the whole string parameter through to $C, and need to remember to pass the param as a single quoted string) so I thought I would share in case someone else wanted to go this route :)

As before, review the instructions for Defining Custom Utility Functions and ensure the class extends Ens.Rule.FunctionSet

/// Wrapper to built-in objectscript function $CHAR.
/// Intended use = linebreaks ($C(13,10)) in routing rules (trace) where CRLF not easily accessible.
ClassMethod Char(pCharString As %String) As %String
{
    #dim outString,thisChar As %String = ""
    #dim numChars As %Integer
    s numChars = $L(pCharString, ",")
    //q:(numChars<2) $C(pCharString)
    if (numChars<2){ s outString = $C(pCharString) }
    // more than one char, iterate over them to call $C and build outString
    else{
        for n=1:1:numChars {
            s thisCharCode = $P(pCharString, ",", n)
            s outString = outString_$C(thisCharCode)
        }
    }
    q outString
}

I originally had the post-conditional quit for the single-char cases, but felt assigning and using outString was slightly better since it was more consistent coding. Though I wonder if the post-conditional is slightly more efficient... (very outside of my wheelhouse)

Then make sure to pass a single quoted string in the Routing Rule, but otherwise it's just like calling $C:

In my experience, most/all $ objectscript functions ($CHAR, $PIECE, etc) are not available for use in a Routing Rule.  Some of them ($PIECE for example) have "built-in" workarounds in the defined Utility Functions - so in the rule, you can just do "Piece(foo,bar,x,y)" just like you would normally use elsewhere, sans $.

My use case for wanting a linebreak available in a Routing Rule is slightly different from @Erin Dolson 's
(I wanted to output some slightly neater Trace messages) but I think what I did below would work for that + other use cases as well.

Just for fun / to prove it is possible, I created a workaround that will retrieve a $C(13,10), by using a custom utility function:

1. In a class that was already extending Ens.Rule.Functionset, I defined a new classmethod:

/// Get linebreak chars (Carriage Return, Line Feed; ASCII 13, 10). Intended for use in routing rules (trace) where CRLF is not easily accessible.
ClassMethod CRLF() As %String
{
 q $C(13,10)
}

2. In my Routing Rule, I call the function in a Trace (or Assign) action's Value node like any other:

and the trace itself looks like:

[You could easily modify the new utility function to pass back any other char - or really, the best solution IMHO (which I will probably end up implementing in my environment) would just be to create the full wrapper to $CHAR itself via a passed parameter and call it "CHAR"]

FYI / N.B.: I'm on HealthShare (Ensemble) Health Connect 2018.1 but I'm fairly sure this should work for at least as far back as 2016 if not earlier since custom utility functions have been supported for quite some time.

Has anyone ever converted an HL7-embedded Base64-encoded PDF TO (HL7-embedded) RTF?

This looks great, but i noticed the linked LibreOffice conversion table seems to indicate PDF can only be exported (conversion target), not imported (conversion source)

Honestly interested in PDF of any kind; "converting" B64 PDF to a flatfile *.pdf is trivial, but it looks like using *.pdf as a source is not supported for LibreOffice method?

FWIW: Ensemble v2016.2 on Windows