When interface(typesetting)=standard then `R` prints correctly, with the green background. But when interface(typesetting)=extended then `R` prints uncolorized. But you can see that, in the former case, Typesetting:-Typeset is not invoked.

restart:
interface(typesetting=standard):
Q:=`#mi("testing",mathcolor = "lime")`;
lprint(%);
R:=`#mi("testing",mathbackground = "lime")`;
lprint(%);
Typesetting:-Typeset(Typesetting:-EV(Q));
lprint(%);
Typesetting:-Typeset(Typesetting:-EV(R));
lprint(%);
trace(Typesetting:-Typeset):
R;
interface(typesetting=extended):
R;

The output of running the above in Maple 15.01 shows that the following is not displayed with green background (which looks like a bug). And when interface(typesetting=extended) then that's the route Maple takes to handle the TypeMK name.

Typesetting:-mi("testing", mathbackground = "lime", Typesetting:-msemantics = "atomic");

You need to have a space (or an asterisk or period) between those closing and opening brackets, to denote multiplication. That is, between the terms you implicitly expect to be multiplied.

Without the space, it can get parsed as if it were a (compound) function application.

I got your rotation code to work in Maple 15.01, with only changes to layout that affect what got printed. Ie, I inserted a semicolon at the end of the animate line, and a colon at the end of the rectangle line.

G:=s->cat(`#mn(\"`,s,`",mathcolor=\"#00FF00\")`);

G("this is green");

You should easily be able to customize or make adjustments to that. That is for the Standard GUI (or maplet plot driver). For the commandline interface, you could decorate with ANSI escape sequences.

You may need to raise the working precision, and to narrow the range, to find the real root (which is in a steep well).

restart:

Digits:=1000:

expr:=1.778895759*Sigma-1831241.099/(76553.66445-.576e-5*Sigma^2)
+6600.970252*Sigma/(76553.66445-.576e-5*Sigma^2)
+.5739576533e-1*Sigma^2/(76553.66445-.576e-5*Sigma^2)
+.4735119433e-4*exp(.7618258041e-2*Sigma)*Sigma^2/exp(.9051395693e-5*Sigma)
/(76553.66445-.576e-5*Sigma^2)
-39332.76308*exp(.7618258041e-2*Sigma)*(41.17+1/(1-exp(-160)))/exp(.9051395693e-5*Sigma)
/(-69.17083220+Sigma)/(-69.17083220-Sigma)
-629324.2088*exp(.7618258041e-2*Sigma)/exp(.9051395693e-5*Sigma)/
(76553.66445-.576e-5*Sigma^2)-1.778895759*exp(.7618258041e-2*Sigma)
*Sigma/exp(.9051395693e-5*Sigma)
-8.220693466*(41.17+1/(1-exp(-160)))*Sigma^2/(-69.17083220+Sigma)/(-69.17083220-Sigma)
-323.1910570+8.220693466*exp(.7618258041e-2*Sigma)*(41.17+1/(1-exp(-160)))
*Sigma^2/exp(.9051395693e-5*Sigma)/(-69.17083220+Sigma)/
(-69.17083220-Sigma)+323.1910568*exp(.7618258041e-2*Sigma)/exp(.9051395693e-5*Sigma)
+39332.76308*(41.17+1/(1-exp(-160)))/(-69.17083220+Sigma)/(-69.17083220-Sigma) = 0:

sol:=fsolve(expr,Sigma=-69.4..-69.0): evalf[10](%);

                          -69.17083217

evalf(eval(lhs(expr),Sigma=sol)): evalf[10](%);

                                     -988
                      -1.610657191 10    

#plot(z->evalf[1000](subs(Sigma=z,lhs(expr))), -69.4..-69.0);

[edit] It's not clear (to me, yet) whether this root is merely a by-product of the 10-digits of accuracy (or inaccuracy, if you will) of the floating-point coefficients. Could it vanish, if the coefficients were more accurate? (And this does not mean simply converting them to exact rationals, of course.) I have not looked at its conditioning.

It is not so hard to accomplish if you forget about using the SYMBOL font and instead use Maple's Standard GUI instead of the Classic GUI. All of these produce a Greek lowercase single-letter beta and Roman xi (differing according to whether you want upright or italic), entered as 1D Maple Notation in a Worksheet in the Standard GUI.

plot(sin(beta),beta=0..1,labels=[beta,"xi"]);
plot(sin(beta),beta=0..1,labels=[beta,`xi `]);
plot(sin(beta),beta=0..1,labels=[beta,`#mo(xi)`]);

Of course, if your vertical axis label is not the name of a Greek letter then you don't need to quote it or do anything special at all. Only the name of the Greek letter will be typeset specially. eg,

plot(sin(beta),beta=0..1,labels=[beta, hello]);

You could do this with typeset ticks, but it might entail knowing in advance at what points you want them.

