| | <<<Back 1 day (to 2013/04/08) | 2013/04/09 |
| wordToDaBird | question for the mupdf guys, would you like for the iPhone app to allow for printing of the document? | 00:18.18 |
| kens | Oh dear chrisl, avadhut seems even more dense than usual.... | 07:19.01 |
| chrisl | kens: yeh :-( | 07:19.13 |
| | Hmm, actually, maybe not..... | 07:23.18 |
| kens | DO we have any jbig2 devices ? o.O | 07:23.34 |
| chrisl | gdevjbig2.c | 07:23.45 |
| kens | Good grief | 07:23.54 |
| | THey don't really listen though, do they, its not going to be significantly better than CCITT G4 faqx. | 07:24.25 |
| chrisl | And the Makefile has a line "DEVICE_DEVS7=$(PSD)jbig2.dev" - but the jbig2 device doesn't appear | 07:24.41 |
| | Looks like there is a bug in the configure script :-( | 07:27.57 |
| kens | Shows how many people use jbig2 | 07:28.19 |
| | Even when you fix it they'll probably just complain that its not smaller than G4 | 07:28.34 |
| chrisl | Well, given that the jbig2 output device is commented as being "for testing", I don't hold out much hope of it working well! | 07:29.24 |
| kens | You should probably point this out, and explain that's why it isn't present in the build ;-) | 07:29.48 |
| chrisl | It actually should be present in the build when we build with Luratech, but the Makefile ends up with "$(PSD)jbig2.dev" when it should have "$(DD)gdevjbig2.dev" in it | 07:30.52 |
| kens | I bet that's an oversight from when Ralph reorganised the directories | 07:31.24 |
| | Which shows how long its been since anyone last built with this enabled | 07:31.39 |
| chrisl | Everyone that builds with Luratech should get it, it's added automatically to the Makefile when configure sees we're using Luratech | 07:32.43 |
| kens | Well, the last time anyone *wanted* it then | 07:33.31 |
| chrisl | So, do I be helpful, or do I reply to what they've actually reported? | 07:34.09 |
| kens | Well, they have helped you find an oversight | 07:34.33 |
| | But I'd still be inclined to point out that the device is 'for testing' to forestall the next set of 'it doesn't work the way we expected' bugs | 07:35.04 |
| chrisl | True, but they've asked about jbig2DEC and want to know why there isn't a jbig2 *output* device! | 07:35.16 |
| kens | Yes, that was what I meant when I said they were being denser than usual.... | 07:35.35 |
| | ANyway. if you point it out you'll just get another one later | 07:35.50 |
| | Hmm fixing the widths stuff improved the output (very slightly, you wouldn't see it without specifically looking) and made teh final compressed file 10k smaller, which is pretty good. | 07:36.42 |
| chrisl | I'll post them a fixed configure script. | 07:36.56 |
| kens | Yeah, seems reasonable. But I would still poitn out about the device though | 07:37.15 |
| chrisl | I will, and about how pointless JBIG2 is when you deal with plain raster data | 07:37.46 |
| kens | :-) | 07:37.54 |
| | As expected my widths change results in 2700 differences :-( | 07:38.16 |
| | Hopefully they are all miniscule movements o text but I'll have to check them all. Marcos will love me.... | 07:38.38 |
| Robin_Watts | wordToDaBird: Yes. Are you volunteering? | 09:14.11 |
| | kens: bmpcmp -w 3 ? | 10:27.03 |
| kens | Hmm maybe | 10:27.17 |
| | Looks like the cluster restarted the bmpcmp all on its own, and this time it seems to be nearing completion. I confess I have no idea what's going on here. My last bmpcmp was bigger and completed OK but a number of the images were 'unsupported data type' again. | 10:41.33 |
| | Robin_Watts : what do red pixels in the 'diff' window mean ? | 11:08.39 |
| Robin_Watts | Differences are either green or red. One of them is for 'small' differences, but I can't remember which. | 11:09.17 |
| kens | Hmm, maybe red, I've never seen those before, perhaps those are inside the 'w' number ? | 11:09.48 |
| Robin_Watts | kens: could be. | 11:09.57 |
| | I would have said that green was inside the w number and red was bad, but that doesn't fit with your first bitmap result... | 11:12.01 |
| kens | Normally I don't use w and tehy are all green | 11:12.16 |
| | THough I would have thought that a difference inside 'w' would be green, that would make sense to me.... | 11:12.55 |
| Robin_Watts | kens: There is a comment at the top of bmpcmp.c I think, but I wouldn't trust the colors exactly, as I may break out of the search early... | 11:13.36 |
| kens | TBH its not important, as long as hte diffs are highlighted somehow, I need to look at all of tehse | 11:14.05 |
| Robin_Watts | kens: Halftoned stuff clearly throws it all off. | 11:14.28 |
| kens | Its worse with halftoned data certainly but I see it in other places too | 11:14.45 |
| Robin_Watts | You might want to retest with --filter=ppmraw etc to avoid the halftoned cases, then bmpcmp that. | 11:14.48 |
| kens | Not that worried, its only 32 pages | 11:15.03 |
| | In this case I'm only looking for gross differences with text position | 11:15.29 |
| Robin_Watts | Gah. This armeabi thing is killing me. | 11:15.47 |
| | I was sure I had the compile flags right this time :( | 11:16.00 |
| kens | is glad to be nowhere near that | 11:16.01 |
| Robin_Watts | goes for a run. | 11:16.40 |
| cinch | can the -dNOGC flag be recommended in production? it speeds up conversion here by 10-20% | 12:17.00 |
| kens | It turns off garbage collection, so objects which are no longer in use will not return their memory to be reused until the process exits. Obviously this will increase memory consumption. If you find it works then you can use it, its really up to you | 12:18.17 |
| cinch | ok thank you | 12:19.19 |
| | with our PC's memory shouldn't be an issue, i'll see how it goes | 12:19.39 |
| tor8 | Robin_Watts: I can't help but think the compressed buffer creation for images in cbz and xps could use a wrapper function | 12:27.26 |
| Robin_Watts | tor8: Where are you looking? | 12:34.49 |
| | I've just been working in the whole images area, but I haven't pushed the final version for review yet. | 12:35.15 |
| | (It's still going wrong in some cases I can't understand) | 12:35.24 |
| | But I got sidetracked into this damn v8 problem. | 12:35.36 |
| | I am tempted to just set the build up so that armeabi phones don't get forms etc. | 12:35.54 |
| | at least until I get an answer from the v8 devs. | 12:36.13 |
| tor8 | just peeking at your fz_image patch | 12:37.19 |
| | Robin_Watts: sebras mentioned a desire for a slow simple plain c javascript interpreter and wondered "how hard can it be?" yesterday | 12:38.15 |
| Robin_Watts | I've written an ecmascript engine in C before (for the flash player at my last job). | 12:39.59 |
| | The answer is that the central engine ain't that hard. The libs are the killer. | 12:40.16 |
| tor8 | maybe time to try out spidermonkey? it looks to have a C api (or very C-like if indeed it is c++) | 12:47.48 |
| Robin_Watts | tor8: crap license though? | 12:56.43 |
| tor8 | MPL, should be good I think | 12:58.17 |
| Robin_Watts | I have 1 last idea to try after lunch before I give up for now. | 12:58.27 |
| tor8 | Robin_Watts: wikipedia lists spidermonkey as the js engine in adobe reader | 13:41.02 |
| henrys | 5 of the meeting | 14:55.17 |
| Robin_Watts | I've got a friend who's in trouble with his car. Flat tyre, and has slipped off the jack etc. | 14:55.18 |
| | I'm going to have to run out to help him. I'll be back as soon as I can. Sorry! | 14:55.34 |
| henrys | no problem | 14:55.40 |
| Robin_Watts | I have nothing particular for the meeting except to say that I hate compilers/linkers/build systems more than usual this week. | 14:56.13 |
| henrys | paulgardiner, tor8:if you are going to be around a while we could do the meeting after the gs meeting? | 14:56.46 |
| paulgardiner | Yeah, that should be ok. | 14:57.55 |
| tor8 | okay. | 15:18.14 |
| Robin_Watts | back, sorry about that. | 15:19.06 |
| | Right, my last ditch attempt to make armeabi v8 libraries just failed. | 15:26.15 |
| | so I'm going to set it up so that armeabi builds don't get v8. | 15:26.43 |
| | marcosw: kens has been experiencing problems with bmpcmp. | 15:42.35 |
| kens | intermittent though | 15:42.46 |
| marcosw | what did I break now? :-) | 15:42.56 |
| Robin_Watts | I had a quick look, and it looked like not all of the results were getting back from the nodes. | 15:43.05 |
| | sometimes there would be 10 baseline files and 7 'new' files or something, out of 21 tests. | 15:43.32 |
| | so the only ones that got results were the 2 or 3 that happened to have both. The others had an error from bmpcmp saying it couldn't recognise the image format. | 15:44.05 |
| deleet | Robin_Watts: spidermonkey is easy to compile for, I can give you the configure I use | 15:44.47 |
| marcosw | Robin_Watts: is the latest bmpcmp one that has issues? The logs won't have much information for earlier jobs. | 15:46.08 |
| kens | I think the latest one was OK | 15:46.22 |
| marcosw | kens: the next time it happens send me an email without running another bmpcmp and I'll have a look. From Robin_Watts' description it's possible that some of the nodes are either missing some software or are otherwise broken; that would explain why it's intermittent. | 15:49.21 |
| kens | ok marcosw | 15:49.32 |
| marcosw | kens: you could run one now, assuming that your latest clusterpush produced differences. | 15:50.23 |
| kens | I did a bmpcmp on it and it was OK | 15:50.39 |
| henrys | was mvrhel_laptop supposed to be out today? | 15:59.58 |
| kens | holiday I think | 16:00.05 |
| | yes 8th until 12th | 16:01.12 |
| henrys | for the meeting I just had a bunch of bugs to discuss starting with status of alexcher's 693658 and 693659 | 16:01.27 |
| | and some reminders from the agenda for chrisl: svg removal and vmthreshold 8 meg | 16:02.06 |
| chrisl | henrys: yes, haven't forgotten either of those | 16:02.54 |
| | henrys: question: what's the process for when we close a bountied bug? | 16:04.05 |
| henrys | chrisl:you can assign it to me. I think Miles is used to talking to me about the bounties but I don't feel strongly about it. | 16:04.53 |
| alexcher | henrys: I've picked most easy problems from these cases. The rest should be, probably, re-tested and separated into individual bugs. | 16:05.12 |
| chrisl | henrys: that's fine, I'll assign it to you | 16:05.30 |
| henrys | alexcher:well do you need marcosw to help you with that - he typically does that. | 16:05.43 |
| marcosw | now that I've written a script that can enter bugs it's easy to enter individual bugs :-) | 16:06.19 |
| alexcher | henrys: yes, this would help a lot. | 16:06.59 |
| henrys | marcosw:I'll take a copy of that. | 16:07.03 |
| marcosw | henrys: as is true for almost everything I do it's undocumented and buggy, but I can email it it you. | 16:07.57 |
| henrys | without michael or ray I didn't have any other stuff, they have the interesting bugs. Does anyone know if 693583 has been fielded at all? | 16:09.01 |
| | alexcher:so assign both bugs to marcos | 16:09.43 |
| alexcher | OK | 16:10.04 |
| Robin_Watts | henrys: Michael and Ray discussed 693583 on here, with me (and maybe others) chipping in a bit. | 16:10.58 |
| | They have a plan, I believe. | 16:11.07 |
| henrys | Robin_Watts:thanks | 16:11.54 |
| | I'll text him | 16:12.00 |
| | kens:I was going to ask you about a few of my valgrind issues to do with high level color/patterns in PCL but we can probably defer that. | 16:14.23 |
| | marcosw:are you okay doing the assignments for those bugs. | 16:15.57 |
| | ? | 16:16.00 |
| | let me know if you want me to do some. | 16:16.13 |
| | I did text ray but I don't have anything else for this meeting. | 16:16.50 |
| marcosw | henrys: you mean the bug i'm going to enter from splitting up 693658 and 693659? I was going to use the same dartboard as I used for the valgrind issues. | 16:17.27 |
| henrys | well since the dartboard talks back it shouldn't be a problem. | 16:17.56 |
| kens | henrys I think I still havean enhancement for hiigh level patterns in PCL | 16:20.04 |
| henrys | kens:I do believe that is the issue with 693833 and its duplicates | 16:21.22 |
| kens | I cna look at thaT NOW, BEEN DISTURBED FORM COLOUR STUFF, SO IT S NOT A PROBLEM | 16:21.55 |
| | sorry caps lock | 16:22.19 |
| Robin_Watts | removes the voltage from kens underpants. | 16:22.23 |
| henrys | pcl->pdf has that effect on him ;-) | 16:22.40 |
| | kens:are you off color until michael returns? | 16:23.11 |
| kens | not totally, but its a natural break atm | 16:23.33 |
| henrys | kens:okay I can simplify files as needed let me know. | 16:23.53 |
| kens | I'll start tomorrow :-) | 16:24.02 |
| alexcher | I need to leave at 12:30 for family reasons. | 16:25.01 |
| henrys | if kens or chrisl or alexcher have any insight into pdf signatures (see paul's status report) please weigh in | 16:25.24 |
| | okay alexcher. | 16:25.31 |
| kens | No idea sorry | 16:25.34 |
| paulgardiner | henrys: actually, I think I'm past my confusions now. | 16:25.50 |
| henrys | paulgardiner: oh great | 16:26.07 |
| paulgardiner | Not to say that it's easy to implement, but I think I can see how it works now. | 16:26.31 |
| | I'm now looking at how to apply openssl. | 16:27.13 |
| | We do has some bigish jobs if we wish to sign documents, in that we need to support saving by partial update. | 16:27.45 |
| Robin_Watts | We need openssl because of certificates etc? | 16:27.55 |
| paulgardiner | Robin_Watts: yeah, all sorts of standards are involved, pkcs7, asn1 rsa x509 | 16:28.35 |
| henrys | good segue into the mupdf meeting. | 16:28.55 |
| Robin_Watts | We've previously done stuff ourselves (see the md5, rc4, aes stuff). | 16:29.17 |
| henrys | why partial update can parts of the document be signed? | 16:29.22 |
| Robin_Watts | It's always a shame when we pull in new libs. Can we maybe chip the bits off OpenSSL that we need? | 16:29.45 |
| paulgardiner | henrys: typically you sign the doc in one state, but want to alter it without removing the initial signature | 16:30.09 |
| | Robin_Watts: I don't think we need to make the MuPDF library depend on openssl. Just signature-enabled apps | 16:30.48 |
| henrys | paulgardiner: okay I should probably read the spec. I assumed you encrypted with a private key and then it would be readable with your public key. | 16:31.22 |
| paulgardiner | Robin_Watts: in any case, I think a first implemenation should use openssl. We could then implement our own stuff if we thought it reasonable | 16:31.24 |
| kens | henrys can you point me at one of teh nug numbers for PCL an dhigh level colour ? | 16:32.04 |
| | bug* | 16:32.09 |
| paulgardiner | henrys: you hash the doc and then privater-encrpt the hash | 16:32.14 |
| Robin_Watts | henrys: In some cases, you want to sign a document to prove it's authentic (with your private key), but to leave it readable for the world. | 16:32.17 |
| | So someone might "sign" a draft of a document to say they've approved it. | 16:32.42 |
| paulgardiner | henrys: but you then cannot change the doc at all without either invalidating the signature, or using partial update. | 16:32.47 |
| Robin_Watts | Then someone else might want to sign that too. | 16:32.50 |
| paulgardiner | Robin_Watts: yes, or sign as author of a form, for other people to sign when they have filled it in | 16:33.38 |
| henrys | paulgardiner:so somehow the state is saved I can say A signed one part and B signed after this modification? | 16:33.57 |
| paulgardiner | Signing as author is common so as to be able to define the rights of others to make changes | 16:34.11 |
| henrys | kens:693833 and it's dups in the comments | 16:34.26 |
| Robin_Watts | henrys: AIUI, the first signing saves the document as normal, with a signature section that says "The combination of the bytes of the document with my private key is... " | 16:35.15 |
| paulgardiner | henrys: the state is saved by the incremental update mechanism, just in that it creates a new doc that has the previous one as a prefix | 16:35.25 |
| Robin_Watts | People can then verify that using the private key. | 16:35.44 |
| | public key. | 16:35.47 |
| henrys | got it thanks. | 16:35.54 |
| Robin_Watts | Then if people want to sign it again... the incremental update thing needs to be used. | 16:36.07 |
| paulgardiner | If I've said "partial update" anywhere, I meant "incremental update" | 16:36.08 |
| henrys | paulgardiner:is that something for tor8 or Robin_Watts or are you doing that? | 16:36.41 |
| | incremental update | 16:36.56 |
| Robin_Watts | That's something that we're all going to have to think about I think. | 16:37.11 |
| paulgardiner | henrys: I was going to look at checking signatures first, which involves other nasty things, but not partial update. | 16:37.17 |
| Robin_Watts | Incremental update is not hugely compatible with the way we work, I fear. | 16:37.46 |
| paulgardiner | I'd be interested to have a go at incremental update, but as Robin_Watts says, we'll all need to discuss it, and whether I should do it probably depends on your priorities. | 16:38.03 |
| Robin_Watts | certainly not the way saving currently works. | 16:38.09 |
| | I think it may require some tweaks to our core data structures; I think we only store 1 object per number currently. | 16:39.01 |
| | we'd need to extend that to hold older generation object numbers too. | 16:39.18 |
| paulgardiner | Yeah, doesn't sound like rocket science though. | 16:39.31 |
| henrys | Robin_Watts:once you have mupdfwrite going would it be possible to simply output something afresh as a stopgap? | 16:39.44 |
| Robin_Watts | No, but there may be lots of buried assumptions. | 16:40.00 |
| tor8 | if we use a big enough chunk of code for encryption, I think we should just use the library | 16:40.03 |
| paulgardiner | henrys: that's sort of exactly what you can't do because the hash must not change. | 16:40.17 |
| Robin_Watts | henrys: We can already save documents. | 16:40.24 |
| tor8 | partial update should be possible by just flagging changed objects in the xref struct | 16:40.37 |
| henrys | paulgardiner: oh of course. | 16:40.44 |
| Robin_Watts | The bit that's missing for pdfwrite is the graphical object -> pdf operators conversion. | 16:40.52 |
| tor8 | then when saving we'd open as append (or copy the original first) then write the changed objects and write a completely new xref at the end | 16:41.01 |
| paulgardiner | tor8: yeah, that doesn't sounds too horrendous... until we actually try it that is. :-) | 16:41.33 |
| tor8 | being fancy we could do the whole "generation number" and partial xrefs scheme, which will likely fail horribly everywhere | 16:42.07 |
| paulgardiner | We'd also need to be able to read in such files and not lose the fact that there are two versions of the doc | 16:42.15 |
| tor8 | paulgardiner: shouldn't matter (except for xref duplication bloat) or what do you mean? | 16:42.54 |
| Robin_Watts | Right. Currently when we load, we throw away all references to old objects - we only keep pointers to the most recent generation of objects in memory. | 16:43.18 |
| paulgardiner | Part of the checking procedure is making sure that the later version didn't make changes that the pervious version said were disallowed | 16:43.25 |
| tor8 | (as an aside, old old old versions of mupdf had the xrefs in a linked structure like in the pdf file, with different sections) | 16:43.39 |
| paulgardiner | git reset :-) | 16:44.25 |
| tor8 | paulgardiner: this might've been back before the darcs time | 16:45.00 |
| | sebras may have a tarball of the original mupdf cvs repo somewhere | 16:45.12 |
| paulgardiner | tor8: yeah, I thought it might have been | 16:45.20 |
| henrys | get out you haskell interpreter ;-) | 16:45.32 |
| | oh before darcs even | 16:46.02 |
| tor8 | henrys: yeah, I think that was how the original mupdf that I wrote before coming to Artifex worked | 16:46.27 |
| henrys | the other mupdf issue is Robin_Watts schedule for raph. | 16:46.46 |
| paulgardiner | "Utility based on the author's "theory of patches" in which they are likened to operators in quantum mechanics." | 16:46.47 |
| tor8 | robin mentioned writing an evince backend that uses mupdf as a way to get into ubuntu | 16:46.53 |
| Robin_Watts | I don't think it's a huge deal to move the xrefs to be a linked list of blocks again. | 16:47.24 |
| henrys | we need time estimates and then send that off to miles, I don't think we have a problem raph has gone dark but I think we'll do better with a schedule anyway. | 16:47.45 |
| tor8 | Robin_Watts: the xref loading code would have to be rejigged, but should be "a small matter of programming" | 16:48.08 |
| Robin_Watts | That way we can artifically 'step back' in time by moving our pointer to blocks, and thus change back to read each old version of the file in turn. | 16:48.23 |
| paulgardiner | Robin_Watts: oh nice | 16:48.37 |
| | I hadn't twigged that | 16:48.48 |
| tor8 | so basically we can say "load object N" and it'll go through the xref sections from newest to oldest to find one | 16:49.00 |
| Robin_Watts | henrys: tor8 said that the original estimate for the bidir stuff was still good. | 16:49.06 |
| tor8 | and I guess we can add an optional argument to skip a number of xref sections to get at an older version | 16:49.27 |
| Robin_Watts | tor8: yeah. And by changing the start of that search, we can look at older versions of the document seamlessly. | 16:49.32 |
| henrys | tor8:would you like a bug for localization or are you going to followup soon? | 16:49.33 |
| tor8 | I hate the translation work. I've been going through the strings in the android app. There are a number of inconsistencies in there I'd like to fix, and I wonder how some of the strings will translate without context. | 16:50.22 |
| | The website will need some redesigning if we want to have multiple language versions of it | 16:50.52 |
| Robin_Watts | henrys: I was trying to work on the image extraction stuff at the end of last week. It has meant that we need to rejig bits of the code so images can be extracted in their still compressed form. That's almost working, but I've got some problems in release builds that I need to sort out. | 16:51.05 |
| henrys | Robin_Watts: so I should take your last schedule and use the first schedule to make deadlines? | 16:51.45 |
| Robin_Watts | I got sidetracked by someone pointing out that we can't do formfilling on armeabi devices, as our v8 build won't work on them (only on armeabi-v7a). | 16:51.46 |
| tor8 | the bidi stuff should be easy to get something working once I can focus on it. It'll be something fairly simple, not the full bidi algorithm, but should be extendable if a need crops up | 16:51.58 |
| Robin_Watts | henrys: I think so. | 16:52.15 |
| | Turns out that V8 is about to drop all support for pre v7a devices anyway. | 16:52.38 |
| | And try as I might, I cannot get a working build out for older devices anyway, so I think we just say that if you want form filling you need a newer device. | 16:53.13 |
| tor8 | Robin_Watts: hence my suggestion to maybe look at other javascript engines sooner rather than later. still, it may be even more trouble to compile and use spidermonkey. there's still 40+mb of source in mozilla/src/js | 16:53.50 |
| henrys | tor8:I think it would be easier if you just let the consultant f*ck it up then you'll have to fix it. -- in the interest of moving things along. | 16:54.16 |
| Robin_Watts | My phone came with eclair on, and has since been updated to froyo and gingerbread, and it's v7a. | 16:54.49 |
| paulgardiner | tor8: someone on the talker earlier mentioned success in building Spidermonkey for Android. | 16:54.55 |
| tor8 | henrys: okay. they do say on the website that they have "incremental translations" so if you upload the same file again, they'll only do the diffs | 16:54.57 |
| Robin_Watts | So I think non v7a devices are VERY old. | 16:55.00 |
| | tor8: I fear the time taken to build spidermonkey will be even larger than trying to make v8 work. | 16:55.36 |
| paulgardiner | I'd be quite keen to try Spidermonkey as an alternative engine, but I can see it taking at least a couple of weeks | 16:55.46 |
| Robin_Watts | And the population of armeabi phones are vanishingly small now I think. | 16:56.05 |
| tor8 | I'm okay with telling old phones to go away if they want JS support. | 16:56.40 |
| | at least we aren't a paid app :) | 16:56.53 |
| Robin_Watts | tor8: No, we tell them "get me a v8 build that works" :) | 16:56.56 |
| henrys | Robin_Watts:I wouldn't worry about it at all. | 16:57.00 |
| Robin_Watts | So I'm back on the image decode stuff now (or will be tomorrow) | 16:57.25 |
| henrys | okay anything else for the meeting? | 16:57.35 |
| Robin_Watts | I just had a conversation with our mupdf customer. | 16:57.40 |
| | They are interested in the work we've done for text extraction. | 16:57.56 |
| | They have some documents that have the first line of the paragraph emitted at the end etc. | 16:58.14 |
| | so they will try to supply those to us as examples for us to improve our code. | 16:58.41 |
| | They are also interested in column extraction etc. | 16:58.50 |
| | so we might get some docs to drive that work soon. | 16:59.01 |
| henrys | Robin_Watts: that's good. | 16:59.16 |
| tor8 | Robin_Watts: sounds good. | 17:01.48 |
| Robin_Watts | paulgardiner: 3 Androidy reviews on robin/master (plus 2 work in progress patches - ignore them) | 17:12.59 |
| | I'm assuming the meeting is over? No one in the entire history of the planet has ever needed a cup of tea more than I do now. | 17:13.52 |
| | henrys: Something was mentioned at the meeting that didn't get a comment... I briefly discussed the idea of writing an evince backend that calls mupdf. | 17:48.26 |
| | That would get us a viewer on lots of popular unixes. | 17:48.48 |
| | s/briefly discussed/briefly discussed with tor8/ | 17:49.08 |
| henrys | Robin_Watts:I don't see any reason why evince would use mupdf instead of poppler, there is a backend for ghostscript too, nobody uses it. | 17:52.53 |
| Robin_Watts | henrys: It would be a choice for people. | 17:53.39 |
| henrys | OTOH if we bring a viewer to linux with forms, reflow etc then there is a reason to use it. | 17:53.55 |
| Robin_Watts | The theory would be that it's simpler to write a backend than to write a complete viewer. | 17:54.08 |
| | evince does forms etc. | 17:54.17 |
| henrys | Robin_Watts:why would anyone switch out the default poppler? | 17:56.31 |
| Robin_Watts | well, our contention is that we render better/faster etc, right ? | 17:57.03 |
| kens | OK i'm heading off for the night now | 17:58.33 |
| henrys | I see this the final death blow to a real viewer to replace gsview. | 17:59.36 |
| Robin_Watts | henrys: Ah, right. I'd forgotten about that. | 18:01.26 |
| | Yeah, we'd need our own viewer for that. | 18:01.34 |
| henrys | Robin_Watts:what about helping tor8 along with the viewer - which could have reflow, distilling etc. but if you think there is promise with evince I'll go along with it. | 18:02.43 |
| Robin_Watts | henrys: I'm not sure that having 2 of us working on a linux viewer would be productive. | 18:03.36 |
| | I'd be more tempted to look at what michael comes up with for windows 8, and then seeing if some of that can be pulled back to win32. | 18:04.00 |
| | I suspect that may not be easy, but... | 18:04.21 |
| henrys | tor8:what is the status of the viewer? | 18:04.37 |
| Robin_Watts | The android viewer for example, depends massively on the android display structure (views, adapters, etc). | 18:05.07 |
| | If Windows 8 has a similar thing, then we'd end up needing to reimplement all that for windows 32 as a runtime layer. | 18:05.41 |
| henrys | yes we have the same issues for all the platforms - what if we have an iOS customer? | 18:08.23 |
| | that wants all the android features. | 18:09.04 |
| Robin_Watts | henrys: Well, iOS has its own 'display/interaction system' that Tor has already battled with. | 18:09.48 |
| | so things pan/zoom etc in a standard iosy way. | 18:10.01 |
| | android/ios/windows 8 being touch based things, have at least some of the logic for this stuff standardised. | 18:10.35 |
| | linux and windows don't. | 18:10.45 |
| | (standardised for their platform I mean, not standardised across platforms) | 18:11.00 |
| | If you want to put a transparent menu bar on a view in android, well, there are commands to do that - you add it into the layout structure and the display system takes care of it. | 18:12.28 |
| | I bet metro has such things too. | 18:12.52 |
| | but with win32 you either do it by steam, or you sell your soul to MFC, AIUI. | 18:13.38 |
| | Or you plump for something like GTK, but Tor tried that and it's a non-starter on windows. | 18:15.37 |
| henrys | I thought we could focus on windows 8 and not worry about older windows, - a metro app but I haven't studied it carefully. | 18:18.04 |
| Robin_Watts | henrys: Depends if you buy into "The Desktop is Dead" thing. | 18:18.31 |
| | I can't see the windows desktop dying within the next couple of windows releases myself (famous last words) | 18:19.45 |
| | I suspect it's the netbook/desktop divide again (and latterly the tablet/PC divide). | 18:20.17 |
| sebras | Robin_Watts: why was GTK a non-starter on win? | 18:20.34 |
| | Robin_Watts: was it the DLLs..? | 18:20.41 |
| Robin_Watts | netbooks/tablets/Metro is great for consuming information produced elsewhere. | 18:20.41 |
| | But if want to create information, you need a proper desktop/keyboard/mouse/ etc | 18:21.08 |
| | sebras: Yeah. | 18:21.10 |
| | We could try looking at a static build of Gtk for windows, but Tor8 said that had been tried and didn't work. | 18:21.44 |
| sebras | Robin_Watts: is that a big issue? many programs come with installers... and if mupdf on windows is supposed to look like the others... ;) | 18:21.46 |
| Robin_Watts | sebras: Tor8 seemed to think it was a showstopper. | 18:22.05 |
| ray_laptop | hi, all. Sorry for missing the meeting. Today was my day for car trouble | 18:22.11 |
| sebras | he's probably right. | 18:22.15 |
| Robin_Watts | sebras: But we should think about it. Installing properly would make it a lot more palatable. | 18:22.48 |
| ray_laptop | Robin_Watts: do you have time for a question (a second question, that is -- this being the first) ? | 18:23.08 |
| Robin_Watts | ray_laptop: Just time for one, sorry. :) | 18:23.25 |
| sebras | Robin_Watts: yes, but I fear that none of your would appreciate dealing with .msi, nsis or whatever is the installshield of the day... | 18:23.40 |
| Robin_Watts | sebras: We have a chrisl for that :) | 18:23.51 |
| | ray_laptop: Go for it... | 18:24.24 |
| ray_laptop | Line 486 of base/gximono.c is "blamed" on you. This is a valgrind issue because it advances psrc to an uninitialized area (past stop and past endp) | 18:25.40 |
| | eventually it encounters a non-zero byte and stops | 18:25.57 |
| | but the line 490 has a comment: "Note, endp NOT stop" that I don't understand since before the loop we do "stop = endp" and the loop (AFAICT) doesn't change stop or endp | 18:27.34 |
| | Also, this coding method of advancing psrc in a loop without checking for endp as well as some check based on comparisons of *psrc seems to be prevalent in this code | 18:29.34 |
| Robin_Watts | ray_laptop: I vaguely remember this. | 18:30.28 |
| henrys | ray_laptop:I thought there were sentinels in that code such that checking wasn't necessary but I'll be damned if I can find them on rereading. Is it possible they were removed. | 18:30.32 |
| | ? | 18:30.40 |
| Robin_Watts | I think maybe I expanded out the cases here or something? | 18:30.53 |
| ray_laptop | henrys: same here | 18:31.09 |
| | with bug 693735 it advances well past 'endp' and fixing just that line seems OK. | 18:32.06 |
| | but if I try and fix all of the spots that do similar things, I get thousands of diffs | 18:32.42 |
| tor8 | you can't build gtk statically | 18:33.48 |
| Robin_Watts | tor8: why not? The build system just doesn't cope ? | 18:34.35 |
| ray_laptop | BTW, I changed the subject of that bug since it used to say something about "in alloc_acquire_chunk" which was wrong. That was simply the function that allocated the block that we eventually drifted into. The real valgrind culprint was image_render_mono | 18:34.40 |
| tor8 | Robin_Watts: it's officially Not Supported ^TM | 18:36.30 |
| Robin_Watts | ray_laptop: Ah! | 18:36.39 |
| | I remember this bug. | 18:36.44 |
| tor8 | the build system can't do it, and I guess there's lots of assumptions in the code that rely on dynamic linking | 18:36.58 |
| Robin_Watts | I don't remember the stop/endp thing though. | 18:37.21 |
| | ray_laptop: But I'm not responsible for the hunting forwards too far, as far as I can see. | 18:38.22 |
| | Blaming that gets me back to Henrys in 1998. | 18:40.30 |
| | And I think that's the initial import :( | 18:40.48 |
| | ray_laptop: So your fix is to check in the loop for psrc < endp ? | 18:41.23 |
| | tor8: OK, so how would you feel about a viewer that required an installer? Went into a directory with all the required DLLs etc. | 19:01.08 |
| | It's not as nice as the current 'all inclusive' binaries, but as gsview it's going to need a ghostscript installation too, right? | 19:01.44 |
| | Also, I think I just fixed my image problems - you were saying you'd like a helper function or something earlier? Can you expand on that? | 19:02.14 |
| ray_laptop | Robin_Watts: sorry, I was on the phone. Yes, my change was to this: for (; psrc < stop && !*psrc; ++psrc) { | 19:05.27 |
| | Robin_Watts: but I still don't understand the "endp NOT stop!" comment on line 490 | 19:06.29 |
| Robin_Watts | Sounds good to me. | 19:06.34 |
| | Me either :( | 19:06.37 |
| ray_laptop | AND I don't understand why fixing all of the other loops that appear to ignore the 'endp' and 'stop' when advancing psrc causes so many diffs | 19:07.40 |
| | unless I messed up my fix. Anyone willing to review my diff on that ? | 19:08.04 |
| tor8 | Robin_Watts: installer's fine. means we could possibly stop including droidsansfallback as a compiled in blob, if we can reliably find the file path. | 19:08.48 |
| ray_laptop | in the meantime, I will go ahead and commit this fix for the bug case, and look at the other fixes more carefully | 19:09.13 |
| Robin_Watts | ray_laptop: Good or bad diffs? | 19:09.35 |
| | Sure, I'll look at your diffs. | 19:09.48 |
| | your patch I mean. | 19:09.56 |
| | tor8: OK, so we're back on track with a Gtk based viewer then. How is that going? | 19:10.18 |
| henrys | ray_laptop:are you in the masked case? | 19:13.29 |
| sebras | Robin_Watts: re: endp vs stop... the comparison used to be psrc >= stop in gs 5.50... | 19:14.09 |
| ray_laptop | henrys: the comment above the block says "Slow case, masked, not orthogonal." | 19:14.39 |
| | Robin_Watts: I'm running the bmpcmp to see what I get from the first few (1000) diffs | 19:20.20 |
| | at least it'll help me hone in on a simple, obvious file to see what I might have done wrong | 19:21.17 |
| | no takers on reviewing the diffs (git format-patch) | 19:22.38 |
| | :-( | 19:22.45 |
| henrys | ray_laptop:I thought we just pushed to our user repo? | 19:23.45 |
| | but send it to tech | 19:24.03 |
| Robin_Watts | ray_laptop: I said I'd look. | 19:24.58 |
| henrys | I'm not convinced you need the check, if we knew there was at least one transition we'd hit the break inside the for loop, right? | 19:25.02 |
| | i.e. stop is set because you are non orthogonal. | 19:25.48 |
| Robin_Watts | ray_laptop: Easiest way is for you to commit locally (as you've done), then push to your user repo and we can look there. | 19:25.59 |
| henrys | sebras notes the 5.50 difference, it's probably worth tracking down the history. | 19:36.39 |
| Robin_Watts | henrys: I changed it from stop to endp. | 19:39.16 |
| | I was probably mistaken in thinking it did anything. | 19:39.38 |
| ray_laptop | Robin_Watts: Did you add the comment as well ? (seems like you must have had a reason) | 19:40.08 |
| Robin_Watts | I did add the comment, and I can't immediately see why. | 19:40.35 |
| | As you say, endp == stop, so... | 19:40.43 |
| ray_laptop | OK. np | 19:40.45 |
| | poor old x6 -- It's stuck "Installing Ghostscript" and everyone else finished | 19:41.50 |
| henrys | sorry I'll have Macpro and henryx6 back in a minute - having some work done in the house. | 19:47.26 |
| | with the pci sad much less than a minute actually ;-) | 19:48.59 |
| | s/sad/ssd | 19:49.04 |
| Robin_Watts | ray_laptop: Based on those bmpcmps, it looks like at least some of your fixes are incorrect. test 16 for example. | 20:00.40 |
| | I have to go to dinner now, but if you put the patch somewhere, I will look tomorrow. | 20:00.58 |
| ray_laptop | Robin_Watts: agreed. I think tests/Ghent_V3.0/052_Font_report.pdf page 2 is a good place to start. The "xF" is particularly egregious. | 20:27.29 |
| | AND I can reproduce it on Windoze ! | 20:28.26 |
| wordToDaBird | Robin_Watts, yes, I am volunteering if it isn't needed within the next 2 weeks. | 23:00.54 |
| | Got a big project I am working on for work, but in about 2 weeks I should be free and shouldn't take me more than a day or two maybe a week at most to do it. | 23:01.19 |
| Robin_Watts | wordToDaBird: Brilliant! | 23:02.28 |
| | henrys: ping | 23:14.01 |
| | I believe bug 693639 has been finished for a while. Tor had mentioned (to me) the possibility of offering zeniko a bounty for it, and he's just mentioned that on the bug. | 23:15.26 |
| | Forward 1 day (to 2013/04/10)>>> | |
IRC Logs