This a particularly necessary when the lines are very short, e.g., for 2 spaces, for a space and a comma. Current thickness is easy to miss. A thicker line would also help when checking with the dialog box. Sometimes we need more context than what is shown in the d.box to make a decision. When the line is short, it's frustratingly difficult to find the flagged words in the document. So, a thicker line would be very helpful.
reverting status to UNCONFIRMED since there was no independent confirmation by other users. I'm not convinced about your request, so please post a screenshot of one of the cases you describe to persuade me that the spellchecker wavy line is not easy to see.
Created attachment 108080 [details] Hunt Squiggly
(In reply to tommy27 from comment #1) > I'm not convinced about your request, so please post a screenshot of one of > the cases you describe to persuade me that the spellchecker wavy line is not > easy to see. Please see attached. It's no doubt prompted by my weakening eyesight. Thus, it's a request for an option to make it thicker.
Ok, from an ACCESSIBILITY point of view your request is legitimate. having the thickness configurable by the user would not harm anyone. people who like the current thickness would keep the current value, while people with eyesight problems could benefit from a thicker value status NEW. edited summary notes
Yes. Thank you very much. :) _/\_
I agree with the request to add a way to thicken the wavvy line for spell checking in LibreOffice. I have misspelled "wavy" while I am entering this text and I see it as more prominent in this text editor than I would see it in LibreOffice. Keep in mind that higher resolution monitors (2560 x 1440) can resolve a very thin line and it is barely noticable at that very fine size, especially for us old guys.
It would be nice to see this happening. The problem is that the marking has no relation with the text size and/or zoom level. It's always one pixel height. The larger the resolution the more difficult it is to be seen. If this cannot be setup, then make it at least relative to say 10pt/100% zoom (minimal of 1px is ok, though subpixeling would be also an option). At least that way people may zoom in to see the markings if they need to. To bring this problem to numbers. A 15" wide screen laptop with a resolution of 1920x1080 (is fairly common and what I'm using now) has pixel size of about 180µm (20cm/1080px). That's as large as a thick human hair. You don't need to have eye problems to need this setup option; just use a high resolution screen. So this is barely an ACCESSIBILITY problem. (And don't ask for a screen shot, you'll still see that in your resolution with different PPIs) - by the way, new laptops (3200x1800@15,6"-16:9) have a pixel height of 100µm.
(In reply to estani from comment #7) > It would be nice to see this happening. The problem is that the marking has > no relation with the text size and/or zoom level. It's always one pixel > height. <snip> > You don't need to have eye problems to need this setup option; just use a > high resolution screen. > > So this is barely an ACCESSIBILITY problem. I think you've just made it clear that this merits attention. Perhaps we can consider this as more than an enhancement request.
Despite having been opened almost SIX years from now and found legitimate to fix one year after, this issue still hasn't been considered. Even if this parameter may be found too minor to deserve an UI access, could we at least have some way to address it?
Adding needsUXEval to get the design team on board. I support the request that especially for short Terms of single characters it's hard to see the red line. But I don't see an option as a good solution. The default settings should fulfill accessibility and UX guidelines without any user action.
I support the request. An option for a thicker line or highlight text in different color.
Looks to me as this feature is welcome by many. Since we have a good working line for the majority we should introduce an option. My proposal is to do it at LibreOffice > Accessibility "( ) Bold wavy underline for spelling" with the current line width if unchecked and a good alternative for accessible reason. In case the thin line is too thin on high res screens we should take this into consideration and use some scaling factor. Could imagine this as a medium difficult easyhack. Michael, do you have an idea where to tweak the line width?
probably for Writer it's painted in lcl_DrawLineForWrongListData() in sw/source/core/txtnode/fntcache.cxx which calls several different OutputDevice functions e.g. DrawWaveLine()
Created attachment 176189 [details] Screenshot Making the lines always more obtrusive might be wrong. Consider a document with different language or a lot of technical terms. To find the two characters the supposed method is running the dialog interaction. But we do have an accessibility issue. In particular on zoom, what probably people with low sight do, the lines are in fact a bit too faint. So what my patch at https://gerrit.libreoffice.org/c/core/+/125038 does is to take the zoom factor into account and increase the line size and wavyness. Drawback is that it becomes cut-off on huge zoom levels. Opinions are welcome.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4141c13da8245b5ed46be3b7034d014d75f433f9 Resolves tdf#70519 - Make wavy lines depend on zoom factor It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified fixed in: Version: 7.3.0.2 / LibreOffice Community Build ID: f1c9017ac60ecca268da7b1cf147b10e244b9b21 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 103337 has been marked as a duplicate of this bug. ***
*** Bug 155332 has been marked as a duplicate of this bug. ***