Issue 23698 - equations are croped on top
Summary: equations are croped on top
Alias: None
Product: Math
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC Linux, all
: P3 Trivial with 5 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2003-12-19 00:19 UTC by gach
Modified: 2013-08-07 14:54 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

an example to ilustrate this bug... (357.73 KB, application/vnd.sun.xml.writer)
2003-12-19 00:21 UTC, gach
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description gach 2003-12-19 00:19:39 UTC
The equations are croped on OO.o 1.1. The top of the formulas is not
displayed/printed/pdfed. The problem is temporarily solved by moving the formula
one line down (pressing Enter) and back up (with backspace), but after doing
that through the whole document some formulas get reset to their croped form
once again. In the end there is allways a couple of formulas that aren't
displayed right

You can use this file as an example

Let me know if I should test something else.
Comment 1 gach 2003-12-19 00:21:55 UTC
Created attachment 12022 [details]
an example to ilustrate this bug...
Comment 2 gach 2003-12-19 00:23:35 UTC
By the way, this bug is as old as Star Office 5.2. I've been reporting it throuh
the different versions of
Comment 3 jensja 2004-04-05 20:20:47 UTC
Reproducible with OOo1.1.1 on Win2k. 
Some formula object anchored "as character" is not displayed completely.

Workaround: Adding a top margin of eg. 0.2 cm to all formula objects seems to
cure the problem. This can be achieved by changing the value in the frame style
Comment 4 thomas.lange 2004-04-21 10:15:01 UTC
Comment 5 thomas.lange 2004-04-21 10:16:59 UTC
TL->MRU: Please have a look in this how serious it is and if it also affects
printing to choose a target accordingly. Thanks!
Comment 6 gach 2004-04-21 10:30:53 UTC
I can confirm that it affects printing. Formulas are also cropped on the
generated postscript.
Comment 7 michael.ruess 2004-06-17 14:56:00 UTC
MRU->TL: not pretty, but I guess that there are no resources available to fix it
for OO 2.0... thus "OO later" target
Comment 8 gach 2004-06-17 15:51:23 UTC
I am sorry to see that this issue is not taken more seriously. Due to this one,
OO.o is unusable for engineering/maths/physics/... students, which are not that few.
Comment 9 quetschke 2004-06-17 18:34:08 UTC
I just had a look at that document. I would guess that this document was not
created with OOo 1.1.x. When you move the formula by click-drawing it down,
releasing it, and move it up back to the original position, the cropping is gone.

I cannot confirm that printing a page with cropped formulas does show the
cropping. I printed page seven, and formulas (2.14) and (2.15), although
cropped on screen, look good in the printed page.
(OOo 1.1.1 on Windows XP)

vq->gach: Please vote for issue 972, that is really a stopper for scientific
Comment 10 gach 2004-06-17 18:59:26 UTC

This document was written on OO 1.1 on linux (1.0 wasn't even usable for
formulas) but the bug is reproducible on windows as well. 

I think this one is really a stoper. I will vote for it as you suggest.
Comment 11 quetschke 2004-06-17 19:31:11 UTC
vq->gach: Yes, I can definitely confirm the cropping when the formulas
are displayed on screen, but not when printed.
(using OOo 1.1.1 on WindowsXP)

I can now also confirm that the pdf output is cropped, this makes the document
essentially useless, but moving the formulas down and up, as decribed before
cures this problem on screen and in the generated pdf. Possibly there was a
problem with OOo 1.1 generating formulas that might be fixed with OOo 1.1.1.

Please try 1.1.1, I inserted "sqrt {1-u^2 over c^2} over sqrt {1 -v^2 over c^2}"
in a new formula in your document, and it is not cropped.
Comment 12 gach 2004-06-18 12:04:17 UTC

My experience is that moving the formulas solves the problem _temporarily_ . If
you keep on working on the document the problem will come back and once you
solve it at a place it appears somewhere else. After a lot of struglling my
master thesis still ended up with a couple of cropped formulas. I will post the
final document, which is a good test for this bug.

(I started with 1.1 and ended with 1.1.1 IIRC, but I'll confirm this later)

Comment 13 quetschke 2004-06-18 13:47:57 UTC
vq->gach: I wrote my PhD thesis (also physics) in OOo 1.1.1. Something like
160 pages, hundreds of formulas and lots of pictures/drawings.
I had a lot of problems, yes, but never saw a cropped formula. I'm puzzled.
Comment 14 gach 2004-06-18 14:17:47 UTC

Maybe it's worth mentioning that I wrote the document from scratch on OO.o for
linux and only used linux for editing it. Also this may depend on the font one
is using.

I'll post some more info tonight when I can access the documents.

Comment 15 gach 2004-06-24 14:19:35 UTC

- The document was written on OO.o 1.1.0 on Linux

- With this document on 1.1.2 Win32 the problem persists. One can drag the
formula down and up again to fix it, but that makes the problem appear on a
previoulsy not cropped formula. In the end you can never fix the whole document

- The problem appears on the exported PDF file just like it is seen direclty on
OO.o Writer

Comment 16 gach 2004-06-24 14:20:16 UTC
This link

is uptodate for an example document.

Comment 17 brunodu 2004-09-16 16:20:33 UTC

I may have found a work around for this bug:
add ^{stack{~ # ~}} at the top of the equation, exemple you have the equation:

R = { v cos(%theta) }^2 over c^2

which get croped on the top, then make it:

R = { v cos(%theta) }^2^{stack{~ # ~}} over c^2

It will still be croped. BUT the croped part will be the white stack....(fell
free to add as many #~ in the stack as you want!)
It is a once per equation to do job...

Bruno D.
Comment 18 brunodu 2004-09-16 16:27:50 UTC
of course you read:

R = { { v cos(%theta) }^2 } ^{stack{~ # ~}} over c^2
    ^                     ^

my mistake.

Bruno D.