| | <<<Back 1 day (to 2013/04/17) | 2013/04/18 |
| mvrhel_laptop | night all | 06:19.34 |
| kens | chrisl are you able to pick up mail from Gmail using imap ? | 06:56.57 |
| chrisl | I am, but I've had a *lot* of failures over the last few days | 06:57.32 |
| kens | I'm getting xonsisten authorisation failures | 06:57.43 |
| | It was fine until yesterday afternoon, since then , I can't pick mail up | 06:58.03 |
| chrisl | Can you login to webmail? | 06:58.08 |
| kens | Yes, tghat works fine, I even changed my password to be sure I was using teh correct one | 06:58.26 |
| chrisl | Hmm, very odd. I must admit, I didn't look at the reason for connection failures I was getting, because I had a few from spamcop, too, so I assumed it was something ISP related | 06:59.29 |
| kens | Very annoying, I really don't like the webmail interface :-( | 06:59.55 |
| chrisl | No, and the latest revisions make it worse, IMHO | 07:00.25 |
| kens | Its uglier than before, yes :-(( | 07:00.39 |
| chrisl | I take it you still use Eudora? | 07:01.08 |
| kens | Yes, like I said it was fine yesterday morning, in the afternoon I got a failuer which happens sometimes, then it wanted a password, and that failed. | 07:01.45 |
| | Not been able to pick up mail since. | 07:01.54 |
| | I tried switching Eudora to imap and got the same error. | 07:02.34 |
| chrisl | Is it specifically a username/password fail? Not encryption or something like that? | 07:03.52 |
| kens | It syas "Username and password not accepted" | 07:04.37 |
| chrisl | Very strange - you might have to brave google tech support | 07:05.22 |
| kens | Oh god.... | 07:05.30 |
| chrisl | IIRC, Gmail uses a slightly weird port for IMAP, but that shouldn't give you that failure | 07:06.23 |
| kens | I'll let you know if I find anything out. | 07:06.49 |
| chrisl | kens: I did once end up having to go through the password reset process to sort out something like this (as in: "I forgot my password", not just changing it in webmail). Might be worth a punt? | 07:09.29 |
| tkamppeter | I am using Thunderbird and had this problem yesterday afternoon CEST, but in the evening it went away. | 07:09.36 |
| kens | Hmm interesting tkamppeter, thanks | 07:09.48 |
| chrisl | tkamppeter: are you using imap? | 07:09.55 |
| tkamppeter | chrisl, yes, I use IMAP, with Thunderbird on Linux. | 07:12.29 |
| chrisl | tkamppeter: do you know if all those TBird bugs with IMAP constantly (re)downloading mails are fixed? They seem to have been a bit of a nightmare for the developers | 07:13.34 |
| kens | OK I got it, finally. Turns out I reset my password with caps lock on by accident.... | 07:14.58 |
| | I'mguessing the original failure was Google's just like Tills problem..... | 07:15.15 |
| tkamppeter | chrisl, these bugs seem to be fixed. TB is currently working well for me. | 07:22.09 |
| kens | tkamppeter : yes it is working for me with Eudora now too, once I corrected my password | 07:22.34 |
| chrisl | tkamppeter: thanks, I may switch back to TBird, then. I switched to Claws Mail when TBird was downloading tens of gigabytes of data filling up my disk, and causing Gmail to cut me off! | 07:33.29 |
| tkamppeter | chrisl, you should check the settings in "Edit" -> "Account Settings" -> "Your GMail IMAP account" -> "Synchronization & Storage". | 07:56.45 |
| | chrisl, there you should especially go under "Advanced ..." and unselect the "All Mail" folder. | 07:57.46 |
| chrisl | tkamppeter: I did that, and it made no difference. When I finally gave up and switch to Claws, my TBird Inbox file alone on my local disk was 28Gb.... | 08:00.35 |
| tkamppeter | chrisl, perhaps you need to turn off "Keep messages for this account on this computer" or at least choose "Synchronize the most recent 30 Days". | 08:53.45 |
| chrisl | tkamppeter: no, it was a genuine TBird bug, known about, accepted and worked on by the TBird devs. It just seemed that fix gave rise to a new instance of something very similar | 08:55.34 |
| kens | Robin_Watts : ping | 08:59.32 |
| Robin_Watts | pong | 09:00.08 |
| kens | I'm just looking at this image downsampling stuff | 09:00.18 |
| | I think Distiller 'may' be using bicbic when the ratio is non-integer, but I'm not certain | 09:00.37 |
| Robin_Watts | I'm going to lag for a bit, but I am listening. | 09:00.43 |
| kens | I've set up an image 300 dpi, 8-bit gray, simple on/off pattern (00 FF 00 FF...) | 09:01.07 |
| | When I set Acrobat to downsample to 145 dpi, using subsampling, I get output which is surprisingly good. But its not simply 0x00 or 0xFF. Some of the samples have been converted to shades of grey. | 09:01.59 |
| | Does it seem likely to you that this is (silently) using bicubic instead of subsampling, or am I confused as usual ? | 09:02.26 |
| | I just ran the same test using bicubic and the result is identical, so that probably answers my question | 09:03.48 |
| Robin_Watts | I think it must be using some sort of averaging thing, yes. | 09:03.53 |
| kens | OK if the ratio is non-integer then subsample/average/bicubic produce identical transformed image data. | 09:04.59 |
| | Thanks Robin_Watts | 09:05.09 |
| tkamppeter | chrisl, see also discussion here: https://bugs.launchpad.net/bugs/927515 | 09:20.49 |
| chrisl | tkamppeter: the bug(s) I was suffering from was: https://bugs.launchpad.net/bugs/1074260 | 09:24.14 |
| Robin_Watts | kens: not sure I did much really :) | 09:32.35 |
| | tor8: ping | 09:32.39 |
| tor8 | Robin_Watts: hey | 09:32.43 |
| kens | Robin_Watts : you confirmed I wasn't losing the plot totally :-) | 09:32.55 |
| Robin_Watts | So, I've had customer 530 on the skype talking about how mesh rendering is slow. | 09:33.07 |
| | and indeed, for the file they give me, it is. | 09:33.14 |
| | Basically it's got lots of very small meshes that are all ultimately used to draw colored rectangles. | 09:33.42 |
| tor8 | lot of overdraw? | 09:33.50 |
| Robin_Watts | No, just way more mesh detail than is required. | 09:34.10 |
| tor8 | oh, tons of separate meshes? | 09:34.11 |
| | or one big mesh with tiny triangles | 09:34.20 |
| Robin_Watts | At the moment, our code divides all patches down by 2^3 in each direction. | 09:34.31 |
| tor8 | sebras may want to listen in now | 09:34.53 |
| Robin_Watts | so in fiddling with the code, I set that so that it just divides each mesh once in each direction. | 09:35.00 |
| | (i.e. set SUBDIV=1) | 09:35.05 |
| | and I notice that I start to get missing pixels. | 09:35.18 |
| sebras | pops in for a read | 09:35.19 |
| tor8 | for the longest time we didn't subdivide at all | 09:35.33 |
| | but that ended up in lots of missing pixels on some files | 09:35.41 |
| Robin_Watts | In fact, I believe we miss things at the subdiv=3 level too, but it's not so visible. | 09:35.51 |
| | I would like to understand why we are missing pixels. | 09:35.58 |
| tor8 | Robin_Watts: we could do tricky subdivision where we subdivide a lot at the edges and not as much on the inside | 09:36.07 |
| Robin_Watts | These are internal pixels missing. | 09:36.27 |
| | brb, sorry. | 09:36.35 |
| tkamppeter | chrisl, seems that you need a newer Thunderbird. Version 16 has still the bug for sure, version 17 is probably the first fixed one but I am not sure. | 09:36.50 |
| tor8 | oh. that's worse. but could be floating point rounding if we arrive at the same vertex by subdividing from different directions. | 09:36.56 |
| Robin_Watts | tor8: I can't see how that can ever happen. | 09:43.35 |
| | oh.... except maybe between 2 patches... | 09:44.01 |
| tor8 | I remember files with lots of missing pixels between patches | 09:44.04 |
| Robin_Watts | That may give me a simple fix. | 09:44.16 |
| tor8 | but I don't recall ever seeing any inside the patch | 09:44.19 |
| | expand the patch by 1 pixel? :) | 09:44.30 |
| | one quick fix would be to snap all coordinates to the integer grid | 09:45.03 |
| Robin_Watts | OK, scratch that. | 09:46.57 |
| | this is a type 7 mesh. | 09:47.05 |
| tor8 | do you see cracks if you turn off subdivision altogether? | 09:47.26 |
| Robin_Watts | So we are given tensor patches. | 09:47.26 |
| | Our code does not support turning off subdivision. | 09:47.41 |
| | When we subdivide tensor patches, we go through the same calculations for each edge regardless of whether it's top/bottom. | 09:48.30 |
| | Hence we should never be able to get rounding differences. | 09:48.37 |
| tor8 | the patches may have slightly different numbers and not align perfectly, IME | 09:49.00 |
| Robin_Watts | so the original mesh data may be wrong ? | 09:49.18 |
| tor8 | I've seen examples where the original mesh data is wrong, yes | 09:49.31 |
| | so it's worth double checking that first | 09:49.48 |
| Robin_Watts | I did have some code in there that would check the extent of each patch, and cut the subdivision down if the patches were small. | 09:52.48 |
| | but I've since realised that that is not safe to do; if you have 2 adjacent patches, and subdivide one into 2 and the other into 4, the edges don't agree. | 09:53.23 |
| | gs goes to some lengths to insert triangles there to make sure they match up. | 09:53.41 |
| tor8 | biggest problem with the subdivision is it has to be the same for adjoining patches or you will get unsightly seams | 09:53.43 |
| Robin_Watts | tor8: right. | 09:53.58 |
| tor8 | on a big patch you could subdivide edges more finely than interiors, but madness lies that way when trying to create the triangle mesh to fit | 09:54.35 |
| Robin_Watts | There is no way (that I can see) to decide at the start what a suitable subdivision is, as we have no way of knowing what the patch sizes will be - or even how many patches there are in a given mesh. | 09:54.36 |
| | tor8: And we have no idea which patches *are* the edges. | 09:55.01 |
| tor8 | Robin_Watts: yeah. it's non-trivial and IMO not worth it. | 09:55.16 |
| | a better idea would be to rasterize from patches directly and not tesselate | 09:55.44 |
| Robin_Watts | tor8: pulling patches to the grid - that's tricky too. | 10:13.09 |
| | we'd need to arrange to always pull 'outwards'. | 10:13.37 |
| | The code that actually paints the spans is not exact either - it doesn't bresenham, just subdivides. | 10:14.45 |
| | so it can be off by a bit at the end of runs. | 10:14.53 |
| | But that shouldn't matter as it should be consistently off. | 10:15.04 |
| | I'm struggling to see an easy way to check the patch for not having holes in it. | 10:16.25 |
| tor8 | argh! my brain is melting... I really don't understand what's going on with this vertical writing mode offset... | 10:34.17 |
| Robin_Watts | Ok, I have a fudge that seems to solve this problem. | 10:44.54 |
| | Let's unleash it on the cluster. | 10:45.03 |
| | I think I need to buy a copy of Windows 8. | 10:54.41 |
| kens | has one | 10:55.09 |
| Robin_Watts | wonders what the difference between Windows 8 and windows 8 pro is. | 10:56.30 |
| | other than 35 quid. | 10:56.44 |
| | If I buy an upgrade edition, and install Windows 8 in a VMware instance on my WIndows 7 setup, is microsoft going to complain that I'm still using the version of windows I upgraded from? | 10:59.10 |
| kens | I 'upgraded' my WINdows 7 (the time limited thingy) and it didn't complain whhen I put it in a VM | 11:02.32 |
| | At leas it hasn't complained yet | 11:02.51 |
| Robin_Watts | I use a windows 7 installation all day every day. | 11:03.18 |
| kens | me too | 11:03.52 |
| Robin_Watts | And it was that windows 7 license that you upgraded ? | 11:04.08 |
| kens | Yes, I bought in the 'cheap upgrade' period, so I got mine for £15 | 11:04.24 |
| Robin_Watts | right. | 11:04.32 |
| kens | I installed 8 into a VM and carried on using 7 | 11:04.46 |
| | Mostly because I *really* didn't like 8 | 11:04.58 |
| Robin_Watts | Didn't the upgrade want to only install over an existing installation ? | 11:05.09 |
| kens | No, didn't seem to | 11:05.16 |
| | I can't remember if I downloaded it or got a DVD | 11:06.12 |
| Robin_Watts | $120 for the upgrade. Or 74.69 UKP to buy an OEM copy on DVD. | 11:11.32 |
| | so it's 3 quid cheaper (Including postage) to buy the full DVD. | 11:12.08 |
| | 69.99 from amazon with free next day delivery. | 11:14.02 |
| paulgardiner | Robin_Watts: how about installing W7 in a VM and upgrade from within the VM? | 11:14.24 |
| Robin_Watts | paulgardiner: That was my plan. But 1) I'd have to install win 7 in the VM with my existing key. | 11:15.02 |
| kens | I'm glad I bought the cheap upgrade when I could | 11:15.13 |
| Robin_Watts | and 2) that would still work out more expensive than just buying the OEM one. | 11:15.20 |
| | kens: yeah, I should have done the same - if I was eligible :( | 11:15.32 |
| kens | Well, it was a factor in deciding to buy a new PC, buying when I did I could specify windows 7 (important!) and still get a cheap WIndows 8 | 11:16.01 |
| Robin_Watts | just buys an OEM copy from amazon at 69.99. Should be here tomorrow. | 11:16.40 |
| | I got woken by an automated call from my bank this morning asking me whether certain transactions were mine. | 11:17.10 |
| | Did you spend XXX with "a bookshop based in Luxembourg" ? | 11:17.23 |
| | That'd be amazon. | 11:17.33 |
| | Did you spend XXX with "a furniture store based in Bedford" ? That'd be camera equipment from 7dayshop.com | 11:18.07 |
| | Did you spend XXX with "a chemical and aggregated goods store based in luxembourg" ? That'd be ebay. | 11:18.35 |
| gitterrost4 | hi, I have a question about muPDF: Is there an autoreload feature? | 11:22.35 |
| | as mentioned in this bug, apparently it has, but I don't know how to activate it: http://bugs.ghostscript.com/show_bug.cgi?id=691332 | 11:23.07 |
| tor8 | gitterrost4: send a sighup | 11:23.19 |
| Robin_Watts | gitterrost4: Or hit 'r' | 11:23.31 |
| gitterrost4 | I am talking about auto reload | 11:23.44 |
| | I.e. reloading when the file changes | 11:23.57 |
| Robin_Watts | gitterrost4: Right. There is no pure autoreload feature. | 11:24.10 |
| | But reload can be triggered by either hitting 'r' or by sending a SIGHUP to the process. | 11:24.33 |
| gitterrost4 | Ah, that's sad. Thanks anyway. | 11:24.39 |
| | I guess, I'll have to write some skript, that sends a SIGHUP. Thank you :) | 11:25.02 |
| Robin_Watts | So, for instance, if you are regenerating the file using a makefile or a script, you can add the SIGNUP there. | 11:25.06 |
| gitterrost4 | yup, that's what I was thinking | 11:25.17 |
| | I just didn't want to reimplement anything that's already there | 11:25.45 |
| Robin_Watts | good luck. | 11:26.00 |
| gitterrost4 | Thank you very much. Good day! | 11:26.01 |
| Robin_Watts | tor8: ping | 12:04.49 |
| | (and sebras if he's interested) | 12:04.58 |
| tor8 | Robin_Watts: yes? | 12:07.18 |
| Robin_Watts | So, this mesh stuff. | 12:07.29 |
| | Looking at the fz_paint_triangle thing I think I can see a couple of problems. | 12:07.49 |
| | Where we calculate x0 and x1, we then call paint_scan on those values. | 12:08.18 |
| | both x0 and x1 are rounded down. | 12:08.25 |
| | really we should round the lower one down and the upper one up to ensure that we are less likely to get gaps. | 12:09.03 |
| | That's problem 1, easily fixed. | 12:09.25 |
| | problem 2: in paint_scan, we take w = x0 - x1 | 12:09.44 |
| tor8 | that results in 1 pixel overdraw, which is bad for xps with transparent shadings | 12:09.45 |
| Robin_Watts | transparent shadings are done by rendering opaquely to a group, then blending, right? | 12:10.11 |
| | hence overdraw doesn't matter. | 12:10.15 |
| tor8 | Robin_Watts: only in pdf | 12:10.22 |
| | in xps the gradient stops have alpha values | 12:10.31 |
| Robin_Watts | really? | 12:10.52 |
| | I refer you to *p++ = 255 in paint_scan | 12:11.02 |
| | how can that work then ? | 12:11.37 |
| tor8 | Robin_Watts: ah. I think it may work for xps because we render to a pixmap in parameter space, which then gets expanded using the shade->function color map lookup | 12:13.08 |
| Robin_Watts | so overdraw doesn't matter there either ? | 12:13.28 |
| tor8 | Robin_Watts: did you check whether the input patches were perfect or slightly misaligned? | 12:13.46 |
| | Robin_Watts: so it shouldn't | 12:13.54 |
| | s/it/overdraw/ | 12:14.05 |
| | s/$/ matter for xps either/ | 12:14.20 |
| Robin_Watts | I did not check that. I've got it cut down to a single mesh, but that's 70K of data. | 12:14.22 |
| | 70K mesh for a 20x20 area at 200dpi. Can you say "MAD AUTHORING!" ? | 12:14.55 |
| tor8 | Robin_Watts: if it's all in one mesh, you could list and sort the vertices and find almost-the-same ones | 12:15.03 |
| | insane authoring. synonymous with "made by cairo". | 12:15.29 |
| Robin_Watts | tor8: I could, but... | 12:15.36 |
| kens | Oh, is it a Cairo PDF ? | 12:15.40 |
| tor8 | I have no idea :) | 12:15.48 |
| Robin_Watts | It's not cairo as far as I know. | 12:15.53 |
| tor8 | but it's usually cairo these days. used to be powerpoint that had MAD AUTHORING | 12:15.59 |
| kens | Might have started life in teh PostScript world, that's thge sort of insance shading I've seen before | 12:16.17 |
| Robin_Watts | but anyway... problem 2: in paint_scan, we take w = x0 - x1 | 12:16.22 |
| | I'd like that to be w = x0 - x1 + 1 | 12:16.36 |
| tor8 | Robin_Watts: anyway, all this is intended behaviour | 12:16.51 |
| Robin_Watts | That moves us towards the 'any part of a pixel' rule. | 12:16.58 |
| tor8 | x0 = fixed_x0 >> 16 | 12:17.00 |
| | I'm following the basic 3d rasterization rules there | 12:17.14 |
| | as is usual for triangle rasterization | 12:17.23 |
| Robin_Watts | But even with those 2 changes in, I still get a gap. | 12:17.34 |
| tor8 | don't overdraw and stop short of the bottom/right edge | 12:17.35 |
| Robin_Watts | I think the problem is indeed patches with gaps in, and I suspect the gap is a vertical one. | 12:17.57 |
| tor8 | Robin_Watts: toss me the file. I'm fed up trying to figure out this wmode madness. | 12:18.10 |
| Robin_Watts | I tried a hack that expanded the polys a bit. | 12:18.51 |
| | Scan around the poly, finding the min/max x and y. | 12:19.02 |
| | Then round the min's down and the maxes up. | 12:19.12 |
| | and this solves this file. Yay! | 12:19.19 |
| tor8 | if the patches are done properly, with the same coords, the current code (afaui) should not yield any gaps | 12:19.26 |
| Robin_Watts | tor8: I agree. | 12:19.37 |
| tor8 | but if there are bad t-joins or other idiocies going on, there will be cracks | 12:20.00 |
| Robin_Watts | I've spent a day now looking for problems, and I agree that the current code should not produce gaps given perfect input data. | 12:20.23 |
| | the fact that we are seeing gaps makes me think that there must be flawed input data. | 12:20.45 |
| | and so I'm looking for ways for us to cope better with that. | 12:21.02 |
| tor8 | it's quite common in the files I looked at last time I was investigating cracks to have these crappy joins | 12:21.10 |
| | where you have one edge going from vertices A .. B | 12:21.22 |
| Robin_Watts | If the flaws are tiny differences due to FP then it's not great that we can render them with whole pixels missing | 12:21.37 |
| tor8 | and then two triangles aligned with this but having a vertex at the midpoint between A and B | 12:21.43 |
| | so A..M..B and on one side of the edge you have one triangle from A..B and on the other side of the edge A..M and M..B | 12:22.09 |
| Robin_Watts | tor8: Right. | 12:22.15 |
| tor8 | that sort of cofiguration will give cracks | 12:22.16 |
| Robin_Watts | yes indeed. | 12:22.22 |
| | but if we move to an 'any part of a pixel' model for rendering meshes, such cracks become much less likely. | 12:22.50 |
| tor8 | touching any part of a pixel rendering would make those cracks less likely | 12:23.16 |
| | but completely mess up antialiasing should we ever want to implement it | 12:23.27 |
| | and result in overdraw | 12:23.35 |
| | but given the current way we do xps shadings using the color lookup function, the overdraw won't break transparency at least | 12:24.01 |
| Robin_Watts | indeed. | 12:24.15 |
| | The 2 changes I mentioned earlier are enough to do the X part of 'any part of a pixel'. | 12:24.58 |
| tor8 | so a proper 'touch any pixel' rasterizer is fine by me. I'm not sure what needs to be changed to implement that algorithm though, is it just a matter of rounding differently? | 12:25.00 |
| Robin_Watts | It doesn't help with Y though. | 12:25.11 |
| tor8 | y < h into y <= h | 12:25.51 |
| | shouldn't that be enough? | 12:25.56 |
| Robin_Watts | Not fully, no. | 12:27.07 |
| | consider 'shallow' edges of a triangle. | 12:27.45 |
| | Rounding that line up or down by 1 in the Y makes a difference of lots in the X. | 12:28.23 |
| tor8 | gel[i][1] = floorf(... + 0.5); // not fixpoint | 12:28.52 |
| Robin_Watts | Essentially what we want to do is to 'explode' the triangle. | 12:29.42 |
| | which gives us 3 edges, plus various small bits around the edges of the corner pixels. | 12:30.12 |
| tor8 | hm, when making the triangle edge list we round to the pixel grid already | 12:30.33 |
| Robin_Watts | On y, not on x. | 12:30.50 |
| tor8 | maybe the cracks would disappear (or mostly disappear) if we did not do that | 12:30.55 |
| | we truncate and *then* boost to fixed point | 12:31.05 |
| Robin_Watts | oh, wait, yes.... | 12:31.09 |
| tor8 | if we kept both as fixed point, and fixed the errors that would ensue in the y-looping logic | 12:31.32 |
| Robin_Watts | I will fiddle with that after lunch. | 12:31.41 |
| tor8 | we may improve the situation of the T-joins | 12:31.44 |
| Robin_Watts | thanks. | 12:31.44 |
| | indeed. Thanks for that. | 12:31.50 |
| tor8 | maybe that'll fix the gaps without needing to change to touches-every-pixel | 12:32.19 |
| | enjoy lunch! | 12:32.23 |
| kens | chrisl I see you have another nutter with an established position of correctness..... | 13:17.58 |
| | "when I write my own programs, I ensure they work | 13:19.33 |
| | on ALL compilers." what, really ? All of them ? All versions ? | 13:19.33 |
| Robin_Watts | Our code does work. On all C compilers. The compiler you are using fails to compile correct C. Therefore it is not a C compiler. | 13:45.20 |
| kens | THat was ratehr how I felt about it | 13:45.43 |
| | I was just amused by the assertion | 13:47.21 |
| Robin_Watts | I am tempted to post a reply where I say: "Cliche buffer overflow... aborting..." | 13:58.22 |
| chrisl | Sorry, I was off counting to ten - very, very slowly...... | 14:04.25 |
| kens | I think I would need a lot more than 10 | 14:04.36 |
| chrisl | You don't know how slowly I was counting! | 14:04.53 |
| sebras | tor8: Robin_Watts annoying things at work forced me to stop reading. I'll read the logs when I get home. | 14:15.38 |
| chrisl | kens: mind you, it is a little worrying that we can't build Ghostscript with a C89 compiler now :-( | 14:16.09 |
| kens | Well that was a choice we took with that PR stuff | 14:16.30 |
| | are we not implementing our own sprinf ow for locale ? | 14:17.07 |
| chrisl | No, I included fallbacks so that non-C99 compilers would still have a sane fallback for those PR macros - this is other stuff entirely. So far, lcms2 and openjpeg have c99 constructs in them | 14:17.36 |
| kens | well we are stuck in that case. | 14:17.55 |
| | OTOH, c99 is now 14 years old.... | 14:18.07 |
| | and mostly supported before it was finally finished | 14:18.16 |
| amr_ | Hello, I have a problem while loading the "mupdf.c" | 14:18.33 |
| Robin_Watts | amr_: Hi | 14:18.40 |
| amr_ | Hi Robin | 14:18.50 |
| Robin_Watts | chrisl: Could a possible fix be as simple as to put some more whitespace in there? | 14:18.53 |
| chrisl | kens: True, most of the stuff we use was common across most/all compilers long before c99 came along | 14:19.10 |
| Robin_Watts | Instead of: "int %"PRIpsint use "int %" PRIpsint | 14:19.11 |
| chrisl | Robin_Watts: possibly, but as this really seems like a compiler bug, it's rather hard to tell | 14:19.32 |
| Robin_Watts | I guess without knowing the vagaries of his compiler/configuration, we're stuffed. | 14:19.39 |
| amr_ | in the mupdf.c file you mean? | 14:19.43 |
| Robin_Watts | I rather suspect he's screwed up the configure. | 14:19.54 |
| | amr_: Sorry, no, was finishing another conversation. | 14:20.04 |
| amr_ | nvm | 14:20.13 |
| Robin_Watts | amr_: So... does mupdf from google play work on your emulator ? | 14:20.22 |
| amr_ | yes | 14:20.32 |
| Robin_Watts | ok. What emulator ? | 14:20.39 |
| amr_ | I installed it from google play on emulator and devices and it's working | 14:20.48 |
| Robin_Watts | and what devices ? | 14:21.04 |
| amr_ | the emulator i created using the instructions in the mupdf documentation | 14:21.05 |
| Robin_Watts | Ok. So it's the standard emulator. For what platform type? | 14:21.35 |
| amr_ | 2.2 | 14:21.45 |
| | and on my tablet galaxy tab 2 | 14:21.58 |
| Robin_Watts | In the standard emulator if you set up froyo or gingerbread, you get an armeabi based emulation. | 14:22.01 |
| amr_ | 4.0.4 | 14:22.03 |
| Robin_Watts | Are you attempting to build V8 in? | 14:22.18 |
| | (If you don't know what v8 is, then the answer is probably no :) ) | 14:22.51 |
| amr_ | I was depending on the documentation provided | 14:23.42 |
| Robin_Watts | amr_: I can't remember if the documention mentions v8 or not. | 14:23.59 |
| | essentially if you want to use forms, you need to link in a javascript engine. We use the "v8" javascript engine from google. | 14:24.41 |
| | You'd have had to have downloaded a copy of that and put it in thirdparty. | 14:24.53 |
| | If you've not done that, then that removes one large possible area of problems. | 14:25.07 |
| amr_ | mmmm, this is kinda confsuing | 14:26.08 |
| Robin_Watts | amr_: Look in the thirdparty directory. Is there a v8-3.9 directory there? | 14:26.30 |
| amr_ | no | 14:26.53 |
| Robin_Watts | excellent. That makes life easier. | 14:27.06 |
| | So, all the instructions talk about how to build mupdf etc without using eclipse. | 14:27.29 |
| | Have you tried that ? | 14:27.34 |
| amr_ | I used cygwin to build then imported the project android to eclipse to run it but an error occurred while running it | 14:28.56 |
| henrys | Robin_Watts:I wonder if Raed could be directed more towards mupdf which is already heading down the winrt path anyway. | 14:30.04 |
| Robin_Watts | that thought fills me with dread. | 14:31.44 |
| kens | Raed or WinRT ? | 14:32.09 |
| | wor both.... | 14:32.18 |
| Robin_Watts | the conjunction of Raed and mupdf. | 14:33.15 |
| | His makefile foo is weak. | 14:33.49 |
| henrys | I'm just saying if he want a PDF solution for winrt michael is working on it now right? | 14:34.19 |
| Robin_Watts | Is that what he wants? | 14:34.35 |
| amr_ | how to make or create the v8-3.9 directory Robin? | 14:34.40 |
| Robin_Watts | I asked what he wanted and he didn't answer. | 14:34.43 |
| | amr_: You do not want the v8-3.9 directory. | 14:35.00 |
| | amr_: You only need that if you want to handle forms etc. | 14:35.14 |
| henrys | Robin_Watts: we don't know | 14:35.18 |
| Robin_Watts | amr_: Even if you want to handle forms eventually , let's get it working without that for now. | 14:35.44 |
| | amr_: So, why not follow the instructions as written and leave eclipse out of it. | 14:36.10 |
| | Follow them all the way through and you should be able to get something running under the emulator and/or on devices. | 14:36.34 |
| | THEN you can try to pollute it all by using eclipse. | 14:36.44 |
| | At least that way we minimise the amount that can be going wrong. | 14:36.56 |
| amr_ | I already left eclipse and used these instructions in the readme file, but in the step number 12 an error appears | 14:37.27 |
| | while using ndk-build in cygwin | 14:37.37 |
| Robin_Watts | Right. What error ? | 14:38.00 |
| amr_ | it says: your GNUMAKE variable is defined to invalid name: /usr/bin/make, please fix it to point to valid make executable | 14:39.18 |
| | I already used make to generate the generated directory in the project | 14:39.54 |
| Robin_Watts | amr_: Right. You're obviously using the latest ndk. | 14:40.16 |
| amr_ | yup ndk 8 | 14:40.26 |
| Robin_Watts | Google have changed stuff so that you can call ndk-build from a windows shell. | 14:40.35 |
| | Unfortunately in doing so they seem to have broken calling it from under cygwin. | 14:40.49 |
| | So bring up a command window (dos prompt thing) and try to run it from there. | 14:41.07 |
| amr_ | and I run ndk-build under cmd | 14:41.18 |
| Robin_Watts | right. | 14:41.30 |
| amr_ | but in the end it also gives me an error | 14:41.54 |
| | it says in the end 1 Error | 14:42.02 |
| | and the compilation terminated | 14:42.18 |
| | the Error is : no such file or directory | 14:43.19 |
| Robin_Watts | ok, do you know how to use pastebin.com ? | 14:43.23 |
| amr_ | never heard about it :( | 14:43.56 |
| Robin_Watts | Go to pastebin.com, then copy/paste as much of the error lines as you can into it. | 14:44.37 |
| | That will give you a URL that you can paste here, so I can see your error lines. | 14:44.53 |
| amr_ | ok | 14:45.05 |
| Robin_Watts | It saves you pasting huge amounts of text into this window (which is considered unfriendly) | 14:45.08 |
| amr_ | here is the URL Robin: http://pastebin.com/3aUFWa1e | 14:49.27 |
| Robin_Watts | ok, it's failing to find fitz.h, which is pretty basic :) | 14:50.41 |
| | do you have fitz/fitz.h ? | 14:50.57 |
| amr_ | yes i have it | 14:51.30 |
| | I just checked it now | 14:51.38 |
| Robin_Watts | Interestingly, I have r8e, not r8d here. | 14:51.50 |
| | and the line of the paste that says: make: *** [C:\android-ndk-r8d/obj/local/armeabi/objs/mupdf/mupdf.o] Error 1 | 14:52.12 |
| | That's very off. mupdf.o shouldn't be there. | 14:52.56 |
| | Try again, with ndk-build V=1 | 14:53.15 |
| amr_ | ok | 14:53.22 |
| | the same error | 14:53.48 |
| Robin_Watts | And how come you're in C:\Users\3mR ? | 14:53.50 |
| | Surely you should be in C:\Users\3mr\mupdf\android or something ? | 14:54.02 |
| amr_ | OPS, my mistake | 14:55.23 |
| | ok I ran it and in the end it gave me "Stop" | 14:55.54 |
| Robin_Watts | So it worked? | 14:56.19 |
| | so, keep following the instructions. | 14:56.39 |
| amr_ | make: *** No rule to make target `C:\android-ndk-r8d/jni/../../fitz/base_context .c', needed by `C:\android-ndk-r8d/obj/local/armeabi/objs/mupdfcore/__/__/fitz/b ase_context.o'. Stop. D:\mupdf-1.2-source\android> | 14:57.20 |
| Robin_Watts | amr_: I don't understand how it can be getting that path. | 14:57.53 |
| amr_ | is it what is supposed to appear? | 14:57.53 |
| Robin_Watts | The source code isn't inside C:\android-ndk-r8d is it ? | 14:58.10 |
| amr_ | the project is in that path | 14:58.25 |
| Robin_Watts | Where in that path? | 14:59.10 |
| amr_ | I have a path to the android-ndk-r8d and another path to the project android in the mupdf-1.2-source | 14:59.26 |
| Robin_Watts | Right, but the make error you quote above says that's it's looking for fitz/base_context.c in C:\android-ndk-r8d | 15:00.13 |
| | so I'm asking, have you got any mupdf stuff inside C:\android-ndk-r8d | 15:00.32 |
| amr_ | yup | 15:00.42 |
| Robin_Watts | what? and where? and why? | 15:00.55 |
| amr_ | the jni directory which contains .c files | 15:01.09 |
| Robin_Watts | ok. The instructions don't say to do that. | 15:01.30 |
| | You're supposed to be following the instructions exactly as written (except for running ndk-build under cmd rather than under cygwin). | 15:02.15 |
| | Otherwise you're going to hit all sorts of problems, and waste my time. | 15:02.27 |
| tkamppeter | Did Artifex already decide who will represent Ghostscript (MuPDF) on the OpenPrinting Summit? | 15:03.52 |
| Robin_Watts | tkamppeter: mvrhel will be doing that, I believe. | 15:04.13 |
| | chrisl: How slowly are you counting to 10 now? :) | 15:04.32 |
| chrisl | Not slowly enough, apparently - grrrrr!! | 15:04.56 |
| Robin_Watts | "bitfields don't work on *my* port of gcc. No one uses bitfields, right? Do you know how hard it is to port gcc?" :) | 15:05.17 |
| henrys | chrisl:I'd just close it off and tell him sorry we couldn't help | 15:05.40 |
| chrisl | I was just about to point out that we use bitfields quite a lot | 15:05.45 |
| | henrys: given that "normal" gcc 2.95.3 works just fine, I don't how we could help even if we wanted! | 15:06.21 |
| amr_ | ok Robin, i removed it and ran it again and this is what appeared: | 15:06.22 |
| | D:\mupdf-1.2-source\android>ndk-build Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: C:\android-ndk-r8d /jni/Android.mk C:/android-ndk-r8d/build/core/add-application.mk:165: *** Android NDK: Aborting. .. . Stop. D:\mupdf-1.2-source\android> | 15:06.24 |
| Robin_Watts | amr_: APP_BUILD_SCRIPT isn't anything we've set. | 15:07.18 |
| | I can only imagine that you've screwed something up because of the way you were trying to build it. | 15:07.37 |
| | I'd delete everything and start again. | 15:07.58 |
| amr_ | ok Robin I will start again to build it and thanks alot, I really appreciate your time :) | 15:09.27 |
| kens | Hmm well Raed can do everything he wants using MuPDF, except ocnvert to PDF/A | 15:13.50 |
| henrys | kens:that a big "except" | 15:15.52 |
| kens | Yeah Robin really needs ot get that pdfwrite stuff working :-) | 15:16.19 |
| henrys | chrisl:can't imagine shelly's fix would address a crash. | 15:16.20 |
| | kens:I've been telling him for months to get cracking on that ;-) | 15:16.46 |
| chrisl | henrys: I'm just doing as I was bid...... | 15:17.08 |
| henrys | chrisl: right | 15:17.23 |
| Robin_Watts | henrys: If you fix the mupdf mesh drawing, and the image extraction, and the multithreaded crashes with the store, I'll get right back on pdfwrite :) | 15:20.41 |
| henrys | runs away screaming in terror | 15:22.26 |
| | chrisl: I'm waffling on asking for 6.x not some much for the pcl customer but because it might have something interesting in it for PDF/PS and I don't want to fall behind multiple versions. | 15:23.47 |
| | chrisl:what do you think we should do? | 15:25.48 |
| chrisl | henrys: I have 7.x here, I just haven't had time to do anything with it | 15:29.25 |
| henrys | chris:oh okay i didn't know you had it. | 15:31.26 |
| | chrisl:a quick look at the release notes would be useful just in case there is something earth shaking but I'd doubt it. | 15:32.18 |
| chrisl | Yeh, I got it early this year. Unfortunately, it doesn't fix the fundamental problem I hit with the PS/PDF integration | 15:32.34 |
| henrys | chrisl:yup not surprised. | 15:33.32 |
| chrisl | henrys: in the timetable I had in my head, I was planning to get it into a testable build before the next staff meeting - other factors permitting! | 15:34.04 |
| | If it had solved the problem I ran into, I'd have put a higher priority on it. | 15:35.03 |
| | henrys: FWIW, I can certainly try to test the customer's issue with 6.2 - it shouldn't be too hard to get it to work with the old code | 15:35.51 |
| henrys | chrisl:I'm sure marcosw will dispatch when the time is right. | 15:39.44 |
| marcosw | henrys: I'm not working on this, I was told that we don't support 6.x with Ghostscript. | 15:41.13 |
| henrys | marcosw:you put the ball in their court but your still on the court ;-) | 15:42.36 |
| chrisl | I have to go - will check back later | 15:43.09 |
| ray_laptop | chrisl_away: I'm surprised how much effort you put into 693918. | 16:26.55 |
| kens | thinks that's a bozo that hsould have been told to get lost *much* faster | 16:30.19 |
| | OK I'm off, goodnight all | 16:33.57 |
| GSA | hello | 17:52.32 |
| ghostbot | niihau | 17:52.32 |
| GSA | I am facing an issue during building mupdf, I am following this documentation <http://www.mupdf.com/doc/how-to-build-mupdf-for-android> | 17:53.37 |
| | but first is there someone to talk to me? | 17:54.04 |
| Robin_Watts | GSA: sure. | 17:54.09 |
| GSA | Great! | 17:54.22 |
| Robin_Watts | Are you working on windows or linux ? | 17:54.40 |
| GSA | in that command : nano local.properties | 17:54.50 |
| | Windows | 17:54.58 |
| Robin_Watts | nano is an editor. Just use whatever editor you want to edit local.properties. | 17:55.18 |
| | Those instructions are written for linux. | 17:55.28 |
| | The ones in android/ReadMe.txt in the source are more verbose and cover windows better. | 17:55.55 |
| | what version of the ndk are you using ? | 17:56.04 |
| GSA | ndk8rd | 17:56.25 |
| Robin_Watts | ok. so in ReadMe.txt it says to run ndk-build under the cygwin shell. | 17:57.24 |
| | You probably need to run it at a dos command prompt, because of changes in the latest ndk. | 17:57.42 |
| | other than that the ReadMe.txt instructions should be good. | 17:57.53 |
| GSA | ok thanks | 17:58.30 |
| Robin_Watts | marcosw: is the cluster back in that jammed position again? | 17:59.04 |
| marcosw | Robin_Watts: perhaps, I'll check. | 17:59.20 |
| GSA | one more question, the local.properties, I am supposed to edit it and write the SDK dir inside it right? | 17:59.35 |
| Robin_Watts | oh, it moved. | 17:59.35 |
| | Whatever ReadMe.txt says :) | 17:59.53 |
| | yes, the SDK path. | 18:00.16 |
| marcosw | No, I think it was just a long upload time from miles (perhaps the internets is being worked on at this office, I think they were supposed to upgrade the connection earlier this week). | 18:00.21 |
| henrys | Robin_Watts:most of the people I run with would gladly take a spot in the London Marathon if they could get in. Everyone is signing up for races. | 18:03.35 |
| Robin_Watts | henrys: Most of us would like a spot in the london marathon :) | 18:04.04 |
| henrys | The boston thing is having the opposite effect you might expect. A lot of folks I know that ran this year are going back next because of what happened. | 18:06.29 |
| mvrhel_laptop | tkamppeter are you here? | 18:07.08 |
| Robin_Watts | henrys: right. | 18:07.46 |
| ray_laptop | all of a sudden my internet got really slow :-( | 18:21.17 |
| mvrhel_laptop | ok. the non high level image color monitoring seems to work | 19:01.12 |
| | at least the RGB case | 19:01.26 |
| | neutral in CIELAB seems to jump around 0x80 +/- 1 | 19:20.53 |
| | for the a and b components | 19:21.04 |
| ray_laptop | Bug 693412 doesn't make sense to me. Why would someone want 2 copies printed in Duplex mode with the same image on the front and back of the sheet ? | 19:30.29 |
| | I must be misunderstanding something. I know some (high end) printers have fancy paper handling that lets them funnel copies of a page to a special hopper, then when printing the back side, they pull from that tray, but those printers usually directly implement generating multiple copies. | 19:33.58 |
| | and as far as ghostscript is concerned, we just generate on copy in Duplex mode. | 19:34.40 |
| | but I don't know of any inkjet printers that can do this even if they do support printing on the front and the back. For these, to do Duplex copies the software has to send the job multiple times | 19:36.04 |
| | mvrhel_laptop: so do you think that you need to allow for an epsilon to classify a color as "close enough" to neutral ? | 19:53.49 |
| | mvrhel_laptop: we can tell the customer that they may want to tweak it. | 19:54.32 |
| | mvrhel_laptop: and do we want a similar "close enough" range for RGB and CMYK ? | 19:54.56 |
| tkamppeter | ray_laptop, hi | 20:01.30 |
| | mvrhel_laptop, will you give a presentation about GS and MuPDF state of the art, and also about color management state of the art on the OpenPrinting Summit? | 20:04.01 |
| | ray_laptop, sorry, it was mvrhel_laptop laptop who called me, everyone has _laptop in his alias nowadays. | 20:05.48 |
| ray_laptop | tkamppeter: np | 21:20.04 |
| | have bg printing working, but one thing I need to fix up handling the case when the file for each page is different (as in -o out%d.ppm) | 21:21.03 |
| | in case anyone cares, I decided I liked BGPrint=true better -- anyone object or have a better suggestion ? | 21:21.55 |
| henrys | ray_laptop:I wish I had a duplexer I'd like to try a few experiments, I have to think they want #copies of the page front and back. | 21:42.13 |
| | Forward 1 day (to 2013/04/19)>>> | |
IRC Logs