| | <<<Back 1 day (to 2012/12/17) | 2012/12/18 |
| JakeSays | does anybody know if there is a commercial licensing option for redmon? | 02:35.34 |
| Robin_Watts | JakeSays: I'm pretty sure there is. It's either through Artifex or from Ghostgum directly. Someone will be along in a bit that knows more. | 09:11.13 |
| | kens2: Do you know the commercial licensing position for Redmon? | 12:02.19 |
| kens2 | Not really no, I *believe* Artifex is involved now, but I don't know the details. | 12:03.04 |
| Robin_Watts | oh gawd. | 13:11.18 |
| | This file has a t3 glyph that uses the font its contained in. | 13:11.43 |
| kens | That's valid | 13:11.53 |
| | composite glyph for example | 13:12.02 |
| Robin_Watts | Presents problems for mupdf. | 13:16.14 |
| kens | ah :-( | 13:16.39 |
| Robin_Watts | When we first meet a type3 font, we run through and draw all the type3 glyphs to displaylists. | 13:16.44 |
| | and if in the process of doing that we hit a use of the font, we try to load the font again. | 13:17.33 |
| kens | Hmm, you should probably search for the requested glyph already being captured | 13:18.07 |
| | And if its not, defer the glyph until all others have been processed, then process the deferred list | 13:18.25 |
| | Obviously I don't know how possible that ios | 13:18.39 |
| Robin_Watts | kens: We don't even insert the font into the list of fonts until we've finished loading it. | 13:18.55 |
| kens | Robin_Watts : Well, a special check for 'this' font shouldn't be too hard ? | 13:19.15 |
| Robin_Watts | kens: Well, then some git will make a file that uses mutually referencing fonts. | 13:19.43 |
| kens | Robin_Watts : possibly, but that is *highly* unlikely outside of a specially crafted file to exhibit an error | 13:20.08 |
| | Because any job would fail in the absence of either font | 13:20.21 |
| Robin_Watts | yes. | 13:20.27 |
| kens | Basically I wouldn't worry about that | 13:20.33 |
| Robin_Watts | I think we need to define type3's early (before we capture the glyphs). | 13:21.35 |
| | Ah. I think I have it. | 13:22.00 |
| | We load type3's as we always have done before (load without loading the glyphs). | 13:22.16 |
| | And we make it so we load the glyphs to display lists on demand. | 13:22.40 |
| kens | That's how PostScript works | 13:22.51 |
| Robin_Watts | But then after loading the type3 we run through and 'demand' each display list. | 13:23.07 |
| kens | has to go bring the shopping in | 13:23.16 |
| Robin_Watts | has just done that. | 13:23.22 |
| | tor8: ping. | 13:23.26 |
| tor8 | Robin_Watts: yes? | 13:23.42 |
| Robin_Watts | Just hit a problem with the new type3 display list stuff. | 13:23.55 |
| | See the recent conversation with kens. | 13:24.05 |
| tor8 | Robin_Watts: ouch. | 13:24.25 |
| Robin_Watts | tor8: For each glyph we should have a special flag meaning "I am loading this one now", so we can spot malicious files that have nastily recursive (or mutually recursive glyphs) | 13:25.55 |
| tor8 | Robin_Watts: yeah, I'm thinking there's two problems that need to be solved | 13:26.20 |
| | one, don't get into nasty recursion | 13:26.31 |
| Robin_Watts | I think my solution solves it all. | 13:26.35 |
| tor8 | two, allow use of the font in partially loaded state | 13:26.53 |
| Robin_Watts | We change the pdf_load_type3_font to just set up the font with NULL display lists for every glyph. | 13:26.56 |
| | We then change the code so that when it gets a request for a glyph with a NULL display list to load that list now. | 13:27.31 |
| tor8 | Robin_Watts: that doesn't solve the original problem we had that prompted this change though | 13:27.52 |
| Robin_Watts | Then in pdf_load_font, after we've put the font into the store, for type3 fonts, we run through the list of glyphs demanding them. | 13:28.19 |
| tor8 | we must not run the t3procs from a display list | 13:28.21 |
| | only ever from the interpreter | 13:28.25 |
| | right, with that last sentence of yours I'm with you | 13:28.47 |
| Robin_Watts | So that gives us the same behaviour we have now; by the time pdf_load_font exists, we are guaranteed to have loaded all the glyphs to display lists. | 13:29.01 |
| tor8 | Robin_Watts: so basically you're delaying fz_prepare_t3_glyph until after it's in the store | 13:29.35 |
| Robin_Watts | In the code that loads a glyph to a displaylist we should initially set the displaylist from NULL to be an empty display list. | 13:29.43 |
| tor8 | Robin_Watts: to prevent mutual recursion, right? | 13:30.18 |
| Robin_Watts | That way, if glyph 1 calls for glyph 1 to be used (or glyph 1 calls for glyph 2 which calls for glyph 1) we don't get nasty recursions. | 13:30.20 |
| | yeah. | 13:30.22 |
| | yes. | 13:30.33 |
| tor8 | that should work. I can't think of any other problems. but then again, I'm still fuzzy in the head from this nasty cold of mine :( | 13:30.54 |
| Robin_Watts | I'm going to lunch now, so it can sit on us both for a bit before I try it. | 13:31.07 |
| | tor8: ping | 14:41.36 |
| tor8 | Robin_Watts: | 14:42.50 |
| Robin_Watts | Sanity check please... I'm lifting the last loop out of pdf_load_type3_font to a new function (pdf_load_type3_glyphs). I'm not going to have estrings around when I come to that latter function. | 14:42.51 |
| | Can I just run through the entries in charprocs and load them? | 14:43.18 |
| | (so instead of for (i = 0; i < 256; i++), I run over the entries in charprocs) | 14:43.50 |
| tor8 | Robin_Watts: I thought you'd split that loop into two | 14:43.50 |
| | one for loading the charproc buffer, and one at the end for initializing the display lists | 14:44.04 |
| Robin_Watts | Oh, so still load the stream, but call prepare later? | 14:44.11 |
| tor8 | yeah, that's what I thought you'd do | 14:44.26 |
| Robin_Watts | And that solves my problem as I'm running over the non numm t3procs. | 14:44.34 |
| | brilliant. | 14:44.38 |
| | Thanks. | 14:44.40 |
| | s/numm/null/ | 14:44.57 |
| | I'm wondering if this is in fact all I need to do. | 14:45.41 |
| | If a glyph in a type3 font attempts to use another glyph in the same font, I hope the code will detect the presence of the font, and just put an entry in the display list. | 14:46.46 |
| | so preparing one glyph shouldn't be able to cause recursive prepares any more. | 14:47.09 |
| tor8 | Robin_Watts: might need to add a guard against the display list already existing in prepare_glyph | 14:48.19 |
| Robin_Watts | I think I've done that. | 14:48.36 |
| | yeah. but the case I was worried about is when we are preparing glyph 1, if that needs glyph 2, will that cause a recursive prepare? | 14:49.18 |
| tor8 | Robin_Watts: that will trigger a fz_render_t3_glyph which will short out due to the list being null | 14:50.16 |
| Robin_Watts | Right. So why do I need the guard in prepare_glyph ? | 14:50.37 |
| tor8 | (given that it can find the font in the store, which is what we're discussing how to do without breaking everything) | 14:50.40 |
| | you don't, I guess. | 14:50.51 |
| Robin_Watts | ok, fab. | 14:50.56 |
| tor8 | and if glyph 1 uses glyph 1, we'll hit the semi-complete display list and run that | 14:51.26 |
| | so we shouldn't set the t3list to the actual display list until after we've finished it | 14:52.09 |
| Robin_Watts | tor8: will we? | 14:52.14 |
| tor8 | in prepare, where we call t3run that might recurse on malicious files | 14:52.28 |
| Robin_Watts | I was hoping that we'd just insert an entry into the display list saying "display glyph 1" | 14:52.44 |
| tor8 | in prepare: font->t3lists[gid] = fz_new_display_list(ctx); should use a temp | 14:52.46 |
| | Robin_Watts: right. maybe I'm confusing it with the render_direct case. | 14:53.29 |
| Robin_Watts | I'll give it a test. | 14:53.40 |
| tor8 | which would cause the behaviour I mentioned, if it used the display list at all, which it doesn't! | 14:53.45 |
| Robin_Watts | Well, that's moved the assertion on into the scaler. So progress, I hope :) | 14:56.32 |
| Ollea | Hello guys ! | 15:23.53 |
| | I've been looking for Ghostscript return error codes meaning for a while, can anybody tell me where I can found what is error 32512 ? | 15:24.43 |
| kens | Thatlooks like anOS error, its not a normal Ghostscript error. | 15:27.22 |
| | What was the accompanying error message stack ? | 15:27.39 |
| Ollea | I don't know, I tried to pass the -dDEBUG argument to gs but it's not more verbose | 15:29.44 |
| kens | You mean there was no error message at all ? | 15:30.03 |
| | FWIW you can find the PostScript error values in gs/base/gserrors.h | 15:30.25 |
| Ollea | Yes, the STDOUT is the error code... | 15:30.56 |
| kens | Can you quote the whole message please ? | 15:31.14 |
| | Also the OS used and the version of Ghostscript | 15:33.02 |
| Ollea | But there is no error message, only error code is returned | 15:33.10 |
| kens | That sounds to me like your OS is giving you the error. | 15:33.26 |
| Ollea | Yes sure, it's a Debian Kernel 3.2.13 with gs 8.71 | 15:34.05 |
| kens | Well the first thing that springs to mind is that 8.71 is old. | 15:34.41 |
| | WHat command line are you suing, and can you share the file publicly so we cna look at it ? | 15:34.54 |
| Ollea | gs -q -sDEVICE=epswrite -sstdout=%stderr "-sOutputFile=/tmp/out.eps" -dNOPAUSE -dBATCH -P- -dSAFER -dNOCACHE "/tmp/in.eps" | 15:35.33 |
| kens | 1 minute | 15:35.45 |
| Ollea | Sure but it works with root, so I think it a permission problem | 15:36.04 |
| | Cause I'm executing this command through a PHP script | 15:36.27 |
| kens | Take of -dSAFRE | 15:37.03 |
| | But yes it sounds like a permissions problem | 15:37.23 |
| | I would guess the OS error is being passed up when the device tries to openthe output file | 15:38.10 |
| Ollea | Same error without -dSAFER | 15:38.25 |
| kens | THen you should look into the permissions on the output directory, and the user you are executing the script under | 15:38.50 |
| | I am not a Linux expert.... | 15:39.04 |
| | And know very little about PHP | 15:39.14 |
| | If it works when you run as root, then it is not a Ghostscript bug. | 15:39.37 |
| | Notice that you are sending stdout to stderr, are you capturing the stderr output ? | 15:40.05 |
| kens | tries to recall what -P- does | 15:41.32 |
| | Oh, prevents searching the current directory, that's safe neough | 15:42.15 |
| Ollea | Yes you're right, I'm gonna check the outputs... | 15:42.30 |
| kens | I would not set -dNOCACHE, that will just slow the process down | 15:42.48 |
| Ollea | Thanks but I need to do it without cache | 15:44.45 |
| kens | why ? | 15:44.51 |
| Ollea | Cause it is done with many uploaded user files | 15:45.18 |
| kens | WHy is that a problem ? | 15:45.27 |
| henrys | kens:I think Miles always handles redmon but just refer him to Scott and let him sort it out. | 15:45.29 |
| kens | henrys OK. | 15:45.44 |
| Ollea | Actually I'm using a script called eps2svg and this option is set in... | 15:46.04 |
| kens | Not with the command line above, you are not. | 15:46.22 |
| | THat is doing EPS *output* | 15:46.31 |
| Ollea | Sure but the eps2svg script call the eps2eps command and that's where the script returns the error | 15:47.35 |
| | Damned, 32512: No such file or directory | 15:47.41 |
| kens | THat's bonkers | 15:47.46 |
| Ollea | Why ? | 15:48.01 |
| kens | WHy would you convert an EPS into an EPS ? | 15:48.22 |
| | Especially in order to produce an SVG | 15:48.29 |
| Ollea | I was saying to myself a few minutes ago | 15:48.40 |
| henrys | I seem to be having net problems again today. They reported it fixed yesterday but here we go again. | 15:54.52 |
| Robin_Watts | Forms meeting in 5? | 15:57.38 |
| | Presumably there won't be one next week :) | 15:57.47 |
| | And paulgardiner and I are away for the next one too. | 15:58.00 |
| henrys | yes hopefully, I can't seem to get to my mail is anyone having problems reaching gmail? | 15:58.22 |
| Ollea | You're right this command just does : /usr/bin/eps2eps -dNOCACHE "$file_name" "$tmp_dir/temp1.eps" | 15:58.44 |
| kens | that's plain silly | 15:58.56 |
| | I would not do that | 15:59.00 |
| Ollea | Ha yhea ? | 15:59.09 |
| kens | It just slows down the conversion | 15:59.16 |
| Robin_Watts | unless it's using gs as a sanitiser for some dodgy eps? | 15:59.18 |
| henrys | I can write that script in one line ;-) | 15:59.25 |
| Ollea | I think that's the case Robin | 15:59.57 |
| | Because the script deals with user uploaded EPS | 16:00.14 |
| | But if you have a simpler command to convert EPS to SVG, it's with pleasure henrys | 16:01.40 |
| henrys | unfortunately for whatever reason I can't reach gmail and can't access paul's report. | 16:01.57 |
| paulgardiner | henrys: do you have another email address I could forward it to? | 16:02.31 |
| henrys | Ollea:it was a joke presumably you could convert eps to eps with "cat" | 16:02.40 |
| Ollea | Yes thanks :) | 16:03.09 |
| paulgardiner | Basically the reports says that the directory navigation in the file picker is done, and the XPS problem isn't of our doing. | 16:03.35 |
| Robin_Watts | henrys: sent via private chat. | 16:03.36 |
| henrys | Robin_Watts is dumping ... | 16:03.42 |
| | what he said | 16:03.49 |
| | I can't even get to google other large sites are fine. | 16:04.32 |
| Robin_Watts | paulgardiner: So am I right in thinking that the PDF intent stuff is never used? | 16:04.34 |
| | henrys: Is the problem with DNS? | 16:04.45 |
| | IF so, add 8.8.8.8 to your list of DNS resolvers | 16:04.56 |
| paulgardiner | One extra thing not said in the report, I fixed OI File Manager, so XPS opens in MuPDF from that now, although I@ve had trouble submitting the patch | 16:05.06 |
| | Robin_Watts: the mimetype bit is used, and the path part is used by correctly working file managers | 16:06.00 |
| | I also discovered by accident what ES probably does that causes it to offer every viewer on the device. | 16:06.38 |
| Robin_Watts | right. How does the system get its list of mimetypes. | 16:07.01 |
| | Does it have them built in? Or does it rely on the mimetype sent with each file as it's downloaded? | 16:07.48 |
| paulgardiner | It seems to be fixed. The question of adding them seems to have been asked by many people, but no one seems to know a way | 16:07.51 |
| Robin_Watts | Ok, that's my list of obvious questions emptied then :) | 16:08.12 |
| paulgardiner | With downloaded files, it may have ways to store the one from the site. | 16:08.29 |
| | I'd guess not though | 16:08.44 |
| Robin_Watts | Is there a default mimetype? | 16:08.58 |
| paulgardiner | It all works fine if the File Managers get it right. | 16:09.00 |
| Robin_Watts | (application/octet-stream or something?) | 16:09.08 |
| | If so, we could lie and say that mupdf supported that... | 16:09.28 |
| paulgardiner | */* will cause every viewing app to offer, and empty string causes the path match to operate | 16:09.36 |
| Robin_Watts | So we could add */* | 16:09.55 |
| | at the cost of us being offered too often. | 16:10.07 |
| henrys | yeah the 8.8.8.8 seems to work, what is that about? | 16:10.27 |
| paulgardiner | If my submitted patch gets through to OI then their file manager will work, and I can try telling the ES people how to fix it. | 16:10.29 |
| Robin_Watts | henrys: google DNS | 16:10.37 |
| paulgardiner | Robin_Watts: I'd imagine we'd cause more grief by offering too often. At least now that we have the directory navigation people can open the file. | 16:11.18 |
| Robin_Watts | paulgardiner: I wonder how many file managers there are... ASTRO is another one I've heard of. | 16:11.23 |
| | yeah. | 16:11.25 |
| | henrys: Sorry, I didn't mean "google for DNS", I meant "It's the Google DNS service". | 16:11.42 |
| paulgardiner | Robin_Watts: I could try out a few of the more popular ones and suggest the fix to the developers for the ones that don't work | 16:12.09 |
| Robin_Watts | paulgardiner: Might be worthwhile. What do you think henrys ? | 16:12.39 |
| paulgardiner | As I mentioned before, the built in file manager on the S2 works fine | 16:12.48 |
| tor8 | paulgardiner: I'd rather bug devs of slightly broken file managers than add */* to the list of supported files | 16:13.38 |
| paulgardiner | tor8: Yeah, me too. | 16:14.03 |
| | I think ES is about the most popular so might bug them for starters | 16:15.27 |
| henrys | paulgardiner: I think that is the right thing to do. | 16:17.38 |
| paulgardiner | henrys: ok good. | 16:17.57 |
| Robin_Watts | So, anything more for the meeting? | 16:21.11 |
| paulgardiner | I've been assuming I should work on annotation support now. Is that right? | 16:21.40 |
| Robin_Watts | I've bashed a bit on the big archive of sample files and solved some of the SEGVs. | 16:21.42 |
| | but still lots to do. I've lost a couple of days to the latest round of Unicode madness in gs, but I'm focused back on mupdf again now. | 16:22.16 |
| henrys | yes I really want to charge forward with the annotations. | 16:22.52 |
| | is it easy to build apk's is it something that could be automated so we can all bash on this stuff as you work on it. | 16:23.45 |
| | ? | 16:23.47 |
| Robin_Watts | henrys: It's just a question of running ndk-build && ant debug | 16:24.37 |
| paulgardiner | The debugging process generates them, so I just need to upload one every now and then | 16:24.45 |
| Robin_Watts | (on a correctly set up box) | 16:24.51 |
| | possibly we should set up at least one cluster node to be able to build the apk. Then we could add a cluster task to build the apk on every commit. | 16:26.23 |
| henrys | Robin_Watts: that would work for me. | 16:28.50 |
| paulgardiner | That would be nice. | 16:29.00 |
| Robin_Watts | It would protect against accidental breakage. | 16:29.15 |
| paulgardiner | That's a point, nearly forgot: I have a couple of commits that need reviewing | 16:29.37 |
| henrys | so Robin_Watts will take that on and post a location for the apk? | 16:31.32 |
| Robin_Watts | ok. | 16:31.42 |
| henrys | anything else for this week? tor8? | 16:32.38 |
| Robin_Watts | paulgardiner: I'll look at the commits. | 16:35.03 |
| paulgardiner | ta | 16:35.13 |
| Robin_Watts | paulgardiner: One small feature request, that may be completely impossible. | 16:36.56 |
| henrys | let's call it then so no meeting for 3 weeks? | 16:37.00 |
| Robin_Watts | When I scroll down a long list of filenames, and pick a file, and then exit that file, it would be really nice to go back to that point in the list, not back to the top. | 16:37.33 |
| | henrys: We could have a meeting on the 27th? or on the 3rd? | 16:38.06 |
| paulgardiner | Robin_Watts: yeah, that's me being lazy. I had to do that for the outline list, I'll see if I can fix it with this too | 16:38.18 |
| Robin_Watts | paulgardiner: Thanks. I have 1000 files in the directory, which makes checking them in turn an O(n^2) process :) | 16:39.01 |
| tor8 | Robin_Watts: 3rd would be preferable, 27th is a holiday in sweden | 16:39.23 |
| paulgardiner | Robin_Watts: :-) | 16:39.30 |
| tor8 | oh wait, or is it? | 16:39.31 |
| | nvm :) | 16:39.53 |
| Robin_Watts | paulgardiner and I are away from 28th to 1st, so very little is likely to get done between those 2 dates. | 16:40.13 |
| henrys | the 3rd sounds good to me. | 16:40.48 |
| | I'll be around for most of the holiday. | 16:41.00 |
| | though. | 16:41.03 |
| tor8 | Robin_Watts: then 27th makes more sense | 16:41.19 |
| | or just wait 3 weeks | 16:41.34 |
| Robin_Watts | will be off 25/26 and 28-1. | 16:41.36 |
| henrys | let's make the next formal meeting the 3rd and I'm sure we'll bump into each other before that. | 16:42.32 |
| ray_laptop | what? the meetings over already ? (or was that the mupdf meeting?) | 16:43.15 |
| Robin_Watts | ray_laptop: mupdf meeting :) | 16:43.25 |
| ray_laptop | darn, I was just hoping | 16:43.51 |
| henrys | we'll make this one the last of the year! | 16:45.03 |
| Robin_Watts | tor8: Balls. Hit another problem with the type 3 stuff. | 16:45.23 |
| | I'm getting leaks. | 16:45.37 |
| | the type3 font contains a set of display lists. Those display lists can contain a reference to the type3 font. | 16:46.10 |
| | hence ref counting means we never delete the damn font :( | 16:46.25 |
| henrys | bbiab | 16:46.30 |
| tor8 | Robin_Watts: oh, circular references! | 16:48.54 |
| Robin_Watts | mmm. | 16:49.10 |
| tor8 | damn. | 16:49.13 |
| | that's a nasty one. maybe take the hit for these pathological files? | 16:49.31 |
| | adding in weak references is icky | 16:49.41 |
| Robin_Watts | I really don't want to have to implement gc :( | 16:49.43 |
| ray_laptop | type3 fonts aren't that common | 16:49.48 |
| Robin_Watts | self-referential type3's even less so. | 16:50.00 |
| | actually, type3's are more common than you'd hope. | 16:50.35 |
| ray_laptop | can you just use a special allocation method for those and "clean up" at the end of a page ? | 16:52.17 |
| Robin_Watts | ray_laptop: Not trivially. | 16:52.45 |
| chrisl | Robin_Watts: why does the display list need a reference to the font objects? | 16:53.30 |
| Robin_Watts | chrisl: Type 3 fonts are implemented as a list of display lists, one per glyph. | 16:54.00 |
| chrisl | Robin_Watts: Oh, so the display list isn't "flat"? | 16:54.38 |
| Robin_Watts | We used to interpret each glyph each time it was required, but that gives multi-threading problems with several threads trying to run interpreters which all access the file at the same time. | 16:54.52 |
| | So the display list is flat, except for type3 fonts. | 16:55.06 |
| chrisl | So could you make the display list flat, so all glyphs are self-contained, and don't need the font reference? | 16:56.10 |
| ray_laptop | so you have a mutex lock set while you load the entire font ? | 16:56.45 |
| Robin_Watts | ray_laptop: Effectively, yes. | 16:56.58 |
| | chrisl: Interesting. | 16:57.07 |
| chrisl | Robin_Watts: glyphs are *generally* not that big, and this is probably a rare enough occurrence that the extra space won't be a problem | 16:57.52 |
| Robin_Watts | yeah. And we have code to do that already, kinda, I think. | 16:58.06 |
| | For type 3 glyphs that inherit graphic attributes from the environment, we have a 'render_direct' path. | 16:58.37 |
| | Hmm. That might not be at the right level though. | 16:58.54 |
| tor8 | chrisl: we have flattened display lists for some type 3 fonts (where they depend on the surrounding graphics state at the call site) | 16:59.16 |
| | chrisl: but in general we don't because we watn to preserve the text as text for search etc | 16:59.30 |
| kens | GS Meeting time ? | 17:00.12 |
| henrys | yes meeting time. | 17:00.29 |
| | perhaps I'll send out an email to everyone but I think the protocol for vacation, sick, personal days should be send to joann and cc staff | 17:01.33 |
| | is marcosw about? | 17:02.52 |
| marcosw | I am. | 17:03.06 |
| henrys | did we want to review time to run the overnight cluster stuff? | 17:03.31 |
| | for example I'm fine leaving off the pcl cet if it stays in the commit check run | 17:04.45 |
| | but I don't know how much that help time wise. | 17:05.10 |
| | so all not in favor of making this the last meeting of the year, say something. | 17:07.29 |
| Robin_Watts | no, no, I want an excuse to get away from my relatives on Xmas day! | 17:08.09 |
| kens | will not be here Xmas day :-) | 17:08.30 |
| chrisl | On the subject of the cluster - there some indeterminisms have crept in, some/most are mine, and I'm working on it | 17:08.36 |
| henrys | I can't think of anything else for this meeting ⦠either I must have a bad meeting attitude. | 17:08.42 |
| kens | Not been long since face to face meeting | 17:09.43 |
| henrys | I'm sure we'll see each other about, everyone have a good safe holiday! | 17:09.55 |
| ray_laptop | I'm fine with not meeting until 2013 | 17:10.10 |
| Robin_Watts | Well, the world is ending on friday, so it's been nice working with you all. | 17:10.30 |
| ray_laptop | henrys: and a safe happy holiday to you and your family ! | 17:10.30 |
| | Robin_Watts: likewise | 17:10.41 |
| Robin_Watts | unless I see you in the french village waiting for the space ship to arrive to take us all to safety. | 17:11.04 |
| marcosw | henrys: we can leave the pcl cet tests in the overnight run. As I mentioned in the staff meeting I never see any differences, but that doesn't mean we shouldn't run them. | 17:11.58 |
| henrys | another customer wants digitally signed software. | 17:15.36 |
| kens | signed binaries ? | 17:15.56 |
| henrys | can't remember how we weaseled out of that last time. | 17:16.00 |
| | kens:presumably I haven't seen the original request yet. | 17:16.20 |
| Robin_Watts | henrys: We could just md5sum the release binaries and publish the sums? | 17:17.28 |
| chrisl | Robin_Watts: we already do that for the installer..... | 17:17.49 |
| henrys | we do that alreaday | 17:17.51 |
| | I'll forward the request to marcos and support. | 17:20.22 |
| | nvm it is just confusion. | 17:23.16 |
| kens | OK I'm off have a great Xmas everyone | 17:23.28 |
| chrisl | You too, kens | 17:23.36 |
| Ollea | Is that normal that in /usr/bin/eps2eps GS_EXECUTABLE is set to "gs" and not the absolute path to the binary ? | 17:27.28 |
| chrisl | Ollea: yes, that's normal - gs should be in the search path already | 17:31.01 |
| JakeSays | Robin_Watts: thanks for the response. i'll ping artifex, since i need to inquire about ghostscript licensing as well. | 19:19.48 |
| Robin_Watts | JakeSays: Fab. Do you have Scott's email address? | 19:20.08 |
| JakeSays | i dont | 19:20.18 |
| Robin_Watts | scott.sackett@artifex.com | 19:20.28 |
| JakeSays | thanks! | 19:20.38 |
| Robin_Watts | you're welcome. | 19:20.48 |
| | paulgardiner: Just remembered your commits, sorry, I'd gotten sidetracked. | 19:22.54 |
| | So you use '..' for up? | 19:23.03 |
| JakeSays | hmm. does artifex still not support small user? | 19:26.50 |
| | users | 19:26.54 |
| Robin_Watts | JakeSays: Depends what you mean. | 19:27.10 |
| JakeSays | well, our app is not at all high volume | 19:27.33 |
| | and from what i've read, they only deal with high volume oems | 19:27.52 |
| Robin_Watts | There are quarterly minimums for commercial distribution of gs, yes, but that's something you need to take up with Scott. | 19:27.56 |
| | We certainly have "non-high volume" customers. | 19:29.57 |
| JakeSays | i won't waste his time. that model is not a viable option for us. | 19:30.05 |
| | ah hmm. actually, gs itself wouldnt have to be distributed, nust redmon | 19:38.12 |
| | *just | 19:38.14 |
| Robin_Watts | Right, so the redmon terms may be different, I have no idea. | 19:38.34 |
| | tor8: ping | 20:21.52 |
| | Oh, never mind. I see. | 20:23.04 |
| | tor8: Loads of commits for review, please. | 20:34.04 |
| | paulgardiner: I've pushed yours. Thanks. | 20:34.16 |
| Ollea | Thanks for help guys, my problem was just that gs binary could not be found... | 23:52.02 |
| | Forward 1 day (to 2012/12/19)>>> | |
IRC Logs