| | <<<Back 1 day (to 2014/05/14) | 2014/05/15 |
| kens | chrisl I believe that report of corrupted binares is bogus, I'm just writing an email now | 07:12.33 |
| chrisl | kens: I uploaded fresh copies last night | 07:13.18 |
| kens | Ah, OK then | 07:13.32 |
| | I know hte 914 binaries worked, because I downloaded and tested them, how did they get corrupted ? | 07:13.58 |
| chrisl | No idea - it is concerning though. I checked them after I uploaded them when I did the release | 07:14.35 |
| kens | Very odd...... | 07:14.47 |
| chrisl | But GoDaddy did have those problems last week, so might be related | 07:15.07 |
| kens | Hmm, they could have restored from a corrupted backup I guess | 07:15.21 |
| chrisl | Also, I only checked the 9.14 release files last night, I didn't check the others - too much hassle | 07:16.18 |
| kens | I just did a quick md5 check on the named files and they are all OK | 07:16.34 |
| chrisl | Yes, I checked those, and the source archives for 9.14, but none of the others | 07:16.59 |
| | reboot...... | 07:18.19 |
| | kens: did you reply about the downloads? | 07:46.48 |
| kens | chrisl, no I didn't, since you uploaded new ones. | 07:53.01 |
| chrisl | Okay, I'll do so in a minute | 07:53.14 |
| sebras | tor8: good morning! | 09:17.27 |
| tor8 | morning sebras | 09:58.35 |
| | Robin_Watts: ping. | 10:03.43 |
| | the owner password bug was introduced with commit b1ed116091b790223a976eca2381da2875341e10 | 10:04.11 |
| Robin_Watts | ok... | 10:04.41 |
| | oh, crap. | 10:05.25 |
| | OK, so revert that? | 10:08.00 |
| | There probably ought to be a check in there for n > 32 though. | 10:08.12 |
| tor8 | Robin_Watts: question is what to do about the valgrind issue that it was supposed to fix | 10:08.17 |
| kens | OK my router is playing silly beggars on Wi-Fi, so I need to power it off, if that doesn't work its a factory reset, so I may be gone some time....... | 10:08.36 |
| Robin_Watts | if (n > 32) n = 32; should probably solve the valgrind problem, right? | 10:08.54 |
| tor8 | n is /Length / 8 | 10:08.59 |
| Robin_Watts | key is a maximum of 32 long. | 10:09.25 |
| tor8 | how do we reproduce the valgrind problem? | 10:09.28 |
| Robin_Watts | hence n cannot be longer than 32 or we'll overflow. | 10:09.32 |
| tor8 | yeah, clipping n like we do with pwlen might be the right thing to do | 10:09.46 |
| | and pray that we never get cryptos with more than 256 bits :) | 10:10.03 |
| Robin_Watts | well, if we do, it'll need a further fix. | 10:10.18 |
| tor8 | or throw an error instead of truncating? | 10:10.19 |
| Robin_Watts | could do. | 10:10.35 |
| tor8 | hm, we have a sanity check for crypt->length, but *only* for v==2 or v==4 | 10:13.11 |
| | if I move that down to cover all the crypto revisions, and then revert the problem commit we should be good | 10:13.28 |
| Robin_Watts | cool. | 10:16.05 |
| | I wonder if we have increased the length of key recently. | 10:16.29 |
| tor8 | Robin_Watts: I think we implemented more crypto revisions and forgot to move the sanity check | 10:16.51 |
| Robin_Watts | line 679 | 10:16.54 |
| | Doesn't that assume that key is of length 16 for r >= 3 | 10:17.14 |
| tor8 | md5 is only a 16 byte digest | 10:17.18 |
| | the "algorithms" for PDF encryption are just insane | 10:17.45 |
| Robin_Watts | md5 is 64 bytes. | 10:18.07 |
| | oh, 64 byte buffer. | 10:18.18 |
| | 16 byte 'state'. | 10:18.24 |
| tor8 | the output from md5 is only 16 bytes IIRC | 10:18.38 |
| Robin_Watts | The 16 in the fz_md5_update call is the inlen though. | 10:18.40 |
| | so eveidently we only md5 update on the first 16 bytes of the key, even if the key is larger. | 10:19.07 |
| tor8 | 3.(Revision 3 or greater) Do the following 50 times: Take the output from the previ- | 10:19.23 |
| | ous MD5 hash and pass it as input into a new MD5 hash. | 10:19.23 |
| | so that's hashing the 16-byte output from the previous round of md5 | 10:19.33 |
| Robin_Watts | right, so key is only 16 bytes long at that point. | 10:20.05 |
| | so how, in step 2, can we be using 32 bytes of key? | 10:20.22 |
| | In the file you are testing, what is 'n' ? | 10:21.28 |
| tor8 | length is 128 | 10:22.06 |
| | so 16 | 10:22.10 |
| | yeah, something's still fishy | 10:22.17 |
| Robin_Watts | OK, so for (i = 0; i < 16; i++) | 10:22.33 |
| | rather than 32. | 10:22.40 |
| | and fz_arc4_init(&arc4, xor, 16); ? | 10:22.50 |
| | That will keep this file working, but will stop us accessing into the bad range of key. | 10:23.33 |
| tor8 | Robin_Watts: let me re-read the PDF reference | 10:23.40 |
| | page 126 of pdf reference 1.7 | 10:24.09 |
| | algorithm 3.3 | 10:24.12 |
| | steps 1,2,3 are fine | 10:24.43 |
| | oh, grah. this is too confusing! | 10:25.44 |
| | I should be reading algorithm 3.7 | 10:26.05 |
| | 3.7 step 2 | 10:28.22 |
| | the key length in 3.7 step 2 comes from 3.3 step 4. for revision 3 or greater, depends on the value of the encryption dictionary's Length entry | 10:29.19 |
| | so I think we could very well be using more than 16 bytes there... but maybe revision 3 doesn't allow for more than 128 bits? | 10:29.47 |
| | or we should be zero-padding it | 10:29.56 |
| Robin_Watts | I don't have the spec in front of me. Hold on... | 10:31.10 |
| tor8 | only if V is 2 or 3: the value must be a multiple of 8, in the range 40 to 128 | 10:31.35 |
| Robin_Watts | line 674 of the source. | 10:32.56 |
| | if (crypt->r >= 3) | 10:33.02 |
| | Thats 3.3 step 3. | 10:33.13 |
| tor8 | yes. | 10:33.31 |
| Robin_Watts | After that point (in our code at least), only the first 16 bytes of key are valid. | 10:33.35 |
| | (if r >= 3) | 10:33.46 |
| tor8 | and in at that point in the code, length >= 40 && length <= 128 | 10:33.51 |
| | so 5 <= n <= 16 | 10:34.01 |
| Robin_Watts | right. | 10:34.05 |
| tor8 | I suspect, but I'm not 100% convinced yet | 10:34.51 |
| Robin_Watts | Line 694 of our code is 3.3 step 4 (for r >= 3) | 10:35.52 |
| | sorry, let me try that again. | 10:36.20 |
| tor8 | 3.3 step 4 is implicit, there's no code for it | 10:36.55 |
| | line 694 is 3.7 step 2 "Decrypt the value of the encryption dictionary's O entry (first iteration) " | 10:38.10 |
| Robin_Watts | If n <=16 then we're fine. I think just revert my change and fix the test for length | 10:40.28 |
| tor8 | Robin_Watts: look on tor/master | 10:40.51 |
| | there's a few other commits there | 10:41.01 |
| | but now I gotta run for lunch before I faint from hunger... | 10:41.09 |
| Robin_Watts | Rolling the two together would be nice, as it would avoid us reintroducing the same valgrind bug, however briefly. | 10:42.25 |
| | Is the second one correct though? | 10:42.35 |
| tor8 | Robin_Watts: sure. I can do that. | 10:42.37 |
| Robin_Watts | surely we should have if (r <= 2) { existing check } else { new check } | 10:42.59 |
| tor8 | page 117 of the pdf reference, table 3.18 | 10:43.01 |
| Robin_Watts | cos lengths of 0 and 256 might be allowed for r = 2? | 10:43.17 |
| tor8 | the "Length" key is only read for V==2 and V==4 | 10:43.33 |
| | and then it must be 40..128 | 10:43.41 |
| Robin_Watts | 2 or 3 ? | 10:43.54 |
| tor8 | don't confuse R and V as I did when reading it the first time :) | 10:44.07 |
| Robin_Watts | ok :) | 10:44.19 |
| tor8 | sorry, V==2 or V==3 | 10:44.22 |
| Robin_Watts | fair enough. | 10:44.24 |
| tor8 | even more confusing! | 10:44.28 |
| Robin_Watts | lgtm then. | 10:44.29 |
| tor8 | this pdf-crypt mess should probably be refactored to better align with the pdf reference | 10:45.02 |
| | it's grown features in pace with the pdf reference, but never realigned itself with the text | 10:45.25 |
| | so it's really hard to follow | 10:45.29 |
| Robin_Watts | The PDF ref is hard to follow! | 10:45.41 |
| tor8 | we don't support V == 3 at all | 10:45.45 |
| | so that fix is probably wrong | 10:45.49 |
| | it should be as you said | 10:45.52 |
| | if V == 2 then use a stricter range test | 10:45.59 |
| | but Length shouldn't be used at all for V == 4 | 10:46.07 |
| | I'll have to consider this after lunch | 10:46.25 |
| | line 183 should probably be different | 10:46.42 |
| Robin_Watts | sure. I have to pop out for a bit soon. | 10:46.45 |
| cryptopsy | mupdf isn't displaying properly, heres example: | 12:34.24 |
| | cl | 12:34.53 |
| | http://i.imgur.com/MBgGFVl.png | 12:35.04 |
| | on the left side you see a document im viewing with 'W' mode | 12:35.15 |
| | its hilighted because im copying it | 12:35.23 |
| | notice the last line | 12:35.27 |
| | it ends with "being" | 12:35.31 |
| | notice the text on the right, it pasted more than what is after being | 12:35.40 |
| | after the word "being" that is | 12:35.44 |
| | that means mupdf isn't display at least one line and 3/4 of the second last line | 12:36.00 |
| | we know this because it managed to copy more than is displayed! | 12:36.11 |
| kens | We'd need to look at the original PDF file | 12:36.38 |
| cryptopsy | i'll upload it for you | 12:36.46 |
| kens | The text might (for example) be drawn in white | 12:36.48 |
| cryptopsy | that's not possible, because you can see the gray margin at the bottom | 12:37.00 |
| kens | I'd suggest you open a bug report | 12:37.00 |
| | grey then, or TR 3 | 12:37.12 |
| cryptopsy | the original document is a ppt with white background all throughout | 12:37.30 |
| | what a coincidence it would be that it converted exactly that part into gray text to blend with the exact same shade of gray in linux mupdf | 12:37.49 |
| kens | Its possible, and like I said, there are other possibilities | 12:38.06 |
| | THar was merely an example | 12:38.15 |
| | Hence the (for example) | 12:38.23 |
| cryptopsy | i would like to point that also that mupdf is situated at the bottom left corner of my desktop, so i could not have scrolled outside of mupdf | 12:38.36 |
| kens | Please simply open a bug report | 12:38.51 |
| cryptopsy | i cannot, but if you want the pdf file, suggest where i can upload it | 12:39.42 |
| kens | Why can't you open a bug report ? | 12:39.52 |
| cryptopsy | i am in exams week and short on time | 12:40.03 |
| | maybe it will come up in the future again, then i will file a bug | 12:40.34 |
| kens | To be honest, we're all quite busy too, and nobody is going to drop everythign to look at this. If you open a bug it won't get forgotten about | 12:40.41 |
| Robin_Watts | ok. good luck with the exams. | 12:40.49 |
| cryptopsy | it doesn't bother me so much that if a fix was provided on the spot would improve my situation | 12:41.12 |
| | my profession is not software developper | 12:41.35 |
| Robin_Watts | our profession is software development. | 12:42.05 |
| | This means we get paid for it. | 12:42.10 |
| | This means that stuff we are being paid for takes priority over stuff that we're doing for free. | 12:42.26 |
| cryptopsy | yes ... understood | 12:42.38 |
| | as i | 12:42.48 |
| Robin_Watts | as such, if people want us to use our time to do stuff for free, it seems reasonable to make them do as much as they can to simplify our job. | 12:43.00 |
| cryptopsy | the same applies for me | 12:43.17 |
| Robin_Watts | hence we ask people to open a bug report and put a clear description of how to reproduce the problem on it. | 12:43.29 |
| | That minimises the time we have to spend struggling to reproduce stuff when we have time to fit the work in. | 12:43.58 |
| | It also avoids us forgetting about it. | 12:44.06 |
| cryptopsy | i think it was understood what the problem is from what i reported, if more information is requested, i cannot provide it | 12:44.26 |
| | besides uploading the pdf, because it coincides with my goal to find a pastebin for any filetype , since omploader closed down | 12:44.51 |
| Robin_Watts | cryptopsy: No one has time to look at this problem now. Hence we'll have to get back to it in a few days/weeks when we can. | 12:45.16 |
| cryptopsy | yea there's megaupload, but im not feeling like breaking a captcha and signing in everytime there's a bug | 12:45.17 |
| | Robin_Watts: i am ok with that | 12:45.33 |
| Robin_Watts | Hence we need the problem "parked" on the bug tracker. | 12:45.35 |
| | If you can't be bothered to invest the time in opening a bug, why should we be bothered to invest the time solving your problem? | 12:46.05 |
| cryptopsy | hence why i don't file a bug report (because i don't have time to make a formal report with all the necessary information) | 12:46.07 |
| | because i invested the time to make sure all the information is there to show you there's a certain problem in a certain subset of mupdf functionality | 12:46.42 |
| | yet, not sufficient for a bug report | 12:46.51 |
| | bug report is beyond recognition there's a problem, but actually part of the fixing process, and i cannot take part in that | 12:47.38 |
| kens | your definition of a bg report and ours seems to differ. | 12:48.03 |
| cryptopsy | if i file this bug report in gentoo bug forum, i have to fill out 10 fields and upload 10 files | 12:48.15 |
| kens | No, *our* bug tracker | 12:48.25 |
| Robin_Watts | bugs.ghostscript.com | 12:48.26 |
| cryptopsy | kens: well yes, i am fully aware of that, but they don't ask those extra fields just because | 12:48.44 |
| | it has information on how each package is compiled and linked, paths, stuff like this, | 12:48.58 |
| kens | we don't ask that | 12:49.05 |
| Robin_Watts | A bug report on our tracker would require no such effort. Just the same information you gave here, plus an example PDF. | 12:49.22 |
| cryptopsy | can i upload file directly to the bug track? | 12:49.43 |
| kens | yes | 12:49.47 |
| cryptopsy | do i have to registeR? | 12:49.49 |
| kens | yes the first time only | 12:49.59 |
| | we get spammers too | 12:50.24 |
| cryptopsy | in a month im gonna forget my password | 12:50.27 |
| | 4chan gets spammers too, but put a captcha so users dont have to register like dying forums | 12:50.39 |
| kens | You've spent more time arguing about it than you would have submitting the report | 12:51.03 |
| cryptopsy | talking about it had more objectives than fixing the problem | 12:51.15 |
| kens | You don't like cpatchas evfery time, and you don't like passwords, what *do* you like ? | 12:51.36 |
| cryptopsy | like, take chance i dont have to file formal bug report, like discover upload servers, like learn other functionality of mupdf | 12:51.37 |
| | break one sentence captcha would be okay per bug report | 12:51.54 |
| | theres no site on the net that even ask for that long a captcha | 12:52.08 |
| kens | OK well that's not going to happen, not least because thoise of us that use it often would be infuriated | 12:52.29 |
| | As Robin_Watts said good luck with your exams | 12:52.42 |
| cryptopsy | how do you remember all your accounts when you file bug reports across 50 communities? | 12:54.04 |
| tor8 | cryptopsy: the mupdf selection box is designed to select any text that it touches, not just what is completely inside the box | 12:54.04 |
| cryptopsy | tor8: yes i reported that yesterday | 12:54.17 |
| | i think you misunderstood, but am gonna idle now and you can read up | 12:54.31 |
| tor8 | I saw your discussion with sebras yesterday on the IRC logs | 12:54.32 |
| cryptopsy | yes, its different from that this time ... the problem is with display, ttyl | 12:54.43 |
| tor8 | whether that's a good design decision, I'm not so sure, but that's what it does in case there's any confusion about what it should do | 12:55.22 |
| | cryptopsy: mupdf will select everything in the selection drag box, which is made from your mouse events. | 12:58.40 |
| cryptopsy | that's not the point | 12:58.48 |
| tor8 | if the window is too short to display the full box, it will still select it. | 12:58.51 |
| | 'W' mode fits the page width to the window width | 12:59.03 |
| | there's more text below if you scroll... | 12:59.09 |
| cryptopsy | are you trying to troll me into filing a bug report? | 12:59.22 |
| tor8 | I'm trying to understand what your problem is... | 12:59.36 |
| cryptopsy | well, it doesn't matter | 12:59.43 |
| tor8 | but fine, if you want to be aggressive, so can I | 12:59.45 |
| | *plonk* | 12:59.48 |
| Robin_Watts | tor8: I think that might take more time than we have here :) | 12:59.59 |
| cryptopsy | if you're not gonna file a bug report we're both wasting our time | 13:00.04 |
| | i, of course am not (yet) | 13:00.10 |
| Robin_Watts | cryptopsy: We have been very clear. We are not going to file a bug report. | 13:00.22 |
| cryptopsy | Robin_Watts: just you two, i don't know who that guy is | 13:00.33 |
| Robin_Watts | tor is the original author of mupdf. | 13:00.42 |
| cryptopsy | why he's asking me all those questions when its you're so damn clear about it | 13:00.48 |
| Robin_Watts | it seems that tor might have been prepared to work on the bug without a bug report, but... that train has sailed now. | 13:01.43 |
| cryptopsy | yea, that's too bad | 13:01.52 |
| | in irc, people ramble a lot, so i don't blame myself for this escalation | 13:02.45 |
| | maybe if i had known tor8 is lead dev | 13:02.57 |
| | <...> | 13:03.07 |
| | tor8 should not feel like he's hurting my feelings though, like i said before, doesn't bother me at all this problem | 13:03.41 |
| tor8 | if I'm trying to understand the problem and am met with statements like "are you trying to troll me into filing a bug report?" and "well, it doesn't matter" when asking what the problems you're having are... | 13:04.02 |
| | what kind of impression does that leave? | 13:04.14 |
| cryptopsy | actually, i am not even aware he's unblocked me | 13:04.17 |
| | so i feel like i'm talking to a ghost right now | 13:04.22 |
| Robin_Watts | This is why we should have more people being operators just just ray. | 13:05.01 |
| kens | I was thinking of saying that but it souinded provocative | 13:05.16 |
| cryptopsy | tor8, if you're listening, ask yourself what impression does it leave when i'm not a resident of this channel, but suddenly confronted with load of questions from someone i don't know? well, it leaves me with the impression that its a rambling fool, like we see in #linux | 13:05.24 |
| | i've spoken to robin and kens before, so i know who they are | 13:05.35 |
| | ah, as far as irc is, i dont know them IRL | 13:05.47 |
| | robins and kens are determined not to file bug for me (am okay with this), so it came off as strange the barage of questions from someone i don't know after that | 13:06.31 |
| | and, there's no prefix to your irc nickname suggesting to me who's operator, because operator of a channel usually is some authority to the project as well | 13:07.01 |
| | like +cryptopsy, or @cryptopsy | 13:07.08 |
| kens | Our one an only operator is not online, that's robin's point | 13:07.29 |
| cryptopsy | so, if tor8 had some symbol, then i would have known he's some kind of important person in the project, but did not | 13:07.54 |
| kens | We're pretty democratic. We take our users problems eriously and we try to help. However, we can't always be here and we can't always take problem son there and then. So we ask people toi file bug reports so that we can get to them when we have time. Otherwise we forget things. That's all there is to it, nothing sinister here. | 13:09.32 |
| cryptopsy | i knew that going in with the way i intended and did proceed | 13:10.20 |
| | typically, i discover bugs that persist, so that means even though there's huge chance my message is forgotten, i know im likely to follow up, --- but didnt feel this is that kind of case | 13:10.53 |
| | i converted from ppt to pdf after editing the slides myself, so i know the text doesn't go infinitly down underneath the margin of the program --- so i know i cannot miss more than 1 or 2 lines | 13:11.30 |
| | 1 occurance in 250 slides, is not a big deal | 13:11.47 |
| sebras | omg, what is happening?! :) | 13:13.08 |
| kens | Nothing | 13:13.15 |
| tor8 | Robin_Watts: so, there's a squashed and slightly revised fix for the owner password stuff on tor/master | 13:29.46 |
| | if you could give that a quick review I'd be grateful | 13:29.53 |
| | and the other two cmap ones as well, but I'm not sure I fix all of zeniko's signedness woes with that. He'll have to complain again if it doesn't work :) | 13:30.25 |
| | no cluster differences in any of them, which is nice (or bad, since that means we don't test owner passwords anywhere...) | 13:31.00 |
| kens | I don't think we can test owner passwords, we'd have to set the cluster up to add a parameter (at least for Ghostscript) and if they were all the same, would that be a worthwhile test.... | 13:42.23 |
| Robin_Watts | tor8: will look. | 13:48.50 |
| | kens: For every blah.pdf file we'd have a blah.pdf.password file with the password in. Or something like that. | 13:49.13 |
| | tor8: password thing lgtm | 13:51.23 |
| | sizeof should always have () IMAO. | 13:53.04 |
| | other two look plausible to me other than the sizeof grumble. | 13:54.02 |
| kens | wonders if Ray might have troulbe getting to the office today: | 13:54.30 |
| | http://www.bbc.co.uk/news/world-us-canada-27426220 | 13:54.30 |
| chrisl | That doesn't look pleasant! | 13:55.55 |
| kens | Well, *I* woudn't want to be living near it.... | 13:56.12 |
| | Looks like TIll just broke the build | 13:58.33 |
| | gdevcups.c doesn't compile | 13:58.48 |
| tor8 | Robin_Watts: bah, how else can you tell the difference between "sizeof expression" and "sizeof (type)"? | 13:58.53 |
| Robin_Watts | sizeof(expression_or_type) :) | 13:59.20 |
| chrisl | kens: shall I pull that commit out? | 13:59.37 |
| kens | chrisl unless tkamppeter wantsw to chime in ? | 13:59.50 |
| tor8 | sizeof is not a function call, it's an operator, so I don't like when it looks like a function call | 13:59.52 |
| | same with putting parens around the return value | 14:00.00 |
| | Robin_Watts: anyway, thanks for reviewing | 14:00.20 |
| chrisl | kens: well, either way, we don't want broken commits | 14:00.23 |
| kens | No, it makes git bisect difficult to use. Best pull it out | 14:00.40 |
| chrisl | tkamppeter: ping | 14:01.02 |
| | okay, the broken commit is gone.... | 14:01.49 |
| kens | thanks | 14:02.01 |
| chrisl | Well spotted kens! | 14:02.29 |
| kens | :-) | 14:02.33 |
| tkamppeter | chrisl, what is the problem with my last commit? | 14:04.51 |
| chrisl | tkamppeter: see http://www.ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=9ee3be5cd026245de7c7f5372ceabb33ab056dba&project=ghostpdl | 14:05.07 |
| tkamppeter | chrisl, it asks for user name and password, and I fear I do not have them. | 14:06.39 |
| | chrisl, it is a small patch and I can compile GS with it. What is wrong with it? | 14:07.27 |
| kens | It fails to cimpile on the cluster: | 14:07.46 |
| | ./cups/gdevcups.c | 14:07.47 |
| | ./cups/gdevcups.c: In function 'cups_print_pages': | 14:07.47 |
| | ./cups/gdevcups.c:2896:6: error: 'CUPS_RASTER_WRITE_PWG' undeclared (first use in this function) | 14:07.47 |
| chrisl | I bet CUPS_RASTER_WRITE_PWG doesn't exist in our copy of the cups code..... | 14:08.23 |
| tkamppeter | kens, so the problem is that it only works with the system's lib and not with the stone-old built-in one? | 14:08.27 |
| kens | Don't know tkamppeter, I am not a Linux build expert | 14:08.59 |
| | but CHris seems to agree | 14:09.19 |
| tkamppeter | chrisl, kens, so I will reload the GIT, add this constant, and add my patch again. Sorry for the inconvenience. | 14:09.48 |
| kens | Its OK Till, these things happen. Chris should we be compiling in a more up to date version of Cups ? | 14:10.17 |
| | And shouldn't Till have the ability to do a cluster test ? | 14:10.51 |
| chrisl | kens: well, you did the cups lib stuff, so...... but this is exactly why I argued against including it. | 14:11.07 |
| | Till does have the ability to clusterpush | 14:11.18 |
| kens | Hmm, but if we don't include it,tehn it won;t work on Windows where there is no CUPS library | 14:11.32 |
| henrys | kens: add drought heat over 100 they ought to mop that up quickly | 14:11.44 |
| kens | henrys ooh, that could be unpleasant | 14:11.58 |
| chrisl | And till also seems to have a bmpcmp password..... | 14:13.15 |
| tkamppeter | chrisl, kens, I think we should update the built-in CUPS, as there changed a lot, especially the ability to handle PWG Raster. This would be needed for example that your ebedded system customers can make there devices print on IPP Everywhere printers. | 14:13.32 |
| chrisl | tkamppeter: the problem is, what we have is patched because cups (as we got it) wouldn't build on Windows | 14:14.17 |
| kens | Indeed. | 14:14.35 |
| chrisl | I have no feel for what's involved in repeating that process | 14:14.48 |
| kens | Though I no longer remember what I did | 14:14.51 |
| chrisl | I can take a crack it when I have some spare time...... but no promises | 14:15.35 |
| kens | Fair enough | 14:15.41 |
| tkamppeter | kens, chrisl, I cannot maintain a "Windows version" of CUPS and CUPS upstream explicitly does not support Windows. | 14:15.54 |
| kens | I'm currently lost in patterns and image matrices..... | 14:15.55 |
| | tkamppeter : well the only reason we have cups in there, if I remember correctly, is so that we (I) can debug the CUPS device on Windows. | 14:16.33 |
| chrisl | And mvrhel_laptop because of all the weird color spaces cups uses | 14:17.01 |
| henrys | tkamppeter: what's the licensing of the IPP Everywhere? | 14:17.10 |
| kens | Oh yes, I forgot about Michael | 14:17.11 |
| tkamppeter | kens, chrisl, what I can do is to assure correct PWG Raster support for Linux users at least, to define the constant in gdevcups.c so that it simply builds in your cluster but without warrenty that it actually works under Windows. | 14:17.12 |
| chrisl | tkamppeter: it doesn't really "work" under under Windows, it just allows some folks to debug the cups device on Windows | 14:18.07 |
| henrys | tkamppeter: if we could dual license it and create a commercial product porting it would be higher priority. | 14:18.17 |
| kens | If we can manage it, I'd prefer something a little closer to the real cups library. It doesn't have to work with CUPS under WIndows, just produce cups rasters | 14:18.30 |
| tkamppeter | henrys, IPP Everywhere is a PWG standard. AFAIR it is something free what can be used in both free and closed-source software, but in reality the PWG standard is not actually code. | 14:18.39 |
| chrisl | tkamppeter: if you can put in the patch to get your revised code building on the cluster for now, I will try to update cups to a fresher version in near future | 14:20.19 |
| | tkamppeter: but, once again, *please* regression test your changes before committing them - it is standard practice for Ghostscript development | 14:21.16 |
| ray_laptop | morning, all | 14:30.41 |
| kens | Hi Ray, how's the oiil ? | 14:30.53 |
| ray_laptop | Robin_Watts: BTW, I didn't commit the patch for the USE_LARGE_COLOR_INDEX because I found a minor problem (it wouldn't build gdevp14) | 14:31.56 |
| henrys | ray_laptop: are you melting ? | 14:32.27 |
| kens | Frying :-) | 14:32.35 |
| ray_laptop | The funky remnant of compressed color stuff in gdevp14 can't handle component map (e.g. colorant) that are arrays | 14:32.54 |
| | henrys: kens: it _is_ warm, but supposed to be cooling somewhat starting tomorrow | 14:33.27 |
| kens | And the oil gusher ? | 14:33.49 |
| henrys | ray_laptop: there was a very long discussion about your devn changes yesterday in the logs | 14:34.24 |
| kens | read it but didn't really comprehend it | 14:34.43 |
| ray_laptop | generally I stay indoors as much as possible. But the dry air and wind make the eyes dry out, so I have to work a bit harder on the left since it still doesn't blink all the way | 14:34.45 |
| | henrys: I will review the logs | 14:35.11 |
| henrys | ray_laptop: maybe they're making a big deal of it, but they did say century record heat. | 14:35.30 |
| | Robin_Watts: sabrina and I finished Dust. I don't know if I want to go straight in Banks just yet ⦠a bit sci fi'd out just now | 14:39.02 |
| Robin_Watts | henrys: Well, maybe read some Iain Banks rather than Iain M Banks? :) | 14:39.43 |
| kens | henrys I could lend you the Banks novels, could bring one to the stafff meeting. Or Robin_Watts may have them in ebook form | 14:39.44 |
| Robin_Watts | I have them in dead tree form. | 14:39.53 |
| kens | me too | 14:40.07 |
| | Oh well | 14:40.11 |
| henrys | I'll probably get the ebooks | 14:40.59 |
| kens | I did notice a couple of new Stross' Laundry novellas only available in Kindle format. Almost tempting enough to buy a Kindle.... | 14:40.59 |
| ray_laptop | henrys: et al.: So the utility functions and structures in gdevdevn (used by several devices) are intended to allow CLIENT colors more than what device can handle allowing a device to process a subset of the colorants that are in the graphics lib | 14:41.00 |
| | the original tiffsep implementation could only do 8 components at a time, and used the SeparationOrder list to select which were to be rendered | 14:42.00 |
| henrys | ray_laptop: that's fine I was talking about the tiff sep device I believe | 14:42.16 |
| Robin_Watts | kens: Or get someone with a kindle to buy them and to de DRM them for you. | 14:42.56 |
| henrys | I think we all agreed the code is *very* confusing an minimally need comments sorting CLIENT vs. DEVICE | 14:42.59 |
| kens | Hmm, if only I knew someone with a Kindle..... | 14:43.13 |
| | Robin_Watts : they are £0.00 | 14:43.25 |
| Robin_Watts | kens: PM me the URLs. | 14:43.35 |
| ray_laptop | the problem is that the device was setting up the entire separation order map, and that _is_ (AFAICT) CLIENT colors | 14:43.35 |
| henrys | kens: install kindle on your laptop | 14:43.38 |
| kens | Robin_Watts : I'll try and find them again, just a mninute | 14:44.01 |
| | or 2 | 14:44.04 |
| ray_laptop | but as I mentioned today, the gdevp14 code can't really handle the component bit map stuff (for compressed color remnants) when it doesn't fit in a COLOR_INDEX | 14:45.46 |
| henrys | so the other idea was to guarantee the number of device components is always larger the MAX CLIENT components. but that blow performance wise | 14:47.18 |
| ray_laptop | since the compressed color stuff is moribund, I could keep the default CLIENT_MAX at 64 and change those elements to be uint64_t _OR_ limit CLIENT_MAX to ARCH_SIZEOF_COLOR_INDEX * 8 | 14:47.34 |
| chrisl | ray_laptop: so my confusion was that there are various places where the interpreter(s) are referred to as "clients", and others where devices are referred to as "clients", so having GS_CLIENT_COLOR_MAX_COMPONENTS isn't terribly clear...... | 14:47.59 |
| ray_laptop | chrisl: I agree, and I didn't pick the nomenclature, and the history from Jan S. is boiled down to henry's commit with the comment "DeviceN." | 14:48.57 |
| chrisl | ray_laptop: no, I realise it isn't your fault! But I did suggest adding a nice, clear comment about the two values | 14:50.28 |
| henrys | ray_laptop: chrisl did find the client limit is device dependent so we should be okay with that sort of limitation | 14:51.15 |
| Robin_Watts | chrisl: I submit that your problem with the naming is not with GS_CLIENT_COLOR_MAX_COMPONENTS so much as gs_client_color itself. | 14:51.20 |
| ray_laptop | chrisl: there were design notes from Jan S around, but I didn't want to have to go on a research project | 14:51.24 |
| tor8 | kens: do you remember how you fixed 691073 for gs? | 14:51.45 |
| Robin_Watts | The names of the #defines seem fine to me. | 14:51.45 |
| henrys | Robin_Watts: right and gs_client_color is from peter so it made sense to use that nomenclature. | 14:52.02 |
| kens | I fixed a bug ? :O | 14:52.09 |
| henrys | for the #define that is | 14:52.09 |
| Robin_Watts | but changing gs_client_color would break many many devices, I fear. | 14:52.10 |
| chrisl | Robin_Watts: actually it's just the overloading of the work "client"..... | 14:52.19 |
| | s/work/word | 14:52.26 |
| kens | tor8 its not shown as fixed.... | 14:52.39 |
| | Oh but its MuPDF | 14:52.56 |
| tor8 | kens: I mean that file, which caused problems in GS (with a different bug number, I'm sure) | 14:52.57 |
| | when you were doing the freetype integration | 14:53.07 |
| kens | Give me a couple minutes to try and find the GS original | 14:53.16 |
| henrys | ray_laptop: anyway we probably aren't going to change "client" | 14:53.21 |
| chrisl | ray_laptop: I also thought a comment about why tiffsep (and gdevn?) are sort of exceptions in that they use "GS_CLIENT_COLOR_MAX_COMPONENTS" in device code | 14:54.03 |
| henrys | ergo the devicen patch and henrys are off the hook ;-) | 14:54.15 |
| chrisl | It might be good to actually address previous mistakes sometimes...... | 14:55.09 |
| kens | Oh good grief, I remember that file...... Fixing it was horrible. and I htink it was all done in FAPI | 14:56.29 |
| chrisl | Oh, what file is that? | 14:57.03 |
| kens | Its the horrendous arrows in funny orientations | 14:57.21 |
| | following a path | 14:57.27 |
| tor8 | kens: if it's a horrible fix, I'll be quite glad to mark it WONTFIX (too difficult) | 14:57.43 |
| chrisl | Oh, right, yes that was fun.... I thought that was a Postscript file.... | 14:57.57 |
| kens | tor8 it may not be so bad for you, the area I recall was all to do with FAPI handling this file | 14:58.07 |
| | chrisl it was a PS file, but the PDF result seems to be a MuPDF problem | 14:58.23 |
| ray_laptop | I think CLIENT_COLOR_MAX_COMPONENTS is OK as is, but I'll review the descriptions and try to add some comments per chrisl and others | 14:58.26 |
| kens | OK so the PDF file doesn't work in GS either | 14:58.55 |
| tor8 | gs is showing the PDF correctly. both evince and mupdf have the same problems with it. | 14:59.00 |
| kens | GS doesn't show it for me.... | 14:59.09 |
| | Of course, I could have broken my GS | 14:59.18 |
| chrisl | Is the PDF on a bug somewhere? | 14:59.30 |
| kens | 691073 | 14:59.51 |
| | D'oh, I'm in the wrong directory, and of coruse I have a file with the same name..... | 15:00.14 |
| tor8 | kens: it works on my freshly built gs of origin/master | 15:00.19 |
| kens | Yeah, now GS works | 15:00.31 |
| | Helps if you use the right test file, instead of the one you're working on | 15:00.46 |
| tor8 | :) | 15:00.55 |
| kens | Its only some pages that are wrong | 15:01.27 |
| tor8 | kens: did you find the original bug# for gs? | 15:01.32 |
| kens | There is no original bug I'm afraid | 15:01.44 |
| | This was all part of making FAPI work so that we could integrate FreeType | 15:02.00 |
| | as chrisl says, the original file is a PostScript file. | 15:02.10 |
| | Clearly at some point I tested the PDF output in MuPDF and discovered it was incorrect. I'm forced to agree that it probably was incorrect in GS at that point too, which was why I tested it in MuPDF. | 15:03.17 |
| tor8 | yeah, in some of the pages the scaling is off, 7 and 9 are too small, 8 in sucked into a black hole | 15:03.32 |
| kens | But this was before we were using Git, I doubt there is any history to follow | 15:03.39 |
| tor8 | kens: alright. I'll have to dig on my own then. figured it'd be worth asking anyway. | 15:04.06 |
| kens | tor8 yes, its not *many* pages. | 15:04.07 |
| | tor8 always worht asking, sorry I can't remember, its been rather a long while | 15:04.20 |
| chrisl | I take it gs displays it similarly to Acrobat? | 15:04.21 |
| kens | chrisl yes | 15:04.25 |
| | GS is fine, Acrobat is fine | 15:04.31 |
| | Well I say that. They are the same, and correct as per the original PostScript | 15:04.48 |
| | Its possible there is something wrong with the PDF we produce and somehow GS and Acrobat fix it, but then, Acrobat is the standard..... | 15:05.25 |
| chrisl | This was the file that inspired the major revamp in how scaling is handled in the FAPI interface layer | 15:05.43 |
| kens | tor8 6,7,8 are wrong for me, 9 is OK. 18 and 20 are wrong as per the previous ones, 19 the text vanishes | 15:06.45 |
| chrisl | We forcibly replace the font matrix with a identity matrix for Freetype, then incorporate the entire scale/transform into the scale/matrix we pass into freetype..... | 15:09.57 |
| kens | Urgh, well I did remember this whole area as being a right royal pain, from the PostScript file. Presumably after we got the PostScript working, the PDF file 'just worked' | 15:10.44 |
| chrisl | Yes, I think that's probably true. | 15:11.25 |
| | mupdf won't be able to use the same approach since it doesn't recreate the font stream for freetype in the way we do in FAPI | 15:12.11 |
| kens | Oh, well that pretty much puts a stopper on us prividing any help. Maybe there's a clue that its font scaling. | 15:12.44 |
| | I seem to remember this was one of the 'edge cases' we had to deal with, I'm sure these are extremely rare. | 15:13.28 |
| chrisl | My first punt would be to pull the offending type 1 streams out the PDF, and see if the standalone freetype tools handle them - it *might* be a freetype problem | 15:13.35 |
| tor8 | chrisl: ugh. so this is a bug in freetype that you work around then. | 15:18.55 |
| kens | It looks like it. Maybe we should have fixed it in FT and passed it upstream | 15:19.32 |
| chrisl | tor8: tbh, I don't know - I'm saying, with what I know now, that'd be my first port of call | 15:20.26 |
| | It's possible (but no established) that Freetype doesn't correctly handle rotation/skew font matrices | 15:21.30 |
| kens | Robin_Watts : henrys I grabbed kindle for PC and picked up the book, it has no DRM :-) | 15:21.57 |
| kens | is very happy | 15:22.01 |
| tor8 | yeah, it looks like a freetype bug. ftview on the extracted files shows the same scaling problems. | 15:23.10 |
| henrys | kens:there is even a cloud kindle if you don't want to be tied to a device | 15:23.28 |
| tor8 | kens: what is this book? | 15:24.25 |
| kens | Equoid its a Laundry novella | 15:24.42 |
| | set between books 3 and 4 I think | 15:25.03 |
| tor8 | kens: oh, that one. I made my own book of that from the one on the web. | 15:25.04 |
| | nasty unicorns | 15:25.13 |
| kens | Apparently so yes | 15:25.27 |
| chrisl | tor8: given that we work around the freetype problem the way we do, I'd guess it's a matrix multiplication order problem | 15:26.33 |
| tor8 | chrisl: or it tries to decompose the scaling factor to do the hinting, and then fails to reapply the skew properly | 15:27.06 |
| chrisl | tor8: we disable type 1 hinting..... it's applied unscaled, so isn't very worthwhile | 15:27.41 |
| tor8 | it might hit some unfortunate numeric precision issues | 15:27.47 |
| | chrisl: we disable *all* hinting, but I think freetype still does the scaling in multiple steps as if there was a hinting pass | 15:28.17 |
| chrisl | tor8: have you looked at the internals of freetype much? | 15:28.47 |
| kens | We could throw it over the wall to the FT community, but it would be nice if we could diagnose it and come up with a fix | 15:28.54 |
| tor8 | chrisl: no, they scare me with their odd module systems :) | 15:29.05 |
| kens | I think there aren't many people there capable of dealing with a Type 1 font. | 15:29.17 |
| tor8 | I've poked around sometimes, but I always get lost in some of the function pointer indirections | 15:29.25 |
| | kens: it's a CFF font in the embedded PDF, which probbaly makes for even fewer capaple people | 15:29.48 |
| chrisl | tor8: yes, it's "interesting" isn't?! If you want to assign it to me, mention in the bug it's a freetype issue, I'll get to it at some point | 15:29.54 |
| kens | well, CFF is just a reduced type 1.... | 15:30.02 |
| tor8 | chrisl: fab. I'll assign it to you, and mark it as an enhancement. | 15:30.24 |
| chrisl | tor8: sounds good. It may be a while, though...... | 15:31.07 |
| kens | Its been 4 years already :-) | 15:31.33 |
| tor8 | chrisl: I'm in no rush :) | 15:31.35 |
| chrisl | If I have to have bugs, these are the ones I like ;-) | 15:31.59 |
| tor8 | like I said, I'd be okay with just saying WONTFIX but if you want to send it to Werner at some point in the future I'll leave it open | 15:32.04 |
| kens | I think its *highly* unlikely to come actoss real PDF files with this sort of font | 15:32.10 |
| chrisl | well, the original type 1 was hand coded - freetype wouldn't actually read it at all..... | 15:32.50 |
| kens | ROFL | 15:33.00 |
| chrisl | Well, it uses "normal" Postscript - which freetype doesn't do | 15:33.25 |
| kens | fair ebough I guess | 15:34.01 |
| chrisl | Aha, it seems I've had the kindle app on my tablet all along...... | 15:35.30 |
| mvrhel_laptop | good morning | 15:50.04 |
| ray_laptop | gah. This GS_CLIENT_COLOR_MAX_COMPONENTS vs. GX_DEVICE_COLOR_MAX_COMPONENTS is a mess w.r.t MAX_SEPARATIONS | 15:55.15 |
| | as chrisl pointed out. | 15:55.25 |
| | I was going to try and clean up the documentation, but it is such a mess | 15:56.03 |
| mvrhel_laptop | ray_laptop: yes. I was always very confused by all that | 15:57.06 |
| chrisl | ray_laptop: I think that's probably a "project" in itself.... :-( | 15:57.34 |
| ray_laptop | for example the SeparationOrder uses GX_DEVICE_COLOR_MAX_COMPONENTS as a "special" value in the sep map to indicate separations which are not in the SeparationOrder array, but MAX_SEPARATIONS is set to GS_CLIENT_COLOR_MAX (even though the code will not actually allow more than GX_DEVICE_COLOR_MAX) | 15:58.16 |
| | so it looks like maybe that the CLIENT_COLOR_MAX should never exceed the DEVICE_COLOR_MAX | 15:59.09 |
| | but it can be less than the DEVICE_COLOR_MAX | 15:59.32 |
| chrisl | ray_laptop: could that potentially hamper our ability to handle large DeviceN spaces in the interpreter? | 16:01.14 |
| mvrhel_laptop | ray_laptop: so I know you all had this discussion, but CLIENT in this case is the interpreter | 16:01.21 |
| ray_laptop | so maybe it will suffice for now to just add that bit of documentation (and a #if check to compile fail if that invariant is missed) | 16:01.22 |
| mvrhel_laptop | ? | 16:01.23 |
| ray_laptop | mvrhel_laptop: right, CLIENT is the interpreter, and it can be set to < DEVICE_COLOR_MAX for performance reasons (or so claims the documentation) | 16:02.27 |
| | I'm not sure that the performance issues still exist | 16:02.42 |
| | or at least that CLIENT_COLOR_MAX will help much since most of the code that has arrays uses DEVICE_COLOR_MAX | 16:03.23 |
| mvrhel_laptop | I don't quite understand the need for the CLIENT limit. I would think the device limit would drive everything (as to if we are going to use the alternate tint transform) | 16:03.51 |
| ray_laptop | mvrhel_laptop: and you fixed the biggest performance hit with getting rid of the clues array of colors | 16:04.13 |
| mvrhel_laptop | is there some array allocation limit in the interpreter that would make one have the CLIENT number be different than the DEVICE? Or is the CLIENT one more important for the high level devices? | 16:05.25 |
| chrisl | mvrhel_laptop: don't we retain the original color space, even when we need to run the tint transform? | 16:05.58 |
| ray_laptop | mvrhel_laptop: for the tint transform, that is driven by the device structure's color_info, AFAIK, not the graphics lib's code limits | 16:06.00 |
| mvrhel_laptop | yes. we do. good point. I still don't understand why we need CLIENT limit then. | 16:06.46 |
| ray_laptop | chrisl: what do you mean 'retain the original colorspace' ? | 16:07.06 |
| chrisl | ray_laptop: DeviceN for example | 16:07.19 |
| | What I'm wondering is if GS_CLIENT_COLOR_MAX_COMPONENTS is set to, for example, 4 would we fail on a six component DeviceN space? | 16:08.31 |
| mvrhel_laptop | ok looking over things, I dont believe you would ever want GS_CLIENT_COLOR_MAX_COMPONENTS to be < DEVICE_COLOR_MAX . just as you said ray_laptop | 16:12.31 |
| | it looks like GS_CLIENT_COLOR_MAX_COMPONENTS is used in a few places where it should not be. it also looks like I may have done that :( | 16:14.05 |
| chrisl | mvrhel_laptop: well, gosh, and it's not confusing at all ;-) | 16:14.45 |
| Guest84139 | Hi | 16:14.54 |
| ghostbot | salut, guest84139 | 16:14.54 |
| ray_laptop | mvrhel_laptop: actually, I think I said the inverse. GS_CLIENT_COLOR_MAX can never exceed GX_DEVICE_COLOR_MAX | 16:15.59 |
| Guest84139 | a question : it's possible in next release of mupdf add like plattform in source DJGPP with video library GRX? | 16:16.21 |
| ray_laptop | mvrhel_laptop: I'm not sure why you'd ever want CLIENT to be less, but it cannot exceed DEVICE or bad things happen | 16:16.57 |
| Robin_Watts | hmm. From looking at it yesterday, I decided it made sense to allow CLIENT_COLOR_MAX to be larger than DEVICE_COLOR_MAX | 16:17.04 |
| | but not the other way around. | 16:17.17 |
| mvrhel_laptop | ray_laptop: glancing over the code, that is what I thought | 16:17.34 |
| ray_laptop | Robin_Watts: but that breaks all of the SeparationOrder map handling | 16:17.34 |
| mvrhel_laptop | perhaps we should just merge them and get rid of the client..... | 16:17.53 |
| Robin_Watts | Consider the case where I have a cmyk printer (so I want device color max = 4), but I want to be able to handle PS files with many different spots in. | 16:18.06 |
| ray_laptop | mvrhel_laptop: it is used a lot less places, and it would prevent confusion, IMHO | 16:18.16 |
| Robin_Watts | (where those spots get mapped down to cmyk) | 16:18.16 |
| | AIUI, that requires device_color_max = 4, and client color max a larger number. | 16:18.39 |
| ray_laptop | Robin_Watts: a *device* can have less than GX_DEVICE_COLOR_MAX_COMPONENTS, that's fine | 16:18.48 |
| Robin_Watts | ray_laptop: Let me rephrase... | 16:19.10 |
| ray_laptop | the macro DEVICE_COLOR_MAX is limits in the code's ability to handle ANY device | 16:19.17 |
| Robin_Watts | AIUI, DEVICE_COLOR_MAX is tied tightly to the gx_color_index type. | 16:19.33 |
| ray_laptop | since that is what is used for arrays of component values | 16:19.40 |
| Robin_Watts | If I am running a cmyk printer, there is no benefit to me having a 64bit gx_color_index. | 16:20.03 |
| | and on some CPUs there is a big advantage to NOT using a 64bit type. | 16:20.20 |
| | So I use a 32bit int, have a DEVICE_COLOR_MAX of 4. | 16:20.41 |
| chrisl | ray_laptop: in an embedded printer, you might want to set GX_DEVICE_COLOR_MAX_COMPONENTS to just the number of components in the engine | 16:20.41 |
| ray_laptop | Robin_Watts: so if you want to have a 32-bit color index, you can still have 32 separations | 16:20.50 |
| Robin_Watts | BUT I want to have 64 separations. | 16:21.01 |
| | so I want to have client color max > device color max. | 16:21.16 |
| | and I can't immediately see why that should be a problem. | 16:21.25 |
| chrisl | Not 64 separations, a 64 component DeviceN color space..... | 16:22.20 |
| ray_laptop | Robin_Watts: I know it breaks (currently) gdevp14.c but we could (for the problem I found) change the problem elements in the structure to be uint64_t instead of COLOR_INDEX | 16:22.21 |
| | I don't know what else might break | 16:22.35 |
| Robin_Watts | hardwiring a 64bit type in is bad. | 16:23.03 |
| henrys | ray_laptop: we'd really like them to be independent, where is the code that breaks when client > device? | 16:23.33 |
| ray_laptop | Robin_Watts: the compressed color code is pretty bad, too, in that it is slow and can result in un-mappable colors | 16:23.48 |
| chrisl | Presumably there would be a performance and memory footprint benefit to to using a small value for DEVICE_COLOR_MAX | 16:24.04 |
| ray_laptop | henrys: line 6880 in gdevp14.c (and following) | 16:24.14 |
| Robin_Watts | having a new type that is set to "whatever is large enough to accomodate max(DEVICE_COLOR_MAX,CLIENT_COLOR_MAX)" would be the right solution, surely? | 16:24.34 |
| ray_laptop | chrisl: all of the arrays that pass around the colorant values use DEVICE_COLOR_MAX | 16:24.50 |
| | chrisl: and the separation map logic uses DEVICE_COLOR_MAX as it's *special* value. | 16:25.42 |
| chrisl | ray_laptop: Right, so there *is* an argument for a small DEVICE_COLOR_MAX value | 16:26.12 |
| ray_laptop | Robin_Watts: having a new macro which is the max of both and using that for arrays would prevent problems, but would still mean having large arrays | 16:26.26 |
| Robin_Watts | I have no problem with having large arrays. | 16:26.43 |
| | I object to being forced to have a large color_index just to accomodate the infrequent large numbers of seps. | 16:27.11 |
| chrisl | Except you use more memory...... | 16:27.12 |
| ray_laptop | Robin_Watts: many of them are stack based | 16:27.22 |
| Robin_Watts | (or the many component devn's) | 16:27.28 |
| | ray_laptop: Let's be clear... we're talking 32 or 64 copies of a few ints on the stack. | 16:27.55 |
| | not 32 or 64 copies of render buffers. | 16:28.05 |
| ray_laptop | Robin_Watts: a 32-bit color index is not large, IMHO and that still lets us have 32 separations | 16:28.10 |
| Robin_Watts | a 32bit color index is indeed not large. but I may not want to be limited to 32 seps. | 16:28.35 |
| kens | I htink one of our customers already wants more than that | 16:29.01 |
| chrisl | So turning the question around: is there ever any reason for DEVICE_COLOR_MAX to be less that CLIENT_COLOR_MAX? | 16:29.18 |
| ray_laptop | Robin_Watts: not all of the structures that have GX_DEVICE_COLOR_MAX_COMPONENTS are small | 16:29.25 |
| Robin_Watts | chrisl: That's what I've just been arguing for! | 16:29.44 |
| henrys | chrisl: what Robin_Watts said | 16:29.54 |
| ray_laptop | kens: if a customer wants more than 32, they can use a LARGE_COLOR_INDEX (the default, anyway) then they will get 64 | 16:30.21 |
| chrisl | Robin_Watts: But I haven't actually seen a *reason* | 16:30.33 |
| kens | but technically we could have more than 64 separations (daft I know,but its legal) | 16:31.07 |
| chrisl | If the choice is 32 or 64, the most we ever *really* need in the interpreter is 32..... | 16:31.25 |
| | According to the PDF spec implementation limits..... | 16:31.41 |
| kens | I'm not sure PS is so limited | 16:32.33 |
| chrisl | True, but when did you last see a 32+ component DeviceN space in a PS file? | 16:33.04 |
| Robin_Watts | chrisl: There are CPUs on which using a 64bit type for a color index results in unacceptable performance. | 16:33.06 |
| chrisl | Robin_Watts: yes, so use a 32 bit value | 16:33.20 |
| kens | chrisl just saying its techincally legal; | 16:33.32 |
| Robin_Watts | we have at least one customer who uses a 32bit value for this purpose. | 16:33.36 |
| chrisl | Robin_Watts: yes, so use a 32 bit value | 16:33.49 |
| | kens: strictly speaking, for PS, we shouldn't have *any* limit | 16:34.11 |
| Robin_Watts | I would think it was a shame for us to have to tell the customer that he is limited to only 32 components in PS. | 16:34.24 |
| | I accept that we are at liberty to do that (because the PS spec says the number of components supported is device dependent), but it's a shame. | 16:34.57 |
| chrisl | No, the PS spec does not specify any limit on the number of components | 16:35.22 |
| henrys | ray_laptop: know any customers that have pushed above 32? | 16:35.47 |
| Robin_Watts | chrisl: I believe it's mentioned as an implementation limit somewhere? | 16:35.47 |
| chrisl | Not that I could find.... but I may have missed it | 16:36.02 |
| Robin_Watts | I thought ken found a reference to that yesterday. Maybe that was for PDF. | 16:36.10 |
| ray_laptop | Robin_Watts: OK, I reviewed the code and there are no longer big structures that have GX_DEVICE_COLOR_MAX elements | 16:36.17 |
| henrys | can't imagine that would come up in practice, but ... | 16:36.20 |
| Robin_Watts | Hence it would (in my view) be worth at least exploring the possibility of keeping CLIENT_COLOR large while having device color small. | 16:36.39 |
| chrisl | PDF "implementation limits" DeviceN spaces to 32 components | 16:36.58 |
| ray_laptop | chrisl: Right. Adobe CPSI had 252 as a limit | 16:37.24 |
| chrisl | Okay, so even 64 is too low...... | 16:37.52 |
| Robin_Watts | photoshop copes with up to 56 separations, so possibly that's a good number to aim for? | 16:38.10 |
| chrisl | 56 would be no easier than 64...... | 16:38.30 |
| henrys | chrisl: yeah we played with pointers and structs - gxcindex.h - it really shouldn't be limited. | 16:38.32 |
| chrisl | henrys: you said before it was too slow | 16:38.56 |
| Robin_Watts | chrisl: Indeed. So 64 is 'enough' I reckon. | 16:39.16 |
| henrys | always wanted to profile where the issues are with large indices. I don't think we understand them completely. | 16:39.50 |
| chrisl | Robin_Watts: so there is the solid argument for CLIENT > DEVICE, which is what I asked | 16:40.10 |
| Robin_Watts | the problem is that we'd be profiling on PCs, right? Which do 64bit stuff fast. | 16:40.38 |
| ray_laptop | chrisl: I missed it. What is the solid arg for CLIENT > DEVICE ??? | 16:40.45 |
| Robin_Watts | We'd need to profile on mips or something. | 16:40.57 |
| | head. meet desk. | 16:41.03 |
| ray_laptop | Robin_Watts: unless we profile on a Raspberry or Beagle or something | 16:41.22 |
| chrisl | ray_laptop: we might want to keep DEVICE to 32 for performance reasons, but keep CLIENT at 64 for DeviceN support | 16:41.32 |
| kens | is heading off out | 16:41.47 |
| | goodnight all | 16:41.50 |
| Robin_Watts | ray_laptop: that would be ARM rather than MIPS, but yes, that should hopefully show similar issues. | 16:41.54 |
| ray_laptop | chrisl: OK, thanks. and that's IFF a customer NEEDS > 32 DeviceN for some reason, but is on a processor that causes a MAX of 64 to be slow | 16:43.45 |
| chrisl | ray_laptop: Postscript allows DeviceN with > 32 components | 16:44.08 |
| ray_laptop | and we don't even know that 32 vs 64 bit color_index is that much slower. | 16:44.32 |
| | chrisl: PS has implementation limits. For years gs limit was 14, | 16:45.10 |
| henrys | Robin_Watts, Robin_Watts I would think using TEST_CINDEX_STRUCT would show the differences on any platform unless the compiler optimizes away the offset calculation | 16:45.13 |
| ray_laptop | and Adobe's varied according to the product | 16:45.29 |
| chrisl | ray_laptop: well, we always try to match CPSI for Postscript, so....... | 16:45.53 |
| henrys | or TEST_CINDEX_POINTER - but I I'd hate to try and get that working | 16:47.06 |
| chrisl | ray_laptop: as far as I could see, there was no documented limit on the components in a DeviceN space in the PLRM | 16:47.25 |
| Robin_Watts | henrys: I've not tried compiling with either of those enabled. | 16:48.25 |
| chrisl | Well, actually, the names in a DeviceN space are in an array, so at least that's one limit - the maximum size of an array...... | 16:49.49 |
| Robin_Watts | henrys: IF we just want to establish whether 64bit color indexes hurt more than 32bit, we can compile with/without GX_LARGE_COLOR_INDEX (or whatever it is) and do timings. | 16:51.28 |
| | Presumably the customer has already tried this and has settled on large_color_index=0 | 16:52.02 |
| chrisl | That's nothing to do with performance, though | 16:52.18 |
| henrys | Robin_Watts: I thought that was well established, we want to profile and "fix" areas that slow down. | 16:52.29 |
| Robin_Watts | I'm not sure this is something we can "fix" :) | 16:52.45 |
| | If you're on a CPU that's incapable of dealing efficiently with 64bit ints, then using 64bit ints will not be efficient. | 16:53.14 |
| ray_laptop | chrisl: reading the PLRM, it looks like the allowable values for MaxSeparations are 1 to 250, which implies that DeviceN has a max of the Process Color count + the MaxSeparations, so 254 is a limit | 16:53.15 |
| henrys | Robin_Watts: adobe does not seem to have a problem ;-) | 16:54.05 |
| chrisl | ray_laptop: that's a device parameter, though, so the equivalent of GX_DEVICE_COLOR_MAX | 16:54.17 |
| henrys | I suspect we might use the index more than absolutely necessary | 16:54.28 |
| chrisl | Mind you, I find the customer's argument rather amusing: "we're re-implementing transparency blending" but "64 bit colour indices is difficult"??? | 16:55.07 |
| ray_laptop | chrisl: table B1 has 250 also defined as Adobe's Implementation limit for number of separations, colorants, or color components in DeviceN color space | 16:57.21 |
| | chrisl: yeah, this customer is rather a pain (and has been for years). It is also amusing that they say "this has worked for us for 10 years", when they only recently signed on as a customer | 16:58.29 |
| chrisl | ray_laptop: aha! I missed it because it's called "separations" - bad naming.... again! | 16:58.46 |
| | Still, 250 is more than we currently support, so...... | 16:59.23 |
| ray_laptop | chrisl: np | 16:59.24 |
| chrisl | ray_laptop: TBH, Postscript was never my worry on this - I think the largest DeviceN space I've seen in Postscript is ~16 components. But since NChannel came into PDF, I've seen quite a few *large* DeviceN spaces in PDFs - ones I thought Acrobat shouldn't handle, even! | 17:01.48 |
| ray_laptop | chrisl: some of our users, Gigs in particular, have exceeded 16 -- I think he sent us a "real world" one with 24 | 17:13.17 |
| chrisl | ray_laptop: the largest I've seen is 38 components - 4 process and 34 spot plates. Acrobat *should* reject it, but appeared not to..... | 17:14.21 |
| | that was PDF, of course | 17:15.17 |
| | ray_laptop: someone mentioned earlier: it might be good to have (at least) another channel operator/admin #ghostscript over here in the European time zone(s) | 17:39.06 |
| ray_laptop | chrisl: I thought you or kens were, but no problem. Who wants it, you, Robin_Watts, other ? | 17:42.31 |
| Robin_Watts | all 3? can't hurt. | 17:43.23 |
| chrisl | I'm happy to take it on, or both Robin and I - that will give pretty good time coverage | 17:43.38 |
| ray_laptop | Robin_Watts: who's the third one? kens ? | 17:44.37 |
| | now to remember how to add ops ... | 17:45.02 |
| chrisl | Yeh, might as well have kens, too | 17:45.55 |
| tkamppeter | chrisl, kens, I have committed a new patch now, with conditional compiling so that the fix only gets applied if a shared CUPS library is used, but note that for GS producing correct PWG Raster in all configurations the built-in libcups and libcupsimage libraries need to get updated. | 17:59.44 |
| chrisl | tkamppeter: that's super thanks. I will try try to get cups updated in the not too distant future. TBH, I think anyone using CUPS "for real" (rather than just for debugging) should be using the system library, though | 18:01.21 |
| Robin_Watts | tkamppeter: Are you set up to use our cluster? | 18:01.39 |
| tkamppeter | Robin_Watts, I think so, but if I have used it once then years ago. It would be great to have some docs on your site on how to use it. | 18:02.45 |
| Robin_Watts | tkamppeter: OK, probably we ought to make sure you're set up for that. | 18:03.08 |
| | We like to have had all commits run through the cluster to check they don't break stuff before we commit. | 18:03.38 |
| | henrys: till has a log in on casper - presumably he should have access to the cluster etc? | 18:04.37 |
| henrys | Robin_Watts: I would think, he should probably send in an NDA if he is going to look at cluster test files. | 18:05.27 |
| chrisl | Robin_Watts: he's listed in the cluster users on the dashboard | 18:05.44 |
| Robin_Watts | henrys: OK. So either we need to get that sorted, or tkamppeter should ask one of us to cluster test his patches before he pushes ? | 18:06.16 |
| | chrisl: I am going blind. I checked that list a moment ago... | 18:06.52 |
| chrisl | It's the one that says "till" ;-) | 18:07.30 |
| Robin_Watts | yeah, yeah, yeah. | 18:07.44 |
| henrys | I guess he is "grandfathered" in | 18:08.13 |
| | tkamppeter: you haven't signed our nda have you? | 18:08.25 |
| chrisl | Robin_Watts: he probably will need a new password, though | 18:09.18 |
| rayjj | chrisl: you already had op privs on #ghostscript. | 18:10.14 |
| chrisl | rayjj: really?? I wonder when that happened..... | 18:10.32 |
| rayjj | chrisl: try /msg chanserv op #ghostscript chrisl | 18:11.32 |
| chrisl | Cor, the POWER! | 18:11.57 |
| rayjj | that _should_ let you turn on 'op' | 18:11.59 |
| | Robin_Watts: you and kens can do that too now. | 18:12.14 |
| Robin_Watts | rayjj: I haven't see me being made an operator. | 18:13.31 |
| rayjj | We don't set +O (auto-op) per http://freenode.net/using_the_network.shtml We strongly suggest that you avoid configuring your channel to "auto-op". Use the chanserv "op" command to obtain channel operator status only when needed. | 18:13.59 |
| | Robin_Watts: what did chanserv tell you ? | 18:14.31 |
| Robin_Watts | IF I do: /op Robin_Watts results in "You need to be an operator in #ghostscript. to do that." | 18:14.44 |
| rayjj | Robin_Watts: no, you need to do the /msg chanserv op #ghostscript Robin_Watts | 18:15.12 |
| | Robin_Watts: you ask chanserv to make you an operator | 18:15.49 |
| Robin_Watts | "You are not authorized to perform this operation." | 18:15.53 |
| rayjj | Robin_Watts: hmm... I see Flags +o were set on Robin_Watts in #ghostscript. | 18:16.20 |
| Robin_Watts | still no dice. | 18:17.20 |
| rayjj | Robin_Watts: OK, now try the chanserv and see | 18:17.27 |
| Robin_Watts | still no dice. | 18:17.32 |
| chrisl | So I could have zapped that guy earlier all along - drat it! | 18:20.33 |
| tkamppeter | henrys, I do not know. What I have signed for sure is a copyright agreement. | 18:23.24 |
| henrys | tkamppeter: should be fine | 18:23.47 |
| Robin_Watts | Aha. I hadn't logged on :) | 18:23.54 |
| tkamppeter | henrys, but if I had ever used the cluster before, I have probably also signed something NDA or alike to not publish any private user data or so, | 18:24.28 |
| henrys | tkamppeter: I"m sure you're good, destroy our test files when you are finished with them. | 18:25.05 |
| tkamppeter | henrys, OK. | 18:25.32 |
| chrisl | Well, now that I (realise that I) have the power of the IRC gods available to me, I'm going to finish for the day. I have an amazingly sore shoulder, and *really* hope a hot bath will ease it....... | 18:27.09 |
| rayjj | Robin_Watts: I had made you op -- see if chanserv will make you op | 18:27.12 |
| | Oh, it did | 18:27.21 |
| Robin_Watts | I just did that test :) | 18:27.32 |
| rayjj | Robin_Watts: you have to be identified by Nickserv first, as you learned | 18:27.47 |
| | Robin_Watts: chrisl_away: I recommend turning off your op mode unless you need it | 18:28.41 |
| | Robin_Watts: as you just did :-) | 18:28.56 |
| | I type too slowly | 18:29.02 |
| chrisl_away | Okay, how does one do that? | 18:29.07 |
| rayjj | /mode #ghostscript -o chrisl_away | 18:29.32 |
| Robin_Watts | or "/msg chanserv deop #ghostscript chrisl_away" | 18:29.47 |
| chrisl_away | Thanks | 18:29.56 |
| rayjj | or /deop chrisl_away | 18:30.05 |
| | once you are op, you can deop someone | 18:30.23 |
| chrisl_away | TBH, I thought it would drop it when I changed my nick | 18:30.49 |
| | especially since chrisl_away isn't registered..... | 18:31.03 |
| rayjj | BTW, I think henrys has the +o flag set for #ghostscript with chanserv as well | 18:31.16 |
| Robin_Watts | rayjj: Possibly you should give henrys the +f flag too. | 18:37.15 |
| | cos if you go down with another bout of dengue, we're screwed :) | 18:37.25 |
| henrys | the +f flag doesn't sound nice ;-) | 18:38.00 |
| rayjj | how about setting all of you with the same flags as I have: +ARVfiorstv | 18:38.45 |
| Robin_Watts | +f = founder. You have to be a founder to make operators. | 18:38.51 |
| | rayjj: If you want. | 18:38.58 |
| rayjj | Robin_Watts: +F is founder (not +f as far as I know) | 18:39.12 |
| | henrys: can you register so I can see what flags you have ? | 18:39.34 |
| henrys | rayjj: one minute phone | 18:39.55 |
| rayjj | henrys: no rush | 18:40.01 |
| Robin_Watts | Oh, so we have no founder? | 18:40.14 |
| henrys | uh rayjj's friend is knocking | 18:41.21 |
| | rayjj: are you doing "/msg nicserv â¦" command? | 18:43.07 |
| rayjj | henrys: it's nickserv | 18:47.43 |
| | Robin_Watts: the founder of the channel is Ralph Giles (rillian) | 18:50.49 |
| | Robin_Watts: AFAIK, he's the only one that can give someone the +F | 18:51.25 |
| henrys | rayjj: I copy pasted what they into IRC to "VERIFY" and got invalid command | 18:51.57 |
| | ] | 18:51.57 |
| | wtf | 18:52.00 |
| rayjj | henrys: you need /msg nickserv identify ___ (where ___ is your password) | 18:52.31 |
| henrys | rayjj: I did that and it worked and they sent me an email with a command to verify (/msg NickServ VERIFY REGISTER henrys PASSWORD DELETED) which I pasted from email to IRC and it fails | 18:53.38 |
| | the syntax is right I wonder if my client is honking up the command somehow. | 19:00.35 |
| Robin_Watts | henrys: Try the webclient? | 19:01.21 |
| rayjj | henrys: try it from webchat :-) | 19:01.21 |
| | henrys: it might be messing up your key | 19:01.52 |
| henrys | okay I'm going to sign out here and try another client | 19:02.18 |
| rayjj | darn, I didn't ban henrys before he got back in ;-) | 19:03.51 |
| | henrys: OK, you should be able to /msg chanserv op #ghostscript henrys | 19:08.02 |
| henrys | yeah it all works on webchat | 19:09.48 |
| | rayjj: done | 19:10.18 |
| rayjj | henrys: OK. You are now superhenrys :-) | 19:10.29 |
| henrys | lucky me | 19:10.56 |
| rayjj | now you should be able to do: /deop henrys | 19:11.19 |
| | so now we have me, chrisl, Robin_Watts, kens and henrys all with chanserv op privelege | 19:16.11 |
| | so one of will probably remember that we have to ask chanserv for op, and not just do the /op directly (since I do op stuff so infrequently, I have to dig in the little gray cells) | 19:18.35 |
| | oh, and rillian, of course has priveleges | 19:19.01 |
| | mvrhel_laptop: I'm getting mupdf DLL not found with gsview | 19:49.04 |
| mvrhel_laptop | rayjj: weird did you get the new isntaller? | 19:49.24 |
| rayjj | mvrhel_laptop: I thought so. I'll uninstall and try again | 19:49.44 |
| mvrhel_laptop | I actually have a bunch of updates. I need to push a new version | 19:49.45 |
| rayjj | oh, Ok. I'll wait to I see mention here or in email | 19:50.10 |
| mvrhel_laptop | chris had given me a bunch of feedback | 19:50.11 |
| | rayjj: that may make more sense | 19:50.26 |
| | I want to get one more thing fixed then I will create a new installer | 19:50.51 |
| | I will send out an email | 19:50.54 |
| | off to lunch now | 19:52.03 |
| rayjj | didn't we release 1.4 mupdf ? | 19:52.10 |
| | I don't see it in the downloads | 19:52.22 |
| mvrhel_laptop | I think so | 19:52.30 |
| rayjj | for Windows. 1.3 is flagged "Deprecated" | 19:52.54 |
| | there isn't even source there :-( | 19:56.16 |
| | well, fts_25_2524 is definitely wrong with gs (and correct with mupdf). It seems that when we have an SMask and paint text, we don't ever push a transparency group, so the SMask is never applied to the text | 22:21.22 |
| | surprising that never got noticed | 22:21.49 |
| | Forward 1 day (to 2014/05/16)>>> | |
IRC Logs
