I cannot say it is a bug, but it seems a malfunction, that I was at least unable to solve.
The top of the equation cannot be shown in the main window, even when the interline is made big.
Moreover, the equation seems quite difficult to handle: after moving it by drag and drop two lines above or below, the equation is not longer recognized as mathtype object: the right click shows just the menu “Edit Image…” instead of “Edit Mathtype…”. And even when it is not moved, the standard function of two clicks on the equation to launch mathtype, it never works. In these conditions it becomes unreliable to do serious work.
On the first problem I mentioned, see attached image:
Did you use the Edit/Insert/MathType Equation menu command to create it in the first place? If you use MathType independently, and then export and add the equation as a normal graphic, then the integration will be lost.
Many thanks for your kind reply.
Yes, I use the standard insert command. In fact, I noticed that Scrivener does not accept copy and paste equations from Mathtype.
I know that com objects are difficult beasts. In my very limited experience, I notice that Scrivener handles better (old feature) “insert images”. Mathtype can save gif equations (or it can save eps and wmf format), which remain editable. I notice that if I use insert gif equations as images, they are inserted without cuttings at the top (or at the bottom) as it was shown in my previous attachment.
As it stands, this workflow would have its negative side. To edit an equation, one needs with Scrivener to start all over again: remove the old image and insert the edited one.
Okay, I can reproduce the cropping problem but not the drag and drop problem. I have tried dragging the equation around within a single split, and from one split to another, and it survives intact. I can right-click on it and edit it further. What does appear to break is copy and paste. So I’m adding both the cropping problem and copy and paste to the bug queue. Since drag and drop works, I’m hoping copy and paste should be easy to resolve.
Thanks for the feedback. Also in my case the drag and drop does not always produce the change of the right-click Edit menu. I shall try to pin down the conditions that consistently produce the potential mulfunction and come back to you.
create several paragraphs in a new section (o subsection) with few words of text, for each paragraph.
create a Mathtype (MT) equation in the first paragraph - use the square root of the MT toolbar with a^2+b^2.
drag and drop the new equation in the same paragraph (same line). MT equation remains editable.
drag and drop the same equation in one of the paragraphs below (with only few words, and no created equations). In that case the equation is seen with right-click as Edit image. (in its properties the name shown is a long string of numbers).
Other quirck that sometimes occures with MT is the following. Select an equation (possibly with the selection that includes a space). Edit with MT, confirm save and Scrivener adds the edit equation along the old one.
Got it, thanks. The interesting thing is that you can fudge with the order a bit. If you drag the equation from paragraph A to para B first, before doing anything else, then it will remain a MathType image. If you then drag it from column 40 in para B to column 20 in para B, it remains a MathType image. If you drag it from para B to para A, back to where it started, then it becomes an image. So it seems actually to be:
You can drag it within a paragraph all you want
You can move it to another paragraph so long as it has never been dragged before.
Those conditions persist since they can be arranged to not conflict. Condition 1 can be continued after condition 2 has been triggered.
And yes, the equation duplication issue is a known one.
Update: Hmm, actually the above isn’t quite it either. There is something else that is the trigger. I was trying to narrow it down for Lee by making a new equation in the test file I’d set up and just reproduce it in, and now I can drag it all over the place successfully. So something else is the trigger.
Thanks for your attention.
Just a broad naive statement. Since with com objects there are problems, a more transparent method could be to use mathtype equations as editable images: the images saved in a folder of the project that can be modified within Scrivener by calling MT with a right-click, just as it is now (MT is able to edit MT images). In that way the Scrivener document would be much lighter since does not have to embed objects but just to contain a reference to images. Moreover, the mathtype gives also the right specs, that can be used to place the MT image with the correct inline position.
I know, there is after the problem of exporting… to MS Word etc…Well just a thought.
I could be wrong about this, but I don’t think these are COM objects. Looking at the RTF code, it looks like PNG data with MathType data alongside it. The data is used to set up the equation editor when you right-click on the picture.
Yeah this is still marked as open in the system. The problem is, after a reboot I could never get it to reproduce again, and neither could the developer, so unless you have any further information that might help narrow down the steps required to reproduce it, we’re kind of stuck in the dark.
The pattern that I notice is shown by the image: when in doing the drag&drop the baseline of the equation object does change, the mathtype object is perceived as an image.
The picture on the right is where the mathtype has been created; on the left after being drag and drop.