plot(x^3-6*x,x=-3..3,
     xtickmarks=[seq(i=cat(`#mover(mn(`,i,`),mover(mo(" "),mo(" ")))`),
                     i={$-3..3} minus {0})],
     ytickmarks=[seq(i=cat(i,"   "),i=-8..8,2)]
     );

The label of the axis gets shifted down as well. So you might want to override that axis label, and possibly use a textplot to fake/force it elsewhere.

Side by side with the usual, and with less extra space:

plots:-display(Array([
  plot(x^3-6*x,x=-3..3),
  plot(x^3-6*x,x=-3..3,
     xtickmarks=[seq(i=cat(`#mover(mn(`,i,`),mo(" "))`),
                     i={$-3..3} minus {0})],
     ytickmarks=[seq(i=cat(i,"  "),i=-8..8,2)])
                     ]));

Following Markiyan Hirnyk's suggestion to go entirely with textplot for the tick values (but still having the actual tick marks)

a := plot(x^2,tickmarks=[[seq(i="",i=-10..10,2)],
                         [seq(i="",i=10..100,10)]],labels=["",""]):
b := plots:-textplot([seq([j,-8,j],j in {seq(i,i=-10..10,2)} minus {0}),
                      seq([-1.5,j,j],j in {seq(i,i=10..100,10)})]):
L := plots:-textplot([[5,5,"x"],[1,50,"y"]]):
plots:-display(a, b, L);

Is the problem that the 2D output is not properly broken across lines?

If so, then you could try the following.  Save your worksheet as .mws, then open it and run it in the Classic GUI. Run the command

interface(labelling=false):

(You can run that in another sheet, sharing the same kernel. Or you can run it once in your open sheet, and then delete that line.) Then use the File->Export from the menu bar, to export as LaTeX. This seems to produce a result with better line-breaking of typeset output in the emitted LaTeX source, but without having to recourse to using embedded .eps or graphics for the typeset output.

Next submit an SCR against this problem of LaTeX export in the Standard GUI.

You can try solve(Lar, theta1) to try and force a solution for theta1 in terms of theta2. But the resulting implicit RootOf may be multi-valued. So if you try and use `plot` on that then the curve may appear wild as it jumps from one solution curve to the other. (I suspect the same would happen if you tried to fsolve after substituting lots of different values for theta2.)

An alternative is to compute an "implicit plot"

  plots:-implicitplot( Lar, theta1 = -6 .. 6, theta2 = -12 .. 12, gridrefine = 2 )

or, say

  plots:-implicitplot( Lar, theta2 = -6 .. 6, theta1 = -6 .. 6, gridrefine = 2 );

Firstly, you should probably not use an indexed form of `I` in order to get a subscripted `I`. Make extra sure that it's a subliteral or atomic identifier. If you are unsure what that means, use `II` or someother name instead of `I`, as there are routines which may get confused and think you're manipulating the sqrt of -1.

Next, you more usually use k[H]*k[V]=k^2 and not the other way around (with left hand side and right hand side reversed). Because k^2 doesn't appear inside II[ani].

But k[H]*k[V] doesn't appear inside II[ani] either. Maple won't introduce some factor to make it plausible.  Which would Maple choose to substitue for, the k[H] or the k[V]? It's arbitrary, as both k[H] and k[V] appear symmetrically inside k[H]*k[V]=k^2. It's ambiguous.

If you want to just subsitute for 1/k[V] , then you can isolate that from k[H]*k[V]=k^2 and use the resulting equation for the substitution. (Note that `subs`, `algsubs`, and `eval` all need separate rules for substituting for 1/x than they do for substituting for just x. So not only does k[V] have to be isolated, but also reciprocals have to be taken.)

> restart:

> II[ani] := sqrt(k[H]/k[V]);

                                (1/2)
                          /k[H]\     
                          |----|     
                          \k[V]/     

> subber := k^2=k[H]*k[V];

                          2            
                         k  = k[H] k[V]

> isolate(subber,k[V]);

                                   2 
                                  k  
                          k[V] = ----
                                 k[H]

> algsubs( isolate(subber,k[V]), II[ani]); # note how this failed

                                (1/2)
                          /k[H]\     
                          |----|     
                          \k[V]/     

> (1/lhs=1/rhs)(isolate(subber,k[V]));

                           1     k[H]
                          ---- = ----
                          k[V]     2 
                                  k  

> algsubs( (1/lhs=1/rhs)(isolate(subber,k[V])), II[ani]);

                                 (1/2)
                          /    2\     
                          |k[H] |     
                          |-----|     
                          |  2  |     
                          \ k   /     

And lastly, you can use `subs` instead of `algsubs` for this particular substituiton.

Avoid reliance on implicit multiplication (ie. using a space to denote multiplication). It's too common that a space is omitted by mistake. Below, I use -r*x instead of -rx

Also, did you mean exp(-r*x) instead of e^(-r*x)? And what did you mean to imply, by using an inequality in the first argument? Did you mean that to be the formula to match, or were you thinking of constrained optimization in some way?

Is this what you had in mind?

restart:

Y := [96,183,290,472,711,1191,1746,2573,3507,4410,5133,5597,
      5948,6294,6408,6511,6559,6596,6618]:

X := [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19]:

sol:=Statistics:-NonlinearFit(1/(1/6650+(1/n-1/6650)*exp(-r*x)), X, Y, x,
                              initialvalues = [n = 50, r = .5]):

plots:-display(
  plot(<<X>|<Y>>, style=point),
  plot(sol, x=1..19) );

You are passing an expression sequence to Mean. But that routine expects a list, Vector, or Array.

You can correct this, by either passing or creating y1 surrounded by a pair of square or angle-brackets.

eg,

y1 := [76.0,...];

y1 := <76.0,...>;

y1 := Vector([76.0,...]);

or

Mean( [y1] );

etc

There are two issues. The first is the commonplace issue with plot evaluating its argument before the parameter `b` gets a numeric value. You can see the explanation by clicking on the error message in your worksheet, which points at a URL in the Error Message Guide. Axel corrects for this issue, by using uneval quotes around the function name in the first argument to plot, which is one common technique for handling this.

The second issue is that evalb will not be able to determine whether the inequality holds for some exact values of the parameters. You can fix this by using `evalf` on `cb` and `rr`, or passing `R` and `alt` as floats, or by wrapping with `is` so as to use is(cb>rr) instead. This problem can often get fixed automatically when the procedure to be plotted runs inside evalhf mode. (In evalhf, almost everything is a float...) The presence of calls to routines in Units:-Standard prevents evalhf mode, and so some other mechanism must be used to make the inequality test resolve in the case that the second and third arguments are not floats.

occultRatio := proc(beta, R, alt, $)
uses Units:-Standard;
 local rslt:=0;
 local cb:=cos(beta);
 local rr:=sqrt(1-(R/(R+alt))^2);
 if is(cb > rr) then
  rslt := abs(-Pi/2 + arcsin( rr/cb ))/Pi;
 end if;
 return rslt;
end proc:

plot('occultRatio'(b, JupiterRadius, JupiterRadius), b = 0 .. Pi/2);

Note also that `rr` will be unit-free only because you loaded Units:-Standard before defining the `occultRatio` procedure. In my opinion it is better to include the `uses` statement for that right inside the proc's defn, to make it more self-contained, on the grounds that it requires the package's bindings to function properly. The expression R/(R+alt) might get its units resolved (ie. to vanish and become unit-free) in the lucky case that the units match exactly. But if you want to mix meters and centimeters (or trickier) for the 2nd and 3rd arguments then you need either the power of Units:-Standard arithmetic or of `simplify`. And those are non-evalhable.

Here's is a simpler case of the second issue.

> evalhf(proc() if 1 < sqrt(2) then 7; end if; end proc());

                               7.

> proc() if 1 < sqrt(2) then 7; end if; end proc();
Error, (in unknown) cannot determine if this expression is true or false: 1 < 2^(1/2)

For amusement, run this with and without the `print` statement commented-out. The `print` statement also prevents evalhf mode.

restart:

occultRatio := proc(beta, R, alt)
local rslt, cb, rr;
cb:=cos(beta);
rr:=sqrt(1-(R/(R+alt))^2);
#print([cb,rr]);
 if (cb > rr) then
  rslt := abs(-Pi/2 + arcsin( rr/cb ))/Pi;
 end if;
 return rslt;
end proc:

JupiterRadius := 69173:

plot('occultRatio'(b, JupiterRadius, JupiterRadius), b = 0 .. (1/2)*Pi);

[Late comment: Since `is` can return `FAIL`, it's probably safer to use the ever-so-slightly slower is(cb>rr)=true rather than just is(cb>rr) so that the conditional resolves to only `true` or `false`. Since it won't plot under evalhf, it's likely not a big relative penalty. Or use `evalf` for `cb` and `rr`. Or pass `R` and `alt` as floats.]

It's easy enough to get a nice looking effect for the 2D Math input. You can use the Layout palette, which has two variants for it. The "over2" Layout palette entry looks ok, as 2D Math input. (And the font can be resized for the tilde, as well, while doing so.)

But getting good looking 2D Math output for this is harder. In Maple 15 on Windows XP, the output has the tilde too far above the zeta (and a little in front as well). The mechanism to inline uploaded .mw worksheets into posts seems broken, and the exported worksheet (html+gif) shows only zeta with the tilde actually missing.

This seems to produce nicer 2D Math output, with the tilde set closer down and centered better. And it works as a gif with html export of the worksheet. This has to be pasted as 1D Maple notation input, or typed in manually if in 2D Math mode. It doesn't work if you paste it into the GUI when in 2D Math insert mode (unless you go back and retype the &zeta; bit).

zeta_t := `#mover(mi("ζ"),msup(mi(""),mi("˜")))`;

If you're lucky it might work if the slider (and accompanying code) is named Slider0 instead of a customized name like ecslider17. It may be that MapleNet is renaming all sliders using default names, ie. Slider0, Slider1, etc.