| | <<<Back 1 day (to 2012/06/27) | 2012/06/28 |
| Robin_Watts | marcosw: If you see this before I'm up and about in the morning... I see you backtracked in git history for the cluster to add the timing stuff. | 00:05.30 |
| | Can I put the mujstest stuff back in? | 00:05.38 |
| marcosw | Robin_Watts: The cluster code was on the master branch and I added the timing stuff to that. I presumed those changes will be merged with the mujstest changes at some point in the future, correct? | 02:03.20 |
| | mvrhel: ping? | 02:03.29 |
| mvrhel | marcosw: I am here now | 05:15.08 |
| marcosw | Any update on <http://bugs.ghostscript.com/show_bug.cgi?id=693048>? The customer is asking. | 05:24.08 |
| mvrhel | I am working on it this very second. | 05:24.26 |
| | I have 4 files that segv at 300dpi. | 05:24.37 |
| marcosw | that must mean you have hundreds that work, which seems good enough :-) | 05:25.01 |
| mvrhel | I have it pin pointed down to a screw up during the clist writing | 05:25.12 |
| | I am hopeful that this is the final issue | 05:25.26 |
| | but it is a tricky one | 05:25.30 |
| | I *really* want to get this done | 05:25.57 |
| | I am stepping right now watching the bytes go into the clist to see where it breaks | 05:26.35 |
| marcosw | I'll leave you to it then. And hopefully this will be the final issue... | 05:27.11 |
| mvrhel | I have been running the clusterpushes with aa on to see what explodes | 05:28.02 |
| | my wife got the go ahead to start driving today so hopefully I will be back to a normal schedule now | 05:29.46 |
| marcosw | that's good news. driving the kids around is a full time job by itself, at least in our family. | 05:30.45 |
| mvrhel | yes exactly | 05:30.55 |
| | oh weird | 06:12.30 |
| | I believe the way that I set up an extended command in the clist is prone to a very rare error | 06:15.02 |
| | and yes! that was the problem. that was a hard one to track down | 06:24.59 |
| | marcosw: so I am going to cluster push and we will see where we are | 06:25.18 |
| | ok the push was made. I am going to bed now. | 06:35.55 |
| | hopefully we will have some good news for the customer | 06:36.46 |
| ray_laptop | HURRAY !!! The data from the HD in my old laptop transferred over OK (using PCmover Image Assistant and NOT including any VS or Adobe CS3 apps). Now to see if it is stable | 06:58.22 |
| kens | Mayeb a good night's sleep first ? :-) | 06:58.40 |
| ray_laptop | (doesn't crash with BSOD or random reboot "Windows did not shut down correctly" (like Windoze always does the correct thing) | 06:59.13 |
| | kens: yep -- sleep (and leaving the laptop up) are on the agenda | 06:59.46 |
| kens | :-) | 06:59.54 |
| ray_laptop | If I left it up overnight, about 2/3 of the time it would have rebooted by the morning. | 07:00.24 |
| | The NICE thing is that CPUID reports 65 C max temp (was 99 if I was doing much of anything before). I will send the old one into Dell and hopefully it will be good after they clean out the guts | 07:01.55 |
| kens | Definitely sounds like a thermal problem | 07:02.13 |
| ray_laptop | kens: that's what I was hoping, so that's why I moved the old HD over to the new laptop. I didn't crash for about 3 days, but then it started the same (the old laptop also would have semi-stable periods) | 07:03.26 |
| | kens: so I had to be VERY selective as to what I transferred over. | 07:03.50 |
| | kens: AND, of course, I won't be confident until a week or more has gone by. | 07:04.21 |
| | At least I can get back to productive work again :-) | 07:05.03 |
| kens | Good to hear... | 07:05.12 |
| ray_laptop | and the new laptop is slimmer and lighter than the old one, and is i7 instead of i5 and 2.8 GHz instead of 2.2 GHz | 07:06.57 |
| | I only have a few more things that have to be re-installed (doing Adobe Photoshop CS3 now) | 07:08.05 |
| | oops. PhotoShop CS3 demands that I exit Firefox (and thus Chatzilla). | 07:11.03 |
| kens | bb ray_laptop | 07:11.11 |
| ray_laptop | see you later. | 07:11.13 |
| Robin_Watts | What a great PDF. It has a monochrome black and white image in it. Encoded as 16bpc RGB. | 11:06.38 |
| | tor8: Another patch for you on casper. | 11:10.22 |
| tor8 | Robin_Watts: fantastic pdf indeed :) patch looks good. | 11:13.35 |
| Robin_Watts | tor8: Could you spare some time to look at normal_177.pdf? | 11:17.31 |
| | It has a CMYK jpeg in it that comes out with the colors off in mupdf. | 11:17.47 |
| | I've tried fiddling with the decoding, but I'm damned if I can make it make sense. maybe another pair of eyes might help? | 11:18.18 |
| tor8 | Robin_Watts: I can't find it in the slow_web.zip archive | 11:18.55 |
| Robin_Watts | Other archive :) | 11:19.12 |
| | They sent 2 sets of files; problem ones and slow ones. | 11:19.37 |
| tor8 | ah, that one! | 11:19.40 |
| Robin_Watts | Also, normal_161.pdf is a fonty problem, so tor8/chrisl/kens may be in a better position to understand it than I do. | 11:22.24 |
| | When mupdf renders the file, we are missing an "alpha" glyph throughout the page. | 11:22.52 |
| | I'm guessing that's the only glyph used from the /Symbol,Italic font. | 11:23.07 |
| | The /Symbol font is embedded, but the /Symbol,Italic one isn't. | 11:23.20 |
| | gs manages to render it correctly. | 11:23.27 |
| | (for those interested, I've just committed the file to the test repo as tests_private/pdf/customer394/problems/normal_161.pdf) | 11:24.00 |
| tor8 | Robin_Watts: it may be related to how we handle the Adobe colortransform marker thing | 11:25.21 |
| Robin_Watts | tor8: I stepped through the code yesterday, and it all looked plausible. | 11:25.39 |
| | AIUI, Adobe inverts the sense of CMYK jpegs. | 11:25.54 |
| | but I inverted the sense in the color conversion, and it still looked wrong. | 11:26.12 |
| tor8 | Robin_Watts: swapped r and b channels perhaps? just by looking at the output | 11:27.21 |
| Robin_Watts | Anyone using the cluster at the moment? | 11:27.25 |
| | tor8: I think I tried that and it didn't help, but I may be misremembering. | 11:28.11 |
| kens | I've finished with the clustre for now | 11:30.08 |
| tor8 | Robin_Watts: well, gimp can't open the image either :) | 11:30.49 |
| kens | Gimp isn't good with CMYK | 11:31.12 |
| | Or wasn't, at least | 11:31.20 |
| tor8 | I can't find anything that reads CMYK jpegs | 11:31.23 |
| kens | Photoshop | 11:31.31 |
| Robin_Watts | PAINT.net ? | 11:31.34 |
| | but it doesn't look right either. | 11:31.44 |
| tor8 | paint shows it the same as IE, inverted and very very drak | 11:32.01 |
| | dark | 11:32.03 |
| Robin_Watts | But gs renders it correctly, I believe. | 11:32.04 |
| | I guess I could try and follow what gs is doing. | 11:32.56 |
| kens | Good luck :-) | 11:33.04 |
| Robin_Watts | yeah :( | 11:33.12 |
| | kens/chrisl: Does gs synthesise Italic fonts from non italic ones? | 11:35.17 |
| | Or is it just better at falling back? | 11:35.25 |
| | (I have a con-call with this company at 4pm ish and would like to have answers for at least the first few files in their archives) | 11:36.18 |
| tor8 | well, comparing gs and mupdf renderings side by side the blocking artefacts look a lot heavier in mupdf too | 11:36.53 |
| Robin_Watts | tor8: Within that image? | 11:37.08 |
| tor8 | yeah, the platforms in the circles on the right for instance. the rigging details are all blocky in mupdf. like the block-smoothing hasn't been run. | 11:38.06 |
| | or maybe it's just image interpolation done differently | 11:38.20 |
| Robin_Watts | tor8: mupdf and gs use exactly the same algorithm for image interpolation these days :) | 11:38.40 |
| | and the same jpeg lib. | 11:38.46 |
| tor8 | Robin_Watts: actually, that's a hint | 11:38.47 |
| | looking at the separate RGB channels on a screenshot in gimp | 11:39.01 |
| | the red channel has detail, the green and blue don't | 11:39.10 |
| | so I'm guessing it hasn't converted from Ywhatever to CMYK or RGB | 11:39.25 |
| | and left the Y channel in R and the chroma channels in MY or GB | 11:39.46 |
| Robin_Watts | The jpeg lib does spot the adobe marker. | 11:49.17 |
| | and in filt_dctd we hit the if (cinfo->saw_Adobe_marker) thing at line 134 | 11:50.04 |
| | but whether we end up with cinfo->Adobe_transform or not, we get bad results. | 11:50.31 |
| | sorry, whether we end up setting state->color_transform or not, we get bad results. | 11:50.52 |
| | Dammit. I'm going to have to look to see what gs does :( | 11:51.25 |
| chrisl | Robin_Watts: when doing substitution, gs will "generate" an oblique font | 11:52.06 |
| Robin_Watts | right, so if something asks for /Symbol,Italic, and it has /Symbol available, it will magically generate it ? | 11:52.34 |
| | (Sorry, I know my questions here are likely to be overly simplistic) | 11:52.46 |
| tor8 | Robin_Watts: if we just invert the default output from libjpeg we match IE and mspaint at least | 11:53.13 |
| | not the same as gs though... | 11:53.22 |
| chrisl | Yes, although not sure if that applies when the font (Symbol) was embedded | 11:53.22 |
| tor8 | Robin_Watts: and I've tried fiddling with setting cinfo->jpeg_color_space to every possible value and none make it much better | 11:53.49 |
| Robin_Watts | is the ",Italic" a standard convention? | 11:53.56 |
| chrisl | Robin_Watts: see Resource/Init/pdf_font.ps line ~1612 | 11:54.04 |
| Robin_Watts | i.e. is it something we should be doing in mupdf too ? | 11:54.14 |
| chrisl | Robin_Watts: that, and the font Flags | 11:54.17 |
| tor8 | Robin_Watts: yeah, it's a windows-ism I think | 11:54.21 |
| | Robin_Watts: but I believe that's a synthesis that you get from win32 if you open a font by that name, not something part of the pdf spec | 11:55.08 |
| Robin_Watts | Right, but gs has it built in. | 11:55.31 |
| chrisl | The ",Italic" thing is very common (enough for gs to use it) but not required | 11:55.43 |
| Robin_Watts | (including ",BoldItalic" "Light" ",Italic") | 11:56.05 |
| chrisl | Yes | 11:56.11 |
| Robin_Watts | Ok, so it's something we could consider adding maybe. | 11:56.28 |
| chrisl | The PS code for doing all that is pretty obvious - Resource/Init/pdf_font.ps - procedure /findCIDFont | 11:56.58 |
| Robin_Watts | boldening is tougher. | 11:57.18 |
| | Lightening even harder. | 11:57.44 |
| chrisl | I believe GS either scales the font slightly, or in other cases does fill/stroke for boldening | 11:57.58 |
| tor8 | Robin_Watts: pdf_load_system_font looks for "Italic", I think this may be related to another issue zeniko has filed a bug for | 11:58.08 |
| | Robin_Watts: bug 691570 | 11:58.29 |
| chrisl | Robin_Watts: I'm going to lunch (my parents here), look at /findCIDFont, it really is very obvious what it's doing..... | 11:59.27 |
| Robin_Watts | chrisl: Thanks. I'm not going to dive in before the con-call. The main thing is that I have answers to give them. | 11:59.57 |
| tor8 | Robin_Watts: we don't have Symbol,Italic built in, so we should hit pdf_load_system_font instead... | 12:00.15 |
| | but since it has no font descriptor... | 12:00.54 |
| Robin_Watts | Ok, visual C just died on me. I take that to be a good point to have lunch. bbs. | 12:03.57 |
| kens | is glad I'm nto the only on it does that oo | 12:04.26 |
| tor8 | Robin_Watts: fix for normal_161.pdf on tor/master | 12:35.39 |
| Robin_Watts | tor8: oh, cool, let me look.. | 12:48.28 |
| tor8 | Robin_Watts: not sure if it's the best solution, but I think it'll do. it's short and contained at least. | 12:48.54 |
| Robin_Watts | Yeah, nice one. | 12:49.03 |
| | looks good to me. | 12:49.14 |
| | tor8: actually if you haven't pushed it yet... | 12:51.38 |
| tor8 | Robin_Watts: running sane on it, so not pushed | 12:51.52 |
| Robin_Watts | put a reference to normal_161.pdf in the commit message, so we can see what prompted it when we look back in 3 years time :) | 12:52.05 |
| tor8 | Robin_Watts: can do | 12:52.18 |
| paulgardiner | Robin_Watts, tor8: New commit on paul/forms, when you get a moment sometime. | 13:23.17 |
| Robin_Watts | OK, the jpeg lib under gs is returning the data unprocessed. | 13:25.32 |
| | ie. we're getting 4 planes of data out where the middle 2 are decimated. | 13:26.09 |
| | (well, undecimated, if you follow what I mean) | 13:26.25 |
| | so presumably gs must be doing some conversion on the data itself. | 13:26.43 |
| tor8 | Robin_Watts: a manual conversion from YCCK to CMYK? | 13:28.12 |
| flmbray | anyone know of a freeware command line tool that can convert XPS to PDF? | 13:42.45 |
| kens | GhostXPS is open-source | 13:42.58 |
| | GPL | 13:43.01 |
| | However, tis a 'best effort' conversion, the smae as PCL | 13:43.14 |
| Robin_Watts | And if you have any problems with it, kens will just love to hear about them :) | 13:43.19 |
| kens | Absolutely, they can join the pile from tor8 | 13:43.35 |
| flmbray | GhostXPS appears to only provide source code, not binaries? Sorry I should have mentioned - looking for a windows binary. | 13:45.08 |
| kens | Its GPL so we are obliged to provide source. | 13:45.23 |
| | I've no idea if we provide binaries, I guess not | 13:46.03 |
| flmbray | understood... does it compile under VS2010? | 13:46.08 |
| kens | Yes, there is a VS project. | 13:46.20 |
| | It is known to work with VS Express | 13:46.32 |
| chrisl | flmbray: http://www.ghostscript.com/download/gxpsdnld.html | 13:46.39 |
| kens | :-) | 13:46.57 |
| | Was about to say I thought we provided binaries.... | 13:47.08 |
| flmbray | ah thanks | 13:47.36 |
| kens | I'm not aware of any other XPS->PDF converters, though that doesn't mena there aren't any | 13:47.40 |
| chrisl | It is just an execetable in a zip, it's not a full installer like the gs Windows distribution | 13:47.49 |
| kens | Mr Google also says: | 13:50.26 |
| | http://www.micre13b.com/xps-to-pdf-converter.html | 13:50.26 |
| | Hmm, not command line though | 13:51.14 |
| flmbray | chrisl: suggest a command line for gxps? | 13:52.54 |
| chrisl | flmbray: gxps -sDEVICE=pdfwrite -o output.pdf input.xps | 13:53.19 |
| kens | gxps -sDEVICE=pdfwrite -sOutputFile=out.pdf <input.xps> | 13:53.21 |
| flmbray | nice! thanks! | 13:54.31 |
| | BTW I did ask Mr Google... he gave me some pointers that led me here. :) | 13:55.53 |
| | i haven't used IRC in over 10 years... had to figure out how to do it. things have changed a lot. | 13:57.28 |
| | actually my math is bad... 20 years... early 90's | 13:58.08 |
| | just out of HS. we had to use unix green-screen terminals | 13:58.29 |
| | now i feel ancient | 13:58.46 |
| kens | :-) | 13:58.57 |
| | We had amber screens | 13:59.06 |
| chrisl | Those were the days - never been same since they got rid of green screen vt100s...... | 13:59.15 |
| Robin_Watts | tor8: actually, looking at the data I get out of jpeglib, it DOES look to be different between mupdf and gs. | 14:06.20 |
| tor8 | Robin_Watts: does it vary if you change the jpeg_color_space or out_color_space fields in cinfo? | 14:06.51 |
| | maybe should force out_color_space = jpeg_color_space and do it all manually? | 14:07.14 |
| Robin_Watts | gs manages not to. | 14:08.42 |
| | let me step through again, and try and figure out why gs and mupdf are getting different results. | 14:08.59 |
| | ok, so there are radical differences in the values output by the jpeg lib from mupdf and gs, in at least 2 of the planes. I wonder why (and how I missed that originally) | 14:21.48 |
| kens | Presumably we drive the library in different ways | 14:22.27 |
| Robin_Watts | kens: Yes, but having just stepped through both of them, I can't see how :( | 14:24.16 |
| kens | Sorry Robin_Watts not something I know anything about | 14:27.23 |
| henrys | Robin_Watts:I got the impression Scott would just have you at the meeting but I'm here if I can help. | 14:43.52 |
| Robin_Watts | henrys: That was my impression too, but thanks. | 14:44.18 |
| | mupdf uses a different idct routine to gs, and fancy upsampling -but even changing that to match I get different results out before the post process phase for 2 of the planes. VERY odd. | 14:45.23 |
| tor8 | Robin_Watts: different jpeglib versions? not that I think something as fundamental as that would change. | 14:46.40 |
| mvrhel | marcosw: I think 693048 is done. I will commit the fix in the next hour. bbiab | 15:22.03 |
| marcosw | mvrhel: great news. | 15:47.26 |
| Robin_Watts | off con-call. seemed to go well. | 15:49.32 |
| | They've made changes to mupdf that they'd like to feed back. | 15:53.41 |
| | some of which I suspect we'll like, others... not so much. | 15:54.03 |
| | but they seem prepared to move to 1.0 and feed us stuff back gradually which is good. | 15:54.20 |
| | kens: ping | 15:54.40 |
| kens | Robin_Watts : pong | 15:55.06 |
| Robin_Watts | they have various customers of theirs who want to produce PDFs specifically to be viewed on their devices. | 15:55.21 |
| kens | OK | 15:55.34 |
| Robin_Watts | hence they want to optimise those PDFs so that they render fast on mupdf. | 15:55.42 |
| | i.e. they want to use RGB images (rather than CMYK ones) | 15:55.53 |
| kens | Can't do that yet | 15:56.04 |
| Robin_Watts | and they want to avoid stupidly repetative clipping operations. | 15:56.10 |
| kens | Define 'stupidly repetetive ? | 15:56.28 |
| Robin_Watts | set a clip rectangle { set a clip rectangle { set a clip rectangle { draw a path } } } | 15:56.53 |
| kens | Hmm, I don't know what we do with that at the moment | 15:57.17 |
| Robin_Watts | Does anyone know of any PDF optimisers out there? | 15:57.37 |
| kens | OK we do honour ConvertCMYKImagesToRGB | 15:57.53 |
| Robin_Watts | I was thinking that gs/pdfwrite might not be a bad place to start with one. | 15:57.54 |
| kens | Many people use GS+pdfwrite as an 'otimiser' | 15:58.14 |
| | Not a lineariser though | 15:58.20 |
| Robin_Watts | ok, so that's a possibility. | 15:58.26 |
| kens | THat can be done with pdfopt.ps | 15:58.27 |
| Robin_Watts | Mupdf doesn't gain from linearisation. | 15:58.34 |
| kens | and in the longer term directly in pdfwrite | 15:58.39 |
| | OK so what (apart from RGB images and clipping) do they mean by optimisation ? | 15:59.05 |
| | If htey would like to send an example of the 'poitnelss clipping' I could take a look | 15:59.22 |
| | I suspect we omit it already but I'm not prepared to say without checking | 15:59.39 |
| Robin_Watts | kens: At the moment their question is "are there any optimisers we can use to make files go faster with mupdf?" and they gave me a stack of 'slow' files. | 15:59.42 |
| | I looked at the first file, and the obvious thing I could see was stupid clipping. | 16:00.04 |
| kens | I guess it depends what makes them slow :-P | 16:00.09 |
| Robin_Watts | indeed. | 16:00.16 |
| kens | OK well try passijng the files through pdfwrite and see what happens | 16:00.30 |
| Robin_Watts | will do, thanks. | 16:00.38 |
| kens | I can take a look at any of them if you want | 16:01.07 |
| Robin_Watts | I'll have a run at them tomorrow, thanks. | 16:01.38 |
| kens | NP feel free to ask questions | 16:01.47 |
| Robin_Watts | I do :) | 16:01.55 |
| | ahahahah. I see a problem with the jpeg lib. | 16:07.06 |
| ascheel | I'm converting a pdf to png using imagemagick and I'm running out of temporary directory space. 'man gs' says the TEMP environment variable changes which directory it uses for temporary files. I changed that variable to a different filesystem, but it appears to still use /tmp. I apologize if this is the wrong place for the question. | 16:08.15 |
| | I am asking here because it's a 'gs' error, but I'm not sure if it's an issue with gs ignoring TEMP or if imagemagick screws with it before passing it off to gs | 16:08.57 |
| chrisl | ascheel: what shell are you using? | 16:09.44 |
| ascheel | bash | 16:09.47 |
| chrisl | Did you remember to export the variable after changing it? | 16:10.05 |
| ascheel | creating the variable with 'export TEMP=/home/myuser/temp' | 16:10.20 |
| | ha... yeah, I got that. ;) | 16:10.26 |
| chrisl | OKay, just checking - it's a common omission...... | 16:10.42 |
| ascheel | but I think imagemagick may shell it out meaning it might not inherit TEMP in that case | 16:10.50 |
| | I guess it's time to hit up #imagemagick instead! | 16:11.01 |
| | I wanted to make sure I wasn't misunderstanding how gs worked. | 16:11.38 |
| chrisl | Your best bet would be call gs directly and remove a variable | 16:11.49 |
| ascheel | AH HA! It is imagemagick screwing up and not gs. | 16:11.56 |
| Robin_Watts | So, rillian made a fix to the jpeg lib, and it's never been taken on in the original. | 16:14.02 |
| kens | oh, interesting, and we've propogated it all this time ? | 16:14.43 |
| Robin_Watts | chrisl: Do you usually handle passing such fixes back to the authors, or should I do it? (I am happy to do it, but if there is company policy here...) | 16:14.49 |
| | evidently. | 16:14.51 |
| | Now I come to look at this, I am pretty sure I hit and fixed this case at my previous employer too. | 16:15.34 |
| kens | Oh god, PCL to PDF...again! | 16:15.55 |
| chrisl | Robin_Watts: I'd prefer you to pass it upstream, just in case questions come back | 16:18.01 |
| Robin_Watts | ok. | 16:18.06 |
| henrys | playing with siri on the iphone quit impressive not much to say about pcl->pdf though .. ;-) | 16:19.03 |
| kens | henrys could you take a quick look at the PCL file, maybe cut it down a bit ? There seem to be a lot pf pages... | 16:19.50 |
| henrys | will do you've confirmed the pdf is different than the pcl. | 16:20.31 |
| | ? | 16:20.32 |
| kens | Well teh PDF looks wrong and provokes an error in Acrobat | 16:20.46 |
| | I'm just rebuilding pcl.exe to try it ehre with latest code | 16:20.59 |
| | but I have to go shortly | 16:21.04 |
| ascheel | chrisl: problem fixed. I appreciate your time. Just in case someone else asks something similar... TMPDIR. | 16:22.10 |
| | but that's an IM thing, not gs | 16:22.16 |
| henrys | kens don't both I've got it. | 16:22.34 |
| | s/both/bother | 16:22.40 |
| kens | OK | 16:22.53 |
| | I will try it quickly | 16:23.01 |
| | since build is done | 16:23.05 |
| | 18 pages :-( | 16:23.22 |
| henrys | siri can tell me how many calories in a cup of milk - the voice recognition is quite good. I thought it would suck. | 16:23.49 |
| kens | current code produces a PDF which does not error | 16:23.53 |
| | but some text is misaligned | 16:24.02 |
| | Text which is missing in the customer PDF is present in the bleeding-edge code version | 16:24.32 |
| | So there are definite improvements over whatever version they are using | 16:24.44 |
| | I should set AutoRotatePages | 16:25.04 |
| | henrys pages 4-15 have mispositioned text | 16:26.27 |
| | aha | 16:26.49 |
| | henrys it renders the same as hte PDF otuptu :-) | 16:26.58 |
| | So 'not my problem'' :D | 16:27.08 |
| henrys | teach you to leave these things to marcosw! | 16:27.28 |
| kens | Yes, you're quite right.... | 16:27.42 |
| | anyway, got to go take Melanie rding bye all | 16:27.54 |
| Robin_Watts | henrys: Well, they throw heavy servers at it. | 16:46.32 |
| | The voice recognition isn't done on the phone; the phone just encodes the voice (using speex, I believe, cheeky bastards that Apple are) and then uploads it to servers to grind on it. | 16:47.13 |
| chrisl | ascheel: glad to hear it's working for you | 16:47.20 |
| henrys | it seems like it depends - there are some canned queries it knows right off - others it says "let me check for you"... | 16:48.13 |
| Robin_Watts | marcosw: ping | 16:49.43 |
| marcosw | Robin_Watts: I'm here about need to run out in 5 minutes. Do you have a quick question? | 16:59.24 |
| Robin_Watts | You backed out the mujstest stuff from the cluster when you added the timing stuff. | 16:59.46 |
| | can I put it back ? | 16:59.51 |
| marcosw | I switched back to the master branch; is that what you mean? | 17:00.55 |
| Robin_Watts | yes, | 17:01.04 |
| | I'd like to rebase my changes on top of master, and then swap back to my branch. | 17:01.17 |
| marcosw | Sounds good to me. Have at it.... | 17:01.28 |
| Robin_Watts | thanks. | 17:01.33 |
| | Is there an "ideal procedure" for restarting the cluster? | 17:01.50 |
| | ./killClustermaster.sh ; ./clustermaster.pl & ? | 17:02.06 |
| sags | Hi all, I'm having a question about PS resources and OpenVMS: what?s the filename template to use for enumerating resources of a given category? | 17:23.41 |
| | A comment in gs_res.ps line 530 says "% Resource files on OpenVMS require a separate template (gs:[dir.*]*)". Being OpenVMS-ignorant, I suspect it wants to pass | 17:23.51 |
| | "dev:[generic.resource.dir" + "category.*]originaltemplate" | 17:24.01 |
| | to .generate_dir_list_templates_with_length, which does not look right (one dir level too deep). Or maybe it intends to pass | 17:24.09 |
| | "dev:[generic.resource.dir" + "category]originaltemplate.*" | 17:24.16 |
| | which has its own problems (the ".*" could mean "all extensions" or "all versions", depending on originaltemplate). However what it does is pass | 17:24.23 |
| | "dev:[generic.resource.dir" + "category]originaltemplate]*" (note the use of "]") | 17:24.34 |
| | This looks incorrect. And even unnecessary, because I think the preceding call, with | 17:24.41 |
| | "dev:[generic.resource.dir" + "category]originaltemplate" | 17:24.47 |
| | should be ehough. And if a 2nd template is necessary for searching into GenericResourceDir, why isn?t it necessary for searching into LIBPATH too? | 17:24.53 |
| mvrhel | henrys: the copy alpha stuff is done. I will get going on the rest of my aging bug items | 17:30.12 |
| henrys | woo hoo! nice mvrhel | 17:31.58 |
| mvrhel | I also still need to look at the psdrgb device and the 16bit version of this to make sure everything is ok there | 17:32.25 |
| | that last clist bug was hard to find | 17:32.30 |
| henrys | sags you might want to try a contact the vms volunteer that last worked on it. We are pretty much clueless. | 17:32.34 |
| mvrhel | need to run an errand. bbiab | 17:33.38 |
| sags | @henrys : Thanks, I'll try to figure out how to do the equivalent of "svn annot" in git. Maybe that will help locate who wrote this. | 17:34.49 |
| ray_work | mvrhel: when you get back, I'd like to find out what the clist issue was. | 17:35.13 |
| henrys | sags I don't know if he had his name on a commit but searching the code and documentation should turn up something. | 17:36.20 |
| | sags:https://groups.google.com/forum/#!topic/comp.os.vms/CL2pyCMsSfs | 17:38.00 |
| | mark berryman? | 17:38.07 |
| | bbiab | 17:38.36 |
| sags | @henrys : Thanks for the pointer, I'll have a look. | 17:40.48 |
| Robin_Watts | marcosw: ping? | 19:02.03 |
| mvrhel | henrys: so I am not sure what to do about 693042 | 19:41.19 |
| | I have profiled it and it is clearly spending time in the transparency stuff | 19:41.34 |
| | I will review the xps file itself to see if there are any obvious things we could be doing | 19:41.52 |
| | I may also compare to another xps rip to see how it does on this file | 19:42.17 |
| Robin_Watts | Is there scope for us doing SWAR or SIMD stuff for the blending ? | 19:42.46 |
| mvrhel | Robin_Watts: I was thinking the same thing. That would help. I am not sure what the customer is set up with though for this | 19:43.35 |
| | although that is what we did for them for the halftoning | 19:44.06 |
| | with the sse2 stuff | 19:44.18 |
| | same customer yes? | 19:44.30 |
| Robin_Watts | pass. | 19:44.48 |
| mvrhel | or am I confused | 19:44.48 |
| | they had some slowness in pcl that drove that | 19:45.12 |
| Robin_Watts | could well be. I haven't checked. | 19:45.18 |
| mvrhel | not sure if this is the same product/group | 19:45.23 |
| | henrys would probably know | 19:45.38 |
| | looking at the file, I don't see why this should take so long to render | 19:46.43 |
| | ok so the old xps rip from years ago renders this file in a matter of seconds at 600dpi | 20:03.51 |
| | so clearly, something is a miss with our approach | 20:04.09 |
| | and that is with AA and interpolation | 20:04.45 |
| henrys | which xps rip, ours? | 20:06.20 |
| | what happens without banding - large MaxBitmap? | 20:07.27 |
| mvrhel | henrys: this is the page mark rip | 21:15.03 |
| | I am looking into the issue now. | 21:15.23 |
| | I can't seem to run the 64 bit version of xps on windows | 21:15.42 |
| | gxps | 21:15.45 |
| | as a side note | 21:15.54 |
| | had to go back to 32 bit to make things work there | 21:16.16 |
| henrys | can you make a bug report about the 64 bit problem and assign it to marcos for now. | 21:23.46 |
| mvrhel | ok | 21:23.53 |
| Ch3rryC0ke | Hi there-- I'm using mupdf in a Win 8 metro project. I'm getting an error in in fitz.h because of the following statement: | 21:30.23 |
| | #define inline __inline | 21:30.28 |
| | In VS C++, there's an error saying: Error1error C4005: 'inline' : macro redefinition (.\PDFGenerator.cpp)c:\program files (x86)\microsoft visual studio 11.0\vc\include\xkeycheck.h199 | 21:31.24 |
| | Error2error C1189: #error : The C++ Standard Library forbids macroizing keywords. Enable warning C4005 to find the forbidden macro. (.\PDFGenerator.cpp)c:\program files (x86)\microsoft visual studio 11.0\vc\include\xkeycheck.h242 | 21:31.35 |
| | The line it points to in xkeycheck.h is for #define inline .. and the only place I find that redefinition is in fitz.h | 21:32.02 |
| | Any idea how I can get around this? It's around line 95 in fitz.h | 21:34.27 |
| tor8 | Ch3rryC0ke: delete the line in fitz.h, or figure out the correct #ifdef | 21:49.08 |
| | Ch3rryC0ke: are you compiling as C++? | 21:49.34 |
| Ch3rryC0ke | I'm compiling a class in C++, but using extern "C" when including mupdf files | 21:50.21 |
| | Deleting the line causes a bunch of cascading errors.. | 21:50.42 |
| tor8 | Ch3rryC0ke: do you have the most recent source? we added C++ guards around the inline definition recently. | 21:56.26 |
| Ch3rryC0ke | I'm using 1.0-source (from codeplex). What release should I pull? Should I pull from git? | 21:56.59 |
| tor8 | pull from git | 21:57.12 |
| | git://git.ghostscript.com/mupdf.git | 21:57.44 |
| Ch3rryC0ke | ok, thanks, I'll try that. Should I just always be using the latest on git? I wasn't sure if releases are tagged etc, I'm spoiled by github where I can see tags etc before pulling | 21:57.45 |
| tor8 | http://git.ghostscript.com/?p=mupdf.git;a=summary | 21:57.59 |
| Ch3rryC0ke | awesome, thanks! | 21:58.18 |
| tor8 | we do regression testing, so the master branch should be good most of the time :) | 21:58.43 |
| Ch3rryC0ke | Awesome-- should I set this up as a submodule in my project? i'm wondering what the best way to do this is since my project is hosted on GitHub | 21:59.18 |
| tor8 | that's up to you how you do | 21:59.46 |
| Ch3rryC0ke | and I want to be able to keep my local changes on top of master (if I need to make any), while still pull new changes, and yet not duplicate all the mupdf code onto Github.. | 21:59.54 |
| | I'm wondering if there is anyway to avoid that duplication.. | 22:00.07 |
| tor8 | then a submodule is probably your best bet, or the new-ish git-subtree command | 22:00.19 |
| Ch3rryC0ke | ok, thanks | 22:00.49 |
| tor8 | take care with submodules and overwriting local changes though. submodules are a bit annoying to use. I'd recommend cloning our git repo into your own github as a separate project, and use a submodule pointing to that from your main project | 22:01.34 |
| | you'll have to do something like that if you want to keep your local changes to mupdf in the git on a separate branch that you can merge or rebase when you pull from upstream | 22:02.34 |
| | anyway, gotta go to bed. night all! | 22:02.42 |
| Robin_Watts | marcosw_: ping? | 23:23.42 |
| marcosw_ | Robin_Watts: yes | 23:27.52 |
| Robin_Watts | hi, I put the mujstest stuff back in. | 23:28.14 |
| | and evidently people have successfully run tests since | 23:28.29 |
| | but my test clusterpush of mupdf didn't seem to do anything before. let me try again | 23:28.54 |
| | Is there a "recommended" procedure for restarting the clustermaster ? | 23:29.21 |
| marcosw_ | there was a problem in run.pl that I introduced that I fixed a bit ago. | 23:29.31 |
| | abortAll.pl sends an abort job to all the nodes | 23:29.43 |
| Robin_Watts | ah, that might explain it. | 23:29.48 |
| | A couple of questions... | 23:29.55 |
| marcosw_ | killClustermaster.sh kills the cluster master and removes the lock file. | 23:30.01 |
| Robin_Watts | Why, when I push a mupdf job does the cluster say "mupdf" rather than "user robin mupdf" ? | 23:30.26 |
| | If I push a mujstest job it says "user robin mujstest" which seems much better. | 23:30.42 |
| | (and I can't see why there is a difference - I just copied the mupdf code!) | 23:31.16 |
| | Another question... are you aware that the cluster is testing debug builds of mupdf rather than release ones ? | 23:31.49 |
| marcosw_ | I knew about the debug issue. that's the default target. | 23:32.44 |
| Robin_Watts | Is there a reason for that? | 23:33.07 |
| marcosw_ | is there a reason the default target is a debug build? | 23:34.32 |
| Robin_Watts | sorry, that was unclear. | 23:34.32 |
| | I mean, is there a reason why we can't add build=release to the make lines ? | 23:34.48 |
| | did you just queue a mupdf job too? | 23:35.09 |
| | the cluster is showing 2. | 23:35.24 |
| | oh, back to 1. | 23:35.35 |
| marcosw_ | I did to see what your comment of "mupdf" vs "use robin mupdf" referred to. I just removed my job but I see "user robin mupdf" in the queue.lst file. | 23:36.06 |
| Robin_Watts | Look at the dashboard. | 23:36.48 |
| marcosw_ | You mean the line that says "Regression robin mupdf started at 06/28/12 23:29:40 UTC - finished at 23:37:26"? | 23:39.19 |
| Robin_Watts | I'll just cluster push again. | 23:39.42 |
| | No, not that line. | 23:39.48 |
| | The green line (or the amber one) that shows queued jobs. | 23:40.14 |
| | I see "user robin mujstest" in amber, and "mupdf" in green. | 23:41.37 |
| | When you ran your job I just saw "mupdf" in amber again. | 23:41.49 |
| | It's not hugely important, I guess. | 23:42.00 |
| marcosw_ | I just cluster pushed a gs job and it says user marcos gs. You wrote the dashboard, where does it get that information from? The queue.lst file shows: | 23:43.27 |
| | user robin mupdf | 23:43.39 |
| | user robin mujstest | 23:43.39 |
| | user marcos mupdf | 23:43.39 |
| | user marcos gs | 23:43.40 |
| Robin_Watts | rillian wrote the dashboard. I just pimped it :) | 23:44.10 |
| | I'll look in the clustermonitor script tomorrow then - I'd assumed it was a queue thing, but it's probably something in the json. | 23:44.42 |
| marcosw_ | I think it's in the javascript code, but it sure is hard to tell. | 23:46.19 |
| | I'll modify the mupdf regression stuff to do release builds instead of debug builds. Should be a couple of line change. | 23:46.49 |
| Robin_Watts | yeah, it's an easy change. | 23:48.10 |
| marcosw_ | so I changed the javascript for the dashboard, but it's probably not an improvement :-) | 23:48.38 |
| Robin_Watts | I need to put a makefile change through on mupdf master tomorrow, then I want to tweak those lines so it won't try and build the js targets for normal mupdf builds. | 23:49.08 |
| | unknown mupdf :) | 23:49.12 |
| marcosw_ | so you do you want me to change to build=release? | 23:51.52 |
| Robin_Watts | no, I can do that tomorrow as part of the other fiddling I have to do. | 23:52.22 |
| | just wanted to check that it wasn't a carefully thought out plan. | 23:52.34 |
| marcosw_ | nothing I do is part of a plan, carefully thought out or otherwise. | 23:55.04 |
| | Forward 1 day (to 2012/06/29)>>> | |
IRC Logs