| <<<Back 1 day (to 2013/05/28) | 2013/05/29 |
ali | Hi.. How can i search specific text while using mupdf? what function in mupdf support that? | 04:59.28 |
Robin_Watts | ali: What platform? | 05:12.44 |
ali | x86,im using c# to call functions in mupdf (as .dll) | 05:14.14 |
Robin_Watts | ali: ok. | 05:18.18 |
| yes, there are searching functions at the API level. | 05:18.28 |
| Look at fitz/text_search.c for the code that does the searching. | 05:18.45 |
| Look at apps/pdfapp.c for example of code that calls it. | 05:19.00 |
| or android/jni/mupdf.c | 05:19.07 |
ali | thanks very much | 05:20.14 |
Robin_Watts | np. | 05:20.21 |
ali | fitz have not any file (text_search.c)!! | 05:42.13 |
| its include doc_search.c | 05:44.03 |
chrisl | tor8: there's a commit on my mupdf repo that adds a doc/thirdparty.txt file | 07:55.01 |
tor8 | chrisl: thanks. | 07:58.34 |
| Robin_Watts: several patches on tor/master | 08:02.30 |
kens | Isn't Robin off to the US today ? | 08:02.47 |
tor8 | oh yeah... | 08:02.53 |
| still early in the morning :) | 08:03.05 |
chrisl | That'll be why he was online at 06:12 this morning! | 08:03.12 |
tor8 | kens: feel like doing some mupdf code review duty? ;) | 08:03.14 |
kens | I wouldn't know where to start tor8 | 08:03.27 |
tor8 | it was mostly in jest :) | 08:04.58 |
kens | is relieved to hear it :-) | 08:05.15 |
tor8 | sebras: you will have to fill in for robin today! (or at least until paulgardiner gets in, he's not off to the us today is he?) | 08:06.31 |
kens | Not as far as I now | 08:08.16 |
| know | 08:08.20 |
ismail | Hi! | 09:50.32 |
| There is a small typo in Makethird file (mupdf.git) | 09:50.42 |
| $(BUILD) should $(build) (lowercase) | 09:50.58 |
| can someone fix it or shall I report a bug? | 09:51.22 |
tor8 | ismail: I'll fix it. | 10:12.26 |
ismail | tor8: thanks | 10:18.56 |
paulgardiner | tor8: ping | 10:19.09 |
tor8 | hi paul | 10:21.17 |
paulgardiner | Line 534 of pdf_repair.c | 10:21.42 |
tor8 | paulgardiner: which commit? | 10:21.58 |
paulgardiner | Unchanged source on orgin/master | 10:22.22 |
| Sometimes we enter here with xref->table[i].ofs >= xref->len | 10:23.00 |
| Should we throw an exception for that case too? | 10:23.26 |
tor8 | paulgardiner: yeah, that sounds like a good idea | 10:24.10 |
| but let me think it through twice first | 10:24.32 |
paulgardiner | Okay good. Just realised that I haven't checked that it does actually happen with unchanged source. I'll just check now. | 10:24.58 |
tor8 | the 'o' ofs should be the number of the object stream that was just loaded | 10:25.59 |
| so ofs being >= xref->len if 'o' is set should be impossible. hmm. | 10:26.48 |
paulgardiner | Let me just confirm it happens with unchanged source | 10:27.26 |
| len = 48 ofs = 610901 | 10:29.18 |
| i = 1 | 10:30.02 |
| All other values in the table entry look sensible | 10:30.41 |
| type = 'n' Everything else 0 or NULL, other than ofs | 10:31.08 |
tor8 | type 'n' means the offset is a file location | 10:31.20 |
| type 'o' means the offset is the object number of the containing ObjStm | 10:31.32 |
paulgardiner | Aaagh! Ignore me. I know what's happening | 10:31.54 |
tor8 | typo 'f' means the offset is the object number of the next 'f' slot in the xref (but we don't rely on it) | 10:31.59 |
| okay. ignoring now :) | 10:32.23 |
| paulgardiner: when you have a moment, could you give the commits on tor/master a review? | 10:32.37 |
| mostly build stuff and some warning fixes | 10:32.43 |
paulgardiner | Sure | 10:32.48 |
| tor8: third one: why if (image_part) after if (!image_part) throw? Is that to shut up the compiler? | 11:18.52 |
| Oh. It's image_part and image_name | 11:22.56 |
tor8 | right. | 11:30.29 |
paulgardiner | tor8: your commits all look okay, although I wouldn't like to claim to have followed everything you do in the one that tidies the thridparty make files | 11:39.14 |
tor8 | paulgardiner: thanks. sebras got a walk through of the make file changes yesterday, so they should be okay. | 11:39.59 |
| I'll push these, then you can proceed with openssl at your leisure. I'll leave the win32 project file setup for it to you and robin though! | 11:40.32 |
paulgardiner | Great thanks | 11:40.59 |
sebras | tor8: I'm not sure I can be blamed for any errors still left though. ;) | 11:44.27 |
paulgardiner | tor8: I updated my xref-interface commits to address Robin_Watts's concern about function calls in for-loop tests. I didn't get a definitive answer as to whether pdf_xref_obj was needed, but I'd have thought it was harmless to add it for now and remove it later. Did you have other qualms | 11:45.10 |
| http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=summary | 11:45.47 |
tor8 | paulgardiner: regarding pdf_xref_obj, wouldn't that work as well by pdf_get_xref_entry()->obj ? | 11:50.29 |
paulgardiner | Ah yes. That would be better | 11:51.01 |
| I'll update | 11:51.06 |
tor8 | paulgardiner: though I think it should be safe to just call pdf_load_object instead | 11:52.05 |
| but I'm afraid to say for certain, the renumbering code has been unfortunately fragile in the past | 11:52.59 |
paulgardiner | Lets leave it for now | 11:53.29 |
tor8 | pdf_resolve_indirect can lead to a pdf_load_object call itself, which does give me a bit more confidence | 11:53.44 |
| I think the current (tabse[num].obj) only works because we've pre-loaded all the objects in a previous step | 11:54.46 |
paulgardiner | Updated and pushed to my repo | 11:58.17 |
tor8 | now there's only the question of the "get" name :) | 12:03.08 |
paulgardiner | We do it elsewhere when the type and accessor conflict | 12:04.09 |
| Just rebased them past the ones you just committed now | 12:04.29 |
tor8 | paulgardiner: grepping through the source I see we've been somewhat less than consistent there | 12:05.25 |
| pdf_get_xref_entry or pdf_xref_get_entry would both be valid choices here | 12:05.55 |
| the former (get_xref_entry) fits better with the general "verb_noun" naming | 12:06.28 |
paulgardiner | I'm easy. | 12:06.37 |
tor8 | if you're happy then I will push your changes | 12:07.47 |
paulgardiner | Yeah great thanks | 12:08.09 |
tor8 | just running them through sane now | 12:08.17 |
paulgardiner | Oh yes. I haven't run your script yet | 12:08.49 |
tor8 | btw, if you're on linux, using "clang" instead of "gcc" will silence the "may be used unitinialized" warnings that try/always/catch confuse gcc with | 12:09.00 |
| 0 files changed. | 12:09.08 |
| pushed. | 12:09.55 |
paulgardiner | ta | 12:10.45 |
tor8 | paulgardiner: some documentation files about naming and reference counting on tor/master | 12:42.22 |
paulgardiner | tor8: both look fine | 12:45.57 |
tor8 | paulgardiner: thanks. | 12:46.41 |
alexcher | kens: What do you know about zero-escape in pdf_scan_token ? We have a file with zero characters in names. | 13:03.11 |
kens | alexcher I'mlooking at it.THe problem is the named destination is a unicode (16BE) name and we don't permit NULLs in our cvs routines | 13:03.47 |
alexcher | OK | 13:04.20 |
tor8 | paulgardiner: in your git command line shell whatever you use, you can run "bash scripts/gitsetup.sh" to install the whitespace fixing hooks that I committed yesterday. | 13:19.06 |
| that adds an alias "git wsfix" as well to fix your current workspace diffs | 13:19.34 |
paulgardiner | Will that affect all repos or just mupdf? | 13:20.01 |
tor8 | only mupdf | 13:20.11 |
paulgardiner | Excellent | 13:20.16 |
| Done | 13:20.56 |
tor8 | the same hook and alias could be added to ghostpdl or any other repo, but really wants some .gitattribute configuration to set the desired whitespace settings | 13:21.05 |
| the default just strips trailing whitespace | 13:21.14 |
sebras | tor8: so no automagic installation of the git aliases when doing make..? | 13:39.14 |
kens | alexcher there isn't any obvious way for us to handle this problem file. We convert all named destinations into name objects, because we don't build a Names tree, and so cannot handle named destinations whose destination is a string. Names cannot contain Unicode values in PDF (unlike PostScript) so we can't take the Unicode name and use it directly as a name. | 13:59.58 |
| The best we could do I think is to ignore the offending named destination. | 14:00.17 |
| alexcher, if you have any ideas about this I'd be interested.... | 14:01.08 |
alexcher | kens: why #XX convention can't be used? | 14:16.50 |
kens | alexcher, hmmm... that works for things like spaces, does it work for NULLs ? | 14:17.26 |
| and would the result still be UTF-16BE ? | 14:17.41 |
alexcher | kens: #00, the result is a byte string | 14:18.19 |
kens | alewxcher, we cannot use byte strings | 14:18.37 |
| the Dest for a named destination must be a name object or a string, if its a string it must have an entry in the names table, which we do not construct | 14:19.10 |
| SO we could use a #00 in the name, but I'm not certain if the named destination *name* is actually visible anywhere in the document | 14:19.50 |
alexcher | kens: This depends on the viewer. I don't remember what AR does. | 14:22.34 |
kens | alexcher I can't seem to sfind any way of seeing teh named destinations, in fact I can't actually find any at present, but its a 7 page file so that's not perhaps surprising. I *think* they are links to the bibilography (hence bib1, bib2...) | 14:23.33 |
| Yes, just found one. | 14:23.54 |
| I don't believe Acrobat displays these names, I guess altering them to use the #xx syntax might be better than nothing. Is there an established method for doing that in the PDF interpreter ? | 14:27.16 |
alexcher | kens: No, PDF interpreter does it the other way. | 14:29.47 |
kens | Ah, that makes sense I guess. Hmm, have to think about it.... | 14:30.02 |
| Hmm, alexcher in pdf_put_name_chars_1_2 there's a comment that says : " Since we only support | 14:47.49 |
| * PDF 1.2 and above, we can use an escape sequence for anything except a | 14:47.49 |
| * null <00>" | 14:47.49 |
| Canyou think of a good reason why we can't use 00 for a Null ? | 14:48.07 |
| Aha, page 57 of the 1.7 PDF Reference Manual: "Beginning with PDF 1.2, any character except null (character code 0) may be included in a name" | 14:51.37 |
| So, we can't use the #xx escape | 14:52.02 |
| OK we already have a hack to deal with this, we replace the NULLs with an arbitrary string. This 'seems' to work adequately well. | 14:56.05 |
sebras | https://play.google.com/store/apps/details?id=com.foobnix.pdf.reader | 20:22.52 |
| appears based on ebookdroid sources (which are based on vudroid which is based on mupdf) | 20:23.20 |
| there is a libebookdroid.so binary in the apk | 20:23.35 |
| it is linked to from dropbox: https://www.dropbox.com/sh/4nhbem9fcgycq5a/6RYw21KpSr | 20:23.49 |
| and this binary contains mupdf symbols. | 20:24.04 |
| I can not find the source on his website. | 20:24.11 |
| also there is a link to a commercial version of the reader here: https://play.google.com/store/apps/details?id=com.foobnix.pro.pdf.reader | 20:24.31 |
| there is also this one: https://play.google.com/store/apps/details?id=com.rookiestudio.perfectviewer with the pdf-plugin https://play.google.com/store/apps/details?id=com.rookiestudio.perfectviewer.pdfplugin&feature=more_from_developer | 20:39.58 |
| the pdf plugins is advertised as GPLv3 and the source is here: http://code.google.com/p/perfect-viewer-pdf-plugin/ | 20:40.21 |
| I'm not sure how artifex views GP | 20:40.37 |
| GPL but the main app is also available as donation-ware | 20:41.07 |
| and on the main app's download page you can also find the binary-only PDFPlugin with a paypay donate-button next to it: https://sites.google.com/site/rookiestudio/xia-zai | 20:41.39 |
| there is also this free pdf viewer plugin: https://play.google.com/store/apps/details?id=com.anttek.explorer.pdfviewerplugin | 20:47.48 |
| which contains mupdf symbols in libvudroid.jpg(!) | 20:48.01 |
| it is not advertised to be gpl | 20:48.11 |
| they also have a main app https://play.google.com/store/apps/details?id=com.anttek.explorer | 20:49.03 |
| which has a pay-for-it pro-version: https://play.google.com/store/apps/details?id=com.anttek.explorer.keyapp | 20:49.29 |
| https://play.google.com/store/apps/details?id=sahityachintan.android.pdfview claims to have mupdf in it, and this is true. however while it is free it never mentions being under gpl or where the source code is located. | 20:54.24 |
| oh, I found links to mupdf.com on the about-page of the app. sorry for the noise. :) | 20:55.50 |
| https://play.google.com/store/apps/details?id=com.lrmobilabs.pdfreader is free, does not mention GPL and has mupdf symbols in it. I can't find the source. and the about-screen doesn't say anything about GPL either. | 20:59.39 |
| of course any of these might be using mupdf under a commercial license, but I'm not aware of it. | 21:02.17 |
robin_watts_mac | got PCL output working from mupdf on the plane. | 21:37.56 |
| Mono only for now, but it copes with all the vagaries of the gs devices, duplex, media selection etc. | 21:38.28 |
| Various commits, including the PCL one on robin master for tor8, paulgardiner, sebras, and anyone else interested to look at. | 21:45.05 |
sebras | robin_watts_mac: why is it imporant to adhere to api-7 instead of api-8? | 22:59.43 |
| robin_watts_mac: oh, and you have not been running tor8's whitespace script... | 23:00.22 |
| robin_watts_mac: how about separating out fz_pixmap_set_resolution() into a separate patch? is there other reasons for having it besides pcl? | 23:02.37 |
| robin_watts_mac: the foreach-patch... I gues it's meant to make to code easier to read, but is it really? it hides how things work..? | 23:10.22 |
| moreover it removes 44 lines of code and inserts 53 lines, so it actually increases the code size..? | 23:10.48 |
| I'm not smart enough to get what is really happening in get_subdiv_level_for_patch(). | 23:13.59 |
| or I shouldn't be trying at 1am... | 23:14.16 |
| Forward 1 day (to 2013/05/30)>>> | |