[DEBATE] The DPI Paradox: Scalable Pixels vs. Relative Units

daffyduck · Yesterday 01:52:50

The Core of the Debate

The contention centers on the advice "Stick to 'em' or 'rem' which is more adaptable to scaling", when applied to a tool specifically designed to set the system DPI.

The Context

This specific advice was quoted from a recent technical exchange on this forum. The post with the mentioned quote can be found here:
https://forum.xfce.org/viewtopic.php?pid=83301#p83301

Proposer: for Scalable Pixels

The advice to use 'rem' or 'em' is fundamentally flawed for a tool that sets the system DPI. The dialog window must serve as a reliable visual anchor to the user. Its size must, by default, depend solely on the DPI setting intended to scale the entire interface, not on the 'Default Font' ('gtk-font-name'), which only affects text size. Using 'rem' introduces the 'Default Font' (in case of GTK 3 CSS) as a secondary variable, meaning the UI no longer scales exclusively with the DPI being changed. Using 'em' is ill-defined for a design specification, as it is a relative measure that has no meaning without a corresponding 'font size value' specified in points. Thus, both 'em' and 'rem' are flawed units for this dialog. Scalable pixels are an appropriate and practical unit for this purpose.
---- 796 characters

Opponent: for Relative Units

... (to be submitted) .....
---- (max. 800 ASCII characters)

The Invitation

I will defend the position of the Proposer (for Scalable Pixels).

