| | <<<Back 1 day (to 2012/06/04) | 2012/06/05 |
| Gigs- | I'm trying to test the new gs with planar, it's been forever, how do I get it to run from the dev tree using the gslib that's there? I tried setting GS_LIB but it still seems to pick up 9.05 from the system directory | 13:21.19 |
| | --help shows the additional search path I told it in the environment, but its like it's ignoring it | 13:21.43 |
| Robin_Watts | hi Gigs | 13:30.21 |
| Gigs- | hi | 13:30.31 |
| Robin_Watts | I don't follow. | 13:31.13 |
| Gigs- | I'm trying to run the git head or whatever git calls the most recent rev directly from the build directory | 13:31.51 |
| Robin_Watts | Presumably you've cloned the git repo, and done ./autogen.sh, then make ? | 13:31.55 |
| Gigs- | yeah everything is built | 13:32.00 |
| Robin_Watts | Then just run it using gs/bin/gs | 13:32.15 |
| Gigs- | ~/gs/gs/sobin$ ls | 13:32.24 |
| | gsc gsx libgs.so libgs.so.9libgs.so.9.06 | 13:32.24 |
| | when I do that the banner says 9.05 | 13:32.36 |
| | there is a system installed 9.05 | 13:32.44 |
| | in usr/lib/ | 13:32.57 |
| Robin_Watts | You did "make so" or something ? | 13:33.05 |
| Gigs- | yeah I always use so | 13:33.21 |
| | it wouldn't be apples to apples if I didn't | 13:33.34 |
| Robin_Watts | I have no experience of the so build. You probably need chrisl... | 13:34.14 |
| Gigs- | one more question you might know.. I noticed I have a bunch of .ps and .upp files in /usr/share/ghostscript/9.05/lib/... I thought those ps init files were compiled in now | 13:34.52 |
| Robin_Watts | Gigs: The resource files are built in. | 13:35.44 |
| | Not all the lib is, AIUI. | 13:35.58 |
| | (but ICBR) | 13:36.07 |
| Gigs- | oh ok | 13:36.10 |
| henrys | Gigs:you have to install the library or use LD_LIBRARY_PATH | 13:36.31 |
| Gigs- | henrys: ok thanks I'll try that | 13:40.38 |
| chrisl | Robin_Watts: do you know if marcosw records the cluster parallel build failures anywhere? | 14:38.30 |
| Robin_Watts | chrisl: No. He literally does: make -j8 && make | 14:38.48 |
| chrisl | Oh, that's not terribly helpful :-9 | 14:39.16 |
| Robin_Watts | I guess you could look in the build logs if he keeps them per machine. | 14:39.25 |
| chrisl | Yeh, but trawling though each log individually is a bit painful - I did it for a couple of tests, and found no failures | 14:40.15 |
| Robin_Watts | chrisl: Indeed. you'd have to find some way of automating it. | 14:44.37 |
| chrisl | Robin_Watts: I suspect that one I just fixed might be source of a lot of the failures - it was a pretty glaring problem, although not *that* easy to spot | 14:45.51 |
| Robin_Watts | chrisl: We have a couple of tools for spotting dependency issues. | 14:46.17 |
| | could the case that you've just found be easily added to one of those tools? | 14:46.32 |
| chrisl | No, I don't think so, this was a dependency on the echogs executable....... | 14:47.46 |
| Robin_Watts | I forget hoe the tools work now. | 14:48.54 |
| | but it might be possible to add a rule to them to check that anything that calls echogs depends on ECHOGS_XE | 14:49.21 |
| chrisl | It might - echogs is called in several ways, though | 14:51.20 |
| Robin_Watts | just looking at checkdeps.pl - I had to do a git blame to check that it was my one, I remember that little about it. | 14:52.11 |
| | but it does at least have some comments. | 14:52.28 |
| chrisl | Ugh, perl - I have a pre-emptive headache........ | 14:53.49 |
| | Robin_Watts: looks like it could get ugly because it will have to check the entire make file "clause", not just the single target line | 14:56.10 |
| Robin_Watts | chrisl: Yeah, read_makefile would have to have a flag for "I have just read a 'foo : bar' line, and have not yet read a blank line. | 14:56.59 |
| | and then would have to check for 'echogs' being in that line - if it is, it should squeal if ECHOGS_XE wasn't in the last $deps it saw. | 14:57.52 |
| chrisl | You can't rely on clauses being separated by white space either, so just "not yet read a blank line" isn't enough | 14:58.26 |
| Robin_Watts | well, we'd cancel that flag if another foo : bar line was seen. | 14:58.52 |
| | (or rather, that flag would then stay set, because we'd be looking for commands for that line) | 14:59.44 |
| chrisl | I don't think it can be rolled into the existing the dep checking code, it probably means writing a separate test | 15:00.11 |
| Robin_Watts | I think it can, but it's not pretty (but then it's perl, what do you expect). | 15:00.41 |
| | I'd volunteer to look at it, but I'm up to my neck in bits of transparency code at the moment. | 15:00.59 |
| | Open an enhancement bug for it, and assign it to me? | 15:01.16 |
| chrisl | I just figured it would be easier to add a "check_echogs_depend" function that futz with the existing header checking | 15:01.46 |
| Robin_Watts | could be. But we'd probably need to duplicate some of the parsing, I fear. | 15:02.21 |
| chrisl | Hmm, does this come under "Build Process", "Test Framework", "General"....... | 15:04.26 |
| Robin_Watts | Yes. | 15:04.42 |
| chrisl | There, I'm on the CC list - if I get the chance before you do, and feel brave, I might look at it. | 15:07.06 |
| ray_laptop | morning, all | 15:51.41 |
| | so, today is the close of the Jubilee, right ? | 15:52.00 |
| kens | Hi ray_laptop | 15:53.12 |
| | and yes | 15:53.15 |
| | End of occicial celebrations | 15:53.28 |
| | official | 15:53.33 |
| henrys | with 3 of us offically on holiday I think we can safely skip the meeting. If anyone wants to talk with me I'll be here. | 15:54.30 |
| kens | is not on holiday :) | 15:54.45 |
| Robin_Watts | I don't think any of us are. | 15:54.53 |
| | (except Paul, who is only halftime anyway) | 15:55.10 |
| ray_laptop | henrys: who's on holiday ? | 15:55.14 |
| kens | ray_laptop : officially this is a public holiday in the UK | 15:55.33 |
| | as was yesterday | 15:55.38 |
| ray_laptop | kens: Oh, I see | 15:55.45 |
| henrys | okay so a meeting we shall have. | 15:58.16 |
| | ray_laptop:we need to fix the licenses and I wanted to talk to you about it. Maybe a phone call would be easiest. | 15:59.00 |
| ray_laptop | henrys: OK. I'm available. | 15:59.17 |
| Robin_Watts | fix the licenses? | 15:59.34 |
| henrys | chrisl:we do need to remove anything that says aladdin and replace it with the regular license header. | 15:59.56 |
| chrisl | henrys: where? In the sources? | 16:00.26 |
| henrys | chrisl:if you grep in the tree you should find a few Aladdin matches. | 16:00.42 |
| ray_laptop | mvrhel said there is a power outage and he is stuck in traffic -- he won't be here until later | 16:00.47 |
| henrys | ray_laptop:okay | 16:00.56 |
| | well since Robin_Watts wants to talk about it. | 16:01.07 |
| | ... | 16:01.09 |
| chrisl | Holy cr*p, lots of references to Aladdin -- I do that tomorrow....... | 16:01.44 |
| henrys | we have this LICENSE file that nothing really refers to... All the headers in the source point back tohttp://www.artifex.com ... I find it rather confusing. | 16:02.05 |
| | and apparently Suse's lawyer does also. | 16:02.27 |
| Robin_Watts | So you'd rather have all the headers point to the same place? | 16:02.35 |
| ray_laptop | I thought the header boilerplate used to refer to the LICENSE file | 16:02.52 |
| henrys | I think one solution is to have "LICENSE" live athttp://www.artifex.com | 16:04.11 |
| chrisl | henrys: the problem is we have two LICENSE files, depending on whether its the GPL release or the commercial | 16:05.22 |
| henrys | the LICENSE file in the base directory and the header pointing tohttp://www.artifex.com for licensing information is quite confusing not? | 16:05.25 |
| | s/not/no | 16:05.31 |
| Robin_Watts | I suspect we ought to have a snapshot of the source be entirely self contained w.r.t license information. | 16:06.13 |
| henrys | why not just use the header in the source files and have ambiguity resolved athttp://www.artifex.com? | 16:06.50 |
| ray_laptop | The clause that used to be in the header (I don't know when it got disappeared) was: | 16:07.08 |
| | This software is distributed under license and may not be copied, | 16:07.12 |
| | modified or distributed except as expressly authorized under the terms | 16:07.12 |
| | of the license contained in the file LICENSE in this distribution. | 16:07.15 |
| chrisl | henrys: How does artifex.com know whether it's a free user or a commercial user? | 16:07.39 |
| Robin_Watts | IMHO, the source should point to LICENSE, and LICENSE can either be the GPL or the Commercial one as appropriate. LICENSE can note the existence of the "other" license and point tohttp://www.artifex.com for additional clarification. | 16:07.47 |
| | Changing LICENSE can happen as part of the commercial release script. | 16:08.17 |
| henrys | chrisl:the license is defined by use and is explained at artifex.com/licensing. | 16:08.28 |
| ray_laptop | Robin_Watts: it does, right chrisl ? | 16:08.29 |
| chrisl | ray_laptop, Robin_Watts: yes | 16:08.45 |
| alexcher | What's wrong with the standard GNU header with additional permissions for commercial licensees? | 16:08.45 |
| chrisl | henrys: then why does the LICENSE file need to change for the commercial release? | 16:09.09 |
| ray_laptop | alexcher: the standard GNU header is confusing for a commercial customer | 16:09.18 |
| henrys | chrisl:it doesn't in my view LICENSE should not exist - problem solved. | 16:09.35 |
| Robin_Watts | I like the nice simple wording that ray_laptop gave above in each file. | 16:09.40 |
| ray_laptop | chrisl: Miles requested that the LICENSE file be unambiguosu | 16:09.47 |
| kens | My network is unhappy.... | 16:09.49 |
| ray_laptop | can't spell | 16:09.53 |
| kens | I may disappear unexpectedly | 16:10.01 |
| ray_laptop | kens: like our LICENSE clause in the header :-) | 16:10.18 |
| Robin_Watts | The nice simple header (that works equally well for either license type) leaves the heavy lifting to the LICENSE file. | 16:10.30 |
| | and the LICENSE file can then be as expansive as we wish. | 16:10.48 |
| ray_laptop | Robin_Watts: correct. | 16:11.04 |
| | henrys: so can we just put that clause back in the header ? | 16:11.15 |
| Robin_Watts | And if we are producing a commercial snapshot of the source, then it strikes me as a good idea to remove all references to the GPL (i.e. just replace the LICENSE file with one that talks about the commercial license only). | 16:11.32 |
| chrisl | FWIW, I think we should keep the link tohttp://www.artifex.com in the file header (and add the reference to LICENSE to it) | 16:11.43 |
| Robin_Watts | That seems maximally unambiguous to me. | 16:11.46 |
| ray_laptop | Robin_Watts: the commercial release script does remove GPL from things | 16:12.48 |
| chrisl | Robin_Watts: we do remove all references to GPL for the commercial release (except for one or two tools we supply as a "courtesy") | 16:12.53 |
| henrys | yes but you wouldn't have to do any of that if all the licensing info was at artifex and the source code just pointed to it. | 16:13.23 |
| Robin_Watts | chrisl: So something like: This software is distributed under license and may not be copied, modified or distributed except as expressly authorized under the terms of the license contained in the file LICENSE in this distribution. Seehttp://www.artifex.com for further information. | 16:13.28 |
| | henrys: Right, but then the license information is not fully contained within the source code. | 16:13.48 |
| chrisl | Robin_Watts: yes, exactly | 16:13.53 |
| ray_laptop | is going to do a git bisect to see when the LICENSE clause disappeared | 16:13.55 |
| henrys | Robin_Watts:so what? | 16:14.06 |
| ray_laptop | Robin_Watts: what's wrong with the old clause ? | 16:14.29 |
| Gigs- | OK I got my regression test chewing. 725 pdfs, 1.5% random sample or so of the archive. | 16:14.58 |
| chrisl | henrys: in my experience, it's good practice to have everything self contained. | 16:14.59 |
| Robin_Watts | Having the license information entirely contained within a snapshot sounds like a win to me. (And possibly may be required by the GNU GPL wording, actually?) | 16:15.00 |
| henrys | we removed the old clause so we could have 1 source base that was the direction now we are going back. | 16:15.07 |
| Robin_Watts | henrys: OK, some questions for you... | 16:15.35 |
| | 1) What do we gain by NOT having the license information contained in a snapshot. | 16:15.52 |
| ray_laptop | henrys: we have one source base -- and we did with the old header. | 16:15.55 |
| Robin_Watts | 2) Suppose we want to change the license for future versions - we update the website, and lo, all the old versions have the license change - and that's not legal/right. | 16:16.33 |
| ray_laptop | Robin_Watts: I don't understand -- the LICENSE file is in the snapshot isn't it ? | 16:16.33 |
| Robin_Watts | ray_laptop: I am agreeing with you! | 16:17.13 |
| ray_laptop | OK. I also agree with you that reference to a web site is dicey | 16:17.41 |
| Robin_Watts | ray_laptop: Henrys is suggesting that we change the existing scheme, and I'm trying to understand what he feels he will gain by it. | 16:17.47 |
| Gigs- | Not distributing the license with the work is a bad idea for your own rights too. Someone could claim you had a BSD up there for a while, can't prove you didn't. | 16:17.49 |
| Robin_Watts | Gigs-: Aye. | 16:18.08 |
| henrys | Robin_Watts:no you guys want to change every source file in the system, not me. | 16:18.10 |
| ray_laptop | Robin_Watts: we'd like to source files to clarify that the LICENSE file applies to them (I think) | 16:18.56 |
| henrys | the GPL is fixed legal issues are moot - they will always go back to the contract. | 16:18.58 |
| | for commercial customers that have a dispute. | 16:19.22 |
| Robin_Watts | henrys: At the moment, AIUI, all the files in the system have slightly different wording. | 16:19.36 |
| chrisl | I'm pretty sure Robin_Watts is correct - the GPL requires we ship the license with the code | 16:19.50 |
| Robin_Watts | They should have that wording standardised. The question is what do we standardise it to? | 16:20.03 |
| | If the GPL requires us to ship a LICENSE file (and I believe it does), then we HAVE to have the headers point to the LICENSE file. | 16:20.27 |
| henrys | okay then we have to change everything ... that really sucks | 16:20.31 |
| Robin_Watts | And if we are doing that, then it's a simple matter to swap the LICENSE file in and out for a commercial release (which I believe we already do). | 16:20.55 |
| henrys | do we really have words stating the GPL requires that? | 16:21.18 |
| chrisl | henrys: clause 4, I think | 16:22.10 |
| Robin_Watts | The COPYING file contains the actual GPL license. | 16:22.21 |
| henrys | probably if we want to change the header we should go back to the lawyer, we'll like screw up something if we do it ourselves. | 16:22.35 |
| | s/like/likely | 16:22.46 |
| Robin_Watts | So, should we agree what we think the header should be, then someone can communicate that proposed header + a copy of LICENSE + a copy of COPYING to the lawyer for review? | 16:23.43 |
| chrisl | The other thing is we actually ship a fair amount of code under licenses other than GPL or Artifex commercial - the LICENSE file explains all that | 16:23.52 |
| henrys | chrisl:I don't read that from section 4 | 16:24.03 |
| chrisl | henrys: no, it's talking about the GPL, I suppose | 16:25.04 |
| kens | I see Marcos is going to be off on vacation | 16:25.05 |
| | What shall we do about support ? | 16:25.12 |
| Robin_Watts | henrys: If you look at LICENSE, there is a lot of detail in there, about all sorts of stuff - license, warranty, patent grants etc. | 16:25.15 |
| henrys | all that detail can exist at artifex.com | 16:25.31 |
| Robin_Watts | Are you proposing that all that gets pickled into every header? | 16:25.31 |
| | henrys: You haven't answered my question 1) above. | 16:25.43 |
| | I believe it's a goal worth striving for that the license information should be self contained within a snapshot. | 16:26.26 |
| | And Gigs has suggested a reason why indeed that should be a goal. | 16:26.53 |
| chrisl | Ugh, we'd have to maintain a "mapping" of LICENSE version to GS release version - not good :-( | 16:26.58 |
| Robin_Watts | And so have I. | 16:27.06 |
| | You've not said what you hope to gain by breaking that. | 16:27.20 |
| | What benefit do we get by requiring people to visit artifex.com to find out the license details? | 16:27.56 |
| | (Suppose we change the name of the company? Or the domain name? Old snapshots will suddenly 'lose' their license information) | 16:28.30 |
| chrisl | henrys: besides, I think if we had the LICENSE stuff exist on artifex.com, we'd have to include *direct* link to the license information, so the headers would all need changed anyway. | 16:28.39 |
| henrys | Robin_Watts:I always want the GPL and commercial code to be as similar as possible. I think that is the default arrangement and you should provide reason why it should be otherwise. I'm not hearing anything that isn't really arbritrary "as folks think it should be" | 16:28.52 |
| ray_laptop | henrys: I don't see what the problem is with having the LICENSE file in the snapshot. It isn't causing any problems | 16:28.52 |
| Robin_Watts | henrys: Sorry? Am I missing something here? | 16:29.25 |
| henrys | ray_laptop:it can't be as it is I think we can all agree to that. | 16:29.35 |
| Robin_Watts | The proposal is (and indeed, pretty much what we do now) is that the headers should point to LICENSE. Then only LICENSE needs to change between commercial and GPL versions. How can anything *less* have to change? | 16:30.06 |
| henrys | Robin_Watts:I was answering question no 1. | 16:30.12 |
| chrisl | henrys: we're always going to have to make changes between the GPL and commercial releases since the product information changes - so swapping the LICENSE is trivial in comparison | 16:30.37 |
| ray_laptop | henrys: other than updating all the source files, what is your objection to putting the reference to the LICENSE file back in the headers ? | 16:30.41 |
| | henrys: Note that wording was approved by Miles and his lawyer previously | 16:31.05 |
| henrys | ray_laptop:but we all agreed to remove it and had it approved by the lawyer. | 16:31.36 |
| Robin_Watts | henrys: "ray_laptop:it can't be as it is I think we can all agree to that." - I think you're the only one that doesn't agree to that :( | 16:31.40 |
| | bah, no. | 16:31.55 |
| | henrys: "ray_laptop:it can't be as it is I think we can all agree to that." - I think you're the only one that does agree to that. | 16:32.02 |
| ray_laptop | Robin_Watts: I agree that it is ambiguous now and we need to have the source files identify the license. | 16:32.38 |
| Robin_Watts | In case I am misunderstanding here, can I get a show of hands. Who thinks we should have a simple statement in the headers pointing to the LICENSE file. And the LICENSE file changes between GPL and commercial releases? I do. | 16:33.29 |
| henrys | yes it is ambiguous now. And the choices are change every header or remove the LICENSE do we agree to that much? | 16:33.29 |
| ray_laptop | and IMHO refering to a web site is bogus | 16:33.38 |
| | henrys: I don NOT agree to removing the LICENSE | 16:33.59 |
| Robin_Watts | henrys: That's a misstatement of the choices, IMHO. | 16:34.18 |
| ray_laptop | henrys: that's what makes it so easy to switch from GPL to commercial versions | 16:34.25 |
| henrys | ray_laptop:disagree just removing the license file - doing nothing else fixes that now. | 16:35.58 |
| ray_laptop | henrys: I don't parse that (too many words missing) | 16:36.29 |
| chrisl | henrys:http://www.artifex.com doesn't have licensing information | 16:36.51 |
| henrys | ray_laptop:sorry if we simply remove the license file and put the license information on artifex.com everything is resolved. | 16:37.20 |
| ray_laptop | chrisl: good thing too -- because it would be a bad place to have it | 16:37.27 |
| Robin_Watts | IMHO, what is in the headers now can never be made unambiguous. | 16:37.39 |
| | Which means (again IMHO) we NEED to change every file to something else. | 16:37.59 |
| chrisl | ray_laptop: any idea why the reference to LICENSE was removed from the file headers? | 16:38.19 |
| ray_laptop | henrys: NO! because WHERE on artifex.com isn't clear, and how do we differentiate / switch between GPL and commercial | 16:38.20 |
| Robin_Watts | And the simplest solution, and the most effective, and the clearest, is to point to a local LICENSE file. | 16:38.27 |
| ray_laptop | chrisl: no -- I'm looking at the repos to see when it was changed. 2002 was OK | 16:38.46 |
| | I agree with Robin_Watts | 16:38.56 |
| henrys | http://www.artifex.com/indexlicense.htm explains everything you just need licenses placed there | 16:39.29 |
| chrisl | henrys: that's nothttp://www.artifex.com, though, that's a sub-page of the website | 16:39.56 |
| Robin_Watts | henrys: OK, suppose we release a version of ghostscript, (say) 9.06, and we point tohttp://www.artifex.com/licenseinfo/ or something. | 16:40.11 |
| chrisl | ray_laptop: I think: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8c9c4bdb | 16:40.26 |
| Robin_Watts | Now suppose we want to change the license in 9.07 (for whatever reason). | 16:40.51 |
| | We either have to change the header of every single file to point to somewhere else, or we need to complicate that page so it differentiates between versions. | 16:41.35 |
| | Neither of those solutions is nice. | 16:41.46 |
| | Neither of those solutions is better than simply having a local LICENSE file. | 16:42.01 |
| henrys | okay at last we have a reason and not arbitrary "this is the way it should be" yes that is a difficulty we could have multiple licensense but I adming that is awkward. | 16:42.20 |
| Robin_Watts | Changing all the headers of every file once is nasty, yes, but it is just once. | 16:42.23 |
| ray_laptop | Robin_Watts: (or once more) | 16:42.45 |
| Robin_Watts | ray_laptop: Indeed. | 16:42.54 |
| ray_laptop | we can blame the missing clause on Stefan ;-) | 16:43.26 |
| henrys | no ray_laptop we all agreed to remove it by consensus. | 16:43.53 |
| chrisl | ray_laptop: possibly not entirely fair - but I'm happy to blame him for not commenting the commit clearly...... | 16:44.21 |
| henrys | the idea was to have the licensing on the web site just because you didn't agree with it does not mean it did not exist ;-) | 16:44.26 |
| chrisl | henrys: I assume we should also be changing references to artofcode, too! | 16:45.37 |
| henrys | Robin_Watts:I don't think the license could ever be changed so it was backward incompatible. We always add new restrictions that apply to new code. | 16:45.57 |
| | yes all artofcode should be removed. | 16:46.19 |
| Robin_Watts | henrys: Personally, I'd be quite happy to have a pointer from LICENSE to artifex.com to a page that describes the reason for having 2 licenses and the the differences between them. But a user shouldn't have to navigate that just to understand what the license terms are for this particular snapshot. | 16:46.19 |
| | henrys: Consider when we made luratech standard with the commercial version. | 16:47.03 |
| henrys | okay I'll back down from my position and we'll have 2 license files. | 16:47.28 |
| Robin_Watts | The 'new' license file will presumably say that portions of the code are copyright luratech and are used under license. | 16:47.38 |
| henrys | so chrisl you've got a lot of work to do ;-) | 16:48.42 |
| kens | So, now that's over.... | 16:49.30 |
| | Marcos is on vacation and has no internet, from Friday | 16:49.41 |
| henrys | and only 50 minutes. | 16:49.43 |
| kens | What shall we do about support in the meantime ? | 16:49.54 |
| chrisl | henrys: yippee - I still think it's the right thing to do...... | 16:50.13 |
| henrys | kens and I will do support as usual I suppose. | 16:50.45 |
| kens | OK no problem | 16:50.53 |
| henrys | do you mind kens? | 16:50.53 |
| kens | No, that's fine, just wanted to be sure | 16:51.02 |
| chrisl | ray_laptop: so are just going to resurrect the old paragraph referencing LICENSE? | 16:52.03 |
| henrys | anything else for the meeting? | 16:52.30 |
| Robin_Watts | chrisl: He pasted it earlier. | 16:52.31 |
| chrisl | Robin_Watts: yes, but there's been a lot of water under the bridge since then...... | 16:53.14 |
| Robin_Watts | chrisl: I reckon we should just point to LICENSE in the headers. If we want a pointer to artifex.com that should happen from LICENSE. | 16:53.24 |
| | henrys: Not from me. | 16:53.47 |
| chrisl | Robin_Watts: hmm, from a "publicity" point of view, I wanted to keep the reference to artifex.com in the source files | 16:54.08 |
| | henrys: do you want to check this file header and stuff with the lawyer, or are we good to go? | 16:55.08 |
| henrys | chrisl:if we are just adding back the sentence pointing to LICENSE we are fine. | 16:55.37 |
| chrisl | henrys: cool, thanks. | 16:55.58 |
| Robin_Watts | chrisl: OK, but don't involve the artifex pointer in the licensing terms then? | 16:56.02 |
| henrys | do we all agree on that? I side with chrisl on keeping artifex.com in source. | 16:56.04 |
| | ray_laptop? | 16:56.22 |
| chrisl | Robin_Watts: just something like "For more information....." | 16:56.33 |
| Robin_Watts | Sure, but in a separate paragraph to the LICENSE one? | 16:56.55 |
| chrisl | Yes | 16:57.04 |
| Robin_Watts | Then I have no objection. | 16:57.11 |
| henrys | chrisl:isn't the wording good as is - the new sentence points to the license the current words say "Refer to licensing information at http://www.artifex.com/..." | 16:57.36 |
| | chrisl:we should be just inserting the old sentence, if we are going to do more editing I'd say we want the lawyer. | 16:59.12 |
| chrisl | henrys: I don't know - legals and licensing stuff are not my forte...... | 17:00.32 |
| Robin_Watts | This software is distributed under license and may not be copied, modified or distributed except as expressly authorized under the terms of the license contained in the file LICENSE in this distribution. | 17:00.58 |
| | Seehttp://www.artifex.com for further information. | 17:01.00 |
| | We specifically don't want it to say "Refer to licensing information at http://www.artifex.com/" any more (IMHO). | 17:01.27 |
| chrisl | Robin_Watts: that means *removing* a paragraph | 17:01.30 |
| Robin_Watts | and if that means going back to the lawyer, then so be it. | 17:01.47 |
| | (Just think how upset mvrhel will be to have missed all this :) ) | 17:02.58 |
| chrisl | Robin_Watts: the LICENSE file for the GPL release doesn't mention Artifex, nor does it give any contact details | 17:03.56 |
| henrys | chrisl:I'll pass around an email with the new wording to tech and we can discuss it. | 17:05.09 |
| Robin_Watts | chrisl: Well, it probably should. But adding such information to the LICENSE file is a much less invasive change, right? | 17:05.21 |
| ray_laptop | sorry phone call.. | 17:05.57 |
| chrisl | Robin_Watts: from a legal point of view, I'd say it was a *more* invasive change. Personally, I like having the full contact details in there somewhere, as it makes it feel more "real". | 17:06.31 |
| | henrys: that's probably best (the e-mail) | 17:07.03 |
| Robin_Watts | chrisl: I'm not talking about it being legally significant - just that it's going to mess with our git history less :) | 17:07.23 |
| chrisl | Robin_Watts: the contact details are already in the file headers..... | 17:08.29 |
| Robin_Watts | The current header says "This software is provided AS-IS with no warranty, either express or implied." Is that true for the commercial version too ? | 17:08.44 |
| | I guess it probably is. | 17:09.05 |
| chrisl | That will be superseded by the commercial contract | 17:09.22 |
| henrys | chrisl:it really just has to go back to the old wording, the purpose of the Stefan's code change was to put the license stuff at artifex and we wan't to undo that, but I'll send it out. | 17:09.38 |
| | s/wan't/want | 17:09.52 |
| kens | OK I'm off night all | 17:10.49 |
| chrisl | henrys: I would like some kind of consensus - I don't mind being saddled with making the changes, but preferably only once ;-) | 17:11.39 |
| | Robin_Watts: here's what it was before: http://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=gs/src/gxpcopy.c;h=5639194d | 17:13.03 |
| Gigs- | You all still going on this eh. You know you could leave the GPL in your commercial releases and say something like "unless superseded by a commercial licensing agreement" | 17:13.50 |
| chrisl | Robin_Watts: BTW, I saw the thing you mentioned about the fix for complex paths with transparency - did you recheck the performance when you'd removed the pointless strokepath call? strokepath is a time consuming operation, so it wouldn't surprise me if the performance improved without it. | 17:17.52 |
| Robin_Watts | chrisl: I didn't | 17:18.58 |
| | I suspect there is a lot more to be saved by just not doing the knockout group etc for idempotent ops. | 17:19.36 |
| chrisl | I just thought it might mean you don't need the path complexity metric....... | 17:20.23 |
| ray_laptop | skipping the extra group is always good. Someone should mention that to the cairo guys | 17:20.26 |
| chrisl | ray_laptop: it has been mention to them several times - apparently it's "hard to fix" in cairo...... | 17:22.00 |
| Robin_Watts | For performance, I may end up doing an operator that rolls the path complexity metric into the idempotent check and some transparency setup. | 17:23.24 |
| | but I need to get the damn code working first :( | 17:23.36 |
| henrys | okay message sent | 17:24.36 |
| chrisl | Robin_Watts: I just thought I'd mention it - people often don't realise what a horrible thing strokepath actually does | 17:25.00 |
| ray_laptop | Robin_Watts: still have your q/Q problems ? | 17:25.02 |
| Robin_Watts | ray_laptop: No. That must have been finger problems. | 17:25.18 |
| | chrisl: Yeah, but I've implemented strokepath :) | 17:25.29 |
| henrys | oh damn it ghostscript.com shouldn't be in there ... | 17:25.57 |
| chrisl | Ah, right. TBH, I'd be tempted to remove it from the stroke operation, and just "fudge" the bbox...... | 17:26.35 |
| | henrys: maybe the ghostscript.com link should be there (but not "/licensing") | 17:27.46 |
| Robin_Watts | chrisl: We could have a .strokebbox operator that did pathbbox and applied the appropriate fudge. | 17:27.50 |
| ray_laptop | chrisl: we'd have to fudge it by the linewidth, and miter projection. linewidth is easy -- worst case miter projection harder | 17:27.53 |
| | chrisl: doing a custom operator that does the calculation in C would be better than doing the calcs in PS. | 17:28.49 |
| chrisl | Oh, yeh, I'd forgotten about mitering - I just really dislike strokepath! | 17:29.24 |
| ray_laptop | chrisl: I agree that for a bbox it's sort of overkill | 17:29.42 |
| | but we don't do it that often (the extra trans group) | 17:30.19 |
| Robin_Watts | ray_laptop: In the current code, it's done on EVERY PDF stroke or fill operation. | 17:30.53 |
| ray_laptop | Robin_Watts: EVERY stroke does a group ??? | 17:31.21 |
| chrisl | Given that probably most uses of strokepath are to get the bbox of a stroked path, it surprises me that PS doesn't have a "strokepathbbox" operator - which would do *just enough* to get the bbox | 17:31.29 |
| henrys | chrisl:okay I sent out a correction. | 17:31.51 |
| Robin_Watts | On pages with transparency, the current code I am testing (and the code that marcosw timed before) does a group on every stroke or fill operation. | 17:32.04 |
| ray_laptop | Robin_Watts: it looks like the current code only does it if there is a SMask | 17:32.28 |
| Robin_Watts | ray_laptop: once again, not HEAD, the code I am testing. | 17:32.44 |
| chrisl | henrys: that looks good to me - I'm sure more opinions will be forthcoming...... | 17:33.02 |
| Robin_Watts | That looks good to me too. | 17:34.06 |
| ray_laptop | Robin_Watts: I see. The B/B* operators currently push a group AND use the strokepath op. | 17:34.08 |
| Robin_Watts | ray_laptop: Yes, those are the 'stroke and fill' PDF operators. Michael based the code that I am looking at now on that code. | 17:34.58 |
| henrys | chrisl:give it a day or two, no hurry. | 17:35.41 |
| ray_laptop | Robin_Watts: right -- so we can probably improve the B/B* by skipping the group if the BM and alpha are OK | 17:35.52 |
| Robin_Watts | Yes. | 17:36.04 |
| | I'll look at that after I get this code working (assuming I ever get this code working...) | 17:36.25 |
| chrisl | henrys: okay, will do | 17:40.03 |
| ray_laptop | henrys: (as usual) I have a couple of minor comments, but don't feel strongly about it. | 17:41.09 |
| | I have to go. | 17:41.16 |
| | bbiaw. | 17:41.19 |
| henrys | bbiaw | 17:49.01 |
| mvrhel | ok I am here now | 17:54.41 |
| | good point about checking the BM and the alpha on the group push | 17:56.20 |
| henrys | bah, we've had clear skies all week and now it's overcast for the venus transition. | 17:58.30 |
| Robin_Watts | henrys: Catch it next time :) | 17:58.49 |
| mvrhel | I don't feel that sorry for you. It is 50 degrees and raining here | 17:58.55 |
| | just like during the solar eclipse | 17:59.03 |
| henrys | I did see a good part of the solar eclipse, but we did have some clouds | 17:59.28 |
| | Robin_Watts: ;-) | 17:59.47 |
| mvrhel | I think I need to move to CO where I can make use of my Newtonian reflector telescope | 18:00.01 |
| Robin_Watts | henrys: There is a solar eclipse marathon taking place in Australia in November... | 18:00.19 |
| | mvrhel: Got a few minutes? | 18:01.06 |
| mvrhel | sure | 18:01.12 |
| henrys | Robin_Watts:yeah I've looked at that. running in the glasses might be harmful though. | 18:01.27 |
| Robin_Watts | I've simplified a file here as much as I can to get an example that fails. | 18:01.28 |
| | and I'm having problems with Smasks. | 18:01.55 |
| | Essential the file does an SMask with an alpha of 0.33 and a Solid white square. | 18:02.25 |
| mvrhel | ok | 18:02.35 |
| Robin_Watts | Then, with that in force, does a transparency group with a solid red square in it. | 18:02.52 |
| | Then another transparency group with a solid green square in it. | 18:03.07 |
| mvrhel | so that is part of the smask too? | 18:03.09 |
| | or the soft mask is in the graphic state | 18:03.23 |
| Robin_Watts | the latter. | 18:03.29 |
| mvrhel | during the red and green drawing? | 18:03.30 |
| Robin_Watts | yes. | 18:03.33 |
| mvrhel | ok | 18:03.36 |
| | so the mask is in force during both the red and green groups | 18:04.11 |
| Robin_Watts | Yes. | 18:04.18 |
| | So, what I see here is that when it comes to process the red square group, it makes the smask by doing a begin transparency mask, drawing the white square then ending the transparency mask. | 18:04.46 |
| | Then it begins a transparency group for the red square, draws the square, then ends the group. Then ends the mask. | 18:05.11 |
| mvrhel | You ended the mask twice | 18:05.45 |
| Robin_Watts | oops, forget the last ends the mask. | 18:05.52 |
| mvrhel | ok | 18:06.18 |
| Robin_Watts | Then for the green square, it redoes the mask (begin transparency mask, draw the mask, end the mask), then does the green square group itself (begin transparency group, draw the green square, end transparency group) | 18:06.55 |
| mvrhel | hmm is this is clist mode? | 18:07.10 |
| Robin_Watts | No. | 18:07.15 |
| mvrhel | why is it redoing the soft mask drawing? | 18:07.20 |
| | it should be in the graphic state | 18:07.35 |
| Robin_Watts | What I have just described is what the current head does. | 18:07.41 |
| mvrhel | ok it is fine that it is in the head. I just don't know why it is doing that | 18:08.06 |
| Robin_Watts | me either. | 18:08.13 |
| | but I figure that the head works, so... | 18:08.22 |
| mvrhel | I wonder if there was a pop of the soft mask between the groups | 18:09.05 |
| | there may have been a Q | 18:09.15 |
| Robin_Watts | Nope. | 18:09.27 |
| mvrhel | in the PDF file though? | 18:09.34 |
| | hmm. can you send me the file so I can step through it myself | 18:09.45 |
| Robin_Watts | /R16 gs | 18:10.11 |
| | /R21 Do | 18:10.13 |
| | /R25 Do | 18:10.15 |
| | R16 = smask, R21 = red square R25 = green square | 18:11.04 |
| | Gladly. | 18:11.08 |
| | http://ghostscript.com/~robin/mapUC.pdf | 18:11.29 |
| | (then the file draws a black rectangle on top - I didn't mention that, because it's not involved in the problem so far) | 18:12.31 |
| | Our new code also redraws the mask, but it gets the alpha wrong; we end up with alpha of 1/9th rather than alpha of 1/3rd the second time the mask is drawn. | 18:13.26 |
| mvrhel | ok hold on looking the file contents over | 18:18.22 |
| | ok. I stepped manually through the pdf contents. I am bothered that with this file we are not maintaining the softmask buffer but that is obviously not your issue Robin_Watts | 18:32.11 |
| Robin_Watts | Well, it may be related. | 18:33.14 |
| mvrhel | If you think it is related, I should probably spend some time on that as the whole thing of maintaining smask buffers in sync with graphic states is a nightmare | 18:33.59 |
| Robin_Watts | Specifically the problem I am seeing is that when rendering the mask a second time, it seems to be getting what I think is the original mask on the mask stack, and being polluted with that masks alpha. | 18:34.14 |
| mvrhel | I wonder if you should not be doing any additional knockout groups if we are in a softmask | 18:34.54 |
| | having a complex path in a soft mask is likely to be rare | 18:35.05 |
| | usually they are single images | 18:35.13 |
| | or fills | 18:35.23 |
| | or is it not the knockout that occurs during the softmask creation that is the problem? | 18:36.20 |
| Robin_Watts | As far as I can tell, the knockout during mask creation is not the issue. | 18:37.04 |
| mvrhel | ok | 18:37.10 |
| Robin_Watts | (the RAW_DUMP output looks fine) | 18:37.18 |
| mvrhel | let me step through the rendering of the file and see if I can figure out why it wants to do the softmask twice | 18:37.56 |
| Robin_Watts | oh, wait... | 18:38.05 |
| | the problem is occuring during the second mask creation step. | 18:38.23 |
| mvrhel | aha | 18:38.39 |
| Robin_Watts | so it might be the additional knockout group that's the issue. | 18:38.44 |
| mvrhel | also if I can get the soft mask from not rendering a second time | 18:39.45 |
| | that will fix it | 18:39.50 |
| Robin_Watts | It might fix this file, but I worry that it will leave another case where it's wrong. | 18:40.22 |
| mvrhel | well, we should not be drawing the soft mask twice | 18:40.57 |
| | I thought I had that stuff under control | 18:41.07 |
| Robin_Watts | marcosw has clearly never heard of tempting fate... | 18:41.08 |
| marcosw | knock on titanium | 18:41.22 |
| mvrhel | does this have to do with your cruise? | 18:41.56 |
| Robin_Watts | Right, but if we fix it to only draw the softmask once, then it's possible that we'll hit another problem elsewhere where the knockout group causes problems in an initial smask render. | 18:42.21 |
| | mvrhel: See the mail he sent around just a moment ago. | 18:42.37 |
| | marcosw: Is this the galapagos trip? | 18:42.49 |
| mvrhel | ah yes | 18:42.54 |
| | Robin_Watts: the solution to that will be to force the softmask the second time in your file | 18:43.34 |
| | See what happens when you do that | 18:43.54 |
| Robin_Watts | mvrhel: You mean remove, then replace the smask explicitly? | 18:44.14 |
| mvrhel | yes. or even just set it again. is gs smart enough to know that it is already in an extended state | 18:45.03 |
| Robin_Watts | Doesn't help, it seems. | 18:46.01 |
| mvrhel | no it would still have the issue I am saying | 18:46.18 |
| | hmm wait a minute | 18:46.51 |
| Robin_Watts | OK. I didn't follow what you meant anyway | 18:47.02 |
| mvrhel | hehe | 18:47.06 |
| | so maybe do R16 gs | 18:47.15 |
| | R21 Do | 18:47.19 |
| | R16 gs | 18:47.22 |
| | R25 Do | 18:47.26 |
| Robin_Watts | That's what I did. | 18:47.33 |
| mvrhel | ok | 18:47.36 |
| | and it has the same issue | 18:47.39 |
| Robin_Watts | (actually I had an R22 in there too which removes the SMask) | 18:47.48 |
| | it does. | 18:47.50 |
| mvrhel | ok then we would have an easy test case with the problem | 18:48.02 |
| | after fixing the repeat problem | 18:48.13 |
| | or rather, the repeating is not the issue | 18:48.42 |
| Robin_Watts | Right. | 18:48.47 |
| mvrhel | so you are seeing the softmask get double alpha applied? | 18:49.13 |
| Robin_Watts | Yes. | 18:49.20 |
| mvrhel | as if the knockout group within the softmask has the same alpha | 18:49.32 |
| Robin_Watts | The knockout group within the smask has an alpha of 1. | 18:50.18 |
| mvrhel | there is a dump of the softmask does it have a double applied value? | 18:50.52 |
| | as its contents | 18:51.07 |
| | comparing the contents of the first and second soft mask | 18:51.17 |
| | are they the same? | 18:51.28 |
| Robin_Watts | no. | 18:51.39 |
| mvrhel | ok. so you need to get a break point in pdf mark fill rect during that second white fill | 18:52.06 |
| | and see what is going on value wise | 18:52.13 |
| Robin_Watts | I know the values. | 18:52.20 |
| mvrhel | to find out where the extra alpha is coming from | 18:52.27 |
| Robin_Watts | Give me a tick and I'll try and explain. | 18:52.28 |
| | For each of them, I see the following sequence of operations: | 18:52.37 |
| | soa 1, btm, soa 1, soa .33, btg, soa 1, fill, etg, soa1, etm | 18:53.09 |
| | Where soa = .setopacityalpha, btm = begin_transparency_mask, btg = begin_transparency_group, etc | 18:53.38 |
| mvrhel | I dont know what you mean by soal | 18:53.38 |
| | ok | 18:53.41 |
| | ok so you are seeing the same sequence | 18:54.14 |
| | but you need to go into mark fill rect and actually see what value is being drawn | 18:54.29 |
| | then you will catch it | 18:54.39 |
| Robin_Watts | Yes, I'm still typing... | 18:54.45 |
| mvrhel | sorry | 18:54.51 |
| Robin_Watts | For the first one, the btm produces a 1) Raw_Buf_PreSMask that's entirely blank (rgba = 0,0,0,0) | 18:55.29 |
| | For the second one, the btm produces 9) Raw_Bug_PreSMask thats (1,0,0,0.33) | 18:56.08 |
| mvrhel | oh | 18:56.13 |
| | ok hold on | 18:56.46 |
| Robin_Watts | The btg in both cases produces a TransGrpPush that is blank (0,0,0,0) | 18:57.15 |
| mvrhel | ok give me a few moments | 18:57.45 |
| Robin_Watts | the etg in both cases produces: TransGrpPop = ImageTOS (1,1,1,1) | 18:57.47 |
| | and an ImageNOS (1,1,1,1) | 18:58.05 |
| | sorry: an ImageNOS (0,0,0,0) | 18:58.24 |
| | the first one produces a Composed = (1,1,1,0.33) | 18:58.47 |
| | the second one produces a Composed = (1,1,1,0.11) | 18:59.05 |
| | The difference, as far as I can see, is that in the first group the maskptr = NULL, whereas in the second the maskptr points to something with an alpha of 0.33 | 18:59.38 |
| | And now I'm done typing :) | 18:59.44 |
| mvrhel | OK | 18:59.51 |
| | so my suspicion is that there is an issue with the the initialization of the softmask buffer the second time. It should not be setting it to 1,0,0,0.33. This is due to the values of GrayBackground | 19:02.21 |
| | can you catch what these are in ztrans.c | 19:02.59 |
| | line 285 | 19:03.12 |
| | also Background on line 279 | 19:03.36 |
| Robin_Watts | back, sorry. | 19:03.39 |
| mvrhel | np | 19:03.44 |
| | These are coming from the intrepreter | 19:04.15 |
| Robin_Watts | yes, I can do that. Just a tick. | 19:04.17 |
| | Urm... The first time params.Background looks like it's full of uninitialised values ? | 19:05.28 |
| | params.Background_components = 0 ? | 19:05.57 |
| mvrhel | ok | 19:05.59 |
| | that makes sense | 19:06.03 |
| Robin_Watts | params.GrayBackground = 0 | 19:06.11 |
| | Now let me step through to the second call. | 19:06.18 |
| | The second time params.Background is still uninitialised,and params.Background_components = 0 | 19:07.24 |
| | params.GrayBackground = a structure. | 19:07.45 |
| | No, sorry, me fool. | 19:08.02 |
| | params.GrayBackground = 0 | 19:08.05 |
| mvrhel | oh | 19:08.40 |
| | sorry then. maybe a wild goose chase | 19:08.50 |
| | can you do one more thing | 19:08.54 |
| Robin_Watts | The place where I *can* spot a difference, is inside the end_transparency_group | 19:09.08 |
| | where maskptr is non NULL. | 19:09.21 |
| | sure, shoot. | 19:09.25 |
| mvrhel | add a break point at line 1067 in pdf14_push_transparency_mask | 19:09.33 |
| | if (buf->data != NULL){ | 19:09.43 |
| | your line numbers are prob. different | 19:09.54 |
| | with all your changes | 19:09.57 |
| Robin_Watts | No, same line for me. | 19:10.13 |
| | and rerun? | 19:10.53 |
| mvrhel | I want to know where we are the first and second time through here | 19:11.00 |
| Robin_Watts | OK. | 19:11.05 |
| | I'm stopped there on the first time through. | 19:11.28 |
| mvrhel | ok. so does it go through the opaque background init? | 19:11.48 |
| Robin_Watts | buf->data is non NULL the first time. | 19:12.11 |
| | Is that what you're asking? | 19:12.14 |
| | (looks like a pointer to lots of 205's) | 19:12.41 |
| | and goes into the "Compose mask with opaque background" bit of the if. | 19:13.01 |
| mvrhel | yes | 19:13.32 |
| | ok | 19:13.34 |
| | then the second time through | 19:13.40 |
| Robin_Watts | same second time through | 19:14.08 |
| | (buf->data points to lots of 205's, and goes into the "compose mask with opaque background" bit) | 19:14.30 |
| mvrhel | ok. so that ends that idea | 19:14.34 |
| | so I probably need to have your patch to step through | 19:15.08 |
| | otherwise this is going to take painfully long | 19:15.18 |
| Robin_Watts | ok. | 19:15.24 |
| | Let me make you a patch. | 19:15.39 |
| | Sorry. | 19:15.42 |
| mvrhel | np | 19:15.45 |
| Robin_Watts | http://ghostscript.com/~robin/0001-knockouts.patch | 19:16.32 |
| mvrhel | I have to stop for a bit though and grab some lunch and then I have a dr. appt at 1:30 | 19:16.34 |
| | so I might not might it through until a bit later | 19:16.47 |
| Robin_Watts | Sure. I'll happily stop for the evening now. | 19:16.48 |
| | Feel free to kick it back to me if you can suggest more tests that I can do. | 19:17.15 |
| | Thanks. | 19:17.29 |
| mvrhel | ok. You have made a very simple file so it should not be too hard for me to figure this out | 19:17.48 |
| | it is just tedious. I may see if I can figure out why we get the double soft mask too | 19:18.13 |
| wart___ | Hi folks. I was annoyed the mupdf couldn't tell me what the page of the pdf I was viewing was, and then I found this: http://ghostscript.com/pipermail/gs-cvs.mbox/2011-September/013410.html | 19:56.31 |
| | so i grabbed the latest git pull, and checked and x11_main.c has the requisite patch. But pressing P doesn't do a darn thing. | 19:56.49 |
| | So I'm guessing this has to do with being in edit mode or something... man page doesn't mention 'P'. | 19:57.46 |
| | Thanks in advance. | 19:57.49 |
| kens2 | chrisl ping | 19:59.53 |
| zag | Hello? | 20:18.57 |
| kens2 | Hello | 20:19.05 |
| zag | I have a general question perhaps you could please share some of your knowledge? I've spent some good hours using google and reading forums. But I still don't know where to start since I'm pretty new to linux | 20:20.43 |
| saper | and the question is? | 20:21.05 |
| zag | I have a USB printer that will printer using window's generic drivers. I would like to set it up on a linux box. (it has a custom distro) Can you perhaps give some light to where I can start to achieve this goal? | 20:22.30 |
| saper | wart___: btw, you don't see the page number in the title? | 20:22.40 |
| kens2 | zag what do you mean by Windows 'generic' dfrivers ? | 20:24.15 |
| | You certainly can't use Windwos drviers on Linux | 20:24.33 |
| saper | GDI? | 20:24.34 |
| | zag: you have to find out if ghostscript or some other tool can convert postscript to your printer's language whatever it is | 20:25.07 |
| | zag: did you see this? http://aplawrence.com/Linux/gdi_printing.html | 20:27.07 |
| zag | when i setup the printe,r I choose "Generic Text Only" . I'm sorry I did run into that term while using google. I'll read over it and see if I can use it. | 20:28.40 |
| saper | zag: you need to figure out if your printers is GDI/PPA/whatever; lots of printers these days have some form of Linux support (tried with Canon and HPs recently) | 20:29.33 |
| zag | Okay, thank you for the lead! | 20:30.06 |
| wart___ | saper: ah! | 20:34.26 |
| | saper: i use dwm with no menubar | 20:34.32 |
| | i never thought of a title | 20:34.35 |
| | but there it is | 20:34.38 |
| | thnaks | 20:34.40 |
| | silly me | 20:34.41 |
| Gigs- | mvrhel: I have bad news, it seems that the current git is almost 3 times slower than 9.05 from my tiffsep testing. | 20:36.25 |
| saper | wart___: I use dwm with menubar :) | 20:37.24 |
| wart___ | i'm still curious what the 'P' does; its there in the code | 20:40.52 |
| | after all | 20:40.54 |
| Gigs- | Why does the new tiffsep sometimes name the sep by the separation name and sometimes like s0, s1? | 20:42.26 |
| | nevermind, it was my mistake | 20:43.11 |
| wart___ | btw does mupdf plan on supporting highlighting/annotations? | 20:48.10 |
| | on linux and/or android | 20:48.15 |
| Gigs- | mvrhel: oh it appears compression is on where it was not before. 4.5GB vs 14GB. That could explain the time difference. I guess that trade off is worth it. | 20:57.08 |
| | mixed feelings about the separation names being in the file name. On one hand it is a good feature that makes sense. I just dread retesting all my bash scripts for dealing with the random characters (and spaces) it will introduce. | 20:59.20 |
| | It's very difficult to design a bash script to deal with any possible character in a file name. | 21:00.59 |
| zag | Is there a way for me to just plug my printer in and send raw data to day? | 21:13.14 |
| | to it* | 21:13.24 |
| Gigs- | crap he left | 21:18.47 |
| | port 9100 is raw | 21:18.51 |
| saper | Gigs-: he said it's USB :/ | 21:51.13 |
| Gigs- | oh | 21:53.41 |
| mvrhel | Gigs: you there? | 22:45.48 |
| ray_work | Gigs: the filename out of tiffsep is somewhat filtered in that it doesn't have known "problem" characters. | 23:05.35 |
| | Gigs: it replaces "restricted_chars" with '_' where: int restricted_chars[] = { '/', '\\', ':', 0 }; | 23:07.27 |
| | Gigs: if you want to modify the list, it is in the "copy_separation_name" function circa line 1225 of base/gdevtsep.c | 23:08.43 |
| | Gigs: but obviously it can have spaces (and I suppose even tabs) | 23:09.48 |
| Robin_Watts | mvrhel: ping? | 23:52.00 |
| ray_work | Gigs: BTW, you can turn off compression if performance is more important | 23:53.09 |
| | Robin_Watts: you are up late | 23:53.34 |
| Robin_Watts | ray_work: Just heading to bed now. | 23:53.49 |
| ray_work | Robin_Watts: sleep well. | 23:53.57 |
| Robin_Watts | Was going to check in with mvrhel to see if he'd found anything. | 23:54.01 |
| | (he may not have had a chance to look yet) | 23:54.10 |
| ray_work | at least his system still has power (unlike other parts of Seattle) | 23:54.53 |
| Robin_Watts | Honestly, venus transits the sun, and everything goes to pot. | 23:55.17 |
| ray_work | I need to go look at it and show the kids | 23:55.45 |
| | or is it over ? | 23:55.53 |
| | We had a great view of the (partial) eclipse and the kids got to see it -- I just used a pinhole in a piece of cardboard | 23:56.55 |
| | Forward 1 day (to 2012/06/06)>>> | |
IRC Logs