@Claybourne It looks as if you might (still) have GUI-based numeric formatting on that output?

(It's difficult to tell because you didn't attach the corresponding worksheet; you gave just an image of output, which is not very useful.)

@tomleslie Tom, you wrote,

  "When you write i[`1d`]  in Maple you are creating a TABLE with (so far)
    one indexed entry, whose index is the name '1d'."

That is not true. A table is not created merely by making an indexed reference.

(A table is created by assigning to an indexed reference of an otherwise unassigned name, but it is not created merely by using such an indexed name.)

An alternative approach, using the procedural colorscheme functionality available in Maple 2016 and later.

The plot3d command can produce a MESH that gets rendered here like a space-curve, but it doesn't render the color. So the MESH (of double necessary size, in one dimension) can be turned into the appropriate CURVES substructure, and the color data re-utilized.

This allows either HUE (single procedure) or RGB (three procedures) colorspaces. The procedures take three arguments (for x,y,z values) and thus can be quite general and efficient.

The memoization (option remember) on the returned dsolve procedures is added because plot3d needs at least 2 for the second (dummy) parameter, specified in the grid option.

Download spacecurve_shaded_3.mw

I'd like to mention that I think dharr's workaround using tubeplot is ingenious. I have long admired his good responses on this forum. I simply felt that a topic as basic as coloring a 3D curve might be addressed slightly better.

I'll add that the syntax and usage of my solution (using some code developed long ago) is already a reasonably close match to what the OP described in the original Question.

And I'll also note that I too have found that that the ISOSURFACE plotting structure cannot properly be generally colored. (I have previously submitted a bug report on that.)

You are welcome, as always.

I'd like to mention that I consider this (which you cited) as a relative poor programming technique for such extraction from the listprocedure:
   T,X,V,PX,PV:=rhs~(sol)[ ] )
The problem is that is depends on matching the order of terms in the list. If that order were changed (ie. lexicographically) inadvertantly later on then a mismatch could produce wrong results. I much prefer using 2-argument eval to extract rhs's in a targeted manner.

I consider using tubeplot here to be somewhat of a kludge for a proper 3D curve.

The color procedures provided by dharr involve even more calls to X(t) and V(t) and using memoization there can bring an even greater relative improvement. (Though it's still not as fast as can be done by building a curve, and that difference increases with numpoints.)

Download spacecurve_shaded_2.mw

@janhardo It's not clear what you're trying to say, or ask, in your most recent Reply/Comment.

It seems to be some kind of duplication of your querying here.

@Kitonum One should not use evalc for simplification unless one is willing to restrict the solution to the condition that the unknown names are purely real.

For this example that first step can be accomplished without using evalc, and without imposing that restriction. Eg,

   evala(rationalize(w));

@janhardo A single apostrophe can be used in 2D Input mode as the prime-notation for entering an ordinary derivative.

That syntax for entering a derivative cannot be used in 1D plaintext (so-called Maple Notation) mode. I doubt that will change any time soon, if ever.

@dharr The behaviour described in your Answer changed for Maple 2017.

There is some description of that change on that version's compatibility page.

@janhardo 

That return value of the Typesetting:-Settings is the previous value (which was just changed). That behaviour has some programmatic advantages.

But is also means that you should not look at the output of that command to "see" whether it worked as you expected. Instead, if you want to check that it worked and that the setting is changed then I'd recommend calling it again, for example,

Download TSSusage.mw

@mvms271091 You may use an empty string "" for the second legend item, which will get suppressed. For example,

f := (3*t)/(1 + t^3):
g := (3*t^2)/(1 + t^3):
plot([[f,g,t=-40..-1.5],[f,g,t=-0.6..40]],
     style=point,symbol=cross,symbolsize=12,
     colour=coral,legend=[foo,""]);

You could do the same thing using, say,
  `[]`~(f,g,t=~[-40..-1.5,-0.6..40])
instead of,
  [[f,g,t=-40..-1.5],[f,g,t=-0.6..40]]

@Ivi Please don't post duplicate Question threads for this, though it might not yet be answered here to your satisfaction.

Here is an example of doing it with a procedure.

The scaling=constrained is needed so that the icon doesn't get distorted. An alternative that would estimate the plot assembly's final size (aspect ratio) -- and use that to adjust the icon -- could become tricky in general.

Download image_plot2.mw

Yet another alternative is to build a background image for the whole plot-window, with instances of the icon as carefully placed subimages. Then the aspect-ratio of the icon images could be handled based on any forced size option choice. This approach wouldn't allow the icons to be laid over a densityplot example, however.

@mmcdara In terms of (kernel, at least) efficiency an improvement would be a procedure.

It could accept, say an x,y pair as center point and width/length (or two opposite corner x,y positions). It could then construct that PLOT(GRID(...)..) structure directly. The only thing needing computation would be the two ranges that are the first two arguments of the GRID(...) substructure.

That would be more efficient than `plottools` commands `transform` or `translate`. It would also allow the two float[8] rtables to remain as such, which might even be kinder to the GUI.

@mvms271091 In my Answer I already gave,

DocumentTools:-Tabulate(widthmode = percentage, width = 75,
                                          [[seq([seq(p[3*(i - 1) + j], j = 1 .. 3)], i = 1 .. iquo(11, 3))],
                                           [seq(p[3*iquo(11, 3) + i], i = 1 .. irem(11, 3))]]):

where that latter part,
    [seq(p[3*iquo(11, 3) + i], i = 1 .. irem(11, 3))]
provides the 10th and 11th plots in a fourth row. It's harder to get that last row center-aligned without resorting to the building-blocks in which Tabulate is written (which is done in one manner in my Answer's second example).

