Re: [dev] [st] font fallback
On Sun, Sep 03, 2017 at 10:06:35AM -0700, Eric Pruitt wrote: > On Sun, Sep 03, 2017 at 06:31:44PM +0200, Hadrien Lacour wrote: > > I see, thanks. Don't know why I thought it was like this. Well, I'll try it > > but fontconfig is indeed a big pain in the ass (editing XML is never fun). > > If you don't mind running an older revision of st (or porting my changes > to a newer release), you can use my patch: > https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff > > Eric > Thanks, if it doesn't patch cleanly, I'll probably try to port it (the advantages of minimalist software).
Re: [dev] [st] font fallback
On Sun, Sep 03, 2017 at 06:31:44PM +0200, Hadrien Lacour wrote: > I see, thanks. Don't know why I thought it was like this. Well, I'll try it > but fontconfig is indeed a big pain in the ass (editing XML is never fun). If you don't mind running an older revision of st (or porting my changes to a newer release), you can use my patch: https://github.com/ericpruitt/edge/blob/master/patches/st-00-font-array-support.diff Eric
Re: [dev] [st] font fallback
On Sun, Sep 03, 2017 at 06:24:13PM +0200, Quentin Rameau wrote: > > Hello, > > Hello Hadrien, > > > I'm trying view Japanese text but I don't manage to. Here's what I do > > with urxvt (it works): > > $ urxvt -fn "xft:xos4 Terminus:size=12,xft:Misc Fixed:size=11" > > > > with st (it doesn't; I get blank spaces or squares): > > $ st -f "xos4 Terminus:size=12,Misc Fixed Wide:size=11" > > > > Am I doing something wrong? > > As you can read in config.h, the string is called “font”, not “fonts”. > And so, st doesn't work with fallback fonts, this is something > fontconfig should do for you, there is the configuration to make. > > Until further progress on replacing this bloated font management. > > — Quentin > I see, thanks. Don't know why I thought it was like this. Well, I'll try it but fontconfig is indeed a big pain in the ass (editing XML is never fun).
Re: [dev] [st] font fallback
> Hello, Hello Hadrien, > I'm trying view Japanese text but I don't manage to. Here's what I do > with urxvt (it works): > $ urxvt -fn "xft:xos4 Terminus:size=12,xft:Misc Fixed:size=11" > > with st (it doesn't; I get blank spaces or squares): > $ st -f "xos4 Terminus:size=12,Misc Fixed Wide:size=11" > > Am I doing something wrong? As you can read in config.h, the string is called “font”, not “fonts”. And so, st doesn't work with fallback fonts, this is something fontconfig should do for you, there is the configuration to make. Until further progress on replacing this bloated font management. — Quentin
Re: ls -s vs. du (was: Re: [dev] [st] font fallback)
On 07/01/2013, Raphael Proust raphla...@gmail.com wrote: Real difference is du handles hard links (i.e. shows actual disk usage (as one would expect) by counting hard-linked files only once) while ls list files (as one would expect) (and optionally gives some information about them). Which wins. Ah, yes, I missed this. Unix wins again. Plan 9 ls has no R flag, which makes sense if truly ls's job is to list directories and du's job is to delve deep, tho Unix 8th ls has the flag. On another note, I find it sadly amusing how an unbelievable number of options [1] is fewer than most have today. [1] http://man.cat-v.org/unix_8th/1/ls
ls -s vs. du (was: Re: [dev] [st] font fallback)
[2013-01-05 18:55] Christoph Lohmann 2...@r-36.net % ls -hs st-0.3/st 126K st I wondered why 20h did not use `du -h st-0.3/st' instead. Then I wondered why ls(1) has `-s' at all. Even in 1st Edition Unix, ls(1) has `-s' although du(1) is available. http://man.cat-v.org/unix-1st/1/ls http://man.cat-v.org/unix-1st/1/du Does someone of you have more information on this? meillo
Re: ls -s vs. du (was: Re: [dev] [st] font fallback)
Didnt checked, but i guess that ls -s show size in bytes and du in block bytes, which depends on filesystem. ls -s : file size du : disk used On Jan 6, 2013, at 13:02, markus schnalke mei...@marmaro.de wrote: [2013-01-05 18:55] Christoph Lohmann 2...@r-36.net % ls -hs st-0.3/st 126K st I wondered why 20h did not use `du -h st-0.3/st' instead. Then I wondered why ls(1) has `-s' at all. Even in 1st Edition Unix, ls(1) has `-s' although du(1) is available. http://man.cat-v.org/unix-1st/1/ls http://man.cat-v.org/unix-1st/1/du Does someone of you have more information on this? meillo
Re: [dev] [st] font fallback
Greetings. On Sun, 06 Jan 2013 14:51:43 +0100 Charlie Kester corky1...@comcast.net wrote: Interesting. I get much a much bigger executable with the latest git. So I dug a little deeper and the problem seems to occur when pkg-config adds -lfreetype to the linker flags. Omitting that linker flag gets me a 85k binary after stripping, fwiw. It seems to run OK too. Do I really need to explicitly link to the freetype library? I don't see any complaints from the linker about unresolved symbols... ldd reports that my copy of st built without -lfreetype is using libfreetype.so.6. So it seems that something is already pulling it in. Hmm. I wonder if I was somehow linking to the static version of the freetype library? That might explain the font-related stuff I found in the .rodata section, and maybe the .eh_frame* stuff too. Does freetype appear in the ldd(1) output? Does it appear when you leave out ‐lfreetype? The pkg‐config dance was added to make st compile on OS X. Some OS X in‐ fidels sent me 80 female virgins I could sacrifice. That’s how you sup‐ port open source. Sincerely, Christoph Lohmann
Re: ls -s vs. du (was: Re: [dev] [st] font fallback)
On 06/01/2013, pancake panc...@youterm.com wrote: Didnt checked, but i guess that ls -s show size in bytes and du in block bytes, which depends on filesystem. Nope. Both show size in blocks [1]. It seems proper to do so in ls alone, with a flag of whether to add sizes of all files below; thus we could drop du. One may argue that the job of ls is not to add sizes, but now we have 2 utilities what list files, which loses. [1] http://www.openbsd.org/cgi-bin/man.cgi?query=(ls, du)
Re: [dev] [st] font fallback
On 01/06/2013 05:51 AM, Christoph Lohmann wrote: Does freetype appear in the ldd(1) output? Does it appear when you leave out ‐lfreetype? Yes, even without -lfreetype. I think one of the other shared libraries is pulling it in. I renamed my libfreetype.a to libfreetype.a.bak and the bloating problem goes away. So I'm pretty sure I was linking to it somehow. The pkg‐config dance was added to make st compile on OS X. Some OS X in‐ fidels sent me 80 female virgins I could sacrifice. That’s how you sup‐ port open source. :)
Re: [dev] [st] font fallback
On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. Been using st as my main terminal for a few months now. :) Me too. :)
Re: [dev] [st] font fallback
Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kester corky1...@comcast.net wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Sincerely, Christoph Lohmann
Re: [dev] [st] font fallback
On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kestercorky1...@comcast.net wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Yes. I took a closer look at the stripped executables using objdump, and most of the increase is in the .rodata section: v0.3:0cach (3,244) latest git: 16934h (92,468) But unless I'm mistaken, the static arrays go in the .data or .bss section (which also increased, but not by 16x.) So I must take back the allegation that the caches are the main culprit here.
Re: [dev] [st] font fallback
On 01/05/2013 07:33 AM, Charlie Kester wrote: On 01/05/2013 06:57 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 15:57:21 +0100 Charlie Kestercorky1...@comcast.net wrote: On 12/29/2012 12:20 AM, Kai Hendry wrote: Initially I was worried that the newer version was somehow slower to the version I was running before. Not slower, but definitely bigger. The stripped executable is now 16x the size of that from the 0.3 release -- thanks, no doubt, to these font caches, which are implemented as static arrays. That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. Yes. I took a closer look at the stripped executables using objdump, and most of the increase is in the .rodata section: v0.3: 0cach (3,244) latest git: 16934h (92,468) But unless I'm mistaken, the static arrays go in the .data or .bss section (which also increased, but not by 16x.) So I must take back the allegation that the caches are the main culprit here. I'm also seeing huge ( 20x) increases in the .eh_frame and .eh_frame_hdr sections. .data, on the other hand, increases slightly less than 10x. (But I'd already dropped the Fontcache frc[] array back to 256 elements, backing out the most recent change had which upped it to 2048. It was only after seeing that reverting this had no noticeable effect on the executable size that I started poking around with objdump.) The contents of the .rodata section do seem to have a lot of font-related stuff. I have no idea what's going on with the .eh_frame* sections. Hopefully these issues can be addressed and the size brought back under control. One of the nice things about st 0.3 is that a stripped executable is only 38k. That really helps convey the idea that it's a simple, suckless terminal emulator. Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow.
Re: [dev] [st] font fallback
Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kester corky1...@comcast.net wrote: Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st % strip st-0.3/st ls -hs st-0.3/st 48K % ls -hs scm/st/st 178K % strip scm/st/st ls -hs scm/st/st 91K st But I found out what’s causing the 50k(!) increase. It’s the big key[] array. Simply remove it and you get back the old 48k size. So the ques‐ tion is, if this array could be optimized out. The escape codes only partially have a system that could be replaced with ranges. On my system: % ls -hs /usr/bin/xterm /usr/bin/urxvt 1.3M /usr/bin/urxvt 452K /usr/bin/xterm That array gives st a better escape key support than any other terminal, but it bloats it with seldom used features and is now more than 50% of its size. That’s hard to decide. :/ What are the list's opinions? Sincerely, Christoph Lohmann
Re: [dev] [st] font fallback
On Jan 5, 2013 1:21 PM, Christoph Lohmann 2...@r-36.net wrote: What are the list's opinions? Extract the keys to another header, categorize keys somehow, add defines in config.mk to include/exclude different category keys. Or document defines in readme. Possible categories: EXTENDED_FN, NUMPAD... personally, I really like the fn keys --Carlos
Re: [dev] [st] font fallback
On 01/05/2013 09:55 AM, Christoph Lohmann wrote: Greetings. On Sat, 05 Jan 2013 18:55:12 +0100 Charlie Kestercorky1...@comcast.net wrote: Of course, some growth is expected as new features are added, but going from 38k to 618k is hard to swallow. On my system: % ls -hs st-0.3/st 126K st % strip st-0.3/st ls -hs st-0.3/st 48K % ls -hs scm/st/st 178K % strip scm/st/st ls -hs scm/st/st 91K st Interesting. I get much a much bigger executable with the latest git. So I dug a little deeper and the problem seems to occur when pkg-config adds -lfreetype to the linker flags. Omitting that linker flag gets me a 85k binary after stripping, fwiw. It seems to run OK too. Do I really need to explicitly link to the freetype library? I don't see any complaints from the linker about unresolved symbols... ldd reports that my copy of st built without -lfreetype is using libfreetype.so.6. So it seems that something is already pulling it in. Hmm. I wonder if I was somehow linking to the static version of the freetype library? That might explain the font-related stuff I found in the .rodata section, and maybe the .eh_frame* stuff too. Weird! Sorry for the noise.
Re: [dev] [st] font fallback
That’s only partially true. The array is adding 48k, which another patch series will reduce. Most of the additional memory usage is due to the font handling. So the inability of font handling in X.org/Fontconfig is the reason why too much has to be done over and over again. Yet another abstraction layer would hide it but waste the same resources. But unless I'm mistaken, the static arrays go in the .data or .bss section (which also increased, but not by 16x.) The bbs segment is not present in the executable. All the static data not initialized go to this segment, and the first thing that the executable does is a memset to 0 of the bbs segment. The executable only has the definition of the segment, begin address and size. This is the reason why is not the same these declarations: static int dummy; static int dummy = 0; The first goes to bbs and it is not present in the executable, and the second goes to data and it is present in the executable (of course some compilers can optimize it).
Re: [dev] [st] font fallback
Initially I was worried that the newer version was somehow slower to the version I was running before. I can't tell the version I was running before, hence the silly patch. So I just compared a little before the font code change and I couldn't really see a difference tbh. http://s.natalian.org/2012-12-29/1356768425_1366x768.png I'm using static char font[] = Terminus:file=ter-x16n.pcf.gz; btw, which can't zoom but looks the best of all the things I've tried. Been using st as my main terminal for a few months now. :) 0001-Show-version-that-corresponds-to-its-git-commit-id-t.patch Description: Binary data
Re: [dev] [st] font fallback
On Sat, Dec 29, 2012 at 04:20:11PM +0800, Kai Hendry wrote: So I just compared a little before the font code change and I couldn't really see a difference tbh. You can see the difference when you copy and paste characters that are not in your font. For example: ⊥ is not present in Terminus. There is a problem I have: character is now displayed, but it is larger than my font so there are some glithes. I think fallback code should never use characters from fonts larger than current font size. I'm using static char font[] = Terminus:file=ter-x16n.pcf.gz; btw, which can't zoom but looks the best of all the things I've tried. I have found better solution now: use font Terminus:pixelsize=16:lang=af or choose some other language. This way you can zoom. lang can be be, mo, wo and many other variants, they all trigger x version of Terminus as you can check with fc-match. Right solution would be to specify charset, but I have not found how to do it properly.
Re: [dev] [st] font fallback
Greetings. On Sat, 29 Dec 2012 15:05:00 +0100 p37si...@lavabit.com wrote: On Sat, Dec 29, 2012 at 04:20:11PM +0800, Kai Hendry wrote: So I just compared a little before the font code change and I couldn't really see a difference tbh. You can see the difference when you copy and paste characters that are not in your font. For example: ⊥ is not present in Terminus. There is a problem I have: character is now displayed, but it is larger than my font so there are some glithes. I think fallback code should never use characters from fonts larger than current font size. I’m working on the too big glyphs. This only appears when high‐detail glyphs, like Japanese or Chinese are scaled down. curl http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt Try this in current st please. It works! :D There is a new patch in st, which should speed the drawing back to nor‐ mal speed, when you are only using known characters from your font. It will need some time, when you first access unknown characters. I need some hints of people using many different Unicode subsets, if a cache of 256 characters is enough. I’m working on the bugs in the selection code related to wrong back re‐ porting of glyph widths. Sincerely, Christoph Lohmann
