| | <<<Back 1 day (to 2014/01/26) | 2014/01/27 |
| chinni | can anyone help to integrate mupdf library into my android application when i am trying to run the app it is showing the following exception"java.lang.ExceptionInInitializerError" | 05:51.47 |
| kens | Hmm the cluster appears to be U/S | 09:30.12 |
| | I've sumbmitted a job and nothing has happened to it, its just sitting there. | 09:30.31 |
| | Or has it finished already ? | 09:30.46 |
| Robin_Watts | kens: I'm guessing it's finished already. | 10:51.33 |
| kens | It had, I was caught by surprise | 10:51.44 |
| | under 14 minutes for a full test run of GS | 10:52.12 |
| Robin_Watts | tor8: ping | 11:59.05 |
| kens | paulgardiner : Robin_Watts, any idea on MuPDF with Android 4. ? | 12:07.43 |
| | http://stackoverflow.com/questions/21378044/mupdf-1-3-cannot-open-pdf-with-android-4-0 | 12:07.46 |
| Robin_Watts | kens: I'd ask them if the same problem exists with an unchanged version of the sources pulled from git. | 12:08.41 |
| kens | ÖK I cna do that. | 12:08.50 |
| Robin_Watts | If it does, then report it as a bug and we'll look into it. | 12:08.53 |
| | As far as we know the sources in git work fine on all android devices >= 2.2 (or thereabouts) | 12:09.23 |
| paulgardiner | That's very weird. Maybe he is also reacting to the back button in his own code, and shuting down MuPDFActivity before onBackPressed is called. | 12:12.52 |
| kens | paulgardiner : he does claim it works with 1.1, hwich is why I asked, but I posted the answer anyway | 12:13.15 |
| paulgardiner | 1.1 doesn't special case the back button. | 12:13.55 |
| kens2 | lunches | 12:18.41 |
| tor8 | Robin_Watts: pong. | 13:01.58 |
| Robin_Watts | tor8: So, I was thinking last week about bates numbering. | 13:02.13 |
| | and adding support for it within mupdf. | 13:02.26 |
| tor8 | Robin_Watts: how does it work? | 13:02.51 |
| Robin_Watts | Specifically we would need the ability to add bates numbering to a document, and to remove it from a document. | 13:02.59 |
| tor8 | add a visible "stamp" annotation and digital signature? | 13:03.07 |
| Robin_Watts | Sadly not. | 13:03.13 |
| | It's not done via annotations. | 13:03.19 |
| | It's done by finding the page content stream, and by adding stuff onto the end of it. | 13:03.32 |
| tor8 | ew. better hope the content stream has balanced their q's and Q's | 13:03.54 |
| Robin_Watts | It adds a "blah blah BDC" then an invocation of a Do then an "EMC" | 13:04.05 |
| tor8 | so, an XObject as well? | 13:04.18 |
| Robin_Watts | and the form XObject invoked by the Do contains the appearance and the XML information. | 13:04.39 |
| | as a PieceInfo. | 13:04.42 |
| | I tested Acrobat, and it copes with unbalanced q/Qs etc :( | 13:05.02 |
| tor8 | I can see adding it shouldn't be too hard. removing it however... | 13:05.04 |
| Robin_Watts | I have an idea about how to do this. | 13:05.15 |
| | I've got a couple of commits on robin/master that are the first step. | 13:05.45 |
| tor8 | Robin_Watts: I think we can count the number of q's and Q's using the lexer. at Do we automatically rebalance if the XObject is unbalanced. | 13:05.46 |
| Robin_Watts | Firstly, I tweaked the pdf_run_xxx functions (the operator implementations) so that they are all the same format: static void pdf_run_XX(pdf_csi *...) | 13:06.29 |
| | Then I added an array of them to the pdf_csi. | 13:06.53 |
| | The interpreter now calls into that array rather than calling fixed ones. | 13:07.25 |
| | That way we can swap in different sets of them as we need to. | 13:07.43 |
| tor8 | aha! you've found a way to finally use that idea of yours that I tossed when rewriting the interpreter loop :) | 13:08.42 |
| Robin_Watts | Indeed! | 13:08.54 |
| tor8 | Robin_Watts: both commits LGTM (but beware of the two earlier ones you have sitting on the branch that aren't) | 13:09.25 |
| Robin_Watts | My idea is that as well as the normal 'pdf_run' ones, we have a 'pdf_filter' one that takes the input as operators, and can reoutput them to a buffer. | 13:09.30 |
| tor8 | Robin_Watts: and I assume count balancing q's and Q's? | 13:09.47 |
| Robin_Watts | It can optionally filter content out too. | 13:09.49 |
| | Exactly. | 13:09.51 |
| tor8 | Robin_Watts: would be neat to let pdfclean also clean the content streams :) | 13:10.09 |
| Robin_Watts | and it can probably avoid needless repetition of things like: 0 0 1 rg 0 1 0 rg 1 0 0 rg etc. | 13:10.30 |
| tor8 | Robin_Watts: maybe even rebalance the BT/ET that people always forget to put in the right place | 13:10.39 |
| Robin_Watts | And we can watch for what the cm's are set to etc. | 13:10.50 |
| tor8 | Robin_Watts: yeah. we could make pdfclean become a pdf minifying tool by just watching state changes and outputting the minimum necessary in the content streams | 13:11.24 |
| Robin_Watts | It would mean that when people have used the 'marked content' stuff, we can extract just the contents marked with a given tag etc. | 13:11.39 |
| tor8 | of course, that'll be undone by us not compressing or creating object streams on the output end | 13:11.50 |
| Robin_Watts | We can probably add stream compression easily enough. (Do we really not do that yet?) | 13:12.14 |
| tor8 | Robin_Watts: but yes, I do think if we want to go in the direction of a general "pdf editing toolkit" this is definitely worth having | 13:12.21 |
| | Robin_Watts: in pdfclean we only decompress :) | 13:12.30 |
| Robin_Watts | Ok, cool. I will keep bashing at it then. | 13:12.33 |
| | true. | 13:12.36 |
| tor8 | it would be handy (for small enough definitions of handy) to recompress everything as Flate | 13:13.03 |
| Robin_Watts | yes. | 13:13.08 |
| tor8 | get rid of LZW and other cruft | 13:13.12 |
| Robin_Watts | mutool clean -c :) | 13:13.26 |
| | or -z | 13:13.35 |
| tor8 | -z for zip, -c for clean the content streams | 13:13.46 |
| Robin_Watts | yeah. | 13:13.56 |
| | It would also enable us to spot unused resources. | 13:14.06 |
| tor8 | and the filter could in theory do all kinds of color conversions of non-image data | 13:14.08 |
| | just change all color operators into setgray for grayscale | 13:14.18 |
| Robin_Watts | Yes, there is lots of scope for stuff here. | 13:14.29 |
| | I'm glad you're not appalled by this idea :) | 13:14.39 |
| tor8 | "0 0 0 1 k" could easily become "0 g" | 13:14.43 |
| | Robin_Watts: mind you, I've had my head deep in javascript guts lately, my sense of what is appalling might just have been desensitized | 13:15.22 |
| Robin_Watts | ha! | 13:15.28 |
| tor8 | omg, that is one hacky ugly language! | 13:15.31 |
| Robin_Watts | I spent the weekend reading patents. Now *THOSE* are far more convoluted ugly languages :) | 13:16.44 |
| tor8 | Robin_Watts: so, RegExps and Date objects are missing, and a handful of builtin functions, but all the rest of the core language is working (barring the usual set of bugs and misconceptions) | 13:16.49 |
| | now what did you go and do that for? | 13:17.02 |
| Robin_Watts | excellent. | 13:17.02 |
| tor8 | Robin_Watts: that, and adding prototype getter and setter functions is all that's missing before I can unleash the monster on paul | 13:17.32 |
| Robin_Watts | To figure out which patents might still apply to the Smart Office code. | 13:17.53 |
| tor8 | ah. | 13:18.08 |
| Robin_Watts | I think the answer is that none apply to the idea of taking the SOT office loaders and merging that into MuPDF. | 13:18.47 |
| tor8 | looking through all the old picsel patents? | 13:18.48 |
| paulgardiner | tor8: did what I said about storing a native object per method make sense? We started talking about it and then got destracted. | 13:19.00 |
| Robin_Watts | But it's much harder to be 100% sure about whether the patents still apply to the SOT app itself. | 13:19.23 |
| | tor8: yeah. | 13:19.30 |
| tor8 | paulgardiner: I started reading it, and looking at your pdfimp api I have a few (minor) questions for you | 13:19.33 |
| Robin_Watts | heads for lunch. bbs. | 13:20.00 |
| tor8 | paulgardiner: am I correct in assuming that jsimp_new_type is essentially registering a new prototype object that the native "host" objects will use, and addmethod adds a getter/setter property on said prototype object? | 13:20.53 |
| paulgardiner | Yep. | 13:21.11 |
| tor8 | paulgardiner: then I have something that I think should work | 13:21.42 |
| | paulgardiner: this is a simple example of the current native-object-binding api in libjs http://ghostscript.com/~tor/file-js.txt | 13:22.07 |
| | so the basic idea with the libjs api is (just like lua) that all interfacing between C and the javascript happens via a "stack" of values | 13:22.59 |
| | there is no way for the C code to access the javascript objects directly (keeps them safe for garbage collection) | 13:23.22 |
| | so you have a handful of functions to "push" values to the stack, and others to extract from the stack into C data types | 13:23.49 |
| | js_pushnumber() and js_tonumber() for example | 13:23.56 |
| | and also to create new objects on the stack: js_newobject() and to read and set properties | 13:24.12 |
| | js_getproperty() takes a stack index (of the object) and a property name, and pushes the value of the property on the stack | 13:24.35 |
| | and setproperty does the same, but takes the value from the stack | 13:24.42 |
| | and you can create a function object that will call a C function with js_newcfunction() that takes a function pointer | 13:25.31 |
| | that gets called with all the arguments on the stack, and takes the return value from the top of the stack when the function returns | 13:25.55 |
| | now my thinking for native objects is to create a special class of object (like String, Array and Boolean are special classes of objects) that is Userdata | 13:26.53 |
| | and each Userdata also has a tag string, which identifies it to the C code, so that sneaky javascript code doesn't call a method for one class on another's object and causes all sorts of crashing | 13:27.38 |
| paulgardiner | Yeah, that looks nice, but there is a special problem in MuPDF to do with the fact that we wish to support multiple engines and we want a single piece of code that defines the DOM independently of the engine (I'm assuming we wish to continue to do that because some users may with to use v8 even though they have a lighter-weight alternative). | 13:27.48 |
| tor8 | paulgardiner: yes. so I think your jsimp methods should (with a few minor changes) map to the api fairly easily | 13:28.17 |
| | paulgardiner: do you hold on to pointers to javascript objects from the C code? | 13:29.24 |
| | paulgardiner: we could make pdf_jsimp_obj just be ints, or map this sort of stack-based api onto the existing wrappers | 13:31.18 |
| paulgardiner | The problem is specific to creating one interface in terms of another and (I don't believe specific to the way I did it): although the caller of jsimp passed different set get functions for each property, the implementations of the jsimp interface have to use a single pair of set get for all properties and all objects. The differing native set/get s have to be stored somewhere. | 13:31.33 |
| tor8 | the biggest mismatch that I see is the way you pass around pdf_jsimp_obj. I have a way around that, but it's kind of inefficient if you're going to use it heavily. | 13:32.24 |
| | js_ref() is intended to get you a 'handle' to a javascript hosted value | 13:32.43 |
| | but it does that by using a special registry table (just an object, with made up property keys) which is part of the GC root set | 13:33.06 |
| | and returns the key into the table for the value | 13:33.13 |
| paulgardiner | In C if you have set1, set2, ... and you need to create metaset1, metaset2, ... to pass into an engine to call set1, set2, ..., you cannot do it. | 13:33.40 |
| tor8 | because pdf_jsimp_to_string for instance, could trigger some javascript toString() code and that might trigger a GC cycle | 13:33.42 |
| paulgardiner | So you have to use a single metaset function and for each use hide set1, set2, .... in a data structure. | 13:34.22 |
| tor8 | paulgardiner: let me rephrase to see if I understand: the pdf_jsimp interface to mupdf has multiple get/set functions (all taking pdf_jsimp_obj *args[]), but in the jsimp interface to the interpreters... | 13:35.31 |
| paulgardiner | In this case somewhere to store the set functions for each property is needed. If you store them in the object, you have to create a lookup table | 13:35.35 |
| tor8 | ...there is only one getter/setter that is used for all properties, that gets passed the object and property name and does a lookup to the former set? | 13:36.02 |
| paulgardiner | Yesish | 13:36.17 |
| | Yes in Javascipt core. | 13:36.30 |
| | In v8, I'm able to store the getter/setters in the engine attached to the property, so that when my single internal set/get method is called I have access to the stored native set and get | 13:37.17 |
| | That is more efficient. | 13:37.46 |
| tor8 | right, I think I now understand what you meant earlier with storing a native data attached to each property | 13:38.16 |
| paulgardiner | Although efficiency isn't everything, so using the lookup mechanism as in JSCore isn't a disaster | 13:38.24 |
| tor8 | in libjs, my thinking would be to create two c function objects for the getter and setter, and attach them to the property as setter/getter attributes | 13:38.48 |
| paulgardiner | It's just that if you are creating an API for your engine, and if the problem is as general as I think it is, it might be good to solve. | 13:39.12 |
| tor8 | whether it's a c function object or a javascript function object shouldn't matter, it gets called as normal | 13:39.16 |
| paulgardiner | But the problem is that the set/get functions passed through the jsimp interface are of one type and the ones passed into the engine are of another. the engine cannot directly call the native jsimp ones. | 13:40.27 |
| tor8 | js_newobject(J); js_pushcfunction(J, myFooGetter); js_setpropertygetter(J, -2, "foo"); js_pushcfunction(J, myFooSetter); js_setpropertysetter(J, -2, "foo"); js_setproperty(J, -2, "prototype"); | 13:40.28 |
| | paulgardiner: yeah. so the pdf_jsimp prototypes match the v8 api but not the jscore? | 13:41.17 |
| paulgardiner | So for each native jsimp set/get we need an engine metaset/metaget pair, but we are unable to create those on the fly (being C and indeed in many langauages) | 13:41.20 |
| | tor8: no not at all. | 13:41.32 |
| | tor8: I designed the api without looking at v8 | 13:41.47 |
| | I was then surprised twice | 13:41.55 |
| tor8 | paulgardiner: hm. okay. so if you attach the real set/get as a function pointer as a userdata, and then have a wrapper/unwrapper to convert the parameters and return values and calls the userdata function? | 13:42.14 |
| paulgardiner | First surprise was that defining one interface over another had this problem. The second surprise was that v8 had a solution | 13:42.29 |
| | tor8: yeah what you just said has to be done for one interface defined over another, but there is still a problem I think | 13:43.20 |
| | Can I have userdata specific to the property for which set /get is being difined? | 13:44.00 |
| tor8 | yeah. I hadn't really considered the issue of there being a need for two layers of callbacks. | 13:44.10 |
| | paulgardiner: well, I haven't written the code yet, so yes :) | 13:44.26 |
| paulgardiner | tor8: no well you wouldn't. I wouldn't other than having realised that it has special problems | 13:44.47 |
| | tor8: :-) | 13:45.00 |
| tor8 | in my original thinking, you'd have the userdata pointer from the "this" value that gets passed | 13:45.13 |
| paulgardiner | tor8: yes, I think that's most natural, and it is strange that one also needs to attach userdata to the property. | 13:45.53 |
| tor8 | one way to hack around it is to hide the real pointer as a userdata in a closure that gets created around the function object | 13:45.54 |
| | paulgardiner: well, that, or get the name of the property somehow | 13:46.13 |
| paulgardiner | tor8: Looking at my v8 imp I think that is what I do | 13:46.17 |
| tor8 | ick. why do they have to have property getters and setters? | 13:46.23 |
| | why not just functions... :( | 13:46.33 |
| | paulgardiner: I don't do closures for C functions, but you could create a javascript function (which has closures) to call the c function with the hidden userdata-for-the-property but that seems needlessly awkward | 13:47.30 |
| paulgardiner | tor8: there may ways to change jsimp competely that avoids this... or maybe not. I'd be interested. The one thing I'd like to keep is the ability to support multiple engines with the DOM described once and not differently for each engine | 13:47.49 |
| tor8 | paulgardiner: yeah. well, we could make the DOM definition in terms of the libjs api (which is completely abstracted onto a "stack") | 13:48.23 |
| | and then make libjs api wrappers for the other engines | 13:48.35 |
| paulgardiner | tor8: in the v8 implementations I definitely create functions and hide the data in there. That may be the same as you've just suggested | 13:48.49 |
| tor8 | paulgardiner: my C++ foo is too weak | 13:49.28 |
| paulgardiner | tor8: that's an interesting idea. Let me mull that over. | 13:49.31 |
| | tor8: I don't understand my v8 imp any more either. :-) | 13:49.49 |
| tor8 | you create a PDFJSImpMethod to wrap the jsimp function pointer into something you send to v8 | 13:50.12 |
| | so js_newcfunction would do the same trick in a v8-wrapper of wrapping the actual function pointer in a bit of hidden data, and then the callMethod callback would unpack all the arguments and call the hidden function | 13:51.35 |
| | it might be a fair amount of work to reimplement the whole libjs api in terms of the others, but it shouldn't be a lot more than we already do. I have tried to keep it small. | 13:52.32 |
| | paulgardiner: ugh. you know of any decent regexp libraries? PCRE is a huge bloated monstrosity that does a *lot* more than just the slightly extended POSIX regexes that javascript uses | 13:53.11 |
| paulgardiner | Yeah. Not sure. Certainly a possibility. On the other hand, libjs only need provide a way to store userdata in a property and we can go the other way, | 13:53.40 |
| tor8 | and the libc regex.h stuff isn't well supported on windows, nor does it handle utf-8 reliably (it might, if you trick it with setlocale, but that's horrible) | 13:53.42 |
| | paulgardiner: yeah, the only trick is getting the userdata out of the property and into the setter/getter | 13:54.08 |
| paulgardiner | Plus anyone else wishing to support libjs under their own API would be able to take advantage of it | 13:54.17 |
| tor8 | but I could make a separate function prototype for setter and getter C functions | 13:54.36 |
| paulgardiner | tor8: I'd just need it passed in when the libjs set get is called | 13:55.31 |
| | libjs-level | 13:55.40 |
| tor8 | actually, it might be trivial, since the setter and getter functions are full fledged javascript objects, you could hide the wrapper pointer in a regular property | 13:55.47 |
| paulgardiner | Ah. I think I understand. Nice | 13:56.22 |
| tor8 | so you create the meta-wrapper function, and add the real c function object as a property of that, and you extract that property when you call it | 13:56.34 |
| paulgardiner | So it was already there, sort of. | 13:56.35 |
| | Sounds good to me | 13:56.54 |
| tor8 | now I just need a way to get at the called function object (arguments.callee or some such?) | 13:57.09 |
| paulgardiner | Magic | 13:57.56 |
| tor8 | either that or let c functions have a scope and use closures | 13:57.59 |
| | paulgardiner: okay, so we've got a way to solve it that doesn't even involve changing my original concept :) | 13:58.45 |
| paulgardiner | Am I understanding: pass spope in as an arg to C func? | 13:58.51 |
| tor8 | paulgardiner: a C func is currently run with only the global environment as its scope | 13:59.12 |
| | there is no "get local variable" call for the C api | 13:59.23 |
| paulgardiner | tor8: I thought you'd have a simple solution. It's just very difficult to explain the problem in the first place | 13:59.27 |
| Robin_Watts | tor8: http://tiny-rex.sourceforge.net/ maybe? | 13:59.54 |
| tor8 | I could change that with a few lines of code, to just create a scope for a c function object and make the getvar/setvar functions public | 13:59.57 |
| paulgardiner | tor8: sounds good to me. | 14:00.37 |
| tor8 | Robin_Watts: one thought I had was to take the plan9 regex library and extend it. it's small enough to actually understand. | 14:00.43 |
| | or just write my own, it's not like regexes are hard to implement (with a slow, backtracking recursive implementation, which javascript basically mandates with their backreferences \1 \2 etc) | 14:01.15 |
| Robin_Watts | I haven't looked at the above lib - I just asked on another talker :) | 14:01.16 |
| tor8 | paulgardiner: the currently called function object always lives on the stack, so getting that with a special function call (or magic stack index number) should be trivial as well | 14:01.57 |
| | currently I treat positive indexes as function arguments, and negative indexes count from the top of the stack | 14:02.24 |
| | so 0 is this, 1..argc are the arguments, and -1 is the top element on the stack | 14:02.40 |
| | 65535 could be made to mean the function object (or just another api entry point) | 14:03.19 |
| | js_pushcallee() | 14:03.38 |
| | paulgardiner: anyway, should be easy to do | 14:04.02 |
| paulgardiner | tor8: brilliant. Sounds ideal. I like the whole stack thing too. | 14:05.42 |
| tor8 | Robin_Watts: that trex stuff looks like workable. the code looks simple enough to work with to extend for backreferences and positive/negative lookahead and non-capturing closures. | 14:07.04 |
| Robin_Watts | I understood about 8 words of that :) | 14:07.31 |
| tor8 | Robin_Watts: obscure regex features: (?=...) (?:) (?!) and \1 \2 \3 | 14:08.14 |
| | oh, trex already does non-capturing expressions :) | 14:09.47 |
| | not according to the man page but if you read the code | 14:09.55 |
| | #ifdef _UINCODE I suspect a typo! | 14:10.18 |
| paulgardiner | Robin_Watts: little Android fix on paul/master | 16:02.40 |
| Robin_Watts | oh, yes. lgtm. | 16:03.55 |
| paulgardiner | ta | 16:08.59 |
| sybariten | hey | 16:19.01 |
| | im trying to formulate a question thats spot-on to my question, in order to not search too much in vain | 16:19.29 |
| | i want to take a couple of eps files, say 4-6 of them, and create one single page.... like a composie or colalge | 16:19.59 |
| | they are graphs, btw | 16:20.06 |
| | But i dont know which tool is beest for this. | 16:20.17 |
| kens2 | Anything which can place EPS files, adobe illustrator, photshop etc | 16:20.33 |
| | Even MS Word can do this | 16:21.10 |
| Robin_Watts | Or you can write some postscript and include the files, probably. But that requires you knowing postscript. | 16:21.10 |
| | For those not on facebook: http://www.huffingtonpost.com/2014/01/24/conference-call-real-life_n_4662007.html?ncid=edlinkusaolp00000009 | 16:22.41 |
| sybariten | kens2: Robin_Watts oh, sorry. I was a bit vague. :) I need to do it programmatically :) | 16:23.30 |
| Robin_Watts | sybariten: Write some code to output postscript then :) | 16:23.58 |
| kens2 | You will need to read teh DSC comments from teh individual EPS files | 16:24.13 |
| | tehn write PostScript to place teh files individually | 16:24.27 |
| | And bracket each file with the appropriate PostScript operations | 16:24.51 |
| | Its not terribly hard, neither is there likely to be a simple solution. | 16:25.17 |
| sybariten | heres a good example http://i.stack.imgur.com/bYAx5.png imagine i had each of those (weird) graphjs as separate eps files, and wanted to smack them together in that style | 16:25.32 |
| kens2 | There are solutions for n-up imposition, but those normally expect to take fully formed PostScript rather than EPS | 16:25.39 |
| | You could look at PSUtils | 16:26.14 |
| | http://gnuwin32.sourceforge.net/packages/psutils.htm | 16:26.29 |
| sybariten | aha aha | 16:26.33 |
| | psmerge... | 16:27.16 |
| kens2 | sybariten : that's not enough | 16:28.16 |
| | I think | 16:28.20 |
| | Because you need to place each EPS individually | 16:28.29 |
| sybariten | aha | 16:28.43 |
| kens2 | psnup is more like what you want | 16:28.44 |
| sybariten | how do you mean, place them individually....? as opposed to....`? | 16:29.00 |
| Robin_Watts | If you need help, you could call on coscript.biz to help. | 16:29.02 |
| kens2 | sybariten : Each EPS needs to be placed on the page, as opposed to each EPS becoming a page on its own | 16:29.35 |
| | I suspect psmerge does the latter | 16:29.47 |
| mvrhel_laptop | good morning | 16:30.14 |
| kens2 | Except that because these are EPS files you will have no showpages at all, and each one will be drawn on top of the preceding ones, forming a horrible mess | 16:30.18 |
| sybariten | Robin_Watts: interesting field of work | 16:30.20 |
| | i'm fearing this is a case where i'll resort to IM doing a composite | 16:30.58 |
| | which isnt the worst, but.... | 16:31.02 |
| Robin_Watts | sybariten: Alex (the guy that runs coscript) is very experienced in Postscript/EPS etc. | 16:31.03 |
| sybariten | Robin_Watts: ok, cool. I dont think i have any funds to use consultants for this, but i'll remember that! | 16:31.28 |
| Robin_Watts | morning mvrhel_laptop | 16:31.38 |
| henrys | and the snow continues.... | 16:40.43 |
| kens2 | Austria had some over the weekend too :-) | 16:41.00 |
| henrys | kens2:you could probably stop off at aspen or vail on your way to Scott's if Austria doesn't work out. | 16:41.40 |
| kens2 | henrys I'm fairly sure those are further on from Texas ;-) | 16:42.01 |
| | But they had half a metre over the weekend so it looks much nicer | 16:42.20 |
| | Even if they did have to reroute the Hannenkam | 16:42.37 |
| mvrhel_laptop | henrys: I wish we would get some snow around here. It has been like spring for the past 2 weeks | 16:56.54 |
| kens2 | Here too | 16:57.02 |
| | Sunday was 10-11 centigrade | 16:57.14 |
| mvrhel_laptop | wow | 16:57.18 |
| kens2 | And very very wet too | 16:57.27 |
| Robin_Watts | kens2: Tshirt and shorts weather. | 16:57.30 |
| mvrhel_laptop | it has been about the same temp here, but sunny | 16:57.43 |
| | which is very odd | 16:57.48 |
| kens2 | I'mriding in a t-shirt now | 16:57.48 |
| Robin_Watts | would prefer it if the snow stayed away. | 16:58.07 |
| henrys | my new place involves a lot of shoveling so I've become less of a snow fan | 16:59.03 |
| | guess I better tend to my customer bugs, ugh | 16:59.42 |
| zeniko | tor8: In case you're considering trex for regexes: I've got a local fork which contains dozens of bug fixes, better JavaScript compatibility and a larger test suite. | 17:10.57 |
| Robin_Watts | zeniko: sounds ideal. | 17:12.19 |
| | mvrhel_laptop: incoming from Marti. | 17:23.57 |
| kens2 | OK goodnight everyone | 17:25.32 |
| mvrhel_laptop | Robin_Watts: ok. so is this a pre-release? | 17:53.56 |
| Robin_Watts | it is. | 17:54.34 |
| | I've integrated his previous preleases locally before and they've worked well. | 17:54.52 |
| | I will try for that one tomorrow, and put it somewhere you can look at it. | 17:55.05 |
| mvrhel_laptop | ok sounds great. thank you | 17:55.13 |
| Robin_Watts | Maybe you can experiment with the threading stuff, cos you'll know what to test :) | 17:55.26 |
| | gotta pop out to collect helen now. bbiab. | 17:55.37 |
| mvrhel_laptop | ok ttyl | 17:55.40 |
| ray_laptop | Robin_Watts: I see the "testdocs" filling up on peeved. at about 288 Gb so far | 18:03.25 |
| | We're getting about 2.4Gb per hour moving the testdocs onto peeved. Things must compress pretty well. | 19:23.40 |
| | bbiab | 19:24.11 |
| henrys | robin_watts_mac_: I just sent a private message to you but it looks like you fell off the network | 20:35.50 |
| Robin_Watts | I did. | 20:36.07 |
| | so I missed your message. | 20:40.49 |
| | tor8: I am confused by the array handling in the interpreter in pdf-interp.c | 20:43.14 |
| | If we *aren't* in a text object and we meet an array, we parse it all out as an object and call the operator function as normal. | 20:43.55 |
| | If we *are* in a text object, we deal with each entry as we parse it in turn, without waiting for the operator at the end. | 20:44.29 |
| | So if we have: BT [ 1 2 3 4 5 ] 0 d [(test)] TJ ET | 20:45.24 |
| | which would be entirely valid, we'd end up sending 1,2,3,4,5 as spaces, and not setting the dash stuff as we'd expect. | 20:45.58 |
| | I guess the reason behind doing it this was to keep memory usage down? | 20:46.33 |
| | but I can't believe that can have been that much of an issue... | 20:46.47 |
| henrys | Robin_Watts: something weird in my chat client can't go private. | 20:46.54 |
| Robin_Watts | Are you talking to robin_watts or robin_watts_mac? | 20:47.30 |
| | I just tried a private message to you. | 20:47.35 |
| henrys | Robin_Watts: weird I can see your message and it won't let me type | 20:48.04 |
| | let me restart it. | 20:48.12 |
| Robin_Watts | I will too. | 20:48.17 |
| mvrhel_laptop | ok. I seem to have my initial cut at gsview in c# actually rendering pages with mupdf on background threads going through the c++ interface that I wrote for the windows 8 app | 22:02.25 |
| | henrys: it took me a bit to figure out all the windows api shenanigans but now that I have it things should start to come together | 22:03.09 |
| | it is nice that I was able to reuse at least some of my windows 8 code. | 22:03.46 |
| henrys | mvrhel_laptop: congrats ⦠when we get to release time we have to tell miles because he has to give russell some money first (for the name) | 22:05.12 |
| mvrhel_laptop | right. I am hoping I will have something in a very rough form by the staff meeting. | 22:05.44 |
| | release will require some serious beating | 22:06.01 |
| | on the code | 22:06.05 |
| | but perhaps on me too | 22:06.11 |
| | need to head out for a bit. back shortly | 22:07.31 |
| tor8 | Robin_Watts: yeah, it's for saving memory. I don't think you're allowed to change any graphics state inside the BT/ET though. | 23:46.16 |
| | so setting the dash pattern inside it is not supposed to be possible | 23:46.29 |
| | (unless I've completely misread the spec, which is entirely possible) | 23:46.40 |
| | Forward 1 day (to 2014/01/28)>>> | |
IRC Logs
