| | <<<Back 1 day (to 2011/10/21) | 2011/10/22 |
| mvrhel2 | henrys: I know its late but it looks like the windows build was broken by kens | 06:39.59 |
| | this is why we need a simple scratch build to check this | 06:40.22 |
| | with commits | 06:40.30 |
| | before I complain too much, let me clean and rebuild | 06:41.24 |
| | yup its broke | 06:44.54 |
| | hmm that is weird | 06:45.57 |
| | for some reason my fetch did not seem to update gxfcid.h | 06:49.03 |
| | but I see that is was part of the commit | 06:49.11 |
| | oh crap. I see. | 06:50.43 |
| | My git tree is screwed up | 06:50.51 |
| | not sure how that happened but now it all works. | 06:54.54 |
| | had not had a git issue in a long time | 06:55.21 |
| | ok. another XPS issue fixed. calling it a night | 06:58.17 |
| vtorri | hey | 17:57.34 |
| | before, in mupdf, there was the pdf_getpageobject() function | 17:57.52 |
| | the script in mupdf 0.9 replaces it with pdf_get_page_object | 17:58.10 |
| | but that function does not exist... | 17:58.22 |
| | so, by which function is it replaced | 17:58.38 |
| | ? | 17:58.39 |
| | is pdf_getpageobject()/pdf_loadpage() replaced by just pdfloadpage() ? | 18:00.47 |
| | by just pdf_load_page()* | 18:03.13 |
| | tor8: there were API breaks :/ | 18:09.21 |
| sebras | vtorri: yes, pdf_getpageobject()+pdf_loadpage() was replaced with pdf_load_page(), the latter which takes a page number. | 20:55.03 |
| vtorri | sebras: there are plenty of other problems, now | 20:55.53 |
| sebras | vtorri: there are some placed however where one actually wants the page object itself, e.g. gatherpageinfo() in apps/pdfinfo.c in which case one has to do xref->page_objs[pageno-1]. | 20:55.54 |
| vtorri | i mean, plenty of other api break | 20:56.33 |
| sebras | vtorri: ok. do you mind detailing them? I may be able to help you with some of them. | 20:57.02 |
| vtorri | pdf_crypt *crypt, crypt->p | 20:57.35 |
| | crypt is abstract now | 20:57.42 |
| | so i can't access crypt->p | 20:58.54 |
| sebras | vtorri: I believe that you could call pdf_has_permission() as given in pdf/mupdf.h | 20:59.46 |
| | vtorri: you give it an xref and a permission and it does the checking for you. | 21:00.15 |
| | vtorri: if you have further problems with accessing stuff inside pdf_crypt there are other functions for getting crypt-related information near by the prototype of pdf_has_permission() in pdf/mupdf.h | 21:01.08 |
| vtorri | thanks | 21:01.33 |
| | the 2nd parameter is one of hthe enum | 21:01.44 |
| | instead of an int, you should name the enum and use that type | 21:02.07 |
| | so that the user knows what to pass | 21:02.14 |
| sebras | vtorri: generally no enums are used as arguments to any function in mupdf. | 21:02.43 |
| vtorri | same for other unamed enum in mupdf.h | 21:02.47 |
| | in that case, it is | 21:03.00 |
| | so naming the enum is a good idea | 21:03.31 |
| sebras | vtorri: I personally don't have too much of an opinion on that. I'll pass your comment on to tor8 though. | 21:06.10 |
| vtorri | pdf_has_permission() returns 0 if the permission is not given ? | 21:06.27 |
| | that is, like a C "boolean" ? | 21:06.41 |
| sebras | vtorri: yes. | 21:07.07 |
| | vtorri: and the bitvalue when that particular permission is present. | 21:07.35 |
| vtorri | hmm | 21:08.09 |
| sebras | basicaly pdf_has_permission() does: return (!xref->crypt) ? 1 : (xref->crypt->p & p); as you can see in its implementation in pdf/pdf_crypt.c | 21:08.18 |
| | I made it a one-liner for the sake of irc... | 21:08.39 |
| vtorri | ok | 21:10.00 |
| | so i just havve to check if it's 0 or not (for me) | 21:10.11 |
| | i don't need the bit value | 21:10.24 |
| | ebp->page.page->list = fz_new_display_list(); | 21:10.49 |
| | dev = fz_new_list_device(ebp->page.page->list); | 21:10.50 |
| sebras | vtorri yup. you would do something like if (pdf_has_permission(xref, PDF_PERM_PRINT)) { print_document(...) }; | 21:11.01 |
| vtorri | it seems that, now, list is not available anymore | 21:11.05 |
| sebras | vtorri: I need a bit more context to help you. is the code your are fixing available on github or something similar? | 21:12.46 |
| vtorri | svn | 21:13.02 |
| | but the current modifications are in my hd right now | 21:13.11 |
| | i'm fixing the code | 21:13.16 |
| sebras | vtorri: yes, but I could at least see what the code used to look like. url? | 21:13.30 |
| vtorri | ebp->page.page->list = fz_new_display_list(); | 21:13.49 |
| | dev = fz_new_list_device(ebp->page.page->list); | 21:13.50 |
| | error = pdf_run_page(ebp->doc.xref, ebp->page.page, dev, fz_identity); | 21:13.52 |
| | it's for pdf_run_page | 21:14.01 |
| | sebras: is it sufficient ? | 21:16.53 |
| sebras | vtorri: ah, now I got it. you need to declare a variable of type fz_display_list * locally in your viewer. it used to be part of the pdf_page struct, but those two objects have been decoupled from each other. | 21:18.24 |
| | have a look at how apps/pdfapp.c::pdfapp_loadpage_pdf() has changed from app->page->list to app->past_list). | 21:19.23 |
| vtorri | list = fz_new_display_list(); | 21:19.35 |
| | dev = fz_new_list_device(list); | 21:19.44 |
| | error = pdf_run_page(ebp->doc.xref, ebp->page.page, dev, fz_identity); | 21:19.52 |
| | that ? | 21:19.56 |
| sebras | vtorri: mm, that seems correct to me. | 21:20.12 |
| vtorri | should I free the list after the pdf_run_page() call ? | 21:20.26 |
| | i guess so, with fz_free_display_list() | 21:22.29 |
| sebras | vtorri: that depends, if you are not going to use it again do call fz_free_display_list(). | 21:22.35 |
| vtorri | as i free dev, i think so | 21:22.57 |
| | yep, no need | 21:23.14 |
| | it's a code i haven't touched for more than a year | 21:23.25 |
| | it was based on mupdf 0.5 | 21:23.35 |
| sebras | vtorri: but if you may re-render the page again sometime you may keep the reference to the display list to skip re-interpretation of the page's content stream. | 21:23.35 |
| vtorri | hmmm | 21:23.44 |
| | the dev too ? | 21:23.49 |
| | indeed, i call it each time i change the page | 21:24.20 |
| sebras | vtorri: yes the device too. | 21:25.21 |
| vtorri | hop, new FIXME :) | 21:25.41 |
| | thanks | 21:25.43 |
| | it's not finished :) | 21:25.54 |
| sebras | vtorri: have a look at drawpage() in apps/pdfdraw.c it illustrates what you can do (consider e.g. the re-use of the list variable if showxml, showtext and showmd5 are all true). | 21:26.56 |
| vtorri | pdf_get_page_object() does not exist anymore too | 21:27.11 |
| sebras | vtorri: that is somewhat a contrieved example, but I hope that my point get's across. | 21:27.15 |
| vtorri | ok | 21:27.21 |
| | thanks | 21:27.23 |
| | it's for pdf_load_page() | 21:27.42 |
| | but i think the api has changed too | 21:27.52 |
| | yep | 21:28.26 |
| sebras | vtorri: what part of the API are you concerned about? | 21:28.31 |
| vtorri | i have to apss the page, now | 21:28.32 |
| | a lot of | 21:28.42 |
| | it's for a multi document lib | 21:28.51 |
| | mupdf is for pdf rendering | 21:29.01 |
| | so rendering, setting a page, getting informations about the document, the fonts, etc... | 21:29.28 |
| | zooming | 21:29.36 |
| | a lot of the api, i think | 21:30.02 |
| | sebras: i guess that page->text should be manages the same way than page->list, right ? | 21:30.51 |
| | managed* | 21:30.57 |
| sebras | vtorri: very likely. | 21:33.27 |
| | vtorri: yes, have a look at drawpage() in apps/pdfdraw.c in the block if (showtext) { ... } which illustrates what you should do. | 21:34.29 |
| vtorri | ok | 21:35.17 |
| | so now, i have to cache that list, text and dev stuff | 21:35.30 |
| | it's needed for fz_execute_display_list() i think | 21:35.46 |
| sebras | vtorri: yup. | 21:36.21 |
| vtorri | thanks for the help | 21:36.40 |
| | i don't think it remains a lot of problems, now | 21:37.02 |
| sebras | vtorri: basically the renderingen has been decoupled from the PDF parsing. so if you want to cache stuff for later re-use it is now obvious what piece of software should take care of freeing it. | 21:37.17 |
| vtorri | so faster rendering ? | 21:37.54 |
| sebras | vtorri: cool. you are working on that viewer called z-something, right? | 21:37.57 |
| vtorri | e-something :) | 21:38.09 |
| sebras | epdf? | 21:38.14 |
| vtorri | for the enlightenment project | 21:38.17 |
| sebras | ah. | 21:38.19 |
| vtorri | epdf was the first attemps | 21:38.28 |
| | butattempt* | 21:38.42 |
| | but now it's eyesight, certainly renamed as envision | 21:38.59 |
| sebras | sorry. :) then there is someone else that doing some other project named z-something (right now I can only think of zarathustra but I know that is wrong). | 21:39.08 |
| vtorri | as i said, it's a multi doc viewer | 21:39.10 |
| sebras | vtorri: right. | 21:39.17 |
| | vtorri: and through mupdf you get pdf/xps parsing/rendering. | 21:39.35 |
| vtorri | pdf, ps, dvi, images, etc... | 21:39.39 |
| | and now xps, indeed | 21:39.50 |
| | comic book too | 21:40.16 |
| | our rtf rendering lib is a bit rough | 21:40.28 |
| sebras | vtorri: regarding the faster rendering: well, if you keep the display list around for later when the user scrolls back then you need not call pdf_load_page() and pdf_run_page() again. | 21:40.41 |
| vtorri | ha ? | 21:41.09 |
| | i have to call pdf_load_page when i change the page, right ? | 21:42.13 |
| | pdfdraw is an example of use ? | 21:42.40 |
| sebras | vtorri: the first time you want to render the page, yes. | 21:43.29 |
| | vtorri: if you keep a cache of the display lists for the last 10 pages to be shown then you can skip calling pdf_load_page() and pdf_run_page() on later re-renderings if you wish. | 21:44.23 |
| | vtorri: or you could just cache the rendered bitmaps. | 21:44.50 |
| | vtorri: to the best of my knowledge at least. | 21:46.43 |
| | vtorri: tor8 knows these parts better than I do. | 21:47.06 |
| vtorri | adn waht should i call instead of pdf_load_page ? | 21:47.17 |
| | ok | 21:47.23 |
| | time to sleep | 21:48.47 |
| | thanks | 21:48.53 |
| | good night | 21:48.57 |
| sebras | vtorri: I believe that you could just call fz_execute_display_list().. | 21:49.01 |
| | vtorri: oki, good night. | 21:49.10 |
| | Forward 1 day (to 2011/10/23)>>> | |
IRC Logs