| | <<<Back 1 day (to 2014/01/08) | 2014/01/09 |
| kens | CHRISL PING | 09:02.07 |
| | Oops caps sorry | 09:02.15 |
| chrisl | kens: pong | 09:08.16 |
| kens | chrisl I'm looking at bug #693775 which is a Valgrind report from Marcos | 09:08.48 |
| | When I look at the log he seems to be using a script to test with,m and so I can't see the valgrind options he's using (if any) | 09:09.11 |
| | When I run the files here I don't get the warnings he does, is there any special options I should select do you think ? | 09:09.31 |
| | NB I also don't get teh GS warnings he does, with the current code, which may be relevant..... | 09:09.52 |
| chrisl | That's just the valgrind memcheck tool, which is the default, so shouldn't need any options | 09:10.38 |
| kens | OK that's good I guess :-) | 09:10.47 |
| | SO I'll put the bug back to Marcos and say I can't reproduce it, thanks | 09:11.05 |
| chrisl | NP | 09:11.15 |
| kens | chrisl ping again | 10:59.18 |
| chrisl | kens: here | 10:59.47 |
| kens | Looking at a fuzzing problem which (for me) is actually a crash | 11:00.07 |
| | Bug #694236 | 11:00.36 |
| | In gxfcopy.c, gs_copy_font_complete we call font_procs.enumerate_glyph for each glyph in the font | 11:00.55 |
| | One of those in this case returns a GS_NO_GLYPH | 11:01.09 |
| | (I'm assuming the font is knackered) | 11:01.19 |
| | This is a problem when we call colpy_glyph() later on | 11:01.40 |
| chrisl | ..... free_color_space()? | 11:01.47 |
| kens | Yes, it crashes for me | 11:02.03 |
| | In fonts..... | 11:02.12 |
| | Windows and Linus, so its not just memory, I have no idea how Marcos got it to run to completion | 11:02.30 |
| chrisl | Could be things have changed since he did the testing | 11:02.48 |
| kens | My solution is, on line 2332 to check for glyph == GS_NO_GLYPH along with glyph between HS_MIN_CID_GLYPH_INDEX and GS_MIN_CID_GLYPH | 11:03.33 |
| | Cluster run shows no problems, and I htink only pdfwrite uses this stuff. | 11:03.55 |
| | DOes that look reasonable to you ? | 11:04.01 |
| chrisl | I don't understand: looking at the code, if glyph == GS_NO_GLYPH we should never get to line 2332...... | 11:06.17 |
| kens | Maybe our line numbers are different, I've seen that before | 11:06.40 |
| | I mena this pair of lines: | 11:06.57 |
| | if (font->FontType == ft_TrueType && | 11:06.57 |
| | ((glyph >= GS_MIN_CID_GLYPH && glyph < GS_MIN_GLYPH_INDEX) || glyph == GS_NO_GLYPH)) | 11:06.57 |
| | If you want to try running it, put a breakpoint on that line, set a hit count of 105 and then step round he next iteration | 11:08.19 |
| chrisl | Yeh, different line numbers - yeh, that looks okay. It mirrors what's happening in the encoding section (which is what I was looking at) | 11:08.27 |
| kens | OK then I will commit that and go back and retest valgrind, thanks. | 11:08.47 |
| Robin_Watts | Morning paulgardiner. | 11:19.56 |
| | A few things on robin/master (not the last 2) | 11:20.05 |
| paulgardiner | Hi Robin_Watts | 11:20.07 |
| | Oh okay. I'll take a look | 11:20.16 |
| | Robin_Watts: sorry got pulled away. Now I've had a chance to check, all looks fine. | 12:01.24 |
| | Robin_Watts: must ask you what the hell fz_predict_png does sometime... well I can see what it does, but can't figure why. | 12:02.33 |
| chrisl | paulgardiner: it's in the spec: http://www.w3.org/TR/2003/REC-PNG-20031110/#9Filters - or is that not what you mean....? | 12:07.37 |
| paulgardiner | chrisl: oh might be, thanks. Wasn't expecting it to be in the spec as it is our code and I'd have thought most stuff in the spec we'd get from the lib | 12:09.20 |
| | That does look like it might be it though. | 12:09.48 |
| chrisl | I didn't think mupdf uses libpng - I thought tor8 wrote his own | 12:09.54 |
| paulgardiner | oh right. :-) That would explain it. | 12:11.32 |
| | and would also explain why libpng isn't in thirdparty. :-) | 12:12.16 |
| chrisl | Indeed! | 12:12.24 |
| Robin_Watts | paulgardiner: Thanks. | 13:01.27 |
| paulgardiner | np | 13:01.47 |
| ray_laptop | extremely early this morning! | 14:04.40 |
| | good morning, all | 14:04.52 |
| paulgardiner | Hi Ray. Are you all better now? | 14:13.24 |
| kens | Hi Ray | 14:13.43 |
| sebras | tor8: ping. | 14:38.21 |
| paulgardiner | tor8: saving on iOS, at least in part on paul/master | 14:48.43 |
| ray_laptop | paulgardiner: sorry, wasn't paying attention. I'm still pretty much the same. No pain, and feeling OK, but my eye still doesn't blink (and my mouth drroops), so keeping the eye moist is the most difficult part while waiting this out | 14:52.17 |
| | it's been under 4 weeks-- just seems like much longer | 14:54.38 |
| paulgardiner | Eee! Nasty. Early days, I suppose, but was hoping you'd be one of the lucky ones for whom it cleared up more quickly. | 14:57.21 |
| Guest43011 | Anyone here who can answer a question about using ghostscript in my sw application? | 14:57.57 |
| kens | Several | 14:58.18 |
| | Depending on the question | 14:58.25 |
| Guest43011 | We are a company that sell an unit that in the end creates a PDF report. The unit can be connected to a network but can't print PDF files by itself. My question is if I can use ghostscript and create a small program running on a computer in the background which will detect if there exist a PDF file on the unit and in that case print it, and then delete it. | 15:00.19 |
| kens | 'maybe' | 15:00.43 |
| Guest43011 | The question is, can I use ghostcript here or do I need a license? | 15:00.49 |
| kens | What OS does the computer ise, what language does hte printer speak ? | 15:01.01 |
| | We are engineers not lawyers, so..... | 15:01.15 |
| Guest43011 | The program works already ;) | 15:01.17 |
| chrisl | Guest43011: is you app going to be open source? | 15:01.31 |
| kens | Depends how you are using GS | 15:01.35 |
| chrisl | s/you/your | 15:01.37 |
| Robin_Watts | Guest43011: Ghostscript is copyright Artifex. You will need a license to be able to use it. It is possible that the GNU AGPL will cover you, but only if you abide by its conditions. | 15:01.38 |
| ray_laptop | Guest43011: glad it's working | 15:01.45 |
| Guest43011 | Im using GS to send a PDF file to a printer | 15:02.05 |
| Robin_Watts | If you cannot abide by all the terms of the GNU AGPL then you would either need to get a commercial license from Artifex, or not use Ghostscript. | 15:02.13 |
| kens | Are you using GS uinjmodified, invboked as a process, linked dfynamically or staticalyy to your application ? | 15:02.29 |
| | Please excuse the spelling.... | 15:02.43 |
| Guest43011 | yeah, was reading all terms but think is hard to understamd them | 15:02.44 |
| kens | If its not clear, you probably need an opinion from a lawyer | 15:03.00 |
| Guest43011 | using GS like this : | 15:03.28 |
| | public void PrinterThread(string printerName, string fileName, bool portrait) { string gsArguments, gsLocation; ProcessStartInfo gsProcessInfo; Process gsProcess; if (portrait) { gsArguments = string.Format("-noquery -portrait -printer \"{0}\" \"{1}\"", printerName, fileName); gsLocation = @"C:\Program | 15:03.29 |
| | lol wait | 15:03.34 |
| chrisl | Guest43011: probably best to use a pastebin site | 15:03.57 |
| Robin_Watts | Guest43011: The question is, how do you interact with Ghostscript. | 15:04.10 |
| Guest43011 | http://textuploader.com/19d4 | 15:04.13 |
| | see that code for interaction | 15:04.17 |
| | that the only thing Im doing | 15:04.26 |
| chrisl | So you're forking a new process for a completely standard Ghostscript executable? | 15:04.58 |
| Guest43011 | http://textuploader.com/19dl | 15:05.23 |
| | yes | 15:05.33 |
| Robin_Watts | If Ghostscript is installed separately from your app, has all the copyright notices etc intact, is unchanged from one of our releases, is invoked by forking a completely new process, and can hence be uninstalled/replaced by the user then you're probably fine. | 15:05.36 |
| Guest43011 | can Ghostscript be installed during my software installation with a notice? | 15:06.06 |
| | "in silence mode" | 15:06.15 |
| | My program will ofc inform the use that GS is a part of the software | 15:06.37 |
| Robin_Watts | we would prefer not, I think. | 15:06.44 |
| Guest43011 | cool | 15:06.48 |
| Robin_Watts | but it's OK to have your installer call the gs installer as a step, AIUI. | 15:07.10 |
| Guest43011 | cool | 15:07.18 |
| | So its sound to me that this is fine? | 15:07.25 |
| chrisl | You can't "hide" Ghostscript and the AGPL from the end user. | 15:07.57 |
| Guest43011 | The software is free, but would it change anything if it someday would be included in a "pack" that cost money? | 15:08.15 |
| | OK chrisl | 15:08.36 |
| henrys | Guest43011: just change the 2 gsLocation assignments to one assignment after the conditional ;and then we'll be happy -) | 15:09.17 |
| chrisl | Guest43011: you should note that, if you use use and distribute GS under the AGPL there is *no* tech support | 15:09.49 |
| tor8 | paulgardiner: yes, I loathe libpng with a vengeance... it's really just an unpleasant library all around. | 15:10.27 |
| Guest43011 | It's fine. I would make the program work and hopeful I wouldn't need any support. I just wanted to know if i need to get a license for this or not, don't want any problems later on with lawyers | 15:11.27 |
| chrisl | Guest43011: the point is particularly if you *sell* it, and one of your customers hits a problem with GS, you'll be on your own solving that. | 15:12.19 |
| Guest43011 | It's sounds to me that I'm fine, however the word "probably" isn't good enough for me. Guess I need someone with knowledge about this to check on this | 15:12.19 |
| | Okey, cool | 15:12.41 |
| paulgardiner | tor8: I think I've used it for something, but it was probably such an unpleasant experience that it's gotten wiped from my memory. | 15:13.43 |
| chrisl | Guest43011: if you want an authoritative opinion, you can contact Artifex directly. | 15:13.49 |
| tor8 | paulgardiner: when writing png, it *always* ends up with fewer lines (and simpler lines) to just write the data yourself than jump through the hoops needed from the libpng library | 15:14.38 |
| Guest43011 | Yeah i contacted them, but all I got was an answer on how many license i wanted to buy, not an answer if I need a license or not. Ofc they are trying to sell. Will try to discuss this further with them | 15:14.52 |
| | Thanks for all help anyways! | 15:15.00 |
| ray_laptop | Guest43011: doesn't sound like the usual kind of response -- was that from Scott ? | 15:15.42 |
| Guest43011 | yes, Scott Sackett | 15:16.11 |
| tor8 | paulgardiner: that there tmp_path stuff function looks terrible, but I guess that's what you have to do with a braindead spec :( | 15:16.30 |
| ray_laptop | Guest43011: I see. Of course, he isn't a lawyer -- just our sales guy, so he really can't help with the license determination | 15:17.17 |
| paulgardiner | tor8: Yeah, seems there is nothing built in to do it. | 15:17.33 |
| tor8 | paulgardiner: thought might it not be possible to just wrap the file descriptor with fdopen() and return the FILE* for use | 15:17.35 |
| Robin_Watts | Guest43011: Did he send you the "Artifex Inquiry"? | 15:17.44 |
| tor8 | so we don't have to close and reopen | 15:17.47 |
| Guest43011 | Robin_Watts: yes ;) | 15:18.41 |
| paulgardiner | tor8: yeah, might be worth it, although I don't suppose it would ever give a noticable improvement to the user. | 15:18.59 |
| ray_laptop | Guest43011: but sounds like you'll be able to use the AGPL license since gs is kept 'separate' | 15:19.01 |
| Guest43011 | ray_laptop: yeah, there is none else i can contact? | 15:19.05 |
| Robin_Watts | right, that's the standard set of questions he sends out. I always think it's pretty scary, and I wish we could improve the language in there a bit. | 15:19.15 |
| Guest43011 | Robin_Watts: the questions was alright if i would need to buy it, but my q was if i really needed to buy it at all | 15:19.59 |
| tor8 | paulgardiner: I haven't spotted it before, but now I see you've sneaked in some '_'-prefixed fields in the MuLibraryController. | 15:20.00 |
| ray_laptop | Robin_Watts: agreed. It was put together about 12 years ago, and it could probably use an update. | 15:20.06 |
| henrys | Guest43011: I assume you've read the licensing page at artifex.com? If so you can just ask Scott if you fall into category 1 or 2 under the 2 type license paragraph? | 15:20.08 |
| tor8 | paulgardiner: might be some race condition stuff? | 15:20.18 |
| | it's worth getting right, anyway, just for cleanliness sake | 15:20.28 |
| paulgardiner | tor8: I thought I added one in this commit to one that was already there. | 15:20.28 |
| Robin_Watts | essentially, we tailor our licensing proposals to peoples needs. So the first thing he does is to try to understand as much about their needs as possible - hence the huge list of questions. Just answer them as best you can, with as much detail as you can. | 15:20.32 |
| Guest43011 | henrys: i will do that, thanks | 15:20.33 |
| tor8 | paulgardiner: yeah, I hadn't spotted the one that was already there when it first got in! | 15:20.46 |
| henrys | Guest43011: his contact information is on the same page | 15:20.51 |
| tor8 | what does this _ prefix mean? | 15:20.58 |
| paulgardiner | Was the one already there my addition? | 15:21.00 |
| | I guess it must be if you are asking me that. | 15:21.15 |
| | :-) | 15:21.20 |
| tor8 | paulgardiner: I doubt it's one of mine! I *hate* underscore prefixes :) | 15:21.25 |
| paulgardiner | tor8: me too. So that's strange! :-) | 15:22.38 |
| tor8 | let's blame Robin! | 15:23.11 |
| Robin_Watts | I dislike _ prefixes too. | 15:23.24 |
| | Has anyone looked at git blame ? | 15:23.30 |
| | and I haven't touched the iOS code :) | 15:23.39 |
| tor8 | it's probably all my fault! | 15:24.06 |
| | I'm sure I had a reason (like "it's an ugly hack, so it should look ugly!") | 15:24.19 |
| ray_laptop | I was just looking at the http://www.artifex.com/page/licensing-information.html page. found a typo "plan to provide Ghostscript of MuPDF" I think s/of/or/ | 15:24.54 |
| tor8 | it says // temporaries for juggling password dialog | 15:24.56 |
| ray_laptop | I'll email Miles to give him something to do ;-) | 15:25.30 |
| paulgardiner | tor8: It does seem to predate my involvement. | 15:25.31 |
| tor8 | paulgardiner: yeah, I take the blame for it. | 15:25.38 |
| paulgardiner | It's one of those thing I haven't dared to change for fear my understanding isn't all I hope it is | 15:25.47 |
| | I think the underscore was intended to mean thing that doesn't need releasing in dealloc | 15:26.43 |
| | But I think it's a convention that is usually for the case where you are holding a pointer to someone else's data but without a reference. | 15:27.43 |
| tor8 | paulgardiner: it was an ugly hack for the password dialog being all async and I needed to work around the gui framework | 15:28.35 |
| | I have no memory of how it was supposed to work, so if you can fix it in the proper way go for it! | 15:28.56 |
| | paulgardiner: speaking of the ios stuff, I was going through and updating all the Copyright dates | 15:29.11 |
| paulgardiner | Ones in my additions were autotgenerated. | 15:29.45 |
| tor8 | do you really have to put those pointless comment blocks at the top of the files? (I know Xcode likes filling them in, annoyingly) | 15:29.45 |
| | mind if I zap them all? | 15:29.58 |
| paulgardiner | I don't mind at all. I at least took my name out of them :-) | 15:30.32 |
| tor8 | paulgardiner: really? all the ones I have here say "Created by Paul Gardiner on <stupid american date format>" | 15:31.04 |
| paulgardiner | Oh I missed some then | 15:31.15 |
| tor8 | well, a few, not all | 15:31.29 |
| paulgardiner | Is my commit okay to push. I may look at those _vars, but probably better as a separate change. | 15:32.15 |
| | ? | 15:32.21 |
| tor8 | paulgardiner: yeah, go ahead (unless you want to do something about the tmp_path) | 15:33.54 |
| paulgardiner | I think tmp_path is okay for now. If we do want to change it, it wants to be in Android also. | 15:34.39 |
| tor8 | paulgardiner: Robin_Watts: three commits on tor/master | 15:34.50 |
| paulgardiner | tor8: oh, should I wait for yours? | 15:35.43 |
| | nah. I guess it's okay to go | 15:38.43 |
| Robin_Watts | tor8: all good, except the last one. | 15:38.55 |
| | Should you have an if (out != stdout) fclose(out); in there? | 15:39.13 |
| | Or: if (output) fclose(out); | 15:39.46 |
| | otherwise out is never closed. | 15:39.53 |
| paulgardiner | I see nothing else wrong (not that I can claim to have spotted that one). | 15:42.16 |
| mvrhel_laptop | ray_laptop: I am sorry I did not get back to you on your patch | 16:20.42 |
| | I don't see any obvious issues with it though | 16:21.50 |
| | Robin_Watts: not sure if you saw the logs | 16:21.59 |
| Robin_Watts | sorry. will look now. | 16:22.17 |
| mvrhel_laptop | I had pushed up a commit in my repository for you to look at | 16:22.22 |
| | ok | 16:22.23 |
| | I have to head out for a bit now | 16:22.29 |
| | we can chat about issues later if you are around and find any | 16:22.40 |
| | thanks Robin_Watts | 16:22.51 |
| Robin_Watts | mvrhel_laptop needs to work on his 1 line summaries for git commit messages :) | 16:25.06 |
| | mvrhel_laptop: OK. | 16:31.29 |
| | The patch makes as much sense as I'd expect it to, given my poor understanding of the windows stuff. | 16:31.59 |
| | paulgardiner, tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=082ccd035edb3c10b71a82e786cd924c1cd2b430 | 16:43.39 |
| paulgardiner | So build_filter takes ownership even if failing? | 16:46.44 |
| Robin_Watts | paulgardiner: yes. | 16:47.01 |
| | build_filter assumes ownership immediately. I can't see that any other way is sensible. | 16:47.21 |
| paulgardiner | I don't immediately see why taking ownership only if successful isn't sensible. | 16:49.19 |
| | I presume fs_streams aren't ref counted. | 16:50.04 |
| Robin_Watts | paulgardiner: That would be the only function in all of mupdf (as far as I am aware) where ownership depends on whether the call succeeds or fails. | 16:51.28 |
| | They are not ref counted. | 16:51.36 |
| henrys | mvrhel_laptop: what is your level of trust with this guy we are talking with. My hesitation is when I met him I didn't feel like it would be good to do business with him. But first impressions can be wrong. | 16:53.39 |
| tor8 | Robin_Watts: ah, good catch. revised version up now. | 16:59.13 |
| paulgardiner | Robin_Watts: fix should certainly work, anyway. | 16:59.20 |
| Robin_Watts | tor8: looks good to me. | 16:59.42 |
| | paulgardiner: Thanks. | 16:59.49 |
| | tor8: want to weigh in? | 16:59.58 |
| paulgardiner | Robin_Watts: but I still can't help thinking taking ownership only if successful might be more natural. | 17:00.08 |
| tor8 | Robin_Watts: looks reasonable to me, but I'd have to look at the calling code to be sure which way would be more natural | 17:00.41 |
| paulgardiner | Means a load of "thing = NULL" statements would need adding, but we have to do that with free already, so it would be consistent | 17:01.02 |
| Robin_Watts | All the way through MuPDF we have the convention that if a function takes ownership of a param, it takes ownership regardless of success or failure. | 17:01.36 |
| | In general, I believe, it makes the code simpler. | 17:01.54 |
| paulgardiner | Except free | 17:02.01 |
| Robin_Watts | paulgardiner: ? | 17:02.09 |
| | free(x) can never fail. Hence it takes ownership of x (and destroys it) regardless of success or failure. | 17:03.02 |
| | Perhaps I should say "In general, I believe, it makes the calling code simpler" | 17:03.43 |
| paulgardiner | Yeah, what am I on about. | 17:03.46 |
| | But still: | 17:03.53 |
| | If build_filter took ownership it wouldn't be prone to this very-easy-to-make mistake, and it would mean that where the assigned var was not the var holding the value whos ownership was being passed, a "var = NULL" statement would need to be added, which is like free | 17:06.00 |
| | I mean "if it didn't take ownership when failing" of course | 17:06.52 |
| Robin_Watts | build_filter_chain would be lots more complicated. | 17:08.13 |
| paulgardiner | ... but I think I've convinced myself that I prefer it your way actually. | 17:08.27 |
| | build_filter_chain currently has no try/catch ? | 17:08.55 |
| Robin_Watts | actually, I suspect that build_filter_chain currently leaks. | 17:09.10 |
| | in the error case. | 17:09.14 |
| paulgardiner | Anyway got to go. Certainly not important, and I do see what you are saying | 17:09.38 |
| Robin_Watts | actually, I am wrong. fz_streams *are* refcounted. | 17:09.47 |
| | tor8, paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=bc578505cd50f20048f8d21e6311b21339f3c821 | 17:18.28 |
| paulgardiner | Robin_Watts: in which case shouldn't build call addref (or have "drop" in its name) | 17:22.23 |
| | ? | 17:22.24 |
| Robin_Watts | No, because it takes ownership. | 17:22.37 |
| | Oh. | 17:22.49 |
| | Possibly it should have drop in its name (but that's a convention that post dates this code) | 17:23.18 |
| paulgardiner | It might be better if it called addref. I'm wondering now if the only reason it doesn't is to support chain = f(chain) which turns out to not to work well after all | 17:24.38 |
| Robin_Watts | paulgardiner: It might. | 17:27.26 |
| | So the caller would have to do: chain2 = f(chain); fclose(chain); chain = chain2; | 17:27.52 |
| | s/fclose/fz_drop_stream pr whatever/ | 17:28.09 |
| | That doesn't make the calling code any simpler than what we have here, as far as I can see. | 17:28.36 |
| | and we end up having to do an extra take and an extra drop. | 17:29.09 |
| | Gah. When debugging on linux, making the changes on your windows box will not cause them to show up in the build you are testing. | 17:29.54 |
| henrys | marcosw: around? | 17:32.22 |
| paulgardiner | Robin_Watts: I was thinking that the caller would just do chain = f(chain) and the f would addref only if successful. I haven't thought it throughwith care | 17:35.01 |
| Robin_Watts | paulgardiner: build_filter calls a batch of other filter creation functions. | 17:35.38 |
| paulgardiner | And I'm in and out at the moment | 17:35.49 |
| Robin_Watts | All of them take ownership regardless of success/failure. and they are external APIs. | 17:36.08 |
| | I think. | 17:36.16 |
| RyDroid | Hi. | 17:39.28 |
| paulgardiner | Oh okay. I thought that was unusual for ref counted stuff. All the pdf_obj functions (other than the new drop ones) use addref rather than steal the ref from the caller... I thought. | 17:40.38 |
| RyDroid | MuPDF is available on F-Droid https://f-droid.org/repository/browse/?fdfilter=mupdf&fdid=com.artifex.mupdfdemo | 17:41.00 |
| Robin_Watts | RyDroid: only 1.2 though :( | 17:41.47 |
| | but good to see, nonetheless | 17:42.01 |
| RyDroid | I think that it colud be useful that you add this link on your website for people that have not Google Play or do not want to use it (for privacy reasons). | 17:42.02 |
| Robin_Watts | Possibly, but it's hard to offer a link to an older version. | 17:42.41 |
| | tor8: What do you think? | 17:43.36 |
| RyDroid | This is apparently a small team. They do not matter on the last version or the most useful. This a store, that works like a package manager, that has the aim to provide only free/libre software. | 17:43.57 |
| Robin_Watts | RyDroid: Well, we fix bugs all the time. | 17:44.21 |
| | If we point people to a website and they go and download it, and it has problems that we've already fixed, then they will whinge at us. | 17:44.54 |
| RyDroid | A link on a APK on your website could be an other solution for people that want to live without Google. | 17:45.16 |
| Robin_Watts | Yes. | 17:45.34 |
| | But we build multiple apks - do you trust users to be able to download the correct one for their arch? | 17:46.04 |
| RyDroid | They are doing it for x86 and x86-64 and also for ARM on WinRT, so apparently yes. | 17:48.02 |
| | In the worst case, they will try all. | 17:48.34 |
| | The Google Play link could have a flag/textAfter "easier" or something like that. | 17:49.44 |
| Robin_Watts | RyDroid: yes, we will talk it over. Thanks for the suggestion. | 17:50.50 |
| RyDroid | Ok. Thanks for this great program. | 17:51.52 |
| zeniko | Robin_Watts: follow-up patch to my pdf_cache_object one from yesterday (the last on zeniko/mupdf) | 18:09.37 |
| | pdf_get_xref_entry looks a bit dangerous to use now, should we add a comment to that regard - or are multiple xref sections required at all (so that we could go back to the safer doc->table[num]->obj)? | 18:11.00 |
| Robin_Watts | zeniko: Multiple xref sections are required, yes. | 18:13.59 |
| | They are needed for doing incremental saving. | 18:14.15 |
| | which is required for signing etc. | 18:14.22 |
| zeniko | then everybody using pdf_get_xref_entry will have to be extra careful | 18:14.41 |
| | (instead of having multiple xref sections, wouldn't a flattened one be sufficient where the xref entry contains a level number?) | 18:15.20 |
| Robin_Watts | AIUI, no, because older xref entries can coexist with newer ones in a file. | 18:16.27 |
| zeniko | so older xref entries are required for signature checking (even though they're overwritten later on)? | 18:19.44 |
| Robin_Watts | I wouldn't like to swear that they wouldn't be. | 18:20.02 |
| zeniko | paulgardiner: ^ ? | 18:22.06 |
| ray_laptop | mvrhel_laptop: Sorry. I was at a doctor's appt. Thanks for looking at the patch. I'd like to talk sometime later about the problems I had (and still have) with the colors that are put in the clist (as pdf14 colors), but then get used by the device (not the pdf14 device). | 18:22.32 |
| paulgardiner | zeniko: That's right. Well it's not so much to tell if the signature is correct, but to check whether any changes that the signature would disallow have been made. | 18:23.49 |
| | zeniko: we don't currently check that to be honest, but we will need to eventually | 18:24.14 |
| | What was the danger? | 18:25.38 |
| | Actually, I'll have to follow this up tomorrow | 18:25.57 |
| Robin_Watts | essentially, (and I'm sure zeniko will correct me if I'm wrong) we have to be sure that we don't trigger a repair of the file while holding a pointer to an xref entry. | 18:29.19 |
| | Or, to put it differently, while holding a pointer to an xref entry, we have to not do anything that might trigger a repair. | 18:29.40 |
| | tor8, paulgardiner: And another... http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=4c988f4dc47937623f187c2056b6e15e7b357521 | 18:32.20 |
| | zeniko: Thanks. I've pushed that one. | 18:34.25 |
| zeniko | paulgardiner: xref entries are freed whenever the xref is resized (which may also happen when loading objects from a malformed stream, i.e. isn't even necessarily tied to xref repairing) | 18:36.36 |
| | Robin_Watts: thanks | 18:36.52 |
| paulgardiner | zeniko: So the same risk as holding onto &doc->table[num] over several calls, but something someone is more likely to do as they'll think that the pdf-get_xref_entry call is expensive. | 18:43.32 |
| zeniko | paulgardiner: exactly | 18:45.04 |
| mvrhel_laptop | henrys: I am back | 19:39.47 |
| | So, I don't think he is trying to pull a fast one on us, but simply is looking to raise some money with an asset that he has | 19:40.32 |
| | I would want us to carefully understand what the support contracts entail | 19:41.26 |
| | Robin_Watts: sorry about the long first line in the commit message. | 19:41.50 |
| Robin_Watts | mvrhel_laptop: No worries. | 19:42.14 |
| | looks good to me. | 19:42.24 |
| mvrhel_laptop | I am usually good about that sort of thing | 19:42.27 |
| | ok thanks Robin_Watts | 19:42.32 |
| | I think with that, I am going to push an update in the windows store with this | 19:42.46 |
| | and move on to the next thing | 19:42.52 |
| Robin_Watts | great. | 19:42.58 |
| henrys | mvrhel_laptop: yea that's my read and I think there is a contract and price that is good for us so I hope Miles follows up. | 19:43.51 |
| mvrhel_laptop | right | 19:47.15 |
| Robin_Watts | henrys, mvrhel_laptop: You know that you're driving me mad with curiosity, right? :) | 19:48.42 |
| henrys | Robin_Watts: that thought occurred to me, yes | 19:49.18 |
| Robin_Watts | ok, just as long as you know :) | 19:49.55 |
| henrys | Robin_Watts: go private with mvrhel_laptop or I'll be back later. | 19:50.22 |
| | lunching now | 19:50.33 |
| Robin_Watts | ok. have fun. | 19:51.05 |
| henrys | back | 20:43.01 |
| | Robin_Watts: did you talk to michael? | 20:47.49 |
| Robin_Watts | I did thanks. | 20:56.06 |
| | my nosiness is nicely assuaged :) | 20:56.14 |
| mvrhel_laptop | :) | 20:58.56 |
| | brb | 20:58.59 |
| | moving to coffee shop for change in venue | 20:59.08 |
| | Robin_Watts: you there? | 21:43.37 |
| | so I need to fix the winRT code for the change in fz_new_stream. what is the fz_stream_rebind_fn and do I need one? | 21:44.39 |
| | looks like I can just do NULL | 21:46.45 |
| Robin_Watts | just NULL, unless you build streams on top of streams. | 21:47.09 |
| mvrhel_laptop | hmm looks like I broke something though :( | 22:07.39 |
| | fz_open_document_with_stream is throwing for some reason now | 22:08.51 |
| | let me dig in and see | 22:09.02 |
| | at least my catching of errors is working | 22:09.35 |
| | I had a nice error get put up on the screen | 22:09.44 |
| | instead of the usual explosions that I am known for | 22:09.58 |
| zeniko | henrys: ping | 22:10.11 |
| mvrhel_laptop | Robin_Watts: ok I must be doing something really dumb someplace | 22:11.17 |
| henrys | zeniko:yes | 22:11.17 |
| Robin_Watts | mvrhel_laptop: Oh, sorry. | 22:11.42 |
| mvrhel_laptop | in fz_open_document_with_stream dc->count == 0 so it throws immediately | 22:11.49 |
| zeniko | henrys: I've got some patches to openjpeg (and one to jbig2dec) for review on zeniko/GhostPDL | 22:11.50 |
| Robin_Watts | You need to call fz_register_document_handlers. | 22:12.02 |
| zeniko | are you still the man to talk to about these? | 22:12.06 |
| mvrhel_laptop | aha | 22:12.28 |
| Robin_Watts | mvrhel_laptop: Sorry, I should have said. | 22:12.41 |
| mvrhel_laptop | is there some docs on this? | 22:12.48 |
| henrys | zeniko:presumably these were regression tested against mupdf and not ghostscript? | 22:12.54 |
| Robin_Watts | mvrhel_laptop: There is a commit message :) | 22:13.01 |
| mvrhel_laptop | is it one line :) | 22:13.10 |
| Robin_Watts | At least. | 22:13.22 |
| zeniko | henrys: they were - but MuPDF uses a clone of GhostPDL's repo, so that's where the fixes would have to end up anyway | 22:13.38 |
| Robin_Watts | Each document type is now wrapped up in a handler. | 22:13.50 |
| | And we register handlers with the context. | 22:13.55 |
| | Then fz_open_document etc call the handlers in turn. | 22:14.07 |
| zeniko | (also, some of these are tweaks which never made it into your repo but just into SumatraPDF's) | 22:14.09 |
| Robin_Watts | It's so we can build with/without different types just by registering different sets. | 22:14.22 |
| mvrhel_laptop | so if I handle xps, oxps, pdf, cbz I need to register each of these type? | 22:14.30 |
| henrys | zeniko:I'll have a look | 22:14.35 |
| mvrhel_laptop | I will read the commit message | 22:14.35 |
| Robin_Watts | For convenience we have 'fz_register_document_handlers' that registers all of them. | 22:14.37 |
| | So, all you need to do is to call fz_register_document_handlers after your fz_new_context call, and you'll be sorted. | 22:14.58 |
| mvrhel_laptop | ok thanks | 22:15.11 |
| | Robin_Watts: ok thanks. that fixed the issue | 22:16.56 |
| | I am just going to ammend this to the commit you reviewed | 22:17.12 |
| | since I have not pushed it yet | 22:17.18 |
| | I will fix my commit message too | 22:19.45 |
| | ok all pushed to golden. now I will work on getting this thing updated in the store | 22:28.05 |
| | Forward 1 day (to 2014/01/10)>>> | |
IRC Logs