@mmcdara Thanks for reporting this problem. The two PDFs, like all Maple Transactions articles, should be freely available to all. Could you let me know which browser you're using and I'll ask the administrators of the site about the problem? Does using a different browser work?

@Scot Gould I agree with your suggestion and I see that this is already recorded in our database. Also thanks for the "upvote", as it reminded me to switch the reply to an answer.

@anton_dys Yes, indeed, it was soon after your first post that we decided to disable the contrast, brightness and scaletorange options when colorscheme was used. It was unclear and potentially confusing to users how these options should interact with one another.

I'd like to repeat Daniel's invitation to stop by our booth if you're at JMM. You can sign up for our Thursday evening workshop there. We'll be giving an overview of Maple, with emphasis on our newest features. The workshop will be accessible to people who are new to Maple. Experienced users who have not seen our latest developments will hopefully find it useful too.

I will be running the workshop, along with Daniel, and I'll be at our booth much of the week. I'd be very happy to meet any of our MaplePrimes users who are at JMM, so please do come by and say hello!

Paulina Chin
Architect, Mathematical Software

@tomleslie 

Would it be generally safe to assume that any command returned by exports(Typesetting) which "shares a name" with a MathML tag will do pretty much what the latter would do - or would it be safer to regard it as "suck it and see"?

That is true in most cases but not in all. For the purposes of displaying text in a plot, it should be safe enough to just experiment with MathML tags and see what gives you the desired result. The differences are more important if you want to parse the expressions you create (but that is not something that I expect you will generally need to do).

Do you happen to know if the Maple help for the Typesetting() package is going to be enhanced/extended to cover some/all of these undocumented commands, or are they destined to remain effectively "hidden"

There is no immediate plan to document these exports, as they are meant to be used internally. Most of the time, you can get the mathematical display you want without having to build such structures yourself. Of course, there are cases like the one brought up in this thread where it's not so easy to accomplish with the documented tools. 

If it turns out that there is a need for better control of typeset expressions, then we would consider documenting these tags. It is more likely, however, that we'd try to provide tools to users to generate the typeset output they want. This situation is somewhat analogous to that for plot structures. Over the past few years, we've tried to improve the tools for generating customized plot structures so that Maple users don't have to work with the internal representation.

ETA: as mentioned, the Typesetting tags follow the MathML tags closely, though they are not identical. In acer's example, mn actually refers to numeric entities, so it would be better to use mtext for the titles, even though the displayed output is the same in both cases.

@raskr 

No, I am not Phil. That would be my colleague in our Technical Support group. The TS group normally processes user requests and puts them into our database. They eventually get assigned to the appropriate manager and/or developers, which may not be me, so I can't make any promises about fulfilling the request but you can be assured it will be considered. In any case, I'll contact Phil and tell him about the discussion here, if he's not already aware of it.

I just realized that I'd never set my profile information as public, which might account for your confusion between me and Phil. I've fixed that now. 

@tomleslie 

Maple has specific rules on when to display a number in scientific notation. I believe the rules follow roughly those described for the %g format on the printf help page. When scientific notation is used, the displayprecision setting applies to the mantissa.

Unfortunately, I don't think there is a way to change these rules globally. However, you can change the way a specific output is displayed by using the numeric-formatting featured, as described on the Formatting Numbers help page. If you choose the fixed format, then you won't get scientific notation.

@Preben Alsholm Your conclusion is correct. I've confirmed that this is a bug in the 2-D parser and I've added a report to our database.

In Maple 2018, we’ve adjusted the 2-D math in help-page examples to avoid such ambiguities. So now, exp(x) is displayed with exp spelled out in full. Similar changes have been made for indices (e.g. a[i]), special-function names and other potentially ambiguous situations. Unfortunately, the Maple help pages on the Web have not yet been updated to reflect the Maple 2018 changes but my understanding is that this will happen soon.

@hmzhu05 Thanks for the additional information about the contest. I too hope that we'll have more opportunities for collaboration in future events.

@_Maxim_  Good point. I'll look into improving the wording on the plot/tickmarks help page.

This bug is now fixed in Maple 2017.1. Details about the new release are in this post.

@Carl Love Unfortunately, it's not possible for a user to avoid this bug by adjusting one of the typesetting rules. Keep in mind that the rules accessible through the Rules Assistant or the Typesetting commands do not control all of the typesetting system. 

To be honest, I've found, in my experience, that it's rare for errors to be issued during the extended-typesetting stage. Of course, I'm not saying that the typesetting system is free of bugs! However, when a bug does occur, it's more frequently a parsing error or a situation where the extended-typesetting output is incorrect or unexpected (rather than gives an error). When an error does occur, it usually indicates an internal bug (as in this case) that we try to fix as soon as we can. While your suggestion allows a workaround for users while they are waiting for a fix, we'd generally prefer not to suppress the bug but to have it reported and fixed.

If you're uncertain whether an error is caused by the typesetting system, an easy way to check is to assign the result of a command to a variable, with the command ending in a colon to suppress output. If an error occurs, it's in the command. If an error occurs when you subsequently try to display the contents of the variable, then it's the typesetting system's fault. John had noted this in his original message, when he stated that no error occurred with a colon terminator.

Thanks, John, for reporting this bug. We hope that, rather than switch back to standard typesetting right away, you will consider continuing to work with the default extended typesetting mode. There are a number of advantages to using extended typesetting, including the ability to customize certain aspects of the display through the Typesetting Rules Assistant or the Typesetting package exports. We are continuing to work on the reported issues and other improvements to the typesetting system, and user feedback about this feature is very important to us. 

Paulina Chin
Maplesoft

Whle plot3d can be used in this situation, I would generally recommend the plots:-spacecurve solution that Preben posted. The plot3d command was designed to plot surfaces while the plots:-spacecurve command was designed for plotting curves. If you use plot3d with n=1..1 and numpoints=t^2, you'll actually get a t-by-t surface, with lots of duplicate points, so it's much less efficient than plots:-spacecurve. Also, the reason that options like color appear not to work is because there is no surface interior to color. What you're seeing are the black grid lines that show the boundary of the surface.

It has been proposed that plot3d be made smarter so that it can guess when a user wants a curve rather than a surface, and that is still in our future plans, but for now, plots:-spacecurve is a good way to go.

Paulina