@Joe Riel 

Thanks Joe, that's great. That has it absolutely nailed.

So I'm not sure what's going on with the bounding box, but I have a great workaround, which consists in using epstopdf before cropping; epstopdf correctly computes the bounding box and thus cropping can be done correctly.

So for anyone interested, on Windows (but can easily be adapted to linux), the following batch file, named say epstopdfcrop.bat, converts to pdf and crops, which is convenient to include graphics into latex documents: you can insert the graphics with \includegraphics without having to specify a bounding box or worrying about cropping the image, and you can compile the latex file with pdflatex,

Edit: I added a command to rotate the pdf image by 90 degrees, in cases such as the example above where the image was in portrait rather than landscape mode. Note that you need Ghostscript, Calibre, and pdftk, all freeware. If you wanted jpg instead of pdf, you could use imagemagick and add the line: for %%I in (*.eps) do convert "%%~nI.jpg"

@echo off
setlocal
cd /d %~dp0

for %%I in (*.eps) do (
"C:\Program Files (x86)\MiKTeX 2.9\miktex\bin\epstopdf" %%I
)

for %%I in (*.pdf) do (
"C:\Program Files (x86)\Ghostscript\gs9.00\bin\gswin32c.exe" -dSAFER -dNOPAUSE -dBATCH -sDEVICE#bbox "%%I" 2> bounding
"C:\Program Files (x86)\Calibre2\pdfmanipulate.exe" crop -o "%%~nICropped.pdf" -b bounding "%%I"
)

for %%I in (*Cropped.pdf) do (
"C:\Program Files (x86)\pdftk\pdftk.exe" "%%I" cat 1-endE output "%%~nIRotated90.pdf"
)

@Joe Riel 

Thanks Joe, for these explanations.

I have run into a problem I had forgotten about: the cmaple postscript plot driver produces an incorrect bounding box. The problem with this is that cropping the image with a command-line tool will crop in the wrong places. I have in the past solved this problem by using latex and dvip ps as a wrapper to recreate the bounding box, importing the figure with pstricks, making no modification and saving. Would there be a way to fix the problem within the procedure above?

Here is what's going on: Maple calculates the bounding box to be: %%BoundingBox: 126 156 486 635
The printed border matches this exactly, as can be checked in Ghostview by selecting Options --> Show Bounding Box.
However, hovering with the mouse over the bounding box boundery reveals that the true bounding box should in fact be: %%BoundingBox: 156 486 635 126

For some reason, manually editing the bounding box did not help. Something else needs to be fixed. There may be a rotation problem ... See below for a view of the image with both the Ghoscript bounding box and the Maple border --- they disagree. Any idea of what could be wrong with the bounding box?

Thanks, I do appreciate your help very much.

A related question is, can we control the amount of white space between the edges of the image and the border? between the border and the axes? In theory, I think it involves using the following options, but in practice I couldn't get it to work (see the output below)

plotoptions="color=rgb,landscape,border,transparent,shrinkby=0,width=480pt,height=360pt,axiswidth=480pt,axisheight=360pt"

One thing I discovered about Gostview (I usually convert postscript to pdf on the fly so I don't get to use Ghostview much) is that the display settings under Media --> Display Settings can be adjusted to great effect; for instance, changing resolution to 300, Zoom resolution to 600, Depth to 24, I got an awesome-looking display. See below (it's a screen capture saved as jpeg)

The first image shows the great resolution. The second image shows that the plot does not fill the image enough. The third image shows the problem with the bounding box.

 For the purpose of replication, I used the same modified procedure as above, the same testplot, and the following options:

myPlotPS(testplot
 , plotoptions="color=rgb,landscape,border,transparent,shrinkby=0,width=480pt,height=360pt,axiswidth=480pt,axisheight=360pt"
 , thin = 4
 , medium = 8
 , boundarythick = 1
 , fonttype = "Times"
 , fontsize = 80
) ;

Thanks John for bringing this problem up. It's great that there is a workaround. I've been having the same problem you describe and have been looking for a workaround for some time. I eventually resorted to exporting the plot data and using other software to draw the graphs. But I very much welcome a fix that would allow me to produce publishable-quality Maple plots on the fly, as it were. I'm so pleased to see how this thread has come pretty close to an acceptable fix.

