it would have been better if you attached such problem worksheet to use as an example. I do not see this problem you are talking about. But I do not use Maple to export pdf files much if any. I export what I want from the worksheet to Latex and compile the Latex to pdf. You get much better quality pdf this way.

But to change the font size in pdf, there are many external tools to use. Some are free, and some are not.

Adobe itself has an online service that does that Here is the link  https://www.adobe.com/acrobat/hub/how-to/change-font-size-in-pdf  

etc..

@Joe Riel 

This change was meant to be applied/used only within MmaTranslator:-FromMma package and not anywhere else in Maple. 

Since the expression x^y^z is a valid Mathematica expression and the Maple package is meant to be able to translate any valid Mathematica  Math expression to Maple, then it will be better if it can translate this to Maple, using a default internal setting  to generate x^(y^z) as translation to Maple.

Within Maple, it is no problem at all adding explicit () when needed.

That will something useful to have in Maple 2023 if possible. 

@acer 

Thanks! You are right, I am now using Chrom browser and able to write this here as you see,. 

But from Brave browser, which is the one I use all the time as it is more safe (no ads), when I login, this window is disabled for some reason.

I will try clearing the cache from the Brave browser to see if this has anything to do with it.

@tomleslie 

@Carl Love 

The debugger comes up automatically (when you uncomment the DEBUG(); statement). Then in the small window there (below where it says to enter a debugger command) I simply type

Object(A,ode,':-ic'=ic); 

This is to see what happens, without hitting the STEP button. i.e. just type in the window the actual Maple command which is about to execute. The error will show. At least it does on my Maple.

This is very useful feature. It allows one to issue Maple commands inside the debugger and examine things right at the place where there is a problem.

I do not know how you program without a debugger. You must be very good. I get lost without a debugger :)

@Carl Love 

Thanks. But the debugger gives same error. Here is screen shot. I am on windows using 2022.1

another screen shot

Do you not get same error?  

I now find the traditional optional argument handling easier to work with actually. Yes, I have to add few explicit IF THEN ELSE to check for each possible type and do an explicit casting. But this is not too bad, at least I get no strange errors like with corece. So my code now looks something like

if type(ic,set) then
     _self:-ic:=convert(ic,list);
elif type(ic,Vector) then
     _self:-ic:=convert(ic,list);
elif ....etc..
fi;

I do this each argument which can have different type

@dharr 

I understand that the default for y means default. But I need the actual numerical y range used. Using your example

p:=plot(sin(x),x=-1..10):
op(select(type,p,specfunc(VIEW)));

gives

VIEW(-1.0000000000 .. 10.0000000000, DEFAULT, _ATTRIBUTE("source" = "mathdefault"))

WHich does not tell the program what the actual y-range used is. Compare to 

lprint(p)

which has that information but in different location:

                "originalview" = [-.986250000000000071 .. 9.98625000000000007, -1. .. 1.]]))

The above has the actual numerical values for both x and y used. That is what I want. Not "default" as I can't use "default" in my other plots I am doing (phase diagrams), where it needs the acual values for y range.

@dharr 

Thanks but this gives only the x range. I need to also obtain the y-range used. Is it possible to modify it to obtain the both?

@ijuptilk 

But you did not address the question about v

Why is it partial derivative? It only shows in both equation as changing w.r.t. z only. 

You have so many mistakes in just writing what you want solved.

1) v shows as function of z only. So why use partial derivatives? Where will you use  v(z,0) =0 ?

2) There is no K1 in the equations

3) There is no alpha3 in the equations

4) There is no thetab in the equations.

5) There is no eta1 in the equations.

Trying to make the symbols that show in your equations latex match the numerical values you give will be a good start.

@Rouben Rostamian  

Would you know why it works with no error with plus but not with minus?

i.e. it works with  1+p.q but not with 1-p.q  ?

@acer 

good improvement.

@Carl Love 

Hello;

I just always thought of Mathematica Together as similar to Maple's combine, simply because Mathematica has no combine command, only Together command, that is all.

@Preben Alsholm 

Ok, thanks, normal works, so is numer/denom. 

I still do not understand why combine does not work as expected. I guess this is just how it was designed. 

@ecterrab 

Hello;

Based on what you said, this is why I always wondered why Maple sometimes changes the implicit solution to explicit one when adding initial conditions, which will cause odetest not to verify the solution then.

Using same ODE I gave, this is Maple's solution

ode:=sqrt(y(x))+(1+x)*diff(y(x),x)=0:
ic:=y(0) = 1:
sol:=dsolve([ode,ic]);

But this does not verify as is

odetest(sol,[ode,ic])

It will verify, by getting the correct region (in this case when csgn() is -1), But this requires more work from the user to figure that out.

I wonder why Maple did not solve the constant of integration from the general solution (which is implicit, good) and kept the IVP solution implicit? This would cause odetest to verify it as is, with no more post-processing. For the above:

ode:=sqrt(y(x))+(1+x)*diff(y(x),x)=0:
ic:=y(0) = 1:
sol:=dsolve(ode); #solve with no IC

Which is implicit. Now solve for _C1 but keep the solution implicit, something like

eq:=eval(sol,[y(x)=1,x=0]);
the_constant:=PDEtools:-Solve(eq,_C1);
new_sol := eval(sol,the_constant)

Now the IVP solution remained implicit. The difference, is that now odetest verifies it as is

odetest(new_sol,[ode,ic])

Any insight why dsolve does not do this instead of making the final IVP explicit which makes it harder to odetest it?  I do know that one can force the IVP solution to be implicit using

sol:=dsolve([ode,ic],'implicit');

But why not do this by default in such cases, since it generates solution that will odetest to 0 as is.Notice in this case, the general solution came out implicit on its own, without using the option 'implicit'. But not the IVP solution. There one had to force the solution to show as implicit.

This is what I do not understand why.

Maple 2022.1 on windows 10