| <<<Back 1 day (to 2020/05/18) | Fwd 1 day (to 2020/05/20)>>> | 20200519 |
conhector | Hi there, quick question: Does MuPDF have a feature like Acrobat Reader's Night-Mode? | 02:20.40 |
sebras | conhector: MuPDF mini for android doesn't currently have a night mode feature, no. | 06:04.38 |
conhector | sebras: Thank you for the info. | 11:08.34 |
ator | pedr0: you will probably have more luck looking at the pdf_processor stuff | 11:26.01 |
| pedr0: or just use the pdf_filter_page_contents function | 11:26.54 |
| pedr0: see pdf_redact_page for an example of how that stuff is used | 11:27.46 |
malc_ | make build=native started yielding - https://tpaste.us/XgMl , i don't know when this started to happen (`make build=native libs` is what is used to build things over here) | 12:15.44 |
pedr0 | ator: thanks a lot | 16:22.52 |
| I've done so and it's all pretty OK in a small example, but as soon as I try to do something 'real' I stumbled upon a SEGSEV. I am using a document_writer and somehow it explodes when I execute the fz_close_document_writer - within a fz_always block | 16:26.51 |
| Fine, that was me being a silly man and having forgot what lexically scoped means. | 16:48.04 |
hisacro | is there a way to change table of contents colors.. mupdf-gl 1.17.0 | 20:28.23 |
| this https://pictshare.net/jvz17d.png to be exact | 20:31.32 |
sebras | hisacro: not without changing the source code. | 20:44.55 |
| hisacro: whether it will ever be is up to the main developer, ator. my best bet is that it is unlikely to be configurable. | 20:45.32 |
| s/to be/to ever be/ | 20:45.47 |
ator | hisacro: platform/gl/gl-app.h, line 200-ish defines various colors for the UI, such as UI_COLOR_PANEL, etc. | 21:09.49 |
| hisacro: changing those should be enough, I think | 21:10.17 |
hisacro | ator really appreciate it thanks! | 21:12.13 |
malc_ | ator: no comment on the freeglut issue i have alluded to earlier? | 21:22.20 |
ator | malc_: never seen it before, sorry. | 21:25.31 |
| hisacro: https://pastebin.com/raw/um8ZR1n5 something like this should be a decent start | 21:26.52 |
malc_ | ator: never seen my message or the problem i described in the paste? | 21:28.19 |
ator | the problem | 21:28.25 |
malc_ | okay, guess i will have to debug it on my own | 21:29.15 |
sebras | malc_: ator: fg_gl2.h declares fghGenBuffers. that header is included in both fg_gl2.c and fg_window.c | 21:32.02 |
malc_ | sebras: it has no guards or something? | 21:32.36 |
sebras | s/declares/defines/ | 21:33.00 |
| sorry. | 21:33.01 |
ator | I can't replicate the build errors with build=native and CC=gcc nor CC=clang | 21:33.08 |
sebras | this likely only happens when GL_ES_VERSION_2_0 is not set. | 21:33.25 |
malc_ | i just replicated it with empty build (i.e. without build=native) | 21:33.45 |
ator | but maybe you have different opengl headers and that's messing things up? | 21:33.47 |
malc_ | all with gcc | 21:33.50 |
sebras | ator: that seems to be quite likely. | 21:33.59 |
malc_ | ator: i have usual mesa.... it might be quite a bit newer (20.0.7) than whatever you are using though | 21:35.41 |
sebras | malc_: on my system GL_ES_VERSION_2_0 is not set. | 21:36.18 |
| running nm on fg_gl2.o and fg_window.o reveals: | 21:39.21 |
| 0000000000000008 C fghGenBuffers | 21:39.35 |
| for both files. | 21:39.37 |
| "C" The symbol is common. Common symbols are uninitialized data. | 21:39.43 |
| When linking, multiple common symbols may appear with the same | 21:39.44 |
| name. If the symbol is defined anywhere, the common symbols | 21:39.44 |
| are treated as undefined references. | 21:39.44 |
malc_ | sebras: not sure what GL_ES have to do with it though | 21:39.50 |
sebras | malc_: so it seems to me like the linker should accept multiple symbols of that name? | 21:40.15 |
| malc_: are they of type C in your case? | 21:40.27 |
malc_ | sebras: nope: 0000000000000000 B fghGenBuffers | 21:42.46 |
sebras | malc_: that's interesting. | 21:42.56 |
| so gcc-10 thinks they should up as BSS. | 21:43.11 |
| https://lwn.net/Articles/819933/ | 21:46.09 |
| https://github.com/dcnieho/FreeGLUT/commit/b9998bbc1e1c329f6bf69c24606a2be7a4973b8c | 21:47.01 |
| ator: we should take that commit ^^^ | 21:47.11 |
| zzz | 21:48.46 |
malc_ | zebraz: great investigative work (again) thank you | 21:49.36 |
| and things do build with clang so yeah gcc 10 is the culprit here | 21:52.00 |
pedr0 | is there any documentation for mutool poster ? | 22:00.44 |
| can't find it here : https://www.mupdf.com/docs/index.html | 22:01.03 |
| <<<Back 1 day (to 2020/05/18) | Forward 1 day (to 2020/05/20)>>> | |