Description: "Normal preset contact" is the current contact. "Magnify the preset contact" is a 0.3 cm red frame contact. Note: 1, "normal preset contact", the contact is too small and not good. 2, "Magnify the preset contact", the contact is better, but the contact is too large, the position is too close, and will overlap. 3. According to the use environment, switching between “normal preset contact” and “magnifying preset contact” is the best way to improve working speed. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 145847 [details] In the drawing, the functions of normal preset contact and magnify preset contact are added. 1
Created attachment 145848 [details] In the drawing, the functions of normal preset contact and magnify preset contact are added. 2
Created attachment 146021 [details] Version 2
Version 2 Changed to a red dot inside the red box.
You are talking about "Points" (also enabled with F8) that toggles the segment connectors on/off. It's not the glue point feature. (Btw, not all systems show the icons in menus and perhaps you can switch the UI language to English for screenshots.) I disagree with enlarging the dots. First of all there is no use case like "For disabled users it's hard to pick up the tiny dots and we should support accessibility". Furthermore the big red squares are way too obtrusive to me and I would always switch off points when it gets to this size. Or have I missed some aspect, maybe zoom? From the summary '...functions of "normal preset contact" and "magnify preset contact" are added' the request is not clear to me,
Created attachment 146031 [details] document to estimate size of handles The attachments show, that the reporter uses a display setting of (I guess) 150%. That is the default for HiDPI monitors on Windows 10. There are other complains (not sure whether here or on Ask), that for 4k monitors the handles are too small. (You can see, that a HiDPI monitor is used, because the handles are wrongly drawn. There exists an issue about that, but I do not find it.) 和尚蟹: I want to estimate, how large your current handles are. Please open my attachment. It is a small document with a 0.5mm grid. Show it at 2000% zoom, click on the blue line and make a screen shot.
(In reply to Heiko Tietze from comment #5) > 您正在談論打開/ Not necessarily red, the color can be changed. Not necessarily 0.3 cm, the size can be changed. This design is a humanized design. You don't think so, but others think it is needed. Humanize Humanize Humanize
(In reply to 和尚蟹 from comment #7) > You don't think so, but others think it is needed. I don't want to discourage you. In case you totally disagree with my opinion we can discuss your input in the design meeting and have more people consider it. Just drop a note at the comments. But please also read comment 6. Maybe that makes your req
(In reply to Heiko Tietze from comment #8) > req.. uest more clear. (Pushed the wrong key on this stupid mac keyboard, sorry)
Created attachment 146038 [details] Regina Henschel
Created attachment 146039 [details] Regina Henschel
(In reply to Regina Henschel from comment #6) > 和尚蟹: I want to estimate, how large your current handles are. Please open my > attachment. It is a small document with a 0.5mm grid. Show it at 2000% zoom, > click on the blue line and make a screen shot. For you
Created attachment 146040 [details] Regina Henschel
Created attachment 146044 [details] handle for 96dpi I see that "Handle at 96dpi" = 1.6 * "Handle of reporter" (approximately). That corresponds to 100% compared to 174%. Or calculate directly: A handle has currently 9 pixel width, at 96dpi that results in 2.38mm. That is already very small. But with higher dpi, e.g. 167dpi of the reporters screen, it is only 1.4mm. That is really too small. Therefore I think it is a valid request to get larger handles. This proposal adds a frame around a central square. That is not really bad as long as the white part inside is semi-transparent. There are other proposals, e.g to increase the handle size if higher dpi is used, or to enlarge the handles for higher zoom.
Is this a dupe of bug 89544 or bug 117348? I don't find other HiDPI bugs but I also thought there is at least one. Can the handles be changed if a high dpi Screen is used? 'Normal' screens shouldn't show too big handles.
Can someone please change the summary so that everybody understands what this bug is about? I can't.
No UX issue but a bug. Code is under investigation by Armin.
(In reply to Thomas Lendo from comment #15) > Is this a dupe of bug 89544 or bug 117348? No, those are about the grid, but this one is about the handles, which you use to resize an object. I don't find other HiDPI bugs but > I also thought there is at least one. There is a meta bug 90796. > > Can the handles be changed if a high dpi Screen is used? 'Normal' screens > shouldn't show too big handles. That is work in progress. The current idea is to enlarge the handles according the scaling. For that purpose not the combined file markers.png is used, but a single image file for each marker. Such files are already contained in some icon-themes in the source, e.g. colibre or colibre-svg. The marker files are in core/icon-themes/<icon theme name>/svx/res. If the user has a scaling factor of e.g. 150%, LO generates a folder <installation folder>/cache/<icon theme name>/<factor>/svx/res containing the enlarged markers. You can test it, if you zip the icon theme colibre-svg from source, rename it suitable and put it into <installation folder>/share/config. Set your display to 150% and start LO. I do not set this as duplicate, because the idea not to use a solid marker but a marker with a center dot and a frame is new.
This problem can be solved by the method of "magnification level" Assumed "magnification level": Level 1 (0.3 cm). Level 2 (1 cm). Level 3 (2 cm). Level 4 (3 cm). Level 5 (4 cm).
The patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=f713caa6f116ee9d6f99e03a688216984cedce44 is in master. Now the single files for handles are integrated into the delivered icon-themes. Now larger handles are generated when used and cached for reuse. Please test a current developer build, whether the size of the handles is OK now. The fact, that the scaled handles might look blurry is a different issue. This fix does not include the crop handles.
Created attachment 146307 [details] The third edition (change to "circle center point" + "round frame" is better)
The bugtracker is not suitable to _discuss_ design. Please contact the design team. Read section "Get in contact" on https://wiki.documentfoundation.org/Design
Created attachment 147165 [details] "Contact" is still too small, please zoom in 0.5 times, zoom in 0.5 times, do not be afraid that the "contact" and "contact" will be stuck, because the enlarged display will increase the distance of t
Created attachment 147167 [details] If you use a solid "contact", don't have a "frame" that looks better.
(In reply to 和尚蟹 from comment #24) > 創建附件147167 [詳細信息] > 如果使用堅固的“聯繫人”，則沒有看起來更好的“框架”。 Don't have a "frame".
Created attachment 147171 [details] Change to no outer frame (no lines).
Created attachment 147186 [details] See if it can be changed, there is no "outer frame", "transparency" 50%.
The ".docx" is the same as the ".doc" format. The "contact" cannot be automatically scaled.
(In reply to 和尚蟹 from comment #28) Wrong, I accidentally used LibreOffice 6.1 to test, sorry...
Created attachment 147258 [details] Perfect contact (this picture, please hand over to the designer, after the transfer, please reply to the notice, thank you.)
I gave up, I added a new article in the following URL, please support, thank you. https://bugs.documentfoundation.org/show_bug.cgi?id=121915
Dear 和尚蟹, 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
Dear 00, 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
The design of handles and crop markers is determined by the icon-theme. An advanced user can tweak individual images in an icon-theme to his needs. But there is no way for the user to set the size of handles. Some users might need a larger sensitive area. Wrong crop markers in higher resolution is tracked in bug 153421. Bad rendered handles in higher resolution is tracked in bug 121130. "Contact" in this bug report means the resize handles of shapes.