| | <<<Back 1 day (to 2013/07/03) | 2013/07/04 |
| mvrhel_laptop | henrys: your around? | 03:17.25 |
| | or Robin_Watts ... | 03:17.41 |
| | marcows_ are you there? | 04:15.59 |
| | marcosw_ ^^ | 04:16.11 |
| | or marcos .. | 04:16.27 |
| marcosw_ | mvrhel_laptop: yes, but I'm in the eastern time zone, so it's a bit late :-) | 04:16.34 |
| mvrhel_laptop | me too | 04:16.39 |
| | :) | 04:16.41 |
| | 12:16 here | 04:16.47 |
| | quick question for you | 04:16.51 |
| | so the dumb microsoft store rejected the viewer app since they did not like my support contact information, for which I had put the bugzilla website | 04:17.29 |
| | they want a support email address. | 04:17.35 |
| | do we really want to put our support email address in there? | 04:17.55 |
| | do we want to make another "support" email address? | 04:18.13 |
| | perhaps only a few people will ever download and use the thing. who knows. I just don't want there to be any problems since the address will be shown on the windows store. I do have a mupdf@live.com address that I am using for the developer account . Perhaps I should just use this | 04:20.51 |
| | hmmm. maybe marcosw has fallen asleep at keyboard... | 04:21.28 |
| | ok. I will bother someone about this at a more reasonable time. good night marcosw_ | 04:26.09 |
| marcosw_ | mvrhel_laptop: sorry, had to run out for a second. | 04:26.29 |
| mvrhel_laptop | oh no worry | 04:26.37 |
| marcosw_ | I think we should make a different email address. | 04:26.56 |
| mvrhel_laptop | I was just wondering if we wanted to make something like a mupdf@artifex.com or something | 04:27.05 |
| | for this sort of thing | 04:27.16 |
| marcosw_ | what's the windows phone called? I.e. can we make it the equiv of androidsupport@artifex.com | 04:27.53 |
| mvrhel_laptop | we can do win8support@artifex.com | 04:28.38 |
| | that would cover phone store app and win 8 store app | 04:29.03 |
| | can you add that? | 04:29.28 |
| marcosw_ | sound perfect. Shall I forward the emails to you directory or to support? | 04:29.29 |
| mvrhel_laptop | go ahead and send them to me | 04:29.40 |
| | if it get too much then we can figure something else out | 04:30.03 |
| | how long before this becomes live? | 04:30.24 |
| marcosw_ | should be few minutes, if I can figure out the new Google web site... | 04:31.42 |
| mvrhel_laptop | oh great. then I can resubmit this thing tonight | 04:31.57 |
| | and then wait another 5 days.... | 04:32.10 |
| | marcosw_: thanks. have a great 4th and sorry to bug you so late | 04:37.37 |
| marcosw_ | mvrhel_laptop: no problem, you too. I'll send you email when it's set up. | 04:37.55 |
| mvrhel_laptop | ok thanks | 04:38.01 |
| chrisl | kens2: ping | 07:37.57 |
| kens2 | chrisl pong (was fetching coffee) | 07:47.54 |
| chrisl | kens2: np, Do you know what combination of user access flags adds up to "page extraction disallowed in PDF"? | 07:48.51 |
| kens2 | No, why ? Are you looking at that SO question ? | 07:49.06 |
| chrisl | No, this is a guy that contacted me through sourcrforge - could be same guy, says GS freezing/crashing (description varies!) with that PDFs with that setting | 07:50.21 |
| kens2 | SOunds like a different thing, the SO one wanted to use GS to add password security to an existing PDF | 07:50.50 |
| kens | Network keeps dropping out..... | 07:52.27 |
| | Table 3.20 has hte permissions bts | 07:52.35 |
| | p 124 of teh 1.7 PDFRM | 07:52.49 |
| chrisl | Yes, found that, none match what I would term "page extraction" - maybe bit 12? | 07:53.19 |
| kens | Just a moment, I have a file exntrypted that way here | 07:53.36 |
| | "/P is -4" | 07:54.10 |
| chrisl | Okay, thanks - I'll have a play.... | 07:55.13 |
| kens | NP | 07:55.48 |
| | -4 bits 1 & 2 are 0, all other bits are set to 1 | 07:56.06 |
| chrisl | Ta | 07:56.23 |
| kens | WHich by my reading of the spec means evertyhing is permitted | 07:56.23 |
| chrisl | Hmm, even Acrobat doesn't list "page extraction" | 07:57.39 |
| | Oh, yes it does.... | 07:57.56 |
| kens | As a paramter that can be set ? | 07:57.59 |
| | Hmm, seems I have the owner password wrong for my file | 07:58.50 |
| chrisl | Acrobat lists page extraction in the list of parameters set for the file, but doesn't seem to list it in the options to set :-( | 07:59.37 |
| kens | Yep | 07:59.43 |
| | It look slike if a document is secured *at all* you can't do page extraction | 08:00.02 |
| chrisl | Sounds good. | 08:00.26 |
| kens | Yes the 'changes allowed' the most liberal is 'any except extracting pages' | 08:01.35 |
| | It sort of makes sense, there' no real point in protecting the document with a password, and then letting you do anything you like with it | 08:02.15 |
| | But it would be good if this was explicitly stated in the documentation | 08:02.30 |
| chrisl | It would be nice, also, if Acrobat was a bit clearer - but, hey, this is Adobe...... | 08:03.07 |
| | Well, Ghostcript works just fine on a file like that for me. | 08:04.01 |
| kens | Yes, I would expect it to, its known to work with encrypted files, some of our test suite are enmcrypted I believe | 08:04.25 |
| | If the SourceForge user has an example file, we'll look at it if he raises a bug report | 08:04.55 |
| chrisl | Ah, well, this is the usual: "I have this problem, but I can't share the file" bullsh*t | 08:05.28 |
| kens | In that case my response is "I can't help you then" | 08:05.51 |
| | He needs to make a file he can share, or get permission to share the file | 08:06.13 |
| chrisl | Previously, he asked me what his options were, so I said "debug it yourself" | 08:06.40 |
| kens | Like I sadi, he can find/make a file that goes wrong he can share, he can get permission to share it or, yes, he can debug it himself, its open source after all. | 08:07.23 |
| | We don;t do debugging by psychics | 08:07.44 |
| chrisl | Okay, I have communicated those sentiments to the gentleman, and I await the stroppy reply..... | 08:12.48 |
| kens | No doubt :-( | 08:13.04 |
| chrisl | I was tempted to also say that when I said "debug it yourself" that didn't mean "describe the file(s) to me"! | 08:13.45 |
| kens | describing a PDF file sounds like lots of fun :-) | 08:14.05 |
| chrisl | He just said about the security settings, but clearly, that's not much help. | 08:14.45 |
| kens | No help at all..... | 08:14.57 |
| | Have you ever managed to get IdiomRecognition working in Ghostscript ? | 08:15.14 |
| chrisl | I've never tried, tbh. Every time I mention it, Alex and Ray seemed to shiver - I got the idea it's basically verbotten | 08:16.21 |
| kens | Well its the only way to 'fix' this particular problem, and Alex has always seemed quite keen on writing them | 08:16.50 |
| | But I can't get it to work | 08:16.58 |
| chrisl | IIRC, there's a command line parameter to enable it? | 08:17.32 |
| kens | I don't think so, you can disable it with setuserparams | 08:17.44 |
| | If it wasn't enabled it wouldn't be throwing me an 'undefinedresource in findresource' error I would think | 08:18.03 |
| chrisl | Hmm, I thought we disabled it because it hurt performance | 08:18.50 |
| kens | I think I;d heard that too (though I'm inclined to feel it should be fixed in that case) | 08:19.22 |
| chrisl | IIRC, it's because we don't keep the idioms in VM, so every time we do a bind we have to reload the idiom resources | 08:20.09 |
| kens | Like I said 'should be fixed'.... | 08:20.22 |
| chrisl | Hmm, but user params has IdiomRecognition "true", so | 08:21.05 |
| kens | So it is enabled | 08:21.18 |
| chrisl | Well, it is enabled in currentuserparams, that doesn't mean it isn't disabled in some other way! | 08:21.53 |
| kens | Yes I guess oso. Being broken seems to be one way. | 08:22.20 |
| chrisl | Hmm, I see it being set to false, I wonder it gets set to true...... | 08:25.18 |
| kens | No idea.... | 08:25.27 |
| chrisl | It's set to false at the beginning of gs_ll3.ps - which makes sense | 08:25.51 |
| kens | My idiom is pretty simple: | 08:25.52 |
| | currentuserparams /IdiomRecognition get | 08:26.10 |
| | <</IdiomRecognition false>> setuserparams | 08:26.10 |
| | << | 08:26.10 |
| | {1 add} | 08:26.10 |
| | {(Detected idiom) == flush} | 08:26.10 |
| | ] | 08:26.11 |
| | >> | 08:26.11 |
| | <</IdiomRecognition 3 -1 roll >> setuserparams | 08:26.12 |
| | Ooops that cut off all the lines beginning with / | 08:26.33 |
| | "currentuserparams /IdiomRecognition get | 08:26.54 |
| | "<</IdiomRecognition false>> setuserparams | 08:26.54 |
| | " | 08:26.54 |
| | "/PScript5 | 08:26.54 |
| | "<< | 08:26.54 |
| | "/test [ | 08:26.54 |
| | "{1 add} | 08:26.54 |
| | "{(Detected idiom) == flush} | 08:26.55 |
| | "] | 08:26.55 |
| | ">> | 08:26.56 |
| | "/IdiomSet defineresource pop | 08:26.56 |
| | " | 08:26.57 |
| | Then I have a test file : | 08:27.38 |
| | "%! | 08:27.39 |
| | "(*) {==} 256 string /IdiomSet resourceforall | 08:27.39 |
| | " | 08:27.39 |
| | "<</IdiomRecognition true>> setuserparams | 08:27.39 |
| | " | 08:27.39 |
| | "/test {1 add} bind def | 08:27.39 |
| | " | 08:27.40 |
| | "1 test == | 08:27.40 |
| | And that thrwos me an undefined resource in findresource | 08:27.58 |
| | findresource is (of course) written in PostScript | 08:28.17 |
| chrisl | Does that happen when it's called from /.bind_? | 08:28.43 |
| kens | I'm not sure | 08:28.58 |
| chrisl | Ah, so it looks like we only disable idiom recognition during ".bindnow" for performance reasons | 08:32.41 |
| kens | I guess that's possible. | 08:32.52 |
| | What's our interpretation of dynamic linking wrt GPL ? | 08:33.05 |
| chrisl | I guess if you use the DLL or the .so that's dynamic linking - but I don't think that is relevant with GPL3. | 08:34.11 |
| kens | Using the DLL is what this loon is doing, do we regard that as legit under GPL3 or not ? | 08:34.39 |
| chrisl | I'd need to read the license again :-( | 08:34.58 |
| kens | Oh :-( | 08:35.04 |
| | I hoped you would remember, I certainly don't..... | 08:35.14 |
| chrisl | kens: if you look at doc/COPYING line 122 is the relevant part, I think | 08:36.39 |
| kens | OK just a moment | 08:36.48 |
| | So they have to publish a link to the GS sources it would appear | 08:38.30 |
| chrisl | Yes, I don't think there is any way we could be classified under the "standard interface" or "system libraries" sections | 08:39.34 |
| kens | No, certainly not on Windows :-) | 08:39.49 |
| | OK gentle reminder in bug thread. | 08:41.37 |
| chrisl | kens: are you looking at 691209? | 08:48.52 |
| kens | Not at the moment, I'm looking at 688007 | 08:49.15 |
| | Oooh, seems I got idiomrecognition to work back then.... | 08:49.59 |
| chrisl | Yes, it came up on a google search - but I just noticed it's closed | 08:50.32 |
| kens | Yes, because its not really a bug :-) | 08:50.44 |
| | And we supplied an IdiomSet to fix the problem for the user. | 08:51.10 |
| chrisl | Yeh, it was also that you sort of describe how to use it, which I assume is what you're doing now | 08:51.59 |
| kens | I'll get that IdiomSet and test it though, to make sure that the Idiom stuff still works | 08:52.03 |
| chrisl | If it's broken, let me know, and I'll bisect it - it's probably quicker for me | 08:52.36 |
| kens | Give me a few minutes, need to rejig stuff | 08:53.04 |
| | OK Idiom installed, now to test | 08:54.56 |
| | No errors, which is a good thing | 08:55.16 |
| | Don't know if it actually did anything though :-) | 08:55.41 |
| | And I think I see where I was going wrong | 08:57.15 |
| | yeah its working just fine chrisl | 08:58.00 |
| chrisl | Well, that's good | 08:58.41 |
| kens | I think I simply forgot to 'bind' the procedures in the IdiomSet definition | 08:58.43 |
| | Trying to do too many jobs at once, and doing them all badly | 08:59.03 |
| chrisl | Know the feeling..... | 08:59.36 |
| Robin_Watts | tor8: ping ? | 09:06.19 |
| | tor8: Are you happy with sebras debian changes? | 09:07.08 |
| sebras | Robin_Watts: I guess not... ;) | 09:23.05 |
| | but he might be once he's rebooted. | 09:23.35 |
| | tor8: tre.se..? no internet today? | 09:33.04 |
| | tor8: and as Robin said, are you happy with my debian changes? | 09:33.30 |
| tor8 | internet troubles... | 09:34.23 |
| Robin_Watts | tor8: Presumably you still have ridiculously fast fibre to the new place? | 11:20.17 |
| paulgardiner | Robin_Watts: updated incremental-save commit on paul/incremental-save. Also have your annotations commit on that branch, which looks good, | 11:33.07 |
| Robin_Watts | Thanks. | 11:33.19 |
| | paulgardiner: OK. I'm still confused. | 11:40.52 |
| | Where do you set use_list ? | 11:41.04 |
| | Hmm. ObjStm and XRef objects have their use_list entry set to 0. Maybe that's it. | 11:44.14 |
| | Pushed | 11:47.26 |
| paulgardiner | Robin_Watts: Line 1911 of pdf-write.c is, I think, where use_list[num] gets zeroed | 12:02.29 |
| Robin_Watts | fair enough., | 12:03.20 |
| paulgardiner | Ta for push | 12:06.18 |
| sebras | Robin_Watts: I think he has 100Mbit/100Mbit. but 1GBit/1Gbit didn't look too expensive... | 12:41.11 |
| Robin_Watts | sebras: Either of those count as ridiculously fast fibre as far as I am concerned :) | 12:42.02 |
| sebras | Robin_Watts: what city did you live in again..? | 12:42.44 |
| Robin_Watts | I *used* to live in Oxford. But I haven't lived in a city for 15+ years now. | 12:43.21 |
| sebras | Robin_Watts: ok, but it's nearby..? | 12:43.48 |
| Robin_Watts | 25+ miles. | 12:43.59 |
| sebras | Robin_Watts: hm, I have a suggestion then. you need about 1400km of CAT-5 cable... | 12:44.54 |
| Robin_Watts | Chipping Norton has 21CN and FTTC available. | 12:45.35 |
| | 3184 residential/289 non-residential users on that exchange. | 12:46.42 |
| | Hook Norton has neither of those. 1224/94 - so we're a much smaller exchange. | 12:47.05 |
| | Woodstock (where paul is) has 21CN, but not FTTC. 2094/119 | 12:47.45 |
| | so if we can double the size of the village, we might get faster ADSL :) | 12:48.03 |
| | Hmm. My cunning plan for how to work with byte range requests has fallen at the first hurdle. | 12:50.58 |
| | Unless we read the hint stream, we can't know where to fetch from. | 12:51.17 |
| kens | well, no, that's what its for surely ? | 12:51.56 |
| Robin_Watts | kens: right. | 12:52.04 |
| | but chrome's behaviour on download doesn't appear to change whether I nobble the hint stream or not. | 12:52.29 |
| kens | Though I agree with the comments the other day that the spec for linearisation is bonkers, I doubt it was written by an intern though, its not good enough.... | 12:52.56 |
| | Robin_Watts : then whatever cunning method its using, its not linearistaion it sounds like | 12:53.18 |
| Robin_Watts | I believe it is relying on linearisation. | 12:53.39 |
| sebras | kens: :) | 12:53.40 |
| kens | Is there a way to determine the size of a PDF file from the server ? | 12:53.41 |
| Robin_Watts | kens: Yes. | 12:53.49 |
| sebras | Robin_Watts: is that really true? | 12:53.59 |
| kens | If so you could read teh last few kbytes and look for a real xref, then use that | 12:54.00 |
| Robin_Watts | When you do a request you get Content-Length | 12:54.05 |
| | kens: yeah. | 12:54.09 |
| sebras | Robin_Watts: isn't Content-Length optional? | 12:54.10 |
| | Robin_Watts: and what about non-http protocols? | 12:54.17 |
| kens | I don't think we're worried about progressive viewing on non-http protocols are we ? | 12:54.37 |
| Robin_Watts | sebras: Right, so you send an http Range request for the first few bytes of a file. | 12:54.57 |
| | If the server doesn't support range requests, you get the whole file, and tough. | 12:55.13 |
| | If it does you'll get enough for the header, plus an indication of the whole length. | 12:55.33 |
| | as you can't realistically support range requests without supporting Content-Length | 12:55.53 |
| kens | So you have gracefull fallback capability, if it s linearised, read teh hint stream. If that fails (or it snot linearised) read the eof looking for the xref | 12:56.45 |
| | well, the startxref | 12:57.00 |
| Robin_Watts | so actually, you're right. If you have access to byte requests, ignore linearisation. | 12:57.03 |
| kens | Robin_Watts : indeed | 12:57.11 |
| | and if you don;t have byte requests, tehn there is little point.... | 12:57.21 |
| Robin_Watts | I will ponder this more over lunch. Thanks ken. | 12:57.23 |
| kens | So what is the point of linearisation again ? :-) | 12:57.36 |
| sebras | kens: :) | 12:57.47 |
| | kens: 14k4 modems perhaps? | 12:58.00 |
| kens | sebras I guess maybe..... | 12:58.13 |
| | The spec was written 10 years ago I think, maybe more | 12:58.35 |
| tor8 | sebras: your debian fixes look reasonable | 13:01.08 |
| | I see you're taking the manfiles from the intall directory now rather than the originals | 13:01.35 |
| sebras | tor8: yes, it was difficult to fetch files from above the platform directory. | 13:02.14 |
| | at least to have debhelper do that for me. this is why I did this little dance with README. | 13:02.36 |
| tor8 | where does the readme end up in the destination? | 13:03.46 |
| sebras | tor8: /usr/share/doc/mupdf | 13:04.02 |
| | tor8: that's was my intent at least. this is also how other debian packages do it. | 13:04.31 |
| tor8 | sebras: could add it to "make install" | 13:04.37 |
| sebras | tor8: this is also where copyright gets copied. | 13:04.45 |
| tor8 | and put all the text files in docs/ there too | 13:04.46 |
| sebras | tor8: if you do that, then I'll rebase my patch (and simplify it). | 13:05.01 |
| Robin_Watts | tor8, sebras, paulgardiner: New version of the progressive commit online. | 14:38.30 |
| | Biggest change is the new section at the end of this: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=blob;f=docs/progressive.txt;h=4b0e82f4f23cd59650ec1a5ca7e7c3dcab5f8202;hb=63fbc865600478ab7cc54f14709aaa7dc7369b6d | 14:39.06 |
| | Feedback from anyone (mupdfers or not) as to whether that sounds reasonable or not would be appreciated. | 14:39.38 |
| kens | "Adobe defines a specific layout for files together a small amount of extra information that can be used to facilitate this" | 14:41.22 |
| | is grammatically wrong somehow | 14:41.22 |
| Robin_Watts | yeah. let me try rejiging it. | 14:42.17 |
| kens | I couyldn't think of a correct sentence, I htink I'm tired | 14:42.36 |
| | The rest seems to make sense, but I may not be grokking it very well | 14:43.45 |
| sebras | Robin_Watts: I'll have a look when I get home. | 14:43.59 |
| Robin_Watts | Adobe defines "linearized" PDFs as being ones that have both a | 14:44.04 |
| | specific layout of objects and have a small amount of extra | 14:44.06 |
| | information to help avoid seeking within a file. | 14:44.08 |
| kens | Yes that sounds good | 14:44.16 |
| Robin_Watts | I need to lose the second "have" | 14:45.17 |
| | tor8: ping? | 15:04.03 |
| ray_laptop | hi, all. | 15:04.45 |
| Robin_Watts | morning ray_laptop | 15:05.05 |
| ray_laptop | On holiday here and I'm awake, but the family's asleep | 15:05.07 |
| Robin_Watts | Fixed version of the text: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=blob;f=docs/progressive.txt;h=c57e327b790e095a3dd1f80d04c316c3189c3d88;hb=edee7ff5e9c623a2118587ee47f28c618ee93199 | 15:05.48 |
| | ray_laptop: If you're bored, I'd be interested in any thoughts you have on the above. But do have a holiday :) | 15:06.15 |
| ray_laptop | I saw about linearization above. One point of it that we tried to promote was using it for limited memory printer 'streaming', but it doesn't quite have everything needed for that | 15:06.35 |
| | Robin_Watts: looking at it... | 15:06.50 |
| Robin_Watts | ray_laptop: The fact that shared objects are sent after all the pages ruins that :( | 15:07.31 |
| ray_laptop | Robin_Watts: first, Adobe also calls "linearized" "Web Optimized" so that might be worth mentioning | 15:07.36 |
| Robin_Watts | true. | 15:07.46 |
| kens | 'Optimized for fast web view' | 15:07.49 |
| ray_laptop | Robin_Watts: well, shared objects don't HAVE to be sent after the pages. It's just that the spec doesn't require it. Artifex wrote up a variation /Linearized 2 that would be streamable | 15:08.45 |
| Robin_Watts | ray_laptop: The spec specifically says that they have to be sent after the pages. | 15:09.13 |
| | Otherwise the shared object hint table can't work. | 15:09.37 |
| kens | correct | 15:09.43 |
| Robin_Watts | (Not that anyone ever uses it) | 15:09.43 |
| ray_laptop | which was a variant that provided for requiring resources before use, and special hacks to allow discarding objects once no longer reused | 15:09.52 |
| | I never dug into the hints table. | 15:10.24 |
| Robin_Watts | ray_laptop: You're SO lucky. | 15:10.38 |
| kens | Its the whole point of the spec | 15:10.40 |
| | well mostly | 15:10.45 |
| ray_laptop | Robin_Watts: continuing to read your doc... | 15:11.12 |
| | Robin_Watts: I don't understand why the byte-code-range fetching isn't buried in the fz_stream. The stream for an http: doc has to be unique, doesn't it ? | 15:15.48 |
| Robin_Watts | The proposal is that the byte-range fetching IS buried in the stream. | 15:16.21 |
| | The only essential change to the way mupdf works now is that we support 'TRYLATER'. | 15:16.57 |
| | Suppose I make a call to MuPDF to display a page. | 15:17.09 |
| | That will call down to the stream to fetch data. | 15:17.21 |
| | If we hit a need for some data that we don't have, what should we do? | 15:17.38 |
| | Option 1) The stream could block until the data arrives. | 15:17.52 |
| ray_laptop | Robin_Watts: OK, so that is only relevant for a linearized file that is being provided by a server that doesn't support byte ranges (FZ_TRYLATER) ? | 15:17.57 |
| Robin_Watts | Option 2) It can say "try later" and the caller can retry later. | 15:18.16 |
| | If it blocks, then it means that you can't make any other calls to MuPDF until it unblocks. | 15:18.37 |
| | Which might not be what you want. For instance in a viewer I might have pages 1-10 loaded already, and might try to load page 11. | 15:19.07 |
| ray_laptop | Robin_Watts: will it ever return TRYLATER if byte ranges are supported ? | 15:19.11 |
| Robin_Watts | if page 11 is going to take a while, I still want to be able to flick back to pages 1-10 and reread them. | 15:19.34 |
| | ray_laptop: the only thing that returns TRYLATER is the stream code (i.e. the code that the caller implements). | 15:20.04 |
| | And yes, it is free to return TRYLATER in the case of using byte ranges. | 15:20.23 |
| | In fact I would expect it to. | 15:20.25 |
| ray_laptop | Robin_Watts: so we aren't going to provide this (generally useful) stream code ? | 15:20.45 |
| Robin_Watts | ray_laptop: You want us to write an http fetcher ? | 15:21.05 |
| ray_laptop | Robin_Watts: if so, I would expect for the app to have some control over the stream -- how are stream params set ? | 15:22.03 |
| Robin_Watts | Urm.. the 'stream code' is provided by the 'app' to the mupdf library when it opens the file. | 15:22.42 |
| | hence the app and the stream code can communicate however they want. | 15:22.56 |
| | Or am I misunderstanding you? | 15:23.02 |
| ray_laptop | Robin_Watts: like setting the timeout for the blocking for max wait before timeout | 15:23.03 |
| | Robin_Watts: so the http fz_stream is an instance of a fz_stream that has other parts ? | 15:23.43 |
| Robin_Watts | ray_laptop: Right. Such a timeout would be in the particular fz_stream implementation, which is written by the app writer, not by us. | 15:24.10 |
| | The http fz_stream is just a normal fz_stream. | 15:25.00 |
| | Or rather, as far as MuPDF is concerned it's a normal fz_stream. | 15:25.14 |
| ray_laptop | Robin_Watts: mupdf calls the 'read' or 'seek' on the stream, and doesn't know what happens unless an error is returned. That I understand. But the call to 'read' has to pass the HTTP implementation the rest of the parameters that it is using | 15:25.25 |
| | Robin_Watts: so the rest of the params must follow the actual fz_sream part that mupdf uses, right ? | 15:25.58 |
| Robin_Watts | ray_laptop: There can be other params, but they aren't related to the fz_stream bit. I'll try to explain. | 15:26.33 |
| | I'm an app writer. | 15:26.40 |
| ray_laptop | you are ? | 15:26.49 |
| Robin_Watts | I create an HTTPStream object to do a fetch. | 15:26.51 |
| ray_laptop | I used to think more highly of you ;-) | 15:27.02 |
| Robin_Watts | I feed that any params I like (timeouts etc) | 15:27.09 |
| | Then I make an fz_stream object out of that. | 15:27.18 |
| | Then I pass that fz_stream object to MuPDF (fz_open_document_with_stream) | 15:27.35 |
| ray_laptop | Robin_Watts: define "make an fz_stream object out of that." please | 15:27.41 |
| Robin_Watts | ray_laptop: Phone call, sorry. | 15:27.52 |
| chrisl | Robin_Watts: does the fz_stream have an opaque pointer (something like that) for the app to attach it's "private data" to? | 15:28.08 |
| Robin_Watts | chrisl: It does. | 15:28.15 |
| ray_laptop | Robin_Watts: from gs we cast a private object (HTTPStream) to (fz_stream_s) | 15:28.19 |
| | Robin_Watts: OK, similar concept, but less messy (avoiding the cast) | 15:28.44 |
| | LPD liked mashing the structures together | 15:29.29 |
| chrisl | And caused declaration macro hell into the bargain! | 15:30.11 |
| ray_laptop | chrisl: many of these are done the "old fashioned" way without macrros, but yes the ..._common macros were part of LPD's usage | 15:31.07 |
| | Robin_Watts: but now I follow you. | 15:31.37 |
| chrisl | ray_laptop: I prefer the "old fashioned" way - the macros can be a nightmare :-( | 15:31.57 |
| ray_laptop | Robin_Watts: but if we don't do an http fetcher, I would think it would still be worth having and example one in the 'kit' | 15:32.14 |
| | Robin_Watts: this is so generally useful | 15:32.30 |
| | Robin_Watts: so maybe a SoC project for a student, or contract out. fetching HTTP header blocks and ranges isn't that difficult (it can 'punt' on funky server responses) | 15:34.26 |
| Robin_Watts | back. | 15:34.45 |
| | ray_laptop: I would do it by having a 'base' structure personally. Avoiding the gs-like macro hell. | 15:35.23 |
| ray_laptop | chrisl: agreed -- mostly (I use the ones already present in GS, but don't add new ones) | 15:35.31 |
| | Robin_Watts: agreed. | 15:35.54 |
| Robin_Watts | ray_laptop: I have implemented an http fetcher before. | 15:36.03 |
| ray_laptop | Robin_Watts: me too | 15:36.09 |
| | but that was circa 1997 and some features/hacks have been added to the protocol since then | 15:36.37 |
| Robin_Watts | Back when browsers were crap, I wrote something that did restarting transfers in the background, and opened several connections at a time etc. | 15:36.38 |
| | The problem is that these days, with the caching etc, it's a lot of work to do it correctly. | 15:37.07 |
| | And I strongly suspect that anyone that actually does this is going to have their own http fetcher already. | 15:37.23 |
| ray_laptop | Robin_Watts: possibly true | 15:37.41 |
| Robin_Watts | hence I might be tempted to write a skeleton bit of code that calls down to an http fetcher interface. | 15:37.53 |
| | the idea being that people can then use our skeleton to wrap their own http fetcher. | 15:38.20 |
| ray_laptop | Robin_Watts: and use some common 'fetcher' as an example ? | 15:38.23 |
| Robin_Watts | I was thinking that I might 'fetch' from file ;) | 15:38.42 |
| ray_laptop | Robin_Watts: YUCK | 15:38.57 |
| Robin_Watts | What common 'fetcher' were you thinking of? | 15:39.28 |
| ray_laptop | Robin_Watts: the wget code ? | 15:39.53 |
| Robin_Watts | I could shell out to curl or wget or something, but that's a bit horrid. | 15:40.04 |
| chrisl | Robin_Watts: you could use libcurl | 15:40.29 |
| Robin_Watts | chrisl: Such a thing exists? | 15:40.42 |
| | I could do then, yes. | 15:40.47 |
| chrisl | I believe so, yes | 15:40.53 |
| | I mean, it's probably GPL, but as an example, that won't matter | 15:41.11 |
| ray_laptop | http://curl.haxx.se/libcurl/c/ | 15:41.35 |
| Robin_Watts | reading that now. | 15:41.48 |
| chrisl | Robin_Watts: anyway, there are other http implementation in the open source world | 15:42.13 |
| ray_laptop | Robin_Watts: not clear if libcurl does caching, but that isn't critical for an example (IMHO). If mupdf loads a resource (ie., font) does it ever discard it and re-read it ?) | 15:44.50 |
| Robin_Watts | ray_laptop: We'd be fetching the file to a local buffer. | 15:45.15 |
| | So we'd only ever download each byte of the file once. | 15:45.30 |
| | mupdf tends to only load resources once (as they live in the store), but if memory is low they can be evicted and then reread on next use. | 15:46.13 |
| ray_laptop | Robin_Watts: well, for an example, I guess fetching an entire file is 'basic', but it doesn't provide an example of fetching byte ranges (which is more useful) | 15:48.55 |
| Robin_Watts | ray_laptop: I suspect I should bite the bullet and do a version of mupdf that uses libcurl to allow it to read from http addresses. | 15:49.38 |
| sebras | Robin_Watts: is there a user_data void * in the fz_stream that we provide as a potential state to the app developer doing the http-fetcher? | 15:50.06 |
| ray_laptop | Robin_Watts: I think it would be a good project for someone else (saving you for the mupdf kernel) | 15:50.23 |
| | Robin_Watts: like some student or consultant | 15:50.39 |
| sebras | Robin_Watts: it seems that a user_data like pointer is fairly commonly used. even curl has a handle that you need to keep around in order to fetch more data for a particular connection. | 15:50.48 |
| Robin_Watts | sebras: void *state, yes. | 15:50.52 |
| ray_laptop | Robin_Watts: but you would be good to guide someone | 15:50.58 |
| Robin_Watts | ray_laptop: I don't think it's a large enough job to justify getting someone in to do. | 15:51.33 |
| sebras | chrisl: curl is non-gpl is it not..? | 15:51.44 |
| | I have seen it in several proprietary apps at least... | 15:51.58 |
| Robin_Watts | Or at least, if it IS a large enough job, then there are problems that I haven't thought of, in which case I'll get sucked back into it. | 15:51.58 |
| sebras | MIT. | 15:52.13 |
| ray_laptop | Robin_Watts: true | 15:52.15 |
| | MIT is fine for us, if I understand it correctly | 15:52.33 |
| sebras | ray_laptop: yes, to my understanding as well. | 15:52.47 |
| chrisl | sebras: I hadn't looked, just throwing it out as a cautionary comment | 15:52.52 |
| sebras | ray_laptop: I guess it is more a question of carrying another thirdparty around. :) | 15:53.05 |
| chrisl | Yeh, MIT is fine for us. | 15:53.26 |
| sebras | chrisl: well, it prompted me to look it up, so I guess it worked. | 15:53.41 |
| chrisl | :-) | 15:53.51 |
| | LCMS is MIT, too..... | 15:54.16 |
| sebras | chrisl: and according to wikipedia curl builds on darwin, linux, windows, ios, android and the blackberries. no word on winrt though. | 15:55.30 |
| chrisl | WinRT might be a problem, given the API restrictions it introduced | 15:56.02 |
| ray_laptop | we should count how many are at our party -- a lot more than 3 :-) | 15:56.25 |
| | family is awake now. maybe back later | 15:57.58 |
| Robin_Watts | thanks ray_l | 15:58.09 |
| | too slow. | 15:58.12 |
| chrisl | Off now, bye all! | 16:01.59 |
| kens | OK I'm off too, goodnight all | 16:23.04 |
| mvrhel_laptop | Robin_Watts: you around? | 19:16.05 |
| Robin_Watts | I am. | 19:16.12 |
| | malc_: Annotations fixed now, I hope. | 19:16.58 |
| malc_ | Robin_Watts: yep, thank you | 19:18.12 |
| mvrhel_laptop | Robin_Watts: if you can push the commits in my repos to golden I would appreciate it | 19:19.52 |
| Robin_Watts | mvrhel_laptop: I'll look at them now. Sorry, had you mentioned them before? | 19:20.11 |
| mvrhel_laptop | off to celebrate independence from tyranny | 19:20.18 |
| | Robin_Watts: I sent you an email yesterday. no big deal | 19:20.28 |
| Robin_Watts | sorry. | 19:20.35 |
| mvrhel_laptop | just getting things cleaned up | 19:20.37 |
| | going to start a new branch for the phone work | 19:20.46 |
| | had a good time yesterday on the roller coasters. | 19:21.20 |
| | no lines due to weather | 19:21.23 |
| | road a giga coaster that had a 305 foot drop | 19:21.38 |
| Robin_Watts | All look good to me. | 19:21.41 |
| | wow. | 19:21.43 |
| mvrhel_laptop | at 85 degree angle | 19:21.46 |
| | followed by a 6g turn | 19:21.52 |
| | it caused me to start to gray out | 19:22.04 |
| | during the turn | 19:22.22 |
| Robin_Watts | We need to have a staff meeting in vegas, then we can all go up the stratosphere and scare ourselves stupid on the rounds there. | 19:22.34 |
| mvrhel_laptop | http://en.wikipedia.org/wiki/Intimidator_305 | 19:22.41 |
| Robin_Watts | s/rounds/rides/ | 19:22.41 |
| mvrhel_laptop | that would be fun | 19:22.44 |
| | vegas is easy for me to get to | 19:23.33 |
| | i imagine miles would like the gambing | 19:23.47 |
| | gambling | 19:23.52 |
| sebras | that's nothing! ;) http://www.julijonasurbonas.lt/p/euthanasia-coaster/ | 19:24.42 |
| | I suggest you not ride this one though. | 19:25.14 |
| mvrhel_laptop | I dont care for loops so much | 19:28.11 |
| Robin_Watts | mvrhel_laptop: The point of sebras one is that it induces hypoxia and everyone dies. | 19:29.05 |
| mvrhel_laptop | I understand | 19:29.14 |
| Robin_Watts | or strokes out... | 19:29.24 |
| mvrhel_laptop | 10 gs for 60 seconds | 19:29.38 |
| Robin_Watts | I haven't ridden many rollercoasters - not such a big thing here in the US. | 19:29.52 |
| sebras | I have feared them since I was a child and my parents though it would be a good idea for me to ride a small one by myself in .it... | 19:30.21 |
| | which led to me hating flying as well... | 19:30.47 |
| Robin_Watts | I've visited Disneyland (25+ years ago) and Universal Studios. And I've done the coaster at New York, New York in vegas. | 19:30.50 |
| mvrhel_laptop | I used to like them a lot but now they tend to give me a headache due to the bouncing, but this one that I did was smooth but fast | 19:31.10 |
| | I guess we did 6 coasters yesterday | 19:31.31 |
| Robin_Watts | ah. The new york new york one didn't seem that fast, but it seemed very bumpy. I don't mind speed, I do dislike bumps. | 19:31.53 |
| mvrhel_laptop | same as me | 19:32.03 |
| Robin_Watts | mvrhel_laptop: pushed. | 19:34.04 |
| mvrhel_laptop | Robin_Watts: ok great thanks | 19:34.13 |
| Robin_Watts | np. | 19:34.22 |
| | Enjoy the holiday. | 19:34.53 |
| mvrhel_laptop | thanks | 19:35.33 |
| | Forward 1 day (to 2013/07/05)>>> | |
IRC Logs