| | <<<Back 1 day (to 2012/10/29) | 2012/10/30 |
| malc_ | Robin_Watts: that was a fun debugging session.. and there was no bug in the end.. sigh | 00:49.07 |
| kens | chrisl ping | 09:01.13 |
| chrisl | kens: pong | 09:04.50 |
| kens | I'm afraid I sort of lost track, what's the status with the 32-bit file offsets and stream code ? | 09:06.30 |
| chrisl | I haven't committed it yet - actually, I was thinking of asking you to cast an eye over it for me | 09:07.09 |
| kens | Ah, well any time you like, I couldn't remember if you'd committed it or not. However, I'm no expert on the stream stuff | 09:07.35 |
| chrisl | Just a quick sanity check (it passes the cluster test with only expected differences): http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=4ac7d6e6 | 09:09.08 |
| kens | wow 52 files changed.... | 09:09.21 |
| chrisl | Well, there are quite a few places that use this stuff, and other places that should, but didn't, so.... | 09:10.26 |
| kens | Yes indeed, this will take me a short while, I'll get back to you in a bit :-) | 09:10.45 |
| kens | runs off for more coffee | 09:10.57 |
| chrisl | does the same.... | 09:12.36 |
| kens | chrisl I notice that in s_file_read_process you've switched from a uint to a gs_offset_t, which is a signed 64-bit int, so we are limited to 'only' 2^63 bits. I can'r believe this is going to be a problem in the forseeabel future though... | 09:39.10 |
| | I notice that in fapi_ft.c, FF_open_read_stream, you are (potantially) truncating 'length' to a long | 09:39.10 |
| | Of course the likelihood fo a font exceeding 2Gb is small. | 09:39.45 |
| | By the wya, I'm skipping over the build changes, because if you miossed anything there I certainly won't spot it | 09:40.23 |
| chrisl | IIRC, gs_offset_t is the same as the 64 bit definition of offset_t, but I'll double check that. And yes, I wasn't too worried about a multigigabyte font! | 09:40.44 |
| | s/offset_t/off_t | 09:41.36 |
| kens | I don't follow the change in interp.c though | 09:42.31 |
| | I'd better go read teh horrible macros again | 09:42.46 |
| chrisl | That's just to pass the i_ctx_p into the functions so we can get the CPSI mode in them | 09:43.38 |
| kens | Oh, OK then, that makes sense | 09:43.51 |
| chrisl | zop_add and zop_sub previously only took stack pointers | 09:44.11 |
| kens | Right, obviously I'm reading the files in alphabetical order, not necesarily the 'sensible' order | 09:44.39 |
| | Aha, now I see the changes to zop_add and co | 09:49.00 |
| | WHich make much more sense | 09:49.07 |
| chrisl | Yes, I just check, and the standard "off_t" type is definitely signed, hence I kept gs_offset_t signed, too | 09:50.02 |
| kens | OK | 09:50.08 |
| | Its not likely a problem, I just noticed that we had changed from an unsigned return type to a signed return type, limiting the maximum value. But since the masimum is so large.... | 09:50.47 |
| | Looks like the PostScript | 09:52.18 |
| | scanning ands stuff was by far the biggest part of all this | 09:52.27 |
| | OK done, all looks good to me | 09:53.04 |
| chrisl | Pretty much, yes. If it weren't for the sh*tty QL tests making invalid assumptions, this would have been a 2-3 day project... | 09:53.43 |
| | Right, there are two changes in there which weren't in my last clusterpush, I'm going to do another test, then commit if it comes back as expected | 09:54.45 |
| kens | Sounds good chrisl | 09:54.57 |
| chrisl | I found it most irritating that we don't have a complete set of "gp_" functions - seems crazy to have "half an API" there..... | 09:56.03 |
| | I mean "gp_" file functions, of course | 09:56.21 |
| kens | I seem to remember that annoying me when I was doing the stuff in pdfwrite too | 09:56.30 |
| | Hmm Lucid Dream arent' acusotmer are they ? | 09:57.00 |
| chrisl | I thought they were.... | 09:57.15 |
| kens | Just checking | 09:57.21 |
| | "Permanently Non-supportd" | 09:57.37 |
| | So 'My broken file doesn't work' would get closed if it were me | 09:58.02 |
| Robin_Watts | paulgardiner: So, you have 2 commits awaiting pushing ? | 09:58.08 |
| kens | But I'll leave it to Alex | 09:58.12 |
| Robin_Watts | Are those the same ones that tor8 already looked at? | 09:58.32 |
| paulgardiner | Robin_Watts: yes please | 09:58.52 |
| | Robin_Watts: no these are new | 09:59.00 |
| chrisl | Interesting that putting the stack back how it should be causes the file to fail - I guess it's going to be those crazy split content stream files :-( | 09:59.03 |
| kens | chrisl I imagine so yes, but I think restoring the stack properly is better than leaving it and broken files are, after all, broken... | 10:04.28 |
| chrisl | I would agree - as you say, though, it's down to Alex, and as an "unsupported", there's no major pressure..... | 10:05.25 |
| kens | :-) | 10:05.31 |
| Robin_Watts | paulgardiner: Suppose I load a page, then render it. then load the same page again, and render it (without destroying the first one) | 10:06.36 |
| | Then I do something that causes an annotation on that page to change. | 10:06.53 |
| | Then I call fz_update_page with the second page reference. | 10:07.11 |
| paulgardiner | It's fine provided that you associate each bitmap of a page with a page object. | 10:07.47 |
| Robin_Watts | Would fz_poll_change_annot with the first page ref correctly enumerate the changes? | 10:08.15 |
| paulgardiner | No. They are independent | 10:08.41 |
| Robin_Watts | so changes might get dropped? | 10:09.00 |
| paulgardiner | But why would you keep two page references, other than if you had two views of the same page, with each having a bitmap of its current state? | 10:09.47 |
| | two page objects I mean | 10:10.12 |
| Robin_Watts | I'm thinking that we might keep main page bitmaps up to date in the foreground, and have a background thread running that is running through generating thumbnails for display. | 10:10.20 |
| paulgardiner | Yeah that's ok. If you wish to keep both up to date, then you keep with each its own page object. | 10:11.36 |
| Robin_Watts | now I'm confused, because that's what I asked. | 10:12.05 |
| paulgardiner | I'll read what you asked again. :-) | 10:12.26 |
| | Right. polling on one page object is uneffected by calling update on another. | 10:13.43 |
| | ... which may or may not be what you asked. :-) | 10:14.12 |
| Robin_Watts | OK, so if I have 2 page objects each with their own bitmap, we need to call fz_update_page on both page objects before we can poll successfully on both page objects. | 10:14.34 |
| paulgardiner | Yes | 10:14.44 |
| Robin_Watts | page objects are reference counted things. | 10:14.57 |
| paulgardiner | They are completely independent | 10:15.03 |
| Robin_Watts | so I can't just hold 2 references and poll twice. | 10:15.16 |
| | (i.e. one object with 2 bitmaps) | 10:15.29 |
| | No, I can see why that would be hard. | 10:15.47 |
| paulgardiner | That's right. | 10:15.59 |
| | You can have two bitmaps and one page object if you don't mind updating both bitmaps in the same enumeration loop of course. | 10:17.08 |
| Robin_Watts | yeah. | 10:17.57 |
| tor8 | paulgardiner: Robin_Watts: just so you're aware, the xps interpreter reuses xps_page objects. if you ask for page 5 you'll *always* get the same pointer | 10:19.25 |
| paulgardiner | Eeek! Is xps interactive? | 10:20.16 |
| tor8 | not yet! thankfully. and hopefully never. but it's something to be aware of when designing interfaces, that the page objects you get are not guaranteed to be "unique" to your load call. | 10:21.09 |
| | we may want to cache them behind the scenes, it's something I've considered doing for the pdf interpreter in the past at least | 10:21.29 |
| paulgardiner | I guess this use of the page objects would prohibit caching them for pdf. Is that likely to be a problem? | 10:25.59 |
| tor8 | paulgardiner: I don't know. the design sounds fragile to me, when hearing it from this altitude, but as I said, I haven't thought carefully about the problems. | 10:43.24 |
| chrisl | Robin_Watts: Just a quicky: your last ghostpdl commit has a typo: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=aa7d7ffc#patch4 ---- $(gxdevsop.h) should be $(gxdevsop_h) | 10:54.16 |
| Robin_Watts | chrisl: Thanks, will fix. | 10:58.49 |
| | tor8: just been chatting to paulgardiner on the phone about this, and I'm happier than I was. | 10:59.04 |
| chrisl | Cool, thanks. | 10:59.08 |
| Robin_Watts | The way it works in paulgardiners commit is that when we get a mouse click or a change in text etc, the app calls down to the core with an event. | 11:00.51 |
| | The app then calls update on that page. | 11:01.11 |
| | It's then the apps job to run through all the page objects it's currently holding to poll them to see if they need updating. | 11:01.39 |
| | I think the only problems are 1) if the app can end up holding the same page object twice (as would be the case with an xps file, if the app wasn't smart enough to only hold one page object per page) | 11:04.27 |
| | or 2) if we want to catch updates to pages without having a page object open (say if we wanted to keep a thumbnail for every page up to date, and obviously didn't want to hold a page object open for every page in the document). | 11:05.21 |
| | 1) can be worked around by smartness in the app (page objects are refcounted after all) | 11:05.45 |
| | 2) requires a change in interface (perhaps exposing generation numbers for each page). | 11:06.22 |
| | Neither of them seem like complete showstoppers, so I am tempted to just commit paulgardiner's patch as is, and we can keep this in mind, in case any of us have an "Aha!" moment and can see a better approach. | 11:07.26 |
| | So, I'm happy to pass his first one at least. Say if you'd rather I held off from committing it until you've thought about it. | 11:07.55 |
| tor8 | Robin_Watts: well, let's go with it for now. I'm just worried about non-obvious interdependencies or assumptions and limits on how structs must be used. | 11:11.15 |
| Robin_Watts | yes, I see that. | 11:11.43 |
| Robin_Watts | runs | 11:13.21 |
| ray_laptop | morning, all | 14:03.17 |
| Robin_Watts | morning ray | 14:05.13 |
| ray_laptop | chrisl is missing ? | 14:05.31 |
| Robin_Watts | chrisl may be at lunch. | 14:05.46 |
| | Oh, clocks changed here at the weekend, so this is 2pm here. | 14:06.06 |
| Robin_Watts | heads for lunch too. | 14:06.19 |
| ray_laptop | kens: chrisl and you mentioned frustration at missing gp_ file functions. Feel free to add more. Peter tended to just have a minimal set to simplify porting to limited OSes, but I don't think that's much of a concern | 14:07.32 |
| | of course, others may have different opinions | 14:07.52 |
| | or reasons why to only keep the current set of gp_ functions | 14:08.19 |
| kens | ray it wasn't so much frustration as surprise | 14:12.33 |
| | Instead of a complete replacement, sometimes I used gp_f* and sometiems f* | 14:12.54 |
| | Without any obvious reasons.. If it had been me, I would have written replacements for all | 14:13.14 |
| | Even if a lot fo them just ended up calling the OS functions | 14:13.27 |
| chrisl | <sigh> broadband is down - two paper cups and wet piece of string (mobile data) pressed into service :-( | 14:46.57 |
| | kens: that's the 64 bit file offset stuff committed..... and I'm waiting with trepidation for the fallout! | 14:48.41 |
| kens | chrisl thanks for that, I'll get onto the pdfwrite offsets | 14:48.59 |
| chrisl | ping me if you find problems that I've missed - I will not be surprised! | 14:49.26 |
| kens | Lol | 14:49.33 |
| | Hehe all the topten issues belong to Henry ;-) | 14:54.04 |
| chrisl | And all from the same customer? | 14:54.25 |
| kens | I think so yes | 14:54.32 |
| henrys | I've got 2 top ten customers feeding me problems. | 14:55.03 |
| | just about time for the forms meeting. | 14:56.22 |
| kens | Oh clock change = early meeting | 14:56.36 |
| chrisl | Joys of PCL - and using it in undefined ways..... | 14:56.43 |
| kens | henrys I expect paulgardiner hasn't realised that clock change means meeting is early | 14:57.05 |
| Robin_Watts | I can call him if he's not here. | 14:57.21 |
| paulgardiner | I'm here | 14:57.34 |
| | Should I read back? | 14:57.44 |
| kens | Forms meeting about to start is all | 14:57.55 |
| henrys | you'd think we could shift the times together. | 14:58.01 |
| kens | THat would be too easy :-) | 14:58.09 |
| | We cna't even keep in sync with the rest of Europe | 14:58.30 |
| henrys | any word from alexcher? | 14:58.34 |
| Robin_Watts | henrys: No. But all his machines are still alive, so he's not lost power or connection (yet - famous last words etc) | 14:59.03 |
| kens | He's still logged in so I assume he has at least one working computer | 14:59.06 |
| henrys | I had a question about the updates if we did go to an opengl es renderere would that even be necessary. Some apps I see on the nexus are so fast with page changes I can't imagine we'd have to worry about partial updates. | 15:01.40 |
| | I assume they are using open gl | 15:01.51 |
| Robin_Watts | You're saying just redraw the entire screen every time? | 15:02.41 |
| henrys | right | 15:02.54 |
| Robin_Watts | Depends who's doing the bitmap scaling and transparency blending etc. | 15:02.58 |
| paulgardiner | And I'd quess we can't fill shapes in open gl | 15:04.00 |
| henrys | yeah I would imagine these apps are using the high level api to open gl. | 15:04.23 |
| | not just the bitmaps | 15:04.44 |
| | paulgardiner:did you get the android changes in? | 15:06.29 |
| | I'm reading the last part of your report | 15:07.23 |
| paulgardiner | henrys: not quite. I'm not far off, I think. It's a little complicated with everything having to be done on background threads. | 15:07.36 |
| | henrys: what I've done so far on the android app seems to be coming out cleanly, but there's a bug somewhere that's stopping the update actually working, and I still need to suss out how to update both the high-quality bitmap in sync with the fuzzy one. | 15:09.43 |
| | It's definitely close. | 15:10.08 |
| henrys | great. When you get that in can we make another apk... I think we should all take a look at how it is and try to find problems. | 15:11.48 |
| paulgardiner | Sure. That would be very useful. | 15:12.36 |
| henrys | At least Robin_Watts and I have devices we can look at it with, I don't know about tor8 | 15:13.04 |
| | maybe sebras will play with it too. | 15:13.21 |
| Robin_Watts | tor8 and sebras both have android devices, I believe. | 15:13.33 |
| henrys | I can't think of anything else to discuss for the meeting ... tor8, Robin_Watts have anything? | 15:14.39 |
| Robin_Watts | Nope. | 15:15.01 |
| paulgardiner | Ok good. I'll bash on. | 15:15.20 |
| Robin_Watts | henrys: Did we ever hear anything further from the customer about transitions ? | 15:17.26 |
| alexcher | henrys: I'm fine. It was quiet here. | 15:17.44 |
| Robin_Watts | alexcher: glad to hear you're OK. | 15:17.59 |
| henrys | alexcher:glad to hear that. | 15:18.36 |
| | Robin_Watts:I have not heard anything about transitions, I talk to a person there everyday do you want me to ask. | 15:50.04 |
| | ? | 15:50.15 |
| Robin_Watts | henrys: Well, the key thing is to be sure that they aren't waiting for us to give them something. | 15:50.41 |
| | I think that the ball is in their court, but I'd hate for them to think that it's in ours and have the whole thing fall apart. | 15:51.53 |
| henrys | Why don't you send a follow up to him and copy in support? | 15:51.55 |
| Robin_Watts | Ok. | 15:52.01 |
| henrys | he doesn't seem to know other companies are doing what he wants to do, I am not sure what will happen when that comes to light. | 15:53.42 |
| | so I wouldn't be surprised if the project disappears suddenly | 15:55.26 |
| | I was kind of hoping michael would be here but he's maybe at the microsoft thing? | 16:00.56 |
| Robin_Watts | henrys: He is. | 16:01.04 |
| | He's out all week. | 16:01.09 |
| kens | is very glad to have caught him last Friday thten | 16:01.23 |
| Robin_Watts | Accordingly, I'm taking a run at the ETS stuff (figuring out what the hell it's doing, commenting it etc). | 16:01.37 |
| henrys | ray_laptop, Robin_Watts: well we are already pretty late responding to this customer. What are we going to do here. I prefer to get him a response even if incomplete thoughts? | 16:02.32 |
| Robin_Watts | Well, I sent my "best effort" answers yesterday (not the customer). | 16:03.09 |
| ray_laptop | Scott is getting back to them (Max's boss) with a response/expalanation | 16:03.13 |
| henrys | Scott's going to answer his questions ;-^ | 16:03.49 |
| ray_laptop | Robin_Watts: Right, and I agree with those responses. | 16:03.50 |
| | Scott is pretty sure that Max is occupied on another project (or two), but Scott wants to make sure we don't miss a "sindow" | 16:04.22 |
| | "window" | 16:04.28 |
| henrys | so Robin_Watts should send his answers, say he is filling in for michael who will follow up later with the guidance of the original author. Is that what we want to do now? | 16:05.44 |
| ray_laptop | Scott is going to explain that we are researching the code and have requested a consult with the inventor (Raph) to help us on the more difficult issues and to make sure our responses are correct | 16:05.45 |
| Robin_Watts | ray_laptop: And will Scott pass on my responses as part of that? | 16:06.27 |
| ray_laptop | henrys: let me respond with a couple of suggestions to Robin_Watts' responses (as soon as the meeting is done), then he can send it. | 16:06.46 |
| Robin_Watts | ray_laptop: Or you can edit my responses and send them. | 16:07.05 |
| henrys | okay | 16:07.07 |
| ray_laptop | Robin_Watts: I think cc'ing Scott on your responses would be better, and send them straight to Max (from you) | 16:07.21 |
| Robin_Watts | If they've already been talking to ray then it may be better to keep ray as the point of contact rather than whiplashing them back and forth between ray/me/michael. | 16:07.40 |
| | but I'm happy to send them. | 16:08.10 |
| ray_laptop | Robin_Watts: I think the more people Max hears from, the happier they will be that we can provide support. | 16:08.12 |
| Robin_Watts | ok. | 16:08.19 |
| ray_laptop | Robin_Watts: OK. I'll send you my comments shortly, then | 16:08.30 |
| henrys | I have gotten the okay from everyone except ray_laptop, alexcher and tor8 to "BSD" jbig2dec. Are you guys okay with that? | 16:08.30 |
| | it is to help mozilla. | 16:08.42 |
| ray_laptop | Robin_Watts: and feel free to take them or leave them | 16:08.45 |
| tor8 | henrys: sounds fine to me | 16:08.52 |
| ray_laptop | henrys: fine with me. | 16:09.06 |
| tor8 | henrys: make a press release about it? | 16:09.23 |
| ray_laptop | has Miles also agreed ? | 16:09.23 |
| henrys | thanks all | 16:09.29 |
| | yes Miles is good | 16:09.34 |
| ray_laptop | so BSD is better than LGPL ? (or MIT) ? | 16:10.07 |
| Robin_Watts | They actually want MPL, I think. | 16:10.20 |
| ray_laptop | or MPL | 16:10.24 |
| Robin_Watts | The point is that GPL is not good enough for them. | 16:10.37 |
| ray_laptop | they wanted ALL of mupdf MPL originally, right ? | 16:10.55 |
| henrys | ray_laptop:no it was really just an arbitrary choice on my part. | 16:11.05 |
| ray_laptop | or was that someone else | 16:11.08 |
| alexcher | henrys: I don't mind it either way, nor hold any copyright in jbig2dec code. | 16:11.09 |
| ray_laptop | alexcher: I think we should retain copyright just so we can also "parallel license" it | 16:11.44 |
| Robin_Watts | Mozilla will not link any code that isn't MPL into any of their kit. | 16:11.59 |
| | hence if they were to ever have countenanced using MuPDF it would have needed to be MPL'd. | 16:12.26 |
| henrys | ray_laptop:dual license is fine for me. | 16:12.55 |
| | Robin_Watts:they said bsd would be fine. | 16:13.06 |
| ray_laptop | I am fine with MPL (for just jbig2dec). | 16:13.13 |
| Robin_Watts | henrys: Right. BSD is "freer" than MPL. | 16:13.31 |
| henrys | I wasn't crazy about MPL, just another thing we have to explain. Everyone understands BSD | 16:13.53 |
| Robin_Watts | (in the sane sense of "freer", not in the GNU sense of "it's freer, cos you can't use it as freely".) | 16:14.04 |
| | BSD with an advertising clause, right? | 16:14.36 |
| | not BSD without the advertising clause. | 16:14.52 |
| henrys | anyway I've been trying to reach them and haven't gotten response so all this may be moot. | 16:14.52 |
| ray_laptop | BSD has an "acknkwledgement" requirement, iirc. But I don't really care about which license | 16:15.17 |
| Robin_Watts | AIUI, that "acknowledgement requirement" has been dropped in recent versions of the BSD license. | 16:15.48 |
| | (but I could be wrong) | 16:15.51 |
| henrys | after I get a response from them we can dive into details and possibly agree on a different license mit, mpl if it is better, let's not worry about it for now. | 16:16.49 |
| | alexcher:how is the softmask project. Questions, help? | 16:17.38 |
| | marcos has something at school today | 16:18.01 |
| | kens, chrisl:anything for the meeting? | 16:18.12 |
| kens | Nope | 16:18.19 |
| henrys | let's call it done early if nobody has anything. alexcher any bugs you want to raise? | 16:18.49 |
| chrisl | henrys: only that with the commit of the 64 bit file offset stuff, I'd like to encourage folks to use the "PRI..." printf format macros from now on | 16:18.58 |
| alexcher | henrys: there were a few bug about memory corruption reported recently, but I don't have much progress to report. | 16:20.41 |
| | henrys: I'm working on the soft mask and will ask questiona as they appear. | 16:21.25 |
| henrys | chrisl:okay I must have missed something I'll read commits more carefully. | 16:21.37 |
| Robin_Watts | alexcher: In reference to those... if people are having problems with memory corruption, it's worth using --debug=disable-gc rather than -dNOGC | 16:21.42 |
| | as it's better at disabling GC, and hence can give more sane debugging. | 16:22.06 |
| chrisl | henrys: it's just that using the PRI macros on a suitable system, we can get rid of warnings about "expected long long but parameter was int64" and things like that | 16:22.57 |
| henrys | chrisl:ah I see. | 16:23.32 |
| chrisl | As we're using 64 bit integers in more places now, there is the chance such warnings could start to increase | 16:24.06 |
| henrys | okay | 16:25.26 |
| | meeting adjourned | 16:25.36 |
| | back to my top ten bugs ;-< | 16:26.08 |
| kens | chrisl I've made the changes to pdfwrite for 64-bit offsets locally, and it still passes a cluster test. Now to try a *big* test file (in a 32-bit build). DO we have a way to run a 32-bit cluster test now ? | 16:43.21 |
| chrisl | Yes, you can do "clusterpush.pl 32" | 16:43.47 |
| | But you can't bmpbmp the results | 16:43.58 |
| | Or bmpcmp even..... | 16:44.12 |
| kens | I thought there was something, I'll start that while I run a biug test thanks. I don't need a bmpcmp, if its different I'll know why.... | 16:44.19 |
| ray_laptop | Robin_Watts: OK. comments to your ETS mail sent. Feel free to do it your own way (and ignore my comments). The only sort of important thing is to make sure that you can reproduce the black dot overlay effect when using the 'strengths' array suggested in the README (and nonSSE code) | 16:47.30 |
| | Robin_Watts: it may be that he was using the default 0,0,0,0 strengths or was using SSE code | 16:48.02 |
| | Robin_Watts: and thanks for stepping into this (stinking pile) | 16:48.54 |
| | I _really_ wish Miles had let us consult with Raph about this in the month before he left, rather than having him finish the WTS (which we've abandoned) | 16:49.56 |
| kens | well hindsight is always 20/20 | 16:50.23 |
| ray_laptop | (because of serious flaws in the screen generation) | 16:50.29 |
| | kens: my hindshight is corrected by selective memory to 20/10 :-) | 16:50.57 |
| Robin_Watts | I have not actually run this code yet. | 16:52.38 |
| | He said he'd made a visual studio thing to start playing with, right? | 16:53.04 |
| ray_laptop | Robin_Watts: OK. Well, maybe just tell him we're investigating it. | 16:53.11 |
| Robin_Watts | well, I only got 1 file in the stuff you sent me. | 16:53.16 |
| | i.e. not enough to rebuild it. | 16:53.24 |
| ray_laptop | Robin_Watts: yes, both Max and mvrhel have done VS projects | 16:53.29 |
| Robin_Watts | and our existing test code only reads PGMs | 16:53.35 |
| | hence seeing interference between planes is tricky :) | 16:53.51 |
| ray_laptop | Robin_Watts: I think Max wrote a test framework using libtiff | 16:53.59 |
| Robin_Watts | I have mvrhels project here. | 16:54.03 |
| | Bah humbug. | 16:55.00 |
| ray_laptop | Robin_Watts: you dropped off. Last I see from you is "I have mvrhels project here." (in case you wrote something following | 16:55.36 |
| | doing a TIFF backend makes sense since not many viewers can handle CMYK PAM (P7) | 16:57.30 |
| | RGB PPM in is fine, but taking in TIFF with libtiff is pretty easy. | 16:58.07 |
| Robin_Watts | ray_laptop: Simplicity wins for me, I'm afraid. I'm more likely to do ppm in and out and assume that people can drive convert. | 16:59.15 |
| | TIFF is an inexcusable mess that I plan to stay well away from. | 16:59.43 |
| kens | Hmm only 8 cluster nodes run when I ask for 32-bit | 17:04.09 |
| chrisl | Yeh, not all nodes have the 32 bit libraries installed | 17:04.28 |
| Robin_Watts | kens: Yes. Not all the cluster nodes have... what chrisl said. | 17:04.34 |
| kens | Guessed it was that | 17:04.36 |
| ray_laptop | Robin_Watts: so what format will you use for CMYK ? PAM or raw and use Photoshop or viewcmyk.ps ? | 17:04.38 |
| Robin_Watts | PAM in, PAM out. User can call convert to get whatever he wants. | 17:05.18 |
| | or something. I'm not at that stage yet. I'm just trying to grok the code :( | 17:05.42 |
| ray_laptop | Robin_Watts: or you could enhance lib/viewpbm.ps to read P7 (PAM) files that have TUPLTYPE CMYK | 17:06.35 |
| chrisl | awaits with interest the suggestion that Robin_Watts volunteers to write Postscript ;-) | 17:07.37 |
| ray_laptop | Robin_Watts: OK. If you want to go ahead and reply to Max and just tell him you are investigating the issue of black dots overlaying color dots, fine. Just remember to CC Scott | 17:07.48 |
| Robin_Watts | was concocting a witty 'me, code postscript, yeah right', rejoinder :) | 17:08.06 |
| chrisl | Thought as much! If you do end up going that way, I faffed around in there recently, so you could punt it to me | 17:08.47 |
| ray_laptop | Robin_Watts: also, you may point out that even if ETS generates black dots on top of color dots, the chance of a real world printer actually placing the K on top is unlikely | 17:08.56 |
| | between micro-weaving and back-and-forth passes, etc it may be better off to tell the printer to place the dots on top and count on it missing ;-) | 17:10.08 |
| Robin_Watts | ray_laptop: The paper specifically mentions that. | 17:10.51 |
| ray_laptop | chrisl: I was mostly joking about viewpbm.ps (and mostly serious in suggesting libtiff to write CMYK) | 17:10.59 |
| Robin_Watts | Inkjets are apparently very good at getting repeatable dot positions. Lasers much less so. | 17:11.24 |
| | Is this an inkjet or a laser customer ? | 17:11.37 |
| chrisl | wide format inkjet, IIRC | 17:12.12 |
| ray_laptop | Robin_Watts: I don't know of inkjets that are very good at dot positioning. Even cleaning/wiping the head can cause variations. | 17:12.21 |
| | ETS isn't really suitable for laser. | 17:12.34 |
| Robin_Watts | bottom of page 4 of the paper. | 17:13.09 |
| ray_laptop | most laser engines are (1) fast, so ETS is a performance bottleneck, and (2) can't reproduce single dots very well (thus "minimum dot size" for laser engines) | 17:13.31 |
| Robin_Watts | "Multiplane optimization is only effective when the registration between planes is accurate. While this is generally not the case for offset and laser printing, fortunately it is usually the case on inkjets." | 17:13.57 |
| ray_laptop | Robin_Watts: 'accurate' as in "for a given machine, the relative dot position between colorants is consistent", true. Also, the misplacement of dots is in a smaller area (usually about 1 dot diameter) -- much less than the misalignment between colorants on laser even with 'in line' stations. | 17:17.52 |
| | but on a given colorant, the dot position vs. the 'ideal' position varies from dot to dot and line to line much more than with laser | 17:18.55 |
| ray_laptop | has looked at many printed sample through a microscope, both inkjet and laser/led | 17:20.55 |
| Robin_Watts | but by less than a dot width on average? | 17:21.39 |
| ray_laptop | the other thing that happens with bubblejet is aging changing the size of the dots (less so with a properly maintained piezo head) | 17:22.06 |
| | Robin_Watts: alignment between colorants on an inkjet depends on the head mounting (position and tilt). bubblejet usually replaces heads more frequently, so has looser mounting and poorer alignment between colorants (unless you are lucky that time) | 17:24.23 |
| | piezo heads are usually factory mounted in a 'block' and the factory usually tries to align within +/- 1 dot diameter or less (when the head is brand new) | 17:25.33 |
| kens | TIMe for me to be off goodnight all | 17:25.51 |
| ray_laptop | bye, kens | 17:25.56 |
| | the best heads are fabricated as a block, so that the nozzle plate for all 4 (or more) colorants is photo machined, and the manifold behind the plate just delivers different inks to different | 17:27.24 |
| | parts of the head. | 17:27.30 |
| | I think that's what the Epson 2200 had, which Raph used for much of his work. | 17:27.57 |
| | something like the HP DesignJet that has four individual bubblejet heads is going to be the opposite end of the accuracy spectrum. Also it is large format, so there is more slop in the carriage and paper drive mechanism. Being low end, I don't think they have an 'optical mouse' for position feedback | 17:30.11 |
| Robin_Watts | My canon has 4 bubblejet heads, but when you change the cartridges, you run a recalibration. That's accurate to sub droplet sizes I believe. | 17:31.45 |
| ray_laptop | Robin_Watts: since calibration is varies the fire pulse time for each head, it can only compensate for an average dot position, and to the accuracy of the calibration measurement. Any 'tilt' from the top nozzle to the bottom nozzle can't be handled (I suspect) since changing the fire time from the top to the bottom of the head complicates the electronics | 17:35.16 |
| | Robin_Watts: and the 'response' of the head varies with how many nozzles are firing at once, and the firing history of a nozzle. This affects both the drop size and nozzle velocity, so the position on the paper when doing a ETS field tends to be different than when doing an alignment pattern | 17:37.38 |
| | inkjet printers have better alignment than lasers, but I doubt they try for much better than 'it looks good' so that trapping isn't needed | 17:39.12 |
| | got to get back to real work. Have fun with ETS, Robin_Watts | 17:45.07 |
| Robin_Watts | Fun, yes. | 17:45.22 |
| | Hi mvrhel_laptop. | 18:06.06 |
| mvrhel_laptop | hi Robin_Watts | 18:06.13 |
| | I am here drinking the kool-aid | 18:06.25 |
| | or getting assimilated. | 18:06.34 |
| Robin_Watts | Your task today is to count how many times your instructor says "Metro" and then has to correct himself. | 18:06.34 |
| mvrhel_laptop | yes. just had the keynote from ballmer this morning | 18:06.57 |
| Nr18 | I have created a module that contains a define and wheel i call the define from the node definition it shows the following error: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type createuser at â¦.. example http://pastebin.com/CXyE7Qnh | 18:23.38 |
| | any idea? | 18:24.21 |
| Robin_Watts | Nr18: Sounds like you may be confused as to what this channel is :) | 18:24.37 |
| Nr18 | ah thanks | 18:24.48 |
| | swapping channels :-) | 18:25.06 |
| mvrhel_laptop | Robin_Watts: did you end up checking in the ETS code into a git repository? | 18:26.17 |
| Robin_Watts | mvrhel_laptop: I have one here, yes. | 18:26.41 |
| | I haven't pushed it yet cos I figured you'd be busy... | 18:26.55 |
| mvrhel_laptop | well there are a lot of breaks between sesssions | 18:27.08 |
| | so I will have some time here and there to push forward | 18:27.17 |
| Robin_Watts | Let me push it now. | 18:27.23 |
| mvrhel_laptop | ok thanks | 18:27.29 |
| Robin_Watts | git clone mvrhel@ghostscript.com:/home/robin/sauce/ETS.git ETS.git | 18:31.29 |
| | That should get you a copy. | 18:31.34 |
| mvrhel_laptop | Robin_Watts: thanks | 18:31.49 |
| | got it | 18:33.24 |
| | good. you cleaned up my mess | 18:33.44 |
| | oh but no arg inputs... | 18:36.08 |
| Robin_Watts | oh, you'd made code changes? | 18:36.44 |
| mvrhel_laptop | ok session is starting | 18:36.44 |
| Robin_Watts | I'll look. | 18:36.58 |
| mvrhel_laptop | yes in the stuff that I sent you | 18:36.59 |
| | in test_evenbetter.c | 18:37.07 |
| | ok bbiaw | 18:41.05 |
| Robin_Watts | mvrhel: (For the logs). I'm off out for the evening. I've pushed everything so far - the last commit is a work in progress. | 20:32.53 |
| mvrhel_laptop | Robin_Watts: for the logs. I don't see where you pushed my changes that I sent you. Is that the work in progress that you mentioned? | 21:11.24 |
| ray_laptop | hmm... ICCDevCon is in LA on Nov 12. I wonder if mvrhel is planning on attending. The conference fee is only $400 (for non-members like me), so I think I will attend, if nothing else just to meet some of Miichael's acquantainces that will probably be there. | 21:16.37 |
| | Forward 1 day (to 2012/10/31)>>> | |
IRC Logs