I invite the member @CwF (https://forum.xfce.org/profile.php?id=23921), or any Xfce core developer, to act as the Opponent (for Relative Units). If a group of developers wishes to participate, they are welcome to do so, provided they coordinate their responses to speak as a single voice for the purpose of this debate.

Terms of the Debate

If no qualified opponent accepts this invitation, the Proposer's position will be considered the prevailing argument.

As the moderators of this forum are members of the Xfce team, I request that this thread not be closed for frivolous reasons. Should the thread be closed without substantive justification, the Proposer's position will be considered the prevailing argument.

Upon accepting the invitation, the Opponent has 24 hours to write "Opponent: for Relative Units" paragraph for the debate description (above), using a maximum of 800 printable ASCII characters. This response must end with "=== This ends my reply. ===" on a new line. Once complete, the debate description will be updated and any extraneous posts in the thread should be deleted.

This invitation and the rules will then be moved to a separate thread where participants or other users may post procedural complaints. The debate description will be updated to link to that thread.

The debate begins with the Proposer's turn.

Each side is allotted 4 turns, for a total of 8 replies.

If the debate is interrupted by a malicious user, a new thread will be created and the contents of the debate will be copied into it.

These rules may be further negotiated if necessary and changed only if both parties agree to the amendments.

Rules of Engagement

Turn-Based Format:
The debate will proceed in alternating turns. One side responds, then the other.

Closing Marker:
A turn is not considered complete until the author explicitly writes "=== This ends my reply. ===" on a new line. This marker does not count toward the character limit.

Refinement:
Participants may edit their posts to refine their arguments until the closing marker is added. However, each reply must be finalized within a total of 48 hours.

Length Limit:
Each turn is limited to 1,500 visible characters, including quoted text. Quotations are permitted but not required.

Style:
No rich-text formatting is allowed: no bold, italics, underlines, or horizontal lines. For lists, use new lines starting with a bullet or minus sign. [ code ] formatting is permitted for code. Indentation using spaces or tabs is allowed.

Paragraphs should be separated by newlines; excessive whitespace is prohibited.

Each reply may include up to three headings using the [ h ] tag. These headings must be short strings of text separated from the body by empty lines. Any other form of headings or sub-headings is prohibited.

Procedural Complaints:
If a reply exceeds the length limit or otherwise violates these rules, a party may post a complaint. These complaints are for corrective purposes and do not count toward the character limit of the complaining party's turn.

I look forward to this debate.

CwF · Yesterday 02:40:25

Obviously I don't get the debate!

Early in setting up Xfce, navigate to Settings>Appearance and select the Fonts tab;
check the little box and set the DPI to a reasonable setting for you setup.
I run a few variations, some 120, some 144, and a 192.
You can set the font there also if you'd like. I like 13.
Under Settings>Window Manager, under the Style, choose default, or one of the -hdpi or -xhdpi to adjust the window elements.
Done.
For theming I assemble my own, the are two choices: the only one, and the dark only one. In those ever so slowly slowly evolving themes, I never use px. Everything scales according to the render size of a 13 point 'M', or 10, or 15...
For tcl/tk gui's I specify, or tailor to target DPI. Same for Qt.
End.

daffyduck · Yesterday 02:56:05

To clarify for CwF and the other users: this debate centers specifically on a technical claim made by CwF in a previous exchange: "Stick to 'em' or 'rem' which is more adaptable to scaling", here: https://forum.xfce.org/viewtopic.php?pid=83301#p83301

The core of the contention is whether relative units ("em" / "rem") are logically sound when applied to a tool specifically designed to set the system DPI. Your response describes a general setup process, but it does not address the technical flaw of using relative units in a DPI-setting tool.

To ensure this remains a productive technical exchange and does not turn into a mockery, I request that we adhere to the proposed format. If you wish to defend your position, the first step is to formally accept the invitation and provide the "Opponent: for Relative Units" summary (max 800 characters) as outlined in the rules.

If something is not clear, please ask.

JmaCWQ · Yesterday 03:02:01

I do pretty much what @CwF mentions, and usually only have to do that about once every 5 years with a new Long Term Support release of the distro I'm using, and that's it, then I just use it.

@daffyduck seems to like proposing, opposing, debating, assuming, dictating rules, wanting to change defaults etc. etc., but so far, providing zero in the way of anything for testing, comparing, using or whatever.
C'mon daffy, stop waffling and get on with it cool

daffyduck · Yesterday 03:06:21

CwF wrote:

Obviously I don't get the debate!

Perhaps you should read "Proposer: for Scalable Pixels" section in the debate proposal, near the top, and try to understand my argument outlined there.

Added later 11 min 40 s:

JmaCWQ wrote:

I do pretty much what @CwF mentions, and usually only have to do that about once every 5 years with a new Long Term Support release of the distro I'm using, and that's it, then I just use it.
@daffyduck seems to like proposing, opposing, debating, assuming, dictating rules, wanting to change defaults etc. etc., but so far, providing zero in the way of anything for testing, comparing, using or whatever.
C'mon daffy, stop waffling and get on with it

To keep the technical record of this debate clean and readable, I am requesting that all non-participant discussions (like your post) be moved to a separate thread. This allows the Proposer and Opponent to communicate without the noise of unrelated interjections.

If the interjections continue, I will be forced to move the debate to a new thread. I would prefer not to do this, as it creates an unnecessary burden and additional work to preserve the record, but I will not allow the debate to be derailed.

CwF · Yesterday 17:17:10

Well, I think think this is a conflation between what was typed and what was thought to be typed.

Maybe my thought on ‘px’ was incompletely expressed.

Sometimes a manual declaration of pixels is an only choice, sometimes it's lazy. It all depends on the language and environment where it's used. It is always debt, someday on some system it may no longer be a good choice.

Simply put, there isn't always a geometry engine to work with. So if I want a dialog half the screen width, and am currently on a 1080, I may have to declare 960 instead of 0.50. When the screen is 3840 wide, my dialog is only 0.25. Oh well....what can we do.

Often there is a geometry engine built in somewhere and we can eradicate absolutes. When this is the case always take advantage of it even when absolutes are accepted. Hence my comment, in css for themes, px is the choice to be avoided for simpler long term maintenance.

The global scaling now fancied leaves much to be desired, I leave it at 1 and adjust DPI instead.

That's all.

daffyduck · Yesterday 22:47:23

CwF wrote:

Well, I think think this is a conflation between what was typed and what was thought to be typed.
Maybe my thought on ‘px’ was incompletely expressed.
Sometimes a manual declaration of pixels is an only choice, sometimes it's lazy. It all depends on the language and environment where it's used. It is always debt, someday on some system it may no longer be a good choice.
Simply put, there isn't always a geometry engine to work with. So if I want a dialog half the screen width, and am currently on a 1080, I may have to declare 960 instead of 0.50. When the screen is 3840 wide, my dialog is only 0.25. Oh well....what can we do.
Often there is a geometry engine built in somewhere and we can eradicate absolutes. When this is the case always take advantage of it even when absolutes are accepted. Hence my comment, in css for themes, px is the choice to be avoided for simpler long term maintenance.
The global scaling now fancied leaves much to be desired, I leave it at 1 and adjust DPI instead.
That's all.

CwF,

Looking at your latest post, I can see what is happening.
Let me explain a few things.

There are three different scaling factors in GTK. It is a complete mess, a terrible design resulting from catastrophic historical mistakes.

The "global scaling" you refer to is a terrible hack that effectively halves the resolution of the display, or worse. You are correct to leave it at 1, as it is a measure of last resort for when all other scaling factors fail.

Regarding "px," you do not understand how this actually works.

The unit "px" you are referring to is likely a "GTK 3 CSS pixel", which equals 1 hardware pixel when "global scaling" equals 1.

However, I did not use "pixel" or "px" in the sense you are thinking. I used a "scalable pixel". A scalable pixel is actually similar to GTK's "pt" unit, because this equation is true:
1 pixel @ 72 DPI = 1 pt (1 scalable pixel at 72 DPI equals 1 point).

GTK 3's "em" and "rem" are terrible units to use for almost anything. They are defined using a wrong combination of the three available scaling factors and only work well in simply structured stylesheets.

The recommendations you see on the web to use "em" and "rem" in GTK 3 stem from a misunderstanding of web tutorials; people blindly believe what a Google search tells them, not realizing that such advice applies to web design, not GTK 3 CSS.

I would advise that no one should ever use "em" or "rem" in GTK 3 CSS because those units are easily misunderstood—and using "rem" is significantly worse than using "em".

If you want to specify sizes in GTK 3 CSS, you should use "pt", as it is the only unit defined in a way that scales correctly. I advise using "pt" in GTK 3 as the preferred unit for "absolute" sizes, and percentages as the proper unit for relative sizes (i.e., defining a size relative to another size specified in "pt").

Now, regarding my proposal for the Welcome/DPI dialogue window.

The proposal is intended to be implementation-agnostic. It can be implemented in C, C++, Python, or any other language. It does not need to be implemented using GTK at all, although it can be. Using the unit "em" would signal a GTK-specific implementation, which was not my intention.

Since "em" is a relative unit, it defines nothing on its own. You must accompany "em" with another measurement for it to have any meaning.

The "rem" unit is defined relative to the "Default Font" size and DPI, but that is the wrong scaling factor for this tool. The dialogue needs to scale with the DPI, not with a combination of both the DPI and the "Default Font" size.

I have already explained other reasons why "scalable pixels" are the best unit in this post:
https://forum.xfce.org/viewtopic.php?pid=83306#p83306
That post also partially explains why I specified "x-height" instead of the usual "M-width" that you suggested.
I specified sizes in "scalable pixels" because it is the simplest and most practical unit for the job.

What you did in this post:
https://forum.xfce.org/viewtopic.php?pid=83301#p83301
...was blindly copy-paste generic advice from Google without thinking about whether it was applicable to my proposal.

Because the reality is obvious: I am a programmer, and you are not.

I know how to write specifications; you do not.

I spent three days writing that proposal to ensure it is correct, easy to implement, and easy to verify. You responded with a post written in ten minutes that screams "misunderstood" from every word.
Just writing this reply alone takes four times longer than you spent writing that post.

If you wonder why I became angry, that was the reason.

And then, you doubled down in your next post.

The problem with non-programmers, and often programming beginners, is that you simply lack the skills to recognize whether you are right or wrong. You are confident that you are right, even when you are terribly wrong.

Regardless, you still have not accepted my invitation to debate.

However, I would appreciate it if you admitted that I was correct to specify the sizes in "scalable pixels". You may then ask if you wish to know more of the reasons why; that is a good way to learn.

If I have misjudged your previous post and you still believe you are right, then please accept my invitation for a formal debate between the two of us.

CwF · Today 01:45:17

I'm not really interested in a debate. Yes there are many ways things are done. I think I have a handle on it. There is nothing to discuss until you have an installable example to test.

You're welcome to continue on the forums with anyone else interested in your project.
Be nice, the style exhibited here isn't so inviting.

daffyduck · Today 02:31:01

CwF wrote:

I'm not really interested in a debate. Yes there are many ways things are done. I think I have a handle on it. There is nothing to discuss until you have an installable example to test.

You mean: it's not enough that I made the proposal, explained a lots of details, and answered a lot of confidently wrong questions.
Instead "there is nothing to discuss" until I implement it?

You're welcome to continue on the forums with anyone else interested in your project.
Be nice, the style exhibited here isn't so inviting.

Ah, it's my style, it is causing problems. Who could possibly tolerate my "antagonistic", "assumptive", "young blood", "unbecoming", "ego searching for bliss" style?

But, posting complaints like this one is perfectly fine, in fact, that how it should be done:
https://forum.xfce.org/viewtopic.php?pid=83301#p83301
As long as it looks polite, it doesn't matter what the content is at all.

Xfce Forum

Sub domains

#1 Yesterday 01:52:50