fonts in xfce4-terminal

Skaperen · 2019-12-21 02:46:05

are the fonts being used by xfce4-terminal the scalable ones that can be resized? or are they a set of each fixed size? i'm wondering because i have an idea for a new approach to sizing the terminal that can sidestep the problems i keep running into with xfce4-terminal trying to fit a terminal geometry with a font size.

Aravisian · 2019-12-24 06:30:47

Skaperen wrote:

are the fonts being used by xfce4-terminal the scalable ones that can be resized? or are they a set of each fixed size? i'm wondering because i have an idea for a new approach to sizing the terminal that can sidestep the problems i keep running into with xfce4-terminal trying to fit a terminal geometry with a font size.

I do not know the answer to this, but playing with the preferences in xfce4-terminal, I am able to change the text size. This implies it is scalable.

Skaperen · 2019-12-24 21:23:31

there being so many sizes which look alike, that sure does suggest it is one scalable font, unlike the variety of look-different bit-map fonts i once used in the low resolution screen days.

i still don't know in X is doing the actual scaling or if the terminal process is (if so, probably in the font library). my idea is to specify the window geometry in pixels, and either the text geometry or the pixel size in 2D, then calculate the other. that would allow squeezing or stretching the fonts. i have seen the API of a font library and it could do this. but that was many years ago.

i do have a case where specifying 2 different text geometries with font size 22 yields the same wrong text geometry in the resulting window and a different pixel geometry. something is way off as only a couple font sizes get the same text geometry as specified. i tried a lot of font sizes and geometries to get almost-full-screen windows in xfce4-terminal and got these results:

these are figured in a 1920x1080 display
with Greybird style, elementary Xfce
darker icons, DejaVu Sans Book 16 font,
and Monospace 10 monospace font for
the Xfce parts.

with font  1 using 1915x344 gets 1914x344
with font  2 using  958x257 gets  957x256 <-- apparently the width of font 2 and font 3 are the same (but is entirely unreadable)
with font  3 using  959x206 gets  957x206 <-- result size is almost specified size
with font  4 using  639x147 gets  638x146
with font  5 using  478x115 gets  477x114
with font  6 using  383x103 gets  382x102
with font  7 using  319x86  gets  319x85 <-- result size is almost specified size
with font  8 using  319x79  gets  319x78
with font  9 using  273x69  gets  272x68
with font 10 using  240x60  gets  239x59
with font 11 using  212x58  gets  211x56
with font 12 using  192x54  gets  191x53
with font 13 using  192x47  gets  191x46
with font 14 using  174x44  gets  174x44 <-- result size is EXACTLY specified size
with font 15 using  159x43  gets  158x42
with font 16 using  147x40  gets  146x39
with font 17 using  137x37  gets  136x36
with font 18 using  137x36  gets  136x35
with font 19 using  127x34  gets  126x33
with font 20 using  120x32  gets  119x32 <-- result size is almost specified size
with font 21 using  113x32  gets  112x31
with font 22 using  106x29  gets  105x28
with font 23 using  106x28  gets  105x27
with font 24 using  101x30  gets  100x27
with font 25 using   95x29  gets   94x26
with font 26 using   91x25  gets   90x23
with font 27 using   87x24  gets   86x23
with font 28 using   86x23  gets   86x22 <-- result size is almost specified size
with font 29 using   83x22  gets   82x22
with font 30 using   80x22  gets   79x20
with font 31 using   76x21  gets   75x20

i'm using font sizes 14 and 17.

Aravisian · 2019-12-25 06:11:56

It seems you have found your answer.
If it was like in the old days, you would not see the variance that you see above. You would see a linear result. The developers would have simply sized each font to match the resolution That kind of mathematical divergence above is a result of Scaling. If you felt like doing the math, you could find the right ratio for it.
It is a big part of why GTK3 can never equal GTK2 in looks and versatility. With css or GTK3, all parts are Relative. With GTK2, you have a starting point from which you build outward. This results in GTK3 having different dimensions and measurements as you scale, as well. A window starts out a certain way, then as you change the properties gets very slightly out of alignment, gets very slightly out of alignment, gets very slightly out of alignment, suddenly everything lines up, again. Then gets out of whack, again.