John, the plot you posted uses the default Helvetica font and large size. Perhaps you want to modify that, so with the small fix below it's done rather easily.

Thanks to Joe's procedure, we can access another postscript driver than the one Standard GUI currently uses to produce 3D plots (by contrast, 2D postscript plots are rather good in the Standard GUI, I think). As Alejandro reminds us, Maple uses several plot drivers. The Standard GUI driver that takes care of 2D plots was recently rewritten, thoroughly and from scratch afaik, but by contrast the 3D plot driver was not re-written and instead has been, how shall I put it, ruined, yes that's a good word. Instead of producing the classic-style looking plots, with their inelegant default font types and sizes, the 3D plot driver produces a sort of "dirty snapshot" quality wrapped in a postsript code, but no longer true postscript, with the result that the exported plots are essentially useless and cannot be fixed by editing the postscript code. With Joe's code, one gets a true postscript plot, therefore editable.

I'm finally able to test this approach on some of my own plots. And in so doing, I've learned a thing or two. So I'd like to describe here the very small changes I made to Joe's procedure. The results are: added control over the font type and font size, control over the bounding box thickness, and a small fix to remove the DSC error message.

Initially I thought that passing the font size and type information to the plot would work, as in 'axesfont'=[TIMES,10], 'labelfont'=[TIMES,ROMAN,10] , but it didn't, for some reason (perhaps a silly mistake), so instead I extended Joe's editing approach to obtain the same result. It was both an exercise in understanding the code and something I will actually need in real life.

One thing that was not immediately clear to me was the role of "thin", "medium" and "thick." These are shorthands for 3 different sizes defined within the postscript file by Maple's plot driver, and with default values 3, 7, 16. But what do they actually control? In my limited testing, with the test plot below, "thin" controls the tickmarks while "medium" controls the line thickness, and "thick" is not used at all. I do not know if that is a general feature or specific to the examples I tried. I note that the Standard GUI plot driver for 2D plots does not define the "thin", "medium" and "thick" shorthands; it works differently.

This is my test plot. I have chosen a test plot that makes it easier to see the axes than Joe's example.

testplot := plot3d( [4+x*cos((1/2)*y), y, x*sin((1/2)*y)]
  , x = -Pi .. Pi
  , y = 0 .. 2*Pi
  , 'coords' = cylindrical
  , 'style' = patchnogrid
  , 'grid' = [60, 60]
  , 'orientation' = [35, 135]
  , 'lightmodel' = light4
  , 'shading' = zhue
  , 'scaling' = constrained
  , 'transparency' = .3
  , 'axes' = normal
) :

### Joe's procedure modified

myPlotPS := proc( plt
                , { plotoutput :: string := "plotfile.eps" }
                , { thin :: posint := 3 }
                , { medium :: posint := 7 }
                , { thick :: posint := 16 }
                , { boundarythick :: integer := 20 }
                , { fonttype :: string := "Helvetica" }
                , { fontsize :: posint := 133 }
                , { plotoptions :: string := "" }
                , { tmpfile :: string := "plotfile.mpl" }
              )
