| | <<<Back 1 day (to 2016/01/11) | 20160112 |
| HenryStiles | Robin_Watts, chrisl : any reason arg_next()'s output parameter code is not initialized to 0 at the top of the routine? I've worked around it in what I"m doing in PCL but it seems wrong that the routine will in some cases return without inializing the code parameter. | 00:02.29 |
| Robin_Watts | looking. | 00:29.25 |
| | it doesn't need to be ? | 00:30.55 |
| | You can't get any further down than #define is_eol without result being set. | 00:31.37 |
| | Oh, you mean you want *code = 0 ? | 00:32.04 |
| | If I'm reading the code correctly, code is only set if we return NULL. | 00:33.09 |
| | Otherwise it's maintained. | 00:33.49 |
| HenryStiles | Robin_Watts: the "all done" case returns 0 without setting code, I think code should be set to 0 in that case. | 02:11.39 |
| Robin_Watts | HenryStiles: possibly. It's not clear to me what contract the function offers. If it's "code is left unchanged unless this returns NULL" then that'd be wrong. | 10:00.12 |
| chrisl | Hmph, don't like that use of "code" in arg_next()...... | 10:23.47 |
| | But where it's used in gs, the "code" parameter is always initialized before the call to arg_next() | 10:26.30 |
| Robin_Watts | If that's true, then it wouldn't hurt to make it always set *code in the routine, which would be nicer. | 10:27.23 |
| chrisl | Yes, I'd agree - although, I'd prefer if we actually returned the return code | 10:29.13 |
| | And the existing pl_main_process_options() explicitly initializes the variable, too..... | 10:31.04 |
| | Although, personally, I'd prefer the function to be: int arg_next(arg_list * pal, char **param, const gs_memory_t *errmem) | 10:32.26 |
| Robin_Watts | I'd have no complaints about that change. Returning error code does seem more in keeping. | 10:44.43 |
| chrisl | If HenryStiles endorses it, then I'll do it when I dig myself out of my current mess..... | 10:46.58 |
| aleray | hi, I found this command to split my pdfs in two: http://dpaste.com/1TMGVHA | 11:25.12 |
| | it works well but now I'm wondering how it would work with multipage pdfs | 11:25.32 |
| | could you give me a clue? | 11:25.39 |
| kens | Firstly you are not splitting your PDFs in two | 11:25.49 |
| | You are creating 2 new PDF files whcih should have the same visual appearance as portions of the original | 11:26.12 |
| | But the actual content will be different | 11:26.20 |
| | For multipage PDFs you will end up with 2 PDF files, one cintaining all the left sides, the other containing all the right sides. | 11:27.05 |
| | What does it not do that you were expecting it would ? Have you actually bothered to try it first ? | 11:27.34 |
| aleray | kens, thanks. I would like then to intertwine the two pdf files. C/Should I use ghostscript for that or is there another tool more appropriate? | 11:30.11 |
| kens | You cannot simply interleave the pages. | 11:30.28 |
| aleray | kens, yes create a new pdf | 11:30.47 |
| kens | Using GS the 'easiest' way to do it is to produce each page as a separate file and then run all the files, in order, back through pdfwrite. | 11:31.02 |
| | Which leads to potential problems due to multiple conversions. | 11:31.24 |
| | The better solution would be to modify the PDF interpreter to rerun the pages as required, altering the PageOffset each time. However that requires some PostScript programming ability | 11:32.02 |
| aleray | kens, what kind of problems? My final file is intended for offset printing so I'm worried about the conformity of the output | 11:32.36 |
| kens | Every time you run the output back thourh as input you potentially degrade the quality of the output, as compromises may have to be made in order to create the PDF file. | 11:33.10 |
| | Multiple conversion passes are a Bad THing | 11:33.27 |
| aleray | kens, what do you mean by "to modify the PDF interpreter to rerun the pages as required". Could you give me an exemple? | 11:34.47 |
| kens | I mean rewrite the PostScript program which does the work of interpreting the PDF file. And no, I cannot give you an example. It requires some ability to program in PostScript. | 11:35.50 |
| aleray | kens, ok thanks | 11:40.10 |
| Robin_Watts | aleray: To extract pages, you could use mupdf's "mutool clean" feature. | 12:42.58 |
| | That would get you single pages (or page ranges) that don't have any changes in from the original file. | 12:43.26 |
| | Actually, if your sole desire is to reorder the pages, we can probably do that too. | 12:43.57 |
| | Yeah, mutool clean will do that. | 12:45.38 |
| | Oh, but it won't do the offsetting. | 12:46.28 |
| | tor8: robin/master updated with the changes we talked about yesterday. | 12:56.30 |
| | Except for the 'Color' one. I'm not keen on that. I can't see that it actually gains us anything, and it just requires lots of object creation/destruction for no good purpose. | 12:57.09 |
| | My hacked app runs, so it basically works. | 12:57.29 |
| tor8 | Robin_Watts: will look after lunch | 13:01.58 |
| Robin_Watts | Ta. | 13:02.05 |
| tor8 | neck deep in debugging my MuJS typed arrays | 13:02.15 |
| | figured I'd need those for replicating the java api you just wrote in javascript :) | 13:02.29 |
| Robin_Watts | ah :) | 13:07.28 |
| HenryStiles | chrisl: I'd prefer returning the code also ... | 14:20.37 |
| | initialized to something ;-) | 14:25.49 |
| sebras | tor8: trivial patch over at sebras/master for manpages prompted by http://bugs.ghostscript.com/show_bug.cgi?id=696370 | 15:26.17 |
| HenryStiles | staff meeting at #artifex | 15:30.36 |
| aleray | Robin_Watts, mutool poster -x 2 input-spread.pdf output-single.pdf works well | 15:33.25 |
| Robin_Watts | aleray: Oh, I see. Yes. | 15:33.53 |
| aleray | Robin_Watts, I didn't know mupdf. how does it compare with things like podofo impose or pdftk? | 15:34.42 |
| Robin_Watts | aleray: mupdf is also developed by us. | 15:35.58 |
| | It's primarily a renderer for screen use. | 15:36.12 |
| | but it can do simple operations like splitting pages out. | 15:36.28 |
| | We're extending it all the time. | 15:36.40 |
| | I am not particularly familiar with pdftk and podofo impose. | 15:36.55 |
| aleray | Robin_Watts, OK. Artifex is the company who devellop ghostscript right? | 15:37.30 |
| kens | And MuPDF and Smart Office | 15:37.57 |
| Robin_Watts | yes. | 15:38.06 |
| aleray | ok thanks | 15:38.51 |
| | Robin_Watts, do you know how I could increase the size of my pages? I want to add 14pt on the right side of left hand pages and 14pt on the left side of right hand pages | 15:41.17 |
| Robin_Watts | aleray: Currently, no. | 15:41.32 |
| | I'd like to do a mupdf based tool to do that, but we're not there yet. | 15:41.50 |
| aleray | ghostscript can't do that? | 15:41.58 |
| kens | Yes it can, but it means programming PostScript | 15:42.51 |
| Robin_Watts | aleray: Not without programming, no. (what kens said :) ) | 15:43.02 |
| aleray | Robin_Watts, ok thanks | 15:43.43 |
| | I will dig into podofo impose then. Very clever tool for that I think | 15:44.28 |
| kens | The PostScript 'save in a dictioanry' is slow and klunky and much of what we process these days is PDF files. | 15:59.26 |
| | SO I thnk its worth doing myself, I'm doubtful it will be signficantly slower for PostScript | 16:00.03 |
| chrisl | I doubt the extra stuff will hurt the gsave/grestore performance measurably | 16:00.11 |
| kens | <echo...> | 16:00.23 |
| | Best thing is to try it and see I believe | 16:00.43 |
| chrisl | That's the only way to be sure | 16:01.39 |
| Robin_Watts | </NukeTheCodeFromOrbit> | 16:02.29 |
| kens | Like I said, tomorrow I'll do the quick and dirty dict (and perhaps other) stack changes and open a new enhancement, then it can sit for a while. Who knows I may even get to do it one day | 16:02.29 |
| | chrisl have you thought about flights to SFO yet ? | 16:15.58 |
| chrisl | kens: only briefly - keep getting distracted | 16:18.38 |
| kens | I know the feeling :) | 16:18.47 |
| chrisl | I don't think I can be bothered going to the show, though | 16:19.06 |
| kens | I'm not going to go | 16:21.25 |
| | I don't thnk I'd get much from it, especially while trying to stay awake from jetlag | 16:21.41 |
| chrisl | So, probably fly out on the 3rd, back on the 6th - unless there is another compelling reason for extra night(s) | 16:21.49 |
| kens | I'll probably book mine tomorrow then | 16:22.06 |
| rayjj | chrisl: kens: I am getting errors with 64-bit built with VS 2015 Community Ed. when trying to use the "display" device. It dies with an uncaught exception in the WM_MOVE handler. Can one of you try this ( | 16:24.16 |
| kens | Yes, but not today | 16:24.47 |
| rayjj | mvrhel: for the logs: can you try this as well. | 16:25.05 |
| kens | I *thnk* I still have a VS 2015 | 16:25.13 |
| chrisl | I don't have it installed | 16:25.32 |
| | The most recent I have is 2012 | 16:25.43 |
| rayjj | kens: chrisl: mvrhel: it dies as soon as I go to (open) the "image" window. | 16:26.12 |
| | no options on the command line needed | 16:26.53 |
| | well, the first thing is to make sure that 64-bit works on the tool you have | 16:27.37 |
| chrisl | I'm building with 2012 - will let you know | 16:28.09 |
| rayjj | chrisl: thanks. | 16:29.22 |
| | chrisl: actually, gswin64c dies with the exception. gswin64 just goes away without doing anything | 16:30.52 |
| | with gswin64, the command prompt window loses focus and it looks like another window title bar flashes up briefly, then the focus returns to the command prompt window and gswin64 has exited | 16:32.33 |
| chrisl | It's fine with VS2012 | 16:34.28 |
| | rayjj: ^^ | 16:35.34 |
| rayjj | chrisl: oh, darn. BTW, I'm on Windows 10 64-bit Pro | 16:36.19 |
| | mvrhel_laptop: you have VS 2015 and Windows 10, right ? | 16:36.36 |
| chrisl | I'm only on Win7 - even my Windows 8 install is borked just now | 16:37.05 |
| rayjj | mvrhel_laptop: does gswin64c run to the default (display) device OK for you ? | 16:37.05 |
| mvrhel_laptop | rayjj: on one machine I do | 16:37.19 |
| rayjj | I may have been hasty going to Windows 10 :-/ | 16:37.40 |
| mvrhel_laptop | rayjj: I am at the coffee shop now. The machine with VS 2015 and windows 10 is at home. | 16:37.46 |
| | I will try it when I get back | 16:37.50 |
| kens | I can't try it on 10, only 7 | 16:38.20 |
| rayjj | I've had bunches of screwy problems with windows staying "behind" even when they have focus and after I click on the title bar (with 7, windows that got focus always came to the top) | 16:38.52 |
| | mvrhel_laptop: OK, thanks. | 16:39.07 |
| chrisl | rayjj: do you have an earlier VS? | 16:39.08 |
| rayjj | chrisl: yes, but I don't have 64-bit tools installed on 2008 | 16:39.30 |
| mvrhel_laptop | there was an issue with the display device and x64 I do recall that | 16:39.44 |
| | actually the issue may exist with 2013 and windows 8 too. I thought I opened a bug about this | 16:40.03 |
| | let me try here | 16:40.10 |
| rayjj | mvrhel_laptop: thanks | 16:40.28 |
| | mvrhel_laptop: I would think that would be a pretty serious issue | 16:40.56 |
| | although few of our customers use the display device (I think) | 16:41.43 |
| mvrhel_laptop | rayjj: I agree | 16:43.33 |
| | I rarely use the display device myself. I just recall seeing something with x64 and the display device when I was working on that 256 color device issue | 16:45.55 |
| | But I figured at the time that it was because of how I was setting it up (trying to get the windows display device to assume 256 colors) | 16:46.27 |
| | but it may have been something more | 16:46.35 |
| | ok. so yes. with 2013 and 8.1 x64 crashes | 16:50.49 |
| | rayjj: in WndImg2Proc | 16:51.18 |
| | img is bogus | 16:51.43 |
| | let me see if I can find what the issue is. or are you working on it rayjj? | 16:52.05 |
| | let me make sure 32bit is fine.. | 16:53.16 |
| rayjj | mvrhel_laptop: I am just using win32c in the meantime. You are probably better at tracking it down that I am | 16:53.17 |
| mvrhel_laptop | rayjj: ok will do | 16:53.29 |
| rayjj | mvrhel_laptop: 32 bit works OK for me | 16:53.33 |
| | mvrhel_laptop: that's the uncaught exception I'm getting as well (usually with the WM_MOVE event) | 16:54.16 |
| mvrhel_laptop | yes exactly | 16:54.25 |
| | and yes 32 bit is fine here. so at least we are seeing the same things | 16:55.30 |
| rayjj | mvrhel_laptop: thanks for checking this so I know it's not something (else) peculiar with my system/build | 16:55.55 |
| Robin_Watts | mvrhel_laptop: I wonder if there is a ptr -> int -> ptr cast going on somewhere. | 16:56.03 |
| | or (equivalently) an LPARAM that should be an LPPARAM or whatever. | 16:56.19 |
| mvrhel_laptop | don't know. going to start looking now | 16:56.20 |
| Robin_Watts | There is a "stash this magic value in the window" command that only does 32bit. | 16:56.56 |
| rayjj | chrisl: thanks for checking. You and kens don't have to do any more | 16:57.04 |
| Robin_Watts | and there is a revised version that works on 64bit too. | 16:57.09 |
| kens | ?me is relieved | 16:57.13 |
| chrisl | There's a pretty hideous thing where we convert a 64bit pointer to string, and back again, we use on 64 bit systems | 16:57.40 |
| | Because our param lists only have 32 bit integer values available | 16:58.15 |
| rayjj | chrisl: the whole method for getting the display address thingy is hideous | 16:58.22 |
| chrisl | rayjj: I can't remember all the details, I just remember that bit | 16:59.07 |
| rayjj | chrisl: and the magic voodoo for DisplayFormat values is ugly and unfriendly as well. | 16:59.55 |
| chrisl | rayjj: probably 'cause we don't want people to use it ;-) | 17:00.14 |
| rayjj | chrisl: that's a good point :-) | 17:00.31 |
| mvrhel_laptop | ok so in the following | 17:00.56 |
| | if (message == WM_CREATE) { | 17:01.01 |
| | /* Object is stored in window extra data. | 17:01.02 |
| | * Nothing must try to use the object before WM_CREATE | 17:01.04 |
| | * initializes it here. | 17:01.05 |
| | */ | 17:01.07 |
| | img = (IMAGE *)(((CREATESTRUCT *)lParam)->lpCreateParams); | 17:01.08 |
| | SetWindowLong(hwnd, 0, (LONG)img); | 17:01.10 |
| | } | 17:01.11 |
| | img = (IMAGE *)GetWindowLong(hwnd, 0); | 17:01.13 |
| Robin_Watts | That's the puppy. | 17:01.19 |
| mvrhel_laptop | the last line is screwing up img | 17:01.20 |
| Robin_Watts | GetWindowLog/SetWindowLog is 32bit. | 17:01.33 |
| | try using GetWindowLongPtr/SetWindowLongPtr | 17:01.54 |
| mvrhel_laptop | ok | 17:01.57 |
| chrisl | Hmm, how's it work on earlier versions, I wonder..... | 17:02.16 |
| rayjj | chrisl: I don't know since I never used 64-bit :-) | 17:02.38 |
| | and I'm back to 32-bit now, since it works | 17:02.59 |
| chrisl | I get if we're coincidentally always in the lower half of the address space | 17:03.16 |
| | Er, not half..... | 17:03.39 |
| kens | Night all | 17:10.10 |
| chrisl | Robin_Watts: top commit in my ghostpdl repo - the the arg_next() thing | 17:12.37 |
| Robin_Watts | chrisl: Will look in just a mo. | 17:12.48 |
| | mvrhel_laptop: Did that solve it? | 17:58.57 |
| mvrhel_laptop | Robin_Watts: no. there is some issue with the offset value | 17:59.16 |
| | The setting is failing | 17:59.42 |
| | trying to understand exactly what is going on behind the curtain | 18:00.03 |
| | so | 18:00.05 |
| | ret_val = SetWindowLongPtr(hwnd, 0, (LONG_PTR)img); | 18:01.02 |
| | if (ret_val == 0) | 18:01.03 |
| | err = GetLastError(); | 18:01.05 |
| | ends up returning a code | 18:01.10 |
| | ERROR_INVALID_INDEX | 18:01.23 |
| | which makes me think that nIndex the second parameter is wrong | 18:01.59 |
| | reading the description on SetWindowLongPtr it is not clear to me | 18:03.03 |
| Robin_Watts | Urm.. the offset is 0 to the number of bytes of extra window memory allocated. | 18:03.09 |
| | minus the size of an int. | 18:03.25 |
| | I bet we aren't allocating sizeof(int) + sizeof(ptr), but only sizeof (int)*2 | 18:03.42 |
| mvrhel_laptop | I wonder if that is specified for wndclass.cbWndExtra in register_class | 18:04.15 |
| Robin_Watts | Yes, I think so (just googling) | 18:04.49 |
| mvrhel_laptop | ok | 18:04.52 |
| Robin_Watts | yeah, in register_class, change sizeof(LONG) to be sizeof(LONGPTR); | 18:06.11 |
| mvrhel_laptop | ok | 18:06.29 |
| Robin_Watts | text_register_class already uses sizeof(void *) | 18:07.07 |
| | Same change probably needed in plwimg.c register_class too. | 18:07.30 |
| | certainly shouldn't hurt. | 18:07.45 |
| mvrhel_laptop | yeah! it worked | 18:08.27 |
| | so it was the allocation specification | 18:08.40 |
| | and doing the Ptr versions | 18:08.52 |
| | of set and get | 18:08.56 |
| chrisl | Robin_Watts: revised commit in my repo | 18:09.03 |
| Robin_Watts | chrisl: Would you hate me if I said we should use return_error(blah) ? | 18:10.02 |
| mvrhel_laptop | this bug must have been here for a while | 18:10.09 |
| Robin_Watts | chrisl: but that's all I can think to complain of. | 18:10.35 |
| | mvrhel_laptop: Excellent stuff. | 18:10.48 |
| | yeah, I can't believe it's ever worked :( | 18:10.57 |
| | Maybe it was only ever tested on machines with less than 2 Gig of memory? Even then I'd be suspicious about it working. | 18:11.17 |
| mvrhel_laptop | Thanks for all the help Robin_Watts | 18:11.21 |
| chrisl | Robin_Watts: No, I wouldn't hate you - I'd say "Doh!" | 18:11.24 |
| Robin_Watts | no worries. I'd walked this path before - possibly for SO? | 18:11.42 |
| mvrhel_laptop | talk about code duplication. Is it really needed to have plwimg.c and dwimg.c | 18:17.57 |
| Robin_Watts | mvrhel_laptop: (For the logs). I suspect the answer is "it won't be once we get proper language encapsulation done". | 18:36.53 |
| mvrhel_laptop | Robin_Watts: that makes sense | 18:54.05 |
| HenryStiles | wow oil below $30 a barrel | 19:33.11 |
| | weird it'll be interesting to see what the bbox has to do with icc profiles ... | 19:41.19 |
| Robin_Watts | I think he's just running a build with no bbox device included. | 19:41.52 |
| HenryStiles | yes I wish plwimg.c would go away | 19:48.33 |
| | Forward 1 day (to 2016/01/13)>>> | |
IRC Logs