| | <<<Back 1 day (to 2014/11/17) | 20141118 |
| avih | for a function with 1 arg x, returning x/2 directly or in a try block (where catch is never invoked), the try version was 10% slower than the direct version before the catch fix, and after the catch fix it's about 4x (400%) slower. so a very real penalty on this reduced case. correctness is probably still preferable especially since in real life cases the penalty would be usually less. my own real life case became ~30% slower after the change. hmm.. not | 04:51.49 |
| | a fun tradeoff for this correctness... though still, between the two, correctness should probably still win. | 04:51.49 |
| test___ | hi | 05:39.15 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 05:39.15 |
| tor8 | avih: try/finally (without catch) should still be just as fast | 10:53.57 |
| | any use of try will involve a setjmp call, which may add some slowdown depending on OS | 10:54.31 |
| Robin_Watts | tor8: Do you use signals in mujs? | 10:55.03 |
| avih | tor8: interesting. i might be able to turn some of the catches to finaly. | 10:55.06 |
| | though mostly i do have use for the catch var | 10:55.22 |
| tor8 | Robin_Watts: no, so I guess we could look for sigsetjmp where available | 10:55.35 |
| | avih: if you use try/finally for resource cleanup you shouldn't be impacted, and if you use try/catch in an inner loop then you're going to suffer no matter what :) | 10:56.18 |
| | but mostly it's calling a function that uses try/catch that's slow | 10:56.30 |
| Robin_Watts | sigsetjmp saved us a fair bit with mupdf on macos iirc. | 10:56.55 |
| avih | tor8: fwiw, in a limited number of loop iterations (10k iirc) mujs doesn't perform much worse than firefox. but when more optimizations kick in, the "lightweight" mode in firefox becomes extremely quick, while the try/catch mode is considerably slower. in fact, firefox's try/catch mode is only about 3x faster than mujs... | 10:57.13 |
| tor8 | avih: our bytecode speed is roughly the same or slightly faster than spidermonkey's bytecode | 10:58.25 |
| | but when spidermonkey's JIT kicks in, we're left in the dust (as we should be) | 10:58.37 |
| avih | tor8: and yet, firefox's try/catch mode becomes 2 orders of magnitude slower compared to the jit lightweight code | 10:59.25 |
| | as if the jit can't work on the try/catch function | 10:59.54 |
| tor8 | my guess: try/catch prevents the jit | 10:59.55 |
| avih | yeah, feels like it | 11:00.10 |
| tor8 | exceptions in C++ are a nightmare, IIRC | 11:00.12 |
| avih | OTOH, without the jit, spidermonkey's try/catch mode is as fast as its lightweight mode. but for mujs try/catch is now 4x sliwer than lightweight | 11:01.45 |
| | tor8: hmm.. how simple it might be to optimize it such that if the catch var name isn't a formal (or local?) var name then make it lightweight? | 11:23.43 |
| | and if it has eval, fallback to non lightweight | 11:24.46 |
| Robin_Watts | avih: I thought the point of mujs was "correctness in the smallest possible space". | 11:25.25 |
| avih | Robin_Watts: i don't disagree. but if an optimization is simple anough and its gain meaningful enough, it might be worth breaking this principle. can't judge this case myself though. | 11:26.26 |
| Robin_Watts | Adding such performance tweaks needs to be weighed carefully. | 11:26.28 |
| avih | aye. which is why i started with asking how simple it might be :) | 11:27.04 |
| | if it's completely obvious and local, it could be worth it. | 11:27.18 |
| | if the cost was only during compilation, it would have meant very little. but the cost is on every function call where the calee has try/catch | 11:29.11 |
| tor8 | avih: it might be possible to detect that case and put the catch variable in the set of locals and then introduce two new opcodes to deal with the try/catch without pushing an environment record | 11:37.25 |
| | I don't have the compiler code fresh in my memory, so I can't be sure how much work would actually be involved in doing such an analysis | 11:37.55 |
| avih | tor8: hmm.. in that case, probably premature optimization. thx for considering it though. | 11:38.27 |
| tor8 | and like Robin said, it's not a high priority and would all depend on the amount of code and complexity needed | 11:38.29 |
| avih | yes | 11:38.41 |
| tor8 | if it's a simple 10 line tweak, no problem. if it needs several new functions and analysis passes -- maybe not. | 11:38.58 |
| avih | agreed completely | 11:40.59 |
| | at least not at this stage | 11:41.05 |
| | fwiw, i just benchmarked 4 different calles with 10k calls. 1: direct x/2 - 5.6ms. 2: try/finally = 5.6 ms. 3: try/catch: 19 ms 4: direct with the callee containing an embedded and unused function: 40ms. | 11:43.22 |
| | i'd have imagined that 3 and 4 would have been the same speed. | 11:43.35 |
| tor8 | the embedded (but unused) function still needs to be created | 11:44.24 |
| | compare try/catch and creating two new objects (a={};b={};) | 11:44.58 |
| | with the unused inner function | 11:45.17 |
| avih | with 2 new local vars set to {} individually, 12 ms | 11:45.53 |
| | like so: | 11:46.18 |
| | function t1(x){ | 11:46.18 |
| | var a={}, b={}; | 11:46.19 |
| | return x/2; | 11:46.19 |
| | } | 11:46.19 |
| tor8 | so try/catch plus creation of two objects would be roughly equivalent to simply an unused inner function | 11:46.39 |
| avih | oh, i tried the direct one. | 11:47.00 |
| tor8 | an inner function creates two new objects (one for the function, one for its .prototype property) | 11:47.03 |
| avih | yeah, try/catch + 2 vars is similar. 32 ms, vs 37 of the unused embedded function | 11:47.40 |
| tor8 | yeah, that sounds like what I'd expect | 11:48.03 |
| avih | hmm.. it quickly becomes slower eh? | 11:48.20 |
| tor8 | reference the 'arguments' variable to make it even slower | 11:48.27 |
| avih | yeah, i think i noticed that too in the past | 11:48.56 |
| | so yeah, i take it back. optimizing the scopes for special cases is probably premature right now. | 11:49.52 |
| tor8 | yeah. the optimization for lightweight functions is the smallest optimization that given the biggest payback | 11:50.19 |
| avih | sounds like it. | 11:50.30 |
| tor8 | as long as you avoid: inner functions, eval, arguments and try/catch in a function it will be faster than usual | 11:50.38 |
| avih | yup | 11:50.56 |
| tor8 | so any hard working frequently called function should try to have these properties | 11:50.57 |
| avih | and local vars too, it would seem | 11:51.05 |
| tor8 | which is pretty much going to be true of any js interpreter | 11:51.08 |
| | using local vars is always going to be faster than using globals | 11:51.21 |
| | even going so far as to make a local copy of a frequently used global (just as you do in lua) | 11:51.43 |
| avih | i meant the other way, actually. just declaring them adds noticeable duration | 11:51.57 |
| tor8 | var local_foo = global_foo; then use local_foo instead | 11:52.13 |
| avih | i mean, declaring them locally is expensive. though i didn't check how fast would the access be. | 11:52.26 |
| tor8 | really? | 11:52.32 |
| avih | really what? | 11:52.43 |
| tor8 | not sure I follow exactly what you mean, could you give an example | 11:52.44 |
| | of slowdown with local vars | 11:52.51 |
| avih | yeah, your example. the try/catch was 12ms, adding 2 local objects brought it to 32ms | 11:53.13 |
| tor8 | ah. that's not because of any local/global variable -- that's just the cost of creating a new object (think malloc) | 11:53.41 |
| avih | right. | 11:53.49 |
| tor8 | a = {} is equivalent to a = new Object() (but slightly faster, due to not calling a constructor) | 11:54.33 |
| avih | well.. not that i have plans for a video encoded using js interpreter :) but still... brings back the old days where you would have to micro-optimize manually. cute :) | 11:54.45 |
| | encoder* | 11:54.57 |
| tor8 | it never hurts to be mindful of what causes dynamic programming languages to suffer from terrible performance :) | 11:55.17 |
| avih | sure. as i said, forgotten skills. cute :) | 11:55.38 |
| | these days with jits and compiler optimizations, you really mostly have to make sure the algorithm is good, the compiler usually does good enough with micro optimizations | 11:56.27 |
| tor8 | yeah. there's also the fact that sometimes a seemingly innocent construct in a language like JS will do a *lot* of heavy lifting behind the scenes | 11:57.23 |
| | and if you're not aware of those, you can run into trouble without knowing why | 11:57.46 |
| avih | indeed. as i found out today with spidermonkey's resiliance to try/catch optimizations... | 11:58.11 |
| | but it's always ugly to take a nice readable and correct code and deform it to get better speed. | 11:59.23 |
| tor8 | nods. | 11:59.45 |
| avih | tor8: so, my own "Real" case was an event loop handler which calls different dispatch functions according to the event type, where each of these dispatch functions call the handlers in a try/catch. on case of handler error, it displays it but continues to the potentially next handler of this event. so if i wanted to avoid the overhead of calling the dispatch functions due to their try/catch, one solution might be to inline them into the event loop | 12:19.27 |
| | function (which never exits until the program exits)? | 12:19.27 |
| | (i have no intention to do this, i don't have speed limit issues now and i don't expect to have such soon, but just to understand how could the penalty be avoided) | 12:20.52 |
| | since it _seems_ to me right now that the penalty is in invoking the function and not in executing its code | 12:22.19 |
| Robin_Watts | avih: Removing unnecessary function calls seems a good idea. | 12:27.00 |
| avih | Robin_Watts: unnecessary is a loose term :) it does contribute to readability and modularity :) | 12:27.58 |
| Robin_Watts | indeed. | 12:28.08 |
| | but in a performance sense they are unnecessary. | 12:28.24 |
| | C compilers can often spot such things and inline them if they are 'static'. Similarly Java if they are private. | 12:29.07 |
| | I don't know js well enough to know if there is a similar thing. | 12:29.24 |
| avih | yeah.. | 12:32.48 |
| kens | chrisl so Hel;mut's latest problem is that he has a PDF file with a broken CID FOnt (badly enough broken that Acrobat also refuses to load it). So GS (like Acrobat) resorts to using a substitute. Helmut has told GS to use the gothicb.ttf for the CIDFont called CenturyGothic-Bold, and he doesn't actually have a TTF by that name on the system ? | 13:33.35 |
| | Oops, chrisl is away... | 13:34.32 |
| chrisl | kens: really? When I looked in the file, I didn't see any CIDFonts other than Arial being embedded | 14:34.06 |
| kens | Hm, I thought the PDF had the font embedded, but maybe it was just a reference. I'll look at it again (ghe didn't resend the PDF) | 14:34.43 |
| | But for definite his cidfmap references a file in WIndows/Fonts which, acording to his directory list, doesn't exist..... | 14:35.16 |
| | Well Acrobat certainly complains about CenturyGothic,Bold | 14:36.05 |
| chrisl | kens: yes, I see Acrobat's complaint: "Cannot find or create......" | 14:37.29 |
| | I know what the problem is....... | 14:39.47 |
| kens2 | chrisl you are correct, although there is a FontDescriptor, it has no FontFile* entry | 14:40.15 |
| | One of the Arials does has a FOntFIle, as does one of the Arial,Bold fonts | 14:41.57 |
| chrisl | And Helmut's problem is that *later* in the cidfmap file is a *name* mapping: "/CenturyGothic,Bold CenturyGothic-Bold ;", but since "CenturyGothic-Bold" maps to a non-existent TTF file, we'll now remove that map. | 14:42.16 |
| kens2 | Indeed | 14:42.37 |
| | WHat does he expect to happen when he lies to Ghostscript and tells it to use a non-existent font ? | 14:44.48 |
| chrisl | Well, we do validate the TTF based maps now, so...... | 14:46.47 |
| Robin_Watts | Miles needs to upgrade his Mustang... https://www.youtube.com/watch?v=5qanlirrRWs#t=652 | 14:50.48 |
| chrisl | Nah, they're much more civilized in San Francisco....... | 14:51.46 |
| Robin_Watts | Happy Birthday Michael. | 14:55.31 |
| mvrhel_laptop | Hi Robin. Thanks | 14:56.44 |
| henrys | mvrhel_laptop: oh and a big one too! | 15:00.57 |
| Robin_Watts | was too polite to mention that :) | 15:01.24 |
| henrys | miles and I are always talking about mvrhel_laptop defying age... | 15:04.19 |
| jogux | Happy Birthday Michael :) | 15:04.37 |
| chrisl | Presumably he has a painting of himself in the attic that is ageing horribly....... | 15:07.21 |
| paulgardiner | That would explain it | 15:07.50 |
| Robin_Watts | Dorian Color. | 15:08.35 |
| kens | groans | 15:08.48 |
| mvrhel_laptop | :) | 15:11.10 |
| henrys | 5 minutes until the meeting | 15:25.28 |
| | meeting time | 15:30.19 |
| | rayjj: nice work with len! teach me to butt out ;-) | 15:30.41 |
| | we have the meeting coming up soon, I reviewed the workflowy links we start the meeting with looks like a few items could be taken care of quickly. | 15:31.40 |
| rayjj | henrys: thanks. | 15:31.45 |
| henrys | but all in all the bug numbers look good. | 15:32.02 |
| | the segv's in the support list have patches attached by a security guy. might be worth having a quick look at those now. one looks like Robin_Watts domain. | 15:33.40 |
| kens | Which bugs are these ? | 15:34.17 |
| henrys | http://bugs.ghostscript.com/show_bug.cgi?id=695348 | 15:34.18 |
| | support bugs on the workflowy, the first link. | 15:34.47 |
| kens | Right | 15:34.51 |
| Robin_Watts | I have that open as a tab in chrome now, so it can add to my growing guilt. | 15:35.12 |
| mvrhel_laptop | :) | 15:36.00 |
| henrys | Robin_Watts: Not so sure the fix isn't masking something else but... | 15:36.10 |
| Robin_Watts | yes, I'd like to understand the cause. | 15:36.26 |
| kens | I htink 685623 can be closed, shall I do it ? | 15:36.27 |
| henrys | kens: why don't I find that. have a link? | 15:37.27 |
| mvrhel_laptop | I dont find it either | 15:37.39 |
| kens | Its on the page you ponted me too :-) | 15:37.41 |
| Robin_Watts | bug 695623 ? | 15:37.50 |
| kens | Yes | 15:37.59 |
| mvrhel_laptop | ah | 15:38.03 |
| kens | typo on my part | 15:38.07 |
| henrys | kens: yes please close it. | 15:38.37 |
| kens | :-) | 15:38.43 |
| henrys | then there was an errwrite segv patch I thought chrisl could handle quickly. | 15:39.17 |
| chrisl | Oh, I thought that was more Robin_Watts area..... | 15:39.43 |
| | But I'll take it if you like | 15:39.54 |
| henrys | the dreaded poodlebleed bug ... | 15:40.39 |
| | marcosw: can we close that one? | 15:41.45 |
| marcosw | sorry, which one? | 15:42.49 |
| henrys | and the awaiting review class are both rayjj bugs: http://bugs.ghostscript.com/buglist.cgi?bug_status=AWAITING_REVIEW&list_id=19274&query_format=advanced&resolution=--- | 15:42.50 |
| | marcosw: 695654 | 15:43.35 |
| marcosw | henrys: not sure, have we fixed the problem? :-) | 15:44.03 |
| henrys | marcosw: what problem are we using ssl for anything? | 15:45.03 |
| | tor8: any ideas for fred on the mupdf front? | 15:46.01 |
| Robin_Watts | henrys: There are some crashlytics reported crashes for MuPDF. | 15:47.12 |
| | Dunno how tractable they are for a newcomer. | 15:47.35 |
| henrys | mvrhel_laptop: is the xpswrite stuff soon. I have potential fixes for the xpswrite bug fixes but they are going to make a merge for you if I put them in the code now. | 15:47.39 |
| mvrhel_laptop | henrys: yes. I am hoping to have that done today | 15:48.05 |
| tor8 | henrys: no. I tried to build the Qt viewer on my linux box a few days ago but failed. | 15:48.05 |
| rayjj | I took bug 693121 back to "IN_PROGRESS" since I confirmed excessive slowdown and have a patch in process | 15:48.11 |
| henrys | tor8: well do report a bug to him. | 15:48.48 |
| tor8 | it might be because I only have Qt4 installed ... is he using Qt5? | 15:49.21 |
| henrys | Robin_Watts: are these in bugzilla or somewhere else? | 15:49.33 |
| Robin_Watts | henrys: In crashlytics. | 15:49.44 |
| tor8 | henrys: in other news, I am well on track with the EPUB viewer | 15:49.51 |
| | I can view HTML with most relevant CSS styling, all line broken and paginated | 15:50.13 |
| Robin_Watts | The ios builds of MuPDF contain some magic code such that when they crash, a report is sent to crashlytics. | 15:50.13 |
| | They then generate backtraces etc and have the results visible on the web. | 15:50.31 |
| tor8 | missing images (small work), floats (big work) and tables (huge work) | 15:50.33 |
| mvrhel_laptop | epub actually came up at one of the meetings in korea | 15:50.39 |
| Robin_Watts | I get mails every day about then (mostly SOT, but a couple of mupdf ones). | 15:50.50 |
| tor8 | and then I need to write an epub format unpacker to feed the html viewer and we can open EPUB files | 15:50.59 |
| Robin_Watts | No idea if they are reproducible or not. | 15:51.02 |
| tor8 | mvrhel_laptop: what did they say about epub? | 15:51.30 |
| henrys | Robin_Watts: so marcosw could be on the list and he could create bugs ? marcosw ? | 15:52.03 |
| jogux | robin_watts: it's very rare that you managed to reproduce something from crashlytics :-( | 15:52.08 |
| mvrhel_laptop | tor8 they wanted to know if we supported it in mupdf | 15:52.19 |
| henrys | tor8: be great to have a demo in the london for the "sales and marketing department" | 15:53.05 |
| tor8 | henrys: yeah. I'm going to get images in there and then divert to epub unzipping | 15:53.38 |
| rayjj | henrys: do that and they'll be selling it as "done" | 15:53.46 |
| tor8 | so we can have a demo going | 15:53.48 |
| mvrhel_laptop | :) | 15:54.09 |
| henrys | rayjj: fortunately in our new mobile/cloud enviroment, miles' definition of done is starting to look reasonable | 15:55.22 |
| Robin_Watts | normal, not reasonable. | 15:56.01 |
| rayjj | yeah, people tolerate "vaporware" more readily | 15:56.12 |
| henrys | following tradition next tuesday's meetings are canceled. note next week is also a 3 day week for the US folks. Anything else for the meeting. | 15:56.59 |
| | ? | 15:57.00 |
| kens | Not here | 15:57.11 |
| marcosw | henrys: I receive the crashlytics emails and could easily setup an automated system that would create bugs. There will be many of them. | 15:57.12 |
| kens | Enjoy the US vacation :-) | 15:57.28 |
| jogux | marcosw: I think they may have a bugzilla integration (bcbw, they certainly have some bug systems integrated) | 15:57.48 |
| | please don't do anything automated in that area for SOT :-) | 15:58.06 |
| henrys | marcosw: well I was hoping you could confirm and filter a lot, if crashlytics is inflated I'd rather not fill up bugzilla... | 15:58.48 |
| Robin_Watts | I fear a lot of crashlytics bugs are completely unfixable without the particular files the user is using. | 15:59.19 |
| kens | would rather expect that, its the same with Bugzilla after all | 15:59.40 |
| jogux | robin_watts: not at all. now we have line numbers (again) for SOT some are fixable. | 16:00.11 |
| | *testing* the fix is almost impossible of course. but, hey, that's what users for for, right? | 16:00.29 |
| Robin_Watts | jogux: Yes, *some* are fixable, by virtue of "oh, it crashed on this line... that must mean that the problem is... so I can fix it" | 16:00.56 |
| jogux | sometimes you can fix the crash but suspect you're nowhere near the root cause :( | 16:01.15 |
| Robin_Watts | yes. | 16:01.23 |
| | and lots of the time, you'll be stuffed to even patch the symptom. | 16:01.35 |
| jogux | there seem to be two main iOS ones at the moment for mupdf. one is something evil and iOS specific, the other is a null pointer deref in render. | 16:02.10 |
| Robin_Watts | fred may be well placed to do the evil ios specific one maybe? | 16:02.46 |
| jogux | how about icloud drive support for mupdf for fred? | 16:03.06 |
| marcosw | henrys: I don't seem to be getting the none Smart Office crashlytics reports, so I don't know who many of those there are, but there are too many Smart Office ones for me to triage, there have been 12 today already. | 16:03.06 |
| henrys | marcosw: can you add jogux's iOS bugs. | 16:03.13 |
| | ? | 16:03.15 |
| | for mupdf. | 16:03.18 |
| Robin_Watts | jogux: That could work. | 16:03.38 |
| jogux | robin: we don't seem to be getting crash reports for the 1.6 mupdf android btw. (there are some for 1.5) :-S | 16:03.40 |
| Robin_Watts | That's cos 1.6 doesn't crash :) | 16:03.59 |
| jogux | sure, sure. | 16:04.05 |
| henrys | jogux: presumably his work could be pulled over to sot? | 16:04.37 |
| Robin_Watts | I don't know why otherwise. This is google crash reports, not crashlytics, right? | 16:04.45 |
| jogux | robin_watts: crashlytics | 16:04.52 |
| henrys | moving to skype... | 16:04.57 |
| Robin_Watts | Oh, I wasn't aware we had crashlytics working on mupdf android. | 16:05.09 |
| jogux | apparently we don't anymore ;-) | 16:05.23 |
| Robin_Watts | Oh, of course, we do, but it's a private repo. | 16:05.30 |
| marcosw | henrys: I can't add the mupdf crashlytics bugs because I don't receive them (or at least a search for crashlytics mudf in gmail doesn't show them). | 16:05.34 |
| Robin_Watts | and I didn't build from that. | 16:05.36 |
| | so, my bad. | 16:06.09 |
| jogux | robin: sadly http://twiki.ghostscript.com/do/view/MuPDF/AndroidReleases doesn't mention it sadly. I couldn't say for 100% sure that it definitely got finished. | 16:06.39 |
| henrys | jogux can you forward the mupdf problems to marcos | 16:06.41 |
| | ? | 16:06.44 |
| Robin_Watts | jogux: I think it did get finished. I'm sure there is private repo that contains the mupdf public repo as a submodule. | 16:07.23 |
| jogux | certainly is for iOS | 16:07.34 |
| Robin_Watts | thus the crashlytics specific stuff is kept private. | 16:07.35 |
| | Oh, maybe that was ios. | 16:07.45 |
| Robin_Watts | remembers about his failing memory again. | 16:07.57 |
| jogux | mupdf-private doesn't obviously have any android stuff. so I'm not quite sure :-S | 16:08.16 |
| | marcos: you allegedly have a crashlytics account | 16:16.53 |
| | (already, I mean. your artifex email is the login, I hope you know the password :) ) | 16:17.22 |
| | https://www.crashlytics.com/artifex/ios/apps/com.artifex.mupdf/issues?build=1.6&status=open&event_type=all&time=all will show you the ios crashes for the current version | 16:17.44 |
| mvrhel_laptop | henrys: running xpswrite test once more. hopefully this fixes the issues I was having | 17:25.33 |
| | ok. diffs but no more segvs (except that one file) | 17:42.41 |
| | and some files that are no longer timing out | 17:43.40 |
| | henrys: it all looked good. went ahead and pushed | 18:20.38 |
| | so please add your changes | 18:20.49 |
| | that was one item I wanted to get done before the staff meeting. | 18:21.05 |
| | next a bit of fix up on gsview and then this one thing in SOT | 18:21.19 |
| henrys | mvrhel_laptop: great ... | 18:21.50 |
| rcurry71 | New to freenode and new to ghostscript. I'd like to import a PCL file (which includes various tray calls) into a C# project and grab the tray calls per page. Is that possible in GhostScript? | 19:35.36 |
| Robin_Watts | rcurry71: We don't supply any C# code with Ghostscript. | 20:11.52 |
| | But there is Ghostscript.net, which is a set of C# wrappers for gs. | 20:12.07 |
| | So, while we can't help you with the C# side of things, I think it may be possible. | 20:12.31 |
| | I don't quite follow what you mean by "grab the tray calls per page" though. | 20:12.48 |
| | Certainly it is possible to drive Ghostscript (and presumably GhostPCL) programmatically from C# using Ghostscript.net. | 20:16.00 |
| | If you just want to scan the PCL file to get the different paper selection requests out, then I'm not sure that's functionality that's built into the standard code. Henrys would be the guy to ask. | 20:16.49 |
| rcurry71 | GhostScript.net will not deal with PCL files, only PS | 20:19.47 |
| | We have a client that is desiring to use us as their disaster recover option... | 20:20.18 |
| | they have print files(PCL) with tray calls that we will grab off of a FTP | 20:20.47 |
| | it's is for a mailing.. | 20:21.32 |
| | we will grab the PCL file off of the FTP, and create PDFs with an associated .xpif | 20:22.47 |
| | I meant to say: generate a .xpif | 20:22.58 |
| mvrhel_laptop | bbiaw | 20:57.54 |
| | Forward 1 day (to 2014/11/19)>>> | |
IRC Logs