That approached certainly worked for me.  It's good to know there's a viable  alternative, because so far I've found the VectorCalculus package pretty frustrating for all but the most trivial things.  Thanks for the Suggestion.

- Dushan

That approached certainly worked for me.  It's good to know there's a viable  alternative, because so far I've found the VectorCalculus package pretty frustrating for all but the most trivial things.  Thanks for the Suggestion.

- Dushan

Well, I spoke too soon.  I thought for sure that a fixed-width font must be the answer, but I found out it isn't.  In fact, all the fonts produce the same feature, that the minus sign '-' is shorter that the plus sign '+'.  The fonts Courier, Monospaced, etc., all show the same thing.  I took the strings

     'a + b - c'

and 'a - b + c'

and lined them up as above.  I'm using fixed-width font here (Monaco) and on my browser posting window the a, b, & c all line up.  In the Maple window, using any fixed-width fonts, the 'a' and 'c' line up but the 'b's do not.

So for some reason Maple 12 is breaking the fixed-width standard.  I wonder why.  If anything I would expect the minus sign, having less 'ink' than the plus sign, to be at least as big to make sure it is seen.

- Dushan

I had not noticed the 'Text' option in the Search, but as you pointed out, that did do the job.  Thanks.

As for Maple 13 having been updated, that's nice, but not useful to me since I have Maple 12.  But even in Maple 13, I wonder how clever the Title Search is: do you have to know the _exact_ title, or will perturbations about the name also connect with the sought-for information?

- Dushan

That should have occured to me, but didn't.  Yes, that looks like the answer - I've now changed the font to a fixed-width oneand things look better.  Thanks for the pointer.

- Dushan

Thanks for this explanation.

I'll try again, having found a simpler example.  Using Maple 12.02 on a Mac running OS X.4.11.

As a first step trying to simplify a longish expression (pasted together
from separate parts), I copy it to a scratch worksheet and ask it be dis-
played.  It shows up (2D Math mode) with the front part of it missing.
When I step through the expression with the arrow keys, the mode stays
the same, so there doesn't seem to be break in it.  Here's the expression
and its displayed form, pasted into the box that appears on clicking on the
Maple leaf icon above this message input area:

> (R[T] - epsilon[x]*w)*; (2*R[Z]-Z)/(R[Z]^2*(R[Z]-Z)); - ; (R[T]; + epsilon[x]*w)*; > (2*R[-Z]-Z)/(R[-Z]^2*(R[-Z]-Z))-4*R[T]*w*X/(R[-Z]^2*R[Z]^2); print(`output redirected...`); # input placeholder 2 R[-Z] - Z 4 R[T] w X ------------------ - ------------ 2 2 2 R[-Z] (R[-Z] - Z) R[-Z] R[Z]

I don't know if this will magically appear on the post as it does on my work-
sheet.  I suspect not, so had better describe what I see.  The original expres-
sion has been assembled (copied/pasted) from previously obtained pieces to
produce three main terms.  In its 2D Math form the five extra `;` symbols are
not apparent.  On hitting 'Enter' the resulting displayed expression is the
same after the subexpression `+epsilon[x]*w*`, but ignores everything before
it -- that is, before the last of the `;` symbols.

In the earlier post with the longer expression, when I tried to clean it up by
selecting all of it, converting it to 1D Math, deleting the extraneous symbols,
then converting it back to 2D Math, it refused the back-conversion.  In the
present example I was able to clean out the `;` symbols by avoiding the con-
version entirely and simply copying/pasting the expression in 2D Math mode
and deleting whatever didn't belong there.  When I hit 'Enter' to display it,
the complete expression appeared correctly.

It looks like the problem is the extraneous symbols, not apparent in the origi-
nal 2D Math expression, that probably got put there by the copy/paste ope-
ration.  How do I to avoid their unwanted introduction in the first place?

Thanks.

- Dushan Mitrovich

PS, when previewing this post it appeared okay (no formatting symbols) but
the Maple expressions appeared as just text.  After actually posting the com-
ment, I saw that the formatting symbols were back.  On invoking `Input for-
mat`, I see that `Filtered HTML` is checked.  So I have no idea why things
are getting messed up.  My apologies.

Thanks for this explanation.

I'll try again, having found a simpler example.  Using Maple 12.02 on a Mac running OS X.4.11.

As a first step trying to simplify a longish expression (pasted together
from separate parts), I copy it to a scratch worksheet and ask it be dis-
played.  It shows up (2D Math mode) with the front part of it missing.
When I step through the expression with the arrow keys, the mode stays
the same, so there doesn't seem to be break in it.  Here's the expression
and its displayed form, pasted into the box that appears on clicking on the
Maple leaf icon above this message input area:

> (R[T] - epsilon[x]*w)*; (2*R[Z]-Z)/(R[Z]^2*(R[Z]-Z)); - ; (R[T]; + epsilon[x]*w)*; > (2*R[-Z]-Z)/(R[-Z]^2*(R[-Z]-Z))-4*R[T]*w*X/(R[-Z]^2*R[Z]^2); print(`output redirected...`); # input placeholder 2 R[-Z] - Z 4 R[T] w X ------------------ - ------------ 2 2 2 R[-Z] (R[-Z] - Z) R[-Z] R[Z]

