Log of #mupdf at irc.freenode.net.

 <<<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 match10:10.13 
  the -B and -C options10:11.04 
  use fz_tint_pixmap if you want to do the same in llpp10:11.47 
  see render_page in gl-main.c for its use10:12.55 
  ugh, this reminds me that I'm still unhappy about the gamma correction situation10: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 different10: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 there10:16.11 
ator malc_: which opengl version do you use? old fixed function or with shaders?10:53.24 
malc_ ator: FFP10: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 black10: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_luminance10:55.44 
  will be harder to replicate with FF opengl but trivial with shaders10: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" means11:01.27 
  ator: oh, i just remember not touching it :) though faint memories of using MODULATE for something or other are there in my brain11:02.25 
  i've lied (unreliable narrator)! i use modulate all the time11: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 message11:50.06 
  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.png12:02.04 
ator malc_: not my fault that your X server lies about its physical size...12:03.54 
malc_ ator: it does not12: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, hpx12:05.14 
  and 'ppi' just to save me some headaches calculating :)12:05.33 
malc_ ator: https://tpaste.us/yNxk12:10.10 
ator your screen is really 1 meter wide?12:11.27 
malc_ 62 cm12: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 dimensions12:14.08 
malc_ dimensions: 3840x2160 pixels (1016x571 millimeters)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 acceptable12: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 server12:18.14 
malc_ https://github.com/moosotc/snippets/blob/master/.xinitrc and https://github.com/moosotc/snippets/blob/master/bin/setdpi12: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 itself12: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 flag12: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 
  FWIW https://www.displayspecifications.com/en/model/f72116de12: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 up12:25.07 
  <ator> xrandr | grep connected12:25.17 
malc_ ator: https://tpaste.us/YoRM12:30.31 
  it appears that (core)X is lying, not the monitor12:31.25 
artifexirc-bot <ator> yeah, looks that way12:33.25 
  <ator> no idea what to do about it though12: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 in12: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 apps12:36.20 
  I used that command and it overwrote what xdpyinfo returned12:36.32 
malc_ yeah yeah, same reason 96 dpi is returned everywhere12: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 sizes12:37.44 
malc_ oh sorry xrandr --dpi wasn't called by my bin/setdpi12:37.53 
  ator: okay, xrandr --dpi helps, with 200 it's usable12: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 mes12:49.35 
malc_ ator: i think you don't get (more) too-small reports cause everyone and their dog just scales everything12:53.23 
  instead of just making "text" bigger that is12: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 up13:33.07 
sebras malc_: https://sourceware.org/pipermail/libc-alpha/2021-April/124832.html14: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_irzenius15: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/vZmZ19:28.59 
 <<<Back 1 day (to 2021/04/05)Forward 1 day (to 2021/04/07)>>> 
ghostscript.com #ghostscript