| | <<<Back 1 day (to 2011/07/25) | 2011/07/26 |
| henrys | sorry that last commit should have been "cluster_untested" | 01:10.57 |
| kens | Hmm here's a silly question.... | 12:06.03 |
| | If I've added a file to the build, how can I cluster push it ? | 12:06.21 |
| chrisl_r61 | How do you mean? | 12:06.37 |
| kens | Local build works OK. When I cluster push it it doesn't seem to copy the new file. | 12:06.58 |
| | "make: *** No rule to make target `base/gdevagl.c', needed by `obj/gdevagl.o'. Stop." | 12:07.16 |
| | Which I'm assuming means that the new file gdevaglc. hasn't been copied to teh cluster | 12:07.45 |
| | I don't want to commit this until I know it builds.... | 12:08.06 |
| chrisl_r61 | Hmm, clusterpush doesn't specify individual files, so anything you add in psi, base etc (any directory not explicitly excluded) should be rsync'ed, I believe | 12:08.45 |
| kens | Hmm, well I guess I can go look on casper etc. | 12:09.06 |
| | err, peeves tha tis | 12:09.37 |
| | or i7b or something | 12:09.44 |
| | And indeed, the file is not present in /home/ken/ghostpdl/gs/base on peeves | 12:10.40 |
| chrisl_r61 | it doesn't seem to be on casper, either | 12:10.56 |
| kens | Well ,that#'s probably why it isn't copied to the nodes | 12:11.11 |
| chrisl_r61 | I take it the file should be in base? | 12:12.09 |
| kens | yes, indeed. | 12:12.16 |
| chrisl_r61 | Are you using clusterpush or gitpush? | 12:12.50 |
| kens | gitpush | 12:13.03 |
| | I guess I oculd fire up Linux. | 12:13.17 |
| chrisl_r61 | Ah, you probably need to at least git add, maybe even commit (but not push)? | 12:13.30 |
| kens | <sigh> OK, I'll try that then, thanks. | 12:13.43 |
| | Looks like the file is there this time, thankfully. | 12:23.45 |
| chrisl_r61 | Good, it might be worth sending an e-mail round mentioning that limitation on gitpush. | 12:28.08 |
| kens | I'll wait and see if it actually works this tiem :-) | 12:28.25 |
| chrisl_r61 | Fair point! | 12:28.49 |
| kens | Looks like ti built OK this teim, finally! | 13:03.17 |
| Robin_Watts | You need to git add at least, I think. | 13:08.41 |
| kens | Id did a git add and that seems to be working OK | 13:08.53 |
| | I hadn't realised I needed to previously | 13:09.06 |
| chrisl_r61 | Robin_Watts: this UNICODE/UTF8 API thing, did you establish sags's concerns were correct? | 13:13.26 |
| Robin_Watts | chrisl_r61: No. | 13:14.00 |
| kens | Mail sent to tech about gitpush and new files. | 13:14.00 |
| chrisl_r61 | kens: cool, thanks. | 13:14.10 |
| kens | I thought that the new code was better. | 13:14.10 |
| | because previously CJKV file/paths didn't work, and now they do. | 13:14.30 |
| Robin_Watts | I discussed it briefly with henrys and ray yesterday on here. | 13:14.35 |
| | Previously there was no way to make 16bit stuff work (but now, if you utf8 encode it yourself), you can. | 13:15.04 |
| | There is a difference in behaviour for people that used to put "raw" 8 bit stuff in. | 13:15.23 |
| | so people that pass extended ASCII paths. | 13:15.32 |
| chrisl_r61 | Robin_Watts: if it's the extended ASCII codes are a problem, could we a) document the API change, and b) supply an ascii to UTF8 function that we can point to and say "if the affects you, use this"? | 13:15.47 |
| Robin_Watts | ray was concerned that that would affect european customers. | 13:15.54 |
| | chrisl_r61: That sounds reasonable to me. | 13:16.33 |
| chrisl_r61 | I guess we'll talk about it in the meeting. | 13:16.53 |
| | Robin_Watts: I'm keen we keep the API as functionally similar on Unix and Windows as we can. | 13:18.31 |
| Robin_Watts | chrisl: Me too. The fact that we now perform on windows exactly as we have always done on linux/macosx seems right to me. | 13:25.13 |
| chrisl_r61 | Robin_Watts: exactly, and supplying a function which takes almost all the pain out of the transition is just polite. | 13:27.01 |
| Robin_Watts | we have char -> utf8 and utf8 -> wchar functions. | 13:28.00 |
| | but I'm not sure they are exposed. | 13:28.08 |
| chrisl_r61 | Ah, I thought it was just utf8 to wchar and back. | 13:28.30 |
| Robin_Watts | sorry, that was supposed to be wchar -> utf8 | 13:30.10 |
| | Keyboard is clearly dodgy today (not the operator, obviously) | 13:30.27 |
| tor8 | Robin_Watts: which utf8 conversion routines are you using? | 13:30.53 |
| Robin_Watts | My ones. | 13:31.02 |
| | i.e. ones specifically in the code; no additional dependencies. | 13:31.51 |
| tor8 | I guess we have about three different ones in the code now then :) | 13:32.00 |
| Robin_Watts | tor8: Probably. | 13:32.15 |
| tor8 | not that they're big or complicated or anyhing | 13:32.28 |
| Robin_Watts | Probably more than that, as I have 2 copies of mine; one inside the DLL, one outside. | 13:32.39 |
| tor8 | if you want speed, there's a very fast implementation here http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ | 13:33.10 |
| | in mupdf I use the ones from plan9 (where utf-8 originated) | 13:33.45 |
| Robin_Watts | Speed is utterly unimportant, I suspect. | 13:34.03 |
| | I went for clarity. | 13:34.07 |
| tor8 | right, looks very similar to the implementation in xps/xpsutf.c | 13:35.12 |
| Robin_Watts | tor8: How can I tell if we're in a type3 or not ? | 13:53.55 |
| kens | font->FontType | 13:54.23 |
| | If you mean running a CharProc, you cna't tell. | 13:54.48 |
| Robin_Watts | kens: This is mupdf :) | 13:54.55 |
| kens | well, you need to say :-) | 13:55.11 |
| Robin_Watts | and it's specifically when running a charproc. | 13:55.18 |
| | Either we need to modify all of mupdf to pass around some sort of graphics context (so we can know if we are in a type 3 or not) | 14:02.18 |
| | or we need to use a global (yuck!) | 14:02.28 |
| | or we could maybe add a flags word to the pixmap into which we are writing, one bit of which could mean "we are from a type3". | 14:05.54 |
| | But we'd need to be careful to update the flags word whenever we 'push' a group etc. | 14:06.25 |
| | tor8: ? | 14:08.20 |
| | There is, I think, a strong argument that passing a context around within mupdf would be a good thing. | 14:13.17 |
| | The context could be passed to every malloc/free/realloc etc too. | 14:14.21 |
| | But it's a larger change than tor8 might like right now. | 14:14.54 |
| tor8 | Robin_Watts: I was thinking of two ways | 14:20.15 |
| | one) image mask -> assume type3, color image fill -> grid fit | 14:20.33 |
| | two) add another flag bit to the device->hints | 14:20.43 |
| | option two is what the hints flag was added for :) | 14:21.16 |
| Robin_Watts | Ah, right. | 14:21.23 |
| tor8 | the hints are what we use to skip image and shadings processing for text extraction devices | 14:21.47 |
| henrys | kens:anything on the handle leaking we (miles) got an acceleration request for that particular problem - last I saw you were testing it for ray | 14:43.39 |
| kens | Ray's changes made it worse ofr me. | 14:43.58 |
| | I've been wrestling builds today | 14:44.55 |
| Robin_Watts | tor8: Bah. We don't get a device at the point we need it :( | 14:46.09 |
| kens | henrys I'll look some more | 14:46.18 |
| henrys | oh thanks | 14:47.30 |
| kens | No problem. | 14:47.38 |
| Robin_Watts | tor8: It's a shame that the device interfaces don't pass the device as the first pointer rather than user. | 14:47.56 |
| henrys | wonders why the commit email subject always says ghostpdl-9.02... | 14:48.14 |
| Robin_Watts | Especially as you can get the user from the device, but not the other way around. | 14:48.20 |
| henrys | ah we can test the x11 device Xvfb the wikipedia article has a sequence of commands to convert screen output to a raster file. | 15:05.04 |
| tor8 | Robin_Watts: d'oh! | 15:11.31 |
| Robin_Watts | tor8: I have a solution that seems neat. | 15:11.49 |
| | Just preparing a commit now for you to look at. | 15:11.58 |
| | ok, commit on casper. | 15:16.49 |
| | I'll run a sanity check now. | 15:16.54 |
| | oh, gawd. Lion has lost 'make' :( | 15:18.58 |
| tor8 | Robin_Watts: did you lose Xcode? | 15:20.22 |
| | my lion has make | 15:20.31 |
| Robin_Watts | rebooting now to see if it's a transient thing. | 15:20.45 |
| | I wonder if it's a ploy to make people spring for the new version of Xcode too. | 15:21.22 |
| tor8 | mine's in /usr/bin/make | 15:21.25 |
| | the Xcode on the app store is free if you have lion | 15:21.34 |
| Robin_Watts | downloading now. | 15:23.11 |
| henrys | anything special in lion for us? | 15:26.44 |
| | tor8? | 15:26.51 |
| tor8 | henrys: apart from a vastly unfriendlier user interface? not much. | 15:27.25 |
| | main thing is they finally got opengl 3 | 15:27.47 |
| henrys | I'll wait a bit then | 15:28.32 |
| Robin_Watts | The registers verdict was "worth it for macbooks, not so much for imacs" | 15:29.07 |
| | If you sprang for a multimouse thing, you'll be disappointed in that a lot of the new gestures etc don't work. | 15:29.36 |
| tor8 | henrys: I also think they made clang the default compiler for Xcode, but they still have gcc on the command line | 15:30.23 |
| henrys | what is the gdb version? | 15:31.04 |
| Robin_Watts | Do they have valgrind as standard yet ? | 15:31.29 |
| tor8 | 6.3.50 | 15:31.35 |
| henrys | I might skip lion entirely the way it sounds. | 15:32.37 |
| ray_laptop | that's really strange about the "correct" use of the semaphore and monitor free making handle leakage worse. | 15:33.15 |
| kens | ray_laptop : I need to look more. | 15:33.45 |
| | I'm stuck in gcc giving me warnings and trying to get rid of them. | 15:34.23 |
| ray_laptop | without it we don't call gp_semaphore_close which is what calls "CloseHandle" | 15:34.54 |
| | and similarly for monitor_close calling of DeleteCriticalSection | 15:35.32 |
| chrisl | henrys: the ghostpdl-9.02 in the mail subject is because it looks for the most recent tag that is an ancestor of the commit, but we're tagging on branches now, so the 9.03 tag isn't an ancestor. | 15:36.02 |
| henrys | chrisl:ah no big deal. | 15:36.31 |
| chrisl | henrys: we can easily "fix" it by making a suitably named tag on master, or fiddling the script for the hook. | 15:37.15 |
| henrys | chrisl:I don't feel strongly about it - we could just have nothing but the hash if it is a master branch commit. | 15:43.44 |
| chrisl | henrys: I agree it's not urgent, it's just the same question crossed my mind a few days ago, and your mentioned of it prompted me to go look. | 15:46.32 |
| tor8 | chrisl: won't not having 9.03 as an ancestor make it more difficult to bisect or examine history when you can't reasonably say between "9.03" and whatever anymore? | 15:49.42 |
| chrisl | tor8: I think bisect will still work, I did (very briefly) try it | 15:51.46 |
| | tor8: it does mention that "a merge base must be tested" | 15:53.10 |
| | not sure if that is relevant....... | 15:53.34 |
| tor8 | chrisl: one way would be to merge back from 9.03 and make a new tag 9.03-devel | 15:53.36 |
| chrisl | tor8: that would mess up master, I think. | 15:54.20 |
| tor8 | we got non-cherry-picked patches on the 9.03 branch? | 15:54.42 |
| chrisl | Yes, only one, I think, for disabling the UNicode stuff on Windows. | 15:55.08 |
| tor8 | right. makes sense to keep it as a branch then, I guess. | 15:55.39 |
| chrisl | I'm hoping that will be a rare occurence, so we could do as you | 15:56.28 |
| | Oops, wrong key..... | 15:56.38 |
| tor8 | chrisl: or tag the branch point as 9.03-rc | 15:57.40 |
| | if we just want nicer describe tags | 15:57.51 |
| chrisl | tor8: I'll have a think about it, having a tag appear in the ancestry would be good, if it can be done nicely | 15:59.05 |
| henrys | so meeting time! | 16:00.21 |
| | chrisl:how's the release and will we have a download page? | 16:01.11 |
| chrisl | henrys: so far, the release is okay, no one has hit the panic button, and I think we will have a download page..... | 16:01.41 |
| henrys | do we have blockers? | 16:02.46 |
| mvrhel2 | is it meeting time? | 16:03.10 |
| | oh yes it is | 16:03.14 |
| Robin_Watts | I'm seeing something strange here. A clean debug build of rev 5e68712 on windows is showing tiger.eps in grey on the display device. | 16:03.47 |
| henrys | alexcher:you hold the only blocker I can see int search | 16:03.52 |
| | s/int/in | 16:04.01 |
| | ray_laptop:if you didn't see the logs the customer has requested the priority of the handle leak be escalated. | 16:04.51 |
| chrisl | henrys: Robin_Watts and I briefly discussed the (possible?) problem with the UNICODE stuff that sags raised - I suggested we document the change, and include an (Extended) ASCII to UTF8 conversion function for the convenience of anyone who might be affected. | 16:05.13 |
| alexcher | henrys: yes, I know this. | 16:05.17 |
| kens | henrys I think I've sorted my build problems out. If my cluster etst comes back OK I'll commit it, and can look at the handles again tomorrow. | 16:05.40 |
| henrys | alexcher:what is the status of the problem - ray_laptop's fix should have addressed that right? | 16:05.55 |
| alexcher | henrys: I need to check this. I'm working on 692352 now. | 16:06.57 |
| henrys | alexcher:okay | 16:07.46 |
| | chrisl:yes I want to go out with documentation and the uft8 code. I'd say we can provide conversion upon request. | 16:08.36 |
| | s/conversion/conversion functionality | 16:08.55 |
| alexcher | henrys: The fix for 602352 is easy: call restore after drawing a shading but this causes SEGV in a bunch of files. | 16:09.07 |
| henrys | you mean 692 | 16:09.43 |
| alexcher | 692352 | 16:10.03 |
| chrisl | henrys: personally, I'd prefer to include the conversion ASCII to UTF functionality in the library - it won't be a transitional requirement for those that need to use it. | 16:10.15 |
| henrys | anybody else want to weigh in on the unicode stuff? | 16:10.16 |
| Robin_Watts | chrisl: People can lift the functions required for the conversion from gswin32 | 16:11.21 |
| henrys | chrisl:I was thinking the customer would like us to look at his code a provide consultation as to a best patch forward. | 16:11.29 |
| | s/patch/path | 16:11.40 |
| Robin_Watts | I'd rather not bloat the dll interface with an additional function. | 16:11.44 |
| | IMHO, etc. | 16:11.50 |
| chrisl | Robin_Watts: I thought you said it was only the UTF<->wchar functions that were already there? | 16:12.23 |
| Robin_Watts | they are in the gswin32 wrappers. | 16:12.43 |
| | and they are in the apps. | 16:12.51 |
| | but they are not exported as dll entrypoints. | 16:13.00 |
| henrys | mvrhel2:are you happy with the release? | 16:13.08 |
| Robin_Watts | I think this greyscale tiger thing is a blocker. | 16:13.27 |
| chrisl | Robin_Watts: Well, that's fine - if they are there for us to point a developer at, that's all I meant, really. | 16:13.33 |
| henrys | Robin_Watts:please make a bug. | 16:13.48 |
| Robin_Watts | Trying to isolate exactly when it was introduced now, but it looks like it may have been before the branchpoint. | 16:13.56 |
| henrys | or make the bug blocker | 16:13.58 |
| Robin_Watts | I'll make a bug in a mo (when I know what to report) | 16:14.21 |
| henrys | tiger has no color comes to mind. | 16:14.41 |
| kens | colorcir.eps has hte same problem | 16:14.54 |
| mvrhel2 | uh oh | 16:15.01 |
| henrys | device? | 16:15.08 |
| mvrhel2 | Is the device profile screwed up | 16:15.14 |
| kens | display device for me | 16:15.16 |
| Robin_Watts | windows display device. | 16:15.16 |
| | debugbin/gswin32c.exe examples/tiger.eps | 16:15.31 |
| kens | waterfal.ps gives an error "/undefinedfilename in (landcscap.ps)" which is different but equally bad. | 16:15.56 |
| Robin_Watts | bets on 9d37cdc | 16:16.02 |
| ray_laptop | henrys: I looked at the handle leak with the "Process Explorer". It shows LOTS more handles (>20) at exit compared to entry, the semaphore and monitor handles don't show on the list, nor in the count (when using the debugger), so this will be a difficult problem. unloading the DLL reduces the count by 7 but loading it increased it by 9! | 16:16.20 |
| chrisl | mvrhel2: should the default_rgb.icc commit be pulled into the release branch? | 16:17.17 |
| kens | Looks like all PostScript files are in greyscale | 16:17.21 |
| henrys | kens:is any particular display color model broken or all of them? | 16:17.50 |
| chrisl | tiger.eps is in full colour using x11 | 16:18.07 |
| kens | Well the default display device. I haven't tried anything else yet. | 16:18.08 |
| Robin_Watts | 9d37cdc is OK. | 16:18.24 |
| kens | PDF files are also rendered grey, just wanted to check that. | 16:18.46 |
| Robin_Watts | this might be looking bad for me... | 16:18.59 |
| kens | tiger is OK with tiff32nc. | 16:19.44 |
| | Looks like its a problem with the display device only | 16:19.53 |
| marcosw_ | mvrhel2: have all the changes that were going to alter all the bitmaps been committed? If so I'll start looking at the bitmap differences in the daily/weekly regression output. | 16:20.15 |
| henrys | kens, Robin_Watts:maybe just alpha is broken that is the default yes? | 16:21.15 |
| kens | alpha ? | 16:21.23 |
| | Don't think we have alpha in there | 16:21.29 |
| henrys | aa | 16:21.37 |
| Robin_Watts | henrys: No aa in the default windows display device. | 16:21.53 |
| | It's commit d3302b1 - sorry mvrhel2. | 16:22.02 |
| chrisl | x11 and x11alpha seem fine. | 16:22.20 |
| henrys | Robin_Watts:I think if should be the default. Doesn't it look bad? | 16:22.50 |
| Robin_Watts | It's never been the default before. | 16:23.06 |
| | AA would probably look nicer, yes. Certainly for text things. | 16:23.26 |
| henrys | well we (mvrhel2) just went through hell getting x11alpha to be the default on unix/mac exactly because we want aa | 16:24.07 |
| ray_laptop | it is the default when using GSview, so I agree that it should be on "regular" windows | 16:24.45 |
| mvrhel2 | sorry stepped out for 5 secs | 16:24.51 |
| | chrisl: yes please pull that in into the release | 16:25.02 |
| ray_laptop | but just TextAlphaBits, not GraphicsAlphaBits | 16:25.09 |
| chrisl | mvrhel2: thanks | 16:25.11 |
| mvrhel2 | marcosw_: I am trying to do one more that may have changes | 16:25.20 |
| Robin_Watts | henrys: Can we do that after the release? | 16:25.34 |
| marcosw_ | okay, I'm happy to wait rather than look at the files twice. | 16:25.38 |
| mvrhel2 | I would like to replace the default_cmyk.icc profile which is the SWOP CMYK V2 profile with one of our own construction | 16:25.55 |
| henrys | Robin_Watts:yes I suppose I'll put it on my list so we don't forget. | 16:26.07 |
| mvrhel2 | there will/may be minor diffs introduced from this | 16:26.07 |
| ray_laptop | mvrhel2: the input CMYK or the output CMYK ? | 16:26.23 |
| mvrhel2 | both | 16:26.41 |
| | default_cmyk | 16:26.45 |
| Robin_Watts | henrys: It's probably completely safe, but given that we don't do any cluster testing of the windows display device, a long run in before a release seems smarter. | 16:26.46 |
| ray_laptop | mvrhel2: IMHO we should use the same CMYK as Acrobat does "out of the box" | 16:26.54 |
| mvrhel2 | I am trying to understand the license for that profile | 16:27.13 |
| henrys | marcosw_:I found a way we can test X11 and would like to have it tested in the weekly, I also sent mail about pxlcolor and pxlmono. | 16:27.22 |
| ray_laptop | because this has caused a few 'wrong color' bug reports in the past | 16:27.25 |
| marcosw_ | I'm not sure if this should be a release blocker, but Ghostscript compiled on Mac OS X Lion has broken pkmraw output (and possibly others): http://www.ghostscript.com/~marcos/test.png | 16:27.28 |
| | this is not limited to head, older versions fail the same way, as do debug builds. | 16:27.46 |
| ray_laptop | marcosw_: but on older OS's we are OK ? | 16:28.13 |
| marcosw_ | yes. It's only the current Mac OS we fail on. | 16:28.29 |
| henrys | marcosw_:can you create a bug. | 16:28.50 |
| | ? | 16:28.51 |
| ray_laptop | marcosw_: just running the same binary ? | 16:28.51 |
| marcosw_ | no, gs has to be compiled on Lion | 16:29.10 |
| chrisl | marcosw_: what compiler are they using now? | 16:29.13 |
| marcosw_ | henrys: will do. | 16:29.16 |
| Robin_Watts | tor8 said that default compilers had changed from gcc to clang. | 16:29.16 |
| marcosw_ | chrisl: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) | 16:29.30 |
| ray_laptop | marcosw_: I meant, if we build a binary on an older version of macos, does it fail on lion ? | 16:29.31 |
| marcosw_ | ray_laptop: no, it only fails if build on Lion (I think I said that already). | 16:30.07 |
| | s/build/built/ | 16:30.12 |
| mvrhel2 | ray_laptop: I am wondering if we need to have Miles review this | 16:30.26 |
| | http://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_dist.html | 16:30.27 |
| ray_laptop | marcosw_: sorry I didn't catch that. | 16:30.31 |
| Robin_Watts | makes greyscale tiger bug for mvrhel2. | 16:31.01 |
| ray_laptop | marcosw_: sounds like something we should bump upstream to Apple and put an alert in our "News.htm" | 16:31.18 |
| | but I'm not sure it should be a bug for us. | 16:31.57 |
| marcosw_ | I suppose we could drop support for Mac OS X, it seems a shame to do it now that they are gaining market share. | 16:33.24 |
| chrisl | Robin_Watts: what happens if you explicitly set ProcessColorModel? | 16:33.36 |
| henrys | mvrhel2, ray_laptop:is this the same license as the cmaps? | 16:33.52 |
| ray_laptop | mvrhel2: quite a CYA EULA :-( Definitely written by lawyers. | 16:34.11 |
| Robin_Watts | chrisl: Command line ? | 16:34.26 |
| mvrhel2 | for us following item 3 is the one of interest | 16:34.33 |
| ray_laptop | mvrhel2: the CMap license is MUCH more friendly | 16:34.34 |
| chrisl | Robin_Watts: er, not sure, was just looking for it....... | 16:34.46 |
| marcosw_ | opened http://bugs.ghostscript.com/show_bug.cgi?id=692375 | 16:34.54 |
| kens | Causes an unrecoverable error for me. | 16:34.57 |
| mvrhel2 | ray_laptop: it depends upon our license agreement. we need to make sure that we state that Adobe is clear of any liabilities | 16:35.41 |
| marcosw_ | btw, Snow Leopard gcc is the virtually the same version as Lion: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664) | 16:35.56 |
| henrys | 5 minutes after meeting over - please mark bugs blockers if you think the release should be held up for them. | 16:36.06 |
| mvrhel2 | I have no idea how that works with a GPL license though | 16:36.49 |
| ray_laptop | mvrhel2: well, that's pretty easy to add to our LICENSE file | 16:37.08 |
| Robin_Watts | mvrhel2: This is sidestepped by you replacing the profile with an equivalent one ? | 16:37.13 |
| mvrhel2 | yes | 16:37.19 |
| Robin_Watts | Well, that'd be my vote then. | 16:37.26 |
| henrys | ray_laptop:I think we left it with a utf-8 release but you didn't say anything - maybe you missed the conversation. | 16:37.28 |
| mvrhel2 | I replaced the sRGB profile with one of my own creation | 16:37.28 |
| | since that is copyrighted by HP and I could not find out anything about who "owns" that | 16:37.45 |
| | the spec is very clear about sRGB though and it is easy to create your own | 16:38.02 |
| | SWOP V2 CMYK is a bit trickier | 16:38.10 |
| chrisl | Robin_Watts: you could try something like (he guesses) : gswin32c -c"<</ProcessColorModel /DeviceRGB>> setpagedevice" -f ../examples/tiger.eps | 16:38.32 |
| mvrhel2 | as we have to do some reverse engineering | 16:38.36 |
| kens | chrisl -sProcessColorModel=DeviceRGB. causes an error in putdeviceprops for me. | 16:39.05 |
| Robin_Watts | chrisl: Still grey. | 16:39.13 |
| kens | I don't think the device lets you do that. | 16:39.14 |
| chrisl | Oh well, just a thought...... | 16:39.40 |
| ray_laptop | mvrhel2: something like "any portions of this software from Adobe Systems are distributed under the terms in the Adobe EULA (and put in the URL) or the license within the file and Adobe bears no responsibility" | 16:39.47 |
| mvrhel2 | I would think that would be sufficient | 16:40.10 |
| Robin_Watts | Yes, but I can imagine it being a pain for Miles. | 16:40.27 |
| | Lots of people asking "what portions are from Adobe?" | 16:40.37 |
| mvrhel2 | do we not have something in there like this for the CMaps? | 16:40.56 |
| ray_laptop | henrys: w.r.t. the UNICODE (or NO_UNICODE) I'll accept whatever you all think (but reserve the right to say "I told you so" later). | 16:41.08 |
| kens | The CMaps have their own licence header | 16:41.19 |
| mvrhel2 | ok | 16:41.23 |
| Robin_Watts | At worst, any customer that has a problem with have to build with WINDOWS_NO_UNICODE to get the old behaviour back. | 16:41.43 |
| ray_laptop | mvrhel2: We distribute the CMaps in source form so the license is in there. | 16:41.44 |
| Robin_Watts | We've got to cut the cord at some point... | 16:41.55 |
| ray_laptop | mvrhel2: and we _do_ mention the CMaps in the LICENSE file | 16:42.18 |
| henrys | mvrhel2:this would require (by my read) miles to update the customer contracts which he generally doesn't like to do. | 16:42.37 |
| ray_laptop | Robin_Watts: at the very worst, we'll have to ship binaries BOTH ways | 16:42.52 |
| mvrhel2 | ok. let me make a cut and making a profile that is very close to the swop one | 16:42.53 |
| | That is what I am testing right now | 16:43.06 |
| | If you recall this came up at the last meeting and I meant to look into it earlier rather than right before the release. sorry about this | 16:43.53 |
| | ok. so when did I break the display device? | 16:44.26 |
| henrys | the unicode issue is handed off to chrisl and Robin_Watts | 16:44.33 |
| Robin_Watts | d3302b1 | 16:44.36 |
| | Bug 692374 | 16:45.05 |
| chrisl | ray_laptop: how many of our customers and users actually use the library API, rather than just the executable that drops out of our build? | 16:45.28 |
| ray_laptop | henrys: I don't think we have to update the contracts, but the 'end user' verbiage is a bit of a bear. | 16:45.32 |
| mvrhel2 | how do I search on d3302b1 | 16:45.48 |
| | I try on the web interface | 16:46.05 |
| ray_laptop | chrisl: about half of the customers use the API | 16:46.11 |
| | chrisl: and MANY users use GSView which uses the API extensively | 16:47.00 |
| Robin_Watts | * d3302b1 Fix for bug 692204. This forces DeviceGray to K only for CMYK device | 16:47.07 |
| mvrhel2 | oh | 16:47.26 |
| ray_laptop | chrisl: and some customers license GSView and use that with the Artifex Ghostscript | 16:47.39 |
| kens | I tried setting teh GrayToK to fals,e and it made no difference | 16:47.50 |
| chrisl | ray_laptop: hmm, more than I thought. But as Robin_Watts says, we have to enable it at some point - when would you advocate doing so? | 16:48.02 |
| mvrhel2 | ah. well I wanted to change that commit message | 16:48.11 |
| henrys | ray_laptop:if you don't want end users to agree: ... "or your own license agreement which (a) complies with the terms and conditions of this Agreement; (b) effectively disclaims all warranties and conditions, express or implied, on beh | 16:48.23 |
| | alf of Adobe; (c) effectively" ... | 16:48.23 |
| mvrhel2 | there is no GrayToK setting. | 16:48.25 |
| ray_laptop | chrisl: I think we need to give them at least one release wanring. | 16:48.27 |
| mvrhel2 | I will get the docs updated on all of that soon | 16:48.36 |
| kens | mvrhel2 DeviceGrayToK | 16:48.43 |
| | -dDeviceGrayToK=false from the commit log | 16:48.59 |
| Robin_Watts | ray_laptop: People have repeatedly claimed on here that customers NEVER read release warnings. | 16:49.04 |
| mvrhel2 | that commit message is wrong | 16:49.08 |
| | sorry | 16:49.10 |
| kens | Well, that probably explains why it made no difference ;-) | 16:49.23 |
| ray_laptop | chrisl: and give Russell time to develop and distribute a version of GSView that works both ways. | 16:49.50 |
| henrys | I thought we got as far as enabling utf8 and were fussing over details | 16:49.53 |
| mvrhel2 | hehe. It is actually DeviceGrayToKOff=true | 16:50.12 |
| | or just do -dDeviceGrayToKOff | 16:50.21 |
| | that should give you color | 16:50.32 |
| kens | let me try | 16:50.39 |
| chrisl | ray_laptop: our original plan was to release with UNICODE handling "on", and build two sets of binaries one with it on and one off. Anyone that has problems we can point them to "disabled" exe, and warn them that the option will not be there in the future. | 16:50.40 |
| mvrhel2 | the thing I need to dig into is why it is seeing all the source colors as DeviceGray | 16:51.00 |
| kens | -dDeviceGrayToKOff makes no differenec either, still gray | 16:51.16 |
| mvrhel2 | or it is getting screwed up with the hash code | 16:51.20 |
| | weird. ok let me look at it | 16:51.26 |
| | any magic settings needed with the display device? | 16:51.54 |
| kens | none | 16:52.00 |
| | I tried a few DisplayFormat settings bu they all came out gray | 16:52.15 |
| henrys | mvrhel2:so do we still need an out of bounds release after this or are we set? | 16:52.17 |
| ray_laptop | mvrhel2: DeviceGrayToKOff seems a bit awkward. Why not just DeviceGrayToK=true/false ? | 16:52.21 |
| mvrhel2 | it is always on by default | 16:52.44 |
| ray_laptop | mvrhel2: fine so DeviceGrayToK=false turns it off | 16:53.08 |
| mvrhel2 | ok. I can change it to that | 16:53.17 |
| | let me fix the gray tiger first | 16:53.29 |
| kens | And then the log message will be correct :-) | 16:53.34 |
| mvrhel2 | ha | 16:53.39 |
| | yes I guess there was a reason for that | 16:53.48 |
| | I think though I was running into an issue | 16:53.57 |
| | now I remember why I did it this way | 16:54.05 |
| kens | More important to fix the output | 16:54.10 |
| ray_laptop | mvrhel2: yes, the "everything going gray" is much more serious | 16:54.13 |
| mvrhel2 | henrys: what do you mean an out of bounds release after this? | 16:55.14 |
| ray_laptop | mvrhel2: if it's about setting the default in the PS, that's easy to handle | 16:55.48 |
| mvrhel2 | ray_laptop: yes that is the issue | 16:56.02 |
| | I may drag you or alexcher in to help me with that | 16:56.16 |
| alexcher | OK | 16:56.25 |
| mvrhel2 | there was an initialization setting that was getting screwed up with the device params and the order of things | 16:56.43 |
| | as usual | 16:56.45 |
| | henrys: so first I need to get this gray issue fixed. then I would like to get the CMYK profile changed | 16:57.15 |
| ray_laptop | mvrhel2: see the way ORIENT1 is handled in gs_init.ps -- that one is set to 'true' by default if it is not set as an option | 16:57.39 |
| mvrhel2 | ray_laptop: ok thats | 16:57.56 |
| | thanks | 16:57.58 |
| henrys | mvrhel2:do you owe anything to the customers you visited that should be delivered as a release before next February and after the 9.04 release? | 16:58.02 |
| mvrhel2 | henrys: no all of that stuff is in | 16:58.12 |
| | I do need to update the documentation though | 16:58.18 |
| | with respect to all of that | 16:58.23 |
| henrys | okay thanks | 16:58.28 |
| ray_laptop | mvrhel2: there are SWOP ICC profiles from other than Adobe aren't there ? (some color consortium or the other) | 16:58.33 |
| kens | hates the build ssytem | 17:00.57 |
| | I'm going to go and cook dinner and sulk. | 17:01.12 |
| | Be back later. | 17:01.17 |
| henrys | kens means build system(s) | 17:01.26 |
| ray_laptop | IMHO, calling an ICC profile "software" is quite a stretch. It's just a bunch of data -- like saying a telephone number list is 'software' just 'cause you can download it | 17:01.48 |
| | by kens | 17:02.23 |
| mvrhel2 | ray_laptop: I agree. there used to be some SWOP profiles running around (e.g. http://www.swop.org/resources/downloads.asp) but I don't see any profiles there. | 17:02.26 |
| ray_laptop | bye, that is | 17:02.30 |
| | mvrhel2: what about the color.org profiles ? http://www.color.org/registry/index.xalter | 17:07.23 |
| mvrhel2 | hmm. let me look into those | 17:08.20 |
| | they did not have these up a while back when I looked | 17:08.35 |
| Robin_Watts | tor8: Does that patch look OK to you? | 17:09.12 |
| sags | Hi all, I see the GSAPI-versus-utf8 came into discussion. | 17:13.06 |
| ray_laptop | mvrhel2: the license from the IDEAlliance looks pretty friendly: This profile is made available by IDEAlliance, with permission of X-Rite, Inc., and may be used, embedded, exchanged, and shared without restriction. It may not be altered, or sold without written permission of IDEAlliance. | 17:13.35 |
| mvrhel2 | ray_laptop: the question will be, how close is it to the Adobe one.... | 17:14.32 |
| sags | What I think is also important to say is that "doing the right thing" does not require a lot of code or complications. | 17:14.32 |
| ray_laptop | but the 'may not be sold without written permission' seems to be at odds with "exchanged and shared without restriction" | 17:14.40 |
| mvrhel2 | yes | 17:14.50 |
| ray_laptop | mvrhel2: what profiles are the unix printing people using in their ICC push ? | 17:16.06 |
| mvrhel2 | ray_laptop: that is a very good question | 17:16.25 |
| | let me email a couple people on that | 17:16.38 |
| henrys | sags:I am a little uncertain about "right thing", with the change the windows platform is now consistent with mac os x and linux, unless I'm missing something. | 17:17.29 |
| chrisl | henrys: I'm wondering if we should make it run-time option? | 17:18.17 |
| sags | @henrys "the windows platform is now consistent with mac os x and linux": No, I dont' consider to be so. I'll explain. | 17:18.31 |
| | Until now, all paltforms used "whatever encodign the host uses". Because of this, the problem on character encoding was kind of ignored. | 17:19.21 |
| henrys | sags:it would be useful to have a reference bug with an example. | 17:19.25 |
| sags | Now, for Windows only, GS uses an encoding that differs from everything that's common on that platform. | 17:19.57 |
| ray_laptop | henrys: the issue with linux is simple because the arguments come in as UTF-8 so if a german guy types ü it comes in as that, but Windows is different | 17:20.23 |
| sags | @henrys: I wanted to open a bug, bug I'm currently stuck at gsapi_set_display_callback() and gsapi_set_visual_tracer(). These are not so important as the others, but I wanted an eventual proposed patch to be complete. | 17:21.19 |
| ray_laptop | sags: you can open a bug without a solution -- just say you are working on it and assign it to yourself until it's done, then assign it to someone else for 'review' | 17:22.41 |
| mvrhel2 | well that is interesting. for some reason the display device is getting the gray icc profile | 17:23.26 |
| ray_laptop | mvrhel2: well that would explain why it looks gray ;-) | 17:24.02 |
| mvrhel2 | yes | 17:24.05 |
| sags | Well, I'll to do that. It will take some time to explain everything [in English]. I'm not a good writer... | 17:24.15 |
| mvrhel2 | oh | 17:25.47 |
| Robin_Watts | alexcher: ray_laptop: I have my mkromfs ps compaction stuff working, using binary encodings now. | 17:31.59 |
| | but, I assume that the currentobjectformat is non zero. | 17:32.19 |
| | (i.e. that binary encodings are allowed). | 17:32.28 |
| | That seems to be the default setting. | 17:32.35 |
| | Is it OK to assume that, or do I need to wrap the files in: currentobjectformat 1 setobjectformat ... setobjectformat | 17:33.13 |
| alexcher | Robin_Watts: I think it's OK to assume that binary encoding is available. This is our interpreter and we can ensure this. | 17:38.59 |
| Robin_Watts | Well, if someone does: 0 setobjectformat and then tries to execute one of those files, it will fail. | 17:39.39 |
| | but if you know they are all read in a state where binary encoding is OK, that's great. | 17:40.07 |
| | The one file I can't currently safely binary compact is the new merged gs_init.ps | 17:40.36 |
| | Am I right in thinking that binary encodings are not available until after the gs_btokn.ps file has been read | 17:41.07 |
| | ? | 17:41.23 |
| alexcher | Robin_Watts: I don't know how gs_btoken.ps works. | 17:42.43 |
| Robin_Watts | well I have no hope then :( | 17:43.12 |
| | If I put binary encodings in at the start of gs_init.ps it fails with no error. | 17:43.36 |
| | (after the 904, obviously). | 17:43.47 |
| alexcher | Robin_Watts: We can make assumptions about the environment during start-up but cannot do this with resource files. | 17:44.18 |
| Robin_Watts | binary encodings are only available in level 2, so do I have to wait for the interpreter to "switch" to be language level 2 ? | 17:44.25 |
| | alexcher: Right, that's what I was afraid of. | 17:44.42 |
| | That would suggest I need to wrap the resource files. | 17:44.54 |
| alexcher | Robin_Watts: Files in Resource/init directory are not resources. | 17:46.07 |
| Robin_Watts | alexcher: Right. | 17:46.16 |
| | I have 2 classes of files I am dealing with here. | 17:46.26 |
| | 1) Those in Resource/Init that all (mostly) get merged together into a flattened gs_init.ps | 17:46.46 |
| | and 2) The other files (Resource/CMAP etc) | 17:47.03 |
| | I've curently got files of class 2 being compacted with binary encoding, and that seems to work, but it's not properly safe - I need to wrap them. | 17:47.52 |
| alexcher | Robin_Watts: There were plans to drop Level 1 support but nothing is done yet. | 17:48.16 |
| Robin_Watts | I'd like to be able to use binary encoding on the flattened gs_init.ps from 1) too. | 17:48.21 |
| tor8 | Robin_Watts: two nits, otherwise looks good to me. | 17:48.37 |
| Robin_Watts | But to do so, I need to wait until a point in the startup when we swap to level 2. | 17:48.51 |
| tor8 | Robin_Watts: alpha == 1.0 should be alpha == 1 (or 1.0f) to avoid doubles | 17:48.55 |
| henrys | alexcher:I'd really like you to start at least thinking about that (deprecating level 1) maybe a todo list that we could review at the meeting would be a good start. | 17:49.21 |
| Robin_Watts | I was considering having a INARYOK comment in the source to trigger me turning on binary encodings. | 17:49.31 |
| tor8 | Robin_Watts: (float)(int)h -- I guess you mean to floor h, I use floorf(h) elsewhere in the code | 17:49.32 |
| Robin_Watts | No. I definitely DIDN'T mean floor. | 17:49.48 |
| | bah. That should have read "PERCENT BINARYOK" :) | 17:50.16 |
| | alexcher: Does that seem feasible to you? Where would such a place be to put that comment (if you know). | 17:50.50 |
| alexcher | Robin_Watts: A magic comment is fine for me. | 17:50.55 |
| Robin_Watts | tor8: floor is hugely slow, and doesn't seem justified here. | 17:51.13 |
| tor8 | Robin_Watts: so you're doing fract() (if such a function had existed)? | 17:51.39 |
| alexcher | Robin_Watts: I need to look at the code. | 17:51.52 |
| tor8 | erm, I mean the opposite of fract | 17:52.08 |
| Robin_Watts | some languages call it int(). | 17:52.40 |
| tor8 | I have no idea which is faster, converting to int and back or doing floor or truncate-towards-zero. I'll trust your judgement on that :) | 17:53.39 |
| Robin_Watts | I had to handle a bug in gs a while ago, where floor was being used in a shading, and hence being called a lot. | 17:54.08 |
| | It *really* hurts because of all the error checking it does. | 17:54.21 |
| | (floor)(int) is much faster. | 17:54.43 |
| tor8 | right. we use floorf (gah! I hate lion's default behavior of correcting spelling mistakes automatically) in a lot of places | 17:55.35 |
| Robin_Watts | ok, reinstalling Xcode seems to have helped. Runing sane now. | 17:56.29 |
| tor8 | many of them where I really just want fract() | 17:56.31 |
| Robin_Watts | Damn. Now compare appears borked. | 17:57.52 |
| ray_laptop | Robin_Watts: a magic comment like % Binary OK seems consistent with the other things in the init files that are there to support mashing together the gs_init.ps files together. Good luck in finding out exactly where it's OK to switch to binary tokens ;-) | 17:58.34 |
| Robin_Watts | tor8: Do you have sane working on your machine at the moment ? | 18:01.47 |
| ray_laptop | Robin_Watts: I guess you can just start inserting the binary for a '0 pop' and seeing where to put in the comment | 18:05.24 |
| Robin_Watts | ray_laptop: Yes, I was doing something like that already to figure out that they didn't work at the start. | 18:05.58 |
| | I'm fearful that the code might swap into/out of language level 2 several times. | 18:06.18 |
| | so I may have to have INARYON INARYOFF, which could get old very fast... | 18:06.36 |
| henrys | can this be put of until we get rid of level 1? | 18:06.55 |
| Robin_Watts | henrys: yes. | 18:07.42 |
| | I can just commit what I've got now with binary disabled. | 18:07.50 |
| mvrhel2 | so if everyone could live with the minor diffs shown in my bmpcmp, then I may just replace the profile. The new profile is 184KB versus Adobes 545KB | 18:08.17 |
| | Visually I dont notice the diffs | 18:08.34 |
| | Robin_Watts: how do I run with a threshold for bmpcmp again? | 18:08.47 |
| Robin_Watts | mvrhel2: bmpcmp -t 16 | 18:08.58 |
| mvrhel2 | ok let me do that | 18:09.04 |
| henrys | alexcher:another idea isn't there an easy way to make binary part of level 1 , if we are willing to deprecate level 1 I assume an extra operator or 2 that doesn't belong won't matter. | 18:09.25 |
| ray_laptop | Robin_Watts: you probably need to look every place that invokes .setlanguagelevel | 18:11.29 |
| Robin_Watts | I'm going to follow henrys suggestion and wait for level 1 to go away. | 18:11.50 |
| alexcher | henrys: yes, this should be a relatively small change. | 18:12.28 |
| henrys | Robin_Watts:so 2 options | 18:13.14 |
| henrys | wonder if sags would be interested in getting rid of level 1 for us. | 18:13.35 |
| ray_laptop | Robin_Watts: the scanner (psi/iscan.c) require objectformat > 0, then it looks like it is enabled in the scanner (it calls scan_binary_token) | 18:14.59 |
| | Robin_Watts: it doesn't look like it checks for the current languagelevel | 18:15.27 |
| Robin_Watts | ray_laptop: Looks like gs_lev2.ps sets the object format. | 18:17.12 |
| henrys | ray_laptop, Robin_Watts:what is the net rom decrease from binary everything else beign equal? | 18:17.32 |
| Robin_Watts | 300Kish, mostly from cmaps. | 18:17.53 |
| kens | Ah crap, it *still* doesn't build :-( | 18:17.58 |
| ray_laptop | Robin_Watts: ooops. the code uses: #define recognize_btokens() (ref_binary_object_format.value.intval != 0 && level2_enabled) and level2_enabled works out to ( | 18:18.02 |
| | i_ctx_p->language_level >= 2) | 18:18.04 |
| Robin_Watts | kens: on windows? | 18:18.08 |
| kens | On the cluster, Windows is just fine. Locally | 18:18.22 |
| Robin_Watts | ok, cos I think I've broken windows builds at the moment. | 18:18.41 |
| kens | No, this one's mine :-( | 18:18.51 |
| | I'm trying to only have one copy of the Adobe Glyph List | 18:19.14 |
| ray_laptop | Robin_Watts: so if it i only 300K for the CMaps, the extra for the compacted+merged gs_init won't be much (since it is only 150k now) | 18:19.40 |
| kens | <thud> Didn't copy the .c file again.... | 18:19.44 |
| henrys | ray_laptop:by the way I noticed we are distributing many more cmap files than adobe at least on mac os x. How was it decided which maps to include? | 18:27.18 |
| alexcher | Robin_Watts: We need to develop a new binary format for CMap files and add corresponding operators to CIDInit ProcSet. | 18:32.37 |
| | Robin_Watts: It is better to keep CMap files in compact external form because they are rarely used. | 18:33.23 |
| Robin_Watts | alexcher: Well, mupdf has the data in a compact format. | 18:33.30 |
| | and it's a form where we can search quickly through the data. It's a shame to have to unpack it to use it. | 18:35.33 |
| alexcher | Robin_Watts: It's shame. UniCNS-UCS-H is 326K uncompressed and takes 506K loaded. | 18:45.56 |
| Robin_Watts | The C *source* for cmap_cns.h in mupdf is 590K. | 18:46.45 |
| | so it's much smaller when compiled. | 18:47.05 |
| | and we never unpack it. | 18:47.11 |
| kens | finally, its running tests | 18:49.51 |
| ray_laptop | henrys: I don't know how the CMap set was decided on. alexcher may know -- he has added some on occasion and updated them | 18:49.56 |
| | kens: I dumped the bug 689592 back to you -- feel free to leave it as an enhancement or close it to the LATER (like never) state | 18:50.47 |
| kens | OK ray | 18:51.53 |
| ray_laptop | henrys: I'm fine with distributing a subset of the CMaps that we have now, or maybe just having a subset identified for sensitive customers (like 711) | 18:53.02 |
| henrys | ray_laptop:I don't know what is standard on CPSI or windows I just looked at the mac. | 18:54.22 |
| alexcher | ray_laptop: We've collected every CMap published. It was OK when all files were on disk. | 18:56.48 |
| ray_laptop | henrys: CPSI (PhotoPrint) has 159 CMap files. we have 242 | 18:58.01 |
| | henrys: I see 143 CMaps with my Acrobat 9.0 | 19:00.19 |
| | we could keep them in the source distribution for anyone that wanted them but move the others to CMap_other (or some suitable name) or just delete them (letting git keep them for anyone). | 19:01.39 |
| | Adobe's set starts out as 7.2M ours is 11.2M so that's even a better win that compressing | 19:04.35 |
| | henrys: who do you want to do the clean-up (and do you prefer keeping them in the tarball or not) ? | 19:05.33 |
| | henrys: and do you want the union of the Acrobat and CPSI list (it may be more than 159), or do we just go with Acrobat's set ? | 19:06.51 |
| henrys | ray_laptop:let's look at the union first then decide. | 19:07.45 |
| | alexcher should do the project. | 19:07.59 |
| ray_laptop | hmm... there is one that Adobe has that we don't: Adobe-CNS1-ETen-B5 | 19:08.34 |
| mvrhel2 | Robin_Watts: so with the -16 on the bmpcmp all the contone diffs seem to have gone away and only the halftone diffs are left. If everyone is fine, I am going to replace default_cmyk then. The diffs are small (unnoticeable) the profile is less than half the size and we dont have to worry about having Miles change any licenses. | 19:09.06 |
| Robin_Watts | mvrhel2: Sounds like a plan to me. | 19:09.23 |
| mvrhel2 | henrys ray_laptop (and anyone else) are you ok with this? | 19:09.39 |
| ray_laptop | henrys: if you open a bug, I'll add the CPSI list to it (although alexcher may already have a copy of CPSI) and I'll mention the Adobe-CNS1-ETen-B5 that Acrobat has that we don't | 19:09.51 |
| henrys | I am good mvrhel2 | 19:09.55 |
| ray_laptop | mvrhel2: sounds great | 19:10.16 |
| henrys | ray_laptop:sounds good. | 19:10.46 |
| | alexcher? | 19:10.53 |
| ray_laptop | I have to run an errand. bbiaw. | 19:10.57 |
| alexcher | henrys: I don't have PhotoPrint installed. | 19:11.12 |
| Robin_Watts | mupdf has 150, I think. | 19:12.15 |
| henrys | okay so ray_laptop is going to give you the list | 19:12.22 |
| Robin_Watts | henrys: This new board I'm supposed to be getting. Is that from a new customer? | 19:12.59 |
| henrys | yes company i | 19:13.16 |
| Robin_Watts | The mupdf customer ? | 19:13.30 |
| henrys | no gs | 19:14.08 |
| Robin_Watts | ok. new one on me then. | 19:15.01 |
| henrys | tor8:what was the source of your list of cmaps to include in mupdf? | 19:17.51 |
| tor8 | henrys: I started with the set from the PDF spec, but I've had to extend the list due to files in the wild. now I use all the cmaps that were released in the cmap resource release that ken lunde prepared with the new license | 19:19.12 |
| | the ones from here http://sourceforge.net/projects/cmap.adobe/files/ | 19:20.54 |
| Robin_Watts | tor8: OK. Updated commit. | 19:20.55 |
| | tor8: If you could sane that for me I'd be very grateful. No telling how long this will take me to get everything working on my macbook again, and I'd like to close the bug for the customer. | 19:21.47 |
| tor8 | Robin_Watts: what changed in the new commit? | 19:22.21 |
| Robin_Watts | 1.0 to 1.0f | 19:22.27 |
| | That was what you wanted, right ? | 19:22.53 |
| kens | Damn. I think I've gone and applied Ray's semaphore fix by accident | 19:24.08 |
| henrys | ray_laptop:just send me your cpsi list and I'll sort it out. | 19:24.08 |
| ray_laptop | kens: That's no problem. It _really_ should be fixed (IMHO) despite the ambiguous results that you saw. | 19:25.09 |
| kens | Drat, I have. Oh, OK Ray, then I'll leave irt just now. | 19:25.22 |
| | I've spent so long struggling with the build system and Giit I forgot I had that patch applied. | 19:25.52 |
| ray_laptop | kens: like I mentioned earlier, the handle count tracking with Process Explorer doesn't seem to make sense. | 19:25.56 |
| kens | Well, it made snese (for small values of sense) in my tests. | 19:26.16 |
| | It always started with 28 handles, and incremented by 2 for every loop iteration. | 19:26.32 |
| | But that *should* have neded with 128 handles (50 x 2 + 29) and it actually ended with 100. | 19:26.58 |
| | I'm puzzled by that one. | 19:27.22 |
| | But I'll look again at tit tomorrow, now my nice 'easy' fix is finally committed. | 19:27.43 |
| Robin_Watts | kens: Have you seen: http://technet.microsoft.com/en-us/sysinternals/bb896655 | 19:28.39 |
| | handle -a will list all the handles in use, of all types. | 19:28.52 |
| kens | That sounds useful, I'll fetch it tomorrow, thanks Robin | 19:29.04 |
| | OK I really am logging off now. Goodnight all. | 19:29.07 |
| Robin_Watts | np. | 19:29.09 |
| | night. | 19:29.11 |
| tor8 | Robin_Watts: lots of diffs. they look as expected :) | 19:29.30 |
| Robin_Watts | cool. | 19:29.38 |
| ray_laptop | kens: it just seems like too much coincidence that there were two places that didn't properly close semaphores and you were leaking two handles, but the handle number I get back for the semaphore doesn't show up on the Process Explorer list anyway | 19:29.44 |
| tor8 | I don't see any 1.0f's though, you sure you pushed? | 19:29.56 |
| ray_laptop | bye, ken (hope he checks the logs) | 19:30.00 |
| tor8 | I can make a "style fixes" patch if you prefer, it's not a big deal | 19:30.26 |
| Robin_Watts | tor8: I made the change on my repo on casper. | 19:30.40 |
| | Oh, I forgot to add. | 19:30.55 |
| | Look now ? | 19:31.16 |
| tor8 | my preference is for 1 (rather than 1.0f) but I guess you prefer 1.0f for the same reason you prefer parentheses around all expressions :) | 19:31.35 |
| Robin_Watts | avoidance of doubt. | 19:32.14 |
| tor8 | still says (alpha == 1.0) | 19:32.36 |
| Robin_Watts | Ah, right, sorry. | 19:33.50 |
| | I changed the other ones. try now ? | 19:33.56 |
| tor8 | Robin_Watts: great! | 19:34.47 |
| | Robin_Watts: pushed. | 19:39.27 |
| Robin_Watts | thanks. | 19:39.38 |
| | ray_laptop: tkamppeter: mvrhel2: I'll look into bug 692368 tomorrow. | 19:42.40 |
| henrys | I think we should go with Lundes release also in gs. We are also out of date on several files | 19:49.56 |
| MaMaGoody | hello, can I generate polygon with gs? | 19:59.40 |
| | from an eps | 19:59.56 |
| | like breaking curveto into lineto | 20:00.29 |
| Robin_Watts | gs contains no inbuilt facilities for converting curves to lines and then outputting those lines back to the user. | 20:02.38 |
| | But you could program such things in postscript, if you were so inclined. | 20:03.20 |
| | but it wouldn't be any easier than doing it in any other language. | 20:03.30 |
| MaMaGoody | Robin_Watts: thanks a lot. | 20:05.09 |
| Robin_Watts | ray_laptop: That's my mkromfs hackery in. | 20:08.30 |
| | Was there a bug for rom size issues? | 20:09.07 |
| | (dinner, bbl) | 20:09.12 |
| henrys | we've got some failed builds... | 21:49.02 |
| | the cmaps are now 5M lighter. | 22:30.58 |
| Robin_Watts | henrys: which builds failed ? | 23:12.46 |
| | oh, right. | 23:13.13 |
| | Forward 1 day (to 2011/07/27)>>> | |
IRC Logs