I don't know if this will magically appear on the post as it does on my work-
sheet.  I suspect not, so had better describe what I see.  The original expres-
sion has been assembled (copied/pasted) from previously obtained pieces to
produce three main terms.  In its 2D Math form the five extra `;` symbols are
not apparent.  On hitting 'Enter' the resulting displayed expression is the
same after the subexpression `+epsilon[x]*w*`, but ignores everything before
it -- that is, before the last of the `;` symbols.

In the earlier post with the longer expression, when I tried to clean it up by
selecting all of it, converting it to 1D Math, deleting the extraneous symbols,
then converting it back to 2D Math, it refused the back-conversion.  In the
present example I was able to clean out the `;` symbols by avoiding the con-
version entirely and simply copying/pasting the expression in 2D Math mode
and deleting whatever didn't belong there.  When I hit 'Enter' to display it,
the complete expression appeared correctly.

It looks like the problem is the extraneous symbols, not apparent in the origi-
nal 2D Math expression, that probably got put there by the copy/paste ope-
ration.  How do I to avoid their unwanted introduction in the first place?

Thanks.

- Dushan Mitrovich

PS, when previewing this post it appeared okay (no formatting symbols) but
the Maple expressions appeared as just text.  After actually posting the com-
ment, I saw that the formatting symbols were back.  On invoking `Input for-
mat`, I see that `Filtered HTML` is checked.  So I have no idea why things
are getting messed up.  My apologies.

SOLVED: I just stumbled on the fix to the overly-wide Document window.  To make the window more visually bearable I use a 1x1 Table with a light gray background.

When I R-clicked on an empty part of the Table one of the items that showed up was Properties.  Looking at that I noticed that the size was set to some number other than 100%.  After resetting that to 100% and he number of Points to 666666, the Table size went back to normal and the horizontal scroll bar disappeared.  I still have no idea why things got messed up in the first place, but now at least I know how to correct that particular problem.

Thanks for inspiring me to trip over this fix.

- Dushan

PS, when I hit Reply to one of these comments, the Subject: line is blank and I've been cutting-and-pasting the original one into it to stay on the thread.  Is this necessary, or would this already be done automatically?

SOLVED: I just stumbled on the fix to the overly-wide Document window.  To make the window more visually bearable I use a 1x1 Table with a light gray background.

When I R-clicked on an empty part of the Table one of the items that showed up was Properties.  Looking at that I noticed that the size was set to some number other than 100%.  After resetting that to 100% and he number of Points to 666666, the Table size went back to normal and the horizontal scroll bar disappeared.  I still have no idea why things got messed up in the first place, but now at least I know how to correct that particular problem.

Thanks for inspiring me to trip over this fix.

- Dushan

PS, when I hit Reply to one of these comments, the Subject: line is blank and I've been cutting-and-pasting the original one into it to stay on the thread.  Is this necessary, or would this already be done automatically?

Thank you, David, you've solved my questions 2 and 4.

But the fix you recommend for #3 doesn't work in me.  Yes, there is a scroll bar at the bottom, but even after going through the whole Document and making sure that nothing I wrote, not the title nor plot, sticks past the Doc window's L or R borders, the Doc area is always bigger than the window.  If I collapse both Dock areas this is still true, and remains true even if I drag the R window boundary all the way across to the R edge of the screen: all the centered objects (title, plots, Maple output expressions) stay centered on an ever wider dimension, the horizontal scroll bar persists, and always occupies a constant fraction of the scrolling range.  I.e., if the scroll bar has length 1, its range is about 1.27 (I've measured this).  It's as though the program thinks the Doc window is 27% wider than it actually is.

Any other suggestions for fixing this?  It's not a show stopper, of course, but it would be nice if plots and Maple output didn't automatically get truncated on the right.  Thanks.

- Dushan Mitrovich

Thank you, David, you've solved my questions 2 and 4.

But the fix you recommend for #3 doesn't work in me.  Yes, there is a scroll bar at the bottom, but even after going through the whole Document and making sure that nothing I wrote, not the title nor plot, sticks past the Doc window's L or R borders, the Doc area is always bigger than the window.  If I collapse both Dock areas this is still true, and remains true even if I drag the R window boundary all the way across to the R edge of the screen: all the centered objects (title, plots, Maple output expressions) stay centered on an ever wider dimension, the horizontal scroll bar persists, and always occupies a constant fraction of the scrolling range.  I.e., if the scroll bar has length 1, its range is about 1.27 (I've measured this).  It's as though the program thinks the Doc window is 27% wider than it actually is.

Any other suggestions for fixing this?  It's not a show stopper, of course, but it would be nice if plots and Maple output didn't automatically get truncated on the right.  Thanks.

- Dushan Mitrovich