local cmd, fd, str;
uses FT = FileTools, ST = StringTools;

    if IsWorksheetInterface() then
        ### Create temporary file
        fd := fopen(tmpfile, 'WRITE', 'TEXT');
        fprintf(fd, "plotsetup('ps', 'plotoutput = %a', 'plotoptions' = %a);\n"
                , plotoutput
                , plotoptions
               );
        fprintf(fd, "print(%a);\n", plt);
        fclose(fd);

        ### Pass temporary file to maple tty executable
        if kernelopts('platform') = "unix" then
            cmd := "maple";
        else
            cmd := cat(kernelopts('bindir','dirsep'),"cmaple");
        end if;
        cmd := sprintf("%s %s", cmd, tmpfile);
        ssystem(cmd);
    else
        plotsetup('ps', _options['plotoutput'], _options['plotoptions']);
        print(plt);
        plotsetup('default');
    end if;

    ### Modify the generated postscript file
    str := FT:-Text:-ReadFile(plotoutput);
    fclose(plotoutput);

    ### keyword "thin" controls axis tickmark thickness
    str := ST:-RegSubs("\n/thin ([0-9]+) def" = sprintf("\n/thin %d def", thin), str);
    ### keyword "medium" controls axis line thickness
    str := ST:-RegSubs("\n/medium ([0-9]+) def" = sprintf("\n/medium %d def", medium), str);
    ### keyword "thick" is unused in examples I tried
    str := ST:-RegSubs("\n/thick ([0-9]+) def" = sprintf("\n/thick %d def", thick), str);
    ### keyword "boundarythick" controls border thickness, if any
    str := ST:-RegSubs("\n/boundarythick ([0-9]+) def" = sprintf("\n/boundarythick %d def", boundarythick), str);
    ### keyword "fontsize" controls both title and label font sizes, see /defaultFont and /defaultTitleFont
    str := ST:-RegSubs("findfont ([0-9]+) scalefont setfont" = sprintf("findfont %d scalefont setfont", fontsize), str);
    ### keyword "fonttype" controls both title and label font types, see /defaultFont and /defaultTitleFont
    str := ST:-RegSubs("Helvetica" = sprintf("%s", fonttype), str);
    ### Remove Postscript DSC error
    str := ST:-RegSubs("\n%%Pages:  ([0-9]+)" = sprintf("%"), str);

    FT:-Text:-WriteString(plotoutput, str);
    fclose(plotoutput);

end proc:

### Testing the procedure

myPlotPS(testplot, plotoptions="color=rgb"
 , thin = 4
 , medium = 8
 , boundarythick = 0
 , fonttype = "Times"
 , fontsize = 80
) ;

myPlotPS(testplot, plotoptions="color=rgb"
 , thin = 20
 , medium = 20
 , boundarythick = 50
 , fonttype = "Times"
 , fontsize = 200
) ;

Comments:

1. the code currently does not distinguish between the label font and the title font. I couldn't be bothered to go to that next level since I don't use a title myself.

2. The figure border can be removed altogether by using the noborder option in plotoptions. I usually select something like this: 'plotoptions'=`color,portrait,noborder,transparent,width=512pt,height=320pt`

3.  The tweaks I made were obtained by purely intuitive ways by copying and modifying Joe's procedure. They may not be robust to other examples than the one I used for very limited testing. For instance, I have no idea what ([0-9]+) means, but it just seemed to do the job. Suggestions for improvements are naturally very welcome.

nice one, note that this won't work in classic GUI (but neither does my suggestion, for some reason!)

nice one, note that this won't work in classic GUI (but neither does my suggestion, for some reason!)

thanks a lot for your prompt replies,

@acer,

sorry that my question was not clear.

@epostma,

I tried CodeGeneration[Matlab] because that's what I had sucessfully used before, but for this particular purpose I am not tied to a Matlab output, and Maple is fine. I just didn't know about %a, it's that simple.

This is the sort of output I was looking for, e.g.

dx = x*y-1/3*(y-z)
dy = -.01*x
dz = 1/10*z

0.10 instead of 1/10 would be acceptable. All of these .1, .10, 0.1, 0.10 would be acceptable. It's the e0, e1, e2 that I'm trying to avoid.

With Eric's or Joe's suggestions (thanks a lot!), I get

dx = x*y-1/3*y+1/3*z
dy = -.1e-1*x
dz = 1/10*z

So that's a lot better than

dx = x * y - y / 0.3e1 + z / 0.3e1;
dy = -0.1e-1 * x;
dz = z / 0.10e2;

but there's still one .1e-1 in there, can we get rid of it?

thanks a lot for your prompt replies,

@acer,

sorry that my question was not clear.

@epostma,

I tried CodeGeneration[Matlab] because that's what I had sucessfully used before, but for this particular purpose I am not tied to a Matlab output, and Maple is fine. I just didn't know about %a, it's that simple.

This is the sort of output I was looking for, e.g.

