Bug 150368 - Equation editor ignores document zoom, and cannot be zoomed manually
Summary: Equation editor ignores document zoom, and cannot be zoomed manually
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Formula Editor (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Formula-Editor
  Show dependency treegraph
 
Reported: 2022-08-11 08:45 UTC by Klaus
Modified: 2023-04-11 19:52 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the mismatched zoom levels, and how they affect productivity. (291.70 KB, image/png)
2022-08-11 08:48 UTC, Klaus
Details
Odd page- and equation rendering when zooming out a lot (128.03 KB, image/png)
2022-08-11 12:48 UTC, Klaus
Details
Reproduction of issue via Ubuntu browser-VM (344.17 KB, image/png)
2022-08-11 13:25 UTC, Klaus
Details
Why not synchronize the two separate zooms? (610.39 KB, image/gif)
2022-08-11 16:28 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus 2022-08-11 08:45:09 UTC
Description:
The equation editor does not account for document zoom, and doesn't allow manually adjusting the zoom, while editing.



Steps to Reproduce:
1. Create a new equation
2. Write anything inside
3. Zoom in and out in the main document either while or before editing the equation
4. Try to adjust zoom level of equation manually

Actual Results:
During 3., the zoom level of the equation always corresponds to "100%". Only when the document zoom level is at 100%, the rendered equation while editing matches the borders shown in the document.

During 4., the zoom settings of the equation editor are simply greyed out.

Expected Results:
During 3., the zoom level when editing the equation should

  - Match the document zoom level at the time of starting the editing and
  - Update to match the zoom level if the document zoom level is changed during editing


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Reproduced with three builds:

Current nightly:
  Version: 7.5.0.0.alpha0+ / LibreOffice Community
  Build ID: 450471ebbdbff40998509731028b28e0ada53f58
  CPU threads: 12; OS: Linux 5.3; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US
  Calc: CL

Current stable release:
  Version: 7.3.5.2 / LibreOffice Community
  Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
  CPU threads: 12; OS: Linux 5.3; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US
  Calc: CL

Current OpenSuse 15.3 repository version:
  Version: 7.2.5.1 / LibreOffice Community
  Build ID: 20(Build:1)
  CPU threads: 12; OS: Linux 5.3; UI render: default; VCL: gtk3
  Locale: en-US (en_US.UTF-8); UI: en-US
  Calc: threaded
Comment 1 Klaus 2022-08-11 08:48:47 UTC
Created attachment 181720 [details]
Screenshot showing the mismatched zoom levels, and how they affect productivity.
Comment 2 Mike Kaganski 2022-08-11 09:08:15 UTC
(In reply to Klaus from comment #0)
> 4. Try to adjust zoom level of equation manually
> 
> Actual Results:
> During 4., the zoom settings of the equation editor are simply greyed out.

I can't repro this; the zoom control in the status bar works for me on the Math graphic window, zooming it independently of the host document. I'm using Version: 7.4.0.2 (x64) / LibreOffice Community
Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e
CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL

I would expect that both host document and the embedded object zoomed in sync.
Comment 3 Klaus 2022-08-11 10:44:58 UTC
(In reply to Mike Kaganski from comment #2)
> 
> I can't repro this; ...

I just tried on my Windows 10 Laptop, and was able to reproduce the behavior I reported there too.

Version: 7.3.0.3 (x64) / LibreOffice Community
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VLC: win
Locale: de-AT (de_AT); UI: en-US
Calc: threaded

This system is configured entirely independently (private laptop; the original report was made on a desktop PC of my research institution).
Comment 4 Mike Kaganski 2022-08-11 11:30:35 UTC
(In reply to Klaus from comment #3)
> I just tried on my Windows 10 Laptop, and was able to reproduce the behavior
> I reported there too.

I assume that you mean the menu entries, while I talked about status bar zoon control ;)
Comment 5 Klaus 2022-08-11 12:48:10 UTC
(In reply to Mike Kaganski from comment #4)
> (In reply to Klaus from comment #3)
> > I just tried on my Windows 10 Laptop, and was able to reproduce the behavior
> > I reported there too.
> 
> I assume that you mean the menu entries, while I talked about status bar
> zoon control ;)

I can confirm that I mean the menu bar entries, and that the status bar zoom control works.

I also noticed that the issue is less pronounced when working with a maximized window. On my Linux desktop PC, it then occurs only when zooming in strongly, and again when zooming out strongly. At that page even rendering of the pages behaves odd, however (see screenshot).
Comment 6 Klaus 2022-08-11 12:48:57 UTC
Created attachment 181727 [details]
Odd page- and equation rendering when zooming out a lot

See previous comment.
Comment 7 Klaus 2022-08-11 12:50:37 UTC
On my Windows 10 device I cannot reproduce the partial mitigation of the issue for maximized Writer windows.
Comment 8 Klaus 2022-08-11 12:55:22 UTC
On my OpenSuse system, I now observe the font-size auto-adjusting when I actually *change* anything in the equation. I didn't notice that before though.

On Windows 10, this self-correction does not occur.

I am trying to install a Xubuntu VM to demonstrate it...
Comment 9 Klaus 2022-08-11 13:25:42 UTC
Created attachment 181728 [details]
Reproduction of issue via Ubuntu browser-VM

Using Ubuntu via 

   https://www.onworks.net/os-distributions/ubuntu-based/free-ubuntu-online-version-20

and running a 7.4 version via

    wget https://dev-builds.libreoffice.org/daily/libreoffice-7-4/Linux-rpm_deb-x86_64@tb87-TDF/2022-08-11_07.46.26/LibreOfficeDev_7.4.1.0.0_Linux_x86-64_deb.tar.gz
    tar -xzf LibreOfficeDev_7.4.1.0.0_Linux_x86-64_deb.tar.gz
    cd LibreOfficeDev_7.4.1.0.0_Linux_x86-64_deb/DEBS
    for FILE in *.deb; do dpkg -x $FILE .; done
    cd opt/libreoffice7.4/program
    ./swriter

I was again able to reproduce the issue.
Comment 10 V Stuart Foote 2022-08-11 15:46:30 UTC
Actually this seems correct. IIRC the sm "preview" used to only show the specific OLE formula being edited.  The "preview" is now exposing the entire document canvas--holding the OLE frame at the size and zoom of the source document.

The preview is not able to zoom, or respond to zoom actions in the sm Formula editor--so those controls are disabled?

In a sm Formula edit session (i.e. creating an ODF formula .odf directly) zoom and scale functions work correctly.

An actual change to the sm formula is written back to the source document, and embedded formula's frame will update, as will the "preview" in the sm to show the changed size.

What is not making it to the "preview" in sm is the fully rendered formula as its OLE is being edited.  Other embedded formulas in the "preview" are fully rendered.

Will double check how it used to behave, but the current behavior seems consistent for when the sm Formula editor has focus into an embedded formula and is active.

Then question would be what has to happen for the "preview" to show the OLE formula as it is being edited.
Comment 11 Mike Kaganski 2022-08-11 16:28:20 UTC
Created attachment 181730 [details]
Why not synchronize the two separate zooms?
Comment 12 V Stuart Foote 2022-08-11 18:04:20 UTC
(In reply to Mike Kaganski from comment #11)
> Created attachment 181730 [details]

@Mike, you never fully create the formula object in that clip so sm zoom works until it is completed. 

Otherwise seems issue is when you have a formula already in an ODF document (Writer here), and then OLE open it into the sm module. Everything on the document canvas is being previewed. But layout changes made in sm to the formula with focus are not being refreshed in the preview, and will fully render only when the object is closed.  

The zoom for sm is independent of the source module for the OLE formula, and sm zoom controls disabled for the OLE edit; correctly?

> Why not synchronize the two separate zooms?

OK but, should the formula editor display the source canvas with high fidelity to its layout WYSIWYG --or is it better to preview just the OLE formula with focus?  

Ignore the document canvas, with Zoom disabled and no dynamic change to the source OLE frame until edit is completed. I think that was our legacy that now is muddled by preview of the entire document.

Question could be, what is the more desirable canvas "preview" to display in the sm document frame? 

What is the workflow? 
A.) Concentrate of formula editing, and limit view to its dynamic OLE frame. 

B.) Concentrate on layout in document, and provide document zoom while the OLE is being edited?

Is formula editing improved by WYSIWYG and allowing the sm to display more than just the OLE frame for the formula object with focus?
Comment 13 Mike Kaganski 2022-08-11 18:27:07 UTC
WYSIWYG definitely helps.

When you create an *embedded* formula, you are e.g. limited by the width of page, or a table cell, or whatever surrounds. It's absolutely unreasonable to consider editing the embedded formula totally different compared to, say, editing of fontworks, smart shapes, charts (using another module by the way), or frames. The technical difference (we have a different module making this work) is just an implementation detail, and user needs no care about that. Requiring that for some elements, user needs to abandon the convenience to feel the surroundings and "focus on formula", unlike other elements, is not reasonable. If you need to focus on formula, then use Math, not Writer with Math.
Comment 14 V Stuart Foote 2022-08-11 19:14:50 UTC
Well yes. But then we have issues like bug 99225 where the sm formula are rendered to images but then the OLE formulas go missing from the .odt

Non-WYSWYG work flows with linked (or embedded) ODF Formula is more conservative and less risky to calling the Formula editor inside a Writer session.

So questions of workflow for assembling a manuscript with formulas, and the behavior of the sm Formula editor in Writer are valid.

I'd take reliability and consistent behavior over convenience of WYSWYG handling. If the zooming, paning, scrolling of document canvas in the sm Formula editor can't be synchronized--should revert to only exposing the OLE frame for the current formula in the sm preview.
Comment 15 Mike Kaganski 2022-08-11 19:49:18 UTC
(In reply to V Stuart Foote from comment #14)

I simply do not understand what bug 99225 has to do with this. Even if it is connected to zooming the formula (which I didn't understand from *really cursory* reading that longish issue), that is definitely a **bug**, which can't be a reason to reject this - at most, that could be **blocker** for this one (again, if these are connected somehow). But:

1. This one is perfectly valid user expectation and workflow.
2. This is definitely doable.
3. That one is a bug that must be fixed, bit swept under the carpet.
Comment 16 Klaus 2022-08-11 20:13:41 UTC
(In reply to V Stuart Foote from comment #14)

> I'd take reliability and consistent behavior over convenience of WYSWYG
> handling. If the zooming, paning, scrolling of document canvas in the sm
> Formula editor can't be synchronized--should revert to only exposing the OLE
> frame for the current formula in the sm preview.

From the previous post I understand that you'd consider removing the workflow, where the formula being edited is being previewed in the document context, is that correct?

Please strongly reconsider this stance. When drafting documents, I usually need to refer to other equations while editing the next equation. I also need to account for page width limitations and such constraints.

The current zooming issue would be preferable to me over a fix that removes live editing in the document context.
Comment 17 V Stuart Foote 2022-08-11 20:57:14 UTC
This is getting off-topic, but relationship to bug 99225 is to 'avoid data-loss'  

Such that if synchronizing the zoom behavior between the documents source module and the preview pane in sm Formula editor worsens user experience bcz of lost StarMath or MathML formulas then any benefit of WYSIWYG formula preview in the sm Formula module would vanish.

Don't know that it would worsen things, but fully presenting WYSIWYG in sm preview seems risky given the general lack of integration of the entire sm module--it does its own thing. And the opened ODF document archives are very dependent on how the formula get added into the document, and how the formulas are opened for editing. And how the document is written out to archive on save/close or export.

We don't know why the OLE formulas drop out of the archives, Regina suggests it is a memory configuration issue (and we know we've had images doing similar things TCO by Tomaž image life cycle work on tender 201705-01).  Don't know that similar life-cycle handling for OLE formulas can be addressed but believe their loss are still an issue.
Comment 18 V Stuart Foote 2022-08-11 23:10:19 UTC
OK, so my recollection regards preview was flat out wrong.

Checking every major back to 3.3, in the sm Formula module we do present the preview of the full doccument.

When opening an OLE linked formula, it will render the document canvas current view as its preview expanse.

Zoom for a linked formula has changed a bit over the build releases, at 3.3 the canvas zoom worked on the full canvas when "previewed" in the Formula editor--but the sm editor's zoom controls (TB, Menu) were already disabled at that point.

And at 4.2 the sm Formula editor got its zoom bar added (bug 63351) and https://gerrit.libreoffice.org/c/core/+/4053/

But guess the syncronization between the source LO module and sm Formula zoom controls got missed then.

It has only ever been that the sm Formula editor handles individual ODF Formula in their own canvas with full zoom controls from menu, toolbar and slider.