| | <<<Back 1 day (to 2015/10/26) | 20151027 |
| chrisl | Feeling any better kens ? | 08:33.42 |
| kens | chrisl, I have an appointment with the GP at 10:40 | 08:33.59 |
| chrisl | Holy cow! Did you tell them you were bleeding to death?? | 08:34.28 |
| kens | I have an 'alarming' symptom | 08:34.34 |
| | Well its alarming to me | 08:34.46 |
| | Right testicle is swollen and tender, 2x normal size last night 3-4 x normal ths morning | 08:35.20 |
| chrisl | Oh, that is alarming! | 08:35.38 |
| kens | :-( | 08:35.45 |
| | I *think* its probbly an infection, but I'm no doctor.... | 08:36.09 |
| | At the moment I'm expecting a course of antibiotics, hopefully tht will cure it | 08:36.43 |
| chrisl | Well, there is some kind of gastric nastiness going around here - I and several people I know have been floored by it | 08:37.08 |
| kens | :-( I don't (now) thnk this is gastric, its just that the discomfort came on really suddenly and initially felt like an abdominal pain (plus a raging fever) | 08:38.07 |
| | A couple of nurofen sorted the temperature out (eventually) and then I could assess the other symptoms properly | 08:38.42 |
| | I see there was a lengthy discussion about devices and interpreters last night, just reading through itr | 08:39.22 |
| chrisl | Mostly a repeat of the conversation in the last but one staff meeting - as I pointed out | 08:39.47 |
| kens | Yeah, its quite a long discussion though | 08:40.06 |
| | I thnk this would be better handled in person | 08:40.15 |
| henrys | geez kens sorry to hear that. | 08:40.15 |
| kens | henrys shouldn't you be in bed ? | 08:40.23 |
| henrys | yeah just woke up for a bit. | 08:41.27 |
| kens | It 'might' be possible to have currentdevice and friends work with a shared device, I'd have to debug through the PostScript startup code again. I *think* It interrgoates the device to build the initial dictoinary, so that would be OK (provided we run the startup code every time we run the PS interpreter) | 08:42.11 |
| henrys | I'm not a good sleeper during the off season. During tri season and I'm out like a bear. | 08:42.47 |
| kens | Exhaustion will do that :-) | 08:42.59 |
| chrisl | kens: The problem would be prompting it to happen at the appropriate time - we have the initial setting up of pdfwrite to content with, then the setting of the actual device | 08:43.49 |
| kens | Yes we would have to rerun *all* the PostScript startup code from cold every time we switched to the PS interpreter | 08:44.22 |
| | I'm not sure that would be popular | 08:44.31 |
| chrisl | Well, if we take initial device setting out of Postscript, then we have no choice, anyway | 08:46.42 |
| kens | I suppose that's true | 08:46.52 |
| chrisl | Even without the cockeyed implementation of set/currentpagedevice | 08:47.28 |
| kens | Yes agreed. I can't see an alternative. I *thnk* the set/currentdevice is done that way for performance reasons (because getparams is so slow), I may be wrong | 08:48.19 |
| | It *is* horrible though | 08:48.32 |
| chrisl | Sure, but to ensure the device is correctly in the graphics state and so forth, I think we'd have to go through the Postscript, even without the getparams bottleneck (although, it would probably render the problem moot in practice) | 08:50.20 |
| kens | Yes I'm sure we would have to do so | 08:50.43 |
| chrisl | One thought I had was that we could have a custom key in systemdict, (optionally) setup during initialisation which contains the *actual* device to use, and we would check for that entry before looking up device names, etc as we normally do | 08:52.02 |
| kens | Hmm, that might actually work, bit of a kludge, but anythign we do now will be | 08:52.35 |
| chrisl | The equivalent of something like "-dACTUALDEVICE=<memory address>" | 08:52.46 |
| | At the moment, we run into problems with devices in non-gc memory because of the garbage collector - it will do it's mark and sweep expecting the gc-style memory header, which isn't there in the case of, for example, the chunk allocator. So it will trample on memory it shouldn't | 08:58.23 |
| kens | Oh, that's not good | 08:58.41 |
| henrys | chrisl: I also wonder about that what if everything did have headers? i.e. the no_gc stubs were added to each chunk allocation? | 08:59.56 |
| | s/wonder/wondered | 09:00.27 |
| chrisl | henrys: I'm not sure how viable that would be for the heap allocator, but I don't really know | 09:01.21 |
| | henrys: but, nevertheless, it still leaves the issue of the garbage collector potentially wanting to relocate or free memory for which it is not responsible | 09:02.20 |
| henrys | chrisl: it's been so long since I've looked at it. I can' remember but I thought if we used the used gs_no_struct_reloc_ptrs we'd be okay but that may be wrong | 09:07.20 |
| chrisl | henrys: but we don't have a way to know whether to use a real relocptrs or gs_no_struct_reloc_ptrs at run time | 09:13.40 |
| henrys | chrisl: I need to step through it to understand it, but the chunk allocator must be preventing its allocation from being collected now. The multithreaded stuff wouldn't work if that were not so right? | 09:25.35 |
| chrisl | henrys: no, because during multithreaded rendering, during the life of the "child" devices in each thread, the garbage collector will *never* run - since the garbage collector must be triggered from the interpreter, and multi-threaded rendering completes without ever returning to the interpreter | 09:27.45 |
| | And even then, I'm not sure those "child" devices are allocated outside of gc memory | 09:28.52 |
| | Okay, yes, the child devices are allocated from the chunk allocator - but my other point holds true | 09:31.37 |
| | henrys: most or all of these issues can be dealt with. *BUT* I'm keen that we should avoid making a already complex and delicate areas for Ghostscipt even more complex and delicate - especially as I suspect, useful though it will be, the language switching will remain a fairly niche product compared to Ghostscript | 09:35.51 |
| | s/a already complex and delicate areas/an already complex and delicate area | 09:36.18 |
| chrisl | thinks it's bad that my typing is falling apart at only 9:30 am :-( | 09:36.38 |
| henrys | I think I can sleep now, yeah! - good night all | 09:45.24 |
| halabund | Is there a reliable way to detect the location of the Ghostscript command line executable on Windows? | 09:45.25 |
| kens | gnight henrys | 09:45.31 |
| chrisl | henrys: goodnight | 09:45.33 |
| kens | halabund : If you installed it it will be in the registry I thnk | 09:45.46 |
| | If you didn't install it, then no | 09:46.01 |
| chrisl | I don't know how much flexibility there in interrogating the registry - are wildcards allowed? | 09:48.05 |
| kens | I think not | 09:48.15 |
| | But I'm not certain | 09:48.21 |
| | Don't we write everything under th same key ? | 09:48.48 |
| chrisl | Then that could be a problem, since our registry entries include the version number | 09:48.56 |
| halabund | OK, that was going to be my next question. | 09:49.12 |
| kens | Well then I guess you'd need to search for all the possible version numbers :_) | 09:49.23 |
| chrisl | HKEY_LOCAL_MACHINE "Software\GPL Ghostscript\${VERSION}" | 09:49.32 |
| kens | Yeah so if you find the GPL Ghostscript key you shoudl be able to enumerate the sub-kys | 09:50.23 |
| chrisl | Right, then you can get the "GS_DLL" key, drop the .dll file name from the end, and that gives you the path to the executable - a bit hacky, but would work | 09:51.48 |
| halabund | Thanks! | 09:52.16 |
| chrisl | Or you could look for the shortcuts in the Start menu, but that's likely more error prone | 09:52.38 |
| kens | OpenRegistry key then RegKeyEnumEx | 09:52.51 |
| | SOrry RegEnumKeyEx | 09:53.12 |
| | Then check the highest number subkey you find (or are prepared to deal with) | 09:53.46 |
| | Of course if Ghostscrip isn't 'isntalled' then this won't work | 09:54.00 |
| chrisl | Oh, actually, maybe you don't need the string hacking with the DLL file name..... | 09:54.17 |
| kens | GS_LIB stgarts with the bin folder apparently | 09:54.58 |
| chrisl | kens: I'd be wary about that since people do change it | 09:55.27 |
| kens | Yeah, I'd be doubtful that was reliable | 09:55.40 |
| | OK I'll be out for an hour or so. Back in a bit, hopfully | 09:58.08 |
| chrisl | Good luck! | 09:58.15 |
| kens | 918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>918839816 <<#942541-6558177#>>:918839816 <<#942541-6558177#>>-( | 09:58.19 |
| | OOps | 09:58.23 |
| chrisl | I'm guessing that was some sort of swear word in a multi-byte encoding....... | 09:58.54 |
| tor8 | Robin_Watts: ping. | 10:30.07 |
| | Robin_Watts: I've got an idea for the bugzilla commit SHA stuff. | 10:30.26 |
| Robin_Watts | look at the component ? | 10:30.38 |
| tor8 | it's not ideal, but we could set up a special git repository that contains both ghostpdl/master and mupdf/master that the bugzilla redirects to | 10:30.52 |
| | like artifex.git | 10:31.00 |
| Robin_Watts | tor8: urk. | 10:31.07 |
| tor8 | so one repo that holds both projects in different branches | 10:31.21 |
| Robin_Watts | Better to redirect to a cgi-bin that looks up and redirects to the real one. | 10:31.36 |
| tor8 | yeah, that would work too | 10:31.48 |
| | possibly better | 10:31.53 |
| | just a loop to query which git repo has a given commit, should be fast | 10:32.07 |
| Robin_Watts | yeah. speed is less important there, cos it doesn't have to happen every time we format a comment for the screen. | 10:32.43 |
| tor8 | git cat-file -t <sha1> | 10:33.07 |
| | if it says 'commit' we have it, if it returns a status code, we don't | 10:33.33 |
| Robin_Watts | My emails to Raed are being blocked. | 10:40.23 |
| | 212.118.29.133 does not like recipient. | 10:42.36 |
| | Remote host said: 550 5.7.1 Recipient not authorized, your IP has been found on a block list | 10:42.37 |
| | It's spamhaus being officious. | 10:45.08 |
| tor8 | Robin_Watts: okay, I've got a cgi-script that should work | 10:53.51 |
| | http://ghostscript.com/regression/cgi-bin/findgit.cgi?SHA1 | 10:54.38 |
| | Robin_Watts: where is your hack to bugzilla so I can update that to point to my new cgi-script? | 10:59.43 |
| Robin_Watts | Let me look. | 11:01.11 |
| | oh, ass. bugzilla is not on casper any more is it ? | 11:02.30 |
| | So we'll need marcos to edit that. | 11:02.41 |
| kens2 | morning marcosw | 14:17.44 |
| henrys | kens2: so you'll be joining us and all's well? | 14:18.15 |
| marcosw | morning kens2 | 14:18.57 |
| kens2 | henrys hte doc says its n infection | 14:19.46 |
| | given me a 2 week course of high does penicillin and an anti-inflammatory, both sets of tablets sized to choke elephants | 14:20.22 |
| | says I should see some imprtovement in 2 days :-( | 14:20.38 |
| | In the meantime, I'm sitting down as little as possible | 14:20.51 |
| kens2 | obviously needs a standing desk | 14:22.17 |
| henrys | kens2: pain killers? | 14:25.02 |
| kens2 | I cna take paracetamol, have to avoid Ibuprofen, cos its the same NSAID as the anti-inflammatory | 14:25.27 |
| | and codeine is allowed :-) | 14:26.14 |
| henrys | kens2: you can fly here and smoke dope, but it probably wouldn't be worth the trip. | 14:26.56 |
| kens2 | I don't thnk I'd enjoy the journey, too long sitting down, better to go to an Amsterdam coffee shop | 14:27.30 |
| henrys | marcosw: now that I have a new machine I wanted put it on the cluster and I forget the easiest way to do that. | 14:28.04 |
| marcosw | there are instructions on casper in /home/regressioncluster/readme | 14:29.01 |
| henrys | marcosw: perfect thanks | 14:29.15 |
| marcosw | i think they are still correct :-) | 14:29.15 |
| henrys | so customer bugs have bumped up a bit but that's all sot stuff | 14:30.35 |
| marcosw | or you can give me an account and I'll log in and do it. You'll need to do the apt-get install bits in step 0 or give me (temporary) sudo privs. | 14:30.56 |
| rayjj | chrisl: kens: I think something you mentioned before is the key to why BGPrint and NumRenderingThreads are a problem. BGPrint runs while the interpreter is active, so GC can run while it is rendering, and multi-threaded rendering expected the GC to not run. | 14:32.19 |
| kens2 | that wqold be Chris' comment earlier | 14:32.42 |
| rayjj | chrisl: kens: I'll have to ruminate on this, but thanks for the hint | 14:32.42 |
| chrisl | rayjj: possibly.... I wouldn't have thought the devices for BGPrint would be visible from and/or to the garbage collector | 14:33.36 |
| rayjj | kens2: right. the two of your were having a discussion re sharing a device | 14:33.57 |
| chrisl | And for everyone: I'm not really sure what to do about: http://bugs.ghostscript.com/show_bug.cgi?id=693011 | 14:34.11 |
| rayjj | chrisl: which is why I have to think about it | 14:34.31 |
| kens2 | not allow mulit-page output | 14:34.33 |
| chrisl | kens2: Yes, but we have no way to do that currently | 14:34.47 |
| kens2 | Well, what I meant was define it as workign that way | 14:35.02 |
| henrys | rayjj: why would anything allocated by the chunk allocator be subject to gc, the language switch would die immediately if that were the case. | 14:35.08 |
| kens2 | If you want multple pages you have to use %d | 14:35.14 |
| chrisl | kens2: at the moment, even the pnm devices will write multiple pages to the one output file | 14:35.47 |
| | You can't view them , but...... | 14:36.00 |
| rayjj | chrisl: kens2: for PSD, if they don't have %d in the output, we should issue a warning to use it (on the second page) and abort. | 14:36.12 |
| kens2 | Yes, is that a problem ? I would just put that in the documentation for psd | 14:36.18 |
| | Or as ray says, | 14:36.30 |
| chrisl | rayjj: That sounds like a good plan | 14:36.45 |
| rayjj | just as long as a single page input file runs ok without %d :-) | 14:37.18 |
| chrisl | marcosw: will that break the cluster? | 14:37.27 |
| rayjj | hadn't thought about the cluster | 14:37.47 |
| chrisl | And, as I said, the same problem actually exists for ppm, pgm, pkm etc..... | 14:38.03 |
| rayjj | does it run psdcmyk ? | 14:38.05 |
| chrisl | psdcmyk is tested regularly, whether by the cluster or the weekly tests | 14:38.40 |
| rayjj | chrisl: some apps tolerate concatenated ppm's since after each one there is a new header with the dimensions for the next page | 14:38.50 |
| kens2 | regression runs test psdcmykl | 14:38.53 |
| chrisl | rayjj: Oh, really? None of the apps I tried worked, they only displayed the first page | 14:39.28 |
| henrys | marcosw: feel free to just say no to this... but the idea of doing coverage for the languages was to see what we are testing, but I don't think we are actually accumulating all the tests we do right? It looks like your coverage is just from one run? I'm wondering what it takes to create a coverage report that shows *all* the tests you do. | 14:39.31 |
| marcosw | chrisl: probably :-) | 14:39.32 |
| rayjj | so ppm's don't have the page size problem that a PSD does | 14:39.34 |
| henrys | chrisl: how did you get that bug? | 14:40.09 |
| chrisl | henrys: I fixed a very similar problem with the TIFF devices | 14:40.28 |
| marcosw | chrisl: if I understand the question you (or someone) is proposing to modify psdcmyk to output the first page on multi-page documents (rather than the last page, which is how it works now). Is that correct? What about psdrgb? That device currently output multi-page psd files but as we discussed in the bug report it doesn't seem like those are legal files. | 14:42.01 |
| henrys | mvrhel_laptop: how's the bug you started yesterday? | 14:42.07 |
| mvrhel_laptop | henrys: I fixed the slow shading fill issue | 14:42.24 |
| | working now on this wacky psdcmykog bug | 14:42.32 |
| Robin_Watts | kens: Just read logs. OUCH. epididymitis? | 14:42.47 |
| marcosw | chrisl: concatenated ppm's are documented in the spec, though I agree, the are not well supported. I'm pretty sure Image Alchemy can read them (and maybe ImageMagick). | 14:43.35 |
| kens2 | Robin_Watts : no apparently an infection, see above | 14:43.56 |
| chrisl | marcosw: at the moment, we actually write all the pages to the psd file, just so happens that due to how psd files are parsed, only the last page is displayed. The proposal is that if you try to print more than one page without a %d you get an error | 14:44.17 |
| henrys | fredross-perry: are you pretty well filled up with the NUI? If you need a break from that you can jump into mupdf stuff. | 14:45.30 |
| mvrhel_laptop | henrys: its http://bugs.ghostscript.com/show_bug.cgi?id=696227 and I should have it wrapped up today. I have a clist dump for psdcmyk vs psdcmykog and it is interesting. the diffs are that there is a chunk of missing in the psdcmykog clist output that is about 1/2 the file. | 14:45.50 |
| fredross-perry | I am full of NUI yes. | 14:45.50 |
| henrys | everybody please have a look at the coverity bugs they are finding some interesting new stuff, I've got a few to work on too. Perhaps the copy-paste bugs are the most interesting. I'm curious how that algorithm works. | 14:47.03 |
| fredross-perry | henrys: I have some unfinished business in gsview related to proofing which I could wrap up I think with help from mvrhel. | 14:47.04 |
| rayjj | mvrhel_laptop: when I ran the -ZL output, I saw 4 rendering passes with psdcmyk and only one with psdcmykog, but I didn't get any diffs on the first pass | 14:47.50 |
| henrys | kens2: I doubt you should be standing or sitting. Go back to bed, christ... | 14:48.47 |
| kens2 | Bed isn't great either :-( | 14:48.57 |
| mvrhel_laptop | kens2: yes that sounds like ice would be a good idea | 14:49.13 |
| kens2 | I just need to keep shifting about | 14:49.21 |
| Robin_Watts | You can have an utterly legitimate rummage at any point without people being able to tell you off. | 14:49.43 |
| kens2 | ON IRC nobody can hear you scream | 14:50.00 |
| rayjj | kens2: I thought that was what the comment above was: 918839816 <<#942541-6558177#>>... | 14:51.14 |
| henrys | I didn't have anything else for the meeting. Anybody else? | 14:51.17 |
| marcosw | chrisl: no we don't (at least not for all files). The output from the test file attached to http://bugs.ghostscript.com/show_bug.cgi?id=696265 when writing psdcmyk is 2423632 bytes. If you do a -o test%d.psd thats the size of the test4.psd, the last page. | 14:51.24 |
| kens2 | rayjj that's a DELL tracking number, its my cxut and paste bug again... | 14:51.43 |
| | CLassic: | 14:51.59 |
| | http://www.bbc.co.uk/news/world-us-canada-34644333 | 14:51.59 |
| chrisl | marcosw: Hmm, that is.... odd - it's not what the code *seems* to be doing..... | 14:52.05 |
| rayjj | chrisl: maybe it rewinds or seeks in the output file ??? | 14:52.25 |
| marcosw | chrisl: for many (most) files it write out the all the pages, just not for some files. | 14:52.29 |
| chrisl | Oh, yes, that'll be because a setpagedevice changes the page size, so the device is closed and then reopened, along with the output file | 14:53.14 |
| marcosw | anyway, an error when attempting to write multi-page psd files is fine with me. It will report all sorts of md5sum differences for the first run after the commit but shouldn't cause any problems. | 14:54.06 |
| | chrisl: oh, so it's fails for files where all the pages are not the same size? | 14:54.17 |
| kens2 | Yes, that's the problem | 14:54.35 |
| marcosw | the question I was asking is are we going to enforce %d in the output filename for the psdrgb device as well. | 14:54.44 |
| | and my thought is that we should. | 14:54.52 |
| chrisl | marcosw: Yes | 14:54.57 |
| marcosw | an error message is better than a bad output file. | 14:55.08 |
| chrisl | Yes, so it'll print some kind of meaningful-ish error message, and give upi | 14:55.34 |
| | or, possibly, give up.... | 14:55.50 |
| | And psdcmyog for that matter | 14:57.05 |
| marcosw | henrys: sorry, I'm not sure I understand your coverage question. do you want to run coverage for all of the different command line options we regression test weekly (i.e. epscrop)? | 14:57.13 |
| Robin_Watts | marcosw: AIUI, henry wanted one set of results on the web that would show what files/options exercised what lines. | 14:58.12 |
| henrys | kens2: if we were on the bahamas beach now you could put on a speedo and be worshipped as the alpha male ;-) | 14:58.32 |
| kens2 | LOL | 14:58.42 |
| marcosw | chrisl: yeah, psdcmykog too | 14:58.45 |
| Robin_Watts | So given any random line of source, we only need to look in 1 place to find the stuff that exercises it, rather than looking at the gs results, the pcl results, the xps results, etc... | 14:59.10 |
| henrys | marcosw: yes, the coverage for me is to check we are testing everything, I understand line coverage is not path coverage, but it's good data. | 14:59.59 |
| | off to skype. | 15:00.34 |
| mvrhel_laptop | bbiab | 15:01.40 |
| rayjj | chrisl: right, that's in devices/gdevcmykog.c (no mention of psd in the file name) | 15:03.22 |
| | oops. my chatzilla hadn't scrolled, so my comment was rather stale | 15:03.50 |
| chrisl | rayjj: but it did serve a purpose, because you reminded to check - and it looks like psdcmykog depends on psdcmyk but that is not reflected in the makefiles :-( | 15:06.02 |
| rayjj | chrisl: yeah, I suspect there are several broken dependencies. We used to have a tool to analyze for those that we ran pre-release for last minute cleanup | 15:10.01 |
| | but I may be remembering that from a previous job | 15:10.23 |
| kens2 | We've got a new one now, called chris | 15:10.27 |
| chrisl | runs away screaming....... | 15:10.45 |
| | We have a tool that the cluster runs which checks for header dependencies, but I'm not sure it would be practical to build a dependency map of what functions in one file are called from what other file..... that way lies madness, me thinks | 15:12.19 |
| rayjj | chrisl: the one I was thinking of was toolbin/gsmake.tcl check but I'm sure it bit-rotted with the directory changes | 15:15.16 |
| | and my tcl skills are pretty rotted, too | 15:15.54 |
| | I can still (sort of) read it, so it'll come back to me if I need it | 15:16.44 |
| chrisl | As I said, I'm not totally sure that would have caught this one, but my tcl skills are practically non-existent! | 15:17.37 |
| rayjj | chrisl: as far as a 'used by' map, iirc, visual studio does something like that. But then you have to be using VS | 15:17.42 |
| | mvrhel would know about what VS can do | 15:18.17 |
| chrisl | rayjj: there tools that can do that, but translating that into .dev style dependencies (where required) strikes me a a pain, and probably not hugely valuable | 15:19.56 |
| tor8 | marcosw: I've written a CGI script that takes a SHA1 and finds the appropriate git repository it belongs to and redirects to gitweb with the correct project | 15:35.33 |
| | now we just need to (a) put it somewhere publicly accessible (I've put it in the regression/cgi-bin for testing) and then fix Robin_Watts' hack to bugzilla to use it | 15:36.13 |
| marcosw | tor8: great, I can take it from here. | 15:36.37 |
| tor8 | the script is findgit.cgi | 15:36.57 |
| marcosw | tor8: your script is working great. I haven't figured out where it should go, so it's still in regression/cgi-bin. I'll move it in a bit. | 15:52.52 |
| tor8 | yeah, only problem with having it there is requiring the regression dashboard login credentials | 15:53.22 |
| marcosw | I just left it there for testing. | 15:53.49 |
| Robin_Watts | tor8: /usr/lib/cgi-bin ? Or /usr/local/lib/cgi-bin | 15:54.36 |
| marcosw | I think /lib/cgi-bin | 15:54.50 |
| Robin_Watts | OK. | 15:55.05 |
| marcosw | no wait, /usr/lib/cgi-bin is correct | 15:55.09 |
| Robin_Watts | I was surprised to find cg-bin under lib. | 15:55.41 |
| marcosw | yeah, me too. No idea why or who. | 15:55.54 |
| | but as usual, i'm too afraid to change things. | 15:56.04 |
| | (don't get me started about the other weirdness about our apache installation). | 15:56.20 |
| | okay, it's now in /usr/lib/cgi-bin and still seems to work. | 15:57.15 |
| | and that should be weirdnesses, didn't mean to imply only one weirdness | 15:58.07 |
| Robin_Watts | I never thought of wierdness as being an integer thing... | 15:58.42 |
| marcosw | it's like math vs. maths :-) | 15:59.27 |
| | tor8's cgi script even works from internet explorer, will wonders never cease... | 16:01.29 |
| kens2 | http://www.bbc.co.uk/news/world-us-canada-34644333http://www.bbc.co.uk/news/world-us-canada-34644333How about Edge ? | 16:01.48 |
| marcosw | rayjj: have you fixed the dns issue peeved yet? I believe it's just changing the ip addresses in /etc/resolve.conf | 16:04.48 |
| rayjj | marcosw: I think the DNS issue is OK. There is no longer a delay when I log in via ssh | 16:06.36 |
| marcosw | try "pinghttp://www.ghostscript.com" from peeved. | 16:06.49 |
| rayjj | marcosw: it runs really slowly, but the ping time is 74ms | 16:08.01 |
| henrys | marcosw:does the coverage stuff make sense? | 16:08.08 |
| rayjj | from peeves (on the same fiber optic) the ping time is 63ms and it starts and runs faster | 16:08.55 |
| marcosw | rayjj: really slowly is the problem. if you run ping 184.73.189.105 you will see a differences. | 16:09.00 |
| | i believe it's slow because it's going through the name servers in order and the first two are non-existent. | 16:09.46 |
| | henrys: it made more sense until Robin_Watts clarified it for me :-) | 16:10.08 |
| rayjj | marcosw: OK, so I'll remove those from peeved (and peeves) | 16:10.27 |
| henrys | marcosw: oh well I don't need to know the options, I just want to know what's not covered. | 16:10.56 |
| rayjj | I'll re-check with verizon to see what I'm supposed to be using. | 16:11.03 |
| marcosw | rayjj: peeves is fine, it's has a very different /etc/resolve.conf file (putting 8.8.8.8 first, like The Google intended). | 16:11.17 |
| henrys | marcosw: in all the testing we do line number 485 of gdevprn.c doesn't run... that sort of thing. | 16:11.43 |
| rayjj | marcosw: other than 8.8.8.8 first, the other two are the same (non-existent ???) ones as on peeved | 16:11.56 |
| | marcosw: other than 8.8.8.8 first, the other two are the same (non-existent ???) ones as on peeves | 16:12.01 |
| marcosw | rayjj: you are right, the other two are wrong as well. is this related to your recent office move? | 16:12.20 |
| | the third dns server on peeved is peeves, so that seems reasonable. | 16:13.08 |
| marcosw | has been pulling his hair out over a handle leak on windows and turns out it's the Windows Resource Monitor. It's been running for 2 hours and is up to 3935 handles. What the heck is it doing that's consuming all those handles? And why doesn't the Task Manager show the handles column by default? | 16:18.02 |
| | henrys: sorry, distracted by git sha1 redirection, windows handles issues, peeved dns, ghostscript psd out, and something else that I can't recall (and also trying to remember if I ever knew tcl). Will look at the coverage stuff now. | 16:22.07 |
| rayjj | marcosw: OK, peeved is fixed (I think). It responds fast now to pinghttp://www.ghostscript.com, so I re-enabled it | 16:22.27 |
| | marcosw: on the cluster dashboards | 16:22.44 |
| marcosw | now it's using 4135 handles, the madness continues. | 16:22.50 |
| | rayjj: great. Not that one machine made a difference, but it was untidy. | 16:23.05 |
| henrys | marcosw: not a high priority | 16:26.44 |
| marcosw | henrys: the other things weren't either :-) | 16:27.09 |
| henrys | I'm trying to get stupid vmplayer to see my keyboard, everything else seems to work. | 16:27.10 |
| marcosw | henrys: keyboard? how old fashioned. just use the touchscreen. | 16:30.56 |
| henrys | I was pretty impressed with vmware, grabbing a physical windows system and make it into a vm I can run on linux. Everything I want but the damn keyboard works. | 16:33.43 |
| | s/make/making | 16:34.05 |
| kens2 | VMware on windows works just fine, even with vurtual copies of windows, I have several | 16:34.19 |
| marcosw | rayjj: i think you can close <http://bugs.ghostscript.com/show_bug.cgi?id=696254>. The customer has the patch, if they report a problem I'll reopen it. | 16:34.57 |
| henrys | kens2: I have vmware stuff that does work, it's just this copy process has somehow fouled it up. Were you copying a physical system or did you build it from vmware? | 16:35.16 |
| kens2 | I picked up an installed image | 16:35.38 |
| henrys | kens2: see I have all this crap on my windows box that I don't want to reinstall... | 16:36.09 |
| kens2 | Ah well that's where you are going wrong, that never works properly :-) | 16:36.30 |
| henrys | I haven't given up yet. | 16:37.47 |
| | bet it does seem likely to fail | 16:38.01 |
| | in some manner | 16:38.10 |
| kens2 | I always reinstall everything | 16:38.19 |
| henrys | off to cross fit class. be back in a an 1 1/2 hours. | 16:38.43 |
| kens2 | 'enjoy' :-D | 16:38.54 |
| rayjj | mvrhel_laptop: I am running with the debugger on that cmykog problem. I have BandHeight=338 (the default) and in cmykog_process, I see bands at 0, 0x152, 0x2a4, 0x3f6 returning color_usage.or = 0x0a, but for band at 0x548, it return 0x08 | 16:43.02 |
| mvrhel_laptop | rayjj: please dont spend any time on this | 16:43.15 |
| | It is a color usage problem | 16:43.28 |
| | I almost have it solved | 16:43.43 |
| rayjj | mvrhel_laptop: OK. I was going to mention that the data looked reasonable in the magenta band. | 16:43.53 |
| | mvrhel_laptop: color_usage was (iirc) one of my guesses yesterday | 16:44.08 |
| mvrhel_laptop | it has to do with pdcolor being null when clist_write_fill_trapezoid is being called | 16:44.17 |
| | but the trap colors are specified and we dont update the color usuage | 16:44.34 |
| rayjj | but I thought that you had eliminated that by forcing the bands to be generated | 16:44.50 |
| mvrhel_laptop | we only do it for when pdcolor is not null | 16:44.53 |
| marcosw | mvrhel_laptop: I just reopened <http://bugs.ghostscript.com/show_bug.cgi?id=696290>. sorry. | 16:44.54 |
| mvrhel_laptop | rayjj: I thought I had, but it is clear that the color use values are wrong in those bands | 16:45.15 |
| rayjj | mvrhel_laptop: sounds like you have it nailed, then (at least the cause). The solution may take some time | 16:45.40 |
| mvrhel_laptop | marcosw: that makes no sense | 16:45.42 |
| | it ran fine here | 16:45.46 |
| | I will go back and check again | 16:46.02 |
| kens2 | Did you try it in linux ? | 16:46.04 |
| marcosw | are you testing with the correct file? | 16:46.05 |
| mvrhel_laptop | the cluster did | 16:46.08 |
| marcosw | those files were disabled in the cluster, since they timed out. | 16:46.25 |
| mvrhel_laptop | nice | 16:46.34 |
| marcosw | i re-enabled them after your commit. | 16:46.38 |
| mvrhel_laptop | oh I see it is file b | 16:46.56 |
| marcosw | BTW, the problem is with Bug695847b.ps, which is not the original file from the bug report. | 16:46.59 |
| mvrhel_laptop | ok now I understand | 16:47.07 |
| | a file fails that I did not test with | 16:47.16 |
| | nor was it enabled on the cluster | 16:47.23 |
| marcosw | if you add -r300 the error goes away, but the output is blang. | 16:47.27 |
| mvrhel_laptop | ok I will deal with that after I deal with this | 16:47.39 |
| | thanks for checking all of that marcosw | 16:48.16 |
| marcosw | mvrhel_laptop: if the files. had been enabled on the cluster you would have seen Bug695847b.ps change from a timeout to an error, so it would have been helpful. | 16:48.54 |
| mvrhel_laptop | its all good. we are moving forward I believe | 16:49.15 |
| | a crash will be easy to figure out | 16:49.21 |
| | the time out was a pain | 16:49.28 |
| marcosw | mvrhel_laptop: np, they nightly regression tests spotted the problem. I just had to type up the bug report. Hmm, the SmartOffice ATS enters bug reports automatically, I wonder if... | 16:50.06 |
| | ^blang^blank | 16:51.16 |
| | not that blang isn't a fine word. | 16:51.30 |
| | apparently 'blang' is secondhand, stolen, or knocked off 'bling'. | 16:52.18 |
| kens2 | Really ? I had no idea | 16:53.23 |
| marcosw | not to be confused with blång, which is apparently swedish slang for tall and blonde. | 16:53.31 |
| mvrhel_laptop | rayjj: turns out there must be a second place that is checking for color being present other than in cmykog_process. Once I got the color usage values corrected it draws now | 16:53.48 |
| | that is why my override at that spot did nothing | 16:54.05 |
| | anyway I will have a fix shortly for this | 16:54.13 |
| | rayjj: I will have you do a review for this shortly | 16:54.41 |
| marcosw | mvrhel_laptop: with head I see an error when converting Bug695847a.ps to psdcmykog that I don't see with 9.18, so that may be a regression with the last commit as well. | 17:01.36 |
| mvrhel_laptop | odd. ok | 17:01.51 |
| | I will wrap this up and then go back to that | 17:02.03 |
| | thanks | 17:02.05 |
| marcosw | but the psdcmyk output is correct and much faster, so the problem as I reported it is fixed :-) | 17:02.29 |
| | oddly enough the error didn't show up in regression testing, it just generated a blank page. I wonder why... | 17:03.45 |
| mvrhel_laptop | oh that sounds like its going to be a fun one. | 17:05.33 |
| | ok I have this fixed. I will do a regression test on it now | 17:05.47 |
| marcosw | mvrhel_laptop: never mind, ignore the error with Bug695847a.ps issue. that's my problem. | 17:06.16 |
| mvrhel_laptop | ok | 17:06.25 |
| marcosw | mvrhel_laptop: there does seem to be an issue when banding in that the output page is mostly blank, in page mode it's correct. | 17:07.47 |
| mvrhel_laptop | marcosw: oh that might be related to what this fix is for | 17:09.56 |
| | is that for the cmykog device? | 17:10.05 |
| | i mean psdcmykog | 17:10.09 |
| marcosw | yes | 17:10.10 |
| mvrhel_laptop | ok yes, the color usage was not getting updated | 17:10.24 |
| | for the clist | 17:10.28 |
| kens2 | GOodnight all | 17:10.42 |
| mvrhel_laptop | doing a cluster push in a sec to test | 17:10.47 |
| | bye kens | 17:10.50 |
| | hope you are better tomorrow | 17:10.56 |
| marcosw | kens2: night. hope you feel beter | 17:10.56 |
| | too late :-( | 17:11.01 |
| | mvrhel_laptop: there also seem to be regressions with psdcmykog with ps3cet/09-47L.PS and other files from the ps3cet test directory. Do you see those? | 17:11.46 |
| mvrhel_laptop | marcosw: no I did not see them | 17:12.09 |
| marcosw | odd, I'll double check after you submit the fix. | 17:12.35 |
| | First test of the complete 31 machine cluster :-) | 17:15.43 |
| mvrhel_laptop | rayjj is gone. Robin_Watts do you mind taking a look at my fix. You had a hand in color usage I think | 17:16.24 |
| | its on my repos on casper | 17:16.34 |
| Robin_Watts | mvrhel_laptop: Sure. | 17:16.34 |
| | re->pcls->color_usage.or |= (1<<k) | 17:18.02 |
| | would save people having to understand what 'index' is :) | 17:18.24 |
| mvrhel_laptop | hmm | 17:18.29 |
| | ok | 17:18.48 |
| Robin_Watts | (minor point, feel free to ignore it). | 17:18.58 |
| | And it's trapEzoid, not trapAzoid. | 17:19.11 |
| mvrhel_laptop | ha | 17:19.15 |
| Robin_Watts | Unless that's a UK/US thing... | 17:19.16 |
| mvrhel_laptop | ok | 17:19.17 |
| | no | 17:19.38 |
| | you are correct | 17:19.42 |
| Robin_Watts | Other than that, looks great. | 17:19.56 |
| mvrhel_laptop | thats me spelling it the way I say it | 17:20.00 |
| | thanks Robin_Watts | 17:20.10 |
| | ok. I have to head out for a few minutes.. | 17:20.22 |
| | bbiab | 17:20.24 |
| Robin_Watts | In the UK it's trapezium, actually. :) | 17:20.36 |
| marcosw | the google says that trapezium is british for trapezoid. | 17:20.43 |
| Robin_Watts | wonders if there is a windows util to help you find the mouse pointer when you can't remember what screen it's on... | 17:54.04 |
| marcosw | the latest mac os x has a feature if you shake the mouse it makes the pointer really big for a couple of seconds, presumably someone will port that to windows soon if they haven't already. I wonder if it's available for linux... | 18:14.35 |
| | linux has a "show mouse cursor when ctrl key pressed" feature, not quite as intuitive | 18:17.07 |
| | henrys: the coverage analysis runs 72933 tests for ghostscript and 13878 for ghostpcl (all the regression files with various output resolutions and devices). | 18:25.09 |
| | if I mouse over <http://ghostscript.com/coverage/ghostpcl/base/gdevprn.c.html> line 485 I see that this line is executed by: | 18:25.47 |
| | tests_private__pcl__pcl5cats__Subset__ID3ZASC2.BIN.pbmraw.600.1 | 18:26.26 |
| | tests_private__pcl__pcl5cats__Subset__FM70CSC3.BIN.pbmraw.600.1 | 18:26.26 |
| | tests_private__pcl__pcl5ccet__31-04.BIN.ppmraw.600.1 | 18:26.26 |
| | and 4623 more. | 18:26.34 |
| | if i click on the line I get take to <http://ghostscript.com/coverage/ghostpcl/md5/34ff6e6fdf80d9e4737f9ac5c740f5bc.html> which lists all 4626 tests. | 18:27.03 |
| tkamppeter | Anyone here knows a little bit about XPS printers? | 18:27.09 |
| | There are printers only understanding XPS as known printer language and I want to support them under Linux. | 18:27.47 |
| marcosw | the reason that the line isn't yellow is because it's coverage is identical to the previous line and the line before that. Line 482 is yellow because it's not the same set of files as the line before it. | 18:28.08 |
| | the lines in gray (i.e. line 490) are exercised by none of the tests (which is true for most of the error messages). | 18:29.14 |
| | BTW, it takes about 5 hours to run the coverage analysis for ghostpcl and 30 for ghostscript. It runs on a subset of the cluster machines (those machines that have gcc 4.8.4 installed, since I had issues combining gcc coverage output from different versions). | 18:32.46 |
| | since the coverage analysis is only run once a week we could expand the number of input files and options we test. We could even make the files and options non-orthogonal, though I'd prefer to avoid that. | 18:35.40 |
| mvrhel_laptop | tkamppeter: you will want to use the xpswrite device | 18:36.59 |
| tkamppeter | mvrhel_laptop, I have some questions about this kind of printers. | 18:44.28 |
| | mvrhel_laptop, the xpswrite device of GS is probably the only free software implementation currently, so that the straightforward thought is to use it. Am I right? | 18:45.25 |
| mvrhel_laptop | tkamppeter: I am not aware of any other open source solution for this | 18:46.36 |
| | or AGPL I should say | 18:46.47 |
| tkamppeter | mvrhel_laptop, OK. | 18:46.58 |
| mvrhel_laptop | I did a bunch of updates in the last year to xpswrite to make use of it with gsview on windows for the windows printiner | 18:47.25 |
| | s/printiner/printing | 18:47.36 |
| | marcosw: OK. I pushed the fix for the missing bands | 18:48.17 |
| tkamppeter | mvrhel_laptop, as you (or someone at Artifex) have written it, you probably know a little about the hardware of these printers. I would like to know whether these devices have generally enough resources to print the pages as full-page bitmaps, to make a rastertoxps filter to print from phones without needing GS. | 18:48.44 |
| marcosw | mvrhel_laptop: thx. I'll let you know if I see any other issues. | 18:49.14 |
| tkamppeter | mvrhel_laptop, do you have an idea whether this would work? | 18:52.33 |
| mvrhel_laptop | tkamppeter: xps is not streamable so I would expect the printers to have quite a bit of resources. I would suspect that you would be better off sending the xps content from the phone rather than the bitmap | 18:53.39 |
| | marcosw: now I will go back to 696290 | 18:55.17 |
| tkamppeter | mvrhel_laptop, on the (ubuntu) phone the apps produce either PDF or JPG and this is thrown into a CUPS filter stack. To reduce the system size there is only Poppler as PDF interpreter and no Ghostscript. My thought now is to let CUPS run a filter chain like pdftopdf -> pdftoraster -> rastertoxps as it is much easier for me to write a rastertoxps filter than an xps backend for Poppler. | 19:00.35 |
| mvrhel_laptop | tkamppeter: a better solution is to drop Poppler and use mupdf | 19:01.17 |
| | well no really | 19:01.33 |
| | s/no/not/ | 19:01.38 |
| | no xpswrite in mupdf | 19:01.45 |
| | mupdf will render xps source content though | 19:03.14 |
| tkamppeter | mvrhel_laptop, and removing Poppler would require major changes in the phone's PDF viewer app and also major changes in cups-filters as cups-filters has no mupdf support at all yet (coders wanted!!! interns? volunteers? Artifex sponsoring?). | 19:03.26 |
| mvrhel_laptop | hmm I thought Robin_Watts wrote that already | 19:03.47 |
| tkamppeter | What do you mean with Robin_Watts wrote that already? Has he plans about who will code the MuPDF support for cups-filters? | 19:05.26 |
| Robin_Watts | tkamppeter: I wrote some code in mupdf to take rendered bitmaps to various output streams. | 19:06.49 |
| tkamppeter | Robin_Watts, what do you mean with that? | 19:07.53 |
| henrys | marcosw: sorry I just made up that line as an example, without even looking. I understand how the coverage report works. Maybe a concrete example - compile inits 0 is a separate build do we have coverage for that in the report I'm looking at? I do see we are using a "file open" not "romfs file open" as I would expect with compilile_inits 0 but we could be opening something for another reason. | 19:07.55 |
| Robin_Watts | tkamppeter: What raster formats do you need to get out of mupdf ? | 19:09.07 |
| mvrhel_laptop | I thought you did some stuff for Mike Sweet some time back | 19:09.25 |
| Robin_Watts | I remember doing stuff for Mike, yes, and then never hearing anything back despite chasing him a couple of times. | 19:09.59 |
| mvrhel_laptop | right | 19:10.19 |
| Robin_Watts | MuPDF knows how to output to PCL, and to PWG/CUPS format now. | 19:10.57 |
| tkamppeter | Robin_Watts, what I want to do is a simple rastertoxps filter to support printing on XPS printers (printers which have XPS as their only known PDL), to once have general Linux printing support for this new class of printers and second, to print on them on a (Ubuntu) phone which has no GS and no MuPDF installed. | 19:14.29 |
| Robin_Watts | Such printers actually exist? | 19:14.54 |
| | tkamppeter: We talk about this kind of stuff every now and then. | 19:15.21 |
| | The last time we talked we all agreed that it'd be great to drop poppler, and what we really needed was for MuPDF to be able to output in pcl and pwg/cups formats. | 19:15.52 |
| tkamppeter | Robin_Watts, generating XPS from CUPS/PWG Raster should be rather simple (as you only need a tiny part of the XPS spec) but will generate each page as a large bitmap, not allowing by-element color management (not important for a phone) anfd perhaps causing resource problems on the printer (but all XPS printers should be rather modern?). | 19:16.24 |
| Robin_Watts | So I went away and wrote that code, and handed it over to Mike Sweet for him to turn it into the PDFtoXXXX filters that we wanted. | 19:16.29 |
| | and nothing has happened. | 19:16.33 |
| | so I'm rather disenchanted with the whole thing. | 19:17.33 |
| tkamppeter | Robin_Watts, this code was for MuPDF-based pdftoxps filters? | 19:18.21 |
| Robin_Watts | pdf to various different formats of raster. | 19:18.36 |
| | not to xps. | 19:18.43 |
| tkamppeter | Robin_Watts, based on mupdf? | 19:19.00 |
| Robin_Watts | Obviously, yes. | 19:19.08 |
| tkamppeter | Robin_Watts, did you give it to Mike before CUPS 1.6.x was released? | 19:19.34 |
| Robin_Watts | Not a clue. I don't track CUPS releases. | 19:19.48 |
| | This was all more than 6 months ago. | 19:19.56 |
| tkamppeter | Robin_Watts, some 3 years ago? | 19:20.13 |
| Robin_Watts | I doubt it was that long ago. | 19:20.24 |
| tkamppeter | Robin_Watts, with CUPS 1.6.x I have replaced Mike Sweet in terms of CUPS filters. | 19:20.58 |
| Robin_Watts | I have a mail thread between you, me and Mike, entitled 'pdftoraster' that ran from 16/05/13 to 2/7/2013 | 19:21.37 |
| | I have a mail thread between you, me and Mike, entitled 'pdftoraster filter' that ran from 16/05/13 to 2/7/2013 | 19:21.52 |
| tkamppeter | Robin_Watts, CUPS got split into two parts, one is the part which Apple needs for Mac OS X, the daemon, the web interface, the libraries, the command line tools. | 19:21.57 |
| | Robin_Watts, This part Mike (and Apple) continue as free software CUPS on cups.org. | 19:22.56 |
| | Robin_Watts, the other part, most of the filters and some backends are now maintained by me, as the OpenPrinting project cups-filters. | 19:23.44 |
| | Robin_Watts, run by me this project switched over from the PostScript based print filter workflow to the PDF-based one, a decision from my first OpenPrinting Summit in 2006 (initiated by Mike and me). | 19:24.55 |
| | Robin_Watts, I also added cups-browsed to cups-filters to replace the automatic remote printer discovery by CUPS which also got dropped with CUPS 1.6.x. | 19:25.46 |
| | Robin_Watts, so this code which you have given to Mike you better had given to me. | 19:26.13 |
| | Robin_Watts, I hope you still have this code and so I could perhaps take it to integrate in cups-filters. | 19:27.18 |
| Robin_Watts | tkamppeter: Everything I did is in the mupdf tree. You were copied on every mail I sent to Mike. | 19:27.37 |
| tkamppeter | Robin_Watts, OK, I will have a look. | 19:27.57 |
| Robin_Watts | MuPDF has xps output capabilities, I think. | 19:28.32 |
| | In fact, I'm sure it does. | 19:29.56 |
| | Oh, wait, am I thinking of SVG? | 19:30.14 |
| | Yeah, I'm thinking of svg. | 19:30.53 |
| | I'd not imagine that an xps device would be hard to write. | 19:31.24 |
| | Certainly it'd be a lot better than a bitmap based one. | 19:31.49 |
| tkamppeter | Robin_Watts, could you easily get one together using the xpswrite code from GS? | 19:33.30 |
| Robin_Watts | No. | 19:33.44 |
| | The device interfaces for gs and xps are utterly different. | 19:33.54 |
| | For someone that speaks xps, it's probably less than a weeks work to get something that outputs xps files with text as line-art. | 19:34.44 |
| tkamppeter | Robin_Watts, mvrhel_laptop, a rastertoxps filter outputting bitmap-based XPS would work on commonly available XPS printers? | 19:35.46 |
| mvrhel_laptop | ugh. 696290 is a bit ugly. error is happening deep deep in a recursive shading fill. will look more after lunch | 19:36.03 |
| Robin_Watts | tkamppeter: No idea. I have no experience of such printers. | 19:36.27 |
| mvrhel_laptop | tkamppeter: if they follow the spec then yes I would expect it to work | 19:36.48 |
| | off to lunch now | 19:37.09 |
| tkamppeter | Robin_Watts, mvrhel_laptop Do you have some list of current XPS printer models? Perhaps I can arrange a purchase of a sample printer with Canonical. | 19:38.20 |
| Robin_Watts | tkamppeter: I certainly do not. I was not aware that anyone had actually put xps into a printer. | 19:43.02 |
| henrys | the only company I know of fool enough to do that is konica minolta and I actually know the guy that wrote the interpreter, he's retired now. - anyway it's in the bizhub c550. There may be others but I doubt there are many. | 19:46.15 |
| tkamppeter | Robin_Watts, and now we have the problem, printers supporting XPS only and we must support them under Linux ... | 19:46.33 |
| henrys | tkamppeter: really you know of a printer that only supports xps? How does a mac work? | 19:47.14 |
| | yeah! vmware works with my converted system, it was only a matter of removing some lenovo installed drivers. | 21:43.39 |
| tkamppeter | henrys, Konica-Minolta (at least) is producing such evil XPS + GDI printers. | 22:29.53 |
| henrys | tkamppeter: oh I was hoping they would at least throw in pcl. that's awful. | 22:30.40 |
| | tkamppeter: which particular models? I know the language folks, I can ask if there is a sane way to drive the printers but I don't know if there is. | 22:33.07 |
| | tkamppeter: I know some mono konica's support a simple jbig input in a pcl like wrapper | 22:34.06 |
| tkamppeter | henrys, Some links: | 22:35.21 |
| | henrys, http://www.biz.konicaminolta.com/technologies/vista_compatibility/ | 22:35.28 |
| | henrys, http://www.konicaminolta.ba/bs/poslovna-rjesenja/o-nama/press-centar/arhiva-saopstenja-2007/press-single/article/konica-minolta-announces-support-for-microsoft-windows-vista-xps-printing-and-wsd-protocols-11.html | 22:35.48 |
| | henrys, http://kmbs.konicaminolta.us/kmbs/about/news-events/news-releases/News/konica%20minolta%20next%20generation%20bizhub%20mfps%20demonstrate%20support%20for%20windows%20vista%20xps%20printing%20and%20wsd%20protocols | 22:36.14 |
| henrys | this is all dated 7 years ago. Are you sure there haven't been firmware updates to support other languages. I can see having a printer that doesn't support linux these days but not a mac. | 22:40.45 |
| | tkamppeter: actually 8 years ago... | 22:42.36 |
| tkamppeter | henrys, see also this one: http://ubuntuforums.org/showthread.php?t=2297639 | 22:57.30 |
| henrys | tkamppeter: I'll write my friend about it he still does open source stuff may be interested in helping out. He's working on fortran now of all things... aparently there is still a lively community | 23:02.59 |
| | tkamppeter: is there some reason cups can't take pdf/ps with ghostscript and use the xpswrite - I see somebody suggested gxps but that would be xps input which I assume you don't want. | 23:05.46 |
| | s/-/?/ | 23:06.09 |
| mvrhel_laptop | henrys: that was my thought. just use gs with xpswrite | 23:21.51 |
| tkamppeter | henrys, for any solution, GS with xpswrite or rastertoxps, I would need to do some testing and therefore find out which printer models are the ones affected and get one as test sample. | 23:38.20 |
| | Forward 1 day (to 2015/10/28)>>> | |
IRC Logs