[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 #39 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Gabriel Ivașcu from comment #37)
> OK, as Carlos pointed out, I'll split this into two separate bugs and
> patches:
> 
> (1) Add functionality to handle font sizes in points.
> (2) Handle DPI changes and scale the text accordingly.

Perfect, thanks!

> I suggest keeping this bug for (2), as that was its original purpose, but
> for that I need to ask Michael to change the bug's name back to the
> original, since I don't have enough permissions.
> 
> And I'll open a separate bug for (1) with a smaller patch for it. But for
> this I'm not sure if we should fall back to the alternative design, where we
> keep the old font size properties in pixels, and only add setter/getter
> methods for the font size in points. I believe this isn't really the best
> approach, for reasons of usability and consistency.
> 
> I'll try to highlight below why I favor adding points properties and
> deprecating the pixels properties (which should be eventually removed for
> good):
> 
> A. It's a plus to consistency. Currently, "minimum-font-size" property is in
> points, whereas "default-font-size" and "default-monospace-font-size" are in
> pixels, which is already not too consistent.

Yes, I didn't even know minimum-font-size was in points.

> Splitting the default font size
> properties in both pixels and points, will break the consistency even more,
> whereas replacing the pixels properties with points properties will bring
> unity.

That would still be inconsistent because new properties in points will have the -pts suffix, but minimum-font-size will be in point without the -pts suffix. What I don't like about adding new properties is that changing one property will affect two properties, because of both are changing the same internal value. They are not two properties but two ways of expressing the same property. So, adding methods to set the same property in other units makes it clear that we are changing the same thing.

> B. I think users should have to deal with raw pixels. And it's easier for
> them to understand that they are supposed to use only the points
> properties/methods from now on if they see that the pixels
> properties/methods are deprecated and will be removed in a future version.

I'm not sure that's always the case. In a GNOME desktop environment with gnome-settings-daemon, and GTK+ providing accurate information about the DPI, that's for sure the case. But in a embedded device, with not desktop and not using any toolkit at all (WPE), that targets a specific screen where you know the DPI, you might want to move the conversions to the app side instead of using the default one provided by WebCore.

> This is in contrast with keeping the pixels properties/methods and only
> adding points methods, which can be misleading and confusing: changing the
> pixels value will change the points value too and vice versa. (Of course,
> this would happen too if they would use both the new properties and the
> deprecated ones, but that would be their fault.)

I'm not sure I get what you mean here, the fact that changing one property makes another one change too is what I find confusing here.

> C. It's easier for apps to handle font sizes in points rather than pixels,
> i.e. they can pass to WebKitSettings the font size value obtained directly
> from the user preferences.

I agree, and again that's the case of desktop applications in a desktop environment with system preferences.

> Furthermore, what apps currently do, is to set
> multiple font properties at once with g_object_set(). See
> https://git.gnome.org/browse/epiphany/tree/embed/ephy-embed-prefs.c?h=gnome-
> 3-26#n354 and
> https://git.gnome.org/browse/devhelp/tree/src/dh-util.c?h=gnome-3-24#n168.
> Switching from pixels properties to points properties will only require
> changing the property names, whereas keeping the pixels properties and only
> adding points methods, will require calling the setter for points in
> addition to g_object_set().

Yes, I agree it's more convenient to use g_object_set() in that case, but I don't think it's enough reason. We could add global functions to convert between pixels/points instead of making them part of WebKitSettings, that way you could keep using g_object_set().

> If I'm missing something and you strongly believe that the font size
> properties in pixels should not be deprecated and/or removed, please let me
> know, so I would know what patch to upload to (1).

I still think it's better to not duplicate the properties for the reasons I've just exposed, but that doesn't mean the decision is made, so don't change the patch yet.

-- 
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/31248972/attachment.html>