| | <<<Back 1 day (to 2014/08/13) | 2014/08/14 |
| kens | I don't suppose anyone has an ftp password, or a login or something on picas ? | 09:21.49 |
| pedro_mac | kens: no, sorry - just points and casper | 09:22.49 |
| kens | Can you try your points login on picas please ? | 09:23.05 |
| | Marcos may have made them the same. A cusotmer has put files on picas, presumably Marcos gave tghem some access, but I don't seem to have any loginthere | 09:23.35 |
| pedro_mac | kens: just tried to log in - we only have key-based access and that didnât work | 09:24.38 |
| kens | Yeah mine doesn't either | 09:24.46 |
| | Nor does the 'customer' name and password for releases. | 09:25.08 |
| | Looks like I'm going to need marcosw | 09:25.33 |
| tor8 | paulgardiner: ping | 09:51.07 |
| paulgardiner | pong | 09:51.15 |
| Robin_Watts | Home. Stinking cold. Going to bed :( | 09:51.54 |
| tor8 | paulgardiner: how far along did we get with digital signatures? I know we can verify them, but can we create them too? | 09:52.01 |
| paulgardiner | We can create them too | 09:52.22 |
| tor8 | paulgardiner: fantastic! | 09:52.27 |
| paulgardiner | The Android app supports that | 09:52.37 |
| tor8 | paulgardiner: which version of OpenSSL do we need? | 09:53.01 |
| paulgardiner | Currently we can sign only an existing using an existing signature form field. We can't add such a form field (or any type of form field) and we can't just sign a page that has no form | 09:54.03 |
| | tor8: I don't recall. I'm trying to find out. Somehow I don't have it installed here | 09:58.41 |
| | I probably wiped it out with a git clean -fdx | 09:58.52 |
| kens | tor8 paulgardiner Robin_Watts anyone have any access to picas ? | 09:59.08 |
| paulgardiner | Not me sorry kens | 09:59.26 |
| kens | NOt to worry. If I can't find anything byb the ned of the day I'll have to email the customer and ask them to put these files somewhere else. | 09:59.58 |
| Robin_Watts | kens: I don't think so, sorry. | 10:00.59 |
| kens | will have to have words with Marcos after his holiday..... | 10:01.18 |
| tor8 | kens: sorry, not me. | 10:02.00 |
| kens | So its a write-only setup :-) | 10:02.21 |
| tor8 | paulgardiner: don't sweat it. maybe we should move to use LibreSSL now that the thing is usable in a portable setting. | 10:04.29 |
| paulgardiner | A little worrying that I'd have no idea how to build the android app with signature support | 10:05.01 |
| | I do seem to have a git repo called opensll-android | 10:05.20 |
| | And that is 1.0.1e | 10:05.33 |
| Robin_Watts | tor8, paulgardiner: Interesting new MuPDF customer :) | 10:12.14 |
| | or "potential customer evaluating MuPDF", I should say. | 10:12.36 |
| tor8 | Robin_Watts: yes, indeed. I'll forward the mail to you as well, in case you have anything to add. | 10:13.36 |
| kens | I'll CC robin too,I have some questions | 10:14.15 |
| paulgardiner | tor8: I hadn't read to the end of that support request. I could probably put together the missing thirdparty directory if that helps? | 10:15.20 |
| | I thought we used to put these things up on the web site for download | 10:15.45 |
| kens | paulgardiner : its more a question of capability at the moment I think. | 10:15.46 |
| tor8 | paulgardiner: yeah, if you can get it to build and provide more details there I'd be grateful | 10:15.58 |
| paulgardiner | kens: oh okay | 10:16.01 |
| tor8 | paulgardiner: but I don't think it's time critical at the moment | 10:16.15 |
| kens | suspects it might become so.... | 10:16.29 |
| | paulgardiner : might get time off from Smart Office | 10:16.39 |
| paulgardiner | heaven! | 10:17.17 |
| tor8 | kens: good points, both of them. we don't do mixed resolution rendering, or anything fancy like mixing raster and lineart | 10:18.57 |
| kens | Yeah, I thought not. I'll add that on in my reply, also Paul's poitn about adding forms and form fields | 10:19.24 |
| tor8 | kens: just before Raph quit he was prototyping another kind of display list for gs which was based on storing rendered rasters for all text | 10:19.36 |
| kens | paulgardiner : if we had to do signing, and needed to add form and/or form fields, how hard would it be ? | 10:19.50 |
| paulgardiner | kens: I think we['ve done the difficult bit. Actually adding the fields wouldn't be that hard | 10:20.06 |
| tor8 | I'm a bit worried if they're going to start work off the android app, or if they're planning on using their own from the C library | 10:20.21 |
| kens | tor8 Jaws could do it, because the Jaws display list was device independent. The only caveat was that text had to be done at the 'first' resolution, because the bitmaps were cached.... | 10:20.35 |
| tor8 | from the earlier mails, I was under the impression that they wanted a native C library | 10:20.38 |
| kens | paulgardiner : thanks, I'll note that in passing in case they decide its important | 10:20.52 |
| paulgardiner | There's also a problem with verification side in that someone found some files with signatures we cannot verify. openssl moans about them in some strange way that I haven't found time to check out fully | 10:20.53 |
| | But for someone wishing only to verify signatures they create we are fine. | 10:21.19 |
| kens | paulgardiner : bugs are4 a given I htink. We don't need to say that yet :-) | 10:21.32 |
| paulgardiner | I think it was Raed that pointed us at these files | 10:21.38 |
| | kens: good point | 10:21.49 |
| tor8 | paulgardiner: in that case I wouldn't worry, Raed always finds the strangest files | 10:22.00 |
| paulgardiner | :-) | 10:22.14 |
| kens | agrees totally | 10:22.17 |
| | OK I'll write this up and send it round to the MuPDF folks for approval | 10:23.02 |
| | tor8 how much memory does a fz_context use ? If they are worried about memory it seems to me that a lot of independent caches will be a problem. If memory is tight would they be better reusing a fz_context ? I'm guessing not and that if memory gets small they should discard some old ones ? | 10:26.09 |
| tor8 | kens: as long as they discard it in between I don't see a problem. | 10:26.38 |
| kens | OK, but does it use a load of memory for all the cacehs and such ? | 10:27.02 |
| Robin_Watts | They can create a single fz_context, and then clone it for each thread. | 10:27.36 |
| | That means all caches will be shared. | 10:27.47 |
| | The overhead on a single fz_context is quite low (of the order of 1K or something) | 10:28.08 |
| kens | Ah, OK that's probably important information, I didn't realise that from Tor's reply. | 10:28.15 |
| tor8 | kens: a simple program that creates a fz_context and then exits, leaks about 287kb | 10:28.41 |
| kens | Robin_Watts That: 's the context itself though, presumably the caches can grow large, in which case sharing them might be important | 10:29.08 |
| tor8 | I expect the biggest chunk of that to be the hash table array in the glyph cache | 10:29.16 |
| Robin_Watts | tor8: OK, now create an fz_context and then clone it, then exit, and you'll probably leak 288K :) | 10:29.19 |
| tor8 | Robin_Watts: no difference at all :) | 10:30.03 |
| | which probably makes sense if the cloned context is small enough to fit in the same malloc chunk | 10:30.19 |
| Robin_Watts | tor8: Do a memento build. | 10:30.53 |
| | That'll liist the blocks. | 10:31.00 |
| tor8 | Robin_Watts: valgrind --leak-check=full --show-reachable=yes also works well in that respect | 10:31.55 |
| | 4k in the glyph cache, 53k in the error context, 230k for the fz_store | 10:32.37 |
| | which matches what memento says quite well | 10:34.15 |
| kens | paulgardiner : do you have an artifex.com email address ? | 10:36.36 |
| paulgardiner | Yep. Usual sort of thing paul.gardiner@artifex.com | 10:37.13 |
| kens | Yeah fond it now, thanks | 10:37.20 |
| | found* | 10:37.24 |
| paulgardiner | Ooops! irc email address ripping bots will now have my address | 10:37.50 |
| kens | Change it quick.... | 10:38.13 |
| | OK mail sent to tor, ,robin and paul for a review. Feel free to shout at me for mangling your words :-) | 10:39.28 |
| Robin_Watts | tor8: Memento attempts to list the leaked blocks with nesting. And if you've got Memento_label calls in there, you can see what the blocks are too. | 10:40.39 |
| tor8 | Robin_Watts: yeah. Memento is real nice :) | 10:41.04 |
| Robin_Watts | Memento ain't nearly as smart as valgrind, but it does some things nicely :) | 10:41.05 |
| tor8 | I'm just so used to valgrind as a first resort for any kind of trouble | 10:41.32 |
| Robin_Watts | ok, i'm up to date with email and skype. I really am going to bed. | 10:42.40 |
| tor8 | Robin_Watts: sleep tight! | 10:42.53 |
| paulgardiner | kens: can't see any mangling of anything I said. | 10:42.59 |
| | Bye Robin_Watts | 10:43.11 |
| tor8 | kens: the wording about 'discarding' a context is confusing | 10:43.15 |
| | you can always reuse a context between documents; but there is the issue of clearing the caches | 10:43.57 |
| kens | OK can you give me a better phrasing ? TO be honest I'm not really sure about this stuff | 10:44.00 |
| tor8 | which is what you probably meant? | 10:44.05 |
| kens | Yeah I think so. | 10:44.11 |
| | I'll change 'discard' to 'clear caches' then | 10:44.34 |
| tor8 | kens: I don't think we actually have a function to do that :) | 10:44.45 |
| | I'd just say "You can reuse a fz_context from a closed document, but its probably just as cheap (in performance terms) to create a new one." | 10:45.07 |
| kens | Oh..... Doens't that make it hard to reuse a context then ? | 10:45.15 |
| | Yeah I was thinking creating a new one is probably aqbout as fast, I thin I said that somewhere | 10:45.31 |
| tor8 | the stale cached objects will evict themselves eventually | 10:45.34 |
| | but if you really want to be sure, destroying and creating a new context will speed the process | 10:45.54 |
| kens | Seems to me like destroying is the better option. Is that safe with a cloed context ? | 10:46.22 |
| | cloned* | 10:46.29 |
| tor8 | kens: yeah, I'd suggest creating a new context for each document and make sure to close the old context so everything is cleaned up | 10:46.52 |
| kens | Seems like that's the right solution. I'll rewrite with that in place. | 10:47.13 |
| tor8 | kens: we might be able to look at the context allocations and squeeze down those 200kb + 50kb blocks, but that's really more in robin's area | 10:48.21 |
| kens | tor8 if they can't handle multiple 300KB allocations, then it seems to me their only alternative is to clone the exontext and share the caches. | 10:49.03 |
| | If 300KB is a problem, then shaving a few K off isn't going to help much I would think. | 10:49.27 |
| | tor, paul expressed himself happy, and robin has gone to sleep, so I've sent you another revision to look at | 10:55.48 |
| | tor8 : you OK with that email now ? | 11:46.39 |
| tor8 | kens: yes, that looks good | 11:51.53 |
| kens | Thanks Tor I'll send it now then. | 11:52.12 |
| henrys | I let this customer jpx bug fall through the cracks. Iâve never realized how fouled up this stuff actually is. Why not require the dictionary entries be correct vs. the image file. | 14:47.36 |
| | ? | 14:47.39 |
| kens | You mean in PDF ? The image is allowed to override the PDF dictionary. Its insane, and its the only format allowed to do that. | 14:48.18 |
| henrys | kens: itâs worse than that some entries favor the dictionary others the image | 14:50.58 |
| kens | Hmmm, I thought the colour space was the only thing the image dictionary could override, but its been a long time since I looked. It *is* horrifying, I don't understand what Adobe were thinking of when they specified it. I remember it because its the only place where the image dict is allowed to override the PDF dict, and it made a real mess in Jaws getting it to work | 14:52.24 |
| rayjj | kens: did you get into picas ? | 15:00.50 |
| kens | No :-( | 15:00.55 |
| | I sent Marcos an email asking himto move the files or tell me how to get in, but I'v eno idea when/if he'll see it | 15:01.31 |
| rayjj | I am able to using the ftp info that Marcos sent in the email on 7/24, subject "Re: FW: Reg: Ghost Script Queries" | 15:01.46 |
| | that went to support. | 15:01.57 |
| kens | Hmm, let me see if I cna find that, I did search for en email to that customer in the hope that he'd made it public, but couldn't find anything | 15:02.17 |
| rayjj | I downloaded the files, and if you want I can upload them to casper, or log into casper and ftp them into there | 15:03.06 |
| kens | Ah, I had htge right password and the wrong user name. | 15:03.09 |
| | I should be able to get them now | 15:03.16 |
| rayjj | (probably the latter would be faster) | 15:03.17 |
| | kens: let me know if you have a problem getting them now | 15:03.43 |
| kens | Well I cna't connect to picas now..... | 15:04.03 |
| | I'll try sftp instead of firefox | 15:04.15 |
| | Nope, cna't connect. | 15:05.59 |
| | In that password, what is the last character ? IN my email it shows up as 'Acircumflex' | 15:06.30 |
| | OK chrome gets me in | 15:07.58 |
| | I don't see a MuDraw directory there though, do you see it rayjj ? | 15:09.18 |
| rayjj | I just used ftp from the msys shell command line | 15:09.34 |
| kens | And do you see HCL_Testfiles/MuDraw/.... ? | 15:09.55 |
| rayjj | I see MuPDF, but not MuDraw | 15:10.16 |
| kens | Me neither, the files are supposed to be in MuDraw | 15:10.25 |
| | And iI don't see the supposed filenames | 15:10.33 |
| rayjj | kens: nope, me either | 15:11.28 |
| | well, at least you're in :-/ | 15:11.52 |
| kens | OK so I get to send them an email asking politely if they forgot (or were unable) to upload the file. Muppets..... | 15:11.53 |
| | rayjj looks like your problem in bug #695420 is due to the patch in bug #694160. It seems to be because that patch breaks 'quit', if you run with -sOutputFile instead of -o, or use gswin32 instead of gswin32c you don't see the problem (it is there with gswin32c, you just don't see it....) | 15:23.23 |
| | So its not ColorConversionSTrategy causing the error you see. | 15:23.57 |
| tkamppeter_ | mvrhel_laptop, hi | 15:25.35 |
| | mvrhel_laptop, we are waiting for you on the OpenPrinting Summit | 15:26.18 |
| | mvrhel_laptop, for your presentation. | 15:26.34 |
| kens | Oh dear, the depths of these people's stupidity is beginning to get me down. Please come back from vacation soon marcosw :-( | 15:34.31 |
| henrys | kens: I can take them for a while if you want. | 15:40.00 |
| kens | henrys you can look at the files if they get round ot uploading them if you like. It was the inability to comprehend what I thought was a simple statement that was depressing :-( | 15:40.37 |
| henrys | kens: I completely understand | 15:41.22 |
| kens | Also the fact that they sent an email last night saying they were uploading the files, and it wasn't until I said 'so... where are they then ?' that they mailed me to say they couldn't upload them..... | 15:42.13 |
| rayjj | kens: yes, they do seem "challenged" | 15:45.55 |
| kens | 'Special needs' | 15:46.07 |
| rayjj | Are there any issues for them pending that I need to take on ? | 15:46.37 |
| kens | Not as far as I know. | 15:46.48 |
| rayjj | if the latest files show up after you are gone for the day, I'll have a look at them. | 15:47.25 |
| kens | I strogly suspect that the PDF files being 'misidentified as colour' will have images in DeviceRGB and you (I think it was you) already told them that MuPDF doesn't examine the image samples | 15:47.33 |
| | THe other files are (of course!) a totally different topic it appears. Why do people not realise that running on mail threads like this is very confusing ? | 15:48.34 |
| kens | needs to go look at some plumbing | 15:48.43 |
| rayjj | kens: I put that in my closing comment in the bug 695298 | 15:48.57 |
| sebras | tor8: (for the logs) whoa! that glut background was not really gray any more. hello blue! | 15:50.28 |
| rayjj | the "Mix" files claim to be causing an error, but they don't say what they are trying to do with them. I presume mudraw since they are putting them in the Mudraw | 15:50.55 |
| rayjj | is loathe to ask them 'cause I don't want to attract their attention | 15:52.04 |
| | kens: Bug 695240 I get on a 32-bit build on Win 7 | 15:53.51 |
| | (release build) | 15:54.11 |
| kens | Doesn't happen for me, release or debug (after I revert the offending patch) | 15:56.03 |
| | And even before that, I didn't get the corrupted ICC message | 15:56.25 |
| | What was hte SHA you were using ? | 15:57.01 |
| rayjj | kens: I'll retest with HEAD edb5c1a | 16:11.02 |
| | oops, actually 062f4b4 | 16:11.27 |
| | (I have a local patch related to tags) | 16:11.43 |
| kens | I seem to be at 9a8056 | 16:11.45 |
| | "fix conversion of TrueType font with format 0 LOCA tables" | 16:12.07 |
| rayjj | 062f4b4 (origin/master, origin/HEAD) Bug 695423: follow up. | 16:12.28 |
| kens | But note that I had to revert the patch in bug #694160. *Not* the one pointed to by Vladimir Lomov, I think he made a maistake there | 16:12.44 |
| | rayjj : I don't have those last couple yet. | 16:13.11 |
| | I cna get them I guess | 16:13.17 |
| | OK I'm at that SHA with my local changes to remove the .systemexec stuff | 16:14.16 |
| | Clean and rebuild quickly | 16:14.27 |
| rayjj | nope, I still get: .\base\gsicc_manage.c:1084: gsicc_open_search(): Could not find x?<�⺠and it still gets the same Unrecoverable error: undefined in .systemexec.uninstallpagedeviceserverdict | 16:15.06 |
| kens | I'm still rebuilding | 16:15.14 |
| | Did you revert the patch for the .systemexec stuff ? | 16:15.27 |
| | Because with that in there you will get the error I believe | 16:15.37 |
| rayjj | I didn't clean and rebuild. | 16:15.37 |
| kens | doesn't trust VS | 16:15.48 |
| rayjj | I am just running nmake from the command line | 16:16.03 |
| | but I'll rebuild to make sure | 16:16.15 |
| kens | Yeah I don't trust that either | 16:16.17 |
| rayjj | kens: manual rm -fr obj bin now rebuilding | 16:17.06 |
| kens | Seems I did a release build | 16:17.46 |
| | No error message, no corrutped ICC string | 16:18.08 |
| | Ah, NOW I see it | 16:19.08 |
| | But its still just a corrupted message as far as I'm concerned. Your actual error is caused by the commit I mentioned. | 16:19.32 |
| | That's the real problem in this case, a corrupted warning, while undesirable, isn't a big problem | 16:20.13 |
| rayjj | which patch needs to be reverted ? | 16:21.08 |
| kens | http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4fc4b8410d3 | 16:21.27 |
| rayjj | OK, so that patch is flawed. How it causes garbage error messages, I don't understand | 16:30.17 |
| kens | It doesn't cause hte ICC error corruption, I can look at that one, I'm just saying its not urgent. The other one breaks quit and I think that *is* important | 16:30.55 |
| | For me that breaks the use of -o and if you *don't* use -o with the command line executable, you cna't 'quit' out of the GS> prompt either | 16:31.37 |
| | The bonkers message looks like its reading from the name table or something | 16:32.48 |
| | I'm guessing its trying to say that 'quit' is undefined | 16:32.58 |
| rayjj | kens: I'm going to re-open the bug | 16:34.05 |
| kens | I think that's best yes | 16:34.15 |
| rayjj | kens: I mentioned the bug 695240 in my re-open comment | 16:34.50 |
| kens | OK that makes sense, it clearly affects that bug also | 16:35.04 |
| | NB at the time I get the error 'undefined in quit' if I do "systemdict /quit get exec" then it works, which suggest systemdict isn't open O.O | 16:36.36 |
| Robin_Watts | kens: Have you sent that email yet ? | 16:39.35 |
| kens | The one I asked TOr about ? Yes, some time back. SHould have been CC'ed to support so you should have seen it | 16:40.00 |
| kens | is worried now | 16:40.21 |
| Robin_Watts | kens: OK. I'd have reworded the context section a bit. | 16:41.00 |
| | Yes, I see it, sorry. | 16:41.23 |
| kens | Sorry RObin, but you'd gone off. I did pass it through tor again | 16:41.27 |
| | I'm happy to send a followup if there's a problem | 16:41.46 |
| | But it'll have to be quick, I'm about to go out | 16:41.56 |
| Robin_Watts | yeah, I see that. | 16:41.59 |
| | kens: Would you be Ok with me sending a followup to your message dealing just with the context? | 16:42.22 |
| kens | Sure, I'd be happier with someone who actually works with the code responding, or at least correcting my foul-ups | 16:43.00 |
| Robin_Watts | OK, will do that in a mo. | 16:43.15 |
| kens | OK got to go, night all | 16:50.26 |
| mvrhel_laptop | Robin_Watts: are you back? | 17:13.52 |
| | rayjj: how did the pcl monochrome timings go? | 17:14.32 |
| Robin_Watts | mvrhel_laptop: I am. | 17:15.12 |
| mvrhel_laptop | Robin_Watts: question for you | 17:15.16 |
| | did you or rayjj add color detection to mupdf? | 17:15.29 |
| | I seem to remember a discussion about this | 17:15.43 |
| Robin_Watts | tor8 added it. | 17:15.53 |
| mvrhel_laptop | oh ok | 17:15.58 |
| Robin_Watts | mudraw -T | 17:16.04 |
| mvrhel_laptop | mike sweet was asking about it when going out to the cups device | 17:16.35 |
| | I see he has a test-device.c | 17:19.06 |
| Robin_Watts | Yes. The idea is you run the page through the test device, and it keeps track of whether it's used color on a given page or not. | 17:22.20 |
| | It's very simple at the moment. | 17:22.31 |
| mvrhel_laptop | right. ok. I sent Mike Sweet a link to that patch | 17:24.41 |
| | Robin_Watts: how was Scott and Texas | 17:25.06 |
| | hi rayjj | 17:27.10 |
| rayjj | the "gotchas" about mudraw -T are (1) it doesn't have any tolerance and (2) it doesn't inspect images in other than DeviceGray | 17:27.56 |
| | both of which were requirements from ex customer 801 | 17:28.16 |
| mvrhel_laptop | rayjj | 17:28.27 |
| rayjj | hi, mvrhel_laptop | 17:28.32 |
| mvrhel_laptop | it doesnt inspect RGB or CMYK images? | 17:28.42 |
| | I hope it doesnt inspect DeviceGray images | 17:28.53 |
| | those are easy ;) | 17:28.58 |
| rayjj | mudraw doesn't, no. It just says "Must be color" | 17:29.01 |
| mvrhel_laptop | oh ok. well I think this will be fine for what Mike Sweet was looking for | 17:29.29 |
| | he was mainly wondering if a page was all black text, then there is no need to send it as color | 17:29.51 |
| | if I understood what he was asking | 17:30.08 |
| | rayjj: so did the monochrome pcl runs finish? | 17:30.41 |
| Robin_Watts | ray is correct. | 17:31.32 |
| | Those would be easy enough to add though. | 17:31.42 |
| mvrhel_laptop | I would think those would be a bit tedious though | 17:32.44 |
| | gs hooks in to the CM level and watches regardless of object type | 17:33.06 |
| | anyway I think what is there is fine now | 17:34.43 |
| rayjj | mvrhel_laptop: kens and I suspect that the file that we are waiting for from HCL _does_ contain an image that is gray in a colorspace other than DeviceGray. We'll see. | 17:39.17 |
| | mvrhel_laptop: as you say, it's probably easy enough to add | 17:39.36 |
| mvrhel_laptop | that would be Robin_Watts who said that ;) | 17:39.53 |
| rayjj | but it will make it slower, like gs | 17:40.01 |
| | oh, sorry (to both) | 17:40.11 |
| | mvrhel_laptop: yes, the mono pcl finished and I am going to send it (I forgot to last night) | 17:40.40 |
| Robin_Watts | We can probably make the device smart enough to drop out as soon as it knows it's color. | 17:40.43 |
| mvrhel_laptop | at least gs unhooks when it detects. I dont think mupdf does that | 17:40.46 |
| Robin_Watts | So in the case of color pages we drop out quickly. | 17:40.56 |
| mvrhel_laptop | right. that is what gs does | 17:41.01 |
| Robin_Watts | MuPDF will be better than gs in that regard as it can actually stop the page execution. | 17:41.25 |
| mvrhel_laptop | Robin_Watts: also, gs does it while going to the display list | 17:41.43 |
| Robin_Watts | mvrhel_laptop: MuPDF can do it either from the list or from the file. | 17:42.30 |
| mvrhel_laptop | so we just unhook and continue going display list | 17:42.32 |
| | when we detect it | 17:42.39 |
| | Robin_Watts: right. but you are going from the display list to the detection device | 17:43.32 |
| rayjj | mvrhel_laptop: actually, gs continues parsing the page -- it doesn't stop when the page goes to color | 17:43.37 |
| mvrhel_laptop | right. but that is while going to the display list | 17:43.55 |
| | mupdf is hooked in after the display list | 17:44.04 |
| Robin_Watts | mvrhel_laptop: If you're going to the display list then presumably you are going to use the list later. | 17:44.05 |
| rayjj | it would be handy to have gs skip out early, but I'm not sure how to do that | 17:44.13 |
| mvrhel_laptop | what do you mean? | 17:44.24 |
| | gs does stop detecting if it runs into a color | 17:44.35 |
| Robin_Watts | Hence in MuPDF you'd run to the list, then run the list through the detection device (which would bale early) then run it to the appropriate (grey or colour) output device. | 17:44.45 |
| rayjj | once it detects color on a page, stop that page and go to the next | 17:44.52 |
| mvrhel_laptop | why are you stopping the page? do you just want to print out the monochrome pages? | 17:45.20 |
| rayjj | if all you want is the info, and not to render it later | 17:45.22 |
| mvrhel_laptop | oh | 17:45.26 |
| rayjj | that's what HCL wants, AIUI | 17:45.35 |
| mvrhel_laptop | I don't see that as being all that useful. But if that is what HCL wants then I understand | 17:45.53 |
| rayjj | they use the info for billing or something | 17:45.56 |
| mvrhel_laptop | that the mupdf approach is better | 17:46.05 |
| | for this application | 17:46.27 |
| rayjj | mvrhel_laptop: only if it gives results that they want (not call a page color that isn't) | 17:46.38 |
| mvrhel_laptop | true | 17:46.48 |
| Robin_Watts | windows update joy. reboot. | 17:55.36 |
| rayjj | :-( | 17:55.52 |
| | I went through that yesterday | 17:56.04 |
| mvrhel_laptop | rayjj: ok. when you get a chance to send the pcl results please do. thanks | 18:05.44 |
| | i need to reboot this machine too | 18:05.56 |
| | but I will delay a bit longer.. | 18:06.02 |
| | on to SOT | 18:06.22 |
| rayjj | mvrhel_laptop: email sent | 18:06.31 |
| mvrhel_laptop | thanks rayjj | 18:06.38 |
| rayjj | hmm... mudraw on the Pi does PLRM_100.pdf in 33.9 sec and the PLRM_100.xps (created by printing from Acrobat to the "Microsoft XPS Document Writer") in 34.5 sec | 18:16.58 |
| Robin_Watts | rayjj: What command line are you using for mudraw? | 18:18.01 |
| rayjj | build/release/mudraw -r600 -B 661 -m -M ../testing/PLRM_100_mu.pdf > log 2>&1 | 18:18.27 |
| | the 661 is chosen because that has a buffer size of roughly 16m, same as gs -dBufferSpace=16m | 18:19.07 |
| | Robin_Watts: when I was seeing it slower, I had -o /dev/null -F pam (the pam output is horrendously slow) | 18:20.06 |
| Robin_Watts | rayjj: Just double checking that that isn't doing png compression internally :) | 18:21.36 |
| rayjj | Robin_Watts: no, I looked at the code, and without a -o when -m is used, it just renders the page and then skips the output | 18:23.16 |
| Robin_Watts | and -B works? | 18:23.44 |
| rayjj | that's similar to what gs does when -o /dev/null is used, since the bit* and p?m* devices check for OutputFile=/dev/null (and nul:) and skip the fwrites | 18:24.44 |
| Robin_Watts | yeah, seem too. | 18:24.58 |
| rayjj | Robin_Watts: yes -B works, despite a TODO comment | 18:25.02 |
| | I double checked with a debugger :-) | 18:25.18 |
| Robin_Watts | That's what I'm currently doing :) | 18:25.30 |
| | How do those times measure up to what we had before ?> | 18:25.46 |
| | If any are slower than you expect let me know, and I'll double check I haven't broken anything tomorrow. | 18:28.16 |
| rayjj | gxps, has a serious problem with the PLRM_100.xps -- it goes along completing the first 29 pages in 9.6 seconds, then hits a wall and drops to really slow (p 30 takes 8 seconds and all 100 pages takes 396 sec) | 18:33.11 |
| nemo | rayjj: oh hey. that bug you filed. I bisected it down so I could do the conversion over here | 18:46.18 |
| | I mentioned it to kens the other day but... | 18:46.26 |
| rayjj | nemo: please see the logs from today. kens identified the problem as coming from commit: 4fc4b84 Bug 694160: Prevent malicious code being injected into the system. | 18:47.54 |
| | nemo: is that the same commit you found ? | 18:48.04 |
| nemo | ummm | 18:48.11 |
| nemo | checks | 18:48.13 |
| | a2a785d3f6111410198c396fe21813ddd41664be is the first good commit... | 18:48.39 |
| | er | 18:48.42 |
| | last good | 18:48.44 |
| | let's see what comes after | 18:48.47 |
| | commit 7ef7b0d503fee02da12430ee19a394b23b1bfa6f | 18:50.12 |
| | Author: Ken Sharp <ken.sharp@artifex.com> | 18:50.12 |
| | Date: Fri Jan 31 14:50:55 2014 +0000 | 18:50.12 |
| | pdfwrite - colour conversion, consider sRGB to be RGB | 18:50.12 |
| rayjj | nemo: oh, right before the pdfwriter supported color conversion. -- probably a red herring, since before that ColorConversionStrategy really didn't work | 18:50.22 |
| nemo | rayjj: if I update to that one, before.pdf fails in same way | 18:50.24 |
| | ok... | 18:50.32 |
| | rayjj: m'k... | 18:50.42 |
| rayjj | if you look at the file from the conversion of the version that worked, it probably won't be the same | 18:51.12 |
| nemo | same as what, the one that didn't work? ;) | 18:51.47 |
| | oh | 18:51.50 |
| | you mean, same as input | 18:51.53 |
| | dunno. they look about the same | 18:52.18 |
| rayjj | nemo: the one that works having -dProcessColorSpace=/DeviceGray -dColorConversionStrategy=/Gray | 18:52.27 |
| nemo | um... | 18:53.09 |
| | the commandline I'd been trying was | 18:53.14 |
| rayjj | nemo: the bug I opened was that I got spurious error messages out when the params were in the distillerparams dict | 18:53.18 |
| nemo | bin/gs -o x.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -c "<< /ColorImageDict << /QFactor 0.95 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /AutoFilterColorImages false /ColorImageFilter /DCTEncode >> setdistillerparams { .93 div dup 1 gt { pop 1 } if } settransfer" -f /tmp/before.pdf | 18:53.19 |
| | that's the one that had been failing with that message | 18:53.28 |
| | I was just running that one in a git bisect | 18:53.42 |
| rayjj | nemo: really? what message ? | 18:53.49 |
| nemo | which is more annoying than a mercurial bisect btw ⺠| 18:53.52 |
| | .\base\gsicc_manage.c:1050: gsicc_open_search(): Could not find 0��⺠| 18:53.59 |
| | | .\base\gsicc_manage.c:1651: gsicc_set_device_profile(): cannot find device profile | 18:54.02 |
| | that | 18:54.06 |
| rayjj | nemo: not surprised at mercurial being better ;-) | 18:54.21 |
| nemo | lemme recheck | 18:54.26 |
| | rebuilding 7ef7b0d503fee02da12430ee19a394b23b1bfa6f to see what 'sactly happens | 18:55.22 |
| rayjj | nemo: as ken traced the problem to the commit I mentioned (and he did also earlier today) it *could* happen anytime -o is used | 18:55.23 |
| nemo | m'k... | 18:55.40 |
| | well that commit is a much more recent one | 18:55.44 |
| | I was hitting failure on the commandline on a lot of commits back to that Jan 31st one | 18:56.07 |
| | *commandline above | 18:56.17 |
| | I just ran sh autogen.sh/make | 18:56.28 |
| | didn't bother w/ make clean, assumed your build is smart enough | 18:56.35 |
| | they usually are | 18:56.38 |
| | rayjj: ok. so... rebuilt 7ef7b0d503fee02da12430ee19a394b23b1bfa6f | 19:00.14 |
| | and ran | 19:00.21 |
| | gs$ bin/gs -o x.pdf -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -c "<< /ColorImageDict << /QFactor 0.95 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >> /AutoFilterColorImages false /ColorImageFilter /DCTEncode >> setdistillerparams { .93 div dup 1 gt { pop 1 } if } settransfer" -f /tmp/before.pdf | 19:00.22 |
| | ./base/gsicc_manage.c:1050: gsicc_open_search(): Could not find ` | 19:00.27 |
| | | ./base/gsicc_manage.c:1651: gsicc_set_device_profile(): cannot find device profile | 19:00.27 |
| | rayjj: going to update to a2a785d3f6111410198c396fe21813ddd41664be now | 19:00.42 |
| | which was that morning the same day | 19:01.03 |
| | rayjj: aaaand works | 19:07.34 |
| | rayjj: so. yeah, I don't know what the actual problem is, it might indeed be due to some prior bug in one of the parameters there that doesn't show up until that date.. | 19:08.00 |
| | but, definitely shows up prior to 4fc4b84 as far as I can tell | 19:08.42 |
| rayjj | Robin_Watts: I'm running the mudraw times now | 19:10.01 |
| finemann | Hi, I'm using ps2pdf to convert this PS file: http://www-cs-faculty.stanford.edu/~uno/bio.ps.gz For some reason, the fonts don't look as sharp as they'd be in a normal PDF (I can't select the text properly either). I tried embedding the fonts with -dEmbedAllFonts=true, but the fonts look the same. | 19:23.19 |
| | This is what I'm talking about: https://i.imgur.com/Yj3Zsq6.png | 19:23.26 |
| rayjj | finemann: looking at the PS, I see TeXDict begin then %DVIPSBitmapFont: Fa manfnt 12 7 | 19:28.30 |
| finemann | rayjj, sorry I know very little about PS and embedded fonts. | 19:29.24 |
| | Does this mean that I can't convert it properly? | 19:29.47 |
| rayjj | so whatever you used to create this PS file (LaTex ??) rendered the fonts to bitmapped and also munged the text so that it isn't really text | 19:30.02 |
| | finemann: the PDF is "proper" in that it represents what came in | 19:30.34 |
| finemann | rayjj, I don't what was used to create the PDF (it was created by Prof. Knuth). I suppose he used TeX. | 19:30.51 |
| | rayjj, yeah, I mean the bitmap fonts. | 19:31.14 |
| nemo | rayjj: ok. welp. I'm going to free up a channel in IRC here. thanks 'gain for your help | 20:39.03 |
| | rayjj: did you get that stuff prior w/ the 7ef7b0d503fee02da12430ee19a394b23b1bfa6f bug? | 20:39.24 |
| | 'cause you disconnected w/o answering so wasn't sure. | 20:39.35 |
| rayjj | nemo: sorry -- yes, I saw your info, and I can always check the logs. | 20:56.04 |
| nemo | alrighty | 20:57.58 |
| | seeya | 20:58.01 |
| mvrhel_laptop | machine is down to a crawl. time to reboot | 22:21.57 |
| | brb | 22:22.00 |
| rayjj | running mudraw gray (8-bit) to compare to gs.... | 23:11.54 |
| | mudraw rgb done, but the -B param didn't correspond to gs. Of course, since gs uses MUCH smaller bandheight when the page has transparency, j11 will be MUCH slower on page 3 and 8 | 23:13.11 |
| | I'll put all that in the notes (including what bandheight gs chooses for pages) | 23:13.48 |
| | made progress today with the company C SDK and board. Able to get "dbgmon" working. Tonight will be spent reading docs (probably a few times over) | 23:34.36 |
| | Forward 1 day (to 2014/08/15)>>> | |
IRC Logs
