| | <<<Back 1 day (to 2021/04/05) | Fwd 1 day (to 2021/04/07)>>> | 20210406 |
| malc_ | ator: https://github.com/moosotc/llpp/issues/165 was my intuition wrong? | 10:03.11 |
| ator | malc_: for mupdf-gl there are options to set both the black and white colors and it'll color tint (and invert) to match | 10:10.13 |
| | the -B and -C options | 10:11.04 |
| | use fz_tint_pixmap if you want to do the same in llpp | 10:11.47 |
| | see render_page in gl-main.c for its use | 10:12.55 |
| | ugh, this reminds me that I'm still unhappy about the gamma correction situation | 10:13.17 |
| malc_ | ator: thanks, llpp's brightness control is enough for me (dirt cheep too just set the glcolor), what the OP wants is different | 10:13.39 |
| | ator: and what he wants is, a guess, to change the color of just text (a vague term) and tinting is of no use there | 10:16.11 |
| ator | malc_: which opengl version do you use? old fixed function or with shaders? | 10:53.24 |
| malc_ | ator: FFP | 10:53.53 |
| ator | mupdf's -B and -C are essentially just setting glColor with mulitply mode (GL_DECAL) for the 'white' color and an ambient color to lift up the black | 10:54.43 |
| | what he wants looks like setting white to black and black to white to create a 'dark mode' | 10:55.10 |
| | which we have, with a hue-preserving inversion in fz_invert_pixmap_luminance | 10:55.44 |
| | will be harder to replicate with FF opengl but trivial with shaders | 10:56.22 |
| malc_ | ator: i even leave blend mode alone (in the normal case) | 10:59.36 |
| ator | GL_DECAL is the default how glColor and glTexture interact, nothing to do with blend modes :) | 11:00.45 |
| malc_ | ator: and the way i understand his request is that he wants to only change "text" and that (i think) is, in general impossible, because he never defined what "text" means | 11:01.27 |
| | ator: oh, i just remember not touching it :) though faint memories of using MODULATE for something or other are there in my brain | 11:02.25 |
| | i've lied (unreliable narrator)! i use modulate all the time | 11:04.47 |
| | hmm.. "-A -set anti-aliasing level (0-8,9,10)" why not a simple (0-10) ? | 11:42.56 |
| | ator: and since i'm playing mupdf-gl decided to feed it (the infamous) ECMA-376 2nd ed. part1, it appears that mupdf-gl takes longer to show the initial page than llpp. despite the fact that mupdf-gl does not have to get all pages' dimensions (which llpp has too for continuous viewing to work) | 11:47.57 |
| artifexirc-bot | <Robin_Watts> because 0-8 mean "number of bits" and 9 and 10 mean 'special' things. | 11:48.08 |
| malc_ | Robin_Watts: okay, it's just that i never read documentation and it's hard to derive the exact speciality of 9,10 from terse usage message | 11:50.06 |
| | thanks | 11:50.09 |
| | ator: i already mentioned this a long while ago, but here is a visual aid https://boblycat.org/~malc/scratch/mupdf-gl-on-4k-screen.png | 12:02.04 |
| ator | malc_: not my fault that your X server lies about its physical size... | 12:03.54 |
| malc_ | ator: it does not | 12:04.09 |
| ator | hmm. could you add a printf to mupdf-gl and show me what it says? | 12:04.39 |
| malc_ | ator: where? | 12:04.51 |
| ator | in platform/gl/gl-ui.c in ui_init() | 12:04.54 |
| | right after the glutGet(GLUT_SCREEN_WIDTH_MM) block, print out the results of wmm wpx, hmm, hpx | 12:05.14 |
| | and 'ppi' just to save me some headaches calculating :) | 12:05.33 |
| malc_ | ator: https://tpaste.us/yNxk | 12:10.10 |
| ator | your screen is really 1 meter wide? | 12:11.27 |
| malc_ | 62 cm | 12:12.31 |
| ator | then your X server is lying... it returns 1016 not 620 as it should. it lies and claims 96dpi when it's not. | 12:13.28 |
| | xdpyinfo | grep dimensions | 12:14.08 |
| malc_ | dimensions: 3840x2160 pixels (1016x571 millimeters) | 12:15.06 |
| | | 12:15.06 |
| | that said a went through considerable pain to make those (most non mupdf things) respect Xft.dpi which i set manually to something acceptable | 12:16.17 |
| | (as part of .xinitrc) | 12:16.43 |
| artifexirc-bot | <ator> I guess I could dig out my old X11 manuals and figure out how to get the Xft.dpi resource value and use that to override the DPI returned by the X server | 12:18.14 |
| malc_ | https://github.com/moosotc/snippets/blob/master/.xinitrc and https://github.com/moosotc/snippets/blob/master/bin/setdpi | 12:18.31 |
| artifexirc-bot | <ator> do you use an xorg.conf file? | 12:18.44 |
| | <ator> in the Section "Monitor" you can add a DisplaySize <width> <height> to set the physical size, in case Xorg can't figure it out itself | 12:19.27 |
| malc_ | ator: i do not, everything is done by hand (otherwise things start to get unreliable and unreproducible) | 12:19.32 |
| artifexirc-bot | <ator> or just start Xorg with a --dpi flag | 12:19.40 |
| malc_ | ator: i'd rather not, though it's seems easy and tempting to add this to .xserverrc, i'd rather not still... | 12:20.37 |
| | https://github.com/moosotc/snippets/blob/master/.xserverrc | 12:21.00 |
| | FWIW https://www.displayspecifications.com/en/model/f72116de | 12:22.58 |
| artifexirc-bot | <ator> why not? it's misconfigured as it is, I'm assuming the monitor is lying (or not talking at all) about its physical size to X depending on how you hook it up | 12:25.07 |
| | <ator> xrandr | grep connected | 12:25.17 |
| malc_ | ator: https://tpaste.us/YoRM | 12:30.31 |
| | it appears that (core)X is lying, not the monitor | 12:31.25 |
| artifexirc-bot | <ator> yeah, looks that way | 12:33.25 |
| | <ator> no idea what to do about it though | 12:33.32 |
| malc_ | ator: if i recall correctly this is why i stopped trying to trust X inside setdpi and just hardcoded the right value in | 12:34.30 |
| ator | malc_: hm, can you try "xrandr --dpi 160" and see what happens? | 12:35.44 |
| malc_ | ator: it's already 163 :) | 12:36.18 |
| ator | I'm kinda guessing they default to broken behavior for backward compatibility with broken apps | 12:36.20 |
| | I used that command and it overwrote what xdpyinfo returned | 12:36.32 |
| malc_ | yeah yeah, same reason 96 dpi is returned everywhere | 12:36.43 |
| ator | if I run "xrandr --dpi 150" then mupdf-gl scales up (even if I do have ~96dpi actual monitors) | 12:37.11 |
| | the sidebar looks thin though :/ | 12:37.33 |
| | maybe I should look into scaling other ui elements a bit better rather than hardwiring their sizes | 12:37.44 |
| malc_ | oh sorry xrandr --dpi wasn't called by my bin/setdpi | 12:37.53 |
| | ator: okay, xrandr --dpi helps, with 200 it's usable | 12:40.10 |
| | funny how no one but mupdf-gl seems to care about the effect xrandr --dpi had (only tested core X and gtk applications though, maybe things are different with Qt and) | 12:44.18 |
| ator | dpi awareness on linux (i.e gtk+ and Qt) is a royal mes | 12:49.35 |
| | s | 12:49.36 |
| malc_ | ator: i think you don't get (more) too-small reports cause everyone and their dog just scales everything | 12:53.23 |
| | instead of just making "text" bigger that is | 12:53.52 |
| ator | mupdf-gl looks pretty ugly since we just scale up the text size and not the margins and padding :/ | 12:55.25 |
| malc_ | ator: hah, funny how hjkl in mupdf-gl is sort of useless on dvorak, i tried to provide a mode in llpp where you con bind codes instead of names, but then gave up | 13:33.07 |
| sebras | malc_: https://sourceware.org/pipermail/libc-alpha/2021-April/124832.html | 14:40.35 |
| malc_ | sebras: congrats! | 14:41.23 |
| | sebras: btw does this ordlist change has any bearing at all on sv_FI? | 14:55.42 |
| sebras | as far as I know it should only affect sv_SE. I have not looked at sv_FI. | 15:18.48 |
| malc_ | sebras: i've meant to ask whether Swedish speaking finns give a flying f... about the decrees of swedish academy back "home" | 15:45.05 |
| | does Linus care in other words? or _W_irzenius | 15:46.30 |
| artifexirc-bot | <sebras> malc_: good question. | 16:31.46 |
| sebras | malc_: so sv_FI appears to copy sv_SE... | 16:39.24 |
| malc_ | ator: for the logs - https://tpaste.us/vZmZ | 19:28.59 |
| | <<<Back 1 day (to 2021/04/05) | Forward 1 day (to 2021/04/07)>>> | |
Log of #mupdf at irc.freenode.net.
