@marram 

Actually, objects in Maple are represented by DAGs. For that diff function call you can see it by using e.g. dismantle and the inert version of diff:

dismantle(Diff(leaf, x));
FUNCTION(3)
   NAME(5): Diff #[protected, _syslib]
   EXPSEQ(3)
      NAME(5): leaf
      NAME(4): x

@marram 

Actually, objects in Maple are represented by DAGs. For that diff function call you can see it by using e.g. dismantle and the inert version of diff:

dismantle(Diff(leaf, x));
FUNCTION(3)
   NAME(5): Diff #[protected, _syslib]
   EXPSEQ(3)
      NAME(5): leaf
      NAME(4): x

@felipe_p 

May be that the best workaround is exporting the whole worksheet to LaTeX and then extract the relevant pieces from the tex file.

Yes, there should be a good LaTeX package for input and output. As you can check, e,g. in this site, it has been requested many times along the years by many users. And some of them have posted their own contributed packages. But it does not seem to be within the top priorities of Maplesoft management.

@felipe_p 

May be that the best workaround is exporting the whole worksheet to LaTeX and then extract the relevant pieces from the tex file.

Yes, there should be a good LaTeX package for input and output. As you can check, e,g. in this site, it has been requested many times along the years by many users. And some of them have posted their own contributed packages. But it does not seem to be within the top priorities of Maplesoft management.

The section "Saving Semantic Information" in Paulina's report "Maple's 2-D Math Interface" gives some details about the difference between standard and extended typesetting and the usage in the latter of semantic information via the msemantics tag.

The section "Saving Semantic Information" in Paulina's report "Maple's 2-D Math Interface" gives some details about the difference between standard and extended typesetting and the usage in the latter of semantic information via the msemantics tag.

@Christopher2222 

Thank you for this additional information. Certainly, I have checked only with standard typestting where both %a and %A work essentially the same (except for handling quotes). This difference in behavior (standard vs extended typesetting) sounds to me also like a bug (at least in design).

@Christopher2222 

Thank you for this additional information. Certainly, I have checked only with standard typestting where both %a and %A work essentially the same (except for handling quotes). This difference in behavior (standard vs extended typesetting) sounds to me also like a bug (at least in design).

@PatrickT 

It may be interesting to reread this thread, which contains arguments by Laurent and Paulina on this issue.

@PatrickT 

It may be interesting to reread this thread, which contains arguments by Laurent and Paulina on this issue.

@Christopher2222 I meant what I wrote. But it is just a suggestion that you may adapt to your needs. For instance, you could add similarly an option for a different font, a colored background, etc.

@Christopher2222 I meant what I wrote. But it is just a suggestion that you may adapt to your needs. For instance, you could add similarly an option for a different font, a colored background, etc.

@Christopher2222 

As atomic identifiers are names, you can generate them using nprintf like in this procedure:

cprint:=proc(s,c)
nprintf("#mo(%A,mathcolor=\"%A\")",s,c):
end proc:

cprint("this is green",green);#prints green

cprint("this is green",red);#prints red

About undocumentation of TypeMK, here is Paulina's argument on this subject.

@Christopher2222 

As atomic identifiers are names, you can generate them using nprintf like in this procedure:

cprint:=proc(s,c)
nprintf("#mo(%A,mathcolor=\"%A\")",s,c):
end proc:

cprint("this is green",green);#prints green

cprint("this is green",red);#prints red

About undocumentation of TypeMK, here is Paulina's argument on this subject.

It sounds to me increasing/decreasing...