| | <<<Back 1 day (to 2014/04/10) | 2014/04/11 |
| Robin_Watts | morning jogux | 07:57.34 |
| jogux_mac | morning all | 07:57.48 |
| jogux_mac | tucks into a scrambled egg roll | 07:57.59 |
| chrisl | At it's not a bacon roll - that would be cruel...... | 08:01.26 |
| jogux_mac | :) I'm /sort of trying to be healthy, otherwise it would've been a bacon & square sausage roll... | 08:05.20 |
| Robin_Watts | So, with the heartbleed bug... if you use a password on an unpatched server, someone else can come along and (for as long as your password etc sits in memory) can potentially read it out. | 08:10.22 |
| jogux_mac | yep :( | 08:10.44 |
| | and even if you don't use it, there's a fair chance they can grab the hashed version (assuming the server does hash passwords...) | 08:11.14 |
| Robin_Watts | If we assume that attacks using heartbleed weren't widespread before the bug became known, then it's only sites which we have accessed recently that are at risk. | 08:11.55 |
| | Hmm. don't know if I follow that. | 08:12.14 |
| jogux_mac | robin_watts : depends how the passwords are stored; if it's an sqlite db that the server is likely to have cached significant portions of in memory, say... | 08:12.39 |
| Robin_Watts | ok. | 08:12.49 |
| | that changes things. | 08:12.57 |
| jogux_mac | if they're in a proper relational database or similar, that doesn't apply. | 08:13.06 |
| | (as the cache would be in a remote process) | 08:13.31 |
| Robin_Watts | otherwise I'd have said we were better NOT to go around changing passwords etc until we are 100% sure everything is patched (for sites we haven't used since the reveal anyway) | 08:13.36 |
| jogux_mac | or check the site using http://filippo.io/Heartbleed/ first | 08:14.06 |
| kokouuu | hi | 08:14.21 |
| jogux_mac | or https://addons.mozilla.org/en-US/firefox/addon/foxbleed/ or https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic :) | 08:14.54 |
| Guest48423 | Hi | 08:58.55 |
| ghostbot | hello | 08:58.55 |
| Guest48423 | I want to ask about mupdf for android | 08:59.23 |
| | From the doc, I can see that mupdf lib has an option to invert color | 09:00.45 |
| | How to call that option from android? | 09:01.02 |
| kens | Guest48423 : I'd expect Robin_Watts to answer that but it looks like he's away form his keyboard, hang around for a bit | 09:18.05 |
| Guest48423 | Ok thanks | 09:20.49 |
| Robin_Watts | Guest48423: That option is not in the android version. | 10:37.00 |
| | You'd need to fiddle in MuPDFCore.java and jni/mupdf.c to enable it. | 10:37.28 |
| Guest48423 | Ok what should I modify there? | 10:43.29 |
| | I've found fz_invert_pixmap method but still don't know whether this is the correct method | 10:45.43 |
| | and how to call it properly | 10:46.00 |
| Robin_Watts | Guest48423:fz_invert_pixmap is indeed the right thing to call. | 11:02.13 |
| | You'll need to call that after each render. | 11:02.34 |
| Guest48423 | After fz_drop_pixmap? | 11:08.55 |
| Robin_Watts | No, clearly not :) | 11:09.09 |
| | fz_drop_pixmap gets rid of the pixmap. | 11:09.20 |
| | You need to invert it before it's used :) | 11:09.29 |
| Guest48423 | Ok let me try | 11:11.58 |
| | It get inverted but the text become unreadable | 11:13.36 |
| | The text color is not inverted to white | 11:18.58 |
| Robin_Watts | Guest48423: Sorry, I'm not really in a position to help you at the moment. I'm horribly busy on something else that is already taking longer than it should :( | 11:44.01 |
| Guest48423 | Ic, thanks for your help | 11:46.18 |
| henrys | kens:just have him send me email when it's fixed, I take it from there. Once he is billing artifex he will send directly to miles and I'll review that they are okay | 13:15.07 |
| | if he becomes a regular | 13:15.25 |
| kens | OK I'll ask him to send you a mail, I'm happy with the change (minor alteration required to free memory is all) | 13:15.39 |
| | henrys do you want to look at the code ? | 13:17.45 |
| henrys | kens: no I trust ya ;-) | 13:18.04 |
| kens | LOL I don't think I would ...... | 13:18.14 |
| henrys | kens:oh he did sign the agreement prompted for at bugzilla when he submitted the patch right? Do you have that? | 13:32.19 |
| kens | henrys no, because there was no bug report at that time | 13:32.39 |
| | all done via private mail | 13:32.52 |
| henrys | okay I'll follow up | 13:33.09 |
| kens | Great, thanks Henry | 13:33.18 |
| tor8 | kens: where can I find the pdf you mentioned had the save trouble with mupdf? | 13:51.58 |
| | kens: where can I find the pdf you mentioned had the save trouble with mupdf? | 13:57.46 |
| kens | Hmm its one of the QL tests | 13:57.58 |
| | I had a copy locally, do you need the filename ? | 13:58.09 |
| tor8 | kens: could you put it somewhere on casper maybe? | 13:58.10 |
| | I don't think I have a copy of those files here | 13:58.19 |
| kens | I could just mail it to you ? | 13:58.30 |
| tor8 | that'd work too | 13:58.36 |
| kens | :-) Give me a minute to find it again | 13:58.44 |
| tor8 | I think I have something that should prevent the spurious save prompts, but I'd like to see what happens with that file | 13:59.00 |
| kens | OK I found it just a mo | 13:59.15 |
| | On its way now tor | 13:59.55 |
| | Bear in mind that the file *is* broken in some way | 14:00.05 |
| tor8 | kens: thanks. | 14:02.35 |
| kens | No problem | 14:02.43 |
| henrys | tkamppeter: do you want to look at http://bugs.ghostscript.com/show_bug.cgi?id=695152 even though it is not ubuntu | 14:39.01 |
| | ? | 14:39.03 |
| tor8 | henrys: are you sure we actually bought mujs.com...? there's been no word for weeks... | 14:41.25 |
| | kens: that file is repaired because of a broken xref, but the newly saved copy is an incremental save which keeps all the old (broken) xrefs and just tacks on a new trailer just like you said | 14:42.31 |
| henrys | weeks? I'll check with miles again | 14:42.33 |
| kens | tor8 yeah that was more or less what I thought | 14:42.47 |
| tor8 | henrys: at least two weeks since he said we got it | 14:42.48 |
| | paulgardiner: ping. | 14:43.14 |
| paulgardiner | tor8: pong | 14:43.58 |
| tor8 | so, I've looked into a brief hack to not trigger a save on calc.pdf | 14:44.21 |
| henrys | my entire IRC history went away ⦠never seen that before | 14:44.24 |
| tor8 | by checking the field flags for ReadOnly or NoExport | 14:44.43 |
| | but we still have the problem of the repair code triggering a save, but the save is incremental which keeps the broken bits... | 14:45.07 |
| | so every time you do an open/save cycle, it tacks on another trailer | 14:45.47 |
| | henrys: you still on macosx? | 14:46.24 |
| henrys | tor8:for IRC yes, colloquy | 14:46.46 |
| tor8 | I think cmd-k is the shortcut that clears the scrollback in colloquy | 14:46.51 |
| | you might've hit that by accident? | 14:46.56 |
| paulgardiner | tor8: so presumably incremental update isn't appropriate after repair? | 14:47.14 |
| tor8 | paulgardiner: yeah. I'd say so. | 14:47.27 |
| henrys | tor8:okay I hope it doesn't have a short cut for exec sudo rm -rf / geez... | 14:47.47 |
| paulgardiner | The pain is that it is that app that decides what method of save to use, so the app needs a way to ask if incremental is appropriate | 14:48.19 |
| | If we were to add a function to enquire what save mechanism is appropriate, it might make sense to use incremental only for files containing signatures. | 14:49.27 |
| tor8 | paulgardiner: we could check doc->repair_attempted? | 14:49.35 |
| | or what you said | 14:49.51 |
| | but I think incremental saves for form edits makes sense in a way, to keep a version history log | 14:50.20 |
| paulgardiner | tor8: yeah, but then the app writer needs more insider knowledge | 14:50.23 |
| kens | God I'd like to put a muizzle on Hin-Tak sometimes | 14:50.28 |
| tor8 | paulgardiner: we could make it ignore opts.do_incremental if it has repair_attempted, would that make sense? | 14:51.58 |
| | Robin_Watts: ^ | 14:52.00 |
| henrys | kens:he's a bit much - tkamppeter is copied in on the bug so he'll see it. | 14:52.11 |
| Robin_Watts | tor8: reading back. | 14:52.20 |
| tkamppeter | henrys, I will have a look. | 14:53.44 |
| paulgardiner | tor8: I don't think that will work because IIRC the copying of the existing file isn't done by the save function | 14:53.55 |
| Robin_Watts | tor8: You're suggesting that the save routine would ignore opts.do_incremental if doc->repair_attempted ? | 14:53.56 |
| paulgardiner | tor8: I mean there is more to changing save method than altering that flag | 14:54.27 |
| | tor8: On the other hand, if my memory is correct, perhaps that is something we should change, so that it is just a case of setting the correct flag | 14:55.16 |
| tor8 | paulgardiner: hm, yeah. I see you do a wincopyfile, winreplacefile dance | 14:55.22 |
| | I conveniently forgot to read those lines when looking at pdfapp_save :) | 14:55.40 |
| paulgardiner | tor8: yeah, and I think avoiding that looked difficult. | 14:55.52 |
| henrys | tkamppeter: is there a "debug" switch we can tell user to turn on in cups admin to produce a postscript, pcl (PDL file). If not that's a feature request. | 14:56.14 |
| tor8 | yeah. I think we should be able to read the original stream and copy that in the fz_write_document | 14:56.16 |
| | rather than rely on the win_main.c functions | 14:56.55 |
| paulgardiner | tor8: sounds sensible to me. Not sure why I didn't do so. | 14:57.26 |
| tor8 | and opening a file in "ab" mode is begging for trouble if we crash halfway through we'll have destroyed the original | 14:57.44 |
| paulgardiner | I think we always work on a copy | 14:58.04 |
| tor8 | what we should do is write to a temp file in the same directory, copy the original data if incrementally, and then rename to the destination filename | 14:58.15 |
| paulgardiner | ... although I may be misremembering | 14:58.17 |
| tor8 | all within fz_write_document | 14:58.19 |
| | or maybe let the app do the temp file name creation and rename | 14:58.36 |
| | oh wait you do that already. | 14:59.25 |
| | nvm what I just said :) | 14:59.30 |
| tkamppeter | henrys, I have given appropriate instructions on the bug now. | 14:59.54 |
| paulgardiner | Yeah we do that, but not all in fz_write_document AFAIK | 15:00.07 |
| tor8 | paulgardiner: yeah, there's something else that's weird here | 15:00.47 |
| | wingetsavepath into buf, then gen_tmp_file into buf, then winreplacefile buf into the original file name | 15:01.16 |
| paulgardiner | Singular?! Just one thing that's weird?! :-) | 15:01.22 |
| tor8 | paulgardiner: just oddly written, in a way that I'm too stupid to understand the first time through :) | 15:02.11 |
| henrys | tkamppeter: ah the capturing print job data ⦠there it is. thanks | 15:02.16 |
| tor8 | paulgardiner: so I have a patch on tor/master for the readonly/noexport flag handling | 15:03.02 |
| | but I'm thinking there must be a more elegant way to automatically flag the document as dirty when changing a field value/state that would work for checkboxes as well | 15:03.35 |
| henrys | tkamppeter: of course many users won't have access to the cups server. | 15:04.03 |
| paulgardiner | tor8: I'll take a look. Hopefully that will also handle cases where there is JS run on opening a doc | 15:04.06 |
| tor8 | paulgardiner: another thing we could do with the repair stuff is to not trigger the document as dirty on the repair | 15:04.42 |
| | (but still disallow incremental saves if the file has been repaired) | 15:04.54 |
| paulgardiner | tor8: yeah that makes sense. You probably don't want to save just because of repair. | 15:05.59 |
| Robin_Watts | tor8: Well, adobe gives the option to save on document close if it has repaired... | 15:06.31 |
| tor8 | Robin_Watts: too bad we save a broken file, or I wouldn't have minded as much :) | 15:07.15 |
| Robin_Watts | picky picky picky. | 15:07.27 |
| tor8 | I think this is kind of embarrassing to leave in a release, but it's going to be a fair bit of changes needed to fix and we're already running late | 15:08.04 |
| Robin_Watts | tor8: It's no worse than it's ever been, right? | 15:09.02 |
| tor8 | Robin_Watts: did we prompt for saving on edits in 1.3? | 15:09.15 |
| Robin_Watts | I think so. | 15:09.21 |
| | Certainly when we loaded calc.pdf and then exited, it asked to save. | 15:09.36 |
| tor8 | right. then we're no worse off I reckon. | 15:11.58 |
| paulgardiner | tor8: your patch looks okay to me | 15:12.12 |
| tor8 | paulgardiner: Robin_Watts: there's another simple fix to a recent (fairly nasty) bug report on there now too | 15:12.46 |
| marcosw | sebras: okay if I reboot casper in a little while? | 15:13.25 |
| tkamppeter | henrys, but the bug can only get searched for on the server, where CUPS and GS is used, the user needs to talk with his sys admin if needed. | 15:14.15 |
| tor8 | if you're happy with those two I'll include them in the release and make new builds on monday | 15:14.53 |
| marcosw | sebras: actually never mind, I just killed the stuck processes and everything is okay. | 15:15.43 |
| paulgardiner | tor8: which commit? | 15:17.15 |
| tor8 | * eebc338 (HEAD, tor/master, master) Invalidate cached page count value when inserting and deleting pages.* ad0fa16 Add all form field flags. Check flags before marking fields dirty. | 15:17.47 |
| henrys | tkamppeter: I haven't thought it through but it would be nice if a user could send a print job with some command line switch from the client that conveyed don't send this to the printer - send it to say an email address. I think the current troubleshooting is going to "scare away" a lot of folks. | 15:18.06 |
| tor8 | the latest one for http://bugs.ghostscript.com/show_bug.cgi?id=695137 | 15:18.22 |
| paulgardiner | So making it 0 will cause recalculation presumably. Yeah, looks fine | 15:20.14 |
| tor8 | paulgardiner: yeah. I figured that's safer than ++ and -- because it might not have been initially set | 15:20.36 |
| paulgardiner | Makes sense | 15:20.53 |
| tor8 | and the only reason we have it cached is because of a lot of places where it's called in a for loop | 15:21.16 |
| | for (i=0; i < pdf_count_pages(doc); ++i) .... | 15:21.28 |
| | which is a bad practice and should be stomped out before robin catches wind of it ;) | 15:21.46 |
| kens | tor8 Robin_Watts ot would be nice if the dialog said that the reason for offering to save was *because* the file had been repaired, the Adobe'ism is confusing since it offers to 'save changes' on an unchanged file. It would have helped us a lot if Acroabt had said 'this file was dmagaed and has been repaired, save changes?' | 15:24.50 |
| paulgardiner | returns to a life of creating sot splash screens | 15:27.03 |
| sebras | marcosw: oh, ok. :) | 15:31.57 |
| Robin_Watts | tor8: roar! inefficiency! roar! etc. | 15:53.05 |
| kens | goodnight all | 16:22.36 |
| madmoose | tor8: Thanks for fixing my bug for the release :) | 16:47.16 |
| Robin_Watts | So, after 3 days of solid bashing my head against the desk (and bugging jogu a lot) I've managed to get it set up so we can reproduce the customers builds. | 16:51.35 |
| henrys | tor8:miles paid for it but there was confusion or something, I don't know, he's working on it. | 16:55.42 |
| | tor8, Robin_Watts do we have an official release? | 16:56.13 |
| Robin_Watts | henrys: Of MuPDF? | 16:56.32 |
| henrys | Robin_Watts: yes | 16:56.40 |
| Robin_Watts | was told not to wear his mupdf hat. | 16:56.52 |
| | tor8 has been handling the release. He put a fix in earlier today which may be the last one before the release? | 16:57.34 |
| | yeah, I think he said earlier that he's going to do release builds on monday. | 16:58.34 |
| jogux_mac | henrys (etc) : Pete has started to look at Android/good btw. | 17:03.04 |
| henrys | jogux_mac: super | 17:04.04 |
| jogux_mac | I'll need to prod at good/ios next week, as one of the build options mentioned in the spreadsheet seems to no longer exist. I did spot a build flag to enable some kind of good development build though. | 17:06.10 |
| Robin_Watts | henrys: bug 695116 is assigned to me at the moment. It's a customer bug. How does that rate in priority compared to SO work ? | 17:09.47 |
| henrys | Robin_Watts: why is it assigned to you, I get the decoder stuff. I can send that to Luratech and they'll tell us what needs to be done. | 17:13.53 |
| | ? | 17:13.56 |
| Robin_Watts | JPEG, not openjpeg ? | 17:14.05 |
| | luratech ain't involved in this. | 17:14.32 |
| | Images come to me by default in bugzilla I believe. | 17:15.02 |
| henrys | Robin_Watts: oh I read kens comment | 17:15.02 |
| | I'll look at it and send it to the jpeg folks - we talk to them too. | 17:15.48 |
| Robin_Watts | oh, right. Well, if it's jfif data then it ain't openjpeg or luratech, so kens comment appears to be inconsistent. | 17:15.52 |
| henrys | Robin_Watts: I'll take the assignment for now and see if I can move it along. | 17:16.55 |
| Robin_Watts | aw :( | 17:17.07 |
| henrys | Robin_Watts: if you feel passionate about working on this particular problem by all means take a break from the inferno and have at it. | 17:17.40 |
| Robin_Watts | henrys: I'll have a quick look at it until the customer gets back to me. | 17:18.01 |
| | I need a break from python scripts and linux packages etc. | 17:18.27 |
| henrys | Robin_Watts: this whole SOT deal is working out now people won't complain about working on ghostscript ;-) | 17:18.49 |
| Robin_Watts | It's a different kind of hell :) | 17:19.59 |
| | Wait til your Iain M Banks reading gets as far as Matter. | 17:20.54 |
| | oops. Surface Detail. | 17:21.15 |
| henrys | Robin_Watts: sabrina and I decided to read dust first - then we'll move on Iain | 17:21.35 |
| Robin_Watts | oh, well, that doesn't surprise me. | 17:22.01 |
| | mvrhel is reading that at the moment I think. | 17:22.28 |
| | Interesting. The JPEG data is v 1.01, where everybody in the world uses 1.02 | 17:32.11 |
| | OK, so if we substitute in the correct height for the jpeg, we get the correct output. | 17:49.39 |
| | at least enough to satisfy windows jpeg viewer. | 17:50.05 |
| paulgardiner | Ah reading Dust. I need to finish Shift first, which has been rather set back by my falling over while on holiday, landing on my Nook and turing it into a banana-shaped kaleidoscope simulator | 18:07.54 |
| Robin_Watts | paulgardiner: Kindle app for your phone? Or for the ipad. | 18:32.55 |
| | henrys: So the jpeg data in that file is entirely legal. | 18:33.27 |
| | It's just the jpeglib doesn't think it is. | 18:33.35 |
| | It uses a facility that I've never seen used before (namely that it lies about the number of lines in the image up front, then corrects itself with a marker later). | 18:34.09 |
| | It also exposes a bug in the jpeglib whereby the jpeglib claims a maximum height smaller than that which the spec allows for. | 18:34.44 |
| | But we're saved because acrobat doesn't cope either. | 18:35.03 |
| henrys | Robin_Watts: I haven't spoken to them in quite some time but last I did they were responsive | 18:35.18 |
| Robin_Watts | The problem is that it's a fundamental breakage to their API. | 18:35.48 |
| | The JPEG lib tells you up front the size of the image. | 18:36.11 |
| henrys | Robin_Watts: if adobe breaks too why are we looking at it? | 18:36.43 |
| Robin_Watts | but in this file it then corrects itself later to be much smaller. | 18:36.50 |
| | henrys: Cos the customer claims that adobe doesn't break. | 18:36.59 |
| | I've recommended closing it as "won't fix", so hopefully marcos can push back on the customer. | 18:37.44 |
| henrys | Robin_Watts: cool | 18:39.42 |
| Robin_Watts | and the new one, bug695153 looks like it should be mine too. | 18:40.04 |
| henrys | Robin_Watts: eh let kens process it first. | 18:40.54 |
| Robin_Watts | how does NOINTERPOLATE end up on kens plate? | 18:41.33 |
| | I suspect it's going to be that they have an image that's been downsampled massively. | 18:44.08 |
| henrys | Robin_Watts: okay as a matter of policy kens front ends the language stuff, he could simplify the pdf file or do say something useful about it as he's apt to do. But if you want to work on it go ahead. | 18:44.08 |
| Robin_Watts | I think we have some code to apply limits to downsampling... | 18:44.35 |
| henrys | hmm 10 dpi | 18:44.53 |
| Robin_Watts | yeah. | 18:45.49 |
| SpNg | I'm converting an EPS to a transparent png. the EPS has several gradient fills in it. When I use the pngalpha device, I get "banding" in the gradient, but this does not happen when I use png16m. My command line: gs -q -dEPSFitPage -g2000x2000 -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -sOutputFile=my.png my.eps any ideas? | 18:58.07 |
| NoiseEee | hi folks, is it within gs' capability to take a layered PDF and export each layer as an individial image/pdf/etc ? | 19:05.41 |
| SpNg | Robin_Watts: I just submitted a bug report with an EPS with the problem I just mentioned. lmk if I can provide any other details to help. | 19:11.45 |
| Robin_Watts | SpNg: You probably need to talk to mvrhel about that, and he's away this week. | 19:33.40 |
| | So it's a 256x256 image scaled up to be 35379449x35379449 :) | 19:38.36 |
| | henrys: ^ | 19:38.46 |
| henrys | Robin_Watts: who published that crap? | 19:42.53 |
| Robin_Watts | henrys: It's a paradigm I've seen before. It's to do with google maps. | 23:04.45 |
| | AIUI, the map is made up of a series of tiles layered on top of one another. | 23:05.34 |
| | Each tile is 256x256. | 23:05.56 |
| | at the foreground they display the most detailed tile. behind that they have one scaled to be twice the size. behind that another one scaled to be twice *that* size etc. | 23:06.45 |
| | The idea is that on the web they can load the large tiles first and only get the smaller ones as you zoom in. | 23:07.25 |
| | The problem is that when they get published they don't elide the hidden tiles. | 23:07.43 |
| | Not only that, when they render each final tile, they render all the tiles behind it through a clipping rectangle. | 23:08.05 |
| | So each background tile gets scaled multiple times, and a small section from each is plotted. | 23:08.27 |
| | I wrote code a while ago that means that it's smarter about doing the calculations for the scaling. It only actually calculates the interpolated image for the lines where it's used. | 23:09.12 |
| | but even so, this file is SO mad it's still taking a lot of time. | 23:09.26 |
| | Forward 1 day (to 2014/04/12)>>> | |
IRC Logs