dx = x*y-1/3*(y-z)
dy = -.01*x
dz = 1/10*z

0.10 instead of 1/10 would be acceptable. All of these .1, .10, 0.1, 0.10 would be acceptable. It's the e0, e1, e2 that I'm trying to avoid.

With Eric's or Joe's suggestions (thanks a lot!), I get

dx = x*y-1/3*y+1/3*z
dy = -.1e-1*x
dz = 1/10*z

So that's a lot better than

dx = x * y - y / 0.3e1 + z / 0.3e1;
dy = -0.1e-1 * x;
dz = z / 0.10e2;

but there's still one .1e-1 in there, can we get rid of it?

Thanks acer,

when I saw the question the first time, I thought there's something I too would like to know how to do, but being busy with other (less fun but paid) things I merely made a mental note of it. I was quite surprised to discover a little later that no answer had been forthcoming. Even more surprised when google did not return too much on Maple and bifurcation (There is a very useful Maple application by Doug Meade, http://www.maplesoft.com/applications/view.aspx?SID=4694). Nusc's code was right there within mapleprimes, but the OP seemed unaware of it. I made small modifications suggested by Robert Israel and re-posted. I'm glad that the topic has interested you. The plot you get (thanks Preben for posting) is a great improvement. I did originally notice the code was not efficient, and immediately thought about your excellent post

http://www.mapleprimes.com/posts/123463-ImageTools-For-Complex-argument--Plot

That post had much about how to efficiently create colorful density plots. I have just discovered a colorful variant of the bifurcation diagram, written for r*x(1-x^3). The code is written in C. [EDIT: code deleted for fear of copyright issues] Please refer to David Green, the author, http://www.flickr.com/photos/davidmxg/5271405684/

sorry I don't have anything very constructive to say, except why don't you run it all under Maple 14?

I'm testing a worksheet in standard GUI in Maple 15 Windows. No problem here.

Is this a problem of document versus worksheet input format? what version of Maple do you have?

and of course there is also the case of Pi and pi, probably even more common than e/E/exp(1)

as Roman Pearce rightly points out (in the thread from which this is branched), "we should fix this" I agree!!

Maple is sometimes very forgiving, e.g. (this is in Standard GUI):

plot(x,'color'=blue); #ok
plot(x,'colour'=blue); #ok
plot(x,'colour'=BLUE); #ok

and sometimes not, e.g.

plot(x,'COLOR'=blue); #nok

Other example:

plot(x, 'style' = point, 'numpoints' = 10, 'symbol' = circle); #ok
plot(x, 'style' = point, 'numpoints' = 10, 'symbol' = CIRCLE); #ok
plot(x, 'style' = POINT, 'numpoints' = 10, 'symbol' = CIRCLE); #ok
plot(x, 'STYLE' = POINT, 'NUMPOINTS' = 10, 'SYMBOL' = CIRCLE); #nok

And of course Maple's Number One FAQ:

exp(1); # ok
e^(1); # nok
e(1); #nok

I think there is a case for having something like this:

restart;
load(builtin); #I'm making this up,

load(builtin) --- or restart[builtin]; or whatever --- would load names and aliases for builtin functions like the exponential function, the e constant, etc.. Thus, if it were not loaded, you could use gamma and I to mean whatever you like, and not just the gamma constant and the imaginary unit; but if it were loaded, Maple would treat gamma and I as the builtin functions. In the first releases builtin could be on by default. In addition, certain expressions would trigger an information message from the interface.

Example: If you typed e^(1);

Maple would produce a message like "statement ambiguous, do you mean exp(1)? To turn off this message, enter load(builtin,silent)"

good/bad idea?

are you using the same options on both versions? have a look at Tools --> Options --> Precision, any differences there?

I have moved from ubuntu 10.10 to ubuntu 11.10, but it wasn't plain sailing and I understand not everyone is upgrading, so might there be a way to nevertheless use Maple 16 with 10.10? If so, a short hacking strategy would be great to have for those planning to stay with 10.10 a little while longer. Purely personally I welcome the upgrade.

thanks acer, this is the sort of thing that I'll find very, very handy.