You could check this over. (I don't know whether you have restrictions on a, z, x1, etc.)

Download someint.mw

You haven't described what general programmatic functionality you might be after, but here's a start by handling your given example (and allowing general expressions on either side of the equalities, not just those simple names).

You might have already noticed that the 2D Input that looks like a=b=c gets parsed as a=b and b=c , so below I follow that idea.

Download TS_multieq.mw

You could revise it to accept inequalities (and merge them when sensible). Or you could revise it to accept the kinds of relations as additional arguments, eg. `=`, `<=`. Then you might naturally support things like,   a = b >= c  and so on.

Two ways of constructing something that prints (ie. displays as 2D output) like you've requested are as follows:
  1) Using exports like mrow, mi, etc, of the Typesetting package.
  2) Using a specially constructed name that looks like compact calls to such functions, much like MathML. (This is sometimes called TypeMK in Maple.)
The Java GUI knows how to format both of those as nice 2D output. Both 1) and 2) are undocumented, but are close enough to MathML to figure out. Here's the earlier first example, done both ways.

Download TS_MK_multieq.mw

So for either of these approaches your task amounts to programmatically constructing these beasts.

I chose 1) for the implementation in my Answer, on the chance that that you might also to want be able more easily to parse the results to actual Maple expressions. It also makes it easier to typeset compound expressions for each side of the (in)equalities.

For 2) you might use the nprintf command, though it gets trickier to nicely handle compound expressions. For the simple first example of just names like a,b,c, it can be constructed programatically like so,

nprintf(`#mrow(mi(\"%a\"),mo("&equals;"),mi(\"%a\"),mo("&equals;"),mi(\"%a\"));`,  a, b, c);

An easy way to start figuring out some of this syntax is to enter some 2D Input, then right-click to convert it to so-callled Atomic Identifier (aka. a single name, using TypeMK), and then to lprint that. This can give you insight as to how it works.

Below I'm making the working precision within f (and whatever tolerance evalf(Int(...)) uses accordingly) relate to that of the top-level from which g gets called, with rounding. My purpose there is to avoid f inheriting the working precision raised internally by fsolve.

Download inverse_function_with_fsolve_ac.mw

Give that particular form of expression, you could try one of these,

   remove(depends,Expr,C);

   remove(has,Expr,C);

   eval(Expr,C=0);

These rely on the C[k] terms appearing in the way they do in your example.

One way involves using the select command.

L1 := [[1,1,1,1], [1,2,0,0], [0,0,0,0], [1,1,-2,0]]:

select(L->add(L)=0, L1);

        [[0, 0, 0, 0], [1, 1, -2, 0]]

That should work in Maple 2015 and later. In older versions you could do a similar thing as,

select(L->`+`(L[])=0, L1);

Are you saying that you'd like to configure a custom worksheet as your Start Page?

That is documented here.

You could use an empty Table, instead of the one you showed above.

The second case gets automatic simplification of the literal input 2*(x+2*y), but case 1 does not.

Note that automatic simplification occurs between parsing and initial evaluation.

Also, it cannot be prevented through use of unevaluation quotes (single right-ticks):

t^2*( '2*(x+2*y)' );

           2            
          t  (2 x + 4 y)

In your original case 1 the sum B is multiplied by t^2*A which is something that is not purely of type numeric, and that coefficient is not distributed across the sum.

When you alter your case 1 by introducing that eval call you are separating the steps, so that A*B is computed separately. In that case the sum term B gets multipled by the purely numeric value of A and that gets distributed across the sum.

Literal input is not necessarily going to produce the same result as substitution and evaluation after the fact.

note: A bit more on automatic simplification can be had in Section 3.4 "Unevaluated Expressions" of Chapter 3 of the Programming Guide, in the subsection "Evaluation and Automatic Simplification".

The following handles all the examples that you've supplied so far. That includes all the originally provided examples.

common_factor := proc(x::algebraic, ee::algebraic)
  local p, d := gcd(ee, x^frontend(degree,[ee,x]),'p');
  d * p;
end proc:

smthng.mw

Your call to sort(...) without options actually gets in the way.

restart;

