@erik10 I am quite in agreement with you: there's quite a bit of improvement needed for the GUI, in terms not just of rescaling for high-res displays but also for consistent rescaling of embedded components and their associated text.

I'm not trying to suggest that things already work fine. I'm just trying to point out a few things that might possibly help you mitigate the difficulties now.

By the way, there have been quite a few reports by Danish users (mostly students) on this site, over the years, about corrupted worksheets. One aspect that recurs may be the presence of special text characters (eg. Danish), possibly linked to errant escape-characters. But I've been wondering whether the common presence of (not small, always) inserted images in the documents might not also be part of the problem. It would be a good thing to see such problems resolved.

@erik10 

Explicitly supplying some other value for the size option should already override whatever has been set using plots:-setoptions. That's a nice thing about plots:-setoptions, it allows you to set preferences, which can then be easily overridden at any time, with the usual command calls.

Also, the size=list option can be utilized on a call-by-call basis, with different values (as the first float in the list, designating the proportion) as desired.

When you write of "images" I'm not sure whether you mean images as backgrounds to plots, or inserted from the main menubar, or embedded using ImageTools:-Embed, or as a Drawing (canvas).

For images used as the background for 2-D plots, those don't respect plots:-setoptions with the size option, which I think is a good thing. But an explicit use of the size option in a plot command can still override the original dimensions of the image. Eg, using Maple 2016.2, with each of these lines in its own execution group, say,

restart;
plots:-setoptions(size=[300,300]):

img := cat(kernelopts('datadir'),"/undercarriage.jpg"):

# Good. Image file is 600x400.
# Should not adhere to setoptions preference of 300x300.
plot(background=img,axes=none);

# Good. Respects the specified size.
plot(background=img,axes=none,size=[300,200]);

# Good. Picks up setoptions preference of 300x300.
plot(sin(x),x=-Pi..Pi);

For images inserted using the main menubar's Insert->Image action, you could insert them into a single-row, single-column GUI Table, without exterior borders. By right-clicking on that Table you can set its properties. That includes setting it to be a fixed properotion of the GUI window's width (default is 100%). You can also center that borderless Table. As long as the original image width is greater than that proportion of the window width then the image will be zoomed to that dimension. So just make sure that the image is a wide as the maximally needed case.

For an image embedded with the ImageTools:-Embed command you can also right-click and change the Table's properties to a specific fixed proportion of the window width. You can also center it, eg, using the main menubar's Table->Alignment->Table->Center . (It would be nice if that command got the nicer options to do all that programatically like DocumentTools:-Tabulate can, or alternatively if DocumentTools:-Tabulate got the functionality to handle Array-based "images".)

Unfortunately the Drawing canvas does not seem to rescale automatically when placed within a GUI Table whose width property is set to a fixed proportion of the GUI window's width. Ie, objects drawn don't rescale when the GUI window is resized or maximized. That's a pity.

The size option for 2-D plots can also be set as a proportion of the Maple GUI's windows (working area) width.

For example, if you put the following line in your initialization file then all 2-D plots should by default be rendered in 40% of the width of the GUI window's work area.

plots:-setoptions(size=[0.4,1.0]):

Moreover that information is part of the actual PLOT structure, and so it should be respected when someone else re-opens the document (without re-execution).

The second value of 1.0 means that the height is set the same as the width (when scaling=unconstrained).

In other words, the size option is not just restricted to a list of integer values like [400,400] which is a pixel-related setting.

What you've shown looks like a PLOT3D function call (which is the structure in which Maple stores the details of a 3D plot).

But such a structure should be in all-caps, not lowercase. Maple is case-sensitive, and so what you've shown is invalid.

Also, it's a poor (or at best old-fashioned) book that needs to resort to having you enter such a structure by hand, directly. Using plotting commands such as plots:-polygonplot3d, plots:-display, plottools:-polygon, etc, are by far the more usual ways to construct such structures.

Did you have trouble finding those kinds of command (intended for constructing such structures) in Maple's searchable Help system?

@DaGu Perhaps you'd be interested in a scatter plot, with (Lowess) smoothing.

@thuannguyen 

Enter it as C.A not as C*A. 

Do you not see that those are typed differently, using different keystrokes?

It looks like you entered it as C*A instead of C.A . The former of those involves the star (asterisk) on the keyboard, while the latter involves the period.

Notice that your typeset 2-D Input shows an interpunct (raised dot) rather than a period (baseline dot).

@Carl Love I saw the plaintext attempt to define the proc, but asked for a sheet because I didn't see a call to it which would produce the purported followup screen shot.

The source has lots of errors. Eg. several instances of plain = instead of := for statements that seem intended as assignments. And it's not wholly clear to me what lowercase t is for.

I agree with you that the OP should state the underlying goal, and differential equations if relevant.

@berkeliox It is likely that you've done something differently now (if only because your screenshot shows more outputs apparently from within the proc body, other than the final plot call).

This runaround guessing could be avoided if you were to upload your actual worksheet file. For that use the big green up-arrow in the editor here, when adding another followup Comment/Reply.

Please use the big green up-arrow to upload your complete worksheet as an attachment to a new Comment to your Question.

Without that it will be difficult to figure out just exactly what your code is (or whether your sheet even has a "Plot0" embedded Plot Component).

If someone posts duplicates then it could happen that one member deletes one of them (as duplicate) while another member deletes another (as duplicate).

@tomleslie The current .zip file for DirectSearch v.2 does in fact contain two .help format files, containing the Help in the new format (in Russian and English).

See here.

@tomleslie The download of DirectSearch v.2 should already include the .help file.

@Carl Love It might help the OP to know that the reason his original code did not work is that his created p1 and p2 do not match the type check of his overloaded `+`. That's because he has not set up a type `Point`. Of course that type could be implemented without using objects, and even an unevaluated function call Point(..,..) could be made to work with it. I would agree that the original submission looks very much like at attempt at working in the object style, and your Answer is of course quite fine.

The reason I'm saying all this is that in my experience the static export `+` is one of the hardest to get just right. There are several tricky corner cases. Along those lines at least these followup questions could be raised: 1) Even though the original overloaded `+` was clearly designed to require that both arguments were Points, the OP might be interested in a scenario where a Point was added -- temporarily -- to say an unassigned name. 2) As Joe has mentioned, the OP might find it useful to be able to add more than just two points in one call. 3) The object implementation seems to get behaviour of scalar multiplication by a numeric type (for free!?), and we don't yet know whether the OP is OK with that.

For all I know that OP might want all that kind of stuff, or none of it, or just parts of it. If he doesn't want any of it then an overloaded `+` might serve such a restricted goal. And objects might still be useful (even without static `+` as export), because they at least provide a convenient way to define the originally missing type.

Let's suppose that p1 and p2 are both of type Point, and name q is undefined. The OP might wish for W:=p1+q to throw an error. Or he may wish it to return unevaluated. And in that last case he may (or may not) want the subsequent eval(W,q=p2) to invoke the code which adds the points together. I figure that the answers to these things would affect the implementation.

Here's another modification, just for fun then.

Download objectPoint.mw

@Joe Riel In my Maple 2016 both p1+p1 and even 13.7*p2 produce the multiplication, from Carls code (without `*` as static export).