fluid-work IRC Logs-2010-07-09

[07:30:09 CDT(-0500)] * EricDalquist1 (~apollo@76.210.64.231) has joined #fluid-work
[07:30:26 CDT(-0500)] * EricDalquist1 (~apollo@76.210.64.231) has left #fluid-work
[07:45:30 CDT(-0500)] * jhung (~Jon@H42.C192.cci.switchworks.net) has joined #fluid-work
[07:47:48 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[07:56:52 CDT(-0500)] * anastasiac (~team@142.150.154.193) has joined #fluid-work
[08:15:28 CDT(-0500)] * yura_ (~yura@142.150.154.163) has joined #fluid-work
[08:29:46 CDT(-0500)] * mackrauss (~Armin@CPE001b114b4426-CM001ac35c768c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:03:31 CDT(-0500)] <Justin_o> jhung: hello... i just took a look at the summaries i had taken of the canon cameras yesterday
[09:04:12 CDT(-0500)] <Justin_o> the have a line that starts off with "UNIX Time" that differs in the summaries
[09:05:28 CDT(-0500)] <jhung> So the key used to identify the camera's time is different.
[09:06:14 CDT(-0500)] <Justin_o> i think so... i think your's was "Date & Time"
[09:06:22 CDT(-0500)] <jhung> Yes.
[09:06:41 CDT(-0500)] <jhung> Excluding the time, is there any difference between the summaries from Canon #1 and #2?
[09:08:33 CDT(-0500)] <jamon> Justin_o, jhung, can i be of any assistance?
[09:09:10 CDT(-0500)] <jhung> jamon. Yes possibly!
[09:09:11 CDT(-0500)] <Justin_o> jhung: they have serial numbers too
[09:09:33 CDT(-0500)] <jhung> Perhaps justin_o can explain in person.
[09:09:52 CDT(-0500)] <jamon> jhung: k, i'll get his attention in a moment
[09:09:57 CDT(-0500)] * clown (~clown@142.150.154.130) has joined #fluid-work
[09:10:01 CDT(-0500)] <jamon> want to check up on testswarm too
[09:11:29 CDT(-0500)] <jhung> thanks jamon!
[09:12:58 CDT(-0500)] <jamon> Justin_o: ^ ping
[09:16:48 CDT(-0500)] * clown (~clown@142.150.154.130) has joined #fluid-work
[09:17:28 CDT(-0500)] * colinclark (~colin@bas2-toronto09-2925337385.dsl.bell.ca) has joined #fluid-work
[09:28:32 CDT(-0500)] <colinclark> anastasiac and yura_: Morning
[09:28:35 CDT(-0500)] <colinclark> How's it going?
[09:28:46 CDT(-0500)] <yura_> hi colinclark
[09:29:03 CDT(-0500)] <yura_> it's going alright, working on the confirmation dialog refactoring / related bug fix
[09:29:19 CDT(-0500)] <yura_> anastasiac is on the call right now
[09:30:02 CDT(-0500)] <colinclark> ok
[09:30:19 CDT(-0500)] <colinclark> I had a quick question about the change to Repeatable yesterday
[09:30:27 CDT(-0500)] <colinclark> I don't know if you or she is best equipped to answer it
[09:32:40 CDT(-0500)] <yura_> colinclark: go ahead, I will try to answer
[09:33:31 CDT(-0500)] <colinclark> Two pretty easy questions
[09:33:45 CDT(-0500)] <colinclark> 1. What happens if there is no thead in the table?
[09:34:10 CDT(-0500)] <colinclark> 2. How come the table head selector isn't using the DOM Binder instead of just using jQuery directly?
[09:34:25 CDT(-0500)] <colinclark> So I'm looking at lines 141-3 of Repeatable.js
[09:35:47 CDT(-0500)] <yura_> oh , ok, this is fresh code , let me take a look
[09:37:16 CDT(-0500)] <yura_> 1. yes good point, appending and prepending smth to empty jquery is incorrect
[09:38:34 CDT(-0500)] <yura_> 2. we dont really have a selector for that, do you have an idea of how the dom binder should take care of that?
[09:48:54 CDT(-0500)] <colinclark> yura_: For #2, I'm wondering if it's like any other selector?
[09:50:04 CDT(-0500)] <yura_> colinclark: sorry , i m not sure i understand
[09:50:31 CDT(-0500)] <colinclark> Wouldn't we just give it a name, like "headerRow" or something and then use the same selector we are using here?
[09:52:11 CDT(-0500)] <colinclark> Perhaps I don't even fully understand why the code is doing what it's doing
[09:53:52 CDT(-0500)] <yura_> well yes, but then we dont always have a table present, we would have to put a class on the header
[09:54:23 CDT(-0500)] <yura_> at the moment, repeatable will generate all the markup not knowing of the header
[09:54:28 CDT(-0500)] <yura_> or label
[09:55:10 CDT(-0500)] <yura_> that manipulation is there only because if there's a table, we need to add empty td's in the header for primary and delete columns
[09:55:43 CDT(-0500)] <colinclark> right, ok
[09:56:08 CDT(-0500)] <colinclark> That makes some sense
[09:56:44 CDT(-0500)] <colinclark> But I think that means that we could certainly put a new entry in the component's selector options for the tableHeader, which we will of course only use if we are indeed working with a table
[09:57:01 CDT(-0500)] <yura_> yes, that's true
[09:57:03 CDT(-0500)] <yura_> good point
[09:57:19 CDT(-0500)] <colinclark> And it does look like there's perhaps a bug in this code, in that it now assumes that if there's a table, there must be a table header
[09:57:22 CDT(-0500)] <colinclark> Which is quite likely
[09:57:29 CDT(-0500)] <yura_> yes
[09:57:32 CDT(-0500)] <colinclark> And it's good to assume that people are nice enough to use semantic tags like thead
[09:57:37 CDT(-0500)] <yura_> (smile)
[09:57:41 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[09:57:41 CDT(-0500)] <colinclark> but when they don't, I wonder what this code will do?
[09:58:07 CDT(-0500)] <yura_> i think it wont fail or do anything, but that's a speculation
[09:58:52 CDT(-0500)] <Justin_o> colinclark: do you remember what exactly the problem with using lsusb to identify the cameras was... i'm just doing some brainstorming with jamon
[09:59:35 CDT(-0500)] <colinclark> yura_: You're probably right. It should return an empty jQuery, and subsequent operations on it should just do nothing
[09:59:46 CDT(-0500)] <colinclark> Justin_o, jamon: I can't remember off the top of my head
[10:00:02 CDT(-0500)] <colinclark> Except to say that it did not provide sufficient information
[10:00:14 CDT(-0500)] <colinclark> Try it with the G10s and see what you see
[10:00:16 CDT(-0500)] <yura_> colinclark: ya, I will mention it to anastasiac once she's off the call then
[10:00:43 CDT(-0500)] <colinclark> I guess the biggest issue is to make sure that we work with USB hubs and the like, where I'm pretty sure we weren't getting sufficiently distinct information about the ports
[10:00:51 CDT(-0500)] <colinclark> Just the incrementing device number
[10:02:10 CDT(-0500)] * anastasiac is back and catching up on the conversation
[10:03:19 CDT(-0500)] <Justin_o> colinclark, jamon: so i'm getting the bus and device being different but the ID is the same for both cameras... i'll try disconnecting and reconnecting now and seeing what happens
[10:05:10 CDT(-0500)] <Justin_o> colinclark, jamon: yes so on disconnect the device number changes... the bus stayed the same, but i would imagine that if we used a hub they would both have the same bus
[10:05:26 CDT(-0500)] <colinclark> Justin_o: I'm pretty sure that was what I was seeing in VMWare
[10:05:53 CDT(-0500)] <colinclark> If you want to try it out, Justin_o, you can use my super-awesome Dell monitor as a hub
[10:06:06 CDT(-0500)] <anastasiac> colinclark, good catch on hardcoding "thead" - I should have used a selector so that people who might have (inappropriately) used a "tr" for their header-type info can override it. I'll fix that
[10:06:21 CDT(-0500)] <colinclark> anastasiac: Another thought
[10:06:23 CDT(-0500)] <anastasiac> colinclard: regarding what happens if there is no header, jQuery takes care of that
[10:06:24 CDT(-0500)] <Justin_o> (smile) okay... i'll go give it a try
[10:06:38 CDT(-0500)] <colinclark> Wouldn't most people use <th> tags in their headers?
[10:06:51 CDT(-0500)] <colinclark> anastasiac: So jQuery "takes care of that," but do we really want to do it?
[10:07:02 CDT(-0500)] <anastasiac> colinclark, you're probably right, and that's what I started with
[10:07:09 CDT(-0500)] <anastasiac> but cspace uses <thead>
[10:07:26 CDT(-0500)] <colinclark> anastasiac: You just hit the nail on the head, it sounds like
[10:07:31 CDT(-0500)] <colinclark> People are going to do different things
[10:07:49 CDT(-0500)] <anastasiac> yes, that's why I should have used a selector - thanks for catching that
[10:07:54 CDT(-0500)] <colinclark> I think, the way I read this code, we can only handle the <thead>/<td> case
[10:08:47 CDT(-0500)] <anastasiac> colinclark, yes, you're right - and that's a bug. I should have used a selector
[10:09:00 CDT(-0500)] <colinclark> I guess that's only part of it
[10:09:07 CDT(-0500)] <colinclark> This is interesting
[10:09:16 CDT(-0500)] <colinclark> So, we know that people might make table headers a few different ways
[10:09:19 CDT(-0500)] <colinclark> 1. They might not have a header
[10:09:24 CDT(-0500)] <Justin_o> colinclark, jamon: same bus if using a hub (sad)
[10:09:26 CDT(-0500)] <colinclark> 2. They might just use <th> tags
[10:09:58 CDT(-0500)] <colinclark> 3. They might use <thead> with <td> tags
[10:10:05 CDT(-0500)] <colinclark> 4. They might use <thead> with <th> tags
[10:10:36 CDT(-0500)] <colinclark> Does that seem about right, anastasiac and yura_?
[10:10:55 CDT(-0500)] <anastasiac> I'd add "they might use a regular <tr><td> combination
[10:11:02 CDT(-0500)] <colinclark> ok, right
[10:11:06 CDT(-0500)] <colinclark> good
[10:11:10 CDT(-0500)] <colinclark> So we have five use cases
[10:11:36 CDT(-0500)] <colinclark> So, let's assume we move the tableHeader selector into the DOM Binder
[10:11:41 CDT(-0500)] <yura_> colinclark: sounds right
[10:11:43 CDT(-0500)] <colinclark> How many of these use cases can we pass with the current implementation?
[10:11:58 CDT(-0500)] <anastasiac> not very many (smile)
[10:12:00 CDT(-0500)] <colinclark> Looks like we, by luck, will pass #1
[10:12:05 CDT(-0500)] <colinclark> #2, we fail
[10:12:08 CDT(-0500)] <colinclark> #3 we pass
[10:12:11 CDT(-0500)] <colinclark> #4 fail
[10:12:16 CDT(-0500)] <colinclark> #5 fail
[10:12:57 CDT(-0500)] <colinclark> So I guess there are a couple of things we might do that are pretty simple
[10:13:18 CDT(-0500)] <colinclark> a) we could check the type of the elements sitting inside the tableHeader and mimic them
[10:13:42 CDT(-0500)] <colinclark> b) we could provide a simple option where users could define the type of element to inject into the head
[10:13:58 CDT(-0500)] <colinclark> Any other solutions I'm missing?
[10:14:16 CDT(-0500)] <anastasiac> colinclark, those were the two I was thinking of
[10:14:28 CDT(-0500)] <anastasiac> yura_, any other ideas?
[10:15:09 CDT(-0500)] <yura_> colinclark: yes sounds good
[10:15:16 CDT(-0500)] <yura_> so a and b are options?
[10:15:23 CDT(-0500)] <colinclark> anastasiac: As an aside, in terms of the "jQuery takes care of it issue," I might follow the pattern in the code above, just from a stylistic perspective. Check if something is there before operating on it
[10:15:38 CDT(-0500)] <colinclark> yura_: Yep, a and be are the options we can think of so far, at least in terms of keeping it simple
[10:15:43 CDT(-0500)] <anastasiac> colinclark, sure
[10:16:01 CDT(-0500)] <colinclark> I'm inclined to go with a)
[10:16:15 CDT(-0500)] <colinclark> But I guess we should check the HTML spec and find out what else might be floating inside a table row besides cells
[10:17:23 CDT(-0500)] <anastasiac> I'll double-check the spec
[10:17:47 CDT(-0500)] <colinclark> It looks safe enough... TD and TH are the only valid children of a TR
[10:18:39 CDT(-0500)] <colinclark> So you should be able to grab a friend inside the TR and use it create your new cells
[10:18:50 CDT(-0500)] <colinclark> There's a risk here, though
[10:18:50 CDT(-0500)] <colinclark> w
[10:19:09 CDT(-0500)] <colinclark> What sort of classes might be attached there that we either need, or don't need?
[10:20:38 CDT(-0500)] <colinclark> These things are the hardest to know when it's someone else's markup
[10:21:06 CDT(-0500)] <colinclark> But for now, it seems at least slightly better to grab a friend in the row, clone it, empty it, and inject it as your new cell
[10:21:11 CDT(-0500)] <colinclark> Or something to that effect
[10:21:15 CDT(-0500)] <colinclark> yura_, anastasiac: Thoughts?
[10:22:10 CDT(-0500)] <yura_> colinclark: sounds right
[10:22:29 CDT(-0500)] <anastasiac> sounds good to me. I'll be checking in with jesse regarding styling of the tables, to see if he's require any style-related classes. if so, we'll have to define the name in the defaults and inject it.
[10:23:46 CDT(-0500)] <colinclark> anastasiac: Yeah, at that point we may well want to ask users to provide us (optionally) with a fragment of markup that represents the things we should inject into the document for them
[10:24:26 CDT(-0500)] <anastasiac> yes, that'd definitely be something useful to support
[10:26:09 CDT(-0500)] <colinclark> anastasiac: As you implement this, you'll probably want to make a few different chunks of test markup that will test those five scenarios we outlined
[10:26:17 CDT(-0500)] <anastasiac> already on it
[10:26:18 CDT(-0500)] <colinclark> Or at least a few of the most sensible ones
[10:26:21 CDT(-0500)] <colinclark> great, thanks!
[10:26:41 CDT(-0500)] <colinclark> So Justin_o, are you still having trouble with exporting?
[10:27:33 CDT(-0500)] <Justin_o> colinclark: yep... i even stopped and started again... i think maybe the click event isn't hooked up to the export button properly though... so i'm going to check that now
[10:28:20 CDT(-0500)] <colinclark> Ah, interesting
[10:28:23 CDT(-0500)] <colinclark> I'm way behind on my ui updates
[10:28:32 CDT(-0500)] <colinclark> So perhaps I'll wait until you've had a look
[10:28:36 CDT(-0500)] <colinclark> My bad
[10:29:06 CDT(-0500)] <Justin_o> colinclark: looks like the selectors have changed... i'll try to mess around with it for a second to see if it works..
[10:29:15 CDT(-0500)] <colinclark> k
[10:29:38 CDT(-0500)] <colinclark> Maybe jhung or jameswy know?
[10:31:42 CDT(-0500)] <jhung> ?
[10:31:54 CDT(-0500)] <jhung> What is the question?
[10:32:08 CDT(-0500)] <jhung> @colinclark, justin_o
[10:32:15 CDT(-0500)] <colinclark> jhung: Standup
[10:32:18 CDT(-0500)] <colinclark> Then we'll ask (smile)
[10:46:46 CDT(-0500)] <jhung> justin_o: do you want me to help with the selector issue on the capture UI now or can it wait until the afternoon?
[10:47:14 CDT(-0500)] <Justin_o> jhung: it can wait till the afternoon... just ping me when you are free
[10:47:54 CDT(-0500)] <jhung> k
[10:58:24 CDT(-0500)] <colinclark> Justin_o, jhung, jameswy: I think I'm seeing about a 15% speed increase when exporting by not converting to TIFF or making a multipage TIFF
[10:59:17 CDT(-0500)] <jhung> colinclark: that's good news.
[10:59:29 CDT(-0500)] <Justin_o> colinclark: do we have to convert to png for ocropus?
[11:00:44 CDT(-0500)] <colinclark> it seems okay with jpegs
[11:00:44 CDT(-0500)] <colinclark> Of course, the giant caveat in all of this is that my export results look pretty odd
[11:00:44 CDT(-0500)] <colinclark> But I expect that might to do with the oddness of the source images
[11:02:05 CDT(-0500)] <jhung> colinclark: yes. I've seen that behaviour too. Things work out better when using proper binarized images.
[11:02:27 CDT(-0500)] <jhung> however, it raises a question: Is it even possible to export unprocessed images from Decapod into a PDF?
[11:04:36 CDT(-0500)] <colinclark> jhung: Unprocessed in terms of having not been binarized?
[11:04:59 CDT(-0500)] <jhung> yeah. as in colour images/ photos etc.
[11:05:10 CDT(-0500)] <colinclark> As far as I can tell, that's what we've been doing all along
[11:05:34 CDT(-0500)] <colinclark> So, here's what I understand of what was implemented in 0.3:
[11:05:53 CDT(-0500)] <colinclark> Capture: capture left, capture right -> stitch -> thumbnail
[11:06:08 CDT(-0500)] <colinclark> Where "left" and "right" are the raw images straight off the camera
[11:06:13 CDT(-0500)] <jhung> yep
[11:06:28 CDT(-0500)] <colinclark> and where stitching binarizes the images and slaps them together
[11:06:50 CDT(-0500)] <colinclark> So then, on export, we "mogrify" each left and right image into a TIFF
[11:07:01 CDT(-0500)] <colinclark> Then we create one big multipage TIFF from there
[11:07:16 CDT(-0500)] <colinclark> Meaning, I think, the multipage TIFF contains raw, colour, unprocessed images
[11:07:25 CDT(-0500)] <colinclark> Does that seem about right?
[11:09:57 CDT(-0500)] <jhung> yep. Sounds about right.
[11:12:28 CDT(-0500)] * colinclark (~colin@bas2-toronto09-2925337385.dsl.bell.ca) has joined #fluid-work
[11:12:34 CDT(-0500)] <colinclark> Sorry, network
[11:12:44 CDT(-0500)] <colinclark> So, without the cameras, the results I get from exporting are pretty bad. But they are consistent, regardless of whether we mogrify + multipage TIFF
[11:12:49 CDT(-0500)] <colinclark> So that's good, since it's about 15% faster
[11:13:07 CDT(-0500)] <colinclark> So the poor export results presumably come from the fact that the mock images are wacky
[11:13:09 CDT(-0500)] <colinclark> Upside down, etc.
[11:13:21 CDT(-0500)] <colinclark> I don't know if that was always the case, or if I've somehow regressed
[11:18:41 CDT(-0500)] <colinclark> jamon: Is Fluid's JIRA currently down?
[11:26:04 CDT(-0500)] <colinclark> yura_, anastasiac: I'm going to wind down for the day soon and get back to my writing. Anything else you want to chat about before I go?
[11:26:37 CDT(-0500)] <yura_> colinclark: I think for the most part everything is in a good shape
[11:26:38 CDT(-0500)] <anastasiac> colinclark, I don't think so. Good luck with the writing! Do we get a chance to read a draft? (wink)
[11:26:53 CDT(-0500)] <colinclark> anastasiac: sure, as soon as it's ready
[11:26:54 CDT(-0500)] <colinclark> (smile)
[11:27:00 CDT(-0500)] * anastasiac is curious
[11:27:03 CDT(-0500)] <colinclark> I'm still sort of rambling at this point
[11:39:24 CDT(-0500)] <jhung> colinclark: the wackiness with respect or image rotation etc. is what we're trying to fix with the camera calibration. The other wackiness may need a screen capture. I've seen some garbled output from genpdf when using "bad" images.
[11:51:04 CDT(-0500)] * colinclark (~colin@74.198.28.32) has joined #fluid-work
[11:57:40 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[12:08:17 CDT(-0500)] <Justin_o> jhung: do you have a couple minutes to try out the server
[12:08:23 CDT(-0500)] <colinclark> jhung: I'm gonna hit the road momentarily, but I'm wondering if you can do me a favour this afternoon
[12:08:28 CDT(-0500)] <colinclark> ah, Justin_o beat me to it
[12:08:38 CDT(-0500)] <Justin_o> (smile) i'll let you finish though
[12:08:41 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[12:08:42 CDT(-0500)] <colinclark> Steps to do it:
[12:08:50 CDT(-0500)] <colinclark> 1. Check out a clean copy of the decapod default repo
[12:08:56 CDT(-0500)] <colinclark> 2. cd into decapod-server
[12:09:09 CDT(-0500)] <colinclark> 3. hg pull http://bitbucket.org/colinbdclark/decapod-server
[12:09:09 CDT(-0500)] <colinclark> 4. hg update
[12:09:18 CDT(-0500)] <colinclark> 5. python decapod.py
[12:09:27 CDT(-0500)] <colinclark> We're particularly keen to see if exporting works for you
[12:09:36 CDT(-0500)] <jhung> okay
[12:09:53 CDT(-0500)] * jhung1 (~decapod@H42.C192.cci.switchworks.net) has joined #fluid-work
[12:19:44 CDT(-0500)] <jhung-alt> colinclark: launching now...
[12:20:21 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[12:24:33 CDT(-0500)] <jhung-alt> justin_o: my export works.
[12:25:05 CDT(-0500)] <Justin_o> okay... so it is just me... which i guess is a good thing
[12:25:16 CDT(-0500)] <Justin_o> thanks for checking
[12:25:49 CDT(-0500)] <jhung-alt> that's a bit troubling...
[12:25:59 CDT(-0500)] <jhung-alt> is it genpdf or something else?
[12:28:12 CDT(-0500)] <Justin_o> not sure
[12:28:50 CDT(-0500)] <Justin_o> jhung-alt: this is what i'm getting http://fluid.pastebin.com/2dtm1b6g
[12:30:40 CDT(-0500)] <jhung-alt> justin_o: hmmm I don't have any output that looks like that. Let me check my versions.
[12:31:56 CDT(-0500)] <jhung-alt> I have changeset 34 for genpdf. what do you have?
[12:35:35 CDT(-0500)] <Justin_o> what is the hash code for the changeset
[12:35:36 CDT(-0500)] <Justin_o> ?
[12:36:12 CDT(-0500)] <jhung-alt> 34:e46d1748a910
[12:36:55 CDT(-0500)] <Justin_o> jhung-alt: i have the same
[12:37:57 CDT(-0500)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[12:38:39 CDT(-0500)] <jhung-alt> weird. I can't terminate the server with ctrl+C
[12:39:10 CDT(-0500)] <Justin_o> jhung-alt: that is a know issue...
[12:39:28 CDT(-0500)] <Justin_o> colin's not sure what happened but i think he's looking into it
[12:39:34 CDT(-0500)] <Justin_o> you can use ctrl-z
[12:39:42 CDT(-0500)] <Justin_o> but you will have to kill the process manually
[12:39:42 CDT(-0500)] <jhung-alt> thanks
[12:42:03 CDT(-0500)] * greggy (~greg@142.150.154.79) has joined #fluid-work
[12:51:22 CDT(-0500)] <jhung-alt> justin_o when installing genpdf, did you get any errors?
[13:08:58 CDT(-0500)] <jamon> jira is back, the virtual machine ran out of disk space
[13:15:05 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has joined #fluid-work
[13:15:25 CDT(-0500)] <Justin_o> jhung-alt: i don't think so
[13:15:49 CDT(-0500)] <Justin_o> i didn't re-run the installation on genpdf this time...
[13:16:41 CDT(-0500)] <jhung-alt> justin_o: you should. It may be because ocro2pdf.py did not copy over to /usr/lib/python2.6/
[13:17:13 CDT(-0500)] <jhung-alt> correction, I mean /usr/local/lib/python2.6/dist-packages/
[13:18:04 CDT(-0500)] <Justin_o> jhung-alt: okay... i'll give that a trye
[13:18:05 CDT(-0500)] <Justin_o> try
[13:24:51 CDT(-0500)] * colinclark (~colin@bas2-toronto09-1176394646.dsl.bell.ca) has joined #fluid-work
[13:34:04 CDT(-0500)] <jameswy> colinclark, Justin_o, jhung: I'm going to work on the stopgap entry page (re: http://wiki.fluidproject.org/download/attachments/14287290/Decapod+book+management+wireframes+-+Stopgap+management.png?version=1&amp;modificationDate=1276619232000 )
[13:35:30 CDT(-0500)] <jameswy> colinclark: Is there anything you or I need to do to make sure that the page is served up?
[13:35:51 CDT(-0500)] <colinclark> jameswy: I guess it depends where you want it served up from
[13:35:57 CDT(-0500)] <colinclark> From / ?
[13:36:56 CDT(-0500)] <jameswy> colinclark: I guess that'd work for now. Eventually, we'll need a book management "component" of some sort, like we have with calibration & capture.
[13:37:18 CDT(-0500)] <colinclark> sure, but I guess my question is more
[13:37:24 CDT(-0500)] <colinclark> how do you get to the book management page?
[13:37:37 CDT(-0500)] <colinclark> is it the first thing the user sees when they start with decapod?
[13:38:02 CDT(-0500)] <colinclark> (I do agree with you that we'll want a component for book management when it's more than just a static html)
[13:38:32 CDT(-0500)] <greggy> jamon: looks like www.netlernen.net has been taken down
[13:39:45 CDT(-0500)] <jameswy> colinclark: yes, it's the first thing the user should see when they start. Would it make sense to have, say, an empty /index.html that redirects to the book management? That way, in case we do decide to have a screen before the book management, we can easily insert it in?
[13:42:37 CDT(-0500)] <jameswy> (also, I might have no idea what I'm talking about)
[13:50:57 CDT(-0500)] <colinclark> jameswy: lol
[13:50:59 CDT(-0500)] <colinclark> you do too
[13:51:20 CDT(-0500)] <colinclark> So, it's pretty easy to handle this now. Currently / redirects to the capture pge
[13:51:26 CDT(-0500)] <jamon> i'd like to start a campaign
[13:51:39 CDT(-0500)] <jamon> call it the "save our 301 redirects campaign" (tongue)
[13:52:08 CDT(-0500)] <colinclark> We'll just change it to serve up the book management page instead, jameswy
[13:52:45 CDT(-0500)] <jameswy> colinclark: sounds good to me!
[13:53:19 CDT(-0500)] <colinclark> jameswy: In the meantime, all the client-side stuff is mounted by the web server, so you can test with it
[13:54:00 CDT(-0500)] <colinclark> Mounted at /components
[13:54:15 CDT(-0500)] <Justin_o> jhung-alt, colinclark: it would appear that the error I was getting with export was because i didn't do the install.. now it looks like what colin was seeing
[13:54:32 CDT(-0500)] <colinclark> ok, that's good-ish, Justin_o
[13:54:44 CDT(-0500)] <colinclark> so jhung, I can't remember what the results of the old mock server were like
[13:54:53 CDT(-0500)] <colinclark> But should we expect things like upside down pictures and the like?
[13:55:00 CDT(-0500)] <colinclark> And do you figure these cause the poor export results?
[13:55:33 CDT(-0500)] <jhung-alt> Yes. upside down images. unidentifiable text. and other stuff causes the output to be bad.
[13:56:08 CDT(-0500)] <colinclark> jhung-alt: And so, did the old mock server produce similar output? I guess we don't know because the mock server had export disabled?
[13:57:17 CDT(-0500)] <jhung-alt> I don't recall ever doing export in Mock server.
[13:57:35 CDT(-0500)] <jhung-alt> Having a senior moment with that. (wink)
[13:58:22 CDT(-0500)] <colinclark> lol
[13:58:31 CDT(-0500)] <colinclark> Not a senior's moment, don't worry
[13:58:43 CDT(-0500)] <colinclark> From looking at the old code, you never could do an export with the mock server
[13:59:06 CDT(-0500)] <colinclark> It was specifically disabled. michelled said it was because export was too slow for an online, multi-user demo
[13:59:21 CDT(-0500)] <colinclark> But now that we've sort of scrapped that idea for awhile, and the servers are consolidated, export is back
[13:59:39 CDT(-0500)] <jhung-alt> cool.
[13:59:40 CDT(-0500)] <colinclark> So Justin_o or jhung-alt, have either of you captured a few pages with real cameras and seen some successful output?
[13:59:44 CDT(-0500)] <colinclark> I know you're both busy, so it's cool if not
[14:00:00 CDT(-0500)] <colinclark> I'm just super curious. If so, it means I can push these changes to master and we'll be all synched up again
[14:00:29 CDT(-0500)] <Justin_o> colinclark: sure i can try that again now that things seem a bit better
[14:00:30 CDT(-0500)] <jhung-alt> I have in the past. The output is probably what you see (one image per page, with a blank half, some images rotated wrong).
[14:01:03 CDT(-0500)] <colinclark> So is that a giant bug in genpdf?
[14:01:35 CDT(-0500)] <jhung-alt> No necessarily. We should be testing with binarized, rotated, and cropped images because that's what we will be using by the end.
[14:01:45 CDT(-0500)] <jhung-alt> The behaviour gets better the better the images are.
[14:01:55 CDT(-0500)] <jhung-alt> We should retest using good images.
[14:02:15 CDT(-0500)] <jhung-alt> There are sample images sitting in the design svn repo.
[14:03:53 CDT(-0500)] <colinclark> ah, ok
[14:03:53 CDT(-0500)] <colinclark> great
[14:04:22 CDT(-0500)] <colinclark> jhung-alt: Do you recommend that we actually switch the sample images that the mock server uses to the ones in the design svn repo, for better export results?
[14:04:26 CDT(-0500)] <colinclark> (at some point)
[14:04:50 CDT(-0500)] <jhung-alt> yes. The ones in the mock were lower resolution.
[14:06:29 CDT(-0500)] <colinclark> ok, good to know
[14:07:21 CDT(-0500)] <Justin_o> colinclark: i took some pictures, not of text. It made the pdfs but they look very strange
[14:07:27 CDT(-0500)] <Justin_o> i'll try to find a book
[14:09:53 CDT(-0500)] <Justin_o> well i did some shots of a book, but i guess they weren't good enough because the pdf is still mangled
[14:10:06 CDT(-0500)] <colinclark> jhung-alt: Whenever you get a chance, can you stick a comment on this JIRA with a link to the images you recommend using? http://issues.fluidproject.org/browse/DECA-129
[14:12:55 CDT(-0500)] <jhung-alt> done
[14:13:48 CDT(-0500)] <colinclark> thanks
[14:14:36 CDT(-0500)] <colinclark> who doesn't love ferns?
[14:14:54 CDT(-0500)] <jhung> I have a cat one in there too, but it doesn't have much text. (smile)
[14:17:03 CDT(-0500)] <colinclark> :_
[14:17:08 CDT(-0500)] <colinclark> (smile)
[14:47:11 CDT(-0500)] <Justin_o> jhung: i've updated capture.js with the correct selector for the export button and have pushed the change to the master
[14:58:04 CDT(-0500)] * Justin_o (~Justin@142.150.154.171) has left #fluid-work
[14:58:28 CDT(-0500)] * anastasiac (~team@142.150.154.193) has left #fluid-work
[15:12:59 CDT(-0500)] * bsparks (~bsparks@wsip-72-215-204-133.ph.ph.cox.net) has joined #fluid-work
[18:40:27 CDT(-0500)] * jhung (~Jon@H42.C192.cci.switchworks.net) has joined #fluid-work
[22:53:39 CDT(-0500)] * jhung (~Jon@H42.C192.cci.switchworks.net) has left #fluid-work