| | <<<Back 1 day (to 2014/10/29) | 20141030 |
| kizspast | why is mupdf faster than poppler? | 00:42.15 |
| rayjj | kizspast: because it's better ? | 01:00.08 |
| | kizspast: mupdf is a totally separate code base, developed by Artifex Software over the past 10+ years. | 01:00.54 |
| | kizspast: it was designed primarily for PDF, but the "fitz" graphics library is the primary reason for the performance, and is used when mupdf processes other inputs such as XPS | 01:02.11 |
| | guess kizspast got tired of the answer :-/ | 01:03.35 |
| pedro_mac | :) | 01:07.50 |
| UnderSampled | Hello | 03:26.00 |
| 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. | 03:26.00 |
| UnderSampled | I'm trying to build JBIG2dec on windows, but can't figure out how to start | 03:26.43 |
| | do I just run nmake in the dir or something? | 03:26.51 |
| rayjj | UnderSampled: right -- you need to have your environment variables set suitably for the version of Visual Studio (e.g. execute the vsvars9.bat for VS 2008) | 04:39.56 |
| | UnderSampled: then: nmake -f msvc.mak | 04:40.09 |
| | will make jbig2dec.exe | 04:40.21 |
| | UnderSampled: I just tried it with VS 2008 as descrbied. You can also create a project for a "console application" and in the Properties, put the nmake command line in the Configuration Properties under the NMake category | 04:44.42 |
| UnderSampled | rayjj: Hello! | 04:45.14 |
| rayjj | that way the environment will be set correctly for whatever VS you are using | 04:45.21 |
| UnderSampled | I got it to work without libpng just fine, but it didn't work when I tried adding it in | 04:45.52 |
| | I'm using vs2008's environment variable bat | 04:46.17 |
| rayjj | UnderSampled: why did you want libpng ? | 04:46.22 |
| UnderSampled | I want to drag a JBIG2 file onto it and have it output a png | 04:47.08 |
| rayjj | UnderSampled: I haven't tried that, but you will have to edit the makefiles to set the directories (or move them in to the default location) and AFAIK, you hve to build the libs separately | 04:49.00 |
| UnderSampled | I've done that, with multiple different versions of zlib | 04:49.30 |
| | each time it comes back with an error while running "cl.exe" | 04:49.49 |
| rayjj | UnderSampled: needless to say, the developers of this were linux focused. | 04:50.26 |
| | I'll look at the code ... | 04:51.05 |
| UnderSampled | did it do the same for you? | 04:51.20 |
| | Thanks by the way :D | 04:51.26 |
| rayjj | UnderSampled: OK, I'm working from the sources in the gs tree. I copied the zlib and libpng directories into the jbig2dec directory (partly to make it easy to clean up after) | 04:59.20 |
| | then I did: cd zlib nmake -f win32\Makefile.msc which built the zlib.lib static lib | 05:00.20 |
| | then I did: cd .. (back to the jbig2dec directory) followed by: cd libpng nmake -f scripts\makefile.vcwin32 | 05:02.15 |
| | that built libpng.lib | 05:02.26 |
| | then I did cd .. (back to jbig2dec) | 05:02.49 |
| | I modified msvc.mak to create msvcpng.mak with the comments removed on the LIBPNG_CFLAGS and LIBPNG_LDFLAGS lines | 05:05.35 |
| | then nmake -f msvcpng.mak and it built it | 05:06.38 |
| | oops -- I forgot to comment out the next two lines that set these to the empty string | 05:11.12 |
| UnderSampled | rayjj: sounds familiar | 05:11.49 |
| rayjj | oops again. I had to change the directories from ../zlib to ./zlib and ../libpng to ./libpng | 05:12.30 |
| | UnderSampled: OK. getting closer -- now I get a bunch of unresolved stuff | 05:14.13 |
| | UnderSampled: apparently this was never tested very well. There's another area to uncomment later in the .mak file to use libpng, and then the jbig2_image_png.c doesn't compile | 05:25.53 |
| UnderSampled | fun :D | 05:26.04 |
| rayjj | at least with current libpng | 05:26.46 |
| UnderSampled | I had read that there was a change in zlib after 2.1.5 that lessed stuff up for a different program | 05:41.47 |
| | rayjj: but I tried the same version as the makefile asked for and it still had the same error | 05:42.12 |
| rayjj | I have it pretty close now (I needed to add an include for pngstruct.h in jbig2_image_png.c and am down to 1 error: unresolved external symbol _CVT_PTR referenced in function _jbig2_png_flush | 06:00.55 |
| UnderSampled | cool | 06:01.42 |
| rayjj | ahh... got it to build -- added: #define CVT_PTR(ptr) (ptr) | 06:04.45 |
| UnderSampled | does it work? | 06:04.52 |
| | I just tried compiling it with the version of libpng they asked for, and it compiled | 06:04.56 |
| | but it wouldn't run | 06:04.59 |
| rayjj | now the 'usage' says: -t <type> force a particular output file format | 06:05.09 |
| | supported options are 'png' and 'pbm' | 06:05.11 |
| UnderSampled | sounds like running to me :D | 06:05.22 |
| rayjj | I ran: jbig2dec -t png annex-h.jbig2 and it generated several FATAL ERROR messages, but it also made annex-h.png and it looks reasonable | 06:08.39 |
| UnderSampled | interesting | 06:08.54 |
| rayjj | so I have 'msvcpng.mak' (made from the msvc.mak) and the two lines added to jbig2_image_png.c -- would you like them ? | 06:11.39 |
| rayjj | asks silly question | 06:11.51 |
| UnderSampled | :D | 06:11.56 |
| | in exchange I'll give you a jbig2 file, sound good? | 06:12.13 |
| rayjj | UnderSampled: OK, get it from http://ghostscript.com/~ray/jbig2dec_png.zip | 06:13.38 |
| | I have to hit the hay -- good luck ! | 06:14.45 |
| UnderSampled | thanks | 06:14.51 |
| | how should I get you the image? :D | 06:15.04 |
| | ah, here we go | 06:15.56 |
| | rayjj: https://dl.dropboxusercontent.com/u/24305465/output.jb2 | 06:15.59 |
| | have a good night ;D | 06:16.02 |
| batsplat | i'm using gs to convert pdf files to eps files. but certain pdf files that have minimal size (like 100kb) end up becoming 75 MB eps files. what could be the reason for this? is there a way of embedding a pdf in an eps so that it does not take much additional space? here is the command i'm currently using: gs -q -dNOCACHE -dNOPAUSE -dBATCH -dSAFER -sDEVICE=epswrite -sOutputFile=eps_file pdf_file | 09:02.25 |
| kens | If the PDF has transparency then it must be converted to an image, which will be done at the specified resolution of the device (for ps2write, 720 dpi unless otherwise specified) | 09:03.12 |
| | You can't embed a PDF in an EPS file, because PDF is not PostScript. Since the PostScript imagin model does not include transparency, there is no option but to render it when transparency is involved. | 09:04.25 |
| | Of course, many PDF files contain transparency operations that have no actual effect, such as a SoftMask with 100% transparency, files produced by Cairo are particularly prone to this. Since tehre's no easy way to tell whether a given transparent operation actually deos something useful this can lead to surprising results. | 09:06.11 |
| | You can try using the -dNOTRANSPARENCY switch to see if it has any effect. | 09:06.27 |
| nsz | hm cant gs be clever about 100% and 0% transparency? | 09:08.21 |
| kens | Sure, if you don't mind preprocessing every transparent operation to see whether it has an effect or not. Of course, this slows down *every* file | 09:08.47 |
| | And doesn't help at all when the PDF file declares the entire page to be in a transparency group | 09:09.16 |
| | Cairo used to decalre every object as 'trnasparent' by defining a transparency group for it. Then simply wouldn't bother doing any transparent operations if the objects were all opaque | 09:10.06 |
| | Detecting that sort of stupidity takes time | 09:10.16 |
| nsz | i see | 09:10.49 |
| kens | Also checking every byte of a large soft mask image (several megabytes, compressed) to see fi any of them is anythign other than 0xff is not exactly wuick. | 09:11.38 |
| | err quick.... | 09:11.49 |
| kens | typing is poor this morning | 09:11.58 |
| batsplat | lemme just quickly check the -dNOTRANSPARENCY switch | 09:12.39 |
| chrisl | PDF transparency is insanely over complicated, and the way it "groups" objects and handles color spaces makes "lazy" application of transparency incompatible with correct output | 09:12.50 |
| | bbiab..... | 09:14.40 |
| batsplat | i tried the switch and it seems to considerably reduce the conversion times | 09:20.04 |
| | also, i used imagemagick to convert the generated eps to png and found that there was transparency maintained | 09:20.22 |
| kens | Well if its not rendering trnapsrency to huge bitmaps I'd expect it to be quicker | 09:20.25 |
| | No there won't be any transaprency in an EPS file, that's not possible | 09:20.46 |
| | Well, except for overprint, but that's not transparency | 09:21.10 |
| batsplat | well, yeah that's correct | 09:21.54 |
| tor8 | avih: js_pushiterator, js_nextiterator | 09:23.21 |
| | js_pushitererator has a 'hasOwnProperty' argument | 09:23.50 |
| batsplat | when converting using gs from pdf to eps, multiple page pdf files end up creating multiple pages in the eps too. is there an option to select just the first page? | 09:58.34 |
| chrisl | batsplat: -dLastPage=1 | 09:59.43 |
| batsplat | thanks a ton! :) | 10:01.03 |
| chrisl | FWIW, you can also do -dFirstPage=x and an appropriate LastPage to select a single page from the PDF | 10:01.53 |
| batsplat | sweet stuff! :) | 10:02.07 |
| kens | And you can do '%d' in the OutputFile to get each page in a separate numbered file | 10:08.42 |
| | Oh he's gone, oh well | 10:08.50 |
| chrisl | kens: tbh, I had almost mentioned %d to him, but decided not to in case it confused matters...... I didn't want us heading down another rabbit hole | 10:41.43 |
| kens | :-) | 10:41.52 |
| | Good that's another annoying bug report closed. | 10:58.42 |
| | Interesting bug fix there chrisl :-) | 11:16.24 |
| chrisl | kens: as it happened, when I looked at a file for someone on IRC yesterday, I found I could reproduce the warning reliably - so I figured I'd chase it down. It's been hanging around long enough, I reckon | 11:19.17 |
| kens | Its been around for ages certainly, I've been meaning to look at it but kept forgetting. Also, kept not having a file to work with | 11:20.01 |
| | Just like the idiot on Bugzilla 'Oh I can't send you the PDF file, but here's some more irrelevant crap, can you fix it nowe ?' | 11:20.39 |
| chrisl | Yeh, but probably like previous ones, even if he gave us the file, we'd not be able to reproduce - hence why I jumped on it when I found I could reproduce it | 11:21.31 |
| kens | You could be correct but I'm getting heartily fde up of the smug 'its confidential, I can't send it to you' that seems to be coming up a lot. So I'm just closing those ones as soon as the reporter says that | 11:22.28 |
| chrisl | I think that's the only option. It's just a stupid statement - especially with the number of times they then manage to come up with an example they can give us | 11:23.16 |
| kens | Yup, it truncates the prcoess of getting a file at least :-) | 11:24.07 |
| chrisl | I don't even mind "how can I send you a file without it being public?"........ | 11:24.50 |
| kens | THat would be OK, I can deal wiht that | 11:25.20 |
| chrisl | Anyway, as I'd just put that fix in, I figured it would be churlish not to point to it in the bug | 11:26.17 |
| kens | Yeah that's fair enough. Unfortunately it makes it look like we were able to fix the bug from his report, when its really just a coincidence. Oh well | 11:27.00 |
| | Oh God our rendering is complicated...... | 11:27.32 |
| chrisl | s/complicated/over complicated | 11:27.54 |
| kens | Yeah :-( I can't keep track of how many 'devices' are lying around | 11:28.31 |
| | But I'm obviously breaking the clist somehow, I wish I could see where | 11:29.02 |
| chrisl | clist == black magic | 11:29.48 |
| kens | I know, I know. Thing is its giving me different answers with my code installed to not being installed. And I can't figure out why. | 11:30.25 |
| chrisl | You've upset the balance, and the dark side is taking over....... | 11:31.01 |
| kens | More like I've broken the thread holding it all together and teh whole ramshackle edifice has collapsed | 11:31.33 |
| chrisl | So, the current "solution" for setting GS_LIB to something vendor specific won't work with the Windows installer....... | 11:32.04 |
| kens | Oh great :-( | 11:32.11 |
| | Well, that's going to cause some problems..... gs_opendevice sets dev->is_open to true, which of course only sets the current device. And I have a nasty suspicion that some devices rely on not being open at certain times. | 12:05.45 |
| chrisl | Usually devices that rely on not being open at given times take action of their own to ensure that's the case...... | 12:08.01 |
| kens | Well some of tehm look OK, such as the pattern accumulator, I'm just not absolutely certain. It looks like my parent device can safely set the child device to open but I'm not certain. One way to find out I guess..... | 12:08.48 |
| chrisl | For example, I seem to remember devices that set is_open() to false before calling gx_default_put_params() so the device won't be automagically closed and reopened | 12:09.39 |
| kens | Yes, thaere are places where that happens. I note that the clist actually sets the dvice_openmethod to 0 sometimes. That looks like such a bad idea..... | 12:10.10 |
| chrisl | Well, again, effectively breaking the API - *again* | 12:11.00 |
| kens | The API is thoroughly and comprehensivly broke, no doubt in my mind at all | 12:11.27 |
| | There are so many places where people have hacked around problems by doing 'special stuff' that is contra to the design, and works more or less by acccidnet, and by the following developers taking more sepcial action to preserve it | 12:13.05 |
| | Well, that gets me a little further along | 12:13.46 |
| | Ah and now I'm ion hte position where fill_rectangle is NULL and causes a seg fault | 12:14.34 |
| | I suspect this is because I've marked the device as open | 12:16.27 |
| | No, its worse than that, I seem to have the wrong device installed...... | 12:21.44 |
| | Should be a mem device and its not | 12:21.54 |
| chrisl | Are you running with anti-aliasing? | 12:23.02 |
| kens | No | 12:23.43 |
| | psdcmyk, the problem is that the meory device (which does the actual rendering) isn't being installed | 12:24.00 |
| | Trying to figure out why, but this is all spidery stuff | 12:24.17 |
| chrisl | Odd..... | 12:24.19 |
| kens | I suspect its because I'm setting the device as open when I shouldn't, or something. | 12:24.52 |
| | Its all crazy crap in here that relies on stuff being done in a certain order, with secret special sauce to make i work | 12:25.22 |
| | Doh, clist_open calls clist_init, to initialise it, which makes sense, then it calls clist_open_outpu_tfile, which calls slist_init() again..... | 12:29.31 |
| chrisl | Yes, crap isn't it? | 12:29.54 |
| kens | Oh and clist_open is one of thoe that saves its 'open' status and sets it to false while it initialises | 12:30.21 |
| | Hmm, still haven't found out where the clist allocates the memory device yet. | 12:31.21 |
| | OK clist_init_data seems to be where it should be done | 12:34.25 |
| | OK so hte problem is that a device can close itself in a put_params call, and the parent needs to check to see if that has happened. If it has, it needs to mark itself as not open, so that the PostScript will reopen the device. Barking mad..... | 15:03.35 |
| | And we still crash :-( | 15:04.07 |
| chrisl | So the *Postscript* will reopen it?? Really??? | 15:04.12 |
| kens | Yep :-( | 15:04.24 |
| rayjj | chrisl: I don't know if you saw in the logs about the bit-rotted jbig2dec with PNG for Windoze. Now that I have it working, I'll go ahead and do it with makefile conditionals, and also fix jbig2_image_png.c | 15:04.31 |
| | chrisl: unless you want to ;-) | 15:04.48 |
| kens | At least I'm getting as far as clist_playback_band now | 15:05.16 |
| chrisl | rayjj: I actually thought we'd decided to deprecate libpng with jbig2dec..... | 15:05.23 |
| rayjj | kens: the close in put_params is the way the device signals that it needs to be reopened (such as if geometry or color_info changes) | 15:06.03 |
| kens | Hmm, still getting 8Mb more in data list file | 15:06.09 |
| chrisl | kens: I *thought* every device that marks itself as closed also took action to reopen itself | 15:06.22 |
| kens | chrisl not in this case | 15:06.30 |
| chrisl | Ick :-( | 15:06.40 |
| kens | It just calls gs_closedevice | 15:06.43 |
| henrys | kens: the open device stuff made peter crazy so your not going to have a good time with this. | 15:06.56 |
| | and he wrote most of it... | 15:07.16 |
| kens | Oh I'm well along now | 15:07.17 |
| | Its nuttier than a sack full of squirrels mind you | 15:07.32 |
| rayjj | chrisl: I don't recall that, but if we want to, then we should actually rip it out. But I prefer to fix it first, then rip it out (that way the git repo will have at least one working snapshot) | 15:07.34 |
| chrisl | henrys: A sure sign it should have been redesigned, I reckon.... | 15:07.50 |
| | rayjj: No I'm fine with fixing it | 15:08.03 |
| rayjj | chrisl: do you need any more info than what I put in the zipfile posted on casper ? | 15:08.27 |
| chrisl | rayjj: I haven't looked - I'll do so shortly | 15:08.49 |
| rayjj | chrisl: note that was with a separate makefile, *not* the way I think it should be done with nmake conditional stuff | 15:09.08 |
| | chrisl: Thanks. | 15:09.16 |
| kens | I don't really understand why a device 'signals' that it needs different geoemrty by closing itself, then waiting for an open to reconfigure itself, rather than simply reconfiguiring itself there and then...... | 15:09.35 |
| henrys | lots of bounties to review from shelly, glad to see he's had time to do some stuff. | 15:09.57 |
| chrisl | henrys: I think the vast majority are "already fixed" | 15:10.31 |
| | rayjj: I think the zip has everything I need - I'll get it done tomorrow...... | 15:11.40 |
| mvrhel_laptop | good morning | 15:54.53 |
| henrys | mvrhel_laptop: 10 minutes vs 1 week, it's only money ;-) | 15:56.13 |
| mvrhel_laptop | :) | 15:56.22 |
| | there are too many damn unit types running around in that code | 15:56.50 |
| | and format | 15:57.18 |
| henrys | mvrhel_laptop: Do you think you should work with either paul or robin together on problems to start? Losing a week of your time is a big deal for us. I guess I should discuss this on skype with the others. | 15:58.36 |
| mvrhel_laptop | well, part of the problem in this case was that it was a new part of the code for me | 15:59.01 |
| | and the spec description sucked | 15:59.10 |
| Robin_Watts_ | henrys: Let's be clear here... Michael did NOT waste a week. | 15:59.22 |
| mvrhel_laptop | I do think I am now more comfortable working in the vml stuff and the chart code | 15:59.35 |
| | so a goal of getting me more familiar with another part of the code was a success | 16:00.03 |
| Robin_Watts_ | He did a weeks worth of work, and I put the cherry on top. | 16:00.20 |
| | It would have likely taken me a week + 10 mins too :) | 16:00.29 |
| henrys | Robin_Watts_: okay fair enough, I guess it's unavoidable but it is tough to swallow for a small company. | 16:01.39 |
| mvrhel_laptop | hopefully my start-up time will not be that long on future issues | 16:02.05 |
| | at least in this part of the code | 16:02.13 |
| henrys | I do feel our geographical challenges make startup quite slow, and folks are hesitatant to ask lots of questions but I can see mvrhel_laptop was asking ... | 16:03.03 |
| | hi fredross-perry | 16:03.54 |
| Robin_Watts_ | It's in the nature of the beast. | 16:03.54 |
| fredross-perry | hi henry | 16:04.04 |
| Robin_Watts_ | I've spent the best part of a week getting to grips with the bidirectional text code. | 16:04.12 |
| | It's slightly tidier than when I started, but no more functional. I'm hoping that I'm zeroing in on a fix, but I wouldn't like to guarantee a timescale. | 16:05.07 |
| henrys | my comments were about bringing folks into the fold and how to avoid them not wasting lots of time working on stuff that's already known by others. I know there is nothing we can do to speedup problems like bidirectional tests that you are working on now | 16:07.51 |
| | s/tests/fonts | 16:08.07 |
| Robin_Watts_ | henrys: Honestly, my knowledge of the Vml stuff is just as minimal as Michaels was. He is now our expert, I think. | 16:08.43 |
| | Joseph and Pete have a better overview of the code than me, certainly. There are certain areas I know "deeply", but there are others I've never ever looked at. | 16:09.35 |
| | henrys: Certainly we take account of who knows what bits of the code before we dole out work. | 16:13.14 |
| henrys | Robin_Watts_: I almost want to have a meeting in Skype before we start each bug given the amount of time likely involved in addressing any of these issues I don't want to impose that kind of overhead though. But it is something to think about a 5 minute discussinon with everyone weighing in on the problem first could be efficacious over the long term. | 16:22.55 |
| Robin_Watts_ | henrys: Sure. We do tend to talk about who is doing what bug next, so we can swap any hints/information etc before people dive off into stuff. | 16:24.06 |
| pedro_mac | thatâs reasonable - I think to date weâve been having some discussion and picking things off which we thought we could handle. Michael had the added bonus of not having worked on any of it before | 16:24.19 |
| henrys | I'll just put this out to all. We have a bunch of bugs marked fixed by shelly - take this one for example: http://bugs.ghostscript.com/show_bug.cgi?id=694202 where we don't know what fixed the problem. I like to know what exactly fixed sutff, should we pay shelly extra to the historical research or leave them and move on? | 17:04.44 |
| chrisl | henrys: I vote leave them and move on: even if he tracks down which commit made the valgrind error disappear, it be hours and hours of work to be sure it really fixed it, and didn't just disguise it. I don't think that's a good use of time | 17:10.05 |
| Robin_Watts_ | henrys: What chrisl said. | 17:10.17 |
| | I guess it depends how much work he'd have to bisect through. | 17:11.02 |
| henrys | well that bug was a crash now that I look more carefully | 17:11.33 |
| chrisl | I don't think the bisect is what would take the time, but proving it really fixed it. | 17:11.56 |
| henrys | I wonder if it no longer gives valgrind errors but still crashes ;-) | 17:12.05 |
| Robin_Watts_ | I think the bisect is the first part of the job. | 17:12.16 |
| chrisl | henrys: FWIW, I do agree that, in principle, it would be nice to know what really fixed it, I just think with *so* many fuzzing bugs, it's not really practical | 17:12.48 |
| Robin_Watts_ | and it's possible that having bisected, it's a trivial, "Oh, I see what they fixed" | 17:12.49 |
| henrys | of course marcos has all the releases compiled. He might be able to track them down fast. | 17:13.00 |
| chrisl | Robin_Watts_: but my suspicion is that often, it won't be obvious - I could wrong, though..... | 17:13.34 |
| henrys | I mean marcos has all revisions compiled | 17:13.47 |
| chrisl | henrys: we could always get Shelly to investigate two or three, see how much time it takes, and judge based on that | 17:14.08 |
| henrys | chrisl: that sounds right. Is there something else this would distract shelly from doing now? | 17:15.33 |
| chrisl | henrys: he's got some stuff going on with the OpenJPEG people but it's still s..l..o..w - I think it will be more dependant on his day job | 17:16.18 |
| | henrys: I can talk to him about it, if you want | 17:16.26 |
| henrys | chrisl: I'm talking to him now negotiating bounties. It would be valuable to have access to marcos' cache of executables for this. | 17:17.12 |
| chrisl | henrys: possibly, but personally, I don't find bisecting takes that long..... | 17:17.56 |
| | Oh, crap, I have to go...... | 17:18.32 |
| | henrys: if you want to talk through with Shelly what we'd want investigated for these bugs, just let me know | 17:19.01 |
| henrys | for the logs the great thing about the exes is you can go linearly and record the status of every revision in the amount of time it takes to do the bisect and possibly miss information as bisect is prone to do. | 17:20.45 |
| UnderSampled | rayjj: I tried the changes you did last night just before you went to bed, but I got the same "cl.exe" crash as before | 18:32.41 |
| | Forward 1 day (to 2014/10/31)>>> | |
IRC Logs