How do you want them "printed"?

Do you want them as legend entries, or in a caption, or in textplots (positioned near x=1?), or...?

Do you want the values only, or like something=value, or...?

Could you please mention all your requirements when you first submit a Question?

@Axel Vogt Very nice.

I am not sure which version would convert the original directly to that MeijerG, but in several versions it suffices to go through GAMMA as an intermediate step.

Download ax_ex.mw

@Iza Your added requirement can be handled similarly to what I showed before.

For example,

f1:=x->a*x^2:
f2:=x->a*x^2+1:

Explore(plot([[eval(f1(x),a=A),x,x=-A .. A],
              [eval(f2(x),a=A),x,x=-A .. A]],
             color=["Red","Green"]),
        parameters = [[A = 0.5 .. 2.0, label=a]]);

If your f1 and f2 are actually as you've given them  then you might just as well assign the expression results of f1(x) and f2(x) to other names and the use those directly with parametric calling sequence of the plot command. This is more efficient because it invokes f1(x) and f2(x) just once, up front, instead of having those same calls be made for each value of the parameter under Explore. Eg,

f1:=x->a*x^2:
f2:=x->a*x^2+1:

expr1:=f1(x):
expr2:=f2(x):

Explore(plot([[expr1,x,x=-a .. a],
              [expr2,x,x=-a .. a]],
             color=["Red","Green"]),
        parameters = [[a = 0.5 .. 2.0]]);

Here is an alternative. It is not necessary for the f1,f2 procedures you gave. But perhaps you actually intend to use some different f1 and f2. In some situations a procedure might not sucessfully accept a mere name like x as its argument. That is, invoking f1(x) might produce an error if x is an unassigned name and not yet an actual numeric value. This alternative can handle such cases, but is slightly less efficient:

f1:=x->a*x^2:
f2:=x->a*x^2+1:

Explore(plot([[subs(a=A,eval(f1)),x->x,-A .. A],
              [subs(a=A,eval(f2)),x->x,-A .. A]],
             color=["Red","Green"]),
        parameters = [[A = 0.5 .. 2.0, label=a]]);

Using those assignments of doubly uneval-quoted plot calls -- like in your ealier attempts -- looks unnecessarily complicated and non-robust, even if it were made to work. I suggest not coding it like that.

In future, could you please mention all your requirements when you first submit a Question?

@Ahmed111 

As you've noticed, removing the assumption that lambda is also purely real seems to require additional adjustments -- in order to get Carl's suggestion of using evalc to produce as nice a result. I don't understand why you are only considering at Carl's Answer.