expr := cos(x) - sin(x)/(x^2*y) + 3*x*y;

     cos(x)-sin(x)/x^2/y+3*x*y

simplify(expr, {sin(x)/cos(x)=tan(x)});

  -1/x^2/y*tan(x)*cos(x)+cos(x)+3*x*y

cos(x)*expand(%/cos(x));

  cos(x)*(-1/x^2/y*tan(x)+1+3/cos(x)*x*y)

sort(%, order=plex(x,y));

     cos(x)*(3/cos(x)*x*y-tan(x)/x^2/y+1)

I don't think that your use of ``() merits whatever benefits it might provide here (eg, if trying to yank out a numeric coefficient, say).

I suppose that you are getting the RootOf as result of some command, since otherwise you'd already have the expression x^2-1 at hand and this would all be unnecessary.

The first operand of the RootOf can be extracted using the op command. But the name x is not present in the RootOf.

A:= RootOf(x^2-1);

                               2
                 A := RootOf(_Z  - 1)

op(1,A);

                          2
                        _Z  - 1

This works for some pages, though it is rather roundabout. But it can be handier for long Topics.

1) In the open Help, use the menubar icon with tooltip, "Open the current help page in a worksheet window"

2) In that opened worksheet, use the menubar item, File -> Document Properties

3) Copy the entry for the Topic Property

4) Paste that in to the right-click Convert To -> Hyperlink popup.

@Amir_Maple Different approaches to performing the integration can result in different values for the constant term. (As mentioned, the particular value of some constant term does not make the result invalid.)

poly_int_example.mw

From your description of your display problems I suspect that your session has been accidentally set to use prettyprint level 0 for output.

You can test that using the following command,

   interface(prettyprint);

which should not be executed in the same paragraph or execution group as an restart.

If that is the problem then you may fix it as follows:

a) Execute the command (not directly by any restart),
    interface(prettyprint=3):

b) In the GUI go to the menubar item Tools->Options->Display
    and ensure that the combo-box item "Output display" is set
    to "2-D Math Notation"

c) Press the "Apply Globally" button.  Then close the Maple GUI
    altogether, relaunch, and test it.

This may also help with the "Typesetting" artefacts you showed elsewhere.

The edges of the filled region appear rough unless an accompanying outline curve is also rendered. That's why style=polygonoutline (default) has a border.

You're objecting that the fill color doesn't match the outline's color.

You can get a matching color for both filled region and outline (border) by calling the command twice -- once without border and once with as just a line (curve, as outline border) with forced matching color.

with(plots,display): with(plottools,ellipse):

display(
  ellipse([0, 0], 2, 1, filled=true, color = red, style=polygon),
  ellipse([0, 0], 2, 1, filled=true, color = red, style=line),
  size=[1000,500],scaling=constrained,axes=none)

And if you'd like to compare the variants side-by-side,

with(plots,display): with(plottools,ellipse):

display(Array([

  # One the left, the outline is rendered smoothly.
  display(ellipse([0, 0], 2, 1, filled=true, color = red, style=polygon),
          ellipse([0, 0], 2, 1, filled=true, color = red, style=line)),

  # In the middle, the undesirable black outline.
  display(ellipse([0, 0], 2, 1, filled=true, color = red, style=polygonoutline)),

  # One the right, the lack of any outline makes the filled edges jagged.
  display(ellipse([0, 0], 2, 1, filled=true, color = red, style=polygon))

              ]),size=[400,200],scaling=constrained,axes=none);

You might also see my comment on another Answer, in which I show a similar effect of matching colors using a single call to the plot command with a corresponding parametric form.

The plot may not be necessary.

F__A0 := 20;
X__Af := 0.9;
r__A := -2.52*1^2*X*(1 - X);

eq := V = (R + 1)*F__A0*int(1/(-r__A), X = X__Af*R/(R + 1) .. X__Af)
      assuming 0<X, X<1, 0<R, R<1;

    eq := V = 20 (R + 1) (-0.3968253968 ln(R) + 0.3968253968 ln(R + 10.))

Optimization:-Minimize(V, {eq, 0 <= R, R <= 1})[2];

          [R = 0.429944982482764, V = 36.1887187298120]

Solvingforlimitsofintegrals_ac.mw