| | <<<Back 1 day (to 2014/02/25) | 2014/02/26 |
| ray_laptop | a big gaping hole in the transparency code :-( When a tranparent pattern is used as the color for a stencil mask (mask image) and the device is a clist, it is confused (confusing). Why didn't this show up before ? | 02:34.48 |
| | it ends up trying to paint from the ptile->tbits and changing it to paint from the ttrans buffer is also not supported. | 02:36.50 |
| marcosw | ray_laptop: can you try a 'ping ghostscript.com'? the domain doesn't resolve for me. | 03:21.50 |
| | marcosw: don't bother, nothing is resolving, must be a problem with my router | 03:23.59 |
| mvrhel_laptop | psdrgb device is more broke than bug 693070 suggests | 03:25.30 |
| | marcosw: does tiger even work for the device for you? | 03:25.40 |
| | I am not sure I am going to be able to get this device fixed before the release with everything else that is on the burner | 03:26.07 |
| | but I will try | 03:26.10 |
| | You did put it down as a blocker | 03:26.31 |
| marcosw | mvrhel_laptop: nope, tiger doesn't work, generates a black file. | 03:26.50 |
| mvrhel_laptop | ok. same for me | 03:27.01 |
| | I thought tiger worked at one time | 03:27.07 |
| | marcosw: do you know what broke that? | 03:27.17 |
| marcosw | it's probably slightly less than a blocker, but if you can't fix it we should probably disable the device. | 03:27.28 |
| | mvrhel_laptop: no I don't but a bisect should be easy, I'll do that and update the bug. | 03:27.47 |
| | btw, how's the trip going? | 03:27.53 |
| mvrhel_laptop | thanks | 03:27.53 |
| | it is going good. lots of train traveling | 03:28.03 |
| | 10 trains yesterday and 3 meetings | 03:28.09 |
| | 8 hours of trains the day before that | 03:28.19 |
| marcosw | ouch, haven't they heard of airplanes? | 03:28.41 |
| mvrhel_laptop | today is a light day with 2 meetings and about 4 hours of train | 03:28.42 |
| | smart office is generating a lot of interest. | 03:29.28 |
| | got to go | 03:30.00 |
| | getting off train | 03:30.03 |
| marcosw | okay have a good day. | 03:30.07 |
| kens | Hi Michael | 08:42.24 |
| mvrhel_laptop | Hi kens | 08:42.51 |
| kens | In a htoel ? | 08:42.57 |
| mvrhel_laptop | no on train | 08:43.04 |
| kens | Or even hotel... | 08:43.04 |
| | Ah, travelling again :( | 08:43.13 |
| mvrhel_laptop | heading back to hotel. about 1 hour 20 minutes and 2 trains | 08:43.26 |
| kens | Oh well, hope your evening is OK | 08:43.38 |
| | When do you fly back ? | 08:43.45 |
| mvrhel_laptop | thanks. have a good morning. We have 2 more days, flying back on Friday | 08:44.03 |
| kens | Oh so not long back home before you have to depart for Texas... | 08:44.19 |
| mvrhel_laptop | yes. | 08:50.23 |
| kens | Hmm, seems I don't have a current MuPDF checkout. I@ll get one later when I get back. Heading out for a couple of hours now. | 10:11.21 |
| Robin_Watts | paulgardiner: Morning | 10:30.27 |
| paulgardiner | hi | 10:30.33 |
| Robin_Watts | For some reason, my latest commit seems to be interacting badly with your stick note annotations. | 10:31.24 |
| | The pdf_process one. | 10:31.31 |
| | Is ghostscript.com down? | 10:31.37 |
| paulgardiner | ghostscript.com works for me okay | 10:32.32 |
| | What's the bad interaction? | 10:32.48 |
| Robin_Watts | One file is showing a speech bubble that it wasn't before. | 10:34.12 |
| paulgardiner | That might be a positive change. | 10:34.52 |
| Robin_Watts | no, it's not. | 10:34.59 |
| | something is very ill with my machine. | 10:35.13 |
| paulgardiner | It's not about an inch in from the top right corner? | 10:35.33 |
| | Wondering if I accidently committed the test code. | 10:35.47 |
| | Nothing in the cluster tests would add an annotation AFAIK, so it would have to be an appearance stream being symthesised for an existing one | 10:37.13 |
| | No sign I committed the test code | 10:39.16 |
| Robin_Watts | paulgardiner: Sorry, my PC was messing around. I wonder if someone had managed to get in using the chrome remote desktop thing :( | 11:05.49 |
| | If you look at my bmpcmp, you'll see the file in question. | 11:06.11 |
| | Any ideas how that might be happening? | 11:06.18 |
| | paulgardiner: The file in question is tests_private/pdf/PDF_1.7_FTS/fts_19_1908a.pdf | 11:33.50 |
| | No flags in the annotation. | 11:48.19 |
| | Morning tor8. | 11:48.29 |
| tor8 | hi Robin_Watts | 11:49.31 |
| Robin_Watts | oh, I might see what it is... | 11:51.55 |
| | It might be.. it might be... yes. It's because I'm a moron. | 11:52.38 |
| | tor8, paulgardiner: So, new version of the patch online. I think I'm broadly happy with it. | 12:11.20 |
| | If you can see a nice way to simplify the need for process_annot/process_stream/process_contents, then I'd be interested. | 12:11.44 |
| paulgardiner | Not quite what I was expecting but maybe what I was expecting can't be done. | 12:20.39 |
| | There is only one instance of run_annot and run_contents and you get differing behaviours by passing different types of device. | 12:21.37 |
| | I was expecting just a single process_annot and process_contents pair of functions (not virtual) to which you could pass a pdf_op_interpreter, and one type of pdf_op_interpreter being one that drives a device | 12:23.15 |
| tor8 | paulgardiner: Robin_Watts: the complication is that a Do command may invoke an XObject, and that may need to have customized behaviour, is that an accurate summary of the problems? | 13:08.26 |
| paulgardiner | tor8: I guess so. Recursive calls are a part of it, and presumably the case you mention is what leads to the recursion | 13:18.48 |
| Robin_Watts | xobjects can invoke xobjects, yes. | 13:42.04 |
| | and I need to do different things before and after the call to the stream interpretation in the different pdf_processors | 13:42.42 |
| paulgardiner | Yeah, I see why we need the three virtual functions now. Would have been nice if there was a way to have jsut process_stream virtual, but I can't see a trick to do it. | 13:49.49 |
| Robin_Watts | https://www.gnu.org/graphics/package-logos.html <- Posted on HackerNews as "The Worlds Worst Logos" | 13:51.25 |
| | and GNU Ghostscripts logo is just dreadful. | 13:51.35 |
| kens | Umm yes, that's not good | 13:52.32 |
| Robin_Watts | tor8: Can you see anything you'd like change before we think about committing it? | 13:54.30 |
| | sebras objected to the 'trick' of me using PDF_OP_Max to indicate "close this process down". | 13:54.56 |
| | but I quite like it. | 13:55.16 |
| | He also suggested I could split the buffer and filter ones out into different commits, which I am not averse to, but don't want to do unless other people agree. | 13:55.56 |
| | http://t.co/UlYSmsle3u Free e-book with promo code DOTDEBOOKFREE. | 14:13.05 |
| tor8 | I'd prefer PDF_OP_EOF | 14:25.09 |
| Robin_Watts | tor8: Sure. | 14:29.12 |
| | EOF? or EOS? | 14:29.17 |
| | or EOP ? :) | 14:29.27 |
| | I'm gonna grab some lunch. will put that through as soon as I get back (plus anything else you spot in the meantime) | 14:30.02 |
| sebras | tor8: Robin_Watts: why is this better than having a function pointer that is separate from the operators? | 14:30.27 |
| Robin_Watts | The function pointer would have to have exactly the same type. | 14:30.51 |
| | hence it seems more natural to leave it where it is, IMHO. | 14:31.08 |
| sebras | Robin_Watts: the same as the ops? I see. then I agree with mr Andersson. | 14:31.57 |
| tor8 | Robin_Watts: or just PDF_OP_END | 14:35.14 |
| | Robin_Watts: use fz_strlcpy rather than strcpy | 14:35.55 |
| sebras | tor8: I never looked very thoughly at the code as such, becuase I expected there to be discussion about the entire approach? but maybe it is uncontroversial? | 14:36.50 |
| tor8 | sebras: robin and I have talked it over a fair amount | 14:37.10 |
| | the only controversial bits are how to hook it up to the pdf_run_xxx mess | 14:37.31 |
| sebras | tor8: right, I was unaware of that. | 14:37.32 |
| tor8 | sebras: robin wrote some code that had this approach of passing all ops through a function pointer table, but never used for anything but the "run" processor a while back | 14:38.19 |
| | but then I rewrote the inner loop of the interpreter altogether and we lost it | 14:38.30 |
| | sebras: okay, so the latest libjs regex.c code uses an explicit backtracking stack rather than recursion, so we don't crash on stack overflow | 14:39.25 |
| | I haven't figured out how to nicely trap the infinite loops, so I detect them at compile time and throw a syntax error instead. should be good enough for our use, I hope :) | 14:39.54 |
| | and it should be possible, with some care, to make a completely stackless variant if we don't have any I_REF instructions | 14:40.38 |
| | I mean backtracking-less | 14:40.56 |
| sebras | tor8: sounds good. I'll take a look at it later tonight. | 14:41.14 |
| Robin_Watts | tor8, sebras, paulgardiner: New version pushed with END and fz_strlcpy | 15:32.34 |
| | And a newer version, where I've pulled the pdf_run_xxx functions out into pdf-run.c | 16:09.16 |
| sebras | Robin_Watts: will look later tonight. | 17:23.41 |
| Robin_Watts | sebras: Thanks. | 17:23.52 |
| | I'm coming around to the idea of splitting the commit into run and others. | 17:24.07 |
| | cos I'm still tweaking the others. | 17:24.12 |
| sebras | Robin_Watts: I thought so. :) | 19:29.05 |
| Robin_Watts | sebras: I'm currently testing a version where I filter the streams before running them. | 19:37.12 |
| | but the cluster is crashing on it, whereas I'm running just fine. | 19:38.16 |
| | even on the cluster machines, I can't get my binary to give the same problems. | 19:39.13 |
| ray_laptop | can someone approve the tiny patch on my repo? It's a temporary fix to get the correct output when -dGrayValues > 1, until I get the gxht_thresh.c code enhanced (Bug 695073) | 19:54.10 |
| Robin_Watts | evening mvrhel_laptop | 20:08.33 |
| mvrhel_laptop | good morning Robin Watts | 20:08.47 |
| Robin_Watts | It must be *very* early morning there? | 20:09.26 |
| mvrhel_laptop | It is about 5am. | 20:11.43 |
| | but I have been going to bed pretty early | 20:12.08 |
| ray_laptop | mvrhel_laptop: I have a headache from looking at the gxht_thresh code. trying to upgrade it to depth > 1 bit | 20:28.44 |
| | mvrhel_laptop: and another headache from having looked at the pdf14 pattern handling code when there is a clist on the back end of a pattern | 20:29.41 |
| | mvrhel_laptop: you can be glad you're over there so I am not bothering you with this ;-) | 20:30.19 |
| mvrhel_laptop | ray_laptop: sounds like a good time for me to be gone ;) | 20:30.30 |
| | the bit depth stuff should not be too bad though | 20:30.46 |
| | it is going to require some sse2 fixes I would think | 20:31.02 |
| | but it has been a while since I had looked at that ray_laptop | 20:31.18 |
| | so I might be all wrong | 20:31.27 |
| ray_laptop | mvrhel_laptop: yes, sse changes as well as the C code | 20:31.39 |
| | mvrhel_laptop: I'll start with the C code, of course | 20:31.57 |
| mvrhel_laptop | ray_laptop: can we not just use the legacy code when depth is > 1 bit? | 20:32.18 |
| ray_laptop | all of the allowances for SSE alignment issues are causing head pounding | 20:32.39 |
| mvrhel_laptop | or do you feel like this work is really needed? | 20:32.43 |
| ray_laptop | mvrhel_laptop: I have a patch waiting for review on my repo to use the legacy (non optimized) code | 20:33.15 |
| mvrhel_laptop | ok. that is what I would do and move on. this may be more work that it is worth right now | 20:33.43 |
| | ray_laptop: oh I see who this is for | 20:34.20 |
| ray_laptop | mvrhel_laptop: if it works out to not be too bad, we have a potential printer customer about to start performance benchmarks | 20:34.24 |
| mvrhel_laptop | yes | 20:34.30 |
| | it would be nice to have it working | 20:34.38 |
| ray_laptop | mvrhel_laptop: but I have no idea how important they are | 20:34.41 |
| mvrhel_laptop | ray_laptop: quite important I think. we did not go there this trip, as they were to busy to see us, but we had a very good meeting there the last time | 20:35.27 |
| ray_laptop | mvrhel_laptop: maybe you can see from our Marketing department about their importance (while you are on the train with them) | 20:35.50 |
| mvrhel_laptop | the fact that they are doing an evaluation is great. getting them a fix quickly would be great. even if it is to hook in the legacy code | 20:36.07 |
| ray_laptop | mvrhel_laptop: thanks -- I typed too slowly | 20:36.12 |
| | mvrhel_laptop: I already sent them the patch today for using the non-optimized code to get the output correct | 20:36.41 |
| mvrhel_laptop | that is great. thanks ray_laptop | 20:36.54 |
| ray_laptop | mvrhel_laptop: and attached sample output with default halftoning and stochastic halftoning | 20:37.10 |
| mvrhel_laptop | yes, I see that email, but not the one with the patch | 20:37.35 |
| ray_laptop | mvrhel_laptop: can you approve my patch so I can commit it ?http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=30f2c656469f5930b1adc82454706743df68b0d7 | 20:38.00 |
| Robin_Watts | realises that he's had his email turned off all day, cos he rebooted the machine. No wonder it's been quiet. | 20:38.10 |
| mvrhel_laptop | the default one looks much better than the stochastic one. | 20:38.17 |
| | but it depends upon the device | 20:38.28 |
| ray_laptop | mvrhel_laptop: The patch was not an attachment -- it followed my signature as text | 20:38.56 |
| mvrhel_laptop | oh sorry. yes. patch looks good | 20:39.41 |
| ray_laptop | mvrhel_laptop: thanks. | 20:41.28 |
| | I'm not sure why there is so much 'flattening' of teh gray levels with the stocht.ps | 20:41.56 |
| | OK, patch pushed to origin so at least the 'legacy' approach (non-optimized) works | 20:44.55 |
| mvrhel_laptop | that was weird | 20:45.15 |
| | ray_laptop: as I was going to ask you one thing about the patch I was disconnected | 20:45.46 |
| | I wanted to ask about checking the bit depth when the is_planar_dev is true | 20:46.20 |
| | if someone is doing 4 color 4 bit/color case, we will have the same issue | 20:46.48 |
| ray_laptop | mvrhel_laptop: sorry. True I guess it assumes that is_planar is OK. Probably should have been || is_planar_dev && (penum->dev->color_info.depth / penum->dev->color_info.num_components == 1) | 21:01.09 |
| mvrhel_laptop | ray_laptop: yes | 21:01.29 |
| | heading out for breakfast. bbiaw | 21:01.49 |
| ray_laptop | mvrhel_laptop: OK. Thanks | 21:02.01 |
| madmoose | d'oh... how come I'm just now realizing that Robin_Watts is the same Robin_Watts as in #scummvm? | 21:15.15 |
| MacWinner | why is mudpf so much faster/bettering rendering PDF into PNGs than gs? | 22:32.26 |
| | i by accident stumbled upon mupdf.. Surprised I didn't find it earlier since i was searching a lot for a good rendering solution | 22:32.54 |
| | my current gs implementation can take 30 seconds to render a PDF to PNG.. Mudraw only takes like 4 seconds | 22:33.25 |
| | i compared teh quality and it even looks like mudraw is slightly better | 22:33.48 |
| Robin_Watts | MacWinner: Depends on your desired target. | 23:57.39 |
| | For screen use, MuPDF wins hands down. | 23:57.46 |
| | Forward 1 day (to 2014/02/27)>>> | |
IRC Logs