| | <<<Back 1 day (to 2019/05/13) | 20190514 |
| paulgardiner | ator: I've made a start on redaction. Seems to be working, other than I'm saving incrementally. pdf_can_be_saved_incrementally is returning true. Is that intended? Should I keep track of having applied redaction in the app? | 10:00.46 |
| | ator: I'm, so far, permitting only the selection of text to redact. Should I be also providing some way to redact images, or user-selected rectangular areas? | 10:02.01 |
| Robin_Watts | paulgardiner: text to redact is a good starting point. | 10:02.25 |
| | We haven't implemented redaction of images via redaction annotations yet. | 10:03.00 |
| | Ultimately though, we'll probably want to. | 10:03.32 |
| paulgardiner | Okay good. I wanted to make sure I was handling the current features | 10:03.54 |
| ator | paulgardiner: ah, I haven't considered pdf_can_be_saved_incrementally at all | 10:12.46 |
| | we should probably add a flag doc->has_redacted and set and check that flag. | 10:13.06 |
| paulgardiner | yeah. Makes sense | 10:27.45 |
| ator | Robin_Watts: okay, I've got it working quite well with progressive streams. now trying with curl and I get more problems :( | 10:41.14 |
| | mupdf-x11-curl: malloc.c:3760: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed. | 10:41.54 |
| | happened once, cannot reproduce it | 10:41.58 |
| | Attempt to take lock 0 when held already! | 10:42.07 |
| | pdfapp_more_data 0 | 10:42.07 |
| | error: cannot recognize version marker | 10:42.07 |
| | warning: trying to repair broken xref | 10:42.07 |
| | warning: repairing PDF document | 10:42.08 |
| | is a worrying sequence | 10:42.12 |
| | and sometimes it segfaults in I think the other background thread | 10:44.20 |
| Robin_Watts | ew. None of that is good. | 11:21.52 |
| ator | I'll have a look at the curl_stream, I suspect there are bugs in there | 11:26.08 |
| | is it possible to use curl single-threaded with non-blocking IO? | 11:26.33 |
| Robin_Watts | no idea. | 11:29.53 |
| | I had it working before with a slow http server, and it would properly fetch me bits of the file out of order so as to get me complete pages. | 11:30.50 |
| ator | Robin_Watts: yikes! curl is a nightmare to build :( | 15:29.50 |
| Robin_Watts | Don't try and comb the yak. | 15:30.15 |
| ator | I've got a new non-blocking CURL stream implemented, but it only works with my system curl, not the (ancient) curl in our thirdparty build. | 15:30.18 |
| Robin_Watts | ator: I have no problem with updating the curl thirdparty dir. | 15:30.47 |
| ator | Robin_Watts: curl without https support is going to be a bit useless... and adding https support to our makethird is going to require more curl_config.h surgery than I'm comfortable with | 15:40.55 |
| | personally, on Linux, I think we should just use the system curl if available, otherwise nothing. | 15:41.12 |
| | but then there's the question of what to do on windows... | 15:41.26 |
| Robin_Watts | ator: And for those of us who don't use linux? | 15:41.32 |
| | curl is only intended as an example. | 15:41.49 |
| | so http only seems fine to me using a thirdparty build. | 15:42.06 |
| ator | Robin_Watts: what I've got on tor/progressive seems to work pretty well on Linux (using system curl only) | 16:14.19 |
| | if you could patch that up to work on Windows, that'd be swell | 16:14.29 |
| | and when that works, maybe we can look into getting range fetches working too | 16:14.39 |
| Robin_Watts | ator: I will have a look. | 16:14.39 |
| | oh, we haven't got range fetches? | 16:14.52 |
| ator | I couldn't make heads or tails of the range fetching you wrote... | 16:14.55 |
| | and it kept crashing and having lock errors, so I used the curl_multi api to do non-blocking reads in a single thread | 16:15.11 |
| Robin_Watts | "I didn't understand it, so I deleted it". | 16:15.22 |
| ator | just to see if that would work | 16:15.23 |
| | I had to learn the curl api one way or another... :) | 16:15.56 |
| | if you want to debug your curl_stream.c implementation, I won't object. | 16:16.42 |
| Robin_Watts | I'm mired in cluster at the moment, so it won't be today. | 16:17.49 |
| | Forward 1 day (to 2019/05/15)>>> | |
Log of #mupdf at irc.freenode.net.