| | <<<Back 1 day (to 2020/06/01) | Fwd 1 day (to 2020/06/03)>>> | 20200602 |
| myopia | do mupdf authors also run pdf viewers other than mupdf on windows/linux/osx? | 05:38.30 |
| sebras | myopia: I do. evince mostly. and an old version of acrobat for testing occasionally. | 05:48.09 |
| myopia | ah, I recall adobe quite a while ago had released (was it version six or something) acrobat because they had the license server down. | 05:49.26 |
| sebras | myopia: as far as I know this version of acrobat doesn't phone home during installation. | 05:51.05 |
| | oh! I should write acrobat reader of course! | 05:51.25 |
| | sorry for being imprecise. | 05:51.34 |
| myopia | poppler-based viewers has a history of its own, but I had guess that's the common denominator for unix desktops. on windows pdf viewers, however, would the presence of a shell extension, or windows imaging component codec be sign of the author's competence? | 05:51.52 |
| | it's all right. I think that's the Acrobat shipped in CS 2 | 05:52.41 |
| sebras | myopia: depends on what you value. neither components nor shell extensions are about rendering PDF, so in a sense that's superficial code (but might be essential for some use cases of course). | 05:55.10 |
| | i.e. that code has no impact on the rendering quality. | 05:55.37 |
| myopia | you probably mean glue code instead, but WIC (windows imaging component) codec allows people to read pdf in windows photo viewer alone (that's what cuminas' djvu shell extension + wic codec does), doing away with the need of a speciliazed viewer application | 05:58.18 |
| | while the mupdf application is itself rather minimal, I'm suggesting the minimization process can be pushed further | 05:59.10 |
| | (through a WIC gluing layer allowing people to read the pdf in windows photo viewer with only a library + registration) | 05:59.56 |
| sebras | myopia: ok, but then we'd need to read up on how to do that, in addition to building and testing before every release. | 06:00.48 |
| | myopia: if there were mupdf customers asking for this the incentive to look into it would be larger. | 06:02.50 |
| myopia | (I guess you are not asking for msft docs :( but yeah, product development should be driven by commercial interests) | 06:05.50 |
| | (on the other hand, thinking of the possibility microsoft becoming a sponsor and inclusion of your code in the windows nt os. I don't speak for microsoft though.) | 07:06.47 |
| | I'm curious, however, shouldn't you include a list of "stories of success" (with consent of your customer of course) on the official site just as other people did? | 09:04.18 |
| malc_ | - readelf -l ~/xsrc/llpp/build/mupdf/build/native/mupdf-gl | grep STACK | 10:34.54 |
| | GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 | 10:34.54 |
| | | 10:34.54 |
| | the E bit does not make a difference when mupdf-gl is started but for my onw code: | 10:35.27 |
| | [ 3175.205117] process 'xsrc/llpp/build/llpp' started with executable stack | 10:35.38 |
| ator | malc_: did you see my reply regarding the msfents.pdf outline? | 10:35.40 |
| malc_ | ator: nope | 10:35.48 |
| ator | https://ghostscript.com/mupdfirclogs/2020/06/01.html | 10:36.11 |
| malc_ | ator: thanks, can't say that i can make much out of your remark though :) | 10:38.05 |
| ator | malc_: I have a potential fix in the works, that should leave the x/y coordinates untouched if the 'top' value is missing | 10:38.10 |
| | malc_: I couldn't make much sense out of your initial question. I had to guess :) | 10:38.37 |
| | but I'm assuming you mean that it returned a position scrolled to the bottom of the page? | 10:38.55 |
| malc_ | ator: damn! i should take eloquence classes or something | 10:39.16 |
| | ator: maybe, you see my code will make incorrect positions and use them, and having continuous view exacerbates the problem i suppose | 10:40.33 |
| | ator: and the executable stack issue makes me feel violated, why does the kernel lashes out on my program and ignores the same issue in yours, why preferential treatment? is the kernel secretly anti functional... but kidding aside it is a bit puzzling | 10:42.47 |
| ator | I have no idea about the stack permission stuff. I just link my program same way as I've done the past 30 years, and go on my merry way. | 10:43.44 |
| malc_ | ditto | 10:44.53 |
| | and to clarify the continuous view remark, you, i suppose, you go to page + offset within a page, so worst case you still end up within the proper page... i translate the location into a global (whole document) relative position, and use that, which can lead me VERY far away from the intended destination | 10:48.03 |
| | ator: https://tpaste.us/pKVw - weird | 11:19.20 |
| | ator: and even distro built (just installed the package) mupdf has an executable stack | 11:20.52 |
| ator | malc_: I'm guessing they build with non-default flags to make the heap and stack non-executable. changing the default would break a lot of software. | 12:13.35 |
| malc_ | ator: nuc:~/xsrc/llpp | 12:14.52 |
| | - readelf -l build/mupdf/build/native/mupdf-gl | grep -A1 STACK | 12:14.52 |
| | GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 | 12:14.52 |
| | that is vanilla mupdf checkout | 12:15.04 |
| | so, no, i don't think you are correct | 12:15.14 |
| | 0x0000000000000000 0x0000000000000000 RWE 0x10 | 12:15.37 |
| | | 12:15.37 |
| ator | malc_: try adding -Wl,-z,noexecstack to the LDFLAGS in Makerules and rebuild | 12:27.09 |
| | or just -z noexecstack | 12:29.25 |
| | I have no idea why that is needed in mupdf, but mujs for example doesn't | 12:31.58 |
| malc_ | ator: that did the trick for mupdf-gl tack | 12:32.22 |
| ator | probably some third party library or libc function, it's all voodoo to me | 12:32.38 |
| | execstack -q build/debug/mupdf-gl is another way to find out | 12:33.19 |
| malc_ | ator: it just prints that it has Killed something and that's it | 12:41.40 |
| | in any case as it is "-z noexecstack" would be needed for all the binaries linked against mupdf, i think it's worthwhile to find the root cause | 12:42.54 |
| | ator: https://repo.or.cz/llpp.git/commitdiff/HEAD (so, thanks it works, but one (me) can't help but feel dirty and violated) | 12:48.41 |
| | ator: over the past few (weeks?) i have asked several questions in privmsgs but never got any replies, given that there are (at least) two possible explanations for that, i wonder which is it? a) you just don't receive my privmsgs b) the questions make it, but are not worthy | 15:20.40 |
| kens | suspects ator didn't notice them | 15:21.06 |
| | I miss PMs in IRC all the time | 15:21.25 |
| malc_ | kens: that's why i developed elisp (language my irc client is written in), shell (intermediary)' and python to get notifications :) | 15:23.43 |
| | and python *code* | 15:24.02 |
| | sigh | 15:24.05 |
| kens | Good grief, that seems like a lot of effort.... | 15:24.09 |
| | My IRC client does its best, it flashes at me, makes a noise, highlights the window, but I'm still perfectly capable of failing to notice it :-) | 15:25.03 |
| malc_ | kens: well mine is a bit wore sophisticated than that :) it's also lasting,flashes are easy to miss indeed | 15:26.53 |
| | <<<Back 1 day (to 2020/06/01) | Forward 1 day (to 2020/06/03)>>> | |
Log of #mupdf at irc.freenode.net.