[Webkit-unassigned] [Bug 142673] [GTK] Automatically adjust font size when gtk-xft-dpi changes

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Nov 5 07:53:30 PST 2017


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

--- Comment #41 from Michael Catanzaro <mcatanzaro at igalia.com> ---
> Maybe Michael can have the final say on this?

Wrong way around: I'll defer to Carlos. But let's discuss a bit more.

I was almost going to ask you to implement Carlos's suggestion of having global functions to convert between pixels and points and vice-versa (also for GTK only). We don't currently have any global functions in our API, but we have another use-case for one in bug #174816, so there's no harm in adding them. This will make it easier to set the font size using g_object_set() while keeping the original points properties. But I eventually decided that's a bad idea, because of your argument regarding the disparity between having the existing minimum-font-size in points and the other two font sizes in pixels. That's confusing, and really annoying me. (Does minimum-font-size even work properly? How could it, if WebKit was not able to convert between points and pixels?)

I think our solution should fix that. And the only way to do that is to deprecate the existing properties. So my preference is still to stick with the original plan, deprecate all the existing pixels stuff and add the points versions. I don't agree with Carlos that it's bad to have multiple properties that change at the same time; it makes sense in certain situations, such as GTlsCertificate where we provide separate DER and PEM properties to get the certificate in different formats. I don't think that's confusing. And in this case, we'll actually only have one non-deprecated way to get the settings, which is relevant because the deprecated ones will eventually go away. So I think that's fine. In the future, when we add the GTK+ 4 API, we can remove the original pixels versions (from the new API) and then drop the -pts from the names (in the new API), addressing the naming disparity. So this is right for the long term. It'll require some #if conditions, but I think it's the best approach.

Now, for WPE, I agree with Carlos that it probably makes the most sense to stick with pixels instead of points, at least for now, because (to my knowledge) WPE does not expose any monitor DPI information, so the points settings cannot ever really work properly. I propose that we just accept that WPE and GTK need different API here. So let's guard the new API with #if PLATFORM(GTK), guard the G_PARAM_DEPRECATED use as well, remove the new points API from the WPE header file, and not deprecate the pixels API for WPE. It'll require even more conditions, which will be a bit messy, but it's the right thing to do IMO.

Carlos, does that sound OK?

-- 
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/20171105/92268d1b/attachment.html>


More information about the webkit-unassigned mailing list