[Webkit-unassigned] [Bug 247980] WebKitGTK seems confused about size of 1px on 283 dpi display

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=247980

--- Comment #24 from Glen Whitney <gwhitneycom5 at pobox.com> ---
(1) My apologies for any trouble my efforts so far have caused -- I am solely attempting to improve WebKitGTK, which currently produces unusable web page renderings on my Xwindows setup as described above (and which setup works reasonably with other browsers).

(2) As to whether the css-ruler linked is a reasonable benchmark, the [CSS standard](https://www.w3.org/TR/css-values-3/#lengths) for absolute unit sizes says that the canonical unit is the px, and the px is defined as *either* 1/96 of an inch (crazy to have a global standard based on idiosyncratic US units) *or* the distance that subtends an angle of 0.0213 degrees at the expected viewing distance of the device. For the nominal "arm's length" viewing distance (28 inches), the two definitions coincide. It therefore seemed quite reasonable to scale the WebKitGTK rendering so that 1cm would indeed be 1 physical cm, as that is standard-compliant under the first definition and under both definitions for a typical desktop. Hence that is what the now-reverted PR did.

Aside: I do acknowledge that scaling was not the standard's "recommended" behavior on smartphones, which have a significantly lower expected viewing distance, [typically 12-14 inches](https://www.w3.org/TR/css-values-3/#lengths), so a CSS 1cm box "should" be rendered at approximately 4-5 mm on mobile. I wasn't sure how to differentiate the screen type, nor of the extent to which WebKitGTK expected to produce ideal results on a mobile device; note tying absolute dimensions to equal physical lengths is always standard-compliant, although it is not the behavior "recommended" by the standard for mobile devices or for screens expected to be viewed at farther than arms length (such as electronic billboards). Also, since the current behavior on hi-dpi desktops is so far from standards-compliant, getting to at least some compliant state overall seemed like a win.

(3) Finally, I would of course like the opportunity to make a revised PR to resolve this issue, and clearly it would need to be one that does not cause the difficulties referred to in issue https://bugs.webkit.org/show_bug.cgi?id=274075  -- however, there is not any detail in that issue: it simply states "Broke font rendering in some cases" but does not give any information as to what cases or how to reproduce or how to know what is correct font rendering in these cases or how to test. Please could someone on this discussion provide guidance on the actual requirements/constraints on a fix to this issue, how to test it, and on how to decide the screen dimension for 1px (or equivalently for 1cm, as the two are strictly tied to each other by the CSS standard)? The current mechanism is producing unusably tiny screen dimensions on a display with 283 physical pixels per inch, and XWindows correctly reporting the resolution and the display size. Hence some fix is needed, and I am happy to submit it, but at the moment I don't have the information necessary for a potentially successful PR.

Thank you so much!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240513/7c750bbe/attachment-0001.htm>