| | <<<Back 1 day (to 2014/02/24) | 2014/02/25 |
| Robin_Watts | Morning mvrhel_laptop | 00:03.56 |
| mvrhel_laptop | morning Robin_Watts | 00:04.07 |
| Robin_Watts | How's did day 1 go? | 00:04.14 |
| mvrhel_laptop | we are on a train. getting wifi off of Takane-san's phone | 00:04.25 |
| | Day 1 went very well | 00:04.31 |
| Robin_Watts | excellent. | 00:05.49 |
| mvrhel_laptop | reading the logs.... | 00:08.13 |
| Robin_Watts | Has there been much interest in SmartOffice? | 00:20.48 |
| | Either as the app, or as a printing mechanism for office files? | 00:21.20 |
| mvrhel_laptop | Robin_Watts: yes. much interest yesterday | 00:28.25 |
| | not clear for which application yes | 00:28.32 |
| | yet | 00:28.34 |
| | we talked about both though | 00:28.39 |
| | we are meeting with 2 print groups and 1 app group today | 00:29.08 |
| | getting off in 2 stops | 00:29.26 |
| | talk to you all later | 00:29.29 |
| ray_laptop | henrys: you were winking with torscript, but we could call it torjs -- we'd probably get a 'top hit' on that one :-) | 01:57.03 |
| | (unlike mujs that seems to have a lot of hits) | 01:57.48 |
| sebras | tor8: (for the logs) did you also get a mail from someone at github complaining about CRLF in libjs? | 09:49.32 |
| jhabjan | sebras: I reported this issue... I made Visual Studio 2012 project from libjs... trying to see if this can be used for something... | 10:02.50 |
| sebras | jhabjan: yes, I know. :) | 10:09.39 |
| | jhabjan: no one has really tried compiling it for windows yet. | 10:10.03 |
| jhabjan | sebras: it compiles well with slight redefinition | 10:10.46 |
| sebras | jhabjan: yes, I wouldn't expect any major changes being necessary. | 10:11.04 |
| | jhabjan: tor8 mentioned possibly looking into making sure it compiles for windows last night. | 10:11.44 |
| jhabjan | sebras: I can send you visual studio project files if you want.. | 10:14.32 |
| | actually.. the only thing I made is... I added this to 'jsi.h': http://pastebin.com/siK1uvTT | 10:14.56 |
| | change inline to __inline | 10:15.41 |
| | and add _CRT_SECURE_NO_WARNINGS into preprocessor definition.. | 10:16.59 |
| | anyway... the other thing I run into is the regex max state count (which seems to be hardcoded to 10)... or max 10 captures... which fails on complex regex patterns.... | 10:20.03 |
| paulgardiner | tor5, Robin_Watts: text-annotation-creation support on paul/master when you have a moment | 11:11.13 |
| Robin_Watts | looking. | 11:13.07 |
| paulgardiner | ta | 11:13.12 |
| Robin_Watts | So the size is hardwired? | 11:14.09 |
| paulgardiner | Yeah. It's a fixed icon. Looks pretty much like the one Adobe use. | 11:14.51 |
| Robin_Watts | speech, not speach | 11:15.26 |
| paulgardiner | Oops | 11:15.58 |
| tor5 | paulgardiner: s/spea... oh, I see Robin caught it first :) | 11:17.03 |
| Robin_Watts | otherwise looks good. | 11:17.06 |
| | Zeniko has some fixes too. | 11:17.16 |
| paulgardiner | Okay great | 11:17.17 |
| Robin_Watts | And we need to pull in the openjpeg jbig2 changes from gs. | 11:17.27 |
| Robin_Watts | is off for a run (first in a month+), but I'll look later if neither of you beats me to it. | 11:17.56 |
| tor5 | Robin_Watts: the three bugfix patches on zeniko's branch LGTM | 11:20.38 |
| Robin_Watts | back. | 11:44.17 |
| | morning mvrhel_laptop | 11:44.22 |
| paulgardiner | I'll need someone to explain how we are sharing jbig2 between the projects. Is it a subtree of gs and a submodule of mupdf? | 11:44.23 |
| Robin_Watts | exactly. | 11:44.32 |
| mvrhel_laptop | actually good night... | 11:44.34 |
| | in a bit | 11:44.37 |
| | but good morning to you Robin_Watts | 11:44.49 |
| paulgardiner | Okay. Maybe I'm getting it then | 11:45.06 |
| Robin_Watts | paulgardiner: We commit changes in the gs tree. | 12:05.29 |
| | Once a day, a cron job pulls those subtrees out into separate repos. | 12:05.43 |
| | We then use those repos as submodules in mupdf. | 12:05.56 |
| | Thus the process for a fix is to commit into gs, wait a day, then update the submodule pointer in mupdf to point to the new revision. | 12:06.18 |
| | paulgardiner: source/pdf/pdf-appearance.c:1858: warning: unused variable 'obj' | 12:07.00 |
| paulgardiner | Robin_Watts: okay. I think I've pulled in the change to jbig2 on paulg/master | 12:07.54 |
| | Robin_Watts: ah yes. Don't use obj | 12:08.47 |
| | I checked that mupdf builds with the jbig2 fix but I didn't summit a cluster test | 12:09.36 |
| Robin_Watts | well, we'll find out in a mo. | 12:10.04 |
| paulgardiner | Also fixed the unused var and pushed that fix to paulg/master... but after the jbig2 update which I we might not take on if you are also looking at it. | 12:11.15 |
| Robin_Watts | I've just pushed your jbig2 update. | 12:11.32 |
| paulgardiner | Oh okay. Shall I push my little fix for the unused var too, or is there any reason we should wait? | 12:12.23 |
| Robin_Watts | paulgardiner: I'll grab it and push it with zenikos stuff. | 12:14.17 |
| paulgardiner | Ta | 12:14.24 |
| Robin_Watts | Who added pdf_new_obj_from_str ? | 12:14.33 |
| | It appears unused. | 12:14.36 |
| | oh, it's for sumatra. ok. | 12:15.26 |
| | tor8: Forget js. We want this: https://www.youtube.com/watch?v=_P9HqHVPeik | 12:50.28 |
| tor8 | Robin_Watts: the future is here! | 12:55.57 |
| Robin_Watts | tor8, paulgardiner: So, I did some work on the pdf operator filtering stuff yesterday. | 12:59.49 |
| | I have it so that it removes unnecessary q/Q pairs, avoids repeatedly pushing the same colors etc. | 13:00.28 |
| | All marvellously untested of course. | 13:00.58 |
| | and now I'm pondering how best to hook it up. | 13:01.06 |
| paulgardiner | At what stage do we perform this filtering? | 13:01.27 |
| Robin_Watts | At the moment pdf_run_page_contents_with_usage calls pdf_new_csi. | 13:01.48 |
| | Then we call pdf_set_op_processor (or something like that) to set which set of op functions we use. | 13:02.14 |
| | at the moment it always sets the "normal" ones, which are the 'pdf_run_BT' etc set. | 13:02.48 |
| | The theory is that I can put a different set in there and they will get called instead. | 13:03.14 |
| tor8 | pdf_run_page_with_operators()? | 13:04.25 |
| Robin_Watts | Well, there is pdf_run_page_contents and pdf_run_annots | 13:04.59 |
| | I was pondering having pdf_process_page_contents. | 13:05.10 |
| tor8 | I'd make those two wrappers that call your underlying function with the default op table | 13:05.27 |
| Robin_Watts | and pdf_run_page_contents could call pdf_process_page_contents with a function pointer to set up the defaults. | 13:05.33 |
| paulgardiner | This seems a bit like the device interface, but at a different level. | 13:05.47 |
| tor8 | I'd say run/process are a bit too similar in name | 13:05.50 |
| Robin_Watts | Well, run is just "process" but with the 'run' set of operators. | 13:06.13 |
| tor8 | Robin_Watts: we don't call the raw pdf_run_page function in very many places | 13:06.41 |
| | I believe almost all of our tools call the fz_run_xxx functions instead | 13:06.53 |
| | so you could just change pdf_run_xxx to take the operator table as an argument | 13:07.11 |
| Robin_Watts | tor8: true. | 13:07.29 |
| tor8 | and change the pdf_run_page shim that fz_run_page calls | 13:07.31 |
| paulgardiner | So I'm wondering if we should make the things that understands what to do with operators first class object, the same way that the things that understand graphics commands are devices | 13:07.53 |
| Robin_Watts | The bit I can't see clearly is how we set up this stuff to do nested calls. | 13:08.07 |
| tor8 | Robin_Watts: a nested call would just pass the table along? | 13:08.26 |
| Robin_Watts | Hold on, let me put what I've got up for you to look at. | 13:09.02 |
| tor8 | you could (at the risk of some minor confusion) call the op table pdf_device, or (slightly less confusing) pdf_opdevice? | 13:09.14 |
| Robin_Watts | OK, pushed. | 13:11.24 |
| | pdf-interpret-imp.h has the definitions in. | 13:12.20 |
| | Currently the op tables are called pdf_op_processors. | 13:12.55 |
| | Because they contain the logic to process the ops. | 13:13.15 |
| | but a pdf_opdevice is possible. | 13:13.25 |
| | I'm thinking that I could extend pdf_new_csi to take a new argument. | 13:14.49 |
| | That argument would be a pointer to a structure. | 13:14.59 |
| tor8 | op_processor is fine | 13:15.34 |
| Robin_Watts | That structure would contain a setup function pointer, a void * arg to be passed to that function pointer, and a pointer to the next such structure in the chain. | 13:15.40 |
| tor8 | Robin_Watts: before looking at the big picture, I don't understand what pdf-op-filter is really doing | 13:16.57 |
| paulgardiner | If you were going all out for the op_processor way, you might provide one to the run_page run_annot functions instead of a device, and also have a constructor that gives an op processort that drives a device. | 13:17.03 |
| Robin_Watts | tor8: Are you happy with the run and buffer filters? | 13:17.40 |
| paulgardiner | So instead of run_page(dev) run_page(op_pro(dev)); | 13:18.17 |
| | Just a thought. | 13:18.23 |
| tor8 | pdf_buffer_BDC looks to be missing the '/' when putting the name | 13:18.27 |
| sebras | tor8: you saw jhabjans messages in the logs..? | 13:18.34 |
| tor8 | sebras: yes. | 13:18.40 |
| sebras | tor8: oki, then all is good. | 13:18.48 |
| Robin_Watts | tor8: oh, probably. This is all marvellously untested. | 13:18.50 |
| | I'll push such fixes back in the history when I can test them, thus making it look as if it flew from my brain fully formed :) | 13:19.28 |
| | The run (or "normal") filter is just the current status quo refactored into the new form. | 13:20.07 |
| tor8 | Robin_Watts: I'd wrap csi->op_processor->op_table[op](cs, csi->op_state) in some sort of helper function | 13:20.20 |
| | like pdf_run_op(proc, op, state) | 13:20.29 |
| | and maybe rename pdf-op-run to pdf-op-rundev? | 13:20.40 |
| | or pdf-op-draw | 13:20.53 |
| Robin_Watts | tor8: Yeah, that might be nice. A static inline. | 13:21.09 |
| tor8 | Robin_Watts: yeah. definitely for the op-filter which has a hundred such lines | 13:21.26 |
| | and it hides the inner guts of the table lookup | 13:21.41 |
| Robin_Watts | The buffer filter is intended to take the operators it is called with and output them as an operator stream. | 13:22.14 |
| | in an fz_buffer. | 13:22.23 |
| tor8 | Robin_Watts: yeah, a syntax washer | 13:22.25 |
| Robin_Watts | filter is the bit that actually does the washing. | 13:22.38 |
| tor8 | and the op-filter that you've pushed is a forwarding no-op processor? | 13:23.14 |
| Robin_Watts | The initial one is a no op. | 13:23.25 |
| | The latest commit on there fleshes it out. | 13:23.31 |
| tor8 | oh, right. haven't looked at that one yet. | 13:23.41 |
| Robin_Watts | Whenever it gets a q or a colorspace change or a color change, it puts them into the current gstate. | 13:23.52 |
| | and it flushes them 'just in time'. | 13:24.00 |
| tor8 | buffer the gstate, flush the diff before an op, kind of thing? | 13:24.09 |
| Robin_Watts | so we avoid qQ with nothing in it. | 13:24.12 |
| | exactly. | 13:24.13 |
| tor8 | you emit q/Q for matrix changes only? | 13:24.29 |
| Robin_Watts | There is scope for lots more stuff to be washed in the same way (gstates, Tc, Tw etc) | 13:24.34 |
| | tor8: No, I always emit them, as long as there is something in there. | 13:24.53 |
| | But I never output more Q's than q's. | 13:25.00 |
| | And I always emit enough Q's to match the q's at the end. | 13:25.21 |
| tor8 | right, because in theory you could emit a page without q/Q altogether | 13:25.28 |
| | by always setting explicit state | 13:25.32 |
| Robin_Watts | tor8: No, w and w* break that. | 13:25.44 |
| | clipping paths can only be reset by Q. | 13:26.12 |
| tor8 | hm, right. and there's no way in PDF (as opposed to postscript) to set the matrix directly, only by concatenating | 13:26.12 |
| Robin_Watts | yeah. | 13:26.16 |
| | We could do a pdf_op_flatten_as_much_as_possible | 13:26.26 |
| | but this was intended to leave the structure unchanged (as much as possible), just strip out the unnecessary bits. | 13:26.57 |
| tor8 | Robin_Watts: right. | 13:27.10 |
| Robin_Watts | We can also have filters that would select just stuff within given BDCs etc. | 13:27.27 |
| | So you can say "give me only the stuff on the page marked as being part of the first story". | 13:27.50 |
| tor8 | Robin_Watts: yeah. having a programmable filter would be pretty sweet. | 13:28.13 |
| | and have that hooked into the JNI bindings :) | 13:28.24 |
| | or better yet, just do it in javascript (ugh!) | 13:28.38 |
| Robin_Watts | I've not got quite that advanced in my thinking yet. I'm still thinking about it as a C level thing. | 13:28.46 |
| tor8 | it would be neat to be able to feed mutool clean a processor filter script on the command line :) | 13:29.11 |
| | I had been thinking that Lua bindings would be perfect for this sort of thing | 13:29.32 |
| | to do command line level PDF manipulation from a script | 13:29.57 |
| | but now we have mujs/occamscript/libjs/whatever-we're-going-to-call it | 13:30.14 |
| | anyway, the more immediate question of yours, how to set this stuff up | 13:30.36 |
| | I'd be in favor of a complete revamp of how the pdf_run_xxx stuff is called. the api has grown a bit out of control with how many entry points there are | 13:30.58 |
| | and I'd also rename pdf-op-run to pdf-op-draw | 13:31.13 |
| | "run" is generic and applies to all processors, IMO | 13:31.23 |
| Robin_Watts | tor8: The attraction of calling it 'run' is that we have "fz_run_page", and hence the runs match up. | 13:32.53 |
| | which is why I was tempted to use 'process' for the more general versions, and 'run' for the 'run to fz_device' versions. | 13:33.39 |
| | tor8: I'd love to simplify the pdf_run_page_contents_ etc, but it's not immediately trivial to see how. | 13:34.14 |
| | The changes in setup that have to happen on starting an XObject etc are all subtly different. | 13:34.57 |
| | That's why I ended up with run_annot, run_strream and run_contents entry points in the pdf_op_processor. | 13:35.28 |
| | If you can see a way to unify them nicely, I'd be interested. | 13:35.43 |
| | tor8, paulgardiner: New version of the commit pushed. | 15:01.50 |
| | I've squashed the filter changes into the original commit, and moved fz_device as paulgardiner suggested. | 15:02.12 |
| | I'll do that static inline thing now. | 15:02.42 |
| paulgardiner | Looking good | 15:13.39 |
| | Could make pdf_run_annot_with_usage flexible by passing it an op_processor instead of a device (provided op_processors were encapsulated as an object). Would save having to introduce other "run" functions to use different op_processors. | 15:16.08 |
| Robin_Watts | pdf_run_annot_with_usage is a static, right? Yes. That's where I was thinking of changing stuff. | 15:16.49 |
| | I like the idea of changing it to be pdf_process_annot_with_usage. | 15:17.17 |
| paulgardiner | Yeah. | 15:17.30 |
| Robin_Watts | pdf_run_... functions would imply the use of the pdf_op_run stuff. | 15:17.30 |
| | pdf_process_... functions would imply the use of any pdf_processor given. | 15:17.45 |
| paulgardiner | yeah, although you could just have one or the other and have the behaviour decided on the basis of the op_processor passed. | 15:18.45 |
| Robin_Watts | We have some pdf_run_... functions in our external published API already. | 15:19.27 |
| paulgardiner | Although obviously not perculating up as far as the fz interfaces, as you pointed out | 15:19.35 |
| | Oh I see | 15:19.50 |
| | process is the general one. run is specific? | 15:20.06 |
| Robin_Watts | That was my thought, yes. | 15:20.14 |
| paulgardiner | Nice | 15:20.19 |
| henrys | 2 minute until the meeting | 15:28.51 |
| | Does everyone know they have 30G of google drive because we have a business domain at google? | 15:30.25 |
| kens | News to me... | 15:30.33 |
| ray_laptop | just in time :-) | 15:30.45 |
| henrys | ray_laptop: only missed 2 sentences | 15:31.09 |
| ray_laptop | (not on logs yet) | 15:31.43 |
| marcosw | if you have a non-business google account you get 15G of google drive. | 15:31.51 |
| henrys | Does everyone know they have 30G of google drive because we have a | 15:32.39 |
| | business domain at google? (for ray_laptop) | 15:32.39 |
| | I updated the workflowy with ghostdocs business. | 15:32.55 |
| kens | thinks 15G will do for now | 15:32.57 |
| ray_laptop | I'm not sure what data I want to share with google. | 15:33.30 |
| Robin_Watts | henrys: Suggestions for other GhostDocs things: 1) Output limited to 565. 2) Lack of ODT support. | 15:33.53 |
| ray_laptop | Robin_Watts: ODT ? | 15:34.13 |
| Robin_Watts | Native format for open office/libre office | 15:34.28 |
| kens | open document thingy | 15:34.34 |
| | the opposite of OOXML | 15:34.41 |
| henrys | Robin_Watts: does that meant the requirement for a defect (modest proposal) | 15:35.02 |
| Robin_Watts | the goateeless version of ooxml :) | 15:35.04 |
| henrys | ? | 15:35.05 |
| ray_laptop | 565 seems archaic | 15:35.06 |
| kens | What is 565 ? | 15:35.27 |
| ray_laptop | and totally unacceptable for PPT | 15:35.38 |
| Robin_Watts | henrys: I don't follow. | 15:35.41 |
| ray_laptop | kens: I assumed it was 5 bits R 6 G 5 Blue | 15:36.02 |
| kens | Oh right | 15:36.09 |
| Robin_Watts | Wasp has the ability to render to a number of different screen depths built in. | 15:36.18 |
| | greyscale 8bit, and various 16bit depends (444, 555, 565) etc. | 15:36.37 |
| | Last time I looked it didn't support 32bit screen depths. | 15:36.46 |
| ray_laptop | or 24 ? | 15:36.57 |
| Robin_Watts | or 24. | 15:37.05 |
| | This means that when output is required on 24bit screens, we render to 565 and then convert up on blitting. | 15:37.32 |
| | (At least, that's my memory of the situation). | 15:37.44 |
| henrys | Robin_Watts: do Libre Office, Open Office and MS support ODT? | 15:37.57 |
| Robin_Watts | It is possible that someone has written 888 plotters since, but I doubt it. | 15:38.13 |
| kens | I believe all do now | 15:38.13 |
| Robin_Watts | Libre office and Open office certainly support it. It's their native format. | 15:38.28 |
| kens | I think MS do as well now | 15:38.37 |
| | (if you insist) | 15:38.42 |
| henrys | right MS was the question. | 15:38.48 |
| Robin_Watts | I don't know if MS supports it, but I'll believe kens. | 15:38.52 |
| kens | As I recall MS (grudgingly) added support recently | 15:39.14 |
| Robin_Watts | henrys: Oh, and 3) UI scaling problems as reported by tor. | 15:39.41 |
| henrys | where is tor's report? | 15:40.28 |
| Robin_Watts | here on irc. | 15:40.34 |
| | He said that on large screen devices such as his Nexus 10, the text fields were tiny. | 15:40.58 |
| | i.e. they weren't scaled with the overall resolution. | 15:41.20 |
| ray_laptop | I have a lot of lame-o apps on Windows that do that as well. | 15:42.06 |
| henrys | I think that is more suited for a bug in bugzilla then an entry in the agenda. Then I'll add a link to the agenda to ghostdocs bugs and we'll go through them at the meeting. | 15:42.13 |
| Robin_Watts | sure. | 15:42.48 |
| henrys | miles said something about pop up adds but I didn't see anything. | 15:43.19 |
| Robin_Watts | henrys: There is a "Lite" version of the app. I don't *think* it's ad supported, but... | 15:43.50 |
| | it's possible that the store bought version of SO2 advertises SO+? | 15:44.18 |
| | but I've not seen it personally. | 15:44.28 |
| henrys | yeah I have that one and it hasn't displayed an ad yet. | 15:44.44 |
| | I only just realized today when looking at the picsel page you meant real 3d with the glasses - I thought it was just some fancy bogus graphics patent or something. | 15:46.36 |
| | I see 19 ghostdocs bugs with a simple search I'll add the search link to the agenda. | 15:48.02 |
| Robin_Watts | no, real 3d with the glasses. | 15:48.03 |
| paulgardiner | I was involved with the 3d stuff a fair bit | 15:48.19 |
| Robin_Watts | Also, there are some phones (korean, I believe) that ship with lenticular screens. | 15:48.22 |
| | so you get true 3d with no glasses. | 15:48.44 |
| | yeah, I fettled Wasp for Denis for the 3d stuff. | 15:49.09 |
| | Picsel did a nintendo DS build too. Perhaps they were trying to sell it to Nintendo as something for use with the 3DS? | 15:50.02 |
| henrys | I'm just going to go through the agenda this time and add/remove stuff please chime in. | 15:51.40 |
| marcosw | ghostdocs regression testing needs to be on the agenda. | 15:52.34 |
| henrys | tor8: wow ms took razor | 15:53.11 |
| Robin_Watts | marcosw: GhostDocs -> Quality reports -> Artifex testing ? | 15:53.56 |
| henrys | marcosw: thanks | 15:53.56 |
| Robin_Watts | IF artifex testing isn't regression testing, what is it then? | 15:54.20 |
| henrys | clarified | 15:55.17 |
| Robin_Watts | ah, ok. | 15:56.26 |
| | henrys: is it worth me contacting Denis to talk about what the 3d patent is, and whether we actually infringe it? | 15:57.22 |
| henrys | Yes, I'd really like to keep that, now that I know the crazy glasses are involved. | 15:57.57 |
| | so where are we with lcms? | 15:59.01 |
| marcosw | Robin_Watts: regression testing is automated and doesn't involve comparing to known good output, all the ghostdocs testing so far as been comparing to microsoft office generated files by eye. | 15:59.23 |
| | I'm suggesting an agenda item to discuss how to implement regression testing. | 16:00.54 |
| henrys | I guess I'll add the "knock your socks off" prices for greek and cyrillic to the agenda. | 16:02.06 |
| Robin_Watts | marcosw: Right. I thought we were going to get ATS set up for that. | 16:02.46 |
| | http://www.google.com/patents/WO2009122214A3?cl=en <- That's the 3d patent. | 16:02.54 |
| chrisl | henrys: Is there much for us to discuss on that subject? | 16:02.57 |
| Robin_Watts | Supposedly the patent is still in "provisional" status. They haven't heard back whether it's been granted or not for over a year. | 16:03.59 |
| marcosw | Robin_Watts: ATS is the plan, but I think there are details to discuss. | 16:04.15 |
| henrys | chrisl: to me yes, in particular do we want to release something we think sufficient or do we need to emulate UFST - I think that is worth a discussion | 16:04.17 |
| chrisl | henrys: Okay, I rather thought you *did* want that, and the only thing remaining was whether we want to spend on it | 16:04.56 |
| tor8 | henrys: ms? razor? | 16:05.21 |
| henrys | http://www.asp.net/web-pages/tutorials/basics/2-introduction-to-asp-net-web-programming-using-the-razor-syntax | 16:05.56 |
| tor8 | henrys: oh... yeah, razor seems a pretty common name | 16:06.41 |
| henrys | chrisl: yes I do but miles isn't going to pay for all of it I suspect so we need a discussion about an intermediate plan | 16:07.50 |
| chrisl | henrys: Right, okay. | 16:08.23 |
| henrys | we are already past the 1/2 hour - so let's adjourn, I'll keep working the agenda for a while. | 16:09.31 |
| chrisl | Oh, FFS! Windows has just spent ~4 minutes "Preparing to Delete", and now seems to want me to confirm deleting every subdirectory because the top level one is shared :-( | 16:20.39 |
| kens | isn't there a check box for 'do the same for the next N conflicts' or whatever ? | 16:21.52 |
| chrisl | Nope | 16:22.01 |
| kens | Well that's even more crap than usual | 16:22.14 |
| chrisl | I opened a cygwin shell, and deleted there instead - took seconds | 16:22.47 |
| Robin_Watts | henrys: So, Denis isn't 100% sure who owns the 3d patent now. | 16:24.15 |
| | It's possible it was owned by Picsel at the time of the liquidation. | 16:24.26 |
| | which would mean that we could probably get rights to it from the liquidators. | 16:24.45 |
| | (on the grounds that they sold us the code etc, they damn well ought to give us the ability to use it) | 16:25.02 |
| paulgardiner | Don't we already own everything Picsel? | 16:25.39 |
| henrys | I'll ask miles to talk to the liquidators and I've changed the agenda item. | 16:26.37 |
| paulgardiner | Although I still have the recollection of Samsung and Picsel having an agreement beyond just Picsel selling some patents to Samsung, that f Picsel went bust again Samsung would get the rest of Picsel's patents. | 16:27.50 |
| Robin_Watts | paulgardiner: Indeed. We might own the patent without knowing it :) | 16:27.57 |
| | paulgardiner: This patent isn't granted yet. It's still provisional. | 16:28.09 |
| kens | That could keep lawyers in business for years ;-( | 16:28.32 |
| Robin_Watts | well, if samsung own the patent, then we might be able to get it rolled into the existing agreement. | 16:28.32 |
| ray_laptop | Robin_Watts: and it's still just 'pending' (provisional) ? | 16:30.47 |
| Robin_Watts | yes. | 16:32.06 |
| chrisl | Hmm, apparently our documentation says: "Attempting to generate a device independent Postscript Level 2 is a bad idea. Postscript Level 2 data are device dependent by definition". I reckon we should change that, because it's complete and utter bollocks....... | 16:32.19 |
| ray_laptop | chrisl: the original uses for ps2write (and our customer uses) WERE for driving printers, NOT 'device independent'. That being said, I think that comment was to address the issues that _some_ things will come out device dependent (at least resolution locked) | 16:36.43 |
| kens | And I'm busy writing in the bug thread that I'll remove that paragraph from the documentation | 16:37.18 |
| ray_laptop | when we flatten transparency, or Type3 comes in, we have to use the resolution | 16:37.25 |
| kens | Indeed, but that doesn't completely relate to a 'device' | 16:37.46 |
| | Too high or low a resolution won't fail, it will just be sub-optimal | 16:38.02 |
| ray_laptop | kens: no, it doesn't. But I think the specific examples should be mentioned. | 16:38.18 |
| | kens: and the suggestion that -r### can improve the quality of pre-rendered objects | 16:39.09 |
| | oops. | 16:39.15 |
| | kens: and the suggestion that -r### can improve the quality of pre-rendered objects | 16:39.35 |
| kens | SOrry, I missed that, network hiccuped | 16:39.48 |
| ray_laptop | kens: so I gathered. Did you see my comment that "specific examples should be mentioned." ? | 16:40.16 |
| kens | Yes, but I don't think there's an exhaustive list, and several switches interact in difficult to deine ways | 16:40.45 |
| | OK I have some compiler warnings to look at and the docs to rewrite, but I'm nearly done with this | 16:41.40 |
| ray_laptop | kens: OK. Maybe just the suggestion that if you know the resolution of the target printer, use -r### to set it to match | 16:41.50 |
| kens | That's probably the most relevant one | 16:42.05 |
| | Too high results in large slow PostScirpt and since the default is 720 that's the most likely | 16:42.26 |
| ray_laptop | so that pre-rendered or flattened graphics are at a suitable resolution | 16:42.28 |
| | kens: ps2write could easily have a different default resolution (say 300) to pdfwrite, right ? | 16:43.15 |
| kens | Hmm, yes I htink so | 16:43.24 |
| | I beleive they have different structures and initialisers | 16:43.40 |
| chrisl | ray_laptop: (sorry doorbell) "Certain objects may have to be rendered at a device dependent resolution" is a very different implication to "Postscript Level 2 is, by definition, device dependent". | 16:46.20 |
| ray_laptop | kens: looks like just #define X_DPI and Y_DPI before #including gdevpdfb.h | 16:47.19 |
| kens | Probably | 16:47.26 |
| Robin_Watts | tor8: ping | 17:10.52 |
| | paulgardiner: ping | 17:11.00 |
| | How do we feel about returning structs in mupdf? | 17:11.11 |
| | Specifically, how would we feel about having a pdf_processor struct that was a function pointer and a void * argument, and having a function that returned such a struct. | 17:11.50 |
| tor8 | Robin_Watts: you're the one who doesn't like returning structs. remember fz_point and fz_matrix being returned back before you went all pointery? ;) | 17:20.55 |
| | I have absolutely no objections about passing around simple structs as composite values | 17:21.23 |
| Robin_Watts | I dislike passing structs. | 17:21.41 |
| | fz_point is arguable. fz_matrix is bad. | 17:22.03 |
| sebras | tor8: yo, do you want me to show up one more day and we can try to fix those last remaining TODOs? | 18:39.01 |
| zeniko | Robin_Watts: paulgardiner: thanks for updating jbig2dec, please don't forget to also update openjpeg | 18:40.19 |
| | BTW: openjpeg seems to have been resurrected | 18:40.35 |
| sebras | zeniko: oh, did you also get a few mails from them today? | 18:40.54 |
| zeniko | what's your stance on sharing testcases from the two fuzzing runs with them? | 18:41.12 |
| | (I've sent them a bunch of JP2 code streams back in June, asking for confidential treatment, and they've been added to their public(?) test repo) | 18:41.48 |
| | sebras: more than just a few | 18:42.02 |
| Robin_Watts | zeniko: The suppliers of the fuzzed files don't want the raw files spread willy nilly across the net, but they have no problem with the extracted test data being shared with the appropriate people. | 18:42.22 |
| | so extract the jp2 streams from the pdf code and send that, and we're fine. | 18:42.50 |
| | zeniko: Yeah, I plan to look at the opj stuff as soon as I get what I'm doing into reasonable shape. | 18:43.22 |
| | zeniko: You may want to watch my repo in case you have thoughts on what I am doing. | 18:43.42 |
| t4nk747 | hi | 19:04.57 |
| ghostbot | hello | 19:04.57 |
| t4nk747 | my problem is regarding android mupdf' | 19:05.17 |
| | see this bug Bug 695071 | 19:05.30 |
| | have u chkd it | 19:05.54 |
| Robin_Watts | Hi | 19:05.57 |
| ghostbot | bonjour | 19:05.57 |
| t4nk747 | or ching? | 19:05.57 |
| | hi robin | 19:06.06 |
| Robin_Watts | yes, I just closed that bug. | 19:06.13 |
| | What version of the MuPDF source are you working from | 19:06.25 |
| | ? | 19:06.27 |
| t4nk747 | but my issue is not solved sir | 19:06.27 |
| | 1.2 | 19:06.33 |
| | is it ok? | 19:06.45 |
| Robin_Watts | Well, 1.3 is the latest release. | 19:06.47 |
| t4nk747 | or 1.3 i should try? | 19:06.52 |
| Robin_Watts | and we are about to release 1.4 | 19:06.55 |
| t4nk747 | yes i know but i hve no idea how to workout easily with 1.3 so | 19:07.20 |
| Robin_Watts | Certainly we aren't going to go hunting for build bugs in 1.2 | 19:07.27 |
| t4nk747 | dat's nice | 19:07.30 |
| | but can u tel me one thing | 19:07.46 |
| Robin_Watts | Is there any particular reason you are still using 1.2? | 19:07.59 |
| t4nk747 | i have already res_shade.c file in my fitz folder | 19:08.13 |
| | so how can it be dying as per your saying | 19:08.26 |
| Robin_Watts | I don't know. | 19:08.32 |
| t4nk747 | ok | 19:08.41 |
| | so can you tell me how to work with | 19:08.52 |
| | 1.2 | 19:08.54 |
| | sory 1.3 | 19:08.58 |
| Robin_Watts | The smartest way to work is to use git. | 19:09.02 |
| | because then you get access to all our fixes as we do them. | 19:09.15 |
| t4nk747 | ok | 19:09.22 |
| Robin_Watts | Find a clean directory on your harddrive, and do: | 19:09.42 |
| | git clone --recursive git://git.ghostscript.com/mupdf.git | 19:09.48 |
| t4nk747 | and what is the price if i wants to buy commercial liance | 19:09.48 |
| Robin_Watts | and that will copy out the latest git repo into a "mupdf" directory. | 19:10.04 |
| | You can then get all our updates just by pulling them from us. | 19:10.22 |
| | I can't give you a price for the commercial license. | 19:10.36 |
| t4nk747 | ok..dats nice to heard | 19:10.39 |
| | but as i am new i have to first learn about how to import from git | 19:11.04 |
| Robin_Watts | We tailor make our commercial licenses according to the requirements of the customer, hence there is no "one size fits all" license fee. | 19:11.06 |
| t4nk747 | r clon from git | 19:11.10 |
| Robin_Watts | If you mail sales@artifex.com, you can speak to our sales guru, Scott Sackett. | 19:11.53 |
| t4nk747 | if i require it for 1 year so how much it will cost me | 19:11.54 |
| | ok..np | 19:12.08 |
| | thanks for de info | 19:12.14 |
| Robin_Watts | He will mail you back with a huge list of questions, many of which will not apply to you. Basically answer as many of the questions as well as you can. The idea is to give him as many details as possible about what you want to do. | 19:12.37 |
| | he will then get back to you with a licensing proposal. | 19:12.52 |
| t4nk747 | ok..nice to hear | 19:13.08 |
| Robin_Watts | He's traveling at the moment, so he may not reply instantly. If you don't get a reply within 48 hours though, come back here and ask me. | 19:13.51 |
| t4nk747 | and please look back if you have any idea to following error | 19:13.57 |
| | make: *** No rule to make target `/home/developer/workspace/TestAndroid/jni/../../fitz/res_shade.c', needed by `/home/developer/workspace/TestAndroid/obj/local/armeabi/objs/mupdfcore2/__/__/fitz/res_shade.o'. Stop. | 19:14.07 |
| | because i am about to finish | 19:14.39 |
| Robin_Watts | t4nk747: No. I feel I have been quite clear on this. I am not going to invest time and effort into hunting down a bug in 1.2. | 19:14.45 |
| t4nk747 | ok | 19:15.03 |
| Robin_Watts | If the same thing happens with the git code (or 1.3) then I will be more likely to help. | 19:15.04 |
| t4nk747 | thank u for your time | 19:15.11 |
| Robin_Watts | no problem. | 19:15.14 |
| t4nk747 | and nice discussing with you | 19:15.22 |
| | bye...good night... | 19:15.46 |
| Robin_Watts | tor8, paulgardiner, sebras, zeniko: New patch pushed. | 19:33.29 |
| | opinions gratefully received. | 19:33.39 |
| sebras | Robin_Watts: "ediding" in the commit message | 19:37.39 |
| Robin_Watts | sebras: Thanks. | 19:40.05 |
| sebras | Robin_Watts: since you need to update the win32 makefiles to add the new files, what about android/ios/whatever..? | 19:44.52 |
| Robin_Watts | Yes, I need to update for android. | 19:45.25 |
| | I have no clue about ios. | 19:45.37 |
| | unix 'just works' as it uses fitz/*.c etc | 19:45.55 |
| sebras | Robin_Watts: indeed, ain't tor8 clever. ;) | 19:46.13 |
| Robin_Watts | but I'm anticipating having several more revisions of this until everyone is happy. | 19:46.28 |
| | I'm sure that naming alone will be contentious. | 19:46.54 |
| sebras | Robin_Watts: so the filter set is meant to be used for optimizing the commands in a stream as I understand it..? | 19:47.57 |
| Robin_Watts | sebras: Yes. | 19:48.10 |
| sebras | from the commit message the buffer set is really unclear to me. | 19:48.25 |
| Robin_Watts | The plan is that we could set up a filter one on top of a buffer one. | 19:48.34 |
| | Then you process the stream through that, and what ends up in the buffer one is a replacement version of the original stream, but 'washed'. | 19:49.12 |
| | Updated commit message. | 19:56.03 |
| | paulgardiner: For the logs: tests_private/pdf/PDF_1.7_FTS/fts_19_1908a.pdf seems to be showing an annotation now, when it shouldn't be ? | 19:58.50 |
| sebras | Robin_Watts: so basically this is a layer of indirect calls to functions that each do whatever each operator is meant to do. | 19:59.57 |
| | in the normal rendering case. | 20:00.02 |
| | and some specialized optimization things in the filter case. | 20:00.16 |
| | how does this affect speed? (if at all) | 20:00.35 |
| Robin_Watts | In the old code, we used to call: pdf_run_<opname> | 20:00.46 |
| | for each operator. | 20:00.55 |
| | We now call: op_table[op_number](); | 20:01.19 |
| sebras | yes and now we get that pointer from an array, yes. | 20:01.27 |
| Robin_Watts | I would imagine that it's slightly slower, but not noticably so. | 20:01.39 |
| | sebras: for the record, would you nod sagely at: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=096272252c0d00449bb68c7fddecc13ec2cecdd0 please? | 20:03.13 |
| sebras | Robin_Watts: LGTM | 20:05.15 |
| | ok, so I ran mudraw -m pdfref10.pdf in valgrind for 1.2, 1.3 and your version. | 20:05.49 |
| | it is actually quicker by 2 seconds, but that may be due to caching perhaps. | 20:06.15 |
| | what surprises me is that in 1.2 we used to do 217k alloc/frees for pdfref10.pdf and we now do 735k! | 20:06.38 |
| | we also alloc slightly more memory. | 20:06.50 |
| | but I can't attribute any of this to your changes if I read my statistics correctly. and that's reassuring. | 20:07.11 |
| tor8 | sebras: that's a bit unsettling :( | 20:13.02 |
| sebras | tor8: indeed. | 20:13.09 |
| tor8 | Robin_Watts: I have a headache, I'll look at your patch tomorrow. | 20:13.12 |
| sebras | tor8: http://pastebin.com/nhLSWF6k | 20:13.29 |
| Robin_Watts | tor8: sure. | 20:14.46 |
| sebras | Robin_Watts: do I read your code correctly if I assume that PDF_OP_MAX is what is causing the execution of free_processor_*()? | 20:14.48 |
| Robin_Watts | sebras: yes. | 20:15.19 |
| | possibly I could put that as a separate entry point now. | 20:15.37 |
| | Initially I only had the array. | 20:15.44 |
| sebras | Robin_Watts: yes, that would be clearar. | 20:15.49 |
| Robin_Watts | will do that. | 20:15.54 |
| sebras | bisect awards the price to 08c6320 which together with the necessary 7eddc1c seems to increase the number of malloc() calls by 500k. | 20:27.56 |
| Robin_Watts | oooh. | 20:29.15 |
| sebras | Robin_Watts: do you see why? | 20:30.39 |
| | Robin_Watts: is that the pdf_new_*() ones that are added by pdf_array_push()? | 20:31.36 |
| | that would be my guess. | 20:32.03 |
| Robin_Watts | OK, so previously we'd lex things and wouldn't turn them into real pdf things. | 20:33.19 |
| | now we do. | 20:33.25 |
| sebras | mm, that's what I think too. | 20:33.32 |
| Robin_Watts | I *hope* the pdf_array stuff shouldn't need to keep expanding the array as it should just grow once, but there will be more mallocs. | 20:34.13 |
| | BUT, I think it's the right thing to do to treat this stuff properly. | 20:34.27 |
| sebras | as long as we are convinced. | 20:34.59 |
| Robin_Watts | Well, I'm open to other ideas. | 20:37.08 |
| | The old code used to read strings/numbers from the file and call show_space or show_char on them directly. | 20:37.50 |
| | That was bad because 1) it didn't let us cope with BT [(blah) 20 (foo) 10.0 Tc (baz)] TJ ET in the same way that Acrobat does. | 20:39.01 |
| sebras | Robin_Watts: re: your patch, maybe it is wise to wait with introducing filter and buffer until they are used. | 20:41.34 |
| | Robin_Watts: i.e. in a separate patch. | 20:41.35 |
| | Robin_Watts: don't get me wrong, I wasn't complaining. :) | 20:43.14 |
| Robin_Watts | sebras: Sure. I can factor them out. But probably people want to see them to understand the purpose of this work. | 20:45.10 |
| sebras | Robin_Watts: I'd explain that in out-of-band communication. | 20:45.33 |
| Robin_Watts | internet connection playing up for some reason. | 20:45.48 |
| | sebras: I mean it makes sense to have them all in one patch now, but I can refactor before committing if required. Whatever gives the clearest history. | 20:46.24 |
| sebras | Robin_Watts: I haven't checked each op-implementation for "run", but it look reasonable to me. | 20:46.33 |
| Robin_Watts | sebras: Tnat's pretty much the existing code :) | 20:46.59 |
| sebras | Robin_Watts: yup, I know. | 20:47.12 |
| | Robin_Watts: so the intent is to provide this layer to be able to introduce optimizations (since the normal "run" path is virtually unchanged). | 20:48.28 |
| | maybe you guys have been discussing this earlier today when I wasn't paying attention. | 20:48.51 |
| Robin_Watts | sebras: In order to do certain things (like bates numbering etc), we need to be able to manipulate operator streams. | 20:49.44 |
| | add some operators, remove some etc. | 20:49.55 |
| | And we can't do that easily at the moment with the code we have. | 20:50.08 |
| | With this stuff we can do it much more easily, as we can ensure that operator streams are 'sane' and that the graphics state hasn't been left in a bonkers state. | 20:50.42 |
| henrys | hey mvrhel_laptop how goes it? | 20:52.19 |
| mvrhel_laptop | henrys: hi. good over all. smart office seems to be generating a lot of interest | 20:53.35 |
| henrys | is it helping us rip wise or do they just want smart office? | 20:54.31 |
| mvrhel_laptop | well miles has his plan to make it painful to have one without the other. getting into the controller is a difficult change for some of these places. but they all recognize the importance of working with mobile devices for the future and handling a variety of document types | 20:57.24 |
| henrys | how's takanesan? | 20:58.23 |
| mvrhel_laptop | good. scott and I went out for sushi with him last night | 21:02.47 |
| | off to shower.. | 21:06.38 |
| henrys | see you, good luck ! | 21:06.52 |
| kens | Goodnight all | 21:07.47 |
| henrys | late night kens bye | 21:08.13 |
| kens | :-) | 21:08.17 |
| | Stella was at a lecture in London | 21:08.26 |
| wolever | I'm having trouble with -dDownScaleFactor â it doesn't seem to have any effect. Copying the exact example from the docs (gs -sDEVICE=png16m -r600 -dDownScaleFactor=3 -o x.png x.pdf) produces a PNG file with the exact same resolution as the same command without a -dDownScaleFactor | 21:51.24 |
| | This is GS 9.00 | 21:51.31 |
| | Here's a more detailed description: http://stackoverflow.com/q/22027143/71522 | 21:58.10 |
| mvrhel_laptop | off to the trains. we rode 10 yesterday. | 22:12.54 |
| | Forward 1 day (to 2014/02/26)>>> | |
IRC Logs