Any files you support should be designed to completely separate
(passive) data from programs that are executed.
Applications and data viewers may be used to
display files developed externally, so in general don’t allow them
to accept programs (also known as “scripts” or “macros”).
The most dangerous kind is an auto-executing macro that executes
when the application is loaded and/or when the data is initially
displayed; from a security point-of-view this is generally
a disaster waiting to happen.

If you truly must support programs downloaded remotely
(e.g., to implement an existing standard), make sure that you
have extremely strong control over what the macro can do
(this is often called a “sandbox”).
Past experience has shown that real sandboxes are hard to implement correctly.
In fact, I can’t remember a single widely-used sandbox that hasn’t been
repeatedly exploited (yes, that includes Java).
If possible, at least have the programs stored in a separate file, so that
it’s easier to block them out when another sandbox flaw has been found
but not yet fixed.
Storing them separately also makes it easier to reuse code and to cache
it when helpful.