| | <<<Back 1 day (to 2014/02/13) | 2014/02/14 |
| henrys | well after my macbook died I was able to plug the hard drive right into an ATA cable free slot in the mac pro and use everything. | 00:02.38 |
| Robin_Watts | what caused the problem, do you know? | 00:15.30 |
| | haha. I went looking for this: http://xkcd.com/1328/ | 00:16.00 |
| | and I found this: http://xkcd.com/ | 00:16.13 |
| henrys | they told me the logic board was damaged as if it were dropped, (it was) | 00:17.28 |
| | I didn't know you weren't supposed to drop them | 00:18.30 |
| | ;-) | 00:18.32 |
| Robin_Watts | :) | 00:20.54 |
| | did it fall off the pony? | 00:21.10 |
| henrys | and didn't get back up ... | 00:23.36 |
| sibizulu | Hi | 08:32.24 |
| | Any one is there with mupdf | 08:33.02 |
| | ? | 08:33.04 |
| | I have some small doubts. | 08:33.51 |
| | Can any one help me? | 08:34.10 |
| kens | At this time probably not, MuPDF developers shouldbe online in 2 hours or so. In the meantime, type your question. | 08:34.39 |
| | on IRC its best just to ask questions, not to ask if you can ask | 08:34.56 |
| sibizulu | 1. Mupdf have any feature to merge two pdf ? | 08:35.40 |
| kens | No | 08:35.48 |
| sibizulu | 2. can we slice/split a pdf? | 08:36.21 |
| kens | Again, no. | 08:36.28 |
| | Or rather, not as it currently stands | 08:36.44 |
| sibizulu | I check the docs. But nothing fount there. Ok fine. Thank you for the support | 08:37.04 |
| kens | THe library is entirely capable of interpreting a PDF file, but there are currently no facilities to manipulate PDF files in this way. MuPDF is designed as a PDF reader. | 08:37.17 |
| sibizulu | ok fine | 08:37.44 |
| kens | Such features may be added in future | 08:37.49 |
| Robin_Watts | kens: mupdf can split a pdf. | 09:08.24 |
| | mutool clean -ggg in.pdf out.pdf 1-10 | 09:08.46 |
| | will split out the first 10 pages, etc. | 09:08.56 |
| kens | D'oh sorry robin | 09:08.58 |
| Robin_Watts | np. | 09:09.07 |
| tor8 | paulgardiner: ping. | 10:39.20 |
| | oh, wait, it's friday? | 10:39.26 |
| paulgardiner | hi tor8 | 10:39.29 |
| | Nah, I'm working today. | 10:39.38 |
| tor8 | paulgardiner: there's a handful javascript related commits on tor/master | 10:39.46 |
| paulgardiner | Oh okay. I'll take a look | 10:39.58 |
| tor8 | so I've nailed down the remaining errors we get. | 10:41.25 |
| | half of them are due to us not coping with \d in regexps yet :( | 10:41.51 |
| | the other half are all using invalid javascript features, like leading zeroes in numbers | 10:42.15 |
| | AFRange_Validate(true, 08, true, 35); | 10:42.22 |
| | yeah, that 08 can't possibly be expected to be parsed as an octal number now can it? ;) | 10:42.35 |
| | I've spotted a number of errors due to us missing a few features: event.change and x.setFocus() | 10:43.20 |
| | maybe we should have blank stubs for setFocus even if we don't implement it (so as not to cause the scripts to crash with TypeErrors all the time) | 10:43.52 |
| paulgardiner | The 08: is that a mistake in the specific file, or something in my js? | 10:44.22 |
| tor8 | paulgardiner: that's a typical error in the files we come across | 10:45.13 |
| | not of our doing | 10:45.22 |
| | morning Robin_Watts | 10:45.35 |
| paulgardiner | tor8: an error also with v8? | 10:46.04 |
| tor8 | paulgardiner: no, v8 swallows it without complaint | 10:46.17 |
| | but I have no idea what it parses 08 as... octal or decimal | 10:46.26 |
| paulgardiner | I wonder what Adobe do. | 10:46.34 |
| tor8 | there is a compatibility section in the ecmascript spec, which adds octal numbers | 10:46.52 |
| | but octal numbers have been removed from javascript and are supposed to be syntax errors, due to rookie mistakes like this | 10:47.17 |
| | anyway, need to head out for lunch. be back in an hour or so. | 10:47.44 |
| | I pushed the WIP on the libjs integration, if you're curious about the shape of it all | 10:47.55 |
| Robin_Watts | morning tor8 | 10:57.50 |
| kens | thinks tor8 is out to lunch | 10:58.23 |
| Robin_Watts | kens: yes, I was just responding to his "morning" of earlier. | 10:59.18 |
| kens | :) | 10:59.28 |
| | I just enjoyed noting that Tor was completely out to lunch :-) | 11:00.17 |
| paulgardiner | Robin_Watts: did you get a chance to give my corrected commit a quick look? | 11:24.44 |
| Robin_Watts | no. will look now. | 11:25.27 |
| paulgardiner | ta | 11:25.32 |
| Robin_Watts | has just fetched flowers from shop. | 11:25.45 |
| | My status as "good husband" is renewed for another year. | 11:25.55 |
| | or until I forget something. | 11:26.10 |
| | paulgardiner: fz_rect rect = {0.0f,0.0f,0.0f,0.0f}; | 11:53.02 |
| | Would be nicer as fz_rect rect = fz_empty_rect; | 11:53.12 |
| paulgardiner | ah yes | 11:53.32 |
| Robin_Watts | Also, did you see my comments before about pdf_create_widget? | 11:54.50 |
| paulgardiner | Maybe mist that | 11:55.08 |
| Robin_Watts | In the code I'm looking at, you start by doing a pdf_create_annot. | 11:55.09 |
| paulgardiner | missed even | 11:55.13 |
| Robin_Watts | Then you do a load of other stuff that might fail. | 11:55.19 |
| paulgardiner | Bah! Monday morning code. | 11:55.37 |
| Robin_Watts | Either you need some try/catchery in there to back out that pdf_create_annot, or you need to reorder slightly. | 11:55.44 |
| | I suspect that you need to create Root/AcroForm/Fields first. | 11:55.58 |
| | Then do the rest of it, then do pdf_create_annot last, so you can back out the rest of it if it fails. | 11:56.49 |
| | backing out a pdf_create_annot if other things fail is probably harder I suspect. | 11:57.11 |
| paulgardiner | try/catch might be simpler and hardier to later additions | 11:57.46 |
| Robin_Watts | I think you can't escape try/catch :( | 11:58.05 |
| paulgardiner | Ah. I remember now. It wont leak. It would just leave an inconsistent annot. | 12:01.20 |
| Robin_Watts | right, but inconsistent is bad. | 12:01.47 |
| | If we do the pdf_create_annot last, we can avoid even that, right? | 12:02.02 |
| paulgardiner | Yes. Looks hellish to get right though.. Maybe not. The main thing to avoid is having the new obj in one of the annot list and form hierarchy, but not both | 12:03.48 |
| | If I perform pdf_array_push(form, annot->obj) last, I just need to delete the created annot in the catch | 12:05.03 |
| | SigFlags are harmless | 12:05.45 |
| tor8 | paulgardiner: back. | 12:20.11 |
| paulgardiner | All looks fine tor8 | 12:20.21 |
| tor8 | paulgardiner: fab! | 12:20.29 |
| paulgardiner | ... and adds to my understanding of javascript. :-) | 12:21.09 |
| tor8 | paulgardiner: did you look at the libjs implementation as well? | 12:26.12 |
| paulgardiner | oh no. Where's that then? | 12:26.36 |
| tor8 | if you pull again, it's on tor/master | 12:26.51 |
| | I'm wondering if it'd make sense to create wrappers around v8/jscore with a subset of the libjs api | 12:27.25 |
| | and use the same prototype object tricks for native objects | 12:27.49 |
| paulgardiner | I don't know. Is the current pdf_jsimp api unnatural in any way. Its fairly simple. | 12:29.22 |
| | And was intended to be driven by what MuPDF needed rather than to be like any particular implementation. | 12:30.03 |
| tor8 | holding on to objects that could end up being garbage collected without registering them as gc roots worries me | 12:30.03 |
| | not that you hold on to them for long, all you do is return them as soon as you've created them | 12:30.26 |
| paulgardiner | tor8: I have that covered in the v8 implementation | 12:30.29 |
| | I believe | 12:30.38 |
| | I certainly remember having to do something quite intricate to make sure that wasn't a problem. | 12:31.11 |
| tor8 | paulgardiner: I treat pdf_jsimp_obj as integers, holding the stack index of the value. that works fine for arguments, but pdf_new_obj pushes an object onto the stack and takes that index, which won't be valid past the current function | 12:31.31 |
| | as long as you never do more than create transient objects that you return to javascript as a return value, we should be fine | 12:32.12 |
| paulgardiner | With v8, I make calls that protect the objects from garbage collection. | 12:33.51 |
| | Which I then release when the pdf_jsimp objects are freed | 12:34.21 |
| | I have some recollection of the jscore imp being safe too, but I cannot remember why. | 12:34.52 |
| | Perhaps the jscore api also has a function to make objects protected. | 12:38.47 |
| | Yeah. JSValueProtect in the jscore case | 12:41.02 |
| tor8 | paulgardiner: am I correct in assuming that the jscore code never calls the destructor function? | 12:42.25 |
| | (shouldn't matter, since you never actually pass any destructors to new_type) | 12:42.58 |
| paulgardiner | That's right, but it does cause a memory leak. I do have a plan to fix it, but haven't found the time | 12:43.55 |
| | IIRC, priv_data never gets freed. | 12:44.55 |
| | The two things pointed to by priv_data don't need freeing, but the struct itself should be and isn't. | 12:45.45 |
| tor8 | paulgardiner: I assume that the pdf_jsimp_new_obj userdata pointers (the pdf_obj dicts, etc) aren't actually supposed to be reference counterd by the javascript code that points to them? | 12:46.16 |
| | I would have assumed that for example the js->fieldtype destructor would call pdf_drop_obj | 12:46.56 |
| | but then you need to keep_obj when passing it to javascript | 12:47.08 |
| paulgardiner | Where's that? | 12:47.51 |
| tor8 | doc_getField | 12:48.09 |
| | you're wrapping up a pdf_obj dictionary and passing it to javascript | 12:48.25 |
| | paulgardiner: if I may, one idea just came to me; instead of return pdf_jsimp_new_obj, would it be possible to call say pdf_jsimp_return_obj() instead? | 12:50.43 |
| | and then maybe that could simplify the wrappers? | 12:51.03 |
| norbertj | hello tor8: can you have a look at the attachement of BUG 695017 (on the memleaks of xpszip.c) | 12:52.17 |
| paulgardiner | Hmmm. Re the previous question: I'm assuming the looked-up dict isn't going anywhere (which tend to be true, but as you point out isn't guaranteed). That is what the destructors are for but aren't currently wired up. | 12:54.45 |
| tor8 | norbertj: looking now. | 12:55.04 |
| norbertj | tor8: thanks | 12:55.23 |
| paulgardiner | So we could addRef the dict in pdf_jsimp_new_obj and have the destructor call drop. | 12:56.12 |
| tor8 | paulgardiner: yeah, that would be my suggestion. | 12:56.47 |
| paulgardiner | That was the intention originally | 12:57.11 |
| | But I'd gotten to think of the doc as unchanging and hence those objects lasting until the doc is freed. Of course the fact that we now have more interactive features makes that untrue | 12:58.57 |
| tor8 | norbertj: in xps_process_file, the non-error case when running on a ".fpage" file, won't that still leak? | 13:01.30 |
| paulgardiner | I'd have thought changing return new() to return() would make the implementation harder to code because it would occur to the caller as a sort of callback if I'm undettanding correctlly | 13:01.41 |
| tor8 | paulgardiner: well, the jsimp would have to stow it away somewhere and it wouldn't come out of the callback, that's true | 13:03.07 |
| | jsimp_call_method -> callback -> jsimp_return_obj | 13:03.38 |
| | that's the call chain I mean | 13:03.49 |
| | maybe it's more complicated, but it's more like what I need for the libjs api where pointers to javascript objects are forbidden | 13:04.16 |
| | (there's an escape hatch, but it's something I'd like to avoid, by registering the pointer to the object in the "registry" table) | 13:04.40 |
| paulgardiner | Hmmm. I can't say I understand all the issues involved but it seems common to provide a way to allow it. | 13:05.29 |
| tor8 | paulgardiner: yes, by somehow messing with the garbage collector so it will treat the objects as a gc root | 13:06.04 |
| | which is exactly what the libjs registry is for | 13:06.21 |
| | but using that for temporary return values seems overkill to me | 13:06.30 |
| | but maybe that's the only way to do it with v8 and jscore | 13:06.40 |
| norbertj | tor8: indeed before the "return gs_okay: there should also be a free of directory, and close of file I think. | 13:06.52 |
| paulgardiner | tor8: sorry lost me on that last one | 13:08.56 |
| norbertj | tor8: so last part would become: | 13:09.34 |
| | code = xps_parse_fixed_page(ctx, part); if (code) { retval = gs_rethrow1(code, "cannot parse fixed page part '%s'", part->name); } xps_free_part(ctx, part); if (ctx->directory) xps_free(ctx, ctx->directory); if (ctx->file) fclose(ctx->file); return retval; } | 13:09.35 |
| | eeks. | 13:09.45 |
| tor8 | norbertj: yes. I have massaged your patch to do a "goto cleanup" which contains the free of directory and close of file. I have pushed it to my local ghostpdl repository, if you could give it a look I'd appreciate it. | 13:09.51 |
| paulgardiner | tor8: though lost me only because I was accidently reading your other conversation. :-) | 13:10.24 |
| tor8 | http://git.ghostscript.com/?p=user/tor/ghostpdl.git;a=commitdiff;h=c5ad5b7f373313e9bc7b8991cc9e34506e627e0a;hp=1e93c580b175ac086db942c32fab055c6062e8e4 | 13:10.28 |
| | paulgardiner: sooo... should I rephrase or are we good? | 13:11.52 |
| paulgardiner | tor8: I think I get what you mean by the return call. That sounds a bit like the way some VMs work. The VM runs along happily until it hits something that needs to be done by native code and then the native code makes calls that access the VMs registers and performs explicit VM operations (such as return).. Is that similar. | 13:12.35 |
| norbertj | tor8: looks ok to me | 13:13.04 |
| tor8 | paulgardiner: yeah, that's basically what I mean | 13:13.25 |
| | and that's how libjs works, sort of. | 13:13.34 |
| paulgardiner | We are probably good, although I'm not sure what we agreed. :-) | 13:14.01 |
| tor8 | paulgardiner: just thinking out loud :) | 13:14.15 |
| | paulgardiner: I have one change to your actual API, nothing crucial but I think it might make things a bit clearer: pass a name to the type constructor functions | 13:14.49 |
| | paulgardiner: it's on tor/master now | 13:15.43 |
| | norbertj: just running a test, then I'll commit | 13:16.07 |
| paulgardiner | tor8: looks good to me. | 13:17.10 |
| tor8 | paulgardiner: thanks. | 13:17.39 |
| paulgardiner | tor8: I'm not at all against changes to the api. I'm just putting forward arguments to make sure you are aware of the reasoning behind some of the choices, in case they impact on your thoughts. I'd expect your deeper understanding of js to possibly suggest improvements. | 13:19.12 |
| tor8 | paulgardiner: if you look in pdf-jsimp-mu.c on the latest tor/master, the function wrapmethod() | 13:19.53 |
| | you can see a fairly clear example of how the API works | 13:20.20 |
| paulgardiner | yep | 13:20.22 |
| tor8 | I've stowed two properties on the function object, the __call and __type which hold the wrapped method and a sanity check type string | 13:20.59 |
| | so that we don't go calling the functions on the wrong type of object | 13:21.10 |
| | if that happens, we call the wrapped function with obj=NULL, so that may segfault as well | 13:21.32 |
| | but some of the functions don't have an obj, so not sure how to deal with that | 13:21.46 |
| paulgardiner | Right. Some time I should make use of the name to protect types in the other implementations. | 13:21.58 |
| | I think in v8, whatever js object I attached to the type is passed to the call | 13:23.01 |
| | ... even if there is no object | 13:23.11 |
| tor8 | and in pdf_jsimp_new_obj you can see how I pull out the prototype object from the registry, and use that to create the javascript object that wraps the native data | 13:23.20 |
| paulgardiner | All looks very clean. | 13:23.57 |
| tor8 | paulgardiner: what happens if you do getField.apply(event) for instance, in v8? | 13:24.01 |
| | or the equivalent: event.getField = getField; event.getField("foo") | 13:24.51 |
| | in that case, nothing since doc_getField ignores the "obj" argument | 13:25.08 |
| | but you know what I mean | 13:25.17 |
| paulgardiner | I wish I did. :-) | 13:28.22 |
| tor8 | paulgardiner: in v8, callMethod(), I take it args.Holder() returns the 'this' value for the method call? | 13:29.41 |
| paulgardiner | Yes. Were getField to access obj it would not be of the type expected. | 13:30.10 |
| tor8 | and then you call GetInternalField to extract a C pointer you've stashed | 13:31.09 |
| paulgardiner | That's right about Holder | 13:31.12 |
| tor8 | but if the wrong 'this' argument is passed, the types won't match and you could get garbage | 13:31.27 |
| paulgardiner | Yep. | 13:31.57 |
| tor8 | so you need to do a manual type check for all methods, is the 'this' value of the correct type for this method | 13:32.02 |
| paulgardiner | Yeah, you're right. | 13:32.23 |
| tor8 | which is what I added the 'name' parameter to new_type for (though you could store a pointer to the js_pdfimp_type as well I reckon) | 13:32.40 |
| | the javascript spec has all this talk about an internal "class" value for objects | 13:33.01 |
| paulgardiner | tor8: Yes, I understood what you intended the name for. Definitely better. | 13:33.46 |
| | It seems that args.Data() is the stashed method info that I mentioned - the thing that surprised me in v8 and allowed me to avoid look up in the method call | 13:36.14 |
| | Data() is specific to the method not the object to which the method is applied. | 13:37.09 |
| tor8 | paulgardiner: oh, right. it's equivalent to what I do with js_currentfunction() and getting properties from that. | 13:37.55 |
| | args.Data() is not very documented though :( | 13:38.53 |
| | http://izs.me/v8-docs/classv8_1_1Arguments.html is that where you look at v8 docs? | 13:39.03 |
| | or do you have a better reference/ | 13:39.07 |
| | and I wonder what the difference is betweer args.Holder and args.This | 13:41.08 |
| paulgardiner | I think that site is what I used. I also read a tutorial | 13:42.16 |
| | https://developers.google.com/v8/get_started | 13:43.04 |
| | https://developers.google.com/v8/embed | 13:43.10 |
| tor8 | paulgardiner: I can't fathom how you can stand all this C++ | 13:43.36 |
| paulgardiner | I usually like C++ because of the easier string handling and the access to collection types without creating them yourself, but v8 took me a bit out of my depth. | 13:44.57 |
| | Can't say I really understand what is going on with all the templating. | 13:46.28 |
| tor8 | norbertj: I have pushed the commit now, is there anything else to be done for that bug? | 13:49.01 |
| norbertj | tor8: for the bug yes, but that is probably in PCL/PXL (for henry to look at). | 14:04.42 |
| paulgardiner | Robin_Watts: new version up. | 14:11.38 |
| Robin_Watts | paulgardiner: OK. | 14:27.46 |
| paulgardiner | OK as in LGTM? | 14:28.16 |
| Robin_Watts | yeah. | 14:28.21 |
| paulgardiner | ta | 14:28.25 |
| chrisl | mvrhel_laptop: good morning - you'll be pleased to hear that the pressure's off about that Surface Ghostscript bug.... | 14:56.58 |
| kens2 | I'm kind of surprised his temp directory was set liek that, miine is already set to %USERPROFILE% etc | 14:57.47 |
| henrys` | it's amazing how much I miss my laptop, it really can become an appendage | 14:58.15 |
| kens2 | henrys did you see the xkcd cartoon about standing desks ? | 14:58.37 |
| chrisl | kens2: it may be part of the install process, given that GS seems to be being used in a larger system.... | 14:58.49 |
| henrys` | kens2 no I must have missed that I'll go look | 14:59.12 |
| kens2 | chrisl its possible, just odd tht mine was set up in a working way and his wasn't, but yes | 14:59.14 |
| | henrys the one from Wednesday if memory serves | 14:59.24 |
| | http://www.xkcd.com/1329/ | 14:59.37 |
| Robin_Watts | henrys: I pasted that to henrys yesterday. | 14:59.52 |
| henrys` | oh that's right | 15:00.06 |
| Robin_Watts | just after: http://www.xkcd.com/1328/ | 15:00.13 |
| kens2 | I must have missed that in the logs | 15:00.17 |
| Robin_Watts | both of which seem apt :) | 15:00.23 |
| | mvrhel_laptop: I think I found the problem in the PDF export. | 15:18.27 |
| | The 'Widths' of the fonts were being generated incorrectly (a "1024" in the code where it should be "1000") | 15:18.50 |
| | am trying for a rebuilt app now. | 15:19.12 |
| mvrhel_laptop | chrisl: that is good news | 15:27.29 |
| | Robin_Watts: that is even better news | 15:27.35 |
| ray_laptop | mvrhel_laptop: I thought you werre out this AM | 15:28.21 |
| mvrhel_laptop | Robin_Watts: I am out for a while this morning but will try out the new version when I get back | 15:28.28 |
| | ray_laptop: soon I am | 15:28.38 |
| | kids have no school today so need to adjust schedule a bit | 15:28.58 |
| Robin_Watts | mvrhel_laptop: No worries. I'll let you know when/if I get stuff uploaded. | 15:29.06 |
| ray_laptop | my two older kids are off, but my youngest has school. At least they can be left home if needed. | 15:29.45 |
| Robin_Watts | mvrhel_laptop: I sill see images missing on page 15. will have to look into that. | 15:39.34 |
| henrys` | chrisl: you fixed norbert's bug right? 695044? | 15:45.26 |
| | I seem to remember you working on that. | 15:45.47 |
| chrisl | henrys`: no, I don't believe so - he says the performance drop came in 9.07, which was before the FAPI work | 15:46.51 |
| henrys` | chrisl:oh okay. | 15:48.10 |
| chrisl | henrys`: the implication, however, is that the current master code is okay for them, so I wasn't going to worry too much about it | 15:48.56 |
| henrys` | chrisl: sure just bugs me not knowing the source of the issue. | 15:49.21 |
| chrisl | henrys`: If you're concerned, I can bisect it on Monday | 15:51.30 |
| henrys` | oh no don't bother | 15:54.47 |
| | 20,000 pages - geez | 15:55.35 |
| | did a linux upgrade and it logs me out when I log in, hmph | 16:13.43 |
| tor8 | henrys`: I hate it when that happens. I suspect some stupid desktop config file causing something to crash. | 16:21.22 |
| | henrys`: try moving .config out of place | 16:21.36 |
| henrys` | tor8: yeah it's really hopeless to think linux can make inroads with normal users with this kind of nonsense. "Well your .Xauthority isn't 600, what the heck is wrong with you?" | 16:23.04 |
| Robin_Watts | Or it could be something in .login, or .profile, or .bash_rc or .bash_profile or .cshrc or... whatever the current flavour of the month is. | 16:23.05 |
| | http://benguild.com/2011/02/14/apples-remote-desktop-software-is-secretly-bundled-for/ | 16:23.30 |
| tor8 | VMware was making some noise about having a remote desktop to windows-in-the-cloud app for chromebooks the other day | 16:24.58 |
| henrys` | I've been using screen sharing for ages | 16:25.19 |
| | paulgardiner: this is after Robin_Watts has told me this a very modular code base, . exactly opposite of what your email implies. Very hard for me to sort out what's what with these differing descriptions of the code. | 16:41.00 |
| Robin_Watts | There are many modules. | 16:43.07 |
| | But they have wierdass dependencies. | 16:43.19 |
| paulgardiner | Well bits of it are modular. And much of it was orignally modular, but then many changes have been rushed in with sticky tape | 16:43.21 |
| Robin_Watts | The bits we originally wanted - fairly nicely modular. | 16:44.05 |
| paulgardiner | And in UE2 the problem is the modularity. There's the 7 layers of hell: a whole lot of modules that exist at multiple levels. | 16:44.06 |
| henrys` | about Robin_Watts mail - In speaking to Miles open source is not going to happen. I just don't see him doing that at all. | 16:44.07 |
| | don't kill the messenger | 16:45.37 |
| paulgardiner | With so many people working on it for such a long time, there was a variety of approaches. Some people strove for modularity. Others I've overheard saying "all our products will be based on TGV so I'll make this new feature part of TGV" | 16:47.35 |
| | henrys`: in some ways I'd quite like to rework UE2. It could have been much cleaner, but I think by that I mean "I'd quite like to rework UE2 if I had a few years with nothing else to do". | 16:49.22 |
| Robin_Watts | and an infinite supply of electroshock therapy. | 16:50.00 |
| paulgardiner | Probably. If I was given the opportunity, I'd likely regret it. | 16:51.22 |
| Robin_Watts | If we do MuPDF-Office, then not open sourcing it would be insane. It'd require us to change the way we work fundamentally. | 16:53.23 |
| | and we'd get no user feedback, and no bug reports etc. | 16:53.36 |
| | I will be making this point to Miles at the meeting in Texas. | 16:54.00 |
| paulgardiner | I guess it is modular as software goes. It's the huge number of modules and the complex interdepenence and the fact that many use threading internally, rather than relying on being threaded from outside if needs be. | 16:54.43 |
| Robin_Watts | He was at pains to ensure that in the source license deal he has the right to open source. | 16:55.08 |
| paulgardiner | Hmmm. Opensourcing an app you expect revenue from. I see why that has problems. | 16:55.50 |
| Robin_Watts | paulgardiner: That's why we use the GPL. | 16:56.05 |
| | "If you're prepared to completely give away anything you build using our software, then we'll completely give our software away to you" | 16:56.40 |
| paulgardiner | I guess the whole app doesn't have to be opensource. The bits that MuPDF might use would be a very small subset | 16:56.41 |
| Robin_Watts | paulgardiner: Right. It would be insane (impossible) to open source SOT. | 16:57.05 |
| | It would be insane not to open source the "MuPDF-Office" library. | 16:57.21 |
| paulgardiner | Robin_Watts: yeah but they can sell it under the GPL. They can just build our source with no changes and sell it | 16:57.22 |
| Robin_Watts | to whom? | 16:57.37 |
| | anyone that buys it could get it for free. | 16:57.49 |
| | That's exactly the situation we're in with mupdf and gs, and it doesn't happen. | 16:58.00 |
| henrys` | Robin_Watts:that's not the issue. | 16:58.20 |
| paulgardiner | Sorry, I'm talking about the smartoffice app, which I realise you aren't | 16:58.22 |
| henrys` | Robin_Watts: with the new business agreements floating around associated with the new plan more caution is needed with the source code. I don't think that is insane. | 16:59.46 |
| | I'm rethinking it myself. | 17:00.16 |
| | here is my problem https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1114418 | 17:02.42 |
| Robin_Watts | henrys: Sure, let's be cautious, but in all the legal stuff I've read, I've not seen any blockers to open sourcing. | 17:03.49 |
| | If I had seen any blockers to open sourcing, I'd have been shouting about it. | 17:04.10 |
| henrys` | Miles also has to struggle with knowing that you and paul did a perfect job not letting anything slip by whatever the patent interpretations could possibly be. A non source code release is easily fixable, a GPL mistake is disaster. I'd have difficulty with decision too. | 17:07.20 |
| Robin_Watts | henrys: That is true. | 17:08.50 |
| | but then that's part of what code reviews are for. | 17:09.02 |
| | and as software engineers we run the patent gauntlet every day. | 17:09.19 |
| henrys` | Not where the patent holder is a company that you are currently doing business with in the interest of selling a related product. This just got much more complicated in my mind when we moved from the last deal we had. | 17:14.58 |
| Robin_Watts | and it's fairly clear to me that the only possible patent encumbrance is the Edr one. | 17:14.59 |
| henrys` | not beat a dead horse: paulgardiner, Robin_Watts: How is it that Bipartate can maintain the code? They don't seem to have much more resource-wise that us? | 17:18.34 |
| | s/that/than | 17:18.46 |
| | or you think they aren't really keeping up with it? | 17:19.00 |
| Robin_Watts | henrys: They don't have much more resource than us. | 17:19.01 |
| | They *do* have less of a 'relearning curve' as they are basically the guys who have been dealing with it for the past few years. | 17:19.28 |
| henrys` | Robin_Watts: yes true. | 17:19.44 |
| Robin_Watts | but I strongly suspect that their support will be purely of the fighting fires variety. | 17:19.48 |
| | I can't see them getting much new development done. | 17:19.59 |
| henrys` | right they aren't making development moves. | 17:20.10 |
| | anyway I have an errand. bbiab | 17:20.36 |
| | chrisl, tor8:wow I think urw might be willing to do cyrillic in the GPL fonts. | 17:21.34 |
| | great news | 17:21.42 |
| chrisl | Yay! | 17:21.47 |
| zeniko | henrys: are the remaining valgrind issues supposed to be fixed for release? | 17:23.29 |
| | if so, there are two patches on zeniko/ghostpdl for review and landing (one of them is Shelly's) | 17:23.58 |
| henrys` | zeniko we should fix everything for the release | 17:24.37 |
| | ;-) | 17:24.40 |
| zeniko | and where do Freetype patches go? ghostpdl (which doesn't work for MuPDF AFAICT) | 17:25.37 |
| henrys` | I'll look at them when I get back I do prefer a git format patch attached to the bug that I can appy. I think it's better bookkeeping | 17:25.38 |
| | s/appy/apply | 17:25.51 |
| Robin_Watts | zeniko: We've not had to patch freetype before. | 17:26.04 |
| | chrisl has passed bug fixes up to werner I believe, who is very good at applying them and doing new releases. | 17:26.26 |
| zeniko | I'll report the infinite loop upstream, then. | 17:26.50 |
| | henrys`: I've attached git format-patch diffs to bug 694880 and bug 694906 | 17:31.28 |
| | tor8: have you decided on what regex engine you'll use for libjs yet? | 17:32.35 |
| | else, I could look into integrating my t-rex fork into libjs over the weekend | 17:33.29 |
| Robin_Watts | mvrhel_laptop: I have the remaining images being output in the PDF conversion now. | 17:34.52 |
| | I'm not 100% how clean my code is though. I might be leaking horribly. | 17:35.05 |
| tor8 | henrys`: wow, that's good news! (re: URW and cyrillic fonts) | 17:46.01 |
| | zeniko: not yet, was planning on doing it next week. I just got the basic libjs + mupdf integration done this week, and everything except some of the regexp syntax seems to work! | 17:46.38 |
| Robin_Watts | marcosw_: Morning. | 18:15.04 |
| marcosw_ | morning Robin_Watts | 18:15.14 |
| Robin_Watts | I am working on some fixes to the PDF extraction for the SOT stuff. | 18:15.47 |
| | Once I get them in could I trouble you to rerun the tests please? | 18:15.56 |
| marcosw_ | of cpurse, just let me know when you are ready. | 18:16.18 |
| Robin_Watts | Thanks. | 18:16.23 |
| marcosw_ | just the pdf output, not the bmp, correct? | 18:16.37 |
| Robin_Watts | correct. | 18:16.55 |
| locsmif | Hi all. When you set orientation to landscape, does the coordinate system rotate along with it? | 18:17.02 |
| Robin_Watts | I hope that with these changes the PDF should match the bmps. | 18:17.13 |
| marcosw_ | i can run a bmp <-> pdf comparison, if that's what we are interested in. | 18:18.01 |
| Robin_Watts | That might be informative, yes. | 18:18.31 |
| | marcosw: OK. New version pushed. thanks. | 18:31.47 |
| marcosw_ | I'll have results by tomorrow, assuming nothing goes wrong. | 18:32.30 |
| Robin_Watts | ta. | 18:33.24 |
| marcosw_ | Robin_Watts: btw, how does one do a make clean with the FBS? | 18:47.41 |
| Robin_Watts | delete the genroot dir | 18:47.51 |
| marcosw_ | I'm getting the same compiler warnings (errors) as before, did you not add the casts to the repository? | 18:48.34 |
| Robin_Watts | I didn't. sorry. | 18:48.55 |
| | I will do. | 18:48.59 |
| henrys` | marcosw: so much crap has accumulated doing upgrades on henrysx6 I want to do a clean linux install. Is that okay? | 19:05.23 |
| | cd | 19:05.42 |
| marcosw_ | henrys`: off course. let me know when you are done and I'll reinstall the cluster stuff (or you can do it, the instructions on casper in ~regression/cluster/readme should be up to date). | 19:08.46 |
| | ^off^of | 19:08.52 |
| Robin_Watts | mvrhel_laptop, henrys: New GhostDocs.apk - if you could give it a whirl, I'd be grateful. | 19:11.33 |
| marcosw_ | Robin_Watts: here are the consolidated changes needed for epage | 19:27.46 |
| | http://pastebin.com/UEud1n2j | 19:27.48 |
| henrys` | Robin_Watts: I have to assume sabrina took the android to the coffee shop I will test when she gets back. | 19:57.07 |
| mvrhel_laptop | Robin_Watts: I am back. will give it a try | 20:18.10 |
| marcosw | Robin_Watts: I've looked at the quality logic epage bmp vs pdf output and there are still differences. I'll open bugs. | 20:26.12 |
| Robin_Watts | marcosw: Ah, thanks. | 20:34.35 |
| | marcosw: Feel free just to mail me a link and I'll run through. | 20:38.21 |
| marcosw | Robin_Watts: I won't say no to that. I've emailed you the link to all the files (I've only looked at the quality logic ones). | 21:09.51 |
| Robin_Watts | Thanks. At this stage it's easier for both of us I think. | 21:10.11 |
| | underlines are an obvious one. | 21:13.42 |
| ray_laptop | Robin_Watts: BTW, we _do_ have precedent (Luratech) for having non-opensource components | 21:16.23 |
| Robin_Watts | ray_laptop: That's a non opensource component we've bought in. | 21:16.49 |
| ray_laptop | Robin_Watts: AIUI, it's cross-licensed, but still, we've given up revenue. And we developed interface code, and other code for them | 21:17.53 |
| | there is nothing in the Artifex charter that requires that ALL components we develop are open source. | 21:18.25 |
| | Scott would be a bit happier to be able to sell including some non opensource technology, I'm sure | 21:19.00 |
| | there _is_ a requirement that Ghostscript be open source. Even the other parsers (XPS, SVG and PCL) don't have any restrictions against not releasing source | 21:20.01 |
| | now, some of the staff may have a 'religious' devotion to open source, but that's different | 21:20.54 |
| Robin_Watts | All true, but nonetheless we have chosen to embrace the open source way of working, and it's worked well for us. | 21:21.13 |
| | Were it not for the patent issues, I would think we'd be silly to work any other way. | 21:21.33 |
| | the patent issues and the commercial relationship we have/might have with the patent holder does complicate things. | 21:22.00 |
| | but not to the point of making it a non starter. | 21:22.18 |
| | I think this is something that bears discussion. | 21:22.28 |
| ray_laptop | I get a bit tired of answering the question (and getting skepticism about my reply) | 21:22.43 |
| | Robin_Watts: I'm not sure 'silly' is how I'd describe working with non opensource. | 21:23.48 |
| | I thought of another non opensource deviation -- UFST | 21:24.06 |
| | separate licenses, in that case, of course | 21:24.32 |
| Robin_Watts | again, a bought in component. | 21:25.20 |
| ray_laptop | as it is, for anyone to work for us, even as a volunteer, usually requires a NDA and access to the regression testing, otherwise it becomes very cumbersome to accept (untested) patches | 21:26.19 |
| | Robin_Watts: and SOT is a bought in componemt, isn't it ? | 21:27.14 |
| Robin_Watts | ray_laptop: Right, and I'm not suggesting we open source SOT. | 21:27.31 |
| | I am suggesting that we open source the office library that we develop from it. | 21:27.51 |
| | That'd be a much smaller, cleaner, entity. | 21:28.10 |
| ray_laptop | Robin_Watts: I thought open sourcing Office import (based on the bought in SOT technology) was exactly what you were proposing | 21:28.30 |
| | Robin_Watts: that means that we buy in the SOT, then open source it | 21:29.12 |
| Robin_Watts | The SOT code is a huge lump of patent encumbered code. We wouldn't want to open source that. | 21:29.16 |
| ray_laptop | Robin_Watts: of course not | 21:29.27 |
| Robin_Watts | The original proposal that I pitched to Miles/Henry that got this whole thing started was that we buy in the tiny section of the code that does office format handling. | 21:30.03 |
| ray_laptop | Robin_Watts: once we discover whether or not there is revenue from real customers, I'd be against open sourcing to all of the cheaters. | 21:30.25 |
| Robin_Watts | and we take that, and use it to give us a leg up to handling office formats ourselves. As such it would end up substantially reworked. | 21:30.45 |
| ray_laptop | It still pisses me off how much money (my money, too) was put into mupdf and then have so many cheaters. Open source encourages cheaters | 21:31.23 |
| | I have the fervent hope that mupdf will eventually be a net win. | 21:32.46 |
| | and having a proprietary component tied into mupdf might help that | 21:33.43 |
| | I propose that we go open source when 1) we determine that we can't make money on it anyway -- and aren't going to devote manpower to it, or 2) determine that there is a business case and that open source is compatible with that ('cause we are all filthy, stinking rich?) | 21:36.03 |
| Robin_Watts | We clearly have different opinions on many things | 21:38.36 |
| ray_laptop | well, I'd like to hear your business plan | 21:39.08 |
| | I _do_ like making money off of work. Otherwise, things can go south fast | 21:39.45 |
| Robin_Watts | The GPL ensures that we make money of of our work. | 21:40.14 |
| ray_laptop | At some point Miles may decide to "exit". Not very many purchasers will be as laid back | 21:40.40 |
| Robin_Watts | The GPL ensures that people can't build our code into anything they charge for. Hence we lose not a single paying customer by doing a GPL release. | 21:41.13 |
| ray_laptop | Robin_Watts: the GPL does NOT ensure that we make money. | 21:41.45 |
| Robin_Watts | On the plus side, a GPL release gets us visibility, and testing, and bug fixes. | 21:41.45 |
| ray_laptop | ANYONE can charge for products based on our GPL code | 21:42.08 |
| Robin_Watts | Not realistically they can't. | 21:42.26 |
| ray_laptop | Robin_Watts: LOTS of cheaters and 'skaters' ship paid for products based on Ghostscript, and some on mupdf. We get bug reports from users all the time | 21:43.28 |
| | most of them don't ever tell people that its based on our code, so we get no "mind share", just the grief when it doesn't work | 21:44.15 |
| Robin_Watts | And when they are reported, we squash them (assuming their net worth is such that they have anything worth taking). | 21:44.27 |
| | These people would not have paid us if we weren't open source, so it hasn't cost us anything. | 21:45.00 |
| ray_laptop | Robin_Watts: that's part of the problem. Open source makes it too easy for lots of small fry to ruin the market for the rest | 21:45.12 |
| Robin_Watts | These "cheaters" as you put it cost us nothing. | 21:45.28 |
| | No, that's the app stores :( | 21:45.35 |
| ray_laptop | they ship free or 'ad based' products, can dodge at the drop of a hat (or a website) and keep on with their piracy. (gs more than mupdf) | 21:46.24 |
| | the gs cheaters have kept the market for pdfwriter Windows printers at near zero, killed a couple of our customers and kept us from getting nto the business seriously "because nobody is making money in it) | 21:47.58 |
| | now we didn't know what the business would be until pdfwrite was released. Peter didn't care about Windows users. | 21:48.36 |
| | but I just don't want to let the horses out of the barn with Office import "just because we have open source products" | 21:49.48 |
| | it's not like this (a decent office conversion/rendering technology) is a glut on the market. It seems like there might be a "pony in the pile" | 21:51.06 |
| mvrhel_laptop | ray_laptop: I have to agree with you. I don't really see any great advantage to having any of this opensource. I do know that customers (and potential customers) like it when they feel like they are getting something extra for their license | 21:56.14 |
| ray_laptop | henrys`: Robin_Watts: chrisl_away: request for review for a chunk memory allocator patch to use a doubly linked list (from NorbertJ with my changes) | 21:56.58 |
| | anyone else that wants to comment is fine, too | 21:57.54 |
| henrys` | I was 100% for open sourcing the original project with the business agreement we had, this new deal gives me pause. | 22:47.08 |
| tor8 | henrys`: (in jest) we could open source it safely without a build system ;) | 22:58.14 |
| | ray_laptop: (for the logs) I believe the point Robin_Watts may be aiming at is that all our current closed source stuff are third party blobs that we largely drop in as-is | 23:03.46 |
| | whereas a office component would be something we spend a lot of engineering time on ourselves and take on as our project, not some external piece of code we plug in | 23:04.22 |
| Robin_Watts | tor8: Yes. | 23:05.00 |
| | I've realistically yet to hear a convincing argument of what we lose by open sourcing it. | 23:05.31 |
| | The patent holder relationship is a genuine issue that bears thinking about. | 23:06.06 |
| tor8 | Robin_Watts: I'd compare the sneaky cheating apps to music torrent downloading; it's not a sale we would've made anyway, so very little is lost compared to what is gained from having it open source. | 23:07.46 |
| Robin_Watts | tor8: absolutely. | 23:07.57 |
| tor8 | though there is the fact that they (and all the app store bullshit) are poisoning the market | 23:08.15 |
| Robin_Watts | And there is the very real thing that by doing a GPL release of a library we forestall other people doing a BSD library and releasing it. | 23:08.47 |
| tor8 | (it's still really frustrating to see all the cheaters cheating) | 23:08.56 |
| | but cheaters will cheat regardless; there's a lot of precedent for people taking closed source apps, reskinning some graphics, and selling under a different name | 23:09.23 |
| Robin_Watts | indeed. closed source doesn't save you entirely. | 23:09.45 |
| tor8 | welcome back ray | 23:10.23 |
| henrys` | the patent holder relationship is the convincing argument not to release the source, at least it is the only issue to me. For better or worse we are in business now with these folks and I can promise you their interpretation of the patents will be much broader than ours, and it's not a risk worth taking (IMHO) | 23:27.30 |
| ray_laptop | If the cheaters don't have the source, they can't cheat | 23:35.07 |
| | about the only thing they can cheat with are illegal, hacked copies of binaries from some SOT OEM | 23:35.45 |
| henrys` | I wish you would drop the cheater stuff - we would have no prayer of having a business without the open source community | 23:36.07 |
| ray_laptop | henrys`: OK. is "GPL violator" acceptable | 23:36.47 |
| | and are only big, profitable, GPL violators that are worth taking to court the ones that actually impact the market or our business | 23:38.40 |
| henrys` | okay ;-) But we are an open source company, I really wanted to open source this stuff before we took this last turn. I actually voted against doing it but Miles probably made the good business call. | 23:39.17 |
| ray_laptop | (tor's point about poisoning the market) | 23:39.34 |
| henrys` | 50K a month is good poison for me, but it may very well dry up | 23:40.27 |
| | as Robin_Watts has suggested | 23:40.37 |
| ray_laptop | henrys`: I don't define our company as "an open source company". Our business comes from non GPL users, unlike some other (linux) open source companies that have different business models | 23:41.00 |
| | we try (IMHO) to get what advantage we can from open open sourcing our stuff (as Robin_Watts mentioned), but bug reports from free users are hardly a business model | 23:42.31 |
| henrys` | are you aware that we are under contract to keep gs open? We are about as open source as you can get. | 23:43.09 |
| ray_laptop | and contributions from free users (at least with gs which pays the bills) is marginal | 23:43.14 |
| | henrys`: I agree (and mentioned) that gs has to be open source. But that doesn't make us an exclusively open source company | 23:43.55 |
| | the biggest argument for open source is that we have gotten some customers without needing a real marketing/sales department | 23:45.25 |
| | but having a free end-user product that let people know about the availability of the product for license (aka the Foxit approach) might be just as good | 23:48.16 |
| henrys` | maybe for you, it's important for me and I think most of the rest of us to work for an open source company. It is a source of pride and satisfaction separate from financial stuff. | 23:49.10 |
| ray_laptop | henrys`: that comes under the umbrella of 'religion', IMHO. | 23:51.39 |
| tor8 | IIRC mupdf is under the same contract to keep it open source as ghostscript | 23:52.09 |
| ray_laptop | tor8: I am not privy to that, but I'd be surprised | 23:52.28 |
| tor8 | ray_laptop: part of the original buyout of mupdf when I started working for artifex | 23:53.05 |
| henrys` | so I should be covered under the first amendment ;-) | 23:53.54 |
| ray_laptop | tor8: like I said, I don't know. But the fitz library design and development by Raph was while he was an employee. | 23:54.25 |
| | but I don't know what special contract Raph may have had with Miles. I only know mine | 23:54.55 |
| tor8 | ray_laptop: mupdf wasn't originally based on fitz | 23:55.16 |
| | the project to port mupdf over to fitz was done later | 23:55.57 |
| henrys` | bbiab | 23:56.45 |
| ray_laptop | tor8: so was it libart based, or did you have some other renderer ? | 23:57.09 |
| tor8 | libart, yes. | 23:58.05 |
| | Forward 1 day (to 2014/02/15)>>> | |
IRC Logs