You are not logged in.
Pages: 1
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.
Offline
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.
Offline
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.
Offline
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.
Offline
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.
Offline
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)
Offline
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.
Offline
Pages: 1
[ Generated in 0.009 seconds, 7 queries executed - Memory usage: 585.8 KiB (Peak: 602.28 KiB) ]