| | <<<Back 1 day (to 2020/12/19) | Fwd 1 day (to 2020/12/21)>>> | 20201220 |
| vtorri__ | hello | 05:47.36 |
| mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 05:47.36 |
| vtorri__15 | afaics, with msys+mingw-w64, the library is name libmupdf.so and is put in $prefix/lib | 05:49.56 |
| | shared lib of course | 05:50.13 |
| | it should be named libmupdf-X.dll and be put in $prefix/dll | 05:50.42 |
| | X is the major version | 05:50.58 |
| | it may also be called just mupdf-X.dll | 05:51.24 |
| | also, an import lib should be create | 05:52.19 |
| | name : libmupdf.dll.a | 05:53.04 |
| | with this option passed to gcc : | 05:53.20 |
| | -shared -Wl,--out-implib,libmupdf.dll.a | 05:53.56 |
| | if you want, i can provide a patch | 06:02.05 |
| vtorri | also, when i compile the git, i have this error : | 10:07.21 |
| | memento.h not found | 10:08.18 |
| | hmm | 10:09.04 |
| | for source/fitz/memento.c | 10:10.00 |
| | (on Windows, msys2 + mingw-w64) | 10:10.56 |
| artifexirc-bot | <Robin_Watts> include/mupdf/memento.h is certainly there. | 11:12.17 |
| krjst | I'm getting "AttributeError: 'Document' object has no attribute '_updateObject'" error when using the function doc.setToC in the latest version. Is it a bug or the API changed" | 13:44.42 |
| | oops, this is for PyMuPDF | 13:45.02 |
| sebras | krjst: let me have a look. I'm not a pymupdf expert though. | 14:12.01 |
| vtorri | Robin_Watts : only of MEMENTO_MUPDF_HACKS is defined | 17:19.07 |
| | only if* | 17:19.21 |
| sebras | vtorri: in the mupdf build that flag is defined when building memento builds. | 17:38.58 |
| | it affects where memento.h is included from. | 17:39.05 |
| | vtorri: are you intending to build a memento build or did you just include that .c-file by accident? | 17:39.22 |
| | krjst: I've been trying to build our python wrapper both on current HEAD and on 1.18.0, but nowehere can I find doc.setToC() | 17:45.51 |
| | krjst: only to first _now_ notice that you mentioned pymupdf! :) | 17:48.42 |
| | krjst: yeah, they appear to have changed their internal doc._updateObject() to doc.update_object() if I read the code correctly. | 17:49.15 |
| | krjst: I think simply renaming the call in utils.py would work. | 17:50.02 |
| vtorri__ | sebras i compile mupdf using system libraries with that shell script : | 18:03.02 |
| | http://codepad.org/MZOG1OEr | 18:03.05 |
| | sebras it used to works until mupdf 1.17 | 18:03.32 |
| | sebras notivce that latest jbib2dec is already installed | 18:04.19 |
| | it also works with mupdf 1.18 | 18:04.41 |
| | just tried | 18:04.45 |
| | latest jbig2dec == 0.17, taken here : https://www.jbig2dec.com/ | 18:05.44 |
| vtorri | sebras it's a commit done by Robin_Watts that changed this | 18:10.10 |
| | sebras, Robin_Watts : maybe i should set 'build' to 'release' | 18:14.15 |
| | hmm, it is set to release by default | 18:19.17 |
| MP64 | Hi, should I see a significant performance gain when I render only a part of a PDF-page in Java? | 18:28.17 |
| | I use displayList.run(device, matrix, clip, null); | 18:28.35 |
| | When I set clip to full page bounds, nmy document takes 17 seconds. | 18:28.53 |
| | When I set clip to the top quarter of the page, my document takes 15 seconds. | 18:29.14 |
| | Is this normal? | 18:29.17 |
| | Background: I was hoping to improve performance by rendering bands in parallel on a multi-core processor. | 18:29.52 |
| sebras | krjst: ah, you have already reported this! https://github.com/pymupdf/PyMuPDF/issues/779 | 20:40.08 |
| | vtorri: yes, mupdf defaults to release builds unless you set build=debug or build=memento. | 20:47.01 |
| malc_ | sebras: unless build isn't set to "release" is more accurate wording | 20:48.36 |
| sebras | malc_: yeah, yeah. the code is more important than my english. :) | 20:50.57 |
| malc_ | sebras: 是嗎!! | 20:51.45 |
| sebras | 對啊，有不然我說中文的朋友都沒辦法聽到我說什麼，因爲我的發音有一點奇怪，而且我常常搞混單詞。 | 20:53.40 |
| | vtorri: I've tried to use your command to compile this on Linux. on git HEAD we don't include memento.c. and your build shouldn't be doing that either. | 20:56.16 |
| malc_ | sebras: tones ought to be difficult to get, right, too | 21:01.29 |
| sebras | malc_: yeah, but I tend to get those roughly correct for most words. | 21:08.13 |
| | but I might say "peatre" instead of "repeat" because I forget the syllable order within a word. | 21:08.51 |
| | confusingly these are sometimes also valid words! | 21:09.13 |
| malc_ | sebras: learry?? :) | 21:13.00 |
| | which would have been even funnier if we were discussing hinongo | 21:13.47 |
| | sebras: anywho, natt tid.. | 21:20.23 |
| sebras | vtorri: found something. | 21:26.12 |
| | vtorri: I mananged to reproduce. we're apparently including memento.h from jbig2dec when we're not building memento-builds, but we should be including the one from mupdf of course. | 21:26.51 |
| | vtorri: and you're right, this is tied to MEMENTO_MUPDF_HACKS | 21:27.30 |
| | vtorri: I didn't see this because I use the bundled jbig2dec which included a memento.h that was present in the header file search path papering over the issue. | 21:28.06 |
| | vtorri: using this http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=1ca01508187e8fdf99b842b8f0e4284005d75948 I'm able to build in the same way as you do. I'll get robin to review it in january and make sure it gets in. | 21:54.26 |
| vtorri | sebras i'll try thanks | 22:39.39 |
| | sebras and for my comments about windows build ? | 22:43.28 |
| sebras | vtorri: I don't run windows, so i can't really comment on that. | 23:52.08 |
| | vtorri: the devs working on windows are likely away until early next year. do you mind filing a bug about it? that way it will not get lost. :) | 23:52.46 |
| | <<<Back 1 day (to 2020/12/19) | Forward 1 day (to 2020/12/21)>>> | |
Log of #mupdf at irc.freenode.net.