| | <<<Back 1 day (to 2013/01/15) | 2013/01/16 |
| mvrhel_laptop | JamesMT most of the MuPDF guys are on European time so best to try during those hours | 00:20.40 |
| Robin_Watts | You specifically need tor8, I think. | 00:21.01 |
| mvrhel_laptop | except Robin_Watts, who is her 24 hours a day... | 00:21.21 |
| | s/her/here/ | 00:21.26 |
| | I can't quite figure out what is going wrong with my stream reading | 00:21.55 |
| | I have a file that gets read in completely into the buffer | 00:22.02 |
| | I suspect that mupdf is wanting to reread again | 00:22.27 |
| | and my reader is handing it the next set of bytes when requested | 00:22.47 |
| | things start out ok, but fall apart during the reading of the xref stuff | 00:23.18 |
| Robin_Watts | Well, there will be seeking done etc. | 00:23.46 |
| | If it was me, I'd get your stream stuff to output to a log file. | 00:24.08 |
| | saying things like: seek to %d | 00:24.26 |
| | read %d bytes: '......', %d bytes read | 00:24.42 |
| | etc | 00:24.44 |
| | Then we could look to see what stream requests are being made, and when they go wrong. | 00:25.10 |
| mvrhel_laptop | that is a good idea. I think to get seeking working correctly, I need to rework a couple things | 00:25.30 |
| | the c++ managed stream stuff here is poorly documented and overly complicated with too many variants, names and classes | 00:26.17 |
| Robin_Watts | yeah, I'm sure it all makes perfect sense when you see an example laid out in front of you that does exactly what you want, but without that it's like having a jigsaw puzzle. | 00:28.00 |
| JamesMT | Thanks mvrhel_laptop and Robin_Watts. Ill likely give back a try tomorrow as my day is winding down as well. | 00:29.20 |
| Robin_Watts | JamesMT: Night. | 00:29.35 |
| | Crumbs. Chrome just died on me. | 00:30.10 |
| mvrhel_laptop | Robin_Watts: exactly. | 00:36.18 |
| | bbiab | 00:36.18 |
| | made some good progress on my file i/o stuff. good night all | 07:11.24 |
| sebras | alexcher: re: 693 | 10:02.47 |
| | alexcher: re: 693513 -- if I look around a bit I can probably provide you with the original file in case you need it. | 10:03.13 |
| chrisl | Robin_Watts: I'm back...... | 12:08.52 |
| Robin_Watts | Me too | 12:52.08 |
| | I just downloaded a new copy of the simulator. | 12:52.15 |
| | In the previous version I had, there was a solution file to build it. But there isn't one in this one. | 12:52.40 |
| | Should there be, do you know? | 12:52.45 |
| chrisl | Not that I know of. You use a file called "setsim.bat" to start VS appropriately | 12:54.48 |
| | So, that is in ren_rip/SIM/BAT and takes the product name as a parameter - "6thgen" for your purpose, I think | 12:56.33 |
| Robin_Watts | It said "Starting 6thgen printer..." | 13:08.09 |
| | then "6thgen" | 13:08.14 |
| | then nothing happened. | 13:08.19 |
| chrisl | Okay, in that case, you may well need to edit the batch file so it selects the correct VS version, and has the correct path in it | 13:09.11 |
| Robin_Watts | ok, now it starts MSVC, which then gives lots of errors. | 13:12.07 |
| chrisl | I'm just decompressing a vanilla copy of the last sim I got, so I can diff the original setsim with mine | 13:12.55 |
| Robin_Watts | Project file 'd:\cvs\artifex\6g_2012_SIM\2lv_ctl\projectroot\element\ren\ren_rip\SIM\SYSSIM\%SIMROOT%\SIM\SYSSIM\IMG\IPF\ipf.vcproj' could not be loaded. | 13:13.14 |
| | I'm guessing %SIMROOT% is supposed to be set to something useful. | 13:13.27 |
| chrisl | Is there a file called "lastrun.bat" in there? | 13:13.49 |
| Robin_Watts | yes. | 13:14.05 |
| | At least there was until I just deleted it. Gah. Let me unpack that again. | 13:14.37 |
| chrisl | No, that's fine, we don't want it there | 13:14.54 |
| Robin_Watts | ok. | 13:15.04 |
| chrisl | IIRC, it holds the settings from the last call to setsim.bat, which in a new download won't be right for your machine | 13:15.38 |
| | Robin_Watts: it looks to me like it should work, if it's reaching the point of loading VS - which VS version are you using? | 13:19.54 |
| Robin_Watts | I think the problem is that when it starts VS, it has to go through the "can I run this as an administrator?" prompt, and that's causing it to lose all the environment variables. | 13:20.42 |
| chrisl | Mine does that, too | 13:20.58 |
| Robin_Watts | Trying with VS2008 instead of 2005 | 13:21.47 |
| | ok, that built. | 13:22.02 |
| | Now do I just build the solution ? | 13:22.09 |
| chrisl | Yeh, I'd "clean" it forst | 13:22.30 |
| Robin_Watts | s/that built/that loaded/ | 13:22.32 |
| | ok, let's let that run then. Thanks! | 13:23.12 |
| chrisl | It takes quite a while! | 13:23.22 |
| | Robin_Watts: do you have the details about running the exe? | 13:23.42 |
| Robin_Watts | chrisl: not easily to hand, no. | 13:43.04 |
| chrisl | Robin_Watts: Ray sent an e-mail about it long time ago - I'll see if I can dig it out | 13:44.43 |
| | Robin_Watts: I've got a mail from Ray with the details - do you want me to forward it to you? | 13:49.09 |
| Robin_Watts | please. | 13:52.52 |
| chrisl | Robin_Watts: it's way. | 13:54.02 |
| | or "on it's way", even! | 13:54.11 |
| tor8 | chrisl: surely you mean "on its way" ;) | 14:04.53 |
| chrisl | tor8: yes, I do - I hang my head in shame at my appalling grammar! | 14:05.42 |
| tor8 | paulgardiner: going through the list of implicit float -> int conversions (while changing the fz_bbox/fz_rect stuff) I found one of yours in the forms, da_info->font_size is an integer. any specific reason it isn't a float instead? | 14:16.24 |
| paulgardiner | tor8: Pretty sure no, but just looking. | 14:17.41 |
| tor8 | turning on -Wconversion with gcc is a pretty scary sight | 14:18.22 |
| paulgardiner | I can imagine | 14:18.38 |
| tor8 | but at least all the thirdparty libraries are just as bad! :) | 14:18.52 |
| | maybe one day robin can convince me to go on a typesafety nazi crusade, and add const and explicit type casts everywhere! | 14:19.26 |
| Robin_Watts | I think we want just enough consts. | 14:20.13 |
| paulgardiner | I seem to remember, at the time of writing that code, I was unsure whether a decimal was allowed for the size in Tf. | 14:20.21 |
| Robin_Watts | and casts only where it helps readability/correctness. | 14:20.36 |
| tor8 | 2045 warnings in our code with -Wconversion | 14:21.19 |
| | I do think const is a good idea. too bad the C implementation of the idea is a bit shoddy. | 14:21.50 |
| paulgardiner | tor8: if font_size is changed to float, there's at least one place where a %d needs to be changed to a %f. | 14:21.57 |
| tor8 | but still, we should probably use it | 14:21.59 |
| | paulgardiner: %g | 14:22.09 |
| | %f has a horrible fixed number of decimals thing going on | 14:22.24 |
| | Robin_Watts: explicit casts when losing precision might be useful | 14:22.51 |
| paulgardiner | Oh ok. Whatever is the best for Tf | 14:22.59 |
| Robin_Watts | Yes. | 14:23.00 |
| tor8 | Robin_Watts: or better yet, fix our types so that we don't do it as much | 14:23.02 |
| | the whole signed/unsigned crap always makes me angry | 14:23.19 |
| | Robin_Watts: anyway, I have a patch in the works that completely eliminates fz_bbox in favor of fz_rect everywhere. I just need to spend more time going through the places where it's actually converted to integers in the draw device to make sure we don't mess up and truncate instead of round. (hence my chasing implicit float->int casts) | 14:25.14 |
| Robin_Watts | Hmm. Really? | 14:25.44 |
| tor8 | Robin_Watts: where do you keep the latest and greatest sane test files? I have a feeling my suite is horribly out of date. | 14:25.47 |
| Robin_Watts | I can understand removing fz_bbox in the public interface (maybe) | 14:26.16 |
| tor8 | Robin_Watts: it actually came out better than I expected. I was originally only going to remove it from the public interface, but things did end up cleaner with no fz_bbox at all. | 14:26.40 |
| Robin_Watts | but for the draw device, we need bboxes for some things. Using rects for things that have to be ints is just wrong. | 14:26.55 |
| tor8 | the places where it may be integerized are only in relation to pixmaps. | 14:27.25 |
| Robin_Watts | I'll have to look at the patch. | 14:27.29 |
| | right. | 14:27.33 |
| tor8 | rects can represent all sane integer values perfectly, so that's not really a worry | 14:27.42 |
| Robin_Watts | so I could understand if we had an fz_bbox that was only used within the draw device. | 14:27.53 |
| tor8 | s/rects/floats/ | 14:27.54 |
| Robin_Watts | but using floats when we could use ints costs us on embedded platforms. | 14:28.08 |
| | floats are slow. | 14:28.18 |
| tor8 | Robin_Watts: I'd be inclined to rename it fz_irect and live with the ugly name just to prevent it spreading | 14:28.27 |
| Robin_Watts | I could live with that. | 14:28.44 |
| tor8 | Robin_Watts: the places where the rects come in as floats and get turned to ints are already full of floats | 14:28.45 |
| | the matrices come in at the same level | 14:29.04 |
| | Robin_Watts: I'll take what I have now (no fz_bbox at all) and add fz_irect and compare, but first I want to sane the diffs. | 14:29.44 |
| Robin_Watts | Sure. | 14:30.01 |
| | I have no new 'sane' files other than the sumatra ones. | 14:30.14 |
| | and they are all in tests_private/pdf/sumatra | 14:30.26 |
| tor8 | argh, not svn, please! | 14:30.36 |
| Robin_Watts | tor8: sorry. | 14:34.17 |
| Robin_Watts | lunches. bbs. | 14:34.21 |
| henrys | kens:there should at least be an enhancement in bugzilla for customer 1's issue even if they are going at it now. | 15:26.05 |
| kens | henrys we may well have one I will look | 15:30.24 |
| | henrys bug #535932 | 15:36.29 |
| | and #687793 | 15:36.44 |
| henrys | wow a #5 eh? | 15:36.55 |
| kens | :-) | 15:37.05 |
| | I should probably close #535932 and move it to 687793, which is rather more descriptive | 15:38.10 |
| mvrhel_laptop | good morning | 16:47.27 |
| kens | good evening | 16:47.45 |
| mvrhel_laptop | still no word on getting tickest | 16:48.13 |
| | tickets | 16:48.15 |
| kens | Not that I've seen | 16:48.23 |
| mvrhel_laptop | ok | 16:48.40 |
| | how are you feeling today ray_laptop? | 16:50.02 |
| ray_laptop | good morning, Robin_Watts | 16:50.03 |
| | mvrhel_laptop: my neck isn't quite as painful. At least I was able to sleep last night | 16:50.29 |
| mvrhel_laptop | thats good | 16:50.34 |
| ray_laptop | sure is! | 16:50.40 |
| mvrhel_laptop | sounds like a move in the right direction | 16:50.46 |
| ray_laptop | Robin_Watts: how's it going with the simulator ? Do you need any hints on using it ? | 16:51.15 |
| Robin_Watts | ray_laptop: I'm pretty much there I thnk. | 16:51.36 |
| ray_laptop | Robin_Watts: OK. At least it should let you see the same function usage that they report | 16:52.43 |
| Robin_Watts | ray_laptop: They hadn't disabled interpolation in this version, but I have the file from them that should do that. | 16:53.04 |
| | The blackhole for time actually appears to be the pdf14 stuff. | 16:53.18 |
| ray_laptop | but when it comes to performance the x86 is _so_ much faster doing pdf14 rendering compared to their target that it's hard to relate | 16:53.49 |
| henrys | they have powerpc? | 16:54.11 |
| ray_laptop | henrys: yes. About 1.2GHz, iirc (they have different engines with different speeds) | 16:54.44 |
| | Robin_Watts: if there interpolated images, then that will call gx_default_copy_color which will make GOBS of calls to pdf14_fill_rectangle (mostly with 1x1 pixel rects) | 16:56.01 |
| chrisl | We can hardly be expected to do transparency blending *and* match their performance without blending | 16:56.38 |
| ray_laptop | Robin_Watts: the modification for them to limit interpolation (to 150 dpi if the scale is 4) will result in 1/16 the number of pixels | 16:57.05 |
| Robin_Watts | In their profiles (with interpolation turned off) we see 64.7% in pdf14_fill_rectangle | 16:57.05 |
| | ray_laptop: Apparently the speed with interpolation disabled is pretty much the same as the speed with interpolation decimated with that patch. | 16:58.07 |
| ray_laptop | some of their older engines were TOTALLY blowing off interpolation. Same as using -dNOINTERPOLATE | 16:58.14 |
| Robin_Watts | i.e. it's working well. | 16:58.25 |
| ray_laptop | Robin_Watts: OK. | 16:58.45 |
| | Robin_Watts: what's the percentage in pdf14_fill_rectangle with interpolation enabled (at full res) ? | 16:59.28 |
| Robin_Watts | don't know. | 16:59.51 |
| ray_laptop | 65% with interpolation off is still a really high percentage. | 17:00.07 |
| Robin_Watts | yes indeed. hence me optimising those functions at the moment. | 17:00.52 |
| kens | TIMe to go, night all | 17:23.23 |
| Robin_Watts | night kens. | 17:23.31 |
| ray_laptop | mvrhel_laptop: are you available for a question? | 17:24.14 |
| mvrhel_laptop | ray_laptop: sure | 17:24.25 |
| ray_laptop | mvrhel_laptop: thanks. So in gdevp14.c line 3510 it sets the group_color_numcomps to whatever the device has, ignoring the setting from the begin trans group parameter. | 17:25.54 |
| mvrhel_laptop | hold on | 17:26.09 |
| | ray_laptop: the device color settings should have been set to whatever the group was | 17:26.33 |
| ray_laptop | mvrhel_laptop: this is the case when sep_target is true | 17:26.40 |
| mvrhel_laptop | oh. so the group color spaces should not be having any effect in this case | 17:27.09 |
| | they should always be CMYK+spot | 17:27.17 |
| ray_laptop | mvrhel_laptop: in this case the num_components is 4 (no spot colors) but 'max_components' is 14, so the pdf14 device proto chosen is pdf14cmykspot | 17:28.44 |
| mvrhel_laptop | ray_laptop: if we are dealing with a file that has spot colors and we are going out to a sep device, then the transparency group color spaces should never be RGB | 17:29.36 |
| ray_laptop | mvrhel_laptop: so this is the case where it works. Just checking to make sure this is what is intended. | 17:29.53 |
| | mvrhel_laptop: this file doesn't have anything beyond CMYK | 17:30.14 |
| mvrhel_laptop | ok. what about in the case where things don't work? | 17:30.41 |
| ray_laptop | mvrhel_laptop: so the problem is that when I use -dNumRenderingThreads > 0 we end up selecting the pdf14cmyk prototype device, and sep_target is false. Then the color space of the pattern is confused. | 17:31.31 |
| mvrhel_laptop | oh sep_target is not getting set for the thread devices | 17:31.57 |
| Robin_Watts | ray_laptop: What bug are you looking at ? | 17:31.59 |
| ray_laptop | I just wanted to understand this much. I will look at why the MT rendering is selecting a different device. | 17:32.19 |
| | Robin_Watts: 693541 | 17:32.24 |
| mvrhel_laptop | you probably need to jigger the special_op for this | 17:32.29 |
| Robin_Watts | ray_laptop: Right. I said the other day that I was looking at that. | 17:32.45 |
| mvrhel_laptop | hehe | 17:32.51 |
| Robin_Watts | I have a fix in testing for it. | 17:32.52 |
| | But the problems I was seeing are NOT the same as the ones you're describing, so I'm a bit confused. | 17:33.16 |
| ray_laptop | Robin_Watts: OK. so what is your fix ? | 17:33.27 |
| Robin_Watts | The problem that I'm seeing is that we can't calculate plane_depth = dev->color_info.depth / dev->color_info.num_components | 17:34.10 |
| | so, as I said on here the other day, my fix is to change gxdso_is_native_planar. | 17:34.42 |
| ray_laptop | oops. Sorry. wrong bug number. | 17:34.55 |
| Robin_Watts | Instead of returning 0 for non planar, and 1 for planar, I return 0 for non planar, and ... | 17:35.03 |
| | Ah! | 17:35.05 |
| ray_laptop | this is bug 693557 | 17:35.14 |
| Robin_Watts | That makes soooo much more sense :) | 17:35.22 |
| ray_laptop | Robin_Watts: I got the '541 number locked in my brain after our discussing it. | 17:36.01 |
| Robin_Watts | Ok, well, my fix seems to test out quite well for 541, except for a few cases that I can't explain. | 17:36.20 |
| | mainly PCL files, with non planar devices IIRC, which is odd. | 17:36.52 |
| | I'll shut up and leave you to your previous discussion then :) | 17:37.14 |
| ray_laptop | mvrhel_laptop: OK. So the problem is that max_components is set to 4 when we do the putdeviceparams to set the rendering thread's device. This (apparently) never happened to the actual device, so it still has 14. This explains the regression. | 17:52.21 |
| mvrhel_laptop | aha | 17:52.43 |
| ray_laptop | mvrhel_laptop: I can 'brute force' copy the cdev->color_info to the ndev->color_info AFTER the putdeviceparams, but that seems a little hacky | 17:52.55 |
| | mvrhel_laptop: I'm going to look at the putdeviceparams for the primary device to see why max_components isn't getting set | 17:54.00 |
| mvrhel_laptop | yes. I agree. but I don't understand why the thread device would be getting set to something different than what its parent device had | 17:54.02 |
| ray_laptop | mvrhel_laptop: the thread setup copies the prototype of the device (in this case psdcmyk) and starts with max_components=64 | 17:54.40 |
| | mvrhel_laptop: then we read the device params for the actual device and the putdeviceparams is _supposed_ to set the thread's copy to the same state in effect when we start rendering the page | 17:55.48 |
| mvrhel_laptop | max_components is set based upon the file type and the number of spot colors and what we have for GS_CLIENT_COLOR_MAX_COMPONENTS | 17:58.04 |
| | as well as if we have an DEVICEN ICC profile as an output profile | 17:58.23 |
| | this is all set up during prn_open | 17:58.51 |
| JamesMT | Hey all, I am attempting to figure out why MuPDF seems to drop some unicode characters, such as é¨ and é. The specific application I am using is mudraw if that helps. I am consistently getting the warning "cannot encode character with code point 0x7200 (and some other numbers) as well as code point 0. If some insight into if these are related could be given that would be very helpful. | 18:05.25 |
| Robin_Watts | JamesMT: You probably need to speak to tor8, but it's 7pm where he is at the moment, so you may have left it a bit late for the day. | 18:06.22 |
| JamesMT | Arg.. Missed him again!? | 18:06.43 |
| Robin_Watts | Almost certainly he'll need to see the file to be able to make any informed comments. | 18:06.58 |
| JamesMT | Stupid morning rush at work kept me running around in circles :D | 18:07.02 |
| Robin_Watts | Can you share the file publicly? IF so, open a bug on bugs.ghostscript.com and attach it there. | 18:07.26 |
| JamesMT | I will work on getting a public file Robin_Watts.. I was informed yesterday I could send a character or two but we had only received permission to send this file to Oracle. | 18:08.25 |
| | Thanks for the info, as always :) | 18:08.37 |
| Robin_Watts | JamesMT: A character or two? | 18:08.51 |
| | A file which shows the problem with just a character or two in would be ideal. | 18:09.07 |
| | saves us cutting it down. | 18:09.24 |
| JamesMT | Should be easy to get that.. but since I do not speak the language.. or read it.. I will have to have someone else figure out which ones we can send :) | 18:09.54 |
| Robin_Watts | If you are unable to share the file with the world, but could do so with just the developers, then let me know, and we can sort that out. | 18:10.34 |
| JamesMT | Sounds good | 18:12.38 |
| ray_laptop | mvrhel_laptop: OK. I see the asymmetry. During parsing, we never see the MaxSeparations set (because Adobe defines that as 'read_only'), and the gx_default_get_params sets this to color_info.num_components (not max_components) | 18:12.49 |
| JamesMT | Got the wheels turning on this side about either clearing the file for the world, for you guys or just getting some of the characters into a PDF that still exhibits this odd result. | 18:13.13 |
| ray_laptop | JamesMT: how is Oracle involved with this ? | 18:13.54 |
| JamesMT | ray_laptop: We also use some of their software and have had issues with their software with this file | 18:14.49 |
| ray_laptop | JamesMT: gs with -dPDFSTEP can let you see what is printing particular characters | 18:15.06 |
| | JamesMT: I see. I thought maybe Oracle was going to rip-off mupdf (like they do with ghostscript) | 18:15.41 |
| JamesMT | ray_laptop: Haha, Not that I am aware of :) (I do not work for Oracle :)) | 18:16.15 |
| | And I will give that a try, thanks :) | 18:17.00 |
| ray_laptop | in order for Oracle to create PDF's they tell their customers to use ghostscript, but they won't license it from us so their customers can get support and not have to download GPL Ghostscript | 18:17.10 |
| | mvrhel_laptop: did you see my comment about MaxSeparations ? | 18:17.55 |
| mvrhel_laptop | ray_laptop: yes. sorry. I stepped away for a sec | 18:18.18 |
| | Not sure I understand what you are saying there though | 18:19.03 |
| Robin_Watts | ray_laptop, mvrhel_laptop: So, I have tweaked pdf14_mark_fill_rectangle and art_pdf_composite_pixel_alpha_8 to get some speedups. | 18:20.55 |
| mvrhel_laptop | nice | 18:21.09 |
| Robin_Watts | I'm going to try to port the changes back into head. | 18:21.14 |
| ray_laptop | Robin_Watts: great | 18:21.15 |
| Robin_Watts | It depends I guess how far we want to go with the optimisations. | 18:21.33 |
| | I have added specific mono additive only paths as that's what they are using. | 18:21.56 |
| | dunno whether you consider those are worth adding to gs in general. | 18:22.12 |
| | It seems like a common case to me. | 18:22.20 |
| ray_laptop | mvrhel_laptop: the issue is that during parsing, we never put a param list that has MAxSeparations in it, but when we read the device's param_list in order to setup the render thread's device, it puts all valid parameters into the list (as it should), but it sets MaxSeparations from pdev->color_info.num_components | 18:25.58 |
| mvrhel_laptop | that does not seem right | 18:26.22 |
| ray_laptop | then this causes us the set the render thread's max_components to 4 | 18:26.40 |
| | mvrhel_laptop: and then we end up picking the pdf14cmyk device proto INSTEAD of the pdf14CMYKspot proto during rendering, and then the 'sep_target' end up getting set to false. | 18:27.43 |
| mvrhel_laptop | right | 18:27.52 |
| ray_laptop | mvrhel_laptop: so, it seems like setting it to max_components makes more sense, right ? | 18:28.20 |
| JamesMT | ray_laptop: Hmm, the characters show up fine using gs.. | 18:28.28 |
| mvrhel_laptop | that is what I would have expected to see ray_laptop | 18:28.33 |
| ray_laptop | mvrhel_laptop: OK. Whew! what a tangled mess :-( | 18:28.50 |
| mvrhel_laptop | ray_laptop: yes. I have been in there and appreciate you figuring out the issue | 18:29.13 |
| ray_laptop | mvrhel_laptop: trying that locally | 18:29.20 |
| mvrhel_laptop | it is actually better than it used to be | 18:29.29 |
| ray_laptop | mvrhel_laptop: well, the regression ended up on my plate because of the cdev to ndev change in the clist_setup_render_threads | 18:29.58 |
| mvrhel_laptop | there were a lot of issues in the separation and deviceN color settings that I found | 18:30.01 |
| | but I had not played with the MT rendering case | 18:30.20 |
| ray_laptop | mvrhel_laptop: I am sure there were. And in trying to trace any reasoning, a lot of things stop at the massive Henry Stiles commit with the log message "DeviceN" | 18:30.50 |
| mvrhel_laptop | yes. aha. got a reply back from customer 330 | 18:31.18 |
| Robin_Watts | "sorry, we haven't looked yet" ? | 18:33.31 |
| mvrhel_laptop | Robin_Watts: no progress.... | 18:33.47 |
| | shooting for something before the August release now | 18:34.08 |
| ray_laptop | mvrhel_laptop: this should be more consistent since the devn_put_params sets pdev->color_info.max_components = max_sep; | 18:34.19 |
| mvrhel_laptop | ray_laptop: aha. ok. I am surprised this did not cause any other issues | 18:34.46 |
| ray_laptop | mvrhel_laptop: grr... Now it fails because of the horrendous assignment in gdevdevn.c line 513+++ | 18:42.17 |
| | it ends up setting num_components to max_components :-( | 18:42.38 |
| | or max_separations | 18:43.10 |
| mvrhel_laptop | oh I remember trying to figure that one out with all the ?:?:?: | 18:43.22 |
| ray_laptop | yep that's the booger | 18:43.35 |
| | this will only work if MaxSeparations actually comes from the devn_params (i.e. which will keep it at 0). At least for the case where the device uses devn_params | 18:46.18 |
| henrys | nesting conditional with ternary operators could be banned in style.htm, I know some people like them but I think they hurt readability a lot. | 18:49.34 |
| Robin_Watts | Every new programming tool is something sharp for people to stab themselves with. | 18:50.25 |
| ray_laptop | mvrhel_laptop: looking at devn_get_params, I don't see how this works. It looks like it will always return dummy parameters for SeparationOrder, SeparationColorNames and always 'false' for Separations. How can this be right ? | 18:50.53 |
| Robin_Watts | You have to trust that the benefit of the tool outweighs the additional cost in sticking plasters. | 18:50.59 |
| mvrhel_laptop | ray_laptop: I tried to add in comments etc. on this. If you want to drop it all on me that is fine I can try to clean things up further | 18:52.31 |
| ray_laptop | mvrhel_laptop: comments where ? | 18:54.18 |
| mvrhel_laptop | hold on ray_laptop. | 18:54.36 |
| apineda | how can I juse the interpret to run something similar to "gs -sDEVICE=pdfwrite -o OUT.pdf IN.pdf" | 18:55.55 |
| Robin_Watts | apineda: Sorry? | 18:56.45 |
| mvrhel_laptop | ray_laptop: I guess most of my comments went into the device open stuff to explain how those values are set | 18:56.50 |
| ray_laptop | mvrhel_laptop: which file ??? | 18:57.05 |
| mvrhel_laptop | the device | 18:57.13 |
| | file | 18:57.14 |
| | psd | 18:57.16 |
| | tiffsep | 18:57.18 |
| | not relevant to what you are doing | 18:57.40 |
| apineda | Maybe for me it's gswin32 then | 18:58.19 |
| Robin_Watts | gswin32c.exe probably on windows ? | 18:58.32 |
| apineda | Robin_Watts: sorry, that was meant for you | 18:58.36 |
| | yeah | 18:58.37 |
| ray_laptop | mvrhel_laptop: we are supposed to be able to do a 'get_params' and then a 'set_params' on a device. How can devn_get_params ever work ? | 18:59.12 |
| apineda | didn't seem to work. | 18:59.53 |
| | no output | 19:00.06 |
| mvrhel_laptop | ray_laptop: I don't know. I only made the changes with the 4/27/12 commit | 19:00.58 |
| | ray_laptop: do you want me to take this over for you? | 19:01.07 |
| ray_laptop | mvrhel_laptop: how about I go ahead and fix MaxSeparations in devn_get_params and then open a bug for the other issues that may need attention ? | 19:02.48 |
| mvrhel_laptop | ray_laptop: Please do whatever you believe is best | 19:03.07 |
| ray_laptop | mvrhel_laptop: I think we'll be OK since I don't think the thread rendering device ever needs the Separation* params | 19:03.56 |
| | mvrhel_laptop: obviously that's working now. | 19:04.35 |
| henrys | Robin_Watts: do you mind if I cluster push again I see you were using the cluster and your problem is higher priority? | 19:13.36 |
| Robin_Watts | henrys: go for it. | 19:14.20 |
| | pcl runs are way faster than gs ones. | 19:14.44 |
| | having said that, I've just run a gs lowres one, sorry. | 19:16.13 |
| henrys | no problem like I said your work should have priority, I am just fixing a non customer regression. | 19:20.37 |
| | my rsync crapped out anyway - wireless at the library is not so great here. | 19:21.54 |
| Robin_Watts | I'm amazed at how you guys can work in places other than your offices. | 19:22.34 |
| | I couldn't face lugging the 2 huge monitors around with me... | 19:22.52 |
| henrys | headed home now bbiaw | 19:44.54 |
| ray_laptop | mvrhel_laptop: This stuff is a REAL mess. If I end up setting MaxSeparations to max_components, then the screwy ? ? ? code in gdevdevn.c line 513 ends up setting the num_components to that value : (pdevn_params->max_separations) ? pdevn_params->max_separations | 19:45.45 |
| | that ALSO doesn't seem right. max_separations shouldn't affect the number of components we are using | 19:46.42 |
| mvrhel_laptop | ray_laptop: sorry I was out. I had to pickup my son at school | 20:26.51 |
| | Forward 1 day (to 2013/01/17)>>> | |
IRC Logs