Yes, your fresh attempt using,
   [seq([seq(p[i], i = (j-1)*iquo(11,3) + 1..j*iquo(11,3))], j = 1..iquo(11,3)+1)]
does not work because for the fourth row it refereces member p[12] which is not a plot. That is the whole point of the code fragment in my previous paragraph here.

Another terse way is something like,

DocumentTools:-Tabulate(widthmode = percentage, width = 75,
                        [[seq([seq(p[3*(i - 1) + j], j = 1 .. 3)], i = 1 .. 3)],
                         [p[10], "", p[11]]]):

where the middle cell now appears empty.

An alternative to the above is, say,

plots:-display(Array([seq([seq(p[3*(i-1)+j],j=1..3)],i=1..3),
                      [p[10], plot(axes = none), p[11]]]));

where the empty cell gets an empty plot.

Getting the last (fourth) row to be spaced exactly as you showed is trickier. That is why I also showed as a second example like this:

with(DocumentTools): with(DocumentTools:-Layout): with(DocumentTools:-Components):

InsertContent(Worksheet(Table(widthmode=pixels,width=600,alignment=center,interior=none,
                              seq(Row(seq(Cell(InlinePlot(p[3*(i-1)+j])),j=1..3)),i=1..iquo(11,3)),
                              Row(Cell(Table(exterior=none,interior= none,alignment=center,
                                             widthmode=pixels,width=400,
                                             Row(seq(Cell(InlinePlot(p[3*iquo(11, 3) + i]),padding = 0),
                                                     i=1..irem(11,3)))),padding=0,columnspan=3))))):

[edit] The general idea above is to use iquo and irem to construct first the 3 rows or 3, and then a row of the remaining items. Those are common techniques for splitting N objects into groups. Here's another way. If you are ok with using plots:-display, and don't need the botton row to have (center-aligned) fewer cells, then for a list p of N=11 plots you could also get it rendered in 3 columns as follows: question5_acc.mw

plots:-display(Matrix(ceil(11/3), 3,
                      (i, j) -> `if`(3*(i-1) + j > 11,
                                     plot(axes = none),
                                     p[3*(i - 1) + j])));