<div dir="ltr"><div>Hi Kendy,<br><br>Good to hear from you. I've got a number of things in progress on my computer beyond the underlines (<a href="https://wiki.documentfoundation.org/Development/HiDpi">https://wiki.documentfoundation.org/Development/HiDpi</a>) but I wait to get an API first as I'm just writing "if (1) //hidpi".<br>
<br>I personally don't think a floating point value is a good idea. At the lowest level, pixel line widths go to 2 or 3 and in the square case go to 4 or 9. I believe anything who wants more resolution should probably be working based on the system font size. The changes I'm making don't seem to need more than 3 and even 2 is plenty for all laptops today and into the distant future. Floating point arithmetic used to be a lot slower than integer as well but I don't know if that is still true ;-)<br>
<br>I hope it is okay if I can write code that handles the 2x case but has no guarantees about any other value. I can't test what I can't see and there is a fair amount of work to get LibreOffice looking good and supporting variable-sized bitmaps at all. So if it were up to me, I'd just make it a boolean for a while, and focus / force that part to look great everywhere. Then when you were ready to further generalize it, the compiler would make you to validate all the areas. I even have been taking advantage of the simplicity. I found some arrow drawing logic that wanted an odd-sized height for best results. And so I just doubled it and subtracted one ;-) <br>
<br>My biggest concern wrt the API is that it has the right value out of the box. For example, what do normal Macs return for the system font size versus Retinas? What about on Windows? There is plenty of intelligence that can go into a bit.<br>
<br>Putting the change in ImplDrawWaveLine is possible. My change is safer in that it mostly only touches the spelling / grammar which is the most noticeable issue. With ImplDrawWaveLine you have to worry about more callers, printers, etc. and possibilities for dirt on screen. I wouldn't necessarily recommend shifting down 2 pixels for the low-level drawing code, so maybe you'd still have to have changes in both places. ImplDrawWaveLine is a routine takes a pixel line width as input, so perhaps the policy decision should be above it. It seems sort of like putting the bitmap doubling logic into the BitBlt routine versus in the toolbar which loads the bitmaps. I could look at the wavy underline character property logic, but I think it is low priority and still might not change the ImplDrawWaveLine. I haven't looked into it. I'm happy to fix any bugs in my simple code, but get concerned about suggestions that complicate it ;-)<br>
<br>Working on this early next week would be great. I've got about 600 more lines in 14 files to review that make a difference. There is a fair amount of low-hanging fruit. I am possibly stuck on two issues, but I plug away on it as I have free time. The hardest part is finding the actual line of code that have the bug. With my work, they are being marked which makes future work easier. I did see code that is possibly problematic in places like DecoView but I'm just focusing on the visible ones. Toolbar bitmaps are the most important. The Sidebar is the most broken. Do you think they will fix it?<br>
<br></div>Anyway, I look forward to working through the issues soon because I have some time now and hopefully getting this into 4.2.<br><div><br>-Keith <br><br></div></div>