Skaperen · 2019-12-25 19:32:37

what i want is total scalability of the terminal rendering. xfce4-terminal isn't there, yet. but the tools to do it do exist. i just want to confirm if this is done in xfce4-terminal or in X (an xfce4-terminal has to give it the exact specs). since X seems to have no way to tell me the window size in pixels, i worry that the pixel work is deep in X somewhere (or even in the hardware) and terminal programs have a limited scope of specs they can give to shape the display. it would require at least 3 numbers in each of horizontal and vertical (which no terminal program i have seen will even try to set.

Aravisian · 2019-12-26 02:34:57

Skaperen wrote:

what i want is total scalability of the terminal rendering. xfce4-terminal isn't there, yet. but the tools to do it do exist. i just want to confirm if this is done in xfce4-terminal or in X (an xfce4-terminal has to give it the exact specs). since X seems to have no way to tell me the window size in pixels, i worry that the pixel work is deep in X somewhere (or even in the hardware) and terminal programs have a limited scope of specs they can give to shape the display. it would require at least 3 numbers in each of horizontal and vertical (which no terminal program i have seen will even try to set.

You have gone over my head with this one. I understand what you would like to do, but I lack the knowledge to help you do it.
I recall you have been working on making the Terminal your own beast for quite some time. The best I can offer is the faith that you will work your way to it, eventually. Or, the faith that you will give it up, eventually.
My own experience with X is that it is not as clear cut as you may hope. Rather than set a starting point that it builds in a linear direction outward from, like a cathode ray tube might in printing a screen image, it does it from a relative point and the starting position is relative to the screen resolution. I could be wrong.
But if I am not, you can see why this is necessary. On old T.V.'s, resolution was not a thing and screens were standard sizes. And you could see the effect as changes were made over the years as an image started at the top left corner and anything of the image that did not fit the screen size was simply cut off.
This was true for Computer monitors, as well. However, the software printed on the screen based on a Standard screen size.
Times changed and consumers wanted different screen sizes and different resolution.
In Computing, it is unacceptable to have a printed screen image cut off at the borders. So the solution was instead to build from the center of the screen and set the outer edges as borders. As with any equation which must be balanced, some value must change when set values are fixed. If your center is fixed and the outer border is fixed, than the fill in the middle must be variable and that variable is the thing that seems to be driving you nuts.

Last edited by Aravisian (2019-12-26 02:35:44)

Skaperen · 2019-12-27 00:43:08

that's a good description. i believe tools to fill it in do exist. i can figure the arithmetic to position all the characters, so i should be able to code it. this would be making it as a pixel array and feeding that to X. but, i don't know if terminals do that, now. X, and the underlying drivers and hardware, may ha facilities to speed up rendering of characters. maybe displaying a pixel array in X is still slow. maybe constructing the pixel array is slow. if characters don't "land" exactly on a pixel, then character movement, such as scrolling, may require re-rendering the entire screen. doing that for each line of a scroll me still be too slow. the speed i see today, of terminal programs running in X, may be from more advanced features than from faster CPUs. if that is the case, then other code is rendering the text and it needs to know the character to pixel relationship. it may be the cause of limitations and issues i have seen. it is sad enough that requests for specific sizes get something different. if i was just limited to a few sizes, i could work with that. given the inconsistent nature of what i do get, it suggests to me of some critical code designed by someone with limits on their understanding of finite arithmetic or how to apply it to their code.

Xfce Forum

Sub domains

#1 2019-12-21 02:46:05

fonts in xfce4-terminal

#2 2019-12-24 06:30:47

Re: fonts in xfce4-terminal

#3 2019-12-24 21:23:31

Re: fonts in xfce4-terminal

#4 2019-12-25 06:11:56

Re: fonts in xfce4-terminal

#5 2019-12-25 19:32:37

Re: fonts in xfce4-terminal

#6 2019-12-26 02:34:57

Re: fonts in xfce4-terminal

#7 2019-12-27 00:43:08

Re: fonts in xfce4-terminal

Board footer