@vv It works in my Maple 2016.2, but not in my Maple 2017.3.

@nm The OP has used Maple 2022 for most previous postings. I'll compare, using that version, for Linux.

In that version the Postscript right-click export is poor (though not as bad as .jpg).

The PDF and PNG exports are both reasonably good. Resizing the Maple plot window's borders manually using the mouse (or using the size option of plot3d) to increase the plots dimensions in Maple can sometimes bring some improvement.

The .svg export is also poor, and both it and the right-click Postscript export are noticeably inferior to the right-click PNG export.

@mmcdara It's a little tricky to get flexible contour shading in the very old Maple 17 version that the OP uses, and I like your ideas for him.

Here those are, with the 2D contour plots transformed by z-height.

I only made one other adjustment to your code, related to rand() and float ranges.

Download Some_coloring_ac.mw

@GFY I don't know what exactly you've done. I was talking about exporting an oversized image, then changing its dpi and (eventually) dimensions using an external app such as gimp. Of course, I did not suggest that exporting a larger size plot would by itself produce a higher dpi.

I don't know whether you saw any change, using png. For most stock 3d exports, and all other things being equal, I get a better result using png than jpeg (though, jpeg is about the worst; not a high bar).

I don't even know which Maple version you're using, let alone a concrete example.

I usually go with export to PNG format (sometimes doing it via right-click).

And sometimes I will use the size option while constructing the plot3d result, and then export it as a (deliberately) over-large image file which I may then resize or re-jig using an external image processing tool. I have seen some instances where that can improve the quality. I'm not sure what might be the best image format, for that.

Let us know if you can come up with any more details about what's not adequate.

@vv I started from noticing,

   sum(sum(1/i,i=1..n)/n/(n+1), n=1..infinity);
   expand(%);

rather than with your observation.

I will submit a report against the weakness.

I often delete several spam posting at night, but I've skipped the past few nights.

I've noticed that this site's spam-filter seems to miss more AI generated spam postings, and those seem to have become in vogue.

@Christopher2222 The `size` option is now handled by all the 3D plotting commands in exactly the way that other old (2019) Post addressed (for plots:-display and plot3d).

It offered no other functionality in regards to your current query; it merely allowed the window `size` functionlity before it was officially incorporated.

That Post's code is completely irrelevant to modern Maple versions. Indeed, since that Post's code does a hot-rewrite clobber of Library routines you shouldn't use it in any modern version.

On a somewhat related note, I recall that I once wrote this, to mimic independent aspect ratios for axes of a particular flavor (implicitplot3d) of 3D plot.

That's not the same as the zooming thing for 3D plots, but the two topic intertwine, in practice.

I don't actually believe that a pure Library-size solution is possible, despite having written that old Post. What I suspect might be best would be wholly new elements of the PLOT3D structure, which would denote to the (GUI) plot-renderer what axes-aspect-ratios and scaling/zoom factor to use. Those substructure elements would, naturally, be constructed via new options to the relevent Library plotting commands.

@C_R There is a form for it, here.

Whether it goes through the form, or though tech support, it ends up in the same bug tracking database system (and for which triage assessment gets items assigned to the appropriate developer or group).

In your example, this expression (as well as the values substituted into it) does not depend on x,

    rhs(isolate(de5, diff(p(x), x)))

And that's what's used for the vertical (second) component in your plotted points.

It doesn't depend on x, and it doesn't vary with x.

@salim-barzani Please put your followup example for this here, not in a wholly separate and new Question thread. A separate Question thread on this will be deleted.

So, was this the effect you were after, in the sense of avoiding unwanted fractions?

nb. Some more cosmetic improvement could be had by rearranging terms in sums, so that fewer leading terms have a minus sign. I have several variants of code that do this, and can handle this example. (This example is useful because some coefficients in the collect call have opposing needs for sort re-ordering. So no single sort call applied to the whole expression might serve. I have a prototype of a routine that runs through the sub-term sums individually, figuring out a "nice" term re-ordering, in a coefficient-by-coefficient way. Maybe I will make a Post about it. Let me know if you just want a one-off to further beautify this example sooner/now.)

Which fractions do you object to?

Which expressions are you wanting to export?

@vv I thought you might enjoy this (forced) variant, done in Maple 2024.2,

Download nm_simp_exB.mw