@nm That is interesting.

If your actual goal is to include this in LaTeX then why do you go -> .ps -> .pdf ?

@nm I originally thought that you were interested in exporting the whole worksheet, and that your main question here was about the lack of alignment and good behaviour in the GUI Table -- which is why I suggested Tabulate.

I've never seen good behavior of exporting arrays of plots only (ie. stand-alone from the parent worksheet), whether displays using plots:-display or another mechanism.

I know that you do a lot of scripting work. If it were me, I'd script the export (and LaTeX buildup) using programmatically exported, individual plots. I don't think that you're going to get great success (easily, or perhaps at all) by trying to deal with exporting arrays of plots by themselves.

@user-JG The idea is just to put your polynomials into a Matrix.

You can create a Matrix(m,n) of m rows and n columns. Then assign yout polynomials to the entries of M. Then call  Lat(M) as a command. The result would be LaTeX for an m-by-n table.

@Aguiar I did not suggest wrapping the SetProperty call with a print call. My attachment did not have that.

It is the print call (whose argument will be NULL, which is what SetProperty returns) that is causing those blank lines.

Simply remove that print call, ie.
  DocumentTools:-SetProperty("Plot0", value, plot([VAR1], x = 0 .. vmax, gridlines));

That is what was in my attachment with the embedded Plot Component.

Out of interest, does your Comment's first sentence confirm that your Maple version is actually Maple 18?

@emendes Yes, that was my point. Which is why the explanation of the removal action (as described) did not make sense to me. It seemed to rely on the initial ordering of abc.
[edit] Perhaps that is intended. If that is the whole point then I simply misunderstood.

@emendes So, are you trying to remove the image of the conds mapping from abc? if so then it seems like a problem to be trying to do it inplace, entry by entry, because earlier removals will cause items in the image to be overlooked. But perhaps something(?) like the list version of this, for abc as a list:

   abc minus conds~(abc)

I may be miunderstanding. I am also confused by the parts of the given example.

So perhaps people would prefer it if removal of a vote/acceptance did not subtract a value. (And, naturally, that would need a flag internally, so that any subsequent re-vote by the same member would note add any value a second time.)

@Carl Love So, I suppose that phaseportrait is calling dsolve for each of the initial conditions (like how DEplot does). Whereas this use of odeplot (with parameters) calls dsolve once. So there must be quite a bit of setup overhead.

[This old post comparing odeplot and DEplot -- in animation -- is nine years old. Even then I wondered whether DEplot should leverage the parameters functionlity in dsolve, for better performance for IVP problems with multiple ICs. I recall submitting an SCR on it.]

Thanks, I wasn't thinking very hard about theta in the fieldplot. Perhaps I was confusing with number of ICs, weirdly. (4am and insomnia) I updated it.

I cannot say "why", because I do not know. But, it is possible that someone (not me) undid a recent upvote.

Ok, this meld of local declaration and evalf-extension seems easier to use, and can be done with 2D Input.

Download percent_loc_evalf_2.mw

@Christopher2222 Well, I think we all know how to use subs already. I meant, something with a more natural or directed syntax and meaning, like evalf, convert, etc.

Unfortunately the OP did not tell how he intended on using the %. For example, he did not state whether he wanted it to appear in input, or output, or both, etc. If he only needed it for input then he might as well do,
   local % := 0.01:
up front (or the exact 1/100). For example,

restart;
local % := 0.01:

foo:

45*%;

            0.45

45*% * 123/7;

         7.907142857

@Christopher2222 And how would you teach Maple to compute with that, as an actual percentage?

@vv The substitution for 2*Pi into the procedure works. And it's... somewhat easy to work with, sometimes. (I didn't think much, before, about all cases of using it like a shade-between.)

But I suspect that he does not want the disk closing off the top of the cylinder that one of his calls is generating.

@Christopher2222 As I said before, it is tricky not to be misled by the internal state and/or plot persistance. As just one possible example of trickiness, one may have to remove output from any Execution Group and re-execute just to clear some of the internal state markers in play -- not doing so can mean that the current attempt is utterly invalidated. And there seem to be additional markers in play, meaning that it's even trickier to get a clean slate.

There is no mechanism inside plots:-display which guarantees the successful rendering of the projection. But that doesn't stop anyone from getting lucky.

@Jean-Claude Arbaut Another example of interest,

restart;
Digits:=20:
seq( ((n+1.)/n)^(n+1.), n=3..3);

         3.1604938271604938268

restart;
Digits:=20:
seq( evalf(((n+1)/n)^(n+1)), n=3..3);

         3.1604938271604938272

And, yes, here is the result of the single call to procedure u that was made in construction of the a list by using $. As you've subsequently noted, it contains the float 1. (which induces float contagion, so as to get the final float results in list a).

restart;
u:=proc(n) evalf(((n+1)/n)^(n+1)) end proc:

u(n);

         ((n+1.)/n)^(n+1.)

[Edit] My original Answer demonstrated (as intended) that the crucial difference was between results due to float contagion versus results due to ten separate evalf calls. However I originally utilized n=3.0 instead of the evalf'd expression involving name n -- since both induce that float contagion. I figured that was adequate to explain the phenomenon, but I see now that I ought to have been precise. I updated my Answer -- to make it more precise -- as I reinstated it after accidental deletion by someone else.