| | <<<Back 1 day (to 2018/03/24) | 20180325 |
| Tamir_Evan | tor8: I just saw your top commit (http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commit;h=8546b3aac8b1037d299dbd681c9630b4e390f68d). The cross compilers shouldn't need the fix, as they're based on the Mingw-w64 toolchain, that doesn't have the problem. It's the mingw.org's toolchain that has the problem. | 02:57.21 |
| | tor8: A better place for such a fix would be in the 'ifeq "$(OS)" "MINGW"' block (currently line 69 onwards), even though it will effect the MSYS2 toolchains (that also shouldn't need it), as well. | 02:57.44 |
| sebras | /_3./_3.jb2 | 07:50.04 |
| | ehm... | 07:50.19 |
| vtorri | hello | 07:55.05 |
| 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. | 07:55.05 |
| vtorri | is there an example of filling forms in the tools ? | 07:55.33 |
| | detecting them and filling them | 07:55.45 |
| sebras | vtorri: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/x11/pdfapp.c;h=f011b5b0eef5d0a8079cf55266497638bdfc5c6d;hb=HEAD#l1661 | 08:05.13 |
| | vtorri: this is an area of active development, expect APIs to change in the future, I would. :) | 08:05.36 |
| vtorri | hehe | 08:11.01 |
| | sebras btw, would you have some minutes to review my code (it is not long | 08:11.27 |
| | sebras i would have 2 questions | 08:11.42 |
| | btw thank you | 08:12.44 |
| sebras | vtorri: what are your questions? | 08:13.39 |
| vtorri | sebras https://github.com/vtorri/etui/blob/master/src/modules/pdf/etui_module_pdf.c#L431 | 08:51.44 |
| | https://github.com/vtorri/etui/blob/master/src/modules/pdf/etui_module_pdf.c#L497 | 08:52.00 |
| | sebras first link : does the code looks correct to you ? | 08:52.29 |
| | sebras second link : should fz_count_pages() goes into the try block of the 1st link ? | 08:53.00 |
| sebras | vtorri: everything that takes a fz_context * can throw. | 08:53.23 |
| | vtorri: if not today, it might tomorrow. | 08:53.28 |
| | vtorri: and everything that can throw should be in a fz_try()/fz_catch() block if you want to do any form of cleanup. | 08:53.50 |
| vtorri | that answers the 2nd question :) | 08:54.14 |
| sebras | vtorri: if you are fine without cleanup, you don't need the fz_try()/fz_catch(). but that means that the caller must have a fz_try()/fz_catch(). | 08:54.21 |
| vtorri | sebras so i can out all the code which requires a context into a single try block, right ? | 08:55.10 |
| | sebras no need to have plenty of try/catch ? | 08:55.28 |
| sebras | vtorri: you can do it either way. | 08:56.11 |
| | vtorri: you fz_open_memory() to get a new fz_stream * reference, and give it to fz_open_document_with_stream() (which takes a reference to the stream), but you never drop the stream. | 08:57.09 |
| | vtorri: why do you test md->doc.doc for != NULL? mupdf is meant to throw if there is an error, not return NULL. you can assert() for your debug/developer builds if you prefere though. | 08:59.22 |
| vtorri | it's a library and i don't like asserts in a library | 09:00.38 |
| | ok for the stream, thank you | 09:00.47 |
| sebras | vtorri: the magic argument to fz_open_document_with_stream() should be similar to a MIME " | 09:01.06 |
| vtorri | sebras i should pass "application/pdf" ? | 09:02.08 |
| sebras | yes. | 09:02.15 |
| vtorri | ok, thank you | 09:02.24 |
| sebras | vtorri: I agree with you that there should not be asserts in a library if it is a release, if it is a development build that only you use, the situation is different. | 09:03.34 |
| | vtorri: if you ever want to support some other kind of document you can no longer hard code the MIME of course. | 09:05.43 |
| vtorri | sebras indeed | 09:05.58 |
| sebras | vtorri: and if you decide to do that you would also need to call fz_layout_document before fz_load_page(). | 09:06.00 |
| vtorri | i support other kind of documents | 09:06.15 |
| | sebras ok | 09:06.46 |
| sebras | vtorri: in that case, why are you suppling magic "application/pdf"? | 09:06.47 |
| | e.g. epub would require a call to fz_layout_document(). | 09:07.01 |
| vtorri | i agree, but i plan to support epub3, which mupdf does not support | 09:07.23 |
| | for now, it's only a pdf module | 09:07.39 |
| sebras | vtorri: ok, I meant using mupdf. | 09:07.50 |
| vtorri | i will add later postscript, DVI | 09:07.54 |
| sebras | vtorri: I'm not sure what fz_load_page() is meant to do on line 452..? you want to detect an invalid file? how do you know it will be triggered on page 0? perhaps only page 7 will cause the issue..? | 09:08.34 |
| vtorri | epub and kind of app will be done in another modules | 09:08.39 |
| | sebras look at the comment above | 09:09.05 |
| | sebras i've found this in mupdf code somewhere (i didn't invent it :) ) | 09:09.33 |
| sebras | vtorri: I did, but it is not true. | 09:09.39 |
| | vtorri: if the structure of the PDF objects in the file is completely broken page 0 might not load at all, but there is nothing preventing exceptions from occuring later on..? | 09:10.33 |
| | vtorri: just becase fz_load_page(0) succeeds, does not mean that fz_load_page(x) will succeed for x != 0... | 09:11.29 |
| vtorri | so i should just load a page in a try block and manage the error if any in catch | 09:12.11 |
| sebras | vtorri: that's what I would do. and I wouldn't load page 0 when opening the document, but rather handle errors when a page is loaded (in _etui_pdf_page_set()..?) | 09:14.11 |
| smatchcube | Hello, does mupdf support inverting colors out of the box? I would like to add this feature in the MuPDF viewer on Android. | 09:15.09 |
| vtorri | sebras ok, thank you very much | 09:18.29 |
| sebras | smatchcube: the mupdf on android does not, but sample viewers for other platforms do. | 09:20.37 |
| | smatchcube: it happens here: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/x11/pdfapp.c;h=f011b5b0eef5d0a8079cf55266497638bdfc5c6d;hb=HEAD#l942 in mupdf-x11 e.g. | 09:20.46 |
| | smatchcube: however the fz_invert_pixmap() call is not exported via JNI: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/java/src/com/artifex/mupdf/fitz/Pixmap.java;h=1616b90b5fd687b660e893db030d06fb2300be94;hb=HEAD | 09:21.23 |
| | smatchcube: also fz_invert_pixmap() inverts the entire page, background, text, images and all. so pictures will still funky. | 09:21.55 |
| | vtorri: I see that you fz_drop_outline() on line 471, but what if there is an error? you never drop it in fz_catch. | 09:22.36 |
| | vtorri: the same goes for the page you loaded on line 452, it is also never dropped in the fz_catch(). | 09:23.01 |
| | vtorri: in general, when you call fz_new_*() or fz_load_*() you get a new refrence to an object, if the library throws an exception, you are supposed to drop the references to anything you loaded in fz_catch(). | 09:23.50 |
| vtorri | ok, i note that | 09:25.49 |
| sebras | vtorri: see chapter 6 here: https://www.ghostscript.com/~robin/mupdf_explored.pdf it is not a finished mupdf book yet, but it might explain the finer details such as fz_var() more clearly for you. | 09:25.50 |
| vtorri | plenty of stuff to fix :) | 09:25.54 |
| | and to do :) | 09:26.37 |
| sebras | vtorri: there are a few things that do not need to be inside fz_try() even though they take ctx, such as fz_drop_*() and fz_free(). | 09:26.42 |
| vtorri | searching, filling forms and other features | 09:26.51 |
| | Tamir_Evan hey | 09:27.47 |
| | Tamir_Evan do you know if mupdf git code has everything fixed for msys2/mingw build ? | 09:28.14 |
| | Tamir_Evan i have some time right now | 09:28.23 |
| smatchcube | sebras: Thank you, that's exactly what i was looking for, i like inverting the colors with the zathura viewer on my computer, i will try to add the same feature in the android app, i'm new in android development and open source in general. | 09:28.27 |
| sebras | vtorri: https://github.com/vtorri/etui/blob/master/src/modules/pdf/etui_module_pdf.c#L647 you segfault on line 655 because you forget to set page to NULL here: https://github.com/vtorri/etui/blob/master/src/modules/pdf/etui_module_pdf.c#L498 | 09:29.35 |
| vtorri | sebras which version of mupdf ? >= 1.12 ? | 09:33.01 |
| sebras | vtorri: version? | 09:33.28 |
| vtorri | sebras ho sorry, misread | 09:34.35 |
| | thank you | 09:35.16 |
| | sebras line 498, page_teger | 09:36.31 |
| | arg | 09:36.35 |
| | baby laying with keyboard | 09:36.44 |
| | sebras line 498, page_nbr is an integer | 09:36.54 |
| | sebras any, first i should add all the try/catch blocks and manage the errors | 09:37.54 |
| sebras | smatchcube: because the JNI layer does not yet expose any interface to invert, you'd need to apply something like this to the library so it would allow you to invert the pixmap: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=0816737c974f149a10ae4a5d07d877a6b285a80a;hp=9ee9e370436c3bd9b1f3fd8e7c57fb2bdfb39587 | 09:39.13 |
| | smatchcube: because the JNI layer does not yet expose any interface to invert, you'd need to apply something like this to the library so it would allow you to invert the pixmap: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=0816737c974f149a10ae4a5d07d877a6b285a80a;hp=9ee9e370436c3bd9b1f3fd8e7c57fb2bdfb39587 | 09:39.28 |
| | smatchcube: I'll see if the other devs like the code next week, if so I'll try to get it into the library proper. | 09:40.01 |
| | vtorri: yes, but you should not only md->page.page_num = -1; you should also md->page.page = NULL; | 09:40.49 |
| | vtorri: ok, now I have to spend some time on my own things. you have a fair bit of thinks to work on now. | 09:41.22 |
| vtorri | sebras thank you :) | 10:38.58 |
| | sebras i use caloc to alloc my struct, so the page in NULL | 10:40.08 |
| smatchcube | I'm trying to create an icon for the "invert color" feature i would like to add in the android app, wich icon should i choose to describe this feature? A moon? | 12:19.59 |
| | Does it look fine or no? https://i.imgur.com/3GweWCU.png | 12:55.26 |
| Tamir_Evan | vtorri: The main mupdf.git repository still doesn't. Tor's fork's master should be build-able, as long as you use 'HAVE_GLUT=no' (building mupdf-gl is still not supported). | 13:20.25 |
| vtorri | Tamir_Evan ok, thank you | 13:48.24 |
| | Forward 1 day (to 2018/03/26)>>> | |
Log of #mupdf at irc.freenode.net.
