| | <<<Back 1 day (to 2018/09/13) | 20180914 |
| pink_mist | hmm, I just tried building mujs 1.0.4, but got linker errors ... 1.0.3 works fine | 00:47.06 |
| | (a few warnings on both of them though) | 00:47.21 |
| | https://gist.github.com/pink-mist/b6323d500a3d8d10bd7824f6b864087e is the make output | 00:50.53 |
| avih | pink_mist: these look readline related. for now you can make HAVE_READLINE=no | 00:54.31 |
| pink_mist | avih: I assume I don't need readline to link mujs in mpv? | 00:54.59 |
| avih | correct | 00:55.05 |
| pink_mist | alright, let me try it then =) | 00:55.14 |
| | thanks, works now =) | 00:56.30 |
| | odd though ... I certainly do have readline :/ | 00:56.40 |
| avih | could be a version thing or other $whatever issues... | 00:58.01 |
| | i'd guess something is wonky in your setup. it links with readline and then complains that symbols which readline uses are not found... maybe it needs some other lib? imo try LD_FLAGS=-ltermcap (or -ltermlib) | 01:01.05 |
| | LDFLAGS * | 01:01.55 |
| | these maybe could have been avoided by using pkg-config and/or configure step, but mujs tries to stay simple and leaves these earthly matters to you | 01:03.10 |
| pink_mist | ahh, LDFLAG=-ltermcap does the trick, yes! =) | 01:03.54 |
| avih | anyway, it's only used for the interactive shell and even it can also works without it, just without history and fancy line editing | 01:05.23 |
| | (wtf human syntax errors...) | 01:09.23 |
| pink_mist | *LDFLAGS | 01:21.09 |
| tor8 | pink_mist: looks like symbols from libcurses | 09:31.42 |
| | that -lreadline ought to pull in automatically | 09:32.10 |
| sebras | Robin_Watts: may I disturb you with a question? | 16:40.05 |
| Robin_Watts | sure. | 16:40.13 |
| sebras | Robin_Watts: my latest bmpcmp has some results. | 16:40.16 |
| | Robin_Watts: one being 2325_-_JPX_image_with_padding_rejected.pdf | 16:40.24 |
| | with the previous version of openjpeg we could render it fine | 16:40.48 |
| | with the new version, it errors out. | 16:40.54 |
| Robin_Watts | ok. | 16:40.57 |
| sebras | my old acrobat reader 9.5.5 renders the file fine however. | 16:41.10 |
| | can you try with a later version? | 16:41.17 |
| Robin_Watts | Sure. | 16:41.23 |
| sebras | I presume it will render fine, but I don't know. | 16:41.27 |
| Robin_Watts | DC renders it fine. | 16:42.04 |
| sebras | I have examined objects 13, 25 and 37 inside the PDF. | 16:42.08 |
| | these are all JPX images. | 16:42.14 |
| | wait. I'm mixing up my files. :) those were not the objects for this file. | 16:42.47 |
| | in this file the interesting object is number 3, which is a JPX | 16:43.29 |
| | and this file has incorrectly counted the size of its data field it seems. | 16:43.44 |
| | making openjpeg parse an incorrect marker. | 16:43.56 |
| | with the upgrade openjpeg recognizes the error and handles it differently. | 16:44.14 |
| Robin_Watts | There being an incorrect amount of padding, I would guess :) | 16:44.18 |
| sebras | what do I do now? | 16:44.21 |
| Robin_Watts | gs also renders it blank. | 16:44.38 |
| sebras | do I consider this a fatal regression because acroread can render it fine? | 16:44.38 |
| Robin_Watts | I think we open a bug to capture the regression and continue onwards. | 16:45.04 |
| | And then when we have more time, come back and look at it. | 16:45.13 |
| sebras | Robin_Watts: so basically we consider this to be a bug where..? | 16:45.37 |
| Robin_Watts | sebras: We consider it to be a regression. | 16:45.48 |
| sebras | Robin_Watts: the file is fault, openjpeg rejects it, but it didn't use to. | 16:45.53 |
| | Robin_Watts: I figure that this is unlikely to change upstream. | 16:46.03 |
| Robin_Watts | Possibly a justified one, but a regression nonetheless. | 16:46.03 |
| sebras | Robin_Watts: sure, but when we get to this bug, what are we to do? | 16:46.40 |
| | Robin_Watts: the easiest option would probably be to have adobe change their code... ;-) | 16:47.02 |
| Robin_Watts | sebras: So we can look to see if there is a simple fix that we can either carry around as a patch, or pass upstream, and if not, after careful consideration, and all things being equal, and in the fullness of time, we can close the bug. | 16:47.03 |
| | and when people query it, we can point to the bug. | 16:47.26 |
| sebras | Robin_Watts: so a file and forget bug? | 16:47.35 |
| | that seems silly. better to file the bug now and explain the decision and close it while I have the knowledge..? | 16:47.54 |
| Robin_Watts | A bug enables us to postpone doing the analysis on it for now. | 16:48.01 |
| | sebras: If you know enough to open the bug, explain it, and close it now, then so much the better. | 16:48.22 |
| | But when someone complains at least we'll have captured the logic somewhere. | 16:48.45 |
| | sebras: We could possibly make the bug bountiable, in case someone wants to fix it. | 16:49.26 |
| | From the name on the file, I'd guess that zeniko already fixed this once. | 16:50.03 |
| | I know for a fact that when someone comes back in 6 months to ask why this file doesn't render, I won't remember. (Who am I kidding. I won't remember tomorrow). | 16:51.16 |
| | but having the record in a bug might save some time. | 16:51.46 |
| | Forward 1 day (to 2018/09/15)>>> | |
Log of #mupdf at irc.freenode.net.