hi, I was using a small laptop, and all of a sudden realized that I had to move over to a desktop with large screen so I could overview multiple pages, seeing their content, in "Multiple-page view". Sometimes 4 pages are perfectly fine. But this time I wanted to see 8 pages at a time, of the 20-something... But I wasn't able to see the pages' content. That is, I saw the 8 pages, but the text in them was super tiny (the zoom factor was around 36%) On a 19'' "square" monitor, with large area for text editing, the 8 pane view of the document still doesn't allow for seeing the text (12pt).. only the headings... but that's okay... This time, however, I wanted to see the text... hence the idea: Let us have a magnifier tool! "holding it" (via mouse) over the text in the "small" pages, would get you an enlarged view of the area under the magnifier... The magnifier tool could be used both in print preview mode and editing mode... but if it worked only in the latter, that would already be super-great :) - - - thank you for developing Libreoffice including Writer - - -
IMHO a "magnifier" spot-zoom would be an excellent feature *in general* and has been a missing Assistive Technology tool since StarOffice OOo era. Past enhancement requests have been made to zoom into Calc charts, and Draw multi-page/slide views (see also bug 38263 bug 138510, bug 38169, bug 150383, etc.) And this request to spot zoom magnify a portion of the Writer document canvas in 'Mulitple-page' (or any of the view modes) shows the use case is really across all the LO modules where the document canvas shows details that could be zoomed into selectively. +1
But isn't this magnifier thingy a OS/DE tool? Windows has it [1], KDE knows KMag [2], Gnome talks about such a tool [3], and macOS has the Picture-in-picture fucntion [4]. I see no need to implement the wheel again. Ultimately I wonder how this plays together with bug 101646 "UI option "Scaling" was removed". [1] https://support.microsoft.com/en-us/windows/use-magnifier-to-make-things-on-the-screen-easier-to-see-414948ba-8b1c-d3bd-8615-0e5e32204198 [2] https://apps.kde.org/kmag/ [3] https://help.gnome.org/users/gnome-help/stable/a11y-mag.html.en [4] https://appleinsider.com/articles/21/06/27/how-to-magnify-your-screen-with-the-zoom-feature-in-macos
(In reply to Heiko Tietze from comment #2) > But isn't this magnifier thingy a OS/DE tool? Not really of use here. *All* that the os/DE can accomplish is to zoom into some portion of the raster display. They can't exhibit details that are not present in the diminutive size of the LO rendering to screen. The legitimate ask here is for LO to expose that detail (I'd think of it as interactively providing a VCL viewport to the document canvas, or a specific object like a chart, with higher resolution/scale). Since the os/DE *can't* support it, reasonable if LO can.
(In reply to V Stuart Foote from comment #3) > They can't exhibit details that are not present in the diminutive size > of the LO rendering to screen. Can you share an example for this? I understand it as very low-res rendering on a high-res display which fails eventually to zoom for the OS/DE while we could create some high-res version. Quite artificial example.
Ady, since you commented on another ticket to use the OS/DE magnifier: What do you think about this request?
I think this would be a very useful addition to many programs, not just LO. I am thinking of - CAD tools (complex drawings with many details), - database designer (hundreds of tables with many fields and foreign key connections) - video editor with many frames - ... Everywhere where you want to see the big picture and the individual details at the same time, without adjusting the zoom level several times per minute. @Heiko: imagine a monitor with 1920x1080 pixel and a text in Calc with 1920 characters. If you zoom out to see everything then every character is represented by 1 pixel. The OS magnifier has no info about the content, just the pixels, therefore, it magnifies N pixel to N large grey squares. An app-specific magnifier, however, can ask the app "what is at pixel (0, 3)". The app knows that the pixel is coming from a letter "B", so the magnifier can show the capital B with the appropriate font, color, etc. I would find it very useful to have a combo magnifier icon on the toolbar. Sorry if I use wrong naming, by "combo" I mean a button that has an on/off state and a dropdown as well, for finer adjustments. Similarly to the Underline button, where you can toggle if the selected text needs to be underlined or not, you also can adjust with the dropdown what style of underlining you want to toggle. In case of the magnifier, the options could be x2, x4, x8, x16, x32. For me, a question is the mechanics of the magnifier. I can imagine two possible implementations: - simple: within the circle of the magnifier, use the adjusted zoom uniformly (straight lines remain straight) - realistic: in the very center of the magnifier glass, you see the adjusted zoom and closer to the perimeter you can see a lower zoom factor (straight lines become curves) For me, the more realistic solution seems nicer, even if it is harder to develop. I would love this tool in many applications.
The topic was on the agenda of the design meeting. The idea was appreciated by the majority. Magnifying the screen with OS/DE tools is easy but has its limit with the resolution. An inbuilt magnifier tool could render the area in a higher resolution and could be useful not only for accessibility but also to avoid zooming in and out.
Generally: What would be really helpful is having some prior art here. What I found so far are: – navigation views, where a document is shown is a zoomed-out view. Clicks and drags in this view move the main view. This is different from the OSes zoom-in for accessability, since the added view is actually *zoomed out*. All editing still happens in the main view. Examples: Affinity Photo (but probably also other image editors) - Now, that is far fetched, but the game Rollercoaster Tycoon has a main view that can be zoomed and an unlimited amount of in-game windows that can be opened and interacted with, just as with the main view. So we already have different cases: - Additional view for navigation (zoomed out), main view for interaction (zoomed in) - Additional view for interaction (zoomed in), main view for navigation (zoomed out) Technically, one could seamlessly switch between both modes (its just that view/controller need to map the screen/mouse coordinates) BUT it probably leads to confusion and/or additional controls to influence both views independently (Maybe leading to a 80/90s ish excess of floating windows)