In my Answer I suggested using expand instead of evalc (under appropriate assumptions. I think that it is an easier way to get some of the cancellations -- including those you seem now to be mentioning. You could thus try working with the following (or adjusting it further, if you can):
  simplification_ac_L.mw

The final result in that worksheet almost looks like it might have an even simpler trigh form -- but perhaps it's a mirage.

I did not load the LinearAlgebra or PDEtools packages because they have nothing to do with this question. Loading packages that you don't need seems like a very poor methodology to me.

I suggest that the next time you ask a question about a simplification you let us know up front which (if any) of the variables have known qualities that might be used as assumptions (eg, x::real, t::real).

@Carl Love Yes, certainly sometimes evalc is worth it, and it can get some nice simplifications. Though, sometimes evalc can incur significant additional cost, and sometimes it can significantly increase the size of the expression. In my experience I find that both scenarios are common.

For the example at hand, posted by the OP, calling just the expand command with the mentioned assumptions makes all the exp calls cancel arithmetically and disappear. That's lightweight, for this example.

Naturally, one can always find examples where one command is more effective, and other examples showing the opposite. As we know, universal rules are scarce. This one example doesn't demonstrate superiority of any approach in general.

ps. I found a concoction for this example where the simplification produced what might be an invalid result. I suspect the culprit might be use of combine.

pps. I sometimes wonder if some people (not you, not Kitonum, etc) utilize evalc as a means of converting exp to trig, but without realizing the implications of the ensuing real assumptions. So I'll mention an alternative for that specific subtask:

evalc(exp(I*x));

         cos(x) + sin(x) I

convert(exp(I*x),trig);

         cos(x) + sin(x) I

@Carl Love Yes, thanks, although I already know that.

I had already edited my Answer's commentary, to state more specifically that calling evalc alone (without additional assumptions) can be incorrect here if the other variables (epsilon1, epsilon2, lambda1) are not purely real-valued.

It is quite possible that Kitonum's result is incorrect, in light of this. That's why I mentioned all this. We don't know if the OP's original input called conjugate on epsilon1, epsilon2, lambda1 because he consider them as complex-valued or because he copy&pasted from some earlier result of his own.

@Carl Love The OP has Maple 18, and the command you show will not do as well as it could (as as well as I suspect you are thinking) for a few reasons:

  - In that version Maple 18 calling simplify doesn't automatically follow up with simplify(...,size).
  - Calling simplify without options turns some terms with conjugate into abs, which then gets in the way of it finding the nicest factoring in that version Maple 18.

In Maple 18, if expr is assigned the result of the subs(...) call, then these produce the result(s) I suspect you have in mind:

simplify(simplify(evalc(expr),trig),size)
  assuming epsilon1::complex, epsilon2::complex, lambda1::complex;

map(simplify,simplify(simplify(evalc(expr),trig),size))
  assuming epsilon1::complex, epsilon2::complex, lambda1::complex;

simplificationCL18mod.mw

It seems quite a bit simpler to just make real assumptions on t,x,lambda (and proceed with the terse code I had shown in my Answer) than it does to call evalc and make complex assumptions on epsilon1,epsilon2, lambda1 and then apply these variants. The Answer I had given gets the same result as these above, with those real assumptions.

@Kitonum He has Maple 18, in which the final result of your worksheet would not be as your Answer shows, inlined.

In that version either of the following edited adjustments of your last command will produce the result you showed.

   simplify(simplify(evalc(A1)), size)

   factor(simplify(evalc(A1)));

I removed my Answer because I hadn't understood from the OP's initial wording that he wanted a periodic result.

Up vote for Tom.

@mmcdara What you have done is actually no different.

You are simply illustrating that in your Maple 2015 the act of printing Vector A causes a full evaluation of the entries.

Your "trick" to utilize names v||i instead of v[i] does not solve his goal in such later versions. The names in the entries are slightly different, but the behavior in question is the same.

The actual entry stored in A is still the same name.

Download trick_not_2015.mw

In more recent versions of Maple (2018.2 and onwards, say) the printing behaviour changed, and merely printing Vector A still shows the (whichever) unevaluated name.

@Carl Love I was thinking the same, but trying to not be pushy about it.

@Kitonum I have two queries about your Answer:

 -- Do you have suggestions about computing the full range the OP requested, t=0..2*Pi ?

 -- Are you sure about the integrand you used?

@CygnusX1 Did you see the transformer_with_short_CacDS.mw file earlier, in which the running best results can get printed, as DirectSearch runs? It also shows that you force-stopping the computation and still gettting access to the best result's parameter values.

The DirectSearch:-GlobalSearch command has a help page that shows some options for the command. Global optimization is often not easy, especially in the case of several variables (and possible nonlinear objective), and more so if you really need the very best result and not just the best possible within a given number of objective evaluations or time limit.

You could also try rewriting the inner maximization problem to also utilize DirectSearch (instead of the Optimization package and workarounds for it that may slow the objective or prevent it from being evalhf'able). You might be able to get by with your original expression (no frills, even with that abs call). I didn't optimize the inner problem for speed because I didn't know originally that you would be doing that later attempt of global optimization with more variables.

You might also be able add options to DirectSearch so that it did not try to polish results to high accuracy, focusing on attaining coarser results more quickly.

@NeraSnow The reason that you example is not documented in the Help page for Topic Gcd is that this behaviour is not specific to only that command.

The rebinding behaviour of the with command can affect most any name, depending on the particular names of the exports of the package being loaded. The behaviour you describe as "sneaky" is mostly the whole point of the with mechanism.

And it is documented in the Description of the with command's Help page. Ie,

   When with is called with the name of a package as its argument, it binds
   the names exported by the package to the global namespace. This makes
   the exported names available to the interactive user at the top level of the
   Maple interaction loop.

As mentioned, you can continue to utilize the original global name via the colon-dash syntax. And you are not forced to call with. You could, alternatively, utilize the explicit long-form names of package exports. You could also utilize with to load/bind only some select package export.

@CygnusX1 Here is a reworking of your previous Reply's attached worksheet, with some workarounds:
 - to get it to run (here, Maple 16.02)
 - to preserve the best result found so far, if it accidentally bails early with an error

transformer_with_short_Cac.mw

This may be a good time to let you know (or remind you) that in the multivariate case the NLPSolve command provides local optimization, not global optimization. The final results in the above attachment is not showing convergence to a global minimum; I can be a lower objective with the DirectSearch add-on global optimization package. Ie, it can find these values for Zstub and the Zmv[n], which I'll here pass to find the inner maximizing f-value.

NLPSolve(Gammaproc(f,7.94978033705770, 4.08965197980607, 6.12109691708771,
                                8.21891823501128, 13.1493049297548, 25.2038185509781,
                                41.9752157544411),f=f1..f2,maximize);

   [0.00299878124323753), [f = 4.10000001048156]]

transformer_with_short_CacDS.mw

(For the univariate case of the inner maximization w.r.t f I'm just using NLPSolve, which is defaulting to its global branchandbound method. It was the outer multivariate minimization for which I needed the global optimization package DirectSearch.)