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
Created attachment 181720 [details] Screenshot showing the mismatched zoom levels, and how they affect productivity.
(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.
(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).
(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 ;)
(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).
Created attachment 181727 [details] Odd page- and equation rendering when zooming out a lot See previous comment.
On my Windows 10 device I cannot reproduce the partial mitigation of the issue for maximized Writer windows.
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...
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.
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.
Created attachment 181730 [details] Why not synchronize the two separate zooms?
(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?
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.
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.
(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.
(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.
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.
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.