IRC Logs

Log of #ghostscript at irc.freenode.net.

Search:
 <<<Back 1 day (to 2013/06/16)2013/06/17 
vtorri chrisl, i have filled a bug report about compiling gs with msys06:38.32 
chrisl vtorri: I saw it06:42.09 
vtorri chrisl, there are other compilation errors with jpeglib and libpng which are provided with gs06:42.51 
  also, there are compilation warnings about pointer to int on win 64bits06:43.14 
  because on win 64 bits, long are 32 bits long, unlike on unix06:43.40 
chrisl Yeh, those are mostly benign - just the compiler being dumb06:43.55 
  vtorri: FWIW, I only get one link error on msys - no errors in jpeg nor png06:44.26 
vtorri i'm waiting for the libtiff problem to be fixed to provide other bug reports06:45.11 
chrisl I don't see the libtiff problem - has msys removed size_t recently?06:45.48 
vtorri it depends on the toolchain06:46.15 
  try mingw-w6406:46.29 
  it's better than mingw.org06:46.40 
chrisl Why would mingw-w64 remove a (now standard) data type??06:47.01 
vtorri in addition, the math routines in mingw-w64 are faster than the ones in mingw.org and vc++06:47.05 
  not removed06:47.13 
  moved06:47.18 
  well06:47.21 
  include stdlib.h06:47.27 
chrisl So does libtiff compile on its own?06:47.51 
vtorri and ask the mingw-w64 devs :)06:47.57 
  yes06:48.04 
  i have compiled it myself06:48.10 
chrisl Which version, though? We use the libtiff configure script, so.....06:48.47 
vtorri libtiff 4.0.306:49.13 
chrisl Hmm, we've got 40.0106:49.52 
  4.0.106:49.55 
vtorri my compilation flas are --disable-static --disable-cxx06:50.50 
  (except the host and prefix)06:50.58 
chrisl So why are you using those?06:51.17 
vtorri i never use static versions on windows06:51.48 
  and for my needs, i don't care about c++ stuff06:52.10 
chrisl Oh, for libtiff06:52.24 
vtorri chrisl, yes06:52.29 
  they are compilation flags when i have compiled libtiff myself06:52.54 
  btw, libtiff 4.0.3 is "old" (september 2012) so mabe it should be updated in the gs repo06:54.03 
  maybe*06:54.50 
chrisl I know, I keep an eye on the updates, and what's changed.06:55.02 
vtorri ok06:55.10 
chrisl Well, I'll look at the build problem properly at some point, but I've got higher priority stuff to be working on06:55.37 
vtorri btw, iirc, a sub-configure is used for libtiff, right ?06:55.41 
chrisl Yes it is06:55.50 
vtorri iirc, the configure prefix of gs is not passed to the libtiff one, is it intentional ?06:56.13 
chrisl Yes. We don't "install" anything from libtiff, so there's no point06:56.38 
vtorri ok06:56.45 
chrisl We use the configure script to get the platform specific header files, and that's pretty much all06:57.13 
vtorri ok06:57.19 
  also, you provide a way to use an external libtiff, but why isn't it the same for libjpeg and libpng ?06:57.57 
chrisl Again before my time06:58.15 
vtorri ok06:58.20 
chrisl The configure option is redundant, anyway. *If* we allow the external lib to be used, you can prompt it by removing the directory from the Ghostscript source tree, and rerunning configure06:59.13 
vtorri or you can remove it defenitively and make libtiff a needed dependency07:00.40 
chrisl No we won't do that07:01.05 
vtorri ok07:01.22 
  just for my curiosity, why ?07:01.43 
chrisl We have spent considerable time doing QA on the source code we ship - if you link to random version of a library, that QA is rendered useless07:02.29 
  We also have occasional fixes that take time to get into the upstream project (or aren't accepted for some reason), so the source we ship *may* be patched07:03.31 
vtorri ok07:03.47 
chrisl Hmm, I've now been to five web sites related to mingw_w64 and I haven't found an installer on any of them.......07:04.53 
vtorri i give you a link07:05.15 
  chrisl, do you have win 32 bits or win 64 bits ?07:05.44 
chrisl 6407:05.49 
vtorri chrisl, do you prefer gcc 4.7 or 4.8 ?07:06.21 
chrisl Don't care, either should work fine07:06.34 
vtorri http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z/download07:06.55 
  download it somewhere (like in /mingw/mingw64 or something like that)07:07.29 
  update PATH so that it first points to the 'bin' subdir07:07.48 
  and that's all07:07.52 
chrisl Ugh, this really has nothing to do with the normal mingw project, does it?07:08.56 
vtorri indeed07:09.02 
  it's better07:09.07 
chrisl It's "better" except when it doesn't work......07:09.25 
vtorri heh07:09.44 
  i compiled libtiff myself with that toolchain07:09.56 
  and it workds flawlessly07:10.02 
  works07:10.06 
  so...07:10.11 
  maybe there is a problem on your side07:10.31 
chrisl So, I've compiled Ghostscript 9.07 on mingw and it works fine - no problem here07:10.42 
vtorri if you think that it's sufficient for you, then forget my bug report07:11.41 
chrisl I will look at it, when I get time. But my comments about being a "niche" platform count even more, in this case, and I'll prioritise (partly) on that basis07:12.51 
vtorri mingw-w64 is nowadays more used than the original mingw07:13.50 
  just because mingw-w64 is quickly improving, while mingw is almost stagnating07:14.27 
chrisl I doubt that, baring in mind that msys-git is currently the best way to use git on Windows.....07:14.50 
vtorri you won't see gc 4.8 in mingw this year07:14.52 
  i'm talking about mingw07:15.08 
  not msys07:15.12 
chrisl They are quite intimately related07:15.30 
vtorri msys can use any toolchain that you want07:15.49 
  so not so related07:15.54 
  see, even cygwin is currently using mingw-w6407:16.09 
  and MSYS 2 also07:16.20 
chrisl If it's so popular, how come there's no installer..... ;-)07:17.25 
vtorri ho, btw, you're right, msys-git is quite nice, i use it07:17.27 
kens chrisl can I interrupt a bit ?07:17.48 
chrisl kens: please do! :-)07:18.00 
kens bug #69431907:18.14 
  It 'looks' like memory corruption, I cna only make the problem exhibit on Linux, not on any flavour of Windows buld07:18.39 
vtorri why an installer when it's just a tarball to decompress, but there is one, but i stop here07:18.45 
kens chrisl can you try the bug and see what result you get ?07:19.06 
  I had to modify the source even to get to the same point that Marcos put in his traceback07:19.37 
  Of course, the problem is basically down to making the PDF itnerpreter continue after an error...07:20.30 
chrisl A debug build runs to completion for me, I'll try a release build once it's built07:21.15 
kens debug build failed for me :-(07:21.25 
  64-bit mind but I'm sure tha'ts what you are using07:21.40 
chrisl Yes, 64 bit07:21.50 
kens Makes me think its even more likely to be memory corruption07:22.11 
chrisl Release build seg faulted on page 4507:22.36 
kens It shoudl seg fault on closing07:22.52 
  When it writes out the PS file07:23.00 
  Its a 45 page file so I guess that's the same07:23.23 
  My debug version also give me a memory warning about chunks07:24.27 
chrisl Hmm, I'm going to grab a coffee, then I'll try it again with a fresh build07:25.13 
kens OK I'll keep poking with a stick07:25.26 
chrisl Hmm, still no crash in a debug build, but valgrind throws out a bewildering array of errors :-(07:34.19 
  Ah! running under valgrind crashes - actually, it crashes valgrind, too!07:35.18 
  kens: I did find a stack corruption problem in gxtype1.c the other day, with this file. It might be related07:38.07 
  vtorri: what environment do you run that toolchain in?07:43.33 
vtorri chrisl, msys07:43.47 
kens chrisl went to get a coffee, back now07:44.03 
chrisl vtorri: OKay, so I get no errors in libtiff, and I get all the way to the same linker error I got with the "stock" mingw32 tool chain07:44.36 
vtorri chrisl, i did what i have said : untar the tarball in /mingw/mingw64 (that is c:/mingw/mingw64), update PATH and that's all07:44.44 
  really ?07:44.56 
  arg07:44.58 
  strange07:45.10 
chrisl The link error is down to mingw being a half breed between Windows and Unix - we're pulling in *some* Windows code, and *some" Unix code, and we're missing a bit of the Windows code.07:45.50 
vtorri you are sure that the PATH in msys begins with the bin one of the mingw-w64 toolchain ? (in case...)07:46.10 
kens chrisl The problem I see is that the stream which is being written to 'seems' OK, but when it is freed I get a 'Chunk parsing error' in gsalloc.c(1461) followed by a SEGV at line 87407:46.12 
chrisl kens: the crash I saw was in the Type 1 code07:46.59 
kens Oh, very different then07:47.09 
vtorri going to work07:47.10 
  bye07:47.13 
chrisl vtorri: yes, it's deinitely using the mingw x64 compiler07:47.18 
kens Let me update my source07:47.37 
  Hmm, Git says my master is up to date07:48.51 
chrisl kens: the problem I saw the other day was that a glyph runs a subr with no numbers on the operand stack, when pops one or number off the (already empty stack), then the subr pushes numbers onto the stack - the op stack pointer now being *below* the bottom of the actual stack. The result is that the C stack gets corrupted.07:50.47 
kens Seems like a very different problem07:51.31 
  I just did a clean and a debug clean and am rebuilding both07:52.24 
chrisl kens: if you're interested: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=1d49dbbc07:54.01 
kens I see, but I should have that commit already07:54.30 
chrisl No, I never committed that - and I just noticed a mistake!07:54.51 
kens Oh, I just noticed it wasn't a commit07:55.01 
  Oh, a clean debug build doesn't segv now07:56.13 
chrisl That commit fixed the crash I saw in pdfwrite (I think) with that file in a debug build, but it still crashed in a release build....07:56.24 
  Which is why I didn't push the change07:56.40 
kens D'oh, I need the -r30007:57.00 
chrisl Even with that commit "fixed", it still crashes in a release build :-(07:57.37 
kens OK with -r300 debug and release builds still seg fault07:57.47 
  Presumably your fix prevents the memory corruption in a debug build07:58.16 
chrisl It prevents *one* of the memory corruptions....07:58.40 
kens :(07:58.47 
chrisl But a debug build runs to completion for me - for goodness sake :-(07:59.04 
kens It probably just shifts the corruption to somewhere harmless07:59.29 
  I don;t even get teh same fault as Marcos in a debug build, for me that crashes in stell()07:59.55 
  I have to patch around that to get to the point where Marcos sees a crash08:00.10 
chrisl kens: in your repo, is the latest commit your last commit ("silence a valgrind warning.....")?08:01.49 
kens Yes that's what I have08:02.00 
  A release build, run under ddd doesn't file, it gives a nice error and exits08:02.19 
  door, brb08:02.24 
  Ooops our next door neighbour has locked herself out of the house. However, she's locked the kids *in* the house.....08:04.09 
  chrisl I think you should probably commit your fix, since it fixes at least one problem08:04.35 
chrisl kens: okay, I'll do that08:05.02 
kens back to our neighbours again.... Might be a while08:05.24 
  OK back again08:14.37 
chrisl I'm doing a clusterpush on that change before I push it to casper08:17.05 
kens Seems reasonable08:17.12 
  I'm applying it here, but its unfamiliar tools time so its taking me longer than I would like08:17.31 
chrisl Hmm, there's compile fails on the cluster :-(08:17.57 
  Oops, I see - must have typed part of a command into the editor windows!08:19.10 
kens Been there, got all the T-shirts08:19.31 
chrisl And now the cluster seems to be throwing a hissy fit :-(08:23.28 
kens chrisl that change, I can see the c_callsubr needs to have fixed2int prepended to the pdata-.... But in the c2_callgsubr is the csp < &(cstack[0]) the right way round ?08:24.37 
  Actually, forget that08:25.56 
chrisl kens: that was the mistake I mentioned earlier..... git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=579e902408:26.20 
kens I think I'll wait until you commit it, then I cna pull the correct version :-)08:26.52 
chrisl That might be easier.....08:27.37 
kens Its easier for me than trying to cut/paste between VM and Windows, and use nano....08:28.04 
chrisl Can't you just pull into your Windows repo?08:28.38 
kens Yes, but I don't need to, Windows works08:28.57 
  But I have the Firfox window in Windows, and the editor in Linux....08:29.15 
chrisl Well, you could just pull into your linux repo.......08:29.36 
kens And I will, when you commit it :-)08:29.46 
chrisl The cluster seems happy now, so shouldn't be too long08:30.16 
kens Indeed, that's why I thought I'd wait, its probably quicker than me struggling with VMs and stuff08:30.37 
  chrisl I wonder if memento can help spot the memory corruption remaining in that problem file ?08:38.57 
  I'll try a build and run fter I get your fix.08:39.08 
chrisl It's possible. I'll also try a valgrind run with the one allocation per chunk hack08:40.21 
kens Hmm, turns out our neghbour didn't lock herself out exactly, she went out to the garden and her 4 year old son locked the door behind her....08:45.53 
chrisl :-)08:46.28 
kens Of course, he then couldn't figure out (or be told) how to unlock it08:46.46 
chrisl Or didn't want to?08:47.14 
kens Oh I think he wanted to, by the time I got there *both* children were in floods of tears08:47.35 
  Fortunately she'd left an upstairs window open, so I used our ladder to climb in08:47.57 
chrisl Well, live and learn, I suppose08:48.13 
kens :-D08:48.19 
  I think that's the thrid time in 3 years I've had to get her back into her house....08:48.48 
chrisl You should start charging a fee08:49.14 
kens Well, at least its better than fixing people's computers08:49.39 
  your cluster run looks OK08:50.34 
chrisl Yeh, exactly what I expected, so pushed08:50.49 
kens Great I'll go synchronise08:51.02 
chrisl I've noted it on the bug08:52.11 
kens Hmm debug build still SEGV, I'll do a full clean and rebuild08:55.59 
chrisl That does not surprise me - the crash I saw that sparked that fix was quite proximate to the fix08:57.38 
kens Well, I still get a SEGV, time to fire up ddd08:57.55 
  Yes, same crash, same place08:58.58 
chrisl It's weird that I don't see the crash in a debug build08:59.24 
kens I get it both debug and release08:59.37 
  Though as I said, I have to put a patch in just to get that far, mornally it crashes even earlier for me (on a debug build anyway)09:00.00 
chrisl You are using 64 bit LInux?09:00.29 
kens Certainly am09:00.34 
chrisl Bemused......09:00.54 
kens In a VM of course, with 2GB memory. But its the same crash Marcos reported on a real Linux installation09:01.09 
  Or at least the backtrace is the same09:01.27 
chrisl Well, I've started a valgrind run with the single block per chunk hack, but it's going to take an age to run :-(09:01.43 
kens If I could use ddd better I might be ablle to solve this (and if I understood GS's memory handling too)09:02.07 
  What I see is that in i_free_object() 'pstype' is invalid memory09:02.52 
  that's given by the block of memory -1, cast to a obj_header_t pointer, and then the 'o_type' member of that structure09:03.32 
  But it looks like that's actually a macro os some kind09:03.59 
chrisl So, what I would normally do is find where the object is allocated, and put a watch on the pstype entry09:04.16 
kens Its a stream, figuring out where its allocated could be tricky09:04.52 
  NB there is no psype entry09:05.08 
  pstype is given by pp->o_type but that's not a member either so I assume its a macro09:05.46 
chrisl I think it's a union09:06.23 
kens In fact it seems to be o->d->o->t.type09:06.26 
  That first o should be a pp09:06.40 
kens would be a lot happier if this would fail under Windows09:07.34 
  Oh, and it looks like pdev->strm (and probably pdev) are subject to relocation by the garbage collector09:11.22 
chrisl Oh wonderful :-(09:12.26 
  Aha! I can get it go wrong on peeves09:14.34 
kens You're ahead of me. FOr what its worth the stream is allocated in gdev_vector_open_file_options09:15.01 
  (gdevvec.c)09:15.10 
chrisl Okay, if I use gcc 4.4.1 I can get it to wrong here, too.....09:18.24 
kens What were you using before ? Something more recent ?09:18.38 
chrisl 4.7.209:19.08 
kens Well that would change the memory pattern I guess09:19.27 
chrisl Okay, so pstype ends up as some crazy address out around Saturn?09:20.14 
kens Well its certainly barking09:20.25 
chrisl Would it make you happy if I offered to run with this one?09:20.45 
kens I can't look at it right now, I'm back at the beginning in the debugger, looking at the allocation in i_alloc_strcut09:20.50 
  chrisl it would make me happy, but I'd feel gulty09:21.01 
  I'm running a Memento build at the same time09:21.12 
  just to see if it tells me anything09:21.26 
chrisl Okay, if memento doesn't show anything useful, let me hammer on it for a bit - I'm at least more familiar with the debugging tools09:22.09 
kens And the Ghostscript memory stuff.....09:22.24 
chrisl Oh, it also thinks the memory allocation was 1531390564 bytes - that's probably wrong!09:23.06 
kens I didn't notice that, but I'm sure its wrong :-) Its undoubtedly the same memory corruption09:23.32 
chrisl Yes, the memory header ID is corrupted as well09:24.06 
kens I'm not surprised, something is scribbling whwere it ought not to09:24.26 
  I was fairly sure that was the case, but at least you;ve confirmed it09:24.40 
  Oh, looks like all the stuff in i_alloc_struct comes down to macros09:25.11 
chrisl Yes, nice isn't it :-(09:25.56 
kens Incomprehensible would be a better description, I was hoping to find the memory being stomped on. Oh well.....09:26.20 
  Ah its OK obj tells me what I want I think09:26.47 
chrisl The memory header seems to be getting overwritten in gs_md5_append09:39.29 
kens Hmm, interesting, that's kind of an odd place09:39.49 
  Memento is going to be a while, its on page 9 at the moment :-(09:40.33 
chrisl Hmmm, something borked - gdb and/or ddd think that md5.c is in debugobj :-(09:45.26 
kens :-O09:45.36 
  I did get some similar madness, complaining that it couldn't find soure files in debugobj (while simultaneously displaying the source files...)09:46.13 
chrisl It seems very adamnt about it09:48.22 
  or even adamant09:48.30 
kens Or Adam Ant ?09:48.40 
  I have no idea whay it would be complaining about that09:48.52 
  chrisl what was it trying to process when it called gs_md5_append ?09:51.01 
  (Memento has reached page 10...)09:51.19 
chrisl I don't know, whatever was going on, I couldn't inspect variables, or anything :-(09:51.40 
kens O.O09:51.48 
  Seriously messed up09:51.54 
chrisl Yep09:52.02 
kens I have to confess I'm not making any progress here, just floundering in the dark. And memnto only reached page 13 so far10:06.18 
  But the first content stream error is on pag 1210:06.35 
chrisl Memento sets the single allocation per chunk flag, and that *really* hurts the speed10:07.09 
kens I guess that explains it then10:07.19 
chrisl kens: any idea where cos_stream_t is defined?10:10.45 
kens One second, I can find that10:10.55 
  Its a cos_stream_s10:11.11 
chrisl I mean actually defined, yes, but I can't find that defined10:11.26 
kens seems to be defined i gdevpdfo.h10:11.29 
  Using... A macro!10:11.44 
  Its a horrible macro too10:12.37 
chrisl Okay, I'm starting to see some vague light - let me try to clarify my thoughts......10:13.36 
  Actually, maybe a caffeine boost is in order......10:16.08 
kens OK no problem10:16.18 
chrisl kens: <sigh> this is going to take some time, but it is definitely a memory management problem - I suggest you leave it with me for a while10:30.57 
kens jumps at it10:31.27 
  Thanks chris10:31.36 
chrisl I'll let you know when I come up with something worth reporting....10:32.02 
kens ok10:32.11 
Robin_Watts paulgardiner, tor8: png10:58.04 
paulgardiner Hi10:58.27 
ghostbot hola10:58.27 
Robin_Watts paulgardiner: See your email.10:58.38 
paulgardiner Ah right. Just reading it now10:59.41 
tor8 morning10:59.53 
Robin_Watts paulgardiner: Actually, while I remember. You said last week that you had a tweaked version of the smoothness review on your repo.11:00.04 
  I couldn't find it.11:00.06 
  tor8: morning.11:00.10 
  tor8: Similarly see your email :)11:00.28 
paulgardiner Robin_Watts: Yeah, I forgot to push, but did this morning, so you should see it now11:00.29 
Robin_Watts I'm going to try to pull my progressive changes up to the current master now, so you two can pull them apart.11:01.13 
paulgardiner Robin_Watts: I agree with your interpretation11:04.01 
tor8 Robin_Watts: the startup time discussion from a few weeks ago, that just petered out or did we come to any conclusions?11:04.56 
Robin_Watts tor8: It petered out.11:05.06 
tor8 paulgardiner should get a nexus 10 (or similarly high powered device) so he can see the same glitchiness with scrolling frame drops11:05.40 
paulgardiner tor8: After our discussion at the meeting, I may be able to address it without the feedback of having a device that shows the problem.11:06.41 
Robin_Watts Nexus 10 has a dual core CPU.11:07.08 
  Nexus 7 has a quad core.11:07.14 
paulgardiner tor8: it would be handy though, to bring henrys in on this, just to keep him in the loop on all things I'm looking into11:07.30 
Robin_Watts Given that we have a Nexus 10 between us, I wonder if we should get a Nexus 7 as the next device?11:07.43 
  THe Nexus 4 is similarly quad core.11:08.01 
kens Stella has one of those11:08.03 
  Nexus 711:08.09 
paulgardiner On the other hand, possibly access to a device that performs significantly differently to my S2 may be handy11:08.21 
Robin_Watts kens: I bet she'd be unwilling to loan it out though :)11:08.22 
kens Highly :-)11:08.28 
  Think Gollum and ring :-(11:08.48 
paulgardiner kens: Ha. Like it. :-)11:09.19 
  They have Nexus 4 as reference device. Well they say (such as)11:11.32 
Robin_Watts The transformer prime is quad core, so we can use that.11:13.37 
paulgardiner Do we understand the correlation between hardware and glitching?11:15.51 
kens lunches11:22.26 
Robin_Watts paulgardiner: I think the belief is that we glitch on everything. We just don't notice it on devices that aren't hitting 30fps anyway.11:23.45 
paulgardiner Do you mean not hitting 60fps?11:24.55 
Robin_Watts no.11:25.04 
paulgardiner My S2 looks too smooth to be missing 30fps11:25.13 
Robin_Watts So, I'm trying to get the progressive commit up to date (and of course that's conflicted with paulgardiner's recent xref changes)11:36.19 
  The JNI bindings - I would have thought that we want to construct the JNI interface carefully so that it mirrors the C as much as possible - but there may be a case for deviating slightly if it's more natural to the java interface obtained.11:37.37 
  and probably to do that, we'd want to have the header file changes done first? I guess that's not essential, but feels right to me.11:38.04 
tor8 Robin_Watts: how deep do we want the JNI bindings to go?11:39.10 
  the fz_document and fz_device stuff are obviously needed11:39.25 
  and also the pdf_obj and xref edit/save layer, or do we want to use the higher level abstraction for annotations and widgets?11:40.13 
Robin_Watts tor8: This is what we need to decide.11:40.26 
tor8 header file changes should probably go through soon-ish11:40.34 
Robin_Watts I think we should push forward with the header file changes.11:40.48 
paulgardiner That's probably the right approach for the JNI bindings, but I also wonder about instead thinking carefully about how it would be used from android and targetting that specifically.11:41.03 
Robin_Watts Then try to get a minimal JNI set in place (fz_document/fz_device)11:41.13 
  and I suspect our experience doing that will color our thoughts on the shape of the rest of it.11:41.30 
  paulgardiner: It might be nice to drive the JNI work by what we'd need to move the android app over to using it.11:42.23 
tor8 Robin_Watts: would it be worth doing more language bindings at the same time (like Lua, Python and/or Javascript) so we don't paint ourselves into a java language specific corner for how the foreign-language apis will look like11:42.50 
paulgardiner I also wonder about asking Google how they'd like the JNI interface. IMHO, the android architecture is expertly crafted, certainly far better than any interface I've ever designed11:42.51 
Robin_Watts I believe that's what mvrhel did with the Win8 stuff.11:42.52 
  tor8: I would be wary about taking on too much work.11:43.27 
  Bear in mind they say "Release in the second half of 2013"11:43.44 
tor8 if we provide enough low level APIs for JNI, wrapping those up in some elegantly crafted java classes to provide activities and UI components doesn't have to touch any JNI stuff11:44.03 
Robin_Watts Even if they mean release in November, that's probably "final QA by october."11:44.11 
paulgardiner tor8: but multiple JNI calls is inefficient. My thinking stems from realising that if a full low-level JNI interface had been available when I started work on the app, I would probably still have had to make my own higher-level JNI entry points.11:45.52 
tor8 paulgardiner: how inefficient are we talking? milliseconds per call?11:46.18 
paulgardiner tor8: yeah, good point. Mostly we call the JNI to do a fairly large task like to render. If that involves 8 JNI calls rather than 1, it would probably have small effect in time taken as a percentage of the total11:48.06 
tor8 I think the biggest bit of work doing JNI bindings is transferring data structures like the outline tree and arrays etc11:48.25 
  another question is how closely to match with java classes for struct11:50.41 
  s11:50.42 
  it'd be cool if we did have java classes for devices and documents and pages rather than a single big "here's the JNI wrapper" class11:53.00 
Robin_Watts tor8: yes, that's the way it should be.11:53.19 
  PDFDocument extends FzDocument.11:53.42 
  FzDrawDevice extends FzDevice etc.11:53.56 
  FzPage11:54.25 
tor8 yup.11:54.38 
  Robin_Watts: updated windows mingw commit on tor/master11:55.08 
  doesn't change the main/wmain stuff other than the #ifdef11:55.19 
Robin_Watts tor8: I'll get to that as soon as I have all the bits put back together here :)11:55.38 
tor8 I wonder what MSVC does in the presence of both main() and wmain()11:55.57 
Robin_Watts barfs, I bet.11:56.25 
tor8 mingw doesn't seem to recognize wmain, even with -municode11:56.42 
  warning: ambiguous entry point; selected 'mainCRTStartup'11:59.14 
  so it picked main() rather than wmain()...11:59.50 
  Robin_Watts: and wchar/utf-8 function reshuffling commit on tor/master12:34.04 
chrisl kens: ping12:51.10 
kens chrisl pong12:57.24 
  (but I have to go dismantle a wardrobe shortly)12:57.38 
chrisl kens: so, now I'm confused, and have the beginnings of a headache. What did you patch to get past the stream error?12:58.00 
kens which stream error ?12:58.40 
  I had a problem in cos_add_stream that I had to work around (stream was null, not being tested)12:59.03 
chrisl I thought you said you had to apply a patch to get to the error Marcos reported?12:59.13 
kens Yes, the one in cos_add_stream12:59.29 
  Otherwise it SEGV's there for me12:59.38 
  Or did, anyway12:59.42 
  Give me a minute to power up a VM13:00.01 
  Yes in cos_stream_add I tested for (!s) and return 0 if it is NULL, otherwise it tries to stell(s) and that SEGVs13:01.40 
  I'll just stash that and try without it13:02.02 
chrisl kens: hmm, the problem I'm seeing is that pcs->pdev is garbage, so we never get to there13:02.34 
kens That's not a problem I have seen so far13:02.50 
chrisl Using -Z@ the pointer value is 0xa1a1.......13:03.25 
kens Well that's no good13:03.34 
  pcs is a pointer to a colour space ?13:03.44 
chrisl kens: no, it's some stream thing in cos_stream_add()13:04.30 
kens Oh....13:04.37 
  Just a minunte, I'll runn ddd13:04.49 
chrisl it's a cos_stream_t *pcs13:05.31 
kens I get a SEGV in stell(stream *s) , because s is NULL13:05.58 
  called from cos_stream_add mind you13:06.17 
  Looks like i'm just lucky to get that far I think13:06.49 
chrisl So with -Z@ I get pcs->pdev == (gx_device_pdf *) 0xa1a1a1a1a1a1a1a113:06.50 
Robin_Watts kens: You neighbour has now locked herself in a wardrobe?13:06.59 
kens Robin_Watts : ROFL13:07.08 
  Its one we're selling (and no, to the best of my knowledge there is no door to Narnia)13:07.25 
  chrisl looks like hte pdev is borked for me13:08.37 
  FirstPage is 106535321513:09.01 
chrisl OKay, so that's at least consistent13:09.04 
kens It looks like I'm just 'lucky' in the sense that it isn't badly enough broken to cause a prblem for me (at that point)13:09.32 
chrisl Well, value it gets with -Z@ suggests that the memory has not been set after allocation13:10.13 
kens Hmm, well I *think* this particular stream is the main output file, which is opened in gdev_vector_open_file_options or similar name13:10.57 
  But I also think its been relocated since it was opened13:11.17 
chrisl No, I don't think it is the main file - it may be a filter "on top" of the main file13:12.09 
kens Yeah in the back trace I see it starting from pdf_close calling ps2write_dsc_header which calls copy_procsets, so this *should* all be going into the main file13:12.13 
  OK it could be a filter, true13:12.26 
  Probably is in fact13:12.32 
chrisl The cos_procs suggest it's an A85E fitler13:13.03 
kens My only caveat is that because we are ignoring errors in the PDF interpreter, its entirely possible that its not writing to the file it *thinks* it is.13:13.06 
  pdev->strm is the 'current' stream, but that changes depending on what we are doing. If we don't reset it properly, then it could be pointing to a temporary file.13:13.51 
  I'll have to go and dismantle this wardrobe, I'll be back in a bit.13:14.08 
chrisl OKay, thanks13:14.15 
kens OK wardrobe dispatched13:54.16 
Robin_Watts tor8: both commits look good to me. will push them.14:01.21 
paulgardiner Email that came in from tech with time 14:11 keeps killing Thunderbird14:03.32 
Robin_Watts 14:11 in what timezone?14:04.48 
  I've got one called "support11:41:16" ?14:05.30 
kens Could be the HPGL interpreter one, it has attachments14:06.00 
  2xtiff file and a PDF14:06.08 
  SOrry HPGL file I mean14:06.14 
Robin_Watts ooh, yes.14:06.23 
  that makes my thunderbird unhappy too.14:06.33 
kens Eudora is OK with it14:06.42 
Robin_Watts I bet eudora doesn't try to do thumbnails of the tiffs or something stupid, and thunderbird does.14:08.05 
kens Nope, too old to do that14:08.13 
  I just get an icon for the associated program14:08.25 
Robin_Watts kens: Is it worth you zipping the attachments and resending the mail with the zipfile ?14:09.07 
kens I cna f you want, but to be honest its pretty clearly one for Marcos and Henry14:09.28 
Robin_Watts I guess.14:09.36 
kens The missing image is misleading I think14:09.38 
Robin_Watts I feel bad deleting the mail.14:09.50 
kens I see more than a missing image, it looks more like a whole colour overlay has gone14:09.52 
  I'll zip and send it to support14:10.17 
chrisl Hmm, 17Mb of uncompressed attachments, I'm surprised it caused a splutter or two!14:12.04 
kens THe zip is 8Mb its on its way now along with the text of the original message14:13.41 
  Of course, it takes a lot longer to *send* *mb thant to receive 17....14:14.22 
tor8 Robin_Watts: thanks.14:15.22 
  so should I go ahead and do the include file shuffle?14:15.38 
kens Hmm, when I run the file provided, I get 2 pages of PJL.... Well I guess Henry will know what magic runes to write to make it work14:17.23 
Robin_Watts tor8: I think you should.14:17.42 
  tor8: Do you have a version in the repo for us to look at?14:17.59 
  Or are you still working on it ?14:18.03 
tor8 Robin_Watts: tor/headers has the first step14:18.14 
  next step is merging the regular and -internal headers14:18.27 
kens OK Robin_Watts paulgardiner, the mail has been resent with teh attachments zipped, and has left my mcahine, should be with you 'soon'14:18.34 
tor8 and after that, split them into modules14:18.36 
Robin_Watts Gonna do all that on a branch? Sounds good.14:19.33 
tor8 Robin_Watts: any preference for which modules (or how to name them) are welcome14:19.35 
  the merging and splitting will make any header file changes difficult to merge though14:19.53 
  so if there are any pending commits that affect header files, now's the time to say so14:20.08 
Robin_Watts tor8: We'll cope.14:20.14 
  aargh.14:22.42 
  With the progressive loading code, whenever I met an xref, I just ensured that the table was big enough.14:23.08 
  and whenever I read an object, I put it into the table.14:23.17 
  With the new code that keeps xrefs in the order they were in before, that's hard.14:23.41 
  How do I know what xref an object goes into ?14:23.57 
henrys marcosw are you fielding guillaume's bug or should I look at it directly?14:31.54 
kens I tried his file and got a page of PJL henrys, but then I know nothing :-)14:36.02 
henrys probably best for it to go through the system.14:37.18 
  oh I see you guys were talking about it.14:38.33 
kens :-)14:38.37 
henrys he's french what can you do.14:39.51 
  ?14:39.55 
kens I've made no effort to work on it (no poitn really) just tried one quick run of current code, it didn't do what I expected, so I stopped14:41.05 
henrys oh damn now you have me curious - I was looking at a bike catalog ;-)14:41.52 
kens wwwwwwwbike catalog sounds more fun14:42.13 
tor8 Robin_Watts: I have a list of 35 potential sub-headers for fitz.h14:44.02 
henrys kens:fwiw you need -lRTL for plotter files otherwise you will get PJL14:44.49 
tor8 I could make more or fewer, a bit depeding on how tightly we want to group related things to gether14:44.52 
  fz_path, fz_text, etc could all go into device.h along with the device functions14:45.11 
  or live in their own header14:45.16 
Robin_Watts tor8: I'd favour separate headers, personally. I think.14:45.57 
tor8 buffer, compressed-buffer, stream, output as separate I think14:46.39 
  -dashes or _underscores?14:46.53 
Robin_Watts _underscore14:47.09 
  _ is an ISO 9660 char, - isn't.14:47.23 
sebras Robin_Watts: hm.. but using - means less shifting...14:47.23 
paulgardiner kens: TB much happier with newly sent HPGL message, thanks. 14:48.30 
kens Ah OK good to know you got it14:48.39 
sebras Robin_Watts: oh, and isn't joliet more or less standard nowadays..?14:50.11 
chrisl kens: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=bd08091d14:50.16 
Robin_Watts sebras: yes. The ISO 9660 objection is a historical one, really :)14:50.48 
kens chrisl so the problem is a 'broken' font ?14:50.51 
chrisl Well, it's a font that causes an error to occur during the attempt to write it out - baring in mind the fix I put in earlier for this file, broken font isn't surprising!14:51.52 
kens I have a feeling there are a number of errors with this (or a very simlar) cause14:52.13 
chrisl Yeh, but the combination of Ghostscript's filters implementation, and pdfwrite's own stream stuff made it a royal pain :-(14:53.14 
kens OK so if we get an error, rather than simply abort out, we flush the stream and 'end' the file ?14:53.15 
  Oh, and stil return the error code, OK14:53.42 
chrisl Yes, exactly. That pops all the extra filters off the output file, and leaves everything the filter chain where it was to start with14:54.00 
kens Right. This is what I was saying before about the error handling in pdfwrite not really being up to this. I *very* strongly suspect there are a lot of places like this.14:54.29 
  Anyway, the fix looks fine to me, thanks for doign that!14:54.42 
tor8 Robin_Watts: http://ghostscript.com/~tor/stuff/fitz_headers.txt14:54.57 
  sebras: ^14:55.01 
chrisl kens: Yep, there are plenty more in that function alone - but I'm pretending I didn't see them............14:55.16 
kens chrisl I think those sorts of problems are scattered through the pdfwrite code :-(14:55.34 
Robin_Watts tor8: base => fitz ?14:55.34 
tor8 Robin_Watts: include/mupdf/fitz/base was my thought14:55.54 
kens I've tried to be careful to avoid these myself, but I've made no attempt to fix the existing ones (too big a job)14:55.57 
tor8 and include/mupdf/fitz/io/buffer.h14:56.09 
  etc14:56.10 
chrisl kens: like I said in Miami, there's not point trying to track them all down, the best we can do is address them as we find them.14:56.13 
sebras tor8: Robin_Watts: actually when I grep in the result of find /usr/include I find more - in the names than _.14:56.29 
tor8 then we don't collide with include/mupdf/pdf/filter.h and include/mupdf/fitz/filter.h14:56.34 
kens Yeah, its just a shame there are so many points of failure. Oh well, please go ahead and commit it chrisl14:56.39 
chrisl kens: just running a clusterpush, will commit after that14:56.58 
kens would be highly surprised if the cluster showed any errors.14:57.19 
chrisl I know, but just to be safe - plus I can got make a cuppa!14:57.44 
sebras tor8: what would be the names of the collection headers? include/mupdf/base.h?14:58.13 
tor8 include/mupdf/fitz.h would include include/mupdf/fitz/base.h etc14:58.30 
  and include/mupdf/fitz/base.h would include include/mupdf/fitz/base/*.h14:58.49 
  might skip the intermediate ones though14:59.08 
sebras tor8: right.14:59.13 
  tor8: do we want to keep annot or do we want annotation..?14:59.29 
tor8 sebras: good catch14:59.58 
Robin_Watts tor8:sorry, phone call.15:00.33 
  I'm not sure I see the point of fitz/base/xxx.h Why not just fitz/xxx.h ?15:00.56 
henrys kens:I think there is confusion best sorted out by marcos, I get reasonable output and his tiff's look very similar to me, but neither have color.15:01.12 
sebras tor8: also write_document seems too long. why not just write..?15:01.13 
Robin_Watts From the point of view of a caller, what significance does the 'base' have ?15:01.15 
  sebras: fz_write does something else.15:01.26 
tor8 too many header files, or dnoh.t15:01.32 
  brb reboot, mac has iues wih usb agn15:01.44 
Robin_Watts dnoh.t ?15:01.45 
  ok.15:01.51 
sebras Robin_Watts: something tells me tor8 will be annoyed once I get there tonight... ;)15:02.17 
Robin_Watts tor8: so, you were saying why "base" is important.15:04.33 
tor8 every couple of days my macosx 10.8 usb driver goes nuts and starts rate limiting my typing to approx 1 key per 2 seconds15:04.52 
  so yes, were you objecting to just the base/ or also the io/ and resource/ subdirs?15:05.18 
Robin_Watts I really dislike base. and resource.15:06.18 
  and path should not be in device.15:06.25 
  I can live with device15:07.31 
  why should any of the draw headers be exposed?15:07.43 
tor8 Robin_Watts: the draw headers should move into source/draw and be made internal to the draw device15:09.11 
  but one step at a time15:09.13 
Robin_Watts This is the time to make that step.15:09.36 
tor8 what would you suggest for resource and base? just drop them all in one big mess at the top?15:09.38 
Robin_Watts because we might choose to put things in subdirs now, only to find that when we 'privatise' stuff, we're left with such a small set in a subdir that it makes it pointless.15:10.39 
tor8 path and text are only used in the device calls, hence my putting them there15:10.43 
Robin_Watts tor8: Shouldn't there be a 'search' thing somewhere?15:11.18 
  text will be used by that too.15:11.26 
tor8 Robin_Watts: that's a different text, currently in output/text15:11.45 
Robin_Watts I think I'm broadly in favour of having everything in a big mess at the top :)15:11.55 
sebras tor8: hm.. what is a compress_buffer as opposed to a regular buffer?15:12.07 
tor8 a big mess at the top works for a first step15:12.07 
  but it's not a good long term solution to have 50+ files in one directory15:12.28 
  or maybe it is, I haven't tried that approach yet :)15:12.42 
sebras tor8: I would think that gs has proven that quite well, yes.15:12.50 
tor8 I prefer subdirs to prefixes15:13.12 
Robin_Watts sebras: A compressed buffer is what we use in fz_images15:13.14 
  It's a buffer of data, plus details of the compression used on it.15:13.26 
tor8 prefixes + 8 char max file length + 1000+ files in one directory makes for gs pain15:13.30 
Robin_Watts so we can decompress it on demand.15:13.38 
sebras Robin_Watts: aha, ok. but is there reason enough to separate those from the regular ones? header-wise?15:13.49 
Robin_Watts There are only 37 headers in there, so far, and hopefully some of those will be privatised.15:14.02 
  sebras: It's a different data type.15:14.11 
tor8 Robin_Watts: better names for text-used-in-device and text-extracted-from-page-used-in-search15:14.21 
Robin_Watts And it may be one we can hide.15:14.27 
tor8 pcl-output or output-pcl or just plain pcl?15:14.56 
Robin_Watts The 'out' dir was one I was happy with as a subdir.15:15.23 
  That makes sense, because it groups a set of identical things.15:15.33 
tor8 I think both the io and output subdirs could stay15:15.40 
Robin_Watts device/{draw,path,text} makes sense too.15:15.50 
  Sorry!15:16.00 
  device/{draw,text} makes sense too.15:16.08 
  less keen on the io one.15:16.31 
tor8 device/{device, display-list, draw, text}?15:16.49 
Robin_Watts Do we need a public device/device.h ?15:17.27 
  I guess in case people define their own devices.15:17.36 
  yeah, then like that.15:17.39 
tor8 I think we do. for people using it as a 'canvas' api15:17.50 
Robin_Watts but fz_path should be at the top level, IMHO.15:17.54 
  tor8: OK.15:17.59 
tor8 fz_path and fz_text could live in device.h, IMO15:18.21 
  or at the top15:18.26 
Robin_Watts Yes, they could live in device.h15:20.29 
  or at the top. But not in device/15:20.42 
  Morning mvrhel_laptop15:20.56 
  I haven't had a chance to look at that .xap yet, sorry. I did ask for a source pointer on their facebook page, but have had no response yet.15:21.19 
  mvrhel_laptop, tor8: I did wonder about adding a bit of code into MuPDF to allow us to open PDF files that start with 'MuPDF' rather than "PDF".15:21.59 
tor8 Robin_Watts: drop the resource/ subdir as well then?15:22.14 
Robin_Watts I would personally.15:22.24 
tor8 just output, device and document for now?15:22.25 
Robin_Watts I dislike document too.15:22.40 
tor8 I rather like having document and resources separate15:22.59 
Robin_Watts I see the argument for using subdirs to say "here is a set of things that do the same kind of thing"15:23.03 
  hence for devices, or outputs.15:23.10 
tor8 they're related but somewhat independent groups of things15:23.12 
Robin_Watts It seems arbitrary to me that a colorspace is a resource, where a path is not.15:23.37 
  If we DO have a resource dir, then path should live in it.15:24.09 
tor8 fz_path and fz_text could live there as well, but in general the resources are things we stick in fz_store15:24.16 
Robin_Watts Then display_list shouldn't be in there.15:24.44 
  If we say that resource contains 'reference counted resources; then display_list and path certainly belong there.15:25.41 
  s/;/'/15:25.47 
tor8 some things belong in potentially many places15:26.23 
  like the display list15:26.27 
Robin_Watts I'd put the display list just in devices/list.h for now.15:27.08 
tor8 or different aspects of them in separate headers, but that's starting to get annoying15:27.36 
Robin_Watts cos no one will need it without devices/list.h at the moment - and if they ever do, we can split it out, and including devices/list.h will still be enough.15:27.41 
  so actually, I've just argued myself into putting path.h into devices/device.h15:28.10 
tor8 the path stuff should be either in resource/path.h or device/device.h15:28.40 
Robin_Watts Splitting more in future can never hurt us. Splitting too early can (as we may split into the wrong place).15:28.41 
  device/device.h I think. (Sorry, reversing my earlier dogmatism)15:29.00 
tor8 I'll err on the side of not splitting then :)15:29.28 
mvrhel_laptop good morning15:45.23 
kens chrisl I thiknk the other bug (6949a8) is a similar problem, the input is broken and even though Windows doesn't crash, it writes a not very good PDF file out.15:45.45 
  Lots of bits missing15:45.52 
chrisl kens: there's a type in the bug number - but I can take a look at that one tomorrow, if you like15:47.57 
kens lol 69431815:48.11 
  again can't make it fail o Windows15:48.38 
chrisl I'll take a crack at it tomorrow - like I said, being familiar with the tools makes quite a difference15:49.16 
kens Well you got further than me *much* faster15:49.33 
chrisl But I can't face another bug like that today ;-)15:50.06 
kens I know the feeling15:50.12 
chrisl I also need to run an errand - bbiab........15:51.01 
kens OK I've had more than enough today, I'm off for teh night...16:10.03 
tor8 Robin_Watts: argh! circular dependencies...!16:18.47 
Robin_Watts tor8: really? such as?16:19.40 
tor8 fz_document depends on fz_annot depends on fz_document...16:21.00 
Robin_Watts fz_annot is an opaque type, right?16:23.07 
  So typedef struct fz_annot_s fz_annot; goes in document.h16:23.41 
paulgardiner I'd imagine we'll run into a lot of that if we make struct details visible in the public headers16:23.53 
Robin_Watts and annot.h #includes "fz_document.h"16:24.03 
tor8 yeah. I'm going to have to do a lot of shuffling of typedefs in the right order.16:24.04 
Robin_Watts document.h should never need to then include annot.h, right?16:24.27 
tor8 not this particuar instance16:24.44 
  there's however the case of fz_font depending on both fz_device and fz_display_list16:25.09 
  which I solved by using forward declarations of the opaque structs16:25.26 
  but not the typedefs16:25.34 
Robin_Watts tor8: I don't follow that.16:34.39 
  Can't we get font.h to include device.h and list.h and do the typedef struct fz_font_s fz_font; in device.h ?16:36.08 
mvrhel_laptop ugh. this is driving me bananas. so I need to make sure that the windows app can open files on microsofts skydrive. First time I try to open the file, it fails to even get the file name after the file picker and of course things explode. Second time it works just fine. It is like I am not waiting sufficiently for it to be locally downloaded but it is not clear in the documentation how...17:47.30 
  ...to ensure this. it is just all supposed to work17:47.31 
  ok got that working now18:30.35 
  now I need to get the open with working18:31.04 
ray_laptop mvrhel_laptop: Are you here ?20:00.21 
mvrhel_laptop ray_laptop: I am. just about ready to go eat lunch. whats up?20:00.45 
ray_laptop mvrhel_laptop: cust 801's Autocolor Detection Problem #2 is something I need your advice on. It is because clist_begin_typed image treats all RGB images with MultipleDataSources as color20:01.38 
  in non-clist mode it gets it right.20:01.54 
mvrhel_laptop MultipleDataSources. ick20:02.27 
ray_laptop /* Decide if we need to do any monitoring of the colors. Note that multiple source20:02.55 
  (planes) is treated as color */20:02.57 
  pie->unpack = NULL;20:02.59 
  if (dev_profile->pageneutralcolor && pie->color_space.icc_info.data_cs != gsGRAY20:03.00 
  && (pie->num_planes == 1)) {20:03.02 
  else we say the page is color20:03.22 
mvrhel_laptop hmm . is there a case in pdf where pie->num_planes != 1?20:03.56 
  didnt you and I talk about this20:04.00 
ray_laptop mvrhel_laptop: we may have talked about this. In this case the file is PS20:04.19 
mvrhel_laptop ray_laptop: and if you remove the && (pie->num_planes == 1)20:04.53 
  what happens20:04.56 
  I am trying to remember if I coded this up so that multiple sources work anyway20:05.15 
  need to look at code. let me get gs up20:05.28 
ray_laptop mvrhel_laptop: I suspect that it will get confused, but I will look into it.20:05.34 
  mvrhel_laptop: it works OK in non-clist mode.20:05.50 
  but I don't want to force it to non-HL image mode (rectangles) for this case. But that would be a quick (and dirty) fix.20:06.42 
mvrhel_laptop so the fix if one is needed will be in cmd_image_plane_data_mon20:06.59 
ray_laptop mvrhel_laptop: let me trace what happens treating num_planes > 1 the same.20:07.19 
mvrhel_laptop the call of row_has_color20:07.19 
  aound line 220420:07.39 
  so you may have to collect the plane data20:07.54 
ray_laptop mvrhel_laptop: I'd have to keep one row to compare against.20:08.12 
mvrhel_laptop or have a special (and costly new cmd_image_plane_data_multiple_sources_mon function)20:08.31 
ray_laptop since all 3 (or 4) rows have to match up in order to be mono20:08.39 
mvrhel_laptop that would probably be the way that I would go20:08.51 
ray_laptop the costly new function ?20:09.04 
mvrhel_laptop is to have a replacement for cmd_image_plane_data_mon20:09.10 
  when num_planes > 120:09.20 
  which was a replacement for cmd_image_plane_data20:09.47 
ray_laptop mvrhel_laptop: OK. Let me dig into it and see20:09.49 
mvrhel_laptop ok. i am going to grab a bit to eat.20:09.58 
ray_laptop mvrhel_laptop: OK. buen provecho20:10.16 
mvrhel_laptop then I need to go and get a couple things at store. today is my daughters birthday20:10.17 
ray_laptop mvrhel_laptop: I'll run it by you when I have something, or will contact you if I hit a wall, but I should be able to handle it. Thanks for the chat20:11.00 
 Forward 1 day (to 2013/06/18)>>> 
ghostscript.com
Search: