Do you know/expect a web translator work for text inside a Maple worksheet? In any case, I would export the worksheet to plain text format and try its translation.

Some explanation of Maple's answer can be obtained frequently by infolevel. This is in Maple 9 (Maple 7 may be similar):

> infolevel[int]:=3:
> int(sin(x)*(x + sin(x)),x);
int/indef1:   first-stage indefinite integration
int/indef2:   second-stage indefinite integration
int/trigon:   case of integrand containing trigs
int/trigon:   case of integrand containing trigs
int/trigon:   case of integrand containing trigs
                  sin(x) - x cos(x) - 1/2 cos(x) sin(x) + x/2

Actually, square brackets are hardcoded in the procedure `latex/latex/matrix` lines 5 and 23:

> showstat(`latex/latex/matrix`,5):
`latex/latex/matrix` := proc(e)
local i, j, m, n, texlist, ccnt, keepcnt, ll, mcnt, nlist, `&`, `\\\\`, `\\mbox `, `?`, `\\end `, ` \\right] `, `\\begin `, ` \\left[ `, c;
       ...
   5   texlist := ` \\left[ `, `latex/latex/copy`(cat(`\\begin `,`{`,'array',`}`)), `{` || (`latex/latex/copy`(cat(`$`(c,n)))) || ('`} `');
       ...
end proc
> showstat(`latex/latex/matrix`,23):
`latex/latex/matrix` := proc(e)
local i, j, m, n, texlist, ccnt, keepcnt, ll, mcnt, nlist, `&`, `\\\\`, `\\mbox `, `?`, `\\end `, ` \\right] `, `\\begin `, ` \\left[ `, c;
       ...
  23   texlist := texlist, `latex/latex/copy`(cat(`\\end `,`{`,'array',`}`)), ` \\right] `, ll
end proc

So, a way would be to replace this procedure with a patch for these lines.

Something special with this pdf plot export device is that it is available only in the Java sector of the system, meaning that there is not programatic counterpart through the command plotsetup (which can manage alternative export devices, see ?plot,device) providing bounding box configuration, etc. My guess is that this device is a poor hack of the tool for exporting a whole page to pdf. Certainly, if you choose plot to window, instead of plot inline, there is a slight improvement as the exported plot takes the upper sector of the page, instead of the upper left corner.

So, unless there is a hidden hack, I think the best workaround may be to export first to eps and then transform externally to pdf.

As I see it, this problem starts with Maple 15 and seems related to a change in the numerical evaluation of logarithms, producing many calls to iperfpow, iroot,`evalf/ln`, etc, spending a lot of time there. 

Maple is weak with separate color bars. See, e.g. at links in this related thread on separate color bars for density plots.

This empty space bug has been around since it was introduced in Maple 16, see e.g. this thread. The best hope is, probably, its fix in a forthcoming version.

Yes, this issue was a regression introduced to Maple 13 Standard GUI, see e.g. this thread. You may try plotsetup export either in the Classic GUI or in the Command line interface.

See previous threads on this subject linked here.

Equivalence holds assuming u<>0, in which case, being independent of u, take u=1:

> subs(u=1,A);
                         a (y exp(-y) - x exp(-x))
                         ------------------------- + b
                                   y - x
                         -----------------------------
                                     c + d

A well known generalization of the power rule is the derivative divides rule (see e.g. here). Consider the direct transcription of your math note, and see how internally this rule is applied:

> infolevel[int]:=1:
> trace(`int/polynom`):
> int(f(x)^m*diff(f(x),x),x);
int/indef1:   first-stage indefinite integration
int/indef2:   second-stage indefinite integration
memory used=0.9MB, alloc=38.3MB, time=0.07
int/indef2:   applying derivative-divides
int/indef1:   first-stage indefinite integration
{--> enter int/polynom, args = _X^m
                                 b, e := _X, m

                                               (m + 1)
                                       m     _X
                         int/polynom(_X ) := ---------
                                               m + 1

<-- exit int/polynom (now in int/indef1) = _X^(m+1)/(m+1)}
                                      (m + 1)
                                  f(x)
                                  -----------
                                     m + 1

Now, see how the same computational path is followed in this acer's workaround:

> infolevel[int]:=1:
> trace(`int/polynom`):
> int( convert(tan(x)^(n-2)*sec(x)^2, sincos), x );
int/indef1:   first-stage indefinite integration
int/indef2:   second-stage indefinite integration
int/indef2:   applying derivative-divides
int/indef1:   first-stage indefinite integration
{--> enter int/polynom, args = _X^(n-2)
                               b, e := _X, n - 2
                                                  (n - 1)
                                    (n - 2)     _X
                      int/polynom(_X       ) := ---------
                                                  n - 1
<-- exit int/polynom (now in int/indef1) = _X^(n-1)/(n-1)}
                                /sin(x)\(n - 1)
                                |------|
                                \cos(x)/
                                ---------------
                                     n - 1

But a quite different path is followed for the tan form, namely going after Risch integration:

> infolevel[int]:=1:
> int(tan(x)^(n-2)*sec(x)^2,x);
int/indef1:   first-stage indefinite integration
int/indef2:   second-stage indefinite integration
int/trigon:   case of integrand containing trigs
int/indef1:   first-stage indefinite integration
int/indef2:   second-stage indefinite integration
int/trigon:   case of integrand containing trigs
int/prptrig:   case ratpoly*trig(arg)
Norman:   enter Risch-Norman integrator
Norman:   exit Risch-Norman integrator
Risch:   enter Risch integration
Risch:   exit Risch integration
...

So, this problem may be described as a failure to recognize that the derivative divides rule applies.

The transformation made by sqrt here:

> sqrt(4-sqrt(7));
                                    1/2    1/2
                                  14      2
                                  ----- - ----
                                    2      2

is denesting of radicals, rather than automatic simplication as enclosing in forward quotes shows:

> 'sqrt(4-sqrt(7))';
                               sqrt(4 - sqrt(7))

This is performed, in sqrt:-Nested, basically using the method shown e.g. here.

See better ?LinearAlgebra,General,MVshortcut . Yes, be warned that documentation has bugs...

This issue of different definitions for Spherical Coodinates is almost a FAQ, see e.g. this thread and linked ones therin.

Returning a status code for int could go along the lines of this toy procedure:

> test:=proc(f)
> if type(f,specfunc(int)) 
> then return(f,"failure");
> else return(f,"success");
> end if;
> end proc:

> g,status:=test(int(x^2,x));
                                         3
                                        x
                          g, status := ----, "success"
                                        3
> g,status:=test(int(f(x),x));
                                     /
                                    |
                      g, status :=  |  f(x) dx, "failure"
                                    |
                                   /

I agree that a common approach for returning a status code would be desirable. But in Maple little is common across the system and uniformity is not considered a value...

The help page ?return is worth reading in this concern, on the subjects of the ``fail return'' and particularly on the special name FAIL:

The special name FAIL is commonly used by Maple library procedures as a return value which indicates that the computation failed or was abandoned, in cases where returning the unevaluated function invocation is not appropriate.

In particular, it is clear that FAIL is not so commonly used by Maple library procedures as a return value indicating that the computation failed or was abandoned, as claimed here.