| <<<Back 1 day (to 2013/06/20) | 2013/06/21 |
Robin_Watts | hi ray | 00:19.13 |
| I can get into your git. | 00:20.24 |
| oh, he's gone. | 00:20.56 |
| So it must be some sort of problem with the setup. I'd check that GIT_SSH is set to plink. | 00:21.30 |
mvrhel_laptop | sigh. looks like I have some serious work to dig into to make the overprint simulation work for the non-cmyk devices | 01:30.17 |
| ugh. serious issue with the overprint simulation blending. deal with this further in the morning | 06:51.06 |
kens | You're up late mvrhel_laptop | 06:51.28 |
mvrhel_laptop | I was hoping to wrap up the 3 overprint simulation bugs that I have open (2 that are customer bugs) | 06:51.58 |
kens | I guess not then :-( | 06:52.11 |
mvrhel_laptop | but I believe in the ghent tests, I see an issue that is going to be very difficult | 06:52.18 |
| essentially, a fill with a separation color | 06:52.34 |
| then over that a fill with a DeviceN color that includes Cyan + the Separation Color | 06:52.57 |
| with overprint mode set to 1 | 06:53.07 |
kens | Hmm, sound odd, but the Ghent tests are quite thorough | 06:53.22 |
mvrhel_laptop | which should end up blowing away the first separation drawing | 06:53.37 |
| if done correctly | 06:53.45 |
kens | Indeed, since its the same ink | 06:53.50 |
mvrhel_laptop | but the problem is we are off in an alternate tint space by this time | 06:54.05 |
| if we are going off to a standard CMYK device | 06:54.13 |
kens | Ah, that's awkward | 06:54.17 |
mvrhel_laptop | we have no idea about the first deviceN drawing | 06:54.23 |
| with psdcmyk or with tiffsep we are OK | 06:54.34 |
| but otherwise not | 06:54.38 |
| since to do overprint we do a getbits | 06:54.53 |
| to merge things together | 06:55.00 |
kens | Lost me on that bit, you;'re into areas I've never touched | 06:55.15 |
mvrhel_laptop | well we have to grab what was already drawn, when we get around to putting the new fill in | 06:55.49 |
kens | Ah right, you pull back from the page buffer, tha already rendered pixels | 06:56.10 |
mvrhel_laptop | yes | 06:56.19 |
| since what we are going to fill with depends upon what we already drew and what we have coming for the fill | 06:56.43 |
kens | I can't think of an answer to that one | 06:56.51 |
mvrhel_laptop | but if we have lost the DeviceN values all bets are off. It is the overprint mode that is screwing things up. If not for that the blending of the colorants does a good simulation | 06:57.33 |
| maybe something will come to me while I sleep... | 06:58.02 |
kens | You could keep track of all the areas already rendered with each ink and intersect any new rendering with the recorded area, then you would know you didn't have to do portions of the new area. Lot of record keepingthough | 06:58.05 |
mvrhel_laptop | ttyl | 06:58.05 |
kens | goodnigth mvrhel_laptop | 06:58.14 |
mvrhel_laptop | kens: yes that is basically psdcmyk and tiffsep | 06:58.28 |
| anyway done for the night | 06:59.27 |
| ttyl | 06:59.30 |
kens | bb | 06:59.33 |
sebras | https://github.com/Juanvvc/ComicViewer/tree/master/ComicViewer does using mupdf in the same app as using that unrar.jar constitute linking? | 07:58.43 |
| oh and do you know about these guys being your competitors in the android market? http://www.radaee.com/en/ | 08:03.34 |
| they're aiming for ios/win8/winrt versions soon. | 08:03.56 |
| what was the name of the mailing list to which I could send potential GPL-issues to? | 08:54.48 |
kens | Did we have a mailing list ? You can send to Miles directly, or to tech@artifex.com I guess. Maybe even both | 08:55.26 |
sebras | ok. | 08:55.35 |
kens | I think he's a bit swamped at the moment :-) Also he's recovering from a minor operation, so it might be a while before Miles gets to them | 08:56.25 |
sebras | kens: I know. but I can't resist. :) | 08:56.44 |
kens | I'm sure he'll be grateful, eventually :-) | 08:57.01 |
Robin_Watts | Gah. I still can't post to gs-devel@ghostscript.com | 09:27.01 |
kens | Mail it to me and I cna do it for you | 09:27.22 |
Robin_Watts | kens: thanks. | 09:30.02 |
kens | NP | 09:30.16 |
Robin_Watts | tor8: So, what did we decide about makefiles? | 09:30.57 |
kens | Robin_Watts : sent | 09:31.23 |
tor8 | Robin_Watts: last message from me was asking whether to make the config flags more consistent (NOX11, V8_PRESENT) -> (HAVE_X11, HAVE_V8) | 09:32.23 |
| and you said something about calling "make V8_PRESENT=no" on the cluster | 09:32.53 |
Robin_Watts | tor8: consistency would be good, but people (and stackoverflow) rely on NOX11 etc, I think. | 09:33.09 |
tor8 | right. | 09:34.21 |
paulgardiner | :-( I have e6460e79 (entitled "Android build fixes") and Android wont build | 10:53.41 |
Robin_Watts | paulgardiner: Indeed. | 10:54.55 |
| I fixed the error calls to be consistent. | 10:55.02 |
| I haven't fixed android since the shuffle though. | 10:55.12 |
paulgardiner | oh okay. That explains it | 10:55.57 |
chrisl | paulgardiner: I rejigged the (one tiny bit of the) winrt stuff as I'd mentioned before - http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8ff1b883 | 10:56.35 |
paulgardiner | chrisl: Right. I shall have a study, so I'll no what to do another time | 10:57.50 |
chrisl | paulgardiner: like I say, it was a pretty minute change - it just means that the entire "platform" support for winrt is built in the core graphics library ("base") | 10:58.46 |
paulgardiner | Yeah, makes more sense that way. I did have a feeling it wasn't the best place when I was doing it. | 10:59.45 |
chrisl | paulgardiner: well, that's a *lot* less clean-up that I have to do after most people's first venture into the GS build ;-) | 11:01.19 |
Robin_Watts | paulgardiner: ok, I've just pushed the latest version of the progressive build (updated to after the shuffle). | 11:01.42 |
| so I'm in a position to look at the android build if you want me to. | 11:01.53 |
| Shall I, or do you want to? | 11:02.37 |
paulgardiner | I wouldn't say "want" :-) but I'm happy to. | 11:04.05 |
Robin_Watts | I don't mind doing it. I just don't want to waste time having both of us duplicate work. You choose. | 11:07.06 |
paulgardiner | Well if you don't mind doing it, I could work on rebasing my incremental stuff up to the same point. | 11:08.53 |
Robin_Watts | I'll have a go. | 11:15.00 |
paulgardiner | Robin_Watts: My changes are causing timeouts in the cluster tests, but I'm having trouble identifying which files are failing. Most of the log output looks fine. | 11:57.02 |
Robin_Watts | paulgardiner: As a sanity check, cluster push an unchanged tree. | 11:57.37 |
kens | It syas 'log files too big' did you leave some debugging code in there ? | 11:57.48 |
paulgardiner | I did, hoping it would fail in the same way, but no | 11:57.56 |
Robin_Watts | my next bet would be what kens said. | 11:58.18 |
paulgardiner | kens: Don't think so. I don't think I used any debugging for this | 11:58.21 |
kens | There's a lot fo these: | 11:58.56 |
| warning: cannot encode character with code point 0x7420 | 11:58.57 |
paulgardiner | Yeah. I noticed that. Didn't think I'd been near anything to do with that. Might be those lines appear in nornal runs | 11:59.43 |
kens | All the nodes are reporting log files too big, so my guess is *something* is writing into the log files. Especially if a normal run works OK | 12:00.05 |
| You can look at the log files fro the dashboard | 12:00.27 |
paulgardiner | Maybe I should be looking at the final file in each log | 12:00.48 |
kens | I'm not certain, the log terminates with timeoutFail: log file(s) too big: | 12:01.10 |
| and lists a nunber of files | 12:01.16 |
Robin_Watts | paulgardiner: Are you testing mupdf or mujstest ? | 12:01.27 |
paulgardiner | mujstest | 12:01.36 |
kens | fathoms has: | 12:01.39 |
| 4 temp/tests_private__pdf__forms__v1.6__lvn-rn_preceptor_agreement.mjs.ppmraw.72.0.log | 12:01.39 |
| 4 temp/tests_private__pdf__forms__v1.6__ocr_11822_form_l_gcse_form_wms724i.mjs.ppmraw.72.0.log | 12:01.39 |
| 4 temp/tests_private__pdf__forms__v1.6__os_mg04_particulars_for_the_registration_of_a_charge_to_secure_a_series_of_debentures_for_an.mjs.ppmraw.72.0.log | 12:01.39 |
| 4 temp/tests_private__pdf__forms__v1.6__rs01_ob2x6.mjs.ppmraw.72.0.log | 12:01.39 |
| 4 temp/tests_private__pdf__forms__v1.6__se_fm02_cont3_corporate_member_appointments.mjs.ppmraw.72.0.log | 12:01.40 |
| 4 temp/tests_private__pdf__forms__v1.6__se_fm05_cont1_member_appointment.mjs.ppmraw.72.0.log | 12:01.40 |
| 4 temp/tests_private__pdf__forms__v1.6__ucare_pretrip_request.mjs.ppmraw.72.0.log | 12:01.41 |
| 4 temp/tests_private__pdf__forms__v1.7__nonemployeetravel.mjs.ppmraw.72.0.log | 12:01.41 |
| 7380 temp/tests_private__pdf__forms__v1.6__2009tanshin_2.mjs.ppmraw.72.0.log | 12:01.42 |
| 138400 temp/tests_private__pdf__forms__v1.6__oft982.mjs.ppmraw.72.0.log | 12:01.42 |
| This one could be a culprit: | 12:02.16 |
| 138400 temp/tests_private__pdf__forms__v1.6__oft982.mjs.ppmraw.72.0.log | 12:02.17 |
| The other nodes have different file lists | 12:02.44 |
Robin_Watts | paulgardiner: Yeah, try running mujstest on that file locally. | 12:03.19 |
paulgardiner | Yeah great. Thanks for the help | 12:03.36 |
Robin_Watts | I hate android makefiles :( | 12:03.49 |
paulgardiner | I've changed the annotation loading loop. Perhaps it can now fail to terminate in error conditions (although I've pored over it) | 12:05.06 |
Robin_Watts | Gah. It seems this version of the NDK is incapable of building in debug mode :( | 12:14.08 |
kens | o.O | 12:15.31 |
Robin_Watts | Ah, it can't cope with inline assembler in debug mode. sheesh. | 12:20.44 |
paulgardiner | That's better: happy cluster | 12:50.19 |
kens | what was hte problem ? | 12:51.26 |
paulgardiner | As per my suspicions, I'd caused the annotation-loading loop to fail to terminate in one of the error conditions. | 12:52.23 |
kens | ah.... | 12:53.07 |
Robin_Watts | I can work around the inline assembler problems by moving the assembly functions to the end of the files. | 13:06.49 |
chrisl | reboots | 13:17.00 |
henrys | chrisl:I think it reasonable the new directory structure which hopefully will lead to a new language switch setup should be worked on to the exclusion of other stuff other than customer bugs. I saw the customer request and just slapped myself, we should have had this top priority earlier. | 13:25.46 |
chrisl | henrys: a new language switch build won't "fall out" of the revised directory structure / build - it will hopefully make it a little easier, though | 13:27.23 |
Robin_Watts | argh. no, even moving the assembly to the end of files doesn't help. | 13:30.45 |
henrys | no it doesn't fall out but for all practical purposes it is prerequisite. I guess we could cobble something together for them now but that would just change with the new structure. | 13:31.26 |
chrisl | henrys: I'm concerned about rushing such a large change | 13:32.04 |
Robin_Watts | So, modern ARMs can either run in ARM mode or in THUMB mode. (THUMB mode being 16 bit instructions that are less powerful than ARM ones, but are used for code density). | 13:32.17 |
| Typically for mobile devices, we build in thumb mode. but my inline assembler is all in ARM mode (as I need the extra facilities given by ARM mode to get me the speed I need). | 13:32.59 |
henrys | chrisl:what could possibly go wrong ? ;-) | 13:33.03 |
Robin_Watts | So my assembly has little 'change to ARM mode' and 'change back from ARM mode' sections around it. | 13:33.30 |
chrisl | henrys: can I refer you to what happened when I changed the tiff configure to run in its own directory?? | 13:33.41 |
Robin_Watts | The compiler it seems starts to output ARM code after my function, rather than thumb code, so the assembler gets confused. | 13:34.28 |
| What the hell have google broken to do this? | 13:34.38 |
henrys | anyway there is no need to rush, I was just hoping it could be treated as higher priority. | 13:36.12 |
chrisl | henrys: I will make it my main task | 13:36.27 |
Robin_Watts | tor8: ping | 13:37.54 |
| oh, no tor. | 13:38.31 |
henrys | when we do have a large change like that we should really have the entire staff try and break the code, QA is not one of our strong suites. I've worked at companies that had testing people that could unearth all sorts of stuff before shipping. | 13:38.35 |
chrisl | henrys: that often works because the QA people approach from a point of ignorance (not in a bad way, in this case) - it's harder for developers to do that | 13:41.06 |
sebras | chrisl: it also depends on the developer put on the devil horns and really _want_ to break to code. | 13:41.56 |
chrisl | sebras: I find it *very* hard to think of the kinds of totally illogical things to try that really good QA people manage with apparent ease | 13:43.13 |
henrys | I do think some folks have a knack for it. | 13:43.44 |
Robin_Watts | We should hire our parents to do QA. | 13:44.04 |
chrisl | Robin_Watts: that would be end of our productivity...... | 13:44.57 |
Robin_Watts | but my parents can break ANYTHING technological. | 13:45.21 |
chrisl | Robin_Watts: exactly, we'd *never* get anything new done, EVER | 13:45.55 |
paulgardiner | My parents aren't so bad: usually within a couple of minutes they have the mouse pointer stuck in a corner away from anything dangerous they might click on; hence they don't often break anything. | 13:53.39 |
chrisl | Actually, may parents are very good at breaking technology, but can *never* repeat the sequence of actions to produce the breakage - limited use for QA | 13:56.50 |
Robin_Watts | paulgardiner: poposed android fix on robin/master - want to give it a try? | 14:18.50 |
paulgardiner | Robin_Watts: yeah great ta. | 14:19.15 |
| "../../include/mupdf/fitz/context.h:10:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef'" :-( | 14:22.40 |
Robin_Watts | oops. | 14:23.03 |
| I know what that is :) | 14:23.09 |
| New version up there, sorry! | 14:24.14 |
paulgardiner | ta | 14:24.50 |
sebras | Robin_Watts: did you inted to remove draw-scale.c? | 14:25.53 |
Robin_Watts | sebras: I did. | 14:26.00 |
sebras | why? | 14:26.15 |
Robin_Watts | For ages we've had draw-scale and draw-simple-scale | 14:26.36 |
| and draw-scale offers no real advantage over draw-simple-scale. | 14:26.50 |
| and I'm sick of forgetting to update one and not the other. | 14:27.02 |
sebras | ok, but why did we use to have two? | 14:27.20 |
| I though that one was more efficient than the other on small systems..? | 14:27.37 |
Robin_Watts | sebras: draw-scale used to use integers rather than bytes as intermediate values. | 14:27.41 |
| and as such could cope with filters that produced out of range values with clamping etc. | 14:28.05 |
| but we never use it, so why take the pain of having 2 versions? | 14:28.23 |
sebras | ok. makes sense. | 14:28.53 |
paulgardiner | Robin_Watts: android patch works great | 14:36.13 |
Robin_Watts | paulgardiner: Have you looked at it (i.e. can I consider it reviewed) or have you just tried it out ? | 14:36.45 |
paulgardiner | Just tried it. I'll look now | 14:37.02 |
| Looks good to me | 14:39.38 |
Robin_Watts | thanks, pushed. | 14:53.34 |
| Hmm. mupdfwrite appears to be putting PNGs into a PDF file. How did I manage that? :) | 14:55.14 |
| Oh, I see. PNGs in from xps, and I'm not converting them to something that PDF speaks. | 14:59.18 |
| I just converted the xps spec to pdf, and when I load it into acrobat reader it tells me "signature field(s) detected" | 15:03.27 |
| paulgardiner: ^ | 15:03.32 |
paulgardiner | Converted using what? | 15:04.36 |
Robin_Watts | mupdf :) | 15:04.46 |
paulgardiner | Oh!!!! | 15:04.52 |
| How on earth?.... | 15:05.17 |
Robin_Watts | not a clue :) | 15:06.00 |
paulgardiner | It's not like I've event gotten to the stage of adding code for creating signatures | 15:06.23 |
Robin_Watts | I think acrobat is being dumb. | 15:06.51 |
paulgardiner | Robin_Watts: Is it still "V8_BUILD=yes"? | 15:17.53 |
Robin_Watts | That's what I've been using :) | 15:18.07 |
| Though I can't see that in the Makefiles :( | 15:18.52 |
| oh, in the android makefiles. d'oh. | 15:19.21 |
| Yes, still V8_BUILD=1 | 15:19.45 |
paulgardiner | Ta. Thought I saw discussions concerning changing it | 15:20.03 |
Robin_Watts | ray_laptop: Morning. | 15:21.51 |
| Did you get your git woes sorted? | 15:21.56 |
ray_laptop | Robin_Watts: morning. | 15:21.59 |
| nope. | 15:22.03 |
Robin_Watts | I can get to your git just fine. | 15:22.16 |
ray_laptop | my GIT_SSH is plink | 15:22.20 |
Robin_Watts | which makes it sound like it's a problem with your authentication/ssh stuff. | 15:22.33 |
ray_laptop | and I can plink to ghostscript.com | 15:22.41 |
Robin_Watts | git remote -v | 15:22.50 |
ray_laptop | cluster regression@ghostscript.com:/home/regression/cluster/gitbridge/ghostpdl (fetch) | 15:23.52 |
| cluster regression@ghostscript.com:/home/regression/cluster/gitbridge/ghostpdl (push) | 15:23.53 |
| origin ray@ghostscript.com:/home/git/ghostpdl.git (fetch) | 15:23.55 |
| origin ray@ghostscript.com:/home/git/ghostpdl.git (push) | 15:23.56 |
| personal ray@ghostscript.com:/home/ray/repos/ghostpdl.git (fetch) | 15:23.58 |
| personal ray@ghostscript.com:/home/ray/repos/ghostpdl.git (push) | 15:23.59 |
Robin_Watts | plink ray@ghostscript.com | 15:24.19 |
henrys | have an appointment bbia 2 hours | 15:24.38 |
ray_laptop | hmm.. this is interesting: plink ray@ghostscript.com fails with: | 15:25.07 |
| FATAL ERROR: Disconnected: No supported authentication methods available | 15:25.09 |
| but plink @ghostscript works | 15:25.10 |
| I have a saved session named "ghostscript". plink ray@ghostscript also works | 15:25.57 |
Robin_Watts | What saved sessions do you have under putty? | 15:25.57 |
ray_laptop | do I need to save a session "ghostscript.com" ? | 15:26.56 |
Robin_Watts | I have a saved session called "gs" that connects to "robin@ghostscript.com" | 15:27.16 |
| What does your "ghostscript" session connect to ? | 15:27.29 |
ray_laptop | ghostscript.com | 15:27.43 |
Robin_Watts | Make it connect to ray@ghostscript.com ? | 15:27.55 |
| or (to be safe) create another one that does so. | 15:28.16 |
ray_laptop | well, it has user name set to "ray" i.e., it doesn't prompt for "login as:" | 15:28.29 |
Robin_Watts | I like "gs" cos it means I can: "pscp blah gs:" | 15:28.33 |
| ray_laptop: I can only assume it's doing a simple textual match. | 15:28.48 |
| Is your username on the windows host "ray" or "Ray" ? | 15:29.09 |
ray_laptop | "ray" | 15:29.17 |
| I'll try cloning the ghostscript into ghostscript.com | 15:29.52 |
| ah. that fixed it | 15:30.51 |
| git works now. | 15:31.32 |
Robin_Watts | fab. | 15:32.00 |
ray_laptop | thanks, Robin_Watts. I guess I must have cleaned up my saved putty sessions too much | 15:32.22 |
Robin_Watts | np. | 15:32.27 |
| ssh setups are always fragile it seems. | 15:32.37 |
mvrhel_laptop | hmm clearly I have broken something in the world of DeviceN handling with my overprint simulation stuff. have to run an errand now. bbaiw | 16:22.27 |
Robin_Watts | Ok, it's friday afternoon. Can anyone see what's wrong with http://ghostscript.com/~robin/out2.pdf ? | 16:29.35 |
kens | Works in Firefix using pdf.js | 16:30.25 |
Robin_Watts | acrobat doesn't like it. | 16:30.43 |
kens | one moment then | 16:30.51 |
Robin_Watts | There should be an image on the page. | 16:31.01 |
kens | I see a triangle in pdf.js | 16:31.11 |
Robin_Watts | right, it's an image of a triangle :) | 16:31.21 |
kens | Acrobat says no | 16:31.22 |
| No /BPC in the image | 16:31.56 |
| Ghostscript FTW :-) | 16:32.24 |
Robin_Watts | Thanks. | 16:33.05 |
ray_laptop | mvrhel_laptop: thanks for the code review. I just pushed the commit (and sent the change to the customer) | 16:41.48 |
| I am worried that the customer seems to have made a fair amount of changes in 9.06 and we are adding features for them in HEAD. So far I guess they're OK with doing this, but ... | 16:43.06 |
mvrhel_laptop | I am sure it will come back to bite us.... | 16:49.39 |
Robin_Watts | Hi tor8. | 16:54.14 |
| paulgardiner, tor8, sebras: robin/pdfwrite contains a first version of the pdfwrite device. | 16:54.53 |
| I'd like to get it committed to avoid continual rebasing. | 16:55.06 |
tor8 | Robin_Watts: rename draw-simple-scale to draw-scale now that the original draw-scale is gone? | 16:56.45 |
Robin_Watts | tor8: seems fair. | 16:56.56 |
tor8 | Robin_Watts: why %f instead of %g? | 16:58.36 |
Robin_Watts | %g puts 0.1e-9 | 16:58.49 |
| and stuff like that. | 16:59.07 |
tor8 | %f always puts 6 digits even if unneccessary, IIRC | 16:59.09 |
Robin_Watts | It does, but the use of exponents makes %g useless. | 16:59.23 |
tor8 | is 0.1e-9 invalid pdf? | 16:59.25 |
Robin_Watts | it is. | 16:59.28 |
tor8 | rats. | 16:59.31 |
| Robin_Watts: I'd like to go through the pdf write device in more detail eventually, but go ahead and drop it into master now. | 17:05.56 |
Robin_Watts | tor8: Sure. | 17:06.06 |
| I suspect I may need to talk to you about fonts etc. | 17:06.25 |
tor8 | fz_write_document and options don't really belong in fitz, unless you plan on abstracting that to work with cbz and xps as well | 17:06.32 |
| I didn't see any use of the begin_page/end_page calls in that code either, I guess that's on your todo list? | 17:06.54 |
Robin_Watts | tor8: it is abstracted. | 17:07.09 |
| tor8: and indeed, I had forgotten about that, as this code predates it. | 17:07.25 |
tor8 | I'm not convinced an abstraction that only works for pdf is all that useful | 17:07.59 |
Robin_Watts | The abstraction doesn't cost us much. | 17:09.06 |
| but again, this predated our stripping out of pdfinteractive. | 17:09.31 |
| fz_interactive even. | 17:09.42 |
ray_laptop | OK, so down to 1 (hard) issue for cust 801 | 18:00.50 |
| oh, great. Cust 532 turned up an issue with a fix that chrisl or I gave them March 2012 :-( | 18:46.47 |
talexb | I'm trying to get gs to create a PDF for me with the pdfwrite device driver .. but all I get is '**** Unable to open the initial device, quitting.' | 19:28.08 |
Robin_Watts | talexb: What command line? | 19:28.28 |
talexb | Yes pdfwrite is listed in the available device drivers. | 19:28.31 |
Robin_Watts | gs -sDEVICE=pdfwrite -o out.pdf in.ps ? | 19:28.41 |
talexb | Robin_Watts, Ubuntu linux .. | 19:28.42 |
Robin_Watts | talexb: Right, but what is the actual command you're calling... | 19:29.01 |
talexb | I was originally just trying to do a proof-of-concept, writing some Postscript commands to gs by way of stdin .. | 19:29.36 |
| if I run gs interactively with no arguments, I see a page image -- all is fine. | 19:30.27 |
Robin_Watts | well, get it working the normal way first, then try that. | 19:30.31 |
| write your ps into a file, remember to call showpage. Then try the above command line on that. | 19:30.51 |
talexb | OK, I'll try your command line .. thanks! | 19:30.58 |
| Hmph. Worked fine. | 19:32.41 |
| So I was originally using 'sOUTPUT_FILE=test1.pdf' to define my output file .. perhaps gs wants the '-o test1pdf' argument format instead. | 19:34.20 |
| Although I don't understand why gs complains that it's unable to open the initial device. | 19:34.37 |
| Robin_Watts, Thanks for your help, I appreciate it. I'll have to do further investigation -- that's OK, I've just got started. | 19:36.33 |
Robin_Watts | -sOUTPUTFILE=, not -sOUTPUT_FILE= | 20:00.58 |
marcosw | henrys: are you available? | 20:15.36 |
Robin_Watts | marcosw: Congratulations, by the way. | 20:21.53 |
marcosw | Robin_Watts: thanks, touch I'm still not technically done. after to go through my defense later this summer | 20:28.35 |
talexb | Robin_Watts, Oh good grief. | 20:29.22 |
| Thanks, I made that fix, and now my test program works perfectly. | 20:30.13 |
Robin_Watts | talexb: Fab. | 20:35.56 |
talexb | :) IRC never ceases to maze me. And I hope I can return the favour in the future. | 20:40.54 |
henrys | marcosw:I'm back now. | 20:43.05 |
marcosw | henrys: I'm back as now as well. | 22:09.43 |
henrys | I'm back from being back | 22:32.23 |
| ;-) | 22:32.29 |
| marcosw:what did you want? | 22:32.52 |
marcosw | henrys: Just wanted to let you know that we can take Alex's node out of the cluster. I have a one new hex-core machine online and a second dual xeon will be up soon. | 23:04.32 |
Dan1973 | hi all. Anyone knows if muPDF suports displaying the Toc and what keybinding can be used ? | 23:18.08 |
| Forward 1 day (to 2013/06/22)>>> | |