I want this ticket to be sort of "summing up" one, which would have the maximum of pertinent keywords (so, show up in searches and new issues' forms), and correctly formulate the problem, too. When LO/OOO exports the document with formula(s) to MS Word .doc format, two important transformations should be done: 1) 'Fonts size' set of settings for each formula must be transformed into the respective MS Word MathType object set of settings. 2) Rendered formula(s) image(s) of acceptable quality should be put into the exported .doc. I'm attaching: * two simple ODT with A^b formula (one in 14pt, one in 8pt) and some 14pt text, all in Times New Roman * two respective exported DOCs * two snapshots of what MS Word 2003 shows when those DOCs are opened * two snapshots of what MS Word 2003 shows when those DOCs are opened AND formula is double-clicked (opened for editing) and closed (Escape key) without making any changes ** At the moment of testing the MS Word installation had its default settings for MathType objects font sizes as 10pt for formula body text and 7pt for "big" superscript On proofpics one can see that: 1bad) ODT 'Fonts size' data is either ignored or placed into the .doc in a wrong way -- after re-rendering formulas in Word (opening/closing; two snapshots with *_post_doubleclick* in names) the size is obviously something like 10pt in all cases ** this might or might be not worked around by re-setting MS Word default MathType objects' font sizes before opening the LO-exported DOC (I didn't test this yet) 2bad) LO puts the exported rendered image frame too high w/r to the baseline of the paragraph the formula is in (compare the respective *_before_doubleclick* and *_post_doubleclick* pairs) ** this necessitates double-clicking every formula in Word after every export (grand PITA!!)
Created attachment 114946 [details] original ODT, 14pt in formula
Created attachment 114947 [details] original ODT, 8pt in formula
Created attachment 114948 [details] DOC exported from ODT with 14pt in formula
Created attachment 114949 [details] DOC exported from ODT with 8pt in formula
Created attachment 114950 [details] snap of DOC (... 14pt ...) opened, before doubleclick+escape
Created attachment 114951 [details] snap of DOC (... 14pt ...) opened, after doubleclick+escape
Created attachment 114952 [details] snap of DOC (... 8pt ...) opened, before doubleclick+escape
Created attachment 114953 [details] snap of DOC (... 8pt ...) opened, after doubleclick+escape
(In reply to Yury from comment #1) > Created attachment 114946 [details] > original ODT, 14pt in formula Reproduced. Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64) Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9 TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50 Locale: fi_FI
And it will be very, very difficult to solve, without an access to some good docs on storage of 'Microsoft Equation 3.0' objects' properties -- that is, not MathType objects /per se/, but their wrappings inside the .DOC container. Even the placement of those things isn't readily evident. I couldn't find it, at least -- seems to be not stored in raw, but, guessing, as a some kind of diff.
Haha, I think I've got it! Seems Word 2003 does NOT store anything about the concrete settings according to which the actual processing (rendering) of MathType objects is done! I've just made a series of .DOCs each consisting of one (and the same) empty formula only, changing only one aspect (one font face in styles, one pointsize in sizes) of Equation Editor, then 'saving as' under a different name. Lots of changes inside of those .DOCs, regardless of nothing being really changed (excepting the timestamp). However, any of those .DOCS (re-)opens to the Eq. Editor style/size settings as set at last time, not as set when saving the .DOC. So, it looks like the .DOC file just doesn't contain any information on font/size setting for formulas rendering -- the Word installation does (at least, it is so in Word 2003 I have access to). I hope this this little experiment proves that sizing the imported formulas to the 12/8 combination with `eqn` instructions 'size 12' and 'size 8' is unnecessary, counter-productive, indeed. So the whole business with 'size 12' and 'size 8' should be excluded from LO starmath module, just like I've been suggesting for years in https://bugs.documentfoundation.org/show_bug.cgi?id=45284 I believe this leaves only the matter of previews with lower edge shifted up.
Created attachment 124217 [details] ODT with formula and some text around, 5.* series
Created attachment 124218 [details] ODT with formula etc. exported to Word 2003 .DOC
Created attachment 124219 [details] DOC in Word 2003, before clicking into MathType editor
Created attachment 124220 [details] DOC in Word 2003, MathType editor active, with nothing changed
Created attachment 124221 [details] DOC in Word 2003, MathType editor closed with nothing changed
Created attachment 124222 [details] DOC (just as exported) back in LO
Created attachment 124223 [details] DOC (just as exported) back in LO, after StarMath, with nothing changed
Just added attachments 124217-124223, hope the descriptions are sufficient. Please look into that problem, guys. The StarMath/MathType object preview 'shifting up' in exported DOC is quite a showstopper, one has to reclick every individual formula in Word (and keep Word at hand, for that matter). I've tried to do something myself, honest, but actually I'm not capable even of finding the code which positions the exported preview (incorrectly). *** The dimensions of the preview itself generated subtly out of expected proportion are secondary to this. Dialogs from Russian-language Word refer (fields from left to right) to 1) `object` height 0,63cm/0,64cm and width 0,53cm and scale 99% (attachment 124219 [details] `before MathType`) 2) `object` height 0,57cm/0,56cm and width 0,67cm and scale 101%/100% (attachment 124221 [details] `MathType closed`)
Still reproducible Version: 5.4.0.0.alpha0+ Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02 Locale: nl-NL (nl_NL); Calc: CL
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Version: 5.4.4.2 Build ID: 2524958677847fb3bb44820e40380acbe820f960 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: ru-RU (en_GB.UTF-8); Calc: group Issue still there. Is there a need to attach a proofdoc?
Can't test in 6.0.0.1, as the appimage variant crashes immediately after adding, editing and exiting the edit mode of the math object.
(In reply to Yury from comment #22) > Issue still there. Is there a need to attach a proofdoc? There are already a million attachments in this report, so no.
Of course the issue's still there. Version: 6.2.0.1 Build ID: 0412ee99e862f384c1106d0841a950c4cfaa9df1 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; Locale: ru-RU (en_GB.UTF-8); UI-Language: en-US Calc: threaded PS You'll notice I've used the 'gen' VCL plugin, because the 'gtk' one requires wayland now, and I don't even have that thing installed.
Same here: Version: 6.3.0.0.alpha0+ Build ID: 19d9ac1031a08525ed5a5638ceaf508be870825e CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-12-16_01:24:21 Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: CL
(In reply to Yury from comment #26) > PS You'll notice I've used the 'gen' VCL plugin, because the 'gtk' one > requires wayland now, and I don't even have that thing installed. Generally this is not true. Maybe your Linux distribution has some weird dependency set up.
Dunno about 'generally'. Specifically, I'm getting this: /opt/libreoffice6.2/program/soffice.bin: symbol lookup error: /opt/libreoffice6.2/program/libvclplug_gtk3lo.so: undefined symbol: gdk_wayland_display_get_type I'm not re-fetching the 6.3 appimage, but it looked the same with that.
...ah, and to clear the name of my distro :) -- the tail of 'ldd -r libvclplug_gtk3lo.so' output: undefined symbol: gtk_scrolled_window_set_propagate_natural_width (./libvclplug_gtk3lo.so) undefined symbol: gdk_wayland_window_set_dbus_properties_libgtk_only (./libvclplug_gtk3lo.so) undefined symbol: gdk_display_get_default_seat (./libvclplug_gtk3lo.so) undefined symbol: gtk_scrolled_window_set_propagate_natural_height (./libvclplug_gtk3lo.so) undefined symbol: gdk_seat_grab (./libvclplug_gtk3lo.so) undefined symbol: gdk_wayland_display_get_type (./libvclplug_gtk3lo.so) undefined symbol: gdk_seat_ungrab (./libvclplug_gtk3lo.so) undefined symbol: gdk_wayland_window_get_wl_surface (./libvclplug_gtk3lo.so) undefined symbol: gtk_menu_popup_at_rect (./libvclplug_gtk3lo.so)
Dear Yury, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Yury, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug