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

[bugzilla-daemon at webkit.org]

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

--- Comment #42 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #41)
> > 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?)

It turns out that it's a bug in the documentation, minimum font size is no different to other font size settings and it's in pixels, which is what WebCore expects. There's also minimum logical size that we used to expose in WebKit1, but never exposed in WebKit2, I guess because I didn't find any application using it.

> I think our solution should fix that. And the only way to do that is to
> deprecate the existing properties.

The actual fix is removing the points thing from the documentation.

> 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.

Thing is that I was not convinced of deprecated the pixel ones yet, so I was considering having both at the same time.

> 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.

I think using pixels will work in any case, so having convenient methods to get/set in points for other cases like desktop environment would solve the issue without deprecating and making more difficult for apps to port to the next API version.

> 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?

I don't think it's a good idea to introduce more differences in the API between GTK and WPE, and I don't think it's needed in this case.

-- 
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/20171106/8338e3ce/attachment.html>