| | <<<Back 1 day (to 2012/04/16) | 2012/04/17 |
| Robin_Watts | bah. | 07:41.38 |
| kens | You're up early Robin_Watts | 07:41.52 |
| Robin_Watts | Was supposed to take little dog to the vets today for a test; he needed to be starved overnight. | 07:41.55 |
| | But when I put the dogs in the garden they had a fat ball off the bird table. | 07:42.16 |
| kens | oops | 07:42.24 |
| Robin_Watts | so I'll be up stupidly early tomorrow instead :/ | 07:42.28 |
| kens | Hmm, marcos closed two of my bugs, and I have no idea why | 07:43.22 |
| Robin_Watts | kens: He went from RESOLVED -> CLOSED, right? | 07:47.33 |
| chrisl | Hmm, the bugs about unicode file names on Windows have been closed, too, and they are not resolved..... | 07:54.09 |
| Robin_Watts | I can't immediately see that mail... | 07:59.00 |
| chrisl | Subject: [Bug 691222] Gs cannot open Unicode file names on Windows | 08:01.41 |
| kens | Robin_Watts : yes, that's correct, except one was 'LATER' | 08:02.53 |
| chrisl | But it's probably my fault for leaving it "Resolved" after we ifdef'ed out your UTF/wchar code | 08:03.03 |
| kens | Actually, thinking about it, no. | 08:03.22 |
| | One of them was still open I think, I'll check the history | 08:03.33 |
| | No, I was right. One was 'resolved' and went to closed, teh other was 'later' and went to closed. | 08:04.04 |
| | I think hte first one is OK, because I have a duplicate still open | 08:04.16 |
| | The 'LATER' one shouldn#'t be closed though | 08:04.43 |
| | I'm getting a network error updating my Git repository, is casper OK ? | 08:08.26 |
| | Its responding to ping... | 08:08.44 |
| chrisl | update worked for me | 08:09.07 |
| kens | This time it seems to be working.... | 08:09.27 |
| | 3rd attempt | 08:09.37 |
| Robin_Watts | My ssh connection to casper is fine, but the web connection is knackered. | 11:22.08 |
| kens | Mine is back to OK | 11:22.30 |
| Robin_Watts | What is 'console-kit-daemon', and why is it consuming a huge amount of time on casper? | 11:30.24 |
| | Gah. I can't even google now :( | 11:30.41 |
| kens | http://serverfault.com/questions/160612/console-kit-daemon-can-it-be-stopped | 11:31.37 |
| Robin_Watts | reboot router time. | 11:32.37 |
| Robin_Watts_ | Well, web seems happier. | 11:35.27 |
| | I am confused by my bmpcmp results though. | 11:35.36 |
| | OK. I've cleared the bmpcmp results, let's rerun them. | 11:36.50 |
| Robin_Watts | Confused. The cluster runs my code and finds 468 differences. | 11:54.27 |
| | So I bmpcmp it, and every job comes back with 0 length files, implying that no differences were found. | 11:54.55 |
| | but then, magically... I end up with a set of bmpcmp results in my bmpcmp directory. | 11:55.20 |
| kens | have you tried them locally ? | 11:55.21 |
| Robin_Watts | When I run on peeves, I cannot reproduce the results. | 11:55.34 |
| kens | scratches head | 11:55.42 |
| | The cluster seems to be OK for me. | 11:56.02 |
| Robin_Watts | (that is, I expect there to be differences, but when I download the output from peeves and look at it locally, I don't see the gross differences that bmpcmp is showing. | 11:56.19 |
| | I suspect that somehow I'm getting an old version. | 11:56.38 |
| kens | Hmm I guess that's possible | 11:56.52 |
| Robin_Watts | kens: Sanity check me... if you look at my bmpcmps, page 1, number 13, second one, you see a 'crack' in the background to the word 'usefulness' ? | 12:01.54 |
| kens | one sec | 12:02.05 |
| | Ye definitely | 12:02.35 |
| | same in 14 | 12:03.23 |
| | 27 has a black line instead of white | 12:04.24 |
| Robin_Watts | yes, I expect to see lots of 'little' differences. | 12:04.39 |
| kens | No 27 looks wrong | 12:04.46 |
| Robin_Watts | but when I run the file on peeves, I don't get the big differences (like the crack) | 12:04.54 |
| kens | black dotted lein rthrough the sdading | 12:04.57 |
| | Oh, I see. | 12:05.05 |
| | were these run on peeves ? | 12:05.43 |
| Robin_Watts | I use peeves as "a typical cluster node" | 12:06.05 |
| kens | I was wondering if they might have been done on macpro | 12:06.21 |
| Robin_Watts | and I've rerun the bmpcmp several times and got the same results. | 12:06.36 |
| kens | weird. | 12:06.42 |
| | lunch, back i a bit | 12:07.18 |
| | Hmm, just got a weird message while doing a cluster push | 12:59.31 |
| | error: git checkout-index: unable to create file gs/base/memento.c (Permission denied) Index was not unstashed | 13:00.02 |
| Robin_Watts | Seems to be working now for you though? | 13:52.07 |
| kens | It all seems to be OK | 13:52.52 |
| Robin_Watts | I tried again, and reproduced my problem. | 13:53.07 |
| kens | Doesn't matter if it didn't copy memento.c | 13:53.11 |
| Robin_Watts | I'm trying a taylor series based sine instead,and that seems to have solved the problems. | 13:54.18 |
| kens | that was recommended elsewhere, 3 or 4 ? | 13:54.52 |
| | terms ? | 13:55.16 |
| Robin_Watts | I'm using up to x^7 | 13:55.30 |
| kens | Oh, that sounds accurate | 13:55.39 |
| Robin_Watts | x, x3, x5, x7, so 4 terms. | 13:55.42 |
| | I may be able to drop it. | 13:55.48 |
| | but in all honesty it's consistency across the cluster I want, not accuracy. | 13:56.04 |
| kens | Site I read said 4 was pretty good, 3 was OK | 13:56.20 |
| Robin_Watts | I may even make this code depend on a define. | 13:56.24 |
| | http://dotancohen.com/eng/taylor-sine.php | 13:56.34 |
| | That suggests that I may only need up to x^5 | 13:57.01 |
| | BUT... he doesn't say *how* accurate is accurate. | 13:57.15 |
| | I think I've proved that out by .1% is not accurate enough. | 13:57.34 |
| kens | Don't remember what the article I read said | 13:58.08 |
| sobersabre | hi guys. | 14:03.00 |
| | I've been having lots of headache with 9.05 | 14:03.27 |
| | (trying to understand why) | 14:04.16 |
| | with some pdfs we're getting logs filling up their partitions with this message: | 14:04.40 |
| | **** File has unbalanced q/Q operators (too many Q's) **** | 14:05.03 |
| kens | Then your file is invalid. | 14:05.15 |
| | wGS will try and render it anyway | 14:05.39 |
| sobersabre | I understand. but I don't want the logs to explode :) | 14:05.57 |
| | and I want gs to ... give it up. | 14:06.05 |
| kens | -dPDFSTOPONERROR | 14:06.15 |
| | might help | 14:06.32 |
| | -q and -dQUIET | 14:06.54 |
| sobersabre | I see. | 14:07.32 |
| | kens: I think -dPDFSTOPONERROR is a good "fail early" policy. | 14:07.53 |
| Robin_Watts | sobersabre: This isn't anything that has changed recently, though, AIUI. | 14:07.56 |
| | What version were you using before ? | 14:08.09 |
| sobersabre | 8.71 | 14:08.28 |
| kens | sobersabre : people keep asking us to 'do like Acrobat' | 14:08.31 |
| sobersabre | I think it DIED before reaching that error. | 14:08.49 |
| | kens: I don't know what those peoples mean. | 14:08.58 |
| | salto ? | 14:09.03 |
| kens | Yes, previously GS gave up on bad files | 14:09.06 |
| sobersabre | rollover? | 14:09.06 |
| kens | sobre rthey want us to keep trying, even if the file has problems | 14:09.22 |
| | because 'Acorobat displays it' | 14:09.38 |
| sobersabre | kens: what I want you to do is not to continue, but print out something like ... error code I could refer to, and understand what it means :) | 14:09.56 |
| kens | then use PDFSTOPONERROR | 14:10.44 |
| Robin_Watts | sobersabre: PDF files contain 'streams' of operators that describe how to mark the page. | 14:10.48 |
| | q is one such operator; it means 'store the current state on a stack'. | 14:11.13 |
| | Q is another - it means 'restore a previously stored state from the stack'. | 14:11.33 |
| sobersabre | ok. | 14:11.40 |
| Robin_Watts | IF you have more Q's than q's... that's a mistake in the original file. | 14:11.50 |
| | Now you know that, the error message should make sense I hope :) | 14:12.11 |
| sobersabre | so basically there are publishers producing such f*cked up files ? | 14:12.15 |
| kens | Yes, many | 14:12.23 |
| | but 'Acrobat displays it' | 14:12.34 |
| sobersabre | and they're usually Adobe based. right ? | 14:12.36 |
| kens | No, usually other tools | 14:12.42 |
| sobersabre | can you pls name a few ? | 14:12.53 |
| | (custom?) | 14:12.58 |
| kens | wMost of them have no Producer, so I couldn't say | 14:13.32 |
| Robin_Watts | Normally gs gives the producer of the file in the error message, if there is one. | 14:13.43 |
| sobersabre | distiller, man. | 14:14.28 |
| | ADobe! EVIL BUTTS | 14:14.36 |
| | now another question. | 14:17.13 |
| | is it possible gs would once render a file, and at another time not render it ? | 14:17.30 |
| | (SAME FILE) | 14:17.35 |
| kens | Should not be, but it depends, is it the smae machine,OS, configuration etc | 14:17.49 |
| sobersabre | same machine OS configuration. same file 1000 times, can ... it be rendered differently | 14:18.24 |
| | ? | 14:18.28 |
| kens | That would be a non-deterministic problem, we have a few of those in our test suite | 14:18.47 |
| Robin_Watts | sobersabre: The answer is "No, if ghostscript is working right, but we do have a few files where we know we don't work right." | 14:19.42 |
| kens | Aha, I have no seg faults of my own again :-) | 14:22.33 |
| | Robin_Watts : Seems that git error blew away my copy of memento.c somehow | 14:26.33 |
| | But reverting changes brought it back OK | 14:27.17 |
| Shyren | chrisl: If you remember I had color problems yesterday. I can print color with hpdj340 with -sColorModel=CMY. Now the problem is that if I have red color text I see dots of other color in the text coming up in a pattern. | 14:42.51 |
| kens | Red is not a pure CMY colour, so that is to be expected. | 14:43.14 |
| Robin_Watts | Shyren: Your printer has Cyan, Magenta, Yellow (and maybe Black) inks. | 14:43.32 |
| | So red is a mixture of several inks. | 14:43.59 |
| kens | Red is a combination of magenta, blue and maybe black or yellow | 14:44.01 |
| | err/blue/cyan/ | 14:44.20 |
| Robin_Watts | And the exact shade of red will determine exactly what dithered mixture of those colors you see. | 14:44.30 |
| Shyren | How can I resolve this then? Images look awkward | 14:45.44 |
| kens | What do you mean 'resolve' ? | 14:46.00 |
| | THe colour sounds like it is what you should expect | 14:46.11 |
| Shyren | The document has red color and print shows dots of other color in between red color | 14:46.57 |
| kens | We've just explained that. | 14:47.10 |
| | Unless your printer has 16 million inks, then colours are made of a combination of inks. | 14:47.32 |
| chrisl | Shyren: have you tried using a higher resolution? | 14:47.56 |
| Robin_Watts | Shyren: Your printout contains a shade of red that doesn't exactly match your inkjets inks. So a mixture of inks is used to approximate it. | 14:48.21 |
| | IF you use higher resolution (as chrisl suggests) then the dots will be smaller, and will hopefully be less noticable, but will still average out to give you the correct color overall. | 14:48.57 |
| chrisl | It could also be that our default halftones aren't really suitable for inkjet printers....... | 14:49.45 |
| Shyren | chrisl: I am trying with higher resolution now. -r600 or higher? | 14:51.21 |
| chrisl | Shyren: what resolution is your printer? | 14:51.44 |
| Robin_Watts | Shyren: What model printer? | 14:52.40 |
| Shyren | Chrisl: Robin_Watts: H470. Let me look up the resolution on web for the printer | 14:53.15 |
| Robin_Watts | "Up to 4800 optimized dpi color and 1200 input dpi" | 14:54.17 |
| | which smells like 1200dpi as far as we are concerned. | 14:54.28 |
| henrys | I thought these printers were handled by http://hplipopensource.com/ | 14:56.04 |
| chrisl | henrys: does that apply to MacOS as well? | 14:56.51 |
| Shyren | henrys: I know but I am not able to install that on iPad yet while I can do that with GhostScript. | 14:56.52 |
| | chrisl: I am compiling both for MacOS and iOS | 14:57.13 |
| | In the meanwhile -r1200 seems to be unsupported while using hpdj340 and -sColorModel=CMY | 14:58.03 |
| | Should I be using any other device? | 14:58.15 |
| chrisl | Shyren: well, as I keep saying, these aren't devices that we developed, they were written by third party contributors, so our knowledge of them is little to none | 14:58.18 |
| Robin_Watts | That's perhaps not surprising as the GP Deskjet 340 tops out at 300dpi in color. | 14:58.38 |
| henrys | I would assume either an HP or cups solution for mac os x - likely our driver is going to be out of date. | 14:58.58 |
| chrisl | Shyren: try using the generic pcl3 device and using 600 dpi | 14:59.21 |
| Shyren | chrisl: with pcl3 and 600 dpi it gets stuck but whatever it prints is much better than hpdj340 | 15:01.30 |
| henrys | Can you contribute your ios port changes? | 15:02.04 |
| | Shyren ^^^ | 15:02.12 |
| Shyren | henrys: I would like to talk to you offline about it. Whats your email? | 15:02.38 |
| henrys | henry dot stiles at artifex dot com | 15:02.59 |
| | eventually we are going to have to do something with these old crufty devices. | 15:05.28 |
| kens | Chuck em out | 15:05.43 |
| chrisl | Yep, all we can really do is remove them..... | 15:05.57 |
| Shyren | chrisl: Is there any other hpdj device which supports 600dpi? | 15:08.48 |
| chrisl | Shyren: it sees to be more a combination of settings - for example, hpdj1120c does 600dpi, but I get an error about intensity levels..... | 15:09.49 |
| miha | is there any way to use ghostscript so thumbnails are generated..faster.. it takes a while with lots of pages? | 15:18.35 |
| Shyren | chrisl: Usually which devices one should use for HP printers which are not third party? | 15:19.17 |
| chrisl | Shyren: we don't have any. As henrys said, the hplips stuff removed any impetus for us to develop/maintain HP specific devices | 15:20.51 |
| Shyren | chrisl: So my best bet is to port hplips on iOS :) | 15:22.36 |
| chrisl | Shyren: if I were you, I would have a look at the djet500c device and see if you can work out why its output doesn't work right on your printer. | 15:24.24 |
| Shyren | chrisl: http://pastebin.com/ngPUTqBf Can you explain what did those lines do which you have removed. It seems thats breaking the print | 15:25.20 |
| chrisl | Shyren: the code was removing non-marked pixels - on your printer, and mine, the result was that those removed pixels were being drawn black. So I changed it so it doesn't drop those non-marking samples. | 15:26.50 |
| | Shyren: I actually revised the patch a bit, so you might want to try the one I actually committed to our sources: | 15:28.08 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2d76c984 | 15:28.12 |
| Shyren | chrisl: Thanks! | 15:28.46 |
| miha | looking at http://stackoverflow.com/questions/4548919/any-tips-for-speeding-up-ghostscript are options ok? | 15:28.58 |
| kens | Depends what you mean by OK | 15:29.46 |
| miha | kens: i'm interested in fast generation of 300 thumbnails from pdf.. | 15:30.41 |
| | i'd even sacrifice some quality :) | 15:31.01 |
| ray_laptop | miha: are you going to jpeg or something else ? | 15:31.10 |
| Robin_Watts | miha: I'd use mupdf personally. | 15:31.14 |
| ray_laptop | miha: and are you using '-dPDFFitPage' with a fixed media size ? | 15:31.42 |
| miha | ray_laptop: png | 15:31.43 |
| | ray_laptop: no? | 15:31.51 |
| kens | miha I would not describe 300 dpi as a thumbnail | 15:31.58 |
| | and screen is not appropriate for 300 dpi previews | 15:32.09 |
| Robin_Watts | I'm assuming miha means "300 files" rather than "300dpi". | 15:32.26 |
| kens | Oh, misread. | 15:32.37 |
| ray_laptop | miha: well, if you have more than one CPU, gs will run faster to something like ppmraw, then use another process to convert ppm to png. png compression is sort of slow | 15:32.45 |
| Robin_Watts | It was unclear. | 15:32.46 |
| kens | Well setting resolution would help, maybe | 15:32.46 |
| miha | well right now i use 80dpi | 15:33.56 |
| kens | Rather than using PDFSETTINGS I would tweak each setting individually. | 15:34.02 |
| Robin_Watts | miha: The stack overflow question you reference is producing pdf files, not pngs. | 15:34.06 |
| miha | Robin_Watts: sorry :( | 15:34.15 |
| kens | Using /screen will convert everything to RGB | 15:34.16 |
| kens | thinks htis may be why I am confused | 15:34.30 |
| ray_laptop | miha: unfortunately, gs doesn't multi-thread the PNG compression, so you parse+render a page to a bitmap, then PNG compress it, then go to the next page. By moving the PNG to another process, a separate CPU can do the compression | 15:34.36 |
| miha | right now i'm using -q -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r80x80 | 15:34.45 |
| | and then imagemagick for thumbnail | 15:34.51 |
| Robin_Watts | What does imagemagick do? | 15:35.06 |
| | Are you scaling down? | 15:35.08 |
| miha | Robin_Watts: yes | 15:35.12 |
| kens | suspects the ImageMagick is the slow part | 15:35.15 |
| Robin_Watts | Well, I suspect you'd do better using mudraw to go direct from pdf to thumbnail. | 15:35.35 |
| ray_laptop | miha: do you want a constant size thumbnail ? | 15:35.39 |
| miha | ray_laptop: yes | 15:35.44 |
| kens | Set width and height nad then use PDFFitPage | 15:36.10 |
| miha | kens: how? | 15:36.20 |
| Robin_Watts | So, what size thumbnail ? | 15:36.21 |
| kens | So that the PDF is scaled to the required size | 15:36.24 |
| miha | height 70px | 15:36.31 |
| | and maintain ratio? | 15:36.35 |
| kens | miha on the command line | 15:36.35 |
| ray_laptop | miha: then use gs -sDEVICE=png16m -o thumbs-%d.png -g70x70 -dPDFFitPage in.pdf | 15:36.56 |
| kens | miha did you ask this question on Stack Overflow ? | 15:37.02 |
| miha | kens: no | 15:37.07 |
| Robin_Watts | mudraw -h 70 -o thumb%d.png input.pdf | 15:37.08 |
| miha | Robin_Watts: not sure if mudraw is installed? | 15:37.25 |
| Robin_Watts | MuPDF will give vastly better thumbnails than that gs line, because mupdf does antialiasing. | 15:37.59 |
| ray_laptop | miha: the -g___x___ sets the width and height of the "page" produced | 15:38.02 |
| Robin_Watts | miha: easily fixed :) | 15:38.05 |
| | ray_laptop: And damn the aspect ratio! :) | 15:38.20 |
| miha | Robin_Watts: i guess but i'm not root :) | 15:38.29 |
| ray_laptop | Robin_Watts is correct that mupdf will do anti-aliasing faster than gs. | 15:38.35 |
| Robin_Watts | miha: You only need to be root to install it for other people. | 15:38.49 |
| ray_laptop | Robin_Watts: no, PDFFitPage does not distort the aspect ratio of the image -- it just centers it on the page | 15:39.00 |
| Robin_Watts | stands corrected, sorry. | 15:39.12 |
| ray_laptop | if the -g is not symmetric (as with -g61x79) then -dPDFFitPage will rotate for the 'best fit' and center | 15:40.05 |
| | Robin_Watts: does mupdf do 'pngalpha' equivalent (transparent background) ? | 15:41.22 |
| Robin_Watts | There is a -a flag: -a save alpha channel (only pam and png) | 15:41.53 |
| ray_laptop | miha: if you are using gs, then -dTextAlphaBits=4 -dGraphicsAlphaBits=4 is useful for anti-aliasing (that mupdf does by default) | 15:42.12 |
| | miha: I recommend that you benchmark your files on both mupdf and gs to see which you like better (performance and quality), but mupdf might be faster | 15:43.26 |
| rianu | I'm looking at having MuPDF draw to an R5G6B5 bitmap... is just adding a colorspace a good way to do this? | 15:44.18 |
| Robin_Watts | no. | 15:44.39 |
| rianu | I'm also concerned about whether converting that way would increase render time | 15:44.46 |
| ray_laptop | yuck. | 15:44.47 |
| Robin_Watts | MuPDF has a set of (for lack of a better name) plotters, that know how to render in various different modes. | 15:45.16 |
| rianu | But it looks like everything gets copied from a different bitmap to the final one anyway | 15:45.27 |
| Robin_Watts | We can render to 8bit greyscale, or to 888 rgb. | 15:45.42 |
| ray_laptop | rianu: do you want it halftone dithered down to that number of bits or just 'closest color in the palette' ? | 15:45.42 |
| rianu | Sorry, I'm on my phone (work blocks IRC) | 15:46.01 |
| | Closest color would be fine | 15:46.22 |
| Robin_Watts | You could add a whole new set of plotters for 565, but 1) that's not just a simple case of adding a new colorspace, 2) that will mean redoing all the blending logic. | 15:46.38 |
| ray_laptop | that's going to look pretty bad. | 15:46.40 |
| chrisl | Shyren: Just a thought - I'm getting reasonable results with: -r300 -sColorModel=CMYK -sIntensityRendering=Floyd-Steinberg -sDEVICE=hpdj1120c | 15:46.56 |
| Robin_Watts | Much better to render to 888 and then convert down. | 15:46.57 |
| | rianu: Nothing should be 'copied' unless there are transparency groups involved. | 15:47.31 |
| | When you convert down you are free to dither if you want (though, IME, 565 ain't bad) | 15:47.57 |
| ray_laptop | Robin_Watts: any kind of gradient or soft mask is going to show pretty bad mach bands | 15:48.46 |
| Robin_Watts | Picsels software runs in 565 all the time, even on 888 screens, and no one complained :) | 15:49.17 |
| ray_laptop | Robin_Watts: particularly in shades of gray where you will be constrained by 5 bits of blue to 32 levels | 15:49.39 |
| Robin_Watts | (yes, it's not ideal) | 15:49.39 |
| | yup. 565 has well known 'pink' problems in it's greys. | 15:49.59 |
| rianu | Ok, I'll have to run some benchmarks and see if that helps its... both our transfer to video memory and CPU memory access are pretty bad | 15:50.40 |
| Robin_Watts | Well... you can't be rendering direct to video memory,right? | 15:51.23 |
| | because then you'd get horrible effects as the page paints. | 15:51.36 |
| rianu | Trying to help the video memory problem without hurting the CPU | 15:51.42 |
| Robin_Watts | So you must paint once, then copy to the video memory at the end. | 15:51.53 |
| rianu | Correct | 15:52.05 |
| Robin_Watts | So that copy might as well be a conversion step. | 15:52.10 |
| | Which means, the question is, does the work of packing into 565 cost more at rendering time than the extra hit of writing to 888? | 15:53.05 |
| rianu | Yeah, exactly | 15:53.33 |
| Robin_Watts | and I strongly suspect that the simplicity of 888 will outweigh the extra bandwidth hit. | 15:53.41 |
| | You're on an ARM of some kind? | 15:53.48 |
| rianu | Yes | 15:53.54 |
| ray_laptop | hi, mvrhel | 15:54.12 |
| mvrhel_laptop | good morning ray_laptop | 15:54.25 |
| Robin_Watts | Well, you have the write buffer to help with the extra memory hit there. I suspect 888 will win. | 15:54.53 |
| rianu | Ok, I'll give it a try. Thanks for the help! | 15:56.58 |
| Robin_Watts | np. | 15:57.03 |
| henrys | Robin_Watts:I think you first told me about game of thrones? did you see the SNL skit http://gawker.com/5902076/snl-explains-the-nudity-in-game-of-thrones? | 15:57.13 |
| | oh no 3 minutes of a meeting. | 15:57.59 |
| Shyren | chrisl: -r300 -sColorModel=CMYK -sIntensityRendering=Floyd-Steinberg -sDEVICE=hpdj1120c printer doesn't print anything at all and passes the paper through | 15:58.25 |
| Robin_Watts | They've absolutely nailed George R R Martin :) | 15:58.28 |
| chrisl | Shyren: you could try: -r300 -sColorModel=CMYK -sIntensityRendering=printer -sDEVICE=hpdj1120c | 15:59.21 |
| henrys | meeting time. | 16:02.12 |
| kens | yep | 16:02.40 |
| Shyren | chrisl: same result :( I am recompiling with your latest patch | 16:02.55 |
| henrys | I didn't really have much other than alexcher's contentious bug - I think we should do something about it - marcosw has provided so many implementations that do it correctly. | 16:03.10 |
| marcosw | You mean 690797? | 16:03.21 |
| chrisl | henrys: we do it correctly | 16:03.25 |
| kens | 'correctly' is dubious | 16:03.25 |
| marcosw | Oops, I meant http://bugs.ghostscript.com/show_bug.cgi?id=692956 | 16:03.39 |
| kens | And synthesising an appearance stream is non-trivial | 16:03.43 |
| henrys | 692968 yes? | 16:04.01 |
| kens | marcosw:http://bugs.ghostscript.com/show_bug.cgi?id=692968 | 16:04.31 |
| marcosw | sorry, cut and paste error^2 | 16:04.52 |
| Robin_Watts | Are there any viewers in the list of "do it correctly" that don't offer form filling ? | 16:05.24 |
| kens | chrisl did you try Jaws and Harlequin ? | 16:05.46 |
| alexcher | henrys: we can handle this case. I'm going to check what annotations we can render from the data and do this first, before checking for the default appearance. | 16:05.47 |
| henrys | xpdf doesn't do form filling afaik. | 16:06.02 |
| paulgardiner | I assume it's not a text widget? If it were, I may have fixed it. | 16:06.06 |
| Robin_Watts | OK. | 16:06.10 |
| chrisl | Robin_Watts, kens: Harlequin renders it as intended, Jaws does it as we do | 16:06.18 |
| kens | paulgardiner : its Ghostscript, not MuPDF | 16:06.19 |
| Robin_Watts | paulgardiner: Both gs and mupdf show the problem. | 16:06.25 |
| henrys | alexcher:okay | 16:06.27 |
| paulgardiner | :-) Oops! | 16:06.30 |
| ray_laptop | alexcher: only do it as an option, right ? | 16:06.34 |
| kens | chrisl I was sure about Jaws, I'm surprised by HQn | 16:06.38 |
| marcosw | Robin_Watts: I think they all do form filling. | 16:06.40 |
| kens | Harlequin doesn't | 16:06.47 |
| chrisl | kens: it'll be the same us - customer says "sod the spec, do it like Acrobat"....... | 16:07.08 |
| kens | Personally I agree with Chris's comment in the bug, Acrobat is demonstrably wrong | 16:07.15 |
| ray_laptop | it seems sort of wrong to me to ignore a AP stream if it is there | 16:07.21 |
| alexcher | ray_laptop: I thought we strive bor Acrobat compatibility. | 16:07.28 |
| kens | I think we should raise this as a bug with Adobe. | 16:07.29 |
| alexcher | ray_laptop: I thought we strive for Acrobat compatibility. | 16:07.37 |
| ray_laptop | alexcher: I heard you the first time | 16:07.53 |
| | :-) | 16:07.55 |
| kens | ray_laptop : if youread Chris's bug comment, teh spec is clear that the appearance should take precedence if present | 16:07.58 |
| ray_laptop | kens: which is what we are doing (and nobody else does), right ? | 16:08.36 |
| kens | ray_laptop : correct | 16:08.46 |
| marcosw | If someone wants to create a test file that uses an appearance stream that Acrobat renders demonstratively wrong I'll submit it to Adobe, however if I submit this file and say that the $ is wrong and it should be a thorn and a ÿ they'll laugh at me. | 16:08.49 |
| chrisl | marcosw: I've attached one to the bug | 16:09.14 |
| kens | marcosw I'm sure we could arrange such a file, but I still think this file is usable as a demonstration | 16:09.24 |
| ray_laptop | of course the fact that the appearance stream is bad in this case (with the unicode string) does present an issue | 16:09.24 |
| alexcher | kens: this is a bug in the spec that has not been fixed yet. | 16:09.26 |
| kens | alexcher :-) | 16:09.34 |
| | I suspect that is exactly how Adobe will 'fix' it. | 16:09.47 |
| | Or woudl if it wasn;'t in the ISO spec :-) | 16:09.54 |
| ray_laptop | kens: are you looking at Adobe's 1.7 spec, or the ISO spec ? | 16:09.58 |
| chrisl | ray_laptop: I quoted the ISO spec | 16:10.10 |
| kens | ray that was the 1.7 spec, I'll check the ISO one | 16:10.11 |
| | Oh, well there you go | 16:10.17 |
| ray_laptop | chrisl: thanks | 16:10.20 |
| chrisl | ray_laptop: and the revised test file I attached to the bug has both strings valid single byte strings, but with different contents | 16:11.17 |
| paulgardiner | I think I've read something recently in the spec that appearance streams should be regenerated if there is a MK dict present. I may have that wrong. I'll see if I can find it. | 16:11.23 |
| Robin_Watts | I have a couple of things for the meeting (but low priority after everyone else has gone first) | 16:11.46 |
| kens | I have nothing | 16:12.09 |
| henrys | I'm done meeting wise. Anybody else? | 16:12.15 |
| marcosw | chrisl: your attachment renders correctly in Acrobat, I need an example that is obviously wrong in acrobat because it's ignoring the appearance stream. | 16:12.16 |
| mvrhel_laptop | I have nothing. | 16:12.16 |
| chrisl | marcosw: compare it to our output | 16:12.34 |
| kens | marcosw it *is* wrong | 16:12.41 |
| marcosw | I can't file a bug with Adobe saying that Acrobat is wrong because it doesn't agree with Ghostscript. It has to to be OBVIOUSLY wrong. | 16:13.17 |
| henrys | marcosw:we are trying to report Acrobat does not match the words in the spec. | 16:13.30 |
| kens | marcosw it can't be *obviously* wrong. | 16:13.31 |
| | Its wrong because the rendering does not match the appearance stream | 16:13.45 |
| marcosw | Our output is obviously wrong (a thorn and a ÿ are not valid currency symbols). | 16:14.00 |
| kens | Yes, but they are valid text | 16:14.11 |
| | How do you know that wasn't the intention ? | 16:14.20 |
| chrisl | paulgardiner: Acrobat (in this case, at least) is "synthesising" the content stream, regardless of the existence of the MK entry | 16:14.22 |
| ray_laptop | just modify the Td values to right justify above the underline (I think Acrobat left justifies) | 16:14.43 |
| chrisl | marcosw: *my* test file doesn't show a thorn and a ÿ | 16:14.44 |
| alexcher | marcosw: Let's check what effect "/NeedAppearances false" has on the file. | 16:14.46 |
| marcosw | kens: because a thorn and a ÿ are not used as currency symbols and a $ is. | 16:14.46 |
| kens | marcosw but you are assuming it should be a $ | 16:14.58 |
| | I say you are wrong and the originator intended a thorn and ydieresis | 16:15.11 |
| marcosw | kens: I'm glad you didn't write the spell checkers used in modern computers ("How do you know that lsdaflsjas isn't a valid word?"). | 16:15.40 |
| paulgardiner | chrisl: oh ok. Thought it probably wasn't relevant, but mentioned it just in case. It's in the implementation notes somewhere. | 16:15.41 |
| kens | marcosw my point is tha tyo uare making assumptions about the content. | 16:16.02 |
| | You can't know that the $ was correct. | 16:16.10 |
| chrisl | paulgardiner: you could well be right, of course, about what the spec says...... | 16:16.12 |
| kens | In the case of our file, the content should be what we say it is | 16:16.23 |
| alexcher | kens: It's unicode string rendered with a Type 1 font. | 16:16.36 |
| marcosw | yes, I'm making assumptions that thorn and ÿ aren't currency symbols. Which I can back up with evidence (i.e. google.com). | 16:16.43 |
| henrys | so marcosw wants us to demonstrate the problem with sensible symbols - that shouldn't be hard rigth? | 16:16.51 |
| kens | marcosw that's not my point. | 16:17.01 |
| | You cannot be certain that a currency symbol was intended. (I don't disupute that it was) | 16:17.28 |
| henrys | sensible meaning the document doesn't look like it has a typo, is that it? | 16:17.28 |
| paulgardiner | Ah it's Page 1118 anyway | 16:17.39 |
| marcosw | If we displayed a ¥ I wouldn't as convinced that we are wrong (that's supposed to be a yen symbol, just in case IRC has trouble with it). | 16:17.42 |
| kens | My point isn't that the file is displayed 'not as intended' | 16:18.06 |
| chrisl | marcosw: how do we programmatically tell that we're rendering a currency value? | 16:18.17 |
| kens | Its that you cannot produce a file which is 'wrong' for Adobe. | 16:18.18 |
| | Adobe will just say that it must have been intended that way. | 16:18.52 |
| marcosw | chrisl: I'm not sure, but two of the 6 programs that render a '$' are open source, so presumably someone could look | 16:18.59 |
| kens | thinks this is besdide the point | 16:19.17 |
| Robin_Watts | OK. So first thing: most (i.e. all except for a vanishingly small number) of the mupdf 'indetermisms' are down to the fact that macpro jobs differ from the other cluster nodes. It looks like this is down to tiny differences in the results of the sinf function. One way around this is to implement our own sinf function in the code. I've got code here that works. The question is, should I... | 16:19.20 |
| | ...enable this just for cluster tests? It seems a shame to have 'cluster only' code, but not as much of a shame as having indeterminisms. | 16:19.22 |
| kens | We can use either file to report a bug | 16:19.23 |
| chrisl | marcosw: they're not making a judgment on whether the AP content it correct, they're not even looking at the AP content..... | 16:19.45 |
| kens | Robin_Watts : what is hte performance like ? | 16:20.24 |
| marcosw | chrisl: and if we ignore the AP content the file will render as the user expects? | 16:20.33 |
| kens | If its as good as the C run-time (or close) I would always use it | 16:20.47 |
| | marcosw no | 16:20.54 |
| henrys | kens, chrisl: I think what marcosw is saying is the output should look plausible so it gets past the first wall of support which seems quite reasonable. | 16:20.57 |
| Robin_Watts | kens: I don't know. I'd like to think that sinf will be pretty well optimised in most libs. | 16:20.59 |
| alexcher | marcosw: Yes, if AP is removed gs renders the file correctly. | 16:21.05 |
| chrisl | marcosw: we also have to "invent" a valid content stream. | 16:21.06 |
| kens | alexcher but this may not always be the case? | 16:21.32 |
| chrisl | henrys: well, as I have repeated a few times - I have attached a test file to the bug which can show the problem - but I probably need to revise it a little based on what paulgardiner pointed out | 16:22.13 |
| alexcher | kens: first, we need to test this on the cluster. | 16:22.39 |
| kens | Robin_Watts : if your code is 'close enough' in performance, I woudl say use it always | 16:22.43 |
| Robin_Watts | I'm tempted to enclose the new code in #ifdef LOCAL_TRIG_FNS and then -DLOCAL_TRIG_FNS in the cluster compile. | 16:22.58 |
| ray_laptop | I modified the test file to right justify (and fix) the AP stream, Adobe renders it left justified | 16:23.01 |
| Robin_Watts | kens: I can't guarantee that my code will always be "close enough" in speed on all platforms. | 16:23.29 |
| alexcher | kens: second, unsupported cases like XML widgets will continue to use DA. | 16:23.30 |
| chrisl | ray_laptop: my test file has different figures in the two lots of content | 16:23.51 |
| henrys | I'd rather use the platform in the wild and have special cluster code. | 16:23.52 |
| kens | ceases to care about annotations | 16:23.54 |
| Robin_Watts | henrys: I think I'm with you. | 16:24.07 |
| | marcosw: Can we make the cluster build mupdf with an extra define please? (like -DCLUSTER or something?) | 16:25.01 |
| marcosw | Robin_Watts: for the make? sure. | 16:25.19 |
| Robin_Watts | Then I can make CLUSTER -> LOCAL_TRIG_FNS internally. | 16:25.29 |
| marcosw | I may have missed part of this, but why are we running different code on the cluster than in the production build? | 16:26.37 |
| Robin_Watts | marcosw: read back a bit :) | 16:26.55 |
| henrys | marcosw:wasn't there another "problem" bug? | 16:27.26 |
| marcosw | I didn't read back far enough, it's the sinf bug? | 16:27.36 |
| Robin_Watts | marcosw: yes. | 16:27.42 |
| marcosw | not bug, difference between macpro and other nodes. | 16:27.52 |
| Robin_Watts | yes. | 16:27.58 |
| marcosw | Gemma is asking about the bug that mvrhel_laptop is working on. | 16:28.15 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692961 | 16:28.48 |
| Robin_Watts | My second point was about the meeting. I'm assuming that no one other than henrys/sabrina/scott/rebecca will be coming to sunday dinner? You're all welcome, but I need to know for numbers. | 16:29.08 |
| marcosw | Robin_Watts: I'm not flying in until Monday morning, so no Sunday roast for me :-( | 16:29.34 |
| mvrhel_laptop | marcosw: I am working as fast as I can on this. The issues that this change causes are complex. I am down to the final 10% which takes 90% of the time | 16:29.40 |
| henrys | marcosw:I meant bugs we need to discuss because we disagree if they should be fixed. | 16:30.16 |
| mvrhel_laptop | There really are only a handful of files that have rendering issues, but they are pattern/clist issues | 16:30.28 |
| | It is possible if things went well that I could have it wrapped up this week, but I would tell Gemma next week | 16:31.05 |
| marcosw | mvrhel_laptop: I know, it's a complicated issue. The problem was that you (or maybe me) underrepresented the difficulty in an earlier email so their expectations are that's it should be done (two weeks ago you said it was fixed and just needed to be cluster tested). | 16:31.17 |
| mvrhel_laptop | well, yes. her file runs fine | 16:31.33 |
| | the cluster testing was insufficient that we had in place | 16:31.47 |
| | once we added the 300dpi it showed the clist issues | 16:31.58 |
| | with patterns | 16:32.01 |
| Robin_Watts | And finally, I mentioned the idea of clay pigeon shooting on the monday if people were interested, but I'm guessing that those of you that are here would rather do touristy things? | 16:32.15 |
| marcosw | mvrhel_laptop: yes, and I've explained (some of) this to them, but they still want it fixed sooner rather than later :-) | 16:32.38 |
| henrys | Robin_Watts:best not to arm US citizens you never know... | 16:33.10 |
| Robin_Watts | Dick Cheney has already ruined all new shotguns :( | 16:33.31 |
| marcosw | henrys: there was another new bug, but I think it was resolved, hold on an I'll check while you guys discuss fox hunting and the like. | 16:33.36 |
| mvrhel_laptop | marcows: right. I understand. I don't know what else to say other than that I do believe our testing is now sufficient that I can find all the issues | 16:33.43 |
| | And that the remaining issue that was just found on Friday is going to take a least 2 weeks to finish | 16:34.11 |
| Robin_Watts | s/remaining/latest uncovered/ :) | 16:34.29 |
| marcosw | mvrhel_laptop: I'm just asking for an update, not suggesting that you aren't working actively on the problem or that it's not a hard issue to fix. | 16:34.41 |
| mvrhel_laptop | of course next week I am at the open printing summit.... | 16:34.55 |
| marcosw | mvrhel_laptop: is that in San Francisco again? | 16:35.17 |
| mvrhel_laptop | marcosw: it is in cupertino at Apple | 16:35.27 |
| Robin_Watts | The obvious location for anything "open". :/ | 16:36.34 |
| marcosw | mvrhel_laptop: are you presenting? If so I'll come by and ask some hard questions :-) | 16:36.53 |
| | henrys: I believe the other new bug is http://bugs.ghostscript.com/show_bug.cgi?id=692982 but that has been dealt with. | 16:37.26 |
| mvrhel_laptop | Yes. I think on Wednesday. Which I need to get that material together some time. | 16:37.29 |
| henrys | marcosw:yes that was the one I was trying to recall. | 16:38.05 |
| | anyway I guess we can call the meeting sorry to go over. | 16:39.33 |
| kens | NP | 16:39.44 |
| henrys | Robin_Watts:looking at the weather for the UK trip looks a bit cold and damp... | 16:40.50 |
| kens | might be, might be better by then | 16:41.04 |
| Robin_Watts | Rained this morning, then was lovely. | 16:41.05 |
| kens | can't tell with UK weather | 16:41.18 |
| | But bring a coat | 16:41.22 |
| Robin_Watts | yeah. | 16:41.26 |
| henrys | I was hoping to keep up my running while I'm there, but we'll see. | 16:41.46 |
| kens | You don't run in the rain ? | 16:42.05 |
| henrys | I do yes, but it's hard to do long runs in hard rain. | 16:43.01 |
| Robin_Watts | It won't be hard rain, it'll just be drizzle. | 16:43.24 |
| | (probably) | 16:43.36 |
| | I need to mail miles and ask him to get me a room on the monday night, I think. | 16:45.05 |
| kens | I was planning on coming over on Tuesday morning | 16:45.26 |
| miha | tried mudraw locally, indeed it's faster. will talk to admin :) | 16:45.31 |
| | thx | 16:45.37 |
| marcosw | mvrhel_laptop: can you send me an email (or add a comment to bug 692961) mentioning what the remaining issue is? I'd like to have something to tell Gemma other than "we are still working on fixing a bug with the new code". Also, is the remaining issue something that will affect them? I know sending out software with known bugs is wrong, but if the problem only occurs with corner cases that they don't care about... | 16:45.41 |
| Robin_Watts | That way I can come down monday rather than trying to do it early tuesday morning (and I can bring henrys luggage) | 16:45.42 |
| mvrhel_laptop | macosw: ok. let me go ahead and add the update on the bug. Perhaps if I can get things back together somewhat by the end of this week we could get them a snap shot but I am not going to promise or even mention that | 16:47.24 |
| kens | Well, I have to go, goodnight all | 16:48.18 |
| henrys | bye kens. | 16:48.26 |
| ray_laptop | bye, kens | 16:48.27 |
| marcosw | should we start complaining about the internets at the hotel now or wait until we get there? | 16:48.31 |
| mvrhel_laptop | bye kens | 16:48.32 |
| marcosw | bye kens | 16:48.37 |
| | darn, too late. | 16:48.45 |
| Robin_Watts | Presumably alexcher won't be bringing his big bag o'cables. | 16:48.54 |
| ray_laptop | you have to be quick with kens | 16:48.58 |
| henrys | Robin_Watts:so Helen can't come to the meeting? | 16:49.05 |
| marcosw | Robin_Watts: alexcher would have to bring metric cables. | 16:49.21 |
| henrys | to the Holiday Inn that is. | 16:49.22 |
| Robin_Watts | She's teaching on monday in London (I believe the plan is that she will travel in with you on the train on monday morning). | 16:49.58 |
| | And I'm sure you don't want to cart your luggage around london all day, so I'll bring it to the hotel. | 16:50.19 |
| chrisl | Robin_Watts: I've got a load of mains multi-plugs and an extension lead - if we make up a list of stuff we might need, I'm sure we can scrape enough together. | 16:50.27 |
| Robin_Watts | Someone needs to be home monday night to look after doggies. | 16:50.38 |
| henrys | Robin_Watts:yes that is great. thanks a lot. | 16:50.47 |
| ray_laptop | oh, that's right -- I need to bring my power converter (which I have to find) :-( | 16:50.53 |
| alexcher | Most of us have American plugs and laptops that accept 220V. | 16:50.56 |
| chrisl | Ooh, hail stones...... | 16:51.02 |
| | Right, I'm off, too - g'nite! | 16:52.08 |
| Robin_Watts | Unless you all have US -> UK plug adapters, it may be worth someone bringing a small US extension strip. | 16:52.34 |
| alexcher | I will. | 16:52.54 |
| Robin_Watts | Then we can plug that into an adapter and run it at 220V. | 16:52.58 |
| | 240V even. | 16:53.17 |
| | So, marcosw: Do you want to pick a symbol to define for cluster jobs ? | 16:55.10 |
| marcosw | My son is going on a class trip to Japan next month and at the parents' meeting last night they mentioned that US plugs work in Japan except that Japanese outlets don't accept grounded plugs. Someone asked a follow-up question as to where they could buy a Japan -> US voltage adapter :-) | 16:56.39 |
| | I'm happy with CLUSTER, which someone suggested earlier. | 16:57.53 |
| Robin_Watts | cool. thanks. can you let me know when that's in? | 16:58.11 |
| marcosw | assuming I just need to 'nice make -DCLUSTER' it's in now. | 16:58.46 |
| mvrhel_laptop | marcosw: ok comment made on the bug. hopefully that will reset their expectation | 16:58.51 |
| marcosw | mvrhel_laptop: thanks. btw, I registered for open printing for Wed, so I'll probably see you then. | 16:59.27 |
| mvrhel_laptop | cool. | 16:59.33 |
| | Miles may come down for Dinner. I need to send him an email | 16:59.49 |
| | maybe we can take tkamppeter out for dinner that night | 17:00.04 |
| marcosw | Robin_Watts: no, that's not right.... | 17:00.33 |
| Robin_Watts | marcosw: CFLAGS="-DCLUSTER" ? | 17:00.51 |
| mvrhel_laptop | ok. now back to strip tiling fun | 17:01.18 |
| marcosw | that sounds like it, but the cluster makefile obscures the command being based to gcc, so it's hard to tell. | 17:01.40 |
| Robin_Watts | FunFunFunFunFunFun | 17:01.40 |
| | unFunFunFunFunFunF | 17:01.42 |
| marcosw | ^based^passed^ | 17:01.56 |
| tkamppeter | mvrhel_laptop, which night? | 17:02.16 |
| mvrhel_laptop | tkamppeter: Wed. night | 17:02.31 |
| tkamppeter | OK, I would join. It is you and marcos? | 17:02.48 |
| mvrhel_laptop | tkamppeter; Miles may come and join us | 17:03.10 |
| | recall we ate with him last year | 17:03.22 |
| | and marcosw will be there | 17:03.33 |
| tkamppeter | mvrhel_laptop, great. | 17:03.49 |
| marcosw | mvrhel_laptop and tkamppeter: I won't be able to make dinner, my wife is out of town so I have to pick the kids up from school. | 17:04.14 |
| mvrhel_laptop | marcosw: ok | 17:04.32 |
| tkamppeter | marcosw, mvrhel_laptop, you both will be on the Summit? | 17:04.45 |
| marcosw | tkamppeter: I just signed up for Wed, to see mvrhel_laptop's talk on color. | 17:05.19 |
| Robin_Watts | marcosw: Youtube. | 17:05.34 |
| marcosw | it's the only way I can keep up with the changes he makes to Ghostscript :-) | 17:05.35 |
| mvrhel_laptop | tkamppeter: so I arrive Tuesday evening, I am there for all day Wed, and then I have to fly back Thursday afternoon | 17:06.04 |
| marcosw | tkamppeter: if there is a reason for me to attend I can be there the other days, at least through the afternoon. | 17:07.02 |
| tkamppeter | mvrhel_laptop, we have a 3-hour color management session on Wed, if we do not get it filled up we could perhaps use the rest to talk about Ghostscript. | 17:07.53 |
| marcosw | Robin_Watts: are you suggesting I can see mvrhel_laptop's talk on YouTube? | 17:08.17 |
| mvrhel_laptop | tkamppeter: ok how long do you want me to plan to talk? | 17:08.19 |
| Robin_Watts | marcosw: I'm suggesting you should record it and post it to youtube. | 17:08.36 |
| mvrhel_laptop | gawd no | 17:08.41 |
| tkamppeter | On Tuesday afternoon there is also a session which we have cancelled, marcosw, would you be there at Tue 2:15PM - 3:15PM? | 17:09.02 |
| mvrhel_laptop | tkamppeter: my plan was to go over color management in ghostscript. there have been a few changes since last year most notably the output intent work | 17:10.07 |
| tkamppeter | mvrhel_laptop, OK. This you will do in the session on Wed, as originally planned. | 17:10.48 |
| mvrhel_laptop | I can also talk about the current major projects going on in ghostscript right now | 17:10.48 |
| | tkamppeter: ok how long do you want me to talk? | 17:11.11 |
| | is anyone from the openicc group going to be there to present anything? | 17:11.34 |
| tkamppeter | mvrhel_laptop, marcosw, for general talk about GS (what's new, which problems we need to solve, ...) we ccan use said session on Tue and/or remaining time of the Color Management session on Wed. | 17:11.42 |
| mvrhel_laptop | tkamppeter: I think we push those to Wed with my stuff | 17:12.09 |
| tkamppeter | mvrhel_laptop, I do not have anyone coming, I hope on a presentation via call-in. | 17:12.13 |
| mvrhel_laptop | tkmappeter: ok. how many people have registered for Wed? | 17:12.42 |
| marcosw | tkamppeter: Tuesday afternoon is a bit awkward, I have to take drive my Son from school to fencing, so would need to leave by 3:00. | 17:12.45 |
| tkamppeter | I do not need the list of registered people, have to ask Mike Sweet. | 17:14.37 |
| mvrhel_laptop | ok just curious | 17:15.59 |
| | tkamppeter: how much time, should I plan to talk? | 17:16.08 |
| | oy: are you going to join in the open print summit next week? | 17:16.45 |
| | tkamppeter and I were just talking about having some openicc presence at the Wed. session | 17:17.11 |
| tkamppeter | mvrhel_laptop, the whole CM session is 3 hours, for you we should put 60 or 90 minutes perhaps. | 17:17.14 |
| mvrhel_laptop | tkamppeter: ok | 17:17.27 |
| | oy: It would be nice for you to do something about OpenICC | 17:17.57 |
| | ok adding in a high level version of strip_tile_rect is going to simplify stuff dramatically. thanks for Robin_Watts clever design in the planar memory device | 17:36.53 |
| Robin_Watts | marcosw: Why is my compile for mupdf on the cluster dying ? | 17:36.55 |
| marcosw | probably the -DCLUSTER :-( | 17:37.09 |
| mvrhel_laptop | s/thanks for/thanks to/ | 17:37.10 |
| Robin_Watts | mvrhel_laptop: Even a blind acorn can find a squirrel occasionally. Or something like that. | 17:37.59 |
| mvrhel_laptop | well you did well with this design | 17:38.11 |
| | cool. that worked in the non clist case and is much cleaner than what I had | 17:39.03 |
| | now on to the clist implementation | 17:39.10 |
| Robin_Watts | marcosw: I can't find a failed build log on peeves. | 17:39.28 |
| marcosw | Robin_Watts: has there been a change to the thirdpary libraries? I see the error: thirdparty/freetype-2.4.8/src/base/ftstream.c:627: error: expected declaration specifiers before 'FT_BASE_DEF' | 17:39.38 |
| mvrhel_laptop | marcosw: we may end up with good news for the customer yet | 17:39.47 |
| Robin_Watts | marcosw: Maybe it's the git cluster bridge that's broken. | 17:40.12 |
| | On henrysx6 there is no fitz-internal.h | 17:40.39 |
| mvrhel_laptop | of course this is now the clist part that I working on though so I should be careful with what I say | 17:40.56 |
| marcosw | the build logs are in ~marcos/cluster/peeves.log.gz | 17:41.04 |
| | Robin_Watts: odd, there may be something else strange going on with your mupdf clusterpush. give me a sec. | 17:44.22 |
| Robin_Watts | Oh, I've just done another one from peeves. | 17:44.37 |
| marcosw | Robin_Watts: tthat's okay. | 17:45.18 |
| | okay figured that out. the peeves.log.gz file only shows the last 50 lines of the make build. If you look at peeves.make that's the complete list of make errors. | 17:47.13 |
| | here is the first error on my i7: | 17:48.23 |
| | pdf/pdf_encoding.c:1:27: error: fitz-internal.h: No such file or directory | 17:48.25 |
| | In file included from pdf/mupdf-internal.h:4, | 17:48.26 |
| | from pdf/pdf_encoding.c:2: | 17:48.26 |
| | pdf/mupdf.h:4:18: error: fitz.h: No such file or directory | 17:48.26 |
| | In file included from pdf/mupdf-internal.h:4, | 17:48.26 |
| | from pdf/pdf_encoding.c:2: | 17:48.27 |
| Robin_Watts | How odd. | 17:48.50 |
| | They certainly exist here. | 17:49.00 |
| mvrhel_laptop | ugh. need yet another clist command | 17:50.40 |
| Robin_Watts | And on peeves. | 17:50.40 |
| | Ah. it's the CFLAGS thing. | 17:51.39 |
| marcosw | Robin_Watts: I agree, how odd. | 17:52.52 |
| Shyren | Is there anyway to modify hpdj340 device so it can support higher resolutions? | 17:52.58 |
| Robin_Watts | marcosw: Change it to be XCFLAGS="-DCLUSTER" :) | 17:56.29 |
| marcosw | done. | 17:57.01 |
| mvrhel_laptop | ok. I *think* I have this figured out. should not be too difficult | 19:05.06 |
| | but time for lunch now | 19:05.11 |
| yorke | hi, are any of the developers around? | 22:42.39 |
| Robin_Watts | yup. | 23:00.49 |
| | yorke: Yes. | 23:02.15 |
| yorke | I'm trying to create a multithreaded version of the Android MuPDF viewer | 23:04.04 |
| Robin_Watts | ok... | 23:04.26 |
| yorke | I've read the multithreaded example and changed just the call to fz_new_context to provide a set of mutexes | 23:04.27 |
| | but i get a bunch of segfaults even before i introduce any pthreads | 23:04.49 |
| Robin_Watts | You mean, you call fz_new_context with a lock/unlock structure, right? | 23:05.10 |
| yorke | yes, thats right | 23:05.21 |
| | with the lock/unlock functions as well as an array of mutexes | 23:05.34 |
| Robin_Watts | What array of mutexes? | 23:06.21 |
| | I mean, there should be an array of mutexes, but it doesn't have to be in that structure. | 23:06.41 |
| | (unless you put it in the user pointer or something) | 23:07.06 |
| yorke | yea its in the user pointer | 23:07.21 |
| Robin_Watts | ok. | 23:07.30 |
| yorke | i basically followed the example in multi-threaded.c step by step | 23:07.32 |
| Robin_Watts | Well, that should all be fine. | 23:07.34 |
| | At what point does it all fall in a heap ? | 23:07.52 |
| yorke | sorry, hang on a sec | 23:09.21 |
| | http://pastebin.com/wxNHcYk7 | 23:09.56 |
| | sorry, that's the best stack trace i could get | 23:10.15 |
| | the android ndk doesnt really provide too much information | 23:10.24 |
| | it says it's somewhere in pdf_count_pages | 23:10.45 |
| Robin_Watts | Yeah, that's not great. If it was me, I'd be adding some logging. | 23:13.53 |
| | If the only difference is the lock structure, then I'd suspect something in that area. | 23:14.45 |
| | Put some debug in fz_lock. | 23:14.54 |
| yorke | The lock and unlock functions (pthread_mutex_lock and unlock) seem to work fine, I've added logging in those functions and they show up. | 23:15.08 |
| | Ok I'll try that, thanks | 23:15.24 |
| | Do you think it could have something to do with the implementation of pthreads on Android? | 23:15.45 |
| Robin_Watts | It could do. | 23:16.06 |
| | but unless you're actually getting as far as taking/dropping a lock in your own locking functions, then it's more likely to be finger trouble. | 23:16.35 |
| yorke | The openFile function in the viewer actually completes successfully (and takes and drops a bunch of locks in the process) | 23:17.32 |
| Robin_Watts | yorke: I'm in the UK, so it's late here and I'm off to bed, but I'll be back in the morning, and will read the logs. | 23:17.33 |
| | let me know what you find. | 23:17.40 |
| yorke | sure thing, thanks a lot for your time | 23:17.41 |
| Robin_Watts | Interesting. I would have expected it to die on the first one if it was going to. | 23:18.06 |
| yorke | Yea I'm just curious why its failing in the fz_count_pages function (which I assume is single threaded). I'll add more logging once I get back to my machine and update you tomorrow. | 23:20.29 |
| | Forward 1 day (to 2012/04/18)>>> | |
IRC Logs