| | <<<Back 1 day (to 2012/08/27) | 2012/08/28 |
| aq | Hi | 07:49.12 |
| ghostbot | niihau | 07:49.12 |
| aq | im new here | 07:49.41 |
| | want to speak to a mupdf dev | 07:49.50 |
| kens | aq The MuPDF developers aren't here yet. | 07:50.04 |
| | Another hour or so should see at least one of them online | 07:50.20 |
| aq | thanks ken. | 07:50.32 |
| kens | Feel free to ask anyway, this channel is looged and the developers will read the logs when they start | 07:50.53 |
| | Its also barely possible that one of us know s the answer, if its sufficiently simple :-) | 07:51.13 |
| saper | he wanted to donate, maybe | 07:59.23 |
| aq | I have a query, currently typing in pastebin. | 08:00.06 |
| | I have question related to the MuPDF API . I have posted it here http://pastebin.com/xzWhWqcA | 08:06.09 |
| kens | aq the text position is certainly available, because the -tt switch will produce the text as an output from MuPDF. I'd suggest examining the sample applications. In this case mudraw and teh -t, -tt and -ttt switches | 08:11.41 |
| aq | thanks kens. I'll have a look. | 08:12.39 |
| tor8 | aq: you'll want to look through the fitz.h header, more specifically at the fz_text_device which fills out structs with the text and their positioning | 08:19.16 |
| kens | Didn't see you there tor8 I'd have left the questio nto you if I'd known you were online | 08:26.42 |
| tor8 | kens: don't worry, your answer was good :) | 08:27.05 |
| | and I was up unusually early | 08:27.12 |
| Robin_Watts | .- | 14:11.10 |
| | oops. | 14:11.17 |
| sebras | Robin_Watts: thats "A" in morse. | 14:18.25 |
| henrys | 5 of the forms meeting for those needing coffee or tea. | 14:55.40 |
| | paulgardiner:it looks to me like we should do the one way submission of the alpha release but I don't feel strongly about it. | 15:01.19 |
| Robin_Watts | I suspect that submission could be a beta feature quite easily? | 15:01.55 |
| paulgardiner | henrys: doesn't look hard to do,especially if we initially go for the quick and dirty string ops approach. | 15:02.33 |
| henrys | time estimate? | 15:03.05 |
| paulgardiner | I guess the most awkward bit would be in the apps, because presumably it would be the app actually sending the data | 15:03.23 |
| Robin_Watts | We currently have no network code anywhere. | 15:03.41 |
| | No http fetching code to leverage, not even any cross platform TCP libs. | 15:04.30 |
| paulgardiner | I don't think it's hard to do http under windows. I think I've used those apis before. | 15:04.34 |
| Robin_Watts | so unless we're planning the extent of our submission code to be generating the block of data to send, it's unknown territory. | 15:05.01 |
| paulgardiner | Would mean it had to be separately in each app, but that may be appropriate | 15:05.02 |
| | Robin_Watts: yes that's what I was thinking | 15:05.23 |
| | for the lib that is | 15:05.29 |
| Robin_Watts | I'd guess that whoever comes to use this stuff is going to have their own existing http fetcher/sender stuff. | 15:05.43 |
| | (i.e. if someone is sticking in a browser) | 15:05.56 |
| paulgardiner | Yes. Or easy access to one. | 15:06.08 |
| Robin_Watts | so probably the block of data thing is as far as we need go for now. | 15:06.10 |
| paulgardiner | Possibly, although it might not be hard to update the Windows app to send it. | 15:06.39 |
| | and that would allow it to be tested too. | 15:06.49 |
| henrys | It just strikes me as a google checkoff feature if they reevaluate our code. | 15:06.54 |
| paulgardiner | On the other hand, as I look through the DOM work, I'm finding bugs that I ought to sort out. | 15:07.34 |
| | Difficult to judge what is most important. | 15:07.43 |
| henrys | so can you put it at the end of the queue and we'll decide later | 15:08.30 |
| paulgardiner | BTW, I found on a forum earlier today someone saying v8 is included in android since 2.2 and it's fairly easy to access. | 15:08.44 |
| | henrys: ok. Will do | 15:09.08 |
| Robin_Watts | I thought v8 was in android. I didn't know it was easy to access. | 15:09.20 |
| paulgardiner | Looks like libwebcore.so exports the v8 API | 15:09.46 |
| henrys | what did they use before v8? | 15:09.55 |
| paulgardiner | Could be the forum poster is wrong, but sounds hopeful. | 15:10.19 |
| tor8 | Robin_Watts: could we fork it out to an external process, like "curl"? | 15:10.33 |
| paulgardiner | henrys: I read that, but I've forgotten. I can probably find it | 15:10.46 |
| henrys | no big deal | 15:10.55 |
| Robin_Watts | tor8: possibly. but my point is for us to do a cross platform portable thing, it's a whole new block of work. | 15:11.18 |
| paulgardiner | What should we do about print and mailDoc? | 15:12.08 |
| Robin_Watts | Those sound like things that should get punted to the doc. | 15:13.18 |
| | s/doc/app/ | 15:13.41 |
| vtorri | about the thread feature of mupdf, is it to speed up the rendering of a page ? or something else ? | 15:13.45 |
| paulgardiner | Yes. Should we do anything in the app at this stage or just put up message saying the lib supports it, but not the app? | 15:14.37 |
| Robin_Watts | print presumably requires the app to put up a dialogue with printer selection etc,and then call us to render the page(s) required to a bitmap for it to actually send to the printer. | 15:14.39 |
| henrys | tor8:how is our app? | 15:14.48 |
| paulgardiner | Robin_Watts: yeah, not sure quite how it would work. | 15:15.06 |
| Robin_Watts | mailDoc, similarly would require the app to ask for an email address/subject etc, and then get us to save the doc and mail it. | 15:15.28 |
| tor8 | Robin_Watts: yeah. I don't want to put networking into mupdf core. return a block of memory for the app to send would be preferable. | 15:15.44 |
| Robin_Watts | I was wondering if we could have some generic 'pass requests to the app' interface. | 15:15.45 |
| paulgardiner | Robin_Watts: or possibly you save the doc, and hope the platform can pring pdfs? Or is that cheating? | 15:15.52 |
| Robin_Watts | and print and mailDoc would the first users of that interface ? | 15:16.14 |
| paulgardiner | Robin_Watts: I think we need some sort of event system for sending stuff to the app. | 15:16.27 |
| Robin_Watts | paulgardiner: I think the idea is that we want our rendering engine to be involved in the print request. | 15:16.34 |
| paulgardiner | Robin_Watts: yes, the alternative would be cheating. | 15:17.11 |
| Robin_Watts | Are either 'print' or 'mailDoc' of the form 'start this action and don't carry on with any more form interaction/javascript until it's completed' ? | 15:17.55 |
| paulgardiner | henrys: I don't think I replied to the timescale question. A simple submit implementation really isn't difficult, probably including doing the send in the Windows app. Less than a week, I'd imagine. | 15:18.13 |
| Robin_Watts | vtorri: bad time to ask, in a meeting right now. | 15:18.14 |
| vtorri | ok | 15:18.21 |
| | i see that you are going to add some print and netword support | 15:18.40 |
| Robin_Watts | vtorri: but it's intended to make life easier with stuff like thumbnailing in the background. | 15:18.48 |
| vtorri | network* | 15:18.48 |
| tor8 | Robin_Watts: paulgardiner: sumatrapdf have a gdi+ device in their mupdf for printing on windows | 15:18.49 |
| Robin_Watts | vtorri: No, we're not! | 15:19.00 |
| vtorri | Robin_Watts, haa, i just want to add that feature to my app (thumbnails) | 15:19.21 |
| henrys | render it and send it to a printer doesn't sound good. That's why we have all these devices in ghostscript and we don't want to go down that path with mupdf. | 15:19.23 |
| Robin_Watts | vtorri: Right. And it can help with fuzzy redraw and posh UIs etc. | 15:19.44 |
| paulgardiner | Robin_Watts: hmmm, not sure. I think the app shouldn't do anything more until either the print or mailDoc is complete, otherwise further changes might be made | 15:20.25 |
| vtorri | Robin_Watts, may I, one day, give the link of the mupdf part of my lib here for a review ? | 15:20.26 |
| Robin_Watts | vtorri: sure. we can't promise how much time etc we can devote to it, but it's always nice to see what people have done with mupdf. | 15:21.01 |
| henrys | tor8:so what does gtk+ provide printing wise, anything? | 15:21.05 |
| Robin_Watts | And it may influence future direction. | 15:21.09 |
| vtorri | thanks | 15:21.16 |
| Robin_Watts | henrys: I was thinking that if there is a generic 'printer' interface on any given platform, it will quite possibly be in the form: "feed in bitmap to send to printer" | 15:21.48 |
| | And mupdf produces bitmaps. | 15:22.07 |
| | but the exact size/shape/resolution/margins etc of the bitmaps is something that you'd expect the app to handle rather than the mupdf lib. | 15:22.41 |
| henrys | as long as we are using the interface on the platform, yes it is fine. | 15:22.48 |
| paulgardiner | Makes sense. Would be a huge bitmap though for printing resolution | 15:22.54 |
| Robin_Watts | We could feed it in strips. | 15:23.05 |
| paulgardiner | true | 15:23.18 |
| | Indeed the printing api may ask for strips | 15:23.34 |
| Robin_Watts | The mupdf lib does strips etc already. printing really seems like something to leave to the app. | 15:23.43 |
| vtorri | henrys, http://developer.gnome.org/gtk3/stable/Printing.html <-- that, i guess | 15:23.48 |
| Robin_Watts | Unless we want to go the gs route and build in specific smarts for each printer class in mupdf (no, no, please god no). | 15:24.13 |
| tor8 | henrys: probably cairo... | 15:24.13 |
| vtorri | tor8, i don't think that cairo is such high level | 15:26.42 |
| henrys | well we want to go with the platform but I don't think a bitmap is going to be good enough, we should use the platform API - on windows I guess that would be (I hate to say it) XPS | 15:27.32 |
| Robin_Watts | henrys: Urm... Surely not. | 15:27.52 |
| henrys | tor8:how is the viewer coming along? | 15:27.58 |
| paulgardiner | What would be the problem with the bitmap... other than having to render at very high res? | 15:28.14 |
| Robin_Watts | We'd render to a bitmap and feed that to the print stream, and that might form an XPS file that contained our bitmap, but we'd still be basically creating just a bitmap. | 15:28.38 |
| tor8 | henrys: no progress of late, release and zeniko got in the way | 15:28.40 |
| henrys | Robin_Watts:we have experience with this in ghostscript - mswinpr sends bitmaps to gdi and it totally sucks. Everyone complains about it. | 15:28.42 |
| | that's why we are doing an XPS printer for ghostscript. | 15:29.16 |
| Robin_Watts | henrys: Well, then we'd need to write an xpswrite device for mupdf. | 15:29.19 |
| | which is not impossible. | 15:29.34 |
| paulgardiner | I'm interested to know what the complaints about the bitmaps are. In what way do they suck? | 15:29.44 |
| Robin_Watts | I have the beginnings of a pdfwrite for mupdf (enough to do tiger.pdf) | 15:29.56 |
| henrys | dog slow from the huge bitmaps | 15:30.07 |
| tor8 | henrys, Robin_Watts: speaking of xps, all the reviews of mupdf on ios mention using it for viewing xps files | 15:30.07 |
| paulgardiner | henrys: oh ok. Makes sense | 15:30.23 |
| Robin_Watts | So for printing to a PCL printer, we'd go from PDF-> XPS. Then the system would go from XPS -> bitmap -> PCL. Great. | 15:31.12 |
| tor8 | henrys: http://code.google.com/p/sumatrapdf/source/browse/trunk/mupdf/fitz/dev_gdiplus.cpp is higher level than sending bitmaps (except for fallback when transparency is involved, I think) | 15:31.28 |
| Robin_Watts | tor8: Right, but gdi is so, like, last millenium, dude. | 15:31.55 |
| tor8 | I'd prefer xpswrite to that though, xpswrite is useful on its own | 15:32.06 |
| Robin_Watts | I suspect XPSwrite is much easier than PDF write for mupdf. | 15:32.34 |
| chrisl | henrys: I'm not convinced by the mswinpr2 problems being because it uses bitmaps - that's really how cups drives most consumer printers, and there aren't many complaints that. | 15:32.39 |
| Robin_Watts | linux users are just happy that their printers work :) | 15:33.08 |
| paulgardiner | :-) | 15:33.24 |
| chrisl | Robin_Watts: recent crap I've had to deal with from Ubuntu users suggests that's not longer true :-( | 15:33.46 |
| henrys | chrisl:there used to be a lot of complaints, I don't think there are a lot of complaint now because nobody uses it. | 15:34.01 |
| Robin_Watts | But printing from mupdf is a whole new can of worms anyway. The important thing is that the print javascript event is thrown out to the app, and the app has to deal with it (it might call us back of course...) | 15:34.42 |
| chrisl | henrys: yes, but I don't think the root of the problem is it using bitmaps - it may be the Windows print queue's way of dealing with large bitmaps, but that's a different matter. | 15:35.02 |
| Robin_Watts | The interesting point (to me) is whether all javascript/forms interaction etc is frozen until the print completes or not. | 15:35.07 |
| paulgardiner | We don't necessarily have to pick a single mechanism. Presumably it will be the app that decides how to ask the lib for the data to drive the printer | 15:35.36 |
| Robin_Watts | I think paulgardiner said earlier that the form should freeze until the print completes, but I'm not sure that would be what people expect. | 15:36.25 |
| paulgardiner | Robin_Watts: I don't think it's frozen no. I think it amouints to making a request | 15:36.37 |
| | But I was thinking that the app should not allow any changes or quitting until the process is compelte | 15:37.17 |
| Robin_Watts | Right. So that amounts to no more javascript being executed. | 15:37.39 |
| paulgardiner | Not quite | 15:37.59 |
| Robin_Watts | field1.text ="Before printing"; print(); field2.text = "After printing"; | 15:38.10 |
| paulgardiner | The action may have further calls | 15:38.13 |
| Robin_Watts | Are you saying that the field2.text should not happen until after the print dialogue is closed ? If so, I'd characterise that as a freeze. | 15:38.48 |
| paulgardiner | I think that would print "After printing". I could maybe test Reader | 15:38.57 |
| henrys | so it seems to me if we don't anything about printing it's in Tor's viewer app for the most part. | 15:39.01 |
| | s/don't/do | 15:39.10 |
| Robin_Watts | I think the lib needs to tell the app 'I've had a print request', but everything after that is app based. | 15:39.33 |
| paulgardiner | Robin_Watts: I don't think it can freeze because the app cannot put up a print dialog without the call into the lib returning | 15:39.44 |
| tor8 | henrys: yeah. I'd say freeze the app until the print job is submitted. | 15:39.48 |
| | but how to do the freeze with multithreading and callbacks is ... hairy | 15:40.03 |
| paulgardiner | I imagine the print call will put a request in a queue that the app can read | 15:40.04 |
| Robin_Watts | paulgardiner: I agree. That was my concern. | 15:40.14 |
| tor8 | we could make a "copy" of the document and queue that up | 15:40.22 |
| Robin_Watts | I'd hope that 'print' equates to 'open a print dialogue' for this file. | 15:40.55 |
| paulgardiner | Robin_Watts: but another option is to legislate that apps should not allow further action until the print is complete | 15:40.57 |
| | Not allowing further action is different to freezing. I mean ignore user input until the action is complete. | 15:41.47 |
| Robin_Watts | paulgardiner: So apps shouldn't pass any clicks in the window down to the lib ? | 15:42.07 |
| paulgardiner | Robin_Watts: that's what I was thinking. | 15:42.20 |
| Robin_Watts | That seems reasonable (and natural, I guess) | 15:42.26 |
| paulgardiner | And that might just happen naturally because the app is busy feeding the printer api | 15:42.38 |
| henrys | this isn't something alpha is it? Fill in the form, print, assume that is fast with spooling and all ... | 15:43.07 |
| paulgardiner | No. Too much work for the alpha. And sort of independent of forms and javascript in that printing is something you might want for non-forms. | 15:44.04 |
| Robin_Watts | printing itself is definitely not something for the alpha - it's a whole new can of worms. | 15:44.43 |
| | having a mechanism for the app to tell the lib "a print request has been given" does feel like something alpha to me. | 15:45.05 |
| | s/app to tell the lib/lib to tell the app/ | 15:45.15 |
| paulgardiner | Yeah good | 15:45.16 |
| tor8 | Robin_Watts: and part of the request would be a frozen copy of the document I take it? | 15:45.39 |
| Robin_Watts | tor8: No. Just the current document. | 15:46.01 |
| henrys | it isn't a can of worms for paulgardiner, and tor8 only has to do a gtk call as an example, right? | 15:46.04 |
| tor8 | we can just pop up a dialog and say "Printing not supported. Gives us loads of monies and we'll think about it for a bit." | 15:46.38 |
| Robin_Watts | As long as the app stops feeding in mouse clicks/keypresses while the print dialogue is opened we are golden. | 15:46.53 |
| | And I'd hope that mailDoc is a very similar lib->app message. | 15:47.25 |
| paulgardiner | I think you get that by making a model dialog. | 15:47.32 |
| henrys | I probably missed something but I thought printing would be just as important as saving and should be in the alpha. At least something primitive. | 15:48.32 |
| Robin_Watts | henrys: tor8's app is not going to be in the alpha. | 15:48.53 |
| | so even if it was completely trivial to do printing from a gtk app, it still wouldn't help us. | 15:49.25 |
| henrys | I assumed we'd have a crippled viewer to point at by alpha time. | 15:50.09 |
| Robin_Watts | henrys: And if gtk DID offer a trivial 'printing' option, it would presumably be doing it by requesting a bitmap, which you've said you hate. | 15:50.23 |
| paulgardiner | henrys: we can say that the MuPDF lib supports printing, but not our example app... although that assumes bitmap printing. | 15:50.32 |
| | Working at the lib level, a lot of these things are implemented just by making a request to the app. Submit is the same. | 15:51.29 |
| henrys | paulgardiner:okay we'll go with that for now. | 15:51.47 |
| paulgardiner | But for submit, I'm fairly sure the app-side changes aren't hard | 15:51.48 |
| Robin_Watts | AIUI, the linux printing system is based on bitmaps. Windows is based on either GDI (old windows) or XPS (new windows), which I bet a lot of people drive as bitmaps. | 15:52.32 |
| | Android; I don't think there is a standard yet; I've seen at least 1 third party solution that I think is basically a set of bitmap -> printer converters wrapped up under a single interface. | 15:53.20 |
| chrisl | Robin_Watts: On Linux, it's PDF based (now, used to be PS), then for a lot of "desktop" printers, the PDF gets converted to a bitmap, and the bitmap "wrapped" in the printer's native PDL - for PS printers, it gets sent as PS. | 15:54.22 |
| Robin_Watts | paulgardiner: Submit feels like another message from lib to app, with a new lib call for the app to the lib to ask for the data to submit. | 15:54.50 |
| paulgardiner | Yeah | 15:55.01 |
| Robin_Watts | (which nicely parallels mailDoc) | 15:55.05 |
| paulgardiner | exactly | 15:55.12 |
| Robin_Watts | So the interface for the messages from lib to app feels like the key thing. | 15:55.35 |
| paulgardiner | But I think we may be able to update the app to the send fairly easily for Submit | 15:55.36 |
| Robin_Watts | Anyway, we're running out of time, so I'll shut up. | 15:55.46 |
| paulgardiner | Robin_Watts: and we should swap to doing links through that same interface, because in the presence of javascript, the mapping from clicking to opening a url is programable. | 15:56.40 |
| henrys | the more I think about this the more I feel we need the viewer to go with the alpha - we aren't releasing something tangible. | 15:56.41 |
| mvrhel | good morning | 15:56.55 |
| Robin_Watts | mvrhel: Welcome back. | 15:57.04 |
| mvrhel | thanks | 15:57.10 |
| henrys | paulgardiner:I'm afraid we have to go on to the next meeting. | 15:57.23 |
| Robin_Watts | mvrhel: I have lcms stuff to talk about with you after the meeting if that's convenient. | 15:57.23 |
| paulgardiner | henrys: I keep thinking I'd quite like to try knocking up something for Windows using the MFC | 15:57.28 |
| mvrhel | Robin_Watts: thats fine | 15:57.43 |
| paulgardiner | ... but it's the sort of thing that might expand into a lot of work, | 15:57.55 |
| henrys | I'm willing to be beaten back on this but I would think any potential customer would like to download some app that supports forms and play with it. | 15:58.13 |
| Robin_Watts | henrys: Our existing apps support forms, right? | 15:58.33 |
| paulgardiner | henrys: they can save and then use the existing platform support for printing pdfs. We could even cheat in our app, and make it use that mechanism temporarily | 15:59.09 |
| Robin_Watts | We could make those respond to "print" and "mailDoc" and "submit" by popping up a dialogue saying "This functionality isn't in this version of the app". | 15:59.31 |
| paulgardiner | but make the point that the lib supports it. | 15:59.52 |
| Robin_Watts | Right. | 16:00.02 |
| henrys | what app with customers be pointed at alpha time? | 16:00.41 |
| Robin_Watts | "The library has requested a print dialogue. While the library supports printing, this app does not." | 16:00.44 |
| | The existing windows/linux apps. | 16:00.56 |
| henrys | s/with/will | 16:00.59 |
| | so this will work with the X11 viewer on linux for example? | 16:02.10 |
| Robin_Watts | I think the text entry code is rudimentary on X11 compared to the windows one. | 16:02.40 |
| henrys | anyway next meeting can we continue later? | 16:03.02 |
| Robin_Watts | (text is entered at the command line rather than in a pop up currently) | 16:03.06 |
| paulgardiner | There's already a number of features that work only in the Windows app and not in the X11 one, but the X11 one could be updated. May be best if I don't do that, because I don't know much about X11 | 16:03.15 |
| | henrys: later on Tues is difficult for me usually, but any time tomorrow. | 16:03.50 |
| tor8 | the x11 app is difficult to update for text entry, because of no toolkit | 16:03.55 |
| henrys | paulgardiner:yeah anytime during the week we all happened to be about | 16:04.20 |
| | mvrhel:welcome back | 16:04.38 |
| mvrhel | thanks henrys | 16:04.46 |
| henrys | your alive and all so I guess it was a success | 16:04.56 |
| tor8 | paulgardiner: is MFC still supported? or is all the new stuff C# and .NET only? | 16:05.03 |
| mvrhel | yes. we only had one flat tire between the 4 of us and no injuries which is rather amazing consider the ride | 16:05.23 |
| | 145 miles and 17500 feet | 16:05.39 |
| henrys | wow amazing! | 16:05.59 |
| mvrhel | the climbs were insanely difficult | 16:06.01 |
| | and the rides down were insanely fast | 16:06.16 |
| | It hurts to sit right now but other than that I feel pretty good | 16:07.13 |
| tor8 | Robin_Watts: patch on tor/master; raed's latest mail reminded me of something that was missing | 16:08.00 |
| henrys | so I guess one topic for today's meeting is I think we should not accept patches unless it is through the bounty program until we can straighten things out. | 16:08.33 |
| | and verify folks accept that the code will be GPL and Artifex commercial before taking it. | 16:09.19 |
| | okay with everyone? | 16:09.52 |
| Robin_Watts | tor8: looks good to me. | 16:09.59 |
| kens | Fine by me | 16:10.00 |
| Robin_Watts | henrys: For every submitter? Even sebras ? | 16:10.13 |
| | I suspect sebras is a special case ? | 16:10.44 |
| henrys | sebras can be an exception for now. | 16:10.45 |
| Robin_Watts | ok. | 16:10.49 |
| paulgardiner | tor8: Oh . I don't know. Maybe MFC is old hat now. | 16:11.14 |
| henrys | anyway the story is I carefully read our agreement and realize it only applies to past submissions. | 16:11.33 |
| tor8 | paulgardiner: I wonder what sumatra uses. | 16:11.36 |
| henrys | alexcher:you have a bug to talk about. | 16:11.47 |
| Robin_Watts | So, even if someone states on the bug that they are happy to assign copyright to Artifex, we can't accept it ? | 16:11.49 |
| alexcher | 2 bugs. | 16:12.19 |
| henrys | Robin_Watts:I would say if it is was a bountiable bug we'd be okay I don't think anyone is going to fight that (submission and payment) | 16:12.52 |
| alexcher | I have new results for the bug 693301, customer 393. The cause of the problem is now clear but our response to it isn't | 16:12.57 |
| henrys | Robin_Watts:hopefully this is temporary until we fix our agreement. | 16:13.20 |
| Robin_Watts | henrys: sure. | 16:13.27 |
| | alexcher: What seems unclear? As I read that bug, you have a fix. Is there some downside to that fix? | 16:13.57 |
| henrys | marcosw:you said I have a hardware problem any ideas? | 16:14.36 |
| marcosw_ | alexcher: I was just entering a comment for 693301. | 16:14.55 |
| henrys | getting coffee and texting ray | 16:15.01 |
| alexcher | Robin_Watts: It's not a fix. This won't work for a normal file with the format 13. | 16:15.07 |
| Robin_Watts | Or is the fix in luratechs code in a place where they would be unhappy to accept a patch passed back up? | 16:15.10 |
| | henrys: ray is going to his customer today to be there at 10am, I thought ? | 16:15.33 |
| marcosw_ | as I understand it luratech supported format 13 the output would be incorrect, since the jpeg2000 stream is really cmyk but annotated as ycck. Is this correct? | 16:15.48 |
| alexcher | marcosw_: yes | 16:16.20 |
| Robin_Watts | alexcher: Right. So do you have any ideas about how to fix it properly? | 16:16.25 |
| henrys | Robin_Watts:oh that's right | 16:16.31 |
| alexcher | Robin_Watts: No, perhaps we can import the color space from PDF but I don't yet know how to do it in Luratech. | 16:18.01 |
| Robin_Watts | Right, so we need an extension to the luratech API to allow us to pass in a 'suggested' colorspace or something ? | 16:18.49 |
| marcosw_ | I can report the lack of format 13 support to Luratech and have them fix it, but that won't help the customer get the output they expect. | 16:19.02 |
| Robin_Watts | or we need a callback from luratech to allow us to postprocess their choice of colorspace? | 16:19.34 |
| chrisl | alexcher: do you have a feel for what quality difference there is between the openjpeg code and the luratech code? | 16:19.41 |
| alexcher | chrisl: This is easy to check. AFAIK the raster differences are small. | 16:20.54 |
| chrisl | So as an interim solution, I could build them binaries with openjpeg, then? | 16:21.21 |
| Robin_Watts | Last time this was discussed, I thought that luratech was smaller/faster/more memory efficient/gave better results ? | 16:21.45 |
| marcosw_ | can we just implement your comment of "Making color space 13 (YCCK) a synonym of color space 12 (CMYK)"? It would fix this file and not make supporting real YCCK images worse (i.e. we will continue to not read them correctly, just in a different way). Clearly this is what Adobe and Google are doing. | 16:21.48 |
| alexcher | chrisl: Or patch Luratech. | 16:21.51 |
| Robin_Watts | alexcher: I thought you said that patching Luratech was an imperfect solution? | 16:22.35 |
| chrisl | Robin_Watts: faster and more memory efficient, we didn't talk about quality between luratech and openjpeg (that comparison was with Jasper, I think) | 16:22.54 |
| Robin_Watts | ok. | 16:23.04 |
| alexcher | chrisl: see marcosw_'s comment. | 16:23.45 |
| henrys | alexcher:why don't we simply submit the jpeg 2000 data to luratech and ask them how the api should be set up to handle the file? | 16:24.53 |
| chrisl | alexcher: so, is the JPX stream in the PDF actually broken? | 16:25.16 |
| alexcher | chrisl: I thik it is. YCCK is not supportrd by JPX. | 16:26.10 |
| | It's an extension. | 16:26.35 |
| chrisl | alexcher: right, but is the image data actually CMYK? | 16:27.10 |
| Robin_Watts | But it's really CMYK data, right? | 16:27.11 |
| kens | Does the PDF have a different colour space for the JPEG2000 image ? | 16:27.15 |
| | IIRC the PDF colour space is to be used if they are different | 16:27.30 |
| alexcher | kens: Yes, it has. | 16:27.47 |
| Robin_Watts | So we need a way to tell luratech to override the colorspace with one of our choice; we do that for normal JPEGs. | 16:27.48 |
| | I reckon henrys suggestion of going back to Luratech and asking how we should be achieving this is the right thing to do. | 16:28.13 |
| henrys | just a reminder that we are almost to the half hour, don't want to hold folks up. | 16:28.14 |
| kens | Yeah so we need to be able to tell Luratech to ignore the colour space in the image and use the PDF colour space | 16:28.28 |
| Robin_Watts | Either they will tell us how, or they can fix the API so we can. | 16:28.29 |
| chrisl | Or could we convert en-route from YCCK to CMYK (or other base space, as required)? | 16:28.33 |
| alexcher | Robin_Watts: Yes, and set up the channel mapping. | 16:28.37 |
| kens | chrisl I think the problem is that the colour spaxce in the image is *actually* CMYK but declares itself as YCCK in the JPX header | 16:29.00 |
| | Otr am I misunderstanding that ? | 16:29.14 |
| Robin_Watts | Does anyone disagree with the idea of kicking this up to luratech? | 16:29.30 |
| chrisl | In which case, the JPX stream is totally broken, and Luratech may not be too interested in dealing with it | 16:29.55 |
| kens | Robin_Watts : it needs to go to Luratech, but I'd still like to know what the PDF file says the colour space is, and the space of the actual data | 16:29.56 |
| | chrisl the PDF spec says the colour spac ein the PDF file is to be used in place of the one in the JPX image if they are different | 16:30.18 |
| | I think I remember that anyway | 16:30.27 |
| alexcher | DeviceCMYK | 16:30.32 |
| Robin_Watts | kens: My understanding is that the PDF file says it's CMYK, the JPX says YCCK and the actual data is CMYK. | 16:30.33 |
| kens | Robin_Watts : in which case its like I said, valid | 16:30.45 |
| | Valid for PDF | 16:30.51 |
| mvrhel | sounds like it should be treated as cmyk then | 16:30.53 |
| chrisl | But from Luratech's point of view, the JPX file is broken | 16:30.55 |
| Robin_Watts | Indeed. | 16:31.00 |
| kens | We need to be able to tell Luratech to *ignore* the space declaration and use DeviceCMYK instead | 16:31.08 |
| | chrisl I agree, but its in the spec that way | 16:31.20 |
| | THis was one of the horrors I dealt with implementing this in Jaws which is why I remember | 16:31.37 |
| Robin_Watts | chrisl: Right, but if they want to provide a decoder that is useful for PDF, then we need a way to override it. And we should at least mention this to them to see what they say. | 16:31.47 |
| | If they tell us to take a hike, then we'll have to patch it ourselves. | 16:32.04 |
| kens | Yes, but I do agree we need to take it up with Luratech | 16:32.22 |
| Robin_Watts | but they may be prepared to extend it. After all the JPEG lib allows this exact thing. | 16:32.29 |
| kens | Probably for the same reason :-) | 16:32.42 |
| Robin_Watts | indeed. | 16:32.47 |
| henrys | I give luratech an A+ for support they usually get right to the matter and suggest useful changes. | 16:32.53 |
| chrisl | Yes, it does need to go to Luratech, no doubt | 16:32.58 |
| kens | Its a real stupid decision by Adobe that one | 16:33.08 |
| Robin_Watts | OK, so who is going to send it to Luratech? Alex? or do we have someone that usually deals with them ? | 16:33.26 |
| henrys | marcosw_:you volunteered to contact them but let me know if you want me to do it. | 16:33.32 |
| kens | need to put oven on, brb | 16:33.48 |
| alexcher | I think Marcos can do it better. | 16:33.57 |
| marcosw_ | henrys: I think you've reported bugs to luratech in the past but I can do this one. | 16:34.49 |
| henrys | marcosw_:fine by me. | 16:34.59 |
| | you had other bugs alexcher? | 16:35.10 |
| marcosw_ | I'll just send them this IRC transcript, so they understand the color space override issue required by PDF :-) | 16:35.27 |
| kens | I can probably dig the relevant part of the spec out, let me look | 16:35.49 |
| alexcher | Enclosing DoImage in save-restore causes SEGV. | 16:35.57 |
| henrys | alexcher:that's easy assign it to ray | 16:36.30 |
| alexcher | The problem is that rc_mask is in the freed segment when restore happens. | 16:36.35 |
| | This is useful to reduce GC in PDF interpreter. | 16:37.14 |
| marcosw_ | kens: that would probably be helpful, thanks. | 16:37.42 |
| kens | just looking, be a minute if I can find it at all | 16:37.57 |
| alexcher | OK, I'll file a bug and assign to Ray. | 16:38.00 |
| kens | Ah git it. | 16:38.06 |
| henrys | alexcher:okay | 16:38.13 |
| kens | marcosw PDF reference 1.7, page 89, bullet point 2: | 16:38.33 |
| | "ColorSpace is optional since JPEG2000 data contain color space specifications. If present, it determines how the image samples are interpreted, and the color space specifications in the JPEG2000 data are ignored" | 16:38.33 |
| marcosw_ | kens: perfect. | 16:39.12 |
| henrys | anything else for the meeting? | 16:39.25 |
| | chrisl? | 16:39.35 |
| chrisl | henrys: nothing I can think of.... | 16:39.50 |
| marcosw_ | henrys: Any point in a support meeting today? We addressed the only bug that I had questions on. | 16:40.14 |
| mvrhel | I have nothing. Just cluster pushed my threshold patch to see where things are with that. Don't know if ray committed his fix | 16:40.25 |
| henrys | mvrhel:okay I assumed you were in recovery mode. | 16:40.45 |
| chrisl | Hmmm, Luratech has a JP2_Decompress_GetColorSpec() API call, I'm not clear on its purpose, though | 16:40.53 |
| Robin_Watts | I have some lcms2 stuff to talk to mvrhel about; it seems that currently lcms2 isn't being initialised properly and hence it's always using vanilla malloc/free rather than our own provided versions - but that can be discussed afterwards. | 16:40.53 |
| mvrhel | ick | 16:41.17 |
| henrys | okay so have a great day/evening everybody | 16:41.29 |
| Robin_Watts | mvrhel: I have a fix I'd like you to bless :) | 16:41.35 |
| kens | OK goodnight all. | 16:41.44 |
| chrisl | Oops, I meant Luratech has "JP2_Decompress_SetColorSpec()" | 16:41.47 |
| Robin_Watts | night kens. | 16:41.48 |
| mvrhel | bye kens | 16:41.51 |
| henrys | marcosw_:I'm good without a bug meeting. | 16:42.02 |
| | all marcosw_ just sent out the bug report if anybody has anything about that report let us know now. We've moved the bug report meeting to today after the tech meeting. | 16:43.04 |
| marcosw_ | oops, someone just reported a zero day exploit in Java that allows download and running of arbitrary (i.e. not Java) code: http://www.theregister.co.uk/2012/08/27/disable_java_to_block_exploit/ | 16:44.21 |
| | apparently it will be patched on october 16, so no reason to worry :-) | 16:44.48 |
| Robin_Watts | mvhrel: Is now a good time ? | 16:46.40 |
| mvrhel | Robin_Watts: sure | 16:47.49 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=2198f5c518e942ce5735dc91bb49b6a8b9469685 | 16:47.52 |
| | That's my fix. | 16:47.59 |
| | Basically, we were never calling gscms_create or gscms_destroy | 16:48.16 |
| | so I made us call them. But we have no way of handling failure there, so I added a bool return value and made us cope with that. | 16:48.50 |
| mvrhel | that is true since we did not need them before | 16:48.51 |
| Robin_Watts | mvrhel: Well, they are the routines that hook the malloc/free/realloc. | 16:49.13 |
| | so we do need to call them. | 16:49.18 |
| mvrhel | previously we had some call back handlers that were used by lcms to use our memory handlers | 16:49.33 |
| | iirc | 16:49.37 |
| Robin_Watts | Right, and those have to be registered with lcms. | 16:49.48 |
| | which is done in gscms_create | 16:49.59 |
| | Oh. but not in lcms1. So this is all my fault :) | 16:50.15 |
| | I had to tweak the callbacks a bit, because they caused crashes (realloc of null etc) | 16:51.00 |
| | And it looked like the idea of contextptr was so that the cms could have an opaque pointer to some data of it's own if it needed it. | 16:51.46 |
| mvrhel | I see. So when you did the switch to lcms2 you didnt even do the memory allocation stuff | 16:51.56 |
| | the contextptr is there for our customers who may need to lug around who knows what through the color conversion process if they are doing their own thing | 16:52.39 |
| Robin_Watts | When I switched to lcms2 I wrote the memory allocations stuff, but somehow was too dim to twig that it wasn't being called :( | 16:52.44 |
| | mvrhel: Right, so in set_link_data the idea was that the contextptr would get copied in? | 16:53.06 |
| | by customers you mean "customers own cms" ? | 16:53.34 |
| mvrhel | Robin_Watts: that would make the most sense. The idea was that someone may have a pile of data that they use to generate the link in what ever CMM they are using. | 16:57.58 |
| | Some of our RIP customers may have an interest in using this | 16:58.20 |
| Robin_Watts | mvrhel: Hmm. My interpretation of the code was that when we called gscms_create it would get to return a void * pointer. | 16:58.36 |
| | And this would be made available in every link. | 16:58.50 |
| | So that they can stash their own cms internal state there if they want. | 16:59.03 |
| | lcms doesn't use this, so we've never noticed that it's always been passed in the links as NULL until now. | 16:59.28 |
| mvrhel | true. lcms does not use this. but there are customer that we have that want to have an opaque pointer available for there own customized work when a link is requested | 17:00.36 |
| Robin_Watts | Yes, I completely agree that it's a good idea. | 17:00.50 |
| | but I worry that my understanding of what the contextptr is not quite the same as yours. | 17:01.08 |
| mvrhel | when and where that ptr is generated should probably be done at the creation time | 17:01.09 |
| | and storing in the manager makes sense | 17:01.25 |
| Robin_Watts | I've got it as being a single void * that is generated at gscms_create. | 17:01.30 |
| | and it is stored in the iccmanager. | 17:01.38 |
| | and it's copied into every link. | 17:01.42 |
| | So it's the same value for every link | 17:01.50 |
| mvrhel | that sounds reasonable to me | 17:01.57 |
| Robin_Watts | Fab. | 17:02.02 |
| | So, if you're happy with that patch, I'll commit it. | 17:02.11 |
| mvrhel | the address of where all the stuff is should not be changing | 17:02.12 |
| Robin_Watts | "all the stuff" being "the cms' internal state" ? | 17:02.30 |
| mvrhel | all the stuff being the address of a pointer that points to what ever it is that the customer needs to create their link | 17:03.09 |
| | I dont know if it is the CMM internal state | 17:03.24 |
| | you could think of it in that way | 17:03.35 |
| Robin_Watts | An opaque pointer returned at gscms_create time. | 17:03.55 |
| mvrhel | yes | 17:03.59 |
| Robin_Watts | I'm happy with that, cool. | 17:04.06 |
| | So if you're happy with the patch, I'll commit it. | 17:04.20 |
| mvrhel | looks fine to me Robin_Watts | 17:04.30 |
| Robin_Watts | Fab. | 17:04.33 |
| mvrhel | thanks for catching this | 17:04.37 |
| | I was not aware the memory alloc got broken | 17:04.51 |
| Robin_Watts | No worries. | 17:04.55 |
| | I think the memory alloc being broken was my fault. | 17:05.04 |
| mvrhel | I am suprised we did not have any problems | 17:05.05 |
| Robin_Watts | I've been talking to Marti about lcms 2.4 | 17:05.22 |
| | He's taken some of our changes (the accelerations to the hex interp code and some of the 16->8 8->16 conversion maths). | 17:05.59 |
| | He's not taken the transform header stuff yet, but plans to in the future. | 17:06.27 |
| | He's added some cunning code for having factories of optimised color transforms, that we can *almost* use, but not quite. | 17:07.03 |
| | I've suggested a small tweak to it that would allow us to use it and he's considering it. | 17:07.22 |
| | Going to lcms 2.4 causes 14430 diffs, but as far as I can see they are mostly tiny changes (probably due to him pushing one of our conversion optimisations further through the code than we had). | 17:09.50 |
| | There are some larger scale differences though that I may come back to you about. | 17:10.10 |
| mvrhel | Robin_Watts: ok sounds good | 17:16.08 |
| | looks like I still have 2 segvs with the halftone stuff | 17:18.40 |
| sebras | marcosw: (for the logs) thanks for updating bugzilla. :) | 17:43.43 |
| mvrhel | henrys, have you ever heard of these guys? http://www.swiftview.com/ | 17:48.59 |
| | I am refinancing my mortgage and the appraisal of the house I can get in PCL and they recommended this view. weird | 17:49.52 |
| henrys | yes they're a competitor. | 17:51.20 |
| mvrhel | ok | 17:51.26 |
| henrys | make sure your forms work in ghostpcl too ;-) | 17:51.45 |
| | quite unusual to see PCL floating about in that context | 17:52.04 |
| mvrhel | at least this segv happens in windows | 18:01.28 |
| | but unfortunately it is happening in a gc_reclaim so this will be fun to track down | 18:02.00 |
| Robin_Watts | mvrhel: ew. I had some of that fun last week. | 18:02.36 |
| mvrhel | what are some good -Z options.... | 18:02.50 |
| Robin_Watts | -Z@ | 18:02.57 |
| | and $ possibly. | 18:03.05 |
| mvrhel | thanks | 18:03.06 |
| Robin_Watts | What file ? | 18:03.16 |
| mvrhel | Bug689189.pdf.plank.72.0 with my patch | 18:03.34 |
| Robin_Watts | Are you rebased onto an up to date master? | 18:03.57 |
| mvrhel | yes | 18:04.03 |
| Robin_Watts | ok, so it can't be the thing I fixed then :( | 18:04.21 |
| mvrhel | with -Z@? it is taking forever.... | 18:06.48 |
| | something is wrong.... | 18:07.29 |
| Robin_Watts | What are MCH3 and MCH4 color spaces? (random question) | 18:12.20 |
| | mvrhel: Does it die with a memento build? | 18:12.36 |
| | Feel free to mail me details and I'll look tomorrow if that would be helpful. | 18:12.55 |
| mvrhel | Robin_Watts: I will check memento in a bit | 18:13.23 |
| | MCH3 and MCH4 sound like just 3 or 4 DeviceN color space but I cant be sure | 18:13.55 |
| Robin_Watts | That would make sense. | 18:14.33 |
| mvrhel | bbiab. | 18:23.32 |
| henrys | just reading an article in the New York Times, how affordable AWS is these days. We should periodically check if switching the cluster to multiple instances at AWS is affordable to us. | 18:42.42 |
| | I didn't look at numbers though | 18:43.02 |
| Robin_Watts | I thought the problem with AWS was that it charged per hour. | 18:46.14 |
| | So that's 2 problems: | 18:46.41 |
| | 1) currently the cluster nodes run all the time polling for work. So we'd need to have instances up and running 24/7 which would often be idle. | 18:47.07 |
| | but assuming we fixed that and found a way to just spark up instances when we needed them... | 18:47.25 |
| | 2) If we run a 10 minute job, we'd then get charged for the next 50 minutes even though the nodes might be doing nothing. | 18:47.51 |
| henrys | it is $183.00 per month for 10 reserved instances 24/7 - I haven't added bandwidth to the calculator, have a ballpark? | 18:51.12 |
| Robin_Watts | not offhand, sorry, got to run.... | 18:52.46 |
| henrys | np | 18:53.10 |
| gsShelly | henrys: sorry, connection got scrambled, I have updated bug 692849 and cluster tested it | 20:25.17 |
| | henrys: apologies for the mix up but I was developing on linux and windows, one was using pcl mode and the other was using rtl, it only made sense after your last comment! | 20:25.42 |
| | Forward 1 day (to 2012/08/29)>>> | |
IRC Logs