| | <<<Back 1 day (to 2015/08/13) | 20150814 |
| vkkindia | any idea of how to recalibrate or custom dot curve when using tiffsep1 to produce calibrated CMYK tiff files | 06:05.36 |
| | any idea of how to recalibrate or custom dot curve when using tiffsep1 to produce calibrated CMYK tiff files | 06:29.01 |
| chrisl | vkkindia: the threshold arrays are handled in the normal Postscript fashion | 06:40.10 |
| vkkindia | @christ can u give example how to use it in gs | 06:43.36 |
| chrisl | vkkindia: It's Postscript - it's covered in the Postscript Language Reference Manual (PLRM) | 06:44.07 |
| vkkindia | @christ, My aim is to convert pdf to CMYK 1 bit tiff files for output in CTP machines, I need options for how to calibrate the dot % values and also selection of dot shape, screeing techinque AM / FM | 06:51.26 |
| chrisl | vkkindia: halftone screening is really not my area. I would still suggest you need to familiarise yourself with the halftone section of the PLRM (because pretty much anything you do will be driven by Postscript) and then probably look at the tool in "toolbin/halftone/gen_stochastic" for generating the threshold arrays | 06:56.52 |
| vkkindia | thanks @chrisl | 06:58.54 |
| chrisl | vkkindia: also looking at "lib/ht_ccsto.ps" may be off some use | 06:58.56 |
| tor8 | Robin_Watts: welcome back. are you human again today? | 09:26.51 |
| Robin_Watts | Today is the day I attempt to be human, yes :) | 09:27.22 |
| tor8 | Goodie! Then I can pester you all day :) | 09:28.13 |
| | I've updated the opengl-based linux/windows viewer a bit so now it's more capable than the old x11/win32 cruft | 09:29.01 |
| Robin_Watts | It might keep me awake. | 09:29.07 |
| tor8 | just one or two things missing before we can start replacing it, and I can start adding proper form support to the linux viewer | 09:29.42 |
| | the code is on tor/glut if you want to take it for a spin | 09:30.09 |
| Robin_Watts | PC is installing updates. will give it a spin when it reboots. | 09:31.03 |
| tor8 | I've used FreeGLUT as the opengl / cross platform window-system library which has worked great up until I realized that there is no way to access the system clipboard :( | 09:31.06 |
| | so now my choice is, switch to GLFW which has clipboard support, but is ickier to build | 09:31.36 |
| | or hack in clipboard support to freeglut and add it to our thirdparty/ directory | 09:31.47 |
| | I expect that we'll need to add one of these two libraries to thirdparty for windows builds | 09:32.10 |
| | Anyway, the new viewer has an outline view, android-like paging, mouse-over highlights for links, back and forward history navigation | 09:32.57 |
| | and a proper text field for entering search text | 09:33.08 |
| Robin_Watts | tor8: Sounds great. Are there machines where it won't run where the old one would? | 09:33.52 |
| tor8 | I doubt it. Any machine sold the past 15 years has at least an intel integrated graphics chip, and the amount of OpenGL we use is so minimal it'd probably even work with just the software rasterizer. | 09:35.18 |
| Robin_Watts | ok. | 09:36.39 |
| tor8 | I have tested it with GLX to a remote X server over the network, and it works just as well as the old x11 viewer :) | 09:36.47 |
| | I haven't tried with the BSDs, but I expect no significant problems there | 09:38.31 |
| Robin_Watts | paulgardiner: I pointed you at the "MuPDF and questions on multipage" email in support. | 10:02.35 |
| | You replied to the customer, but then you ignored their reply... | 10:02.47 |
| paulgardiner | I just replied to something this morning. Was that it? | 10:03.25 |
| Robin_Watts | Also, someone needs to reply to the mail that Scott forwarded on "Commerical License of MuPDF" on the 3 August. | 10:03.31 |
| | paulgardiner: That was his second question- his first remains unanswered. | 10:04.08 |
| | and you don't mention the idea of banding in your second reply :( | 10:04.59 |
| | Scotts email has to do with the ability to enter Korean in the search for the Android app. | 10:05.52 |
| paulgardiner | I saw the 3/8 email, but didn't see a question. Maybe I should have replied "thanks for the info" though. | 10:07.27 |
| | If I'd though of banding, I'd have mentioned it. So can pnglib take input in bands and compress on the fly? | 10:08.56 |
| Robin_Watts | We don't use pnglib. | 10:09.07 |
| | But mupdf's own png output can work in bands. | 10:09.55 |
| paulgardiner | Well, just what I thought then: if he files a bug then people that know how that stuff works will be able to make a suggestion. | 10:10.52 |
| Robin_Watts | mutool draw -B 128 -o out.png in.pdf | 10:10.54 |
| | If I was a customer and I got your email, the impression I would have is "We can't do it at the moment, maybe we can be prodded into doing it" | 10:11.37 |
| | which would not enthuse me about signing up to a contract. | 10:12.01 |
| | I'll send a followup email. | 10:12.39 |
| paulgardiner | Yes without the simple solution - of which I was unaware - that's our usual response. | 10:13.18 |
| | The whole point of making sure these things go through support is that experts in particular areas can chip in. | 10:14.41 |
| Robin_Watts | I'll send a reply to the Korean input question. I don't anticipate being able to actually give an answer though. | 10:31.42 |
| paulgardiner | Yes, I didn't see that right at the end of the email, although now I can see that's where the question would be. I'm not sure what's being asked. Could it be that they don't know to use utf8? | 10:45.13 |
| Robin_Watts | paulgardiner: I honestly don't know. Let's see what they come back with. | 10:57.54 |
| | tor8: Any chance you could add the freeglut stuff as a submodule on that branch? | 12:17.38 |
| | or is there a reason why that would be bad? | 12:19.05 |
| tor8 | Robin_Watts: I'm going to add it as a submodule so you can build on windows | 12:30.07 |
| | I'm reworking to use GLFW instead of freeglut, since GLFW has clipboard support and might actually support input method editing | 12:30.34 |
| Robin_Watts | tor8: So should I hold off on looking at the branch? | 12:34.44 |
| tor8 | Robin_Watts: no, it's going to take a while | 12:43.24 |
| | do you need a static libfreeglut.a to link with for the windows build? | 12:43.46 |
| Robin_Watts | tor8: You tell me. | 12:44.01 |
| tor8 | it might be quicker for you to just download/build freeglut and add it to the windows project | 12:44.28 |
| | my windows build setup is a bit non-functional at the moment | 12:44.43 |
| Robin_Watts | tor8: I am confused. http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=81aa73b272f350642e490a7c528f06e28a7eb117 | 14:01.03 |
| | How does fz_read_uintX differ from fz_read_uintX_le ? | 14:01.27 |
| | oh, so the suffixless ones are be? | 14:02.06 |
| | Yuck. | 14:02.09 |
| | Why haven't I got cluster emails checking any of sebras' commits? | 14:05.21 |
| kens | Have you checked Gmail spam fgolder ? | 14:05.38 |
| Robin_Watts | kens: I don't use gmail. | 14:05.50 |
| kens | even for Artifex mails ? | 14:06.21 |
| Robin_Watts | indeed. | 14:06.45 |
| kens | THat is, mail to your artifex account | 14:06.45 |
| Robin_Watts | robin.watts at artifex.com just bounces straight out to my own hosting. | 14:07.05 |
| kens | Hmm, and doesn't spam process ? | 14:07.18 |
| | Cos I forward all emails to my own account, and GMail still spam dumps them | 14:07.30 |
| | And I miissed a broken regression test because of it | 14:07.41 |
| Robin_Watts | I don't believe it spam processes. | 14:08.03 |
| kens | It does mine | 14:08.08 |
| | Obviously you may be operatigndifferently | 14:08.21 |
| henrys | kens: did you tell gmail it wasn't spam, mine used to spam regression stuff | 14:08.36 |
| | ? | 14:08.38 |
| kens | henrys, yes I do | 14:08.46 |
| | It doesn't stop it | 14:08.50 |
| | Some days are better than others | 14:09.04 |
| | It doesn't bin *all* my regression mails, only some of them. | 14:09.18 |
| | Whcih in many ways is worse | 14:09.25 |
| henrys | Robin_Watts was 2.74 GB of mail on gmail I assume that's spam. I can't see his email just the stats. | 14:10.01 |
| kens | I believe it is (slowly) getting better but I wish there was a whitelist | 14:10.16 |
| henrys | s/was/has | 14:10.19 |
| Robin_Watts | henrys: Ugh. | 14:10.30 |
| kens | henrys I'm not sure about that | 14:10.31 |
| | I thnk Gmail keeps a copy of all your incoming mail | 14:10.50 |
| | You have to explicitly delete it somewhere, I forget how | 14:11.06 |
| chrisl | Simply setting up a forwarding address doesn't stop it spam filtering. | 14:11.13 |
| kens | GMail says I'm using 6.94 Gb yes my mailboes are all empty | 14:11.18 |
| | chrisl Robin_Watts may be picking up directly, unlike me | 14:11.33 |
| chrisl | kens: popping or IMAPing still means spam filtering happens | 14:12.29 |
| kens | OK that I was unsure about | 14:12.40 |
| | well emptying my Bin recvovered 0.17 Gb.... | 14:13.01 |
| chrisl | if you use imap, you can subscribe to the Spam folder, so you can see the filtered mails in your mail client | 14:13.21 |
| kens | ah if I go to 'All Mail' it has 116,420 mails, I bet that's it | 14:13.31 |
| henrys | I'm going through these fuzzing crashes and can only reproduce a few I wonder if it's hard to redo all these "fuzz" tests. | 14:13.33 |
| kens | henrys we did fix a load of other ones, thye may have already been fixed. | 14:13.50 |
| | Or of course if they are memory problems, they may simply have moved | 14:14.01 |
| Robin_Watts | Ok, there are a load of messages in spam on gmail, but I get them delivered anyway. | 14:14.19 |
| kens | Whcih is why we really need a SHA1 hash of the code being used for fuzzing | 14:14.22 |
| henrys | one didn't crash but I did find it with valgrind... I do expect valgrind to hit them but even that can go wrong I suppose. | 14:15.34 |
| chrisl | Valgrind is wrong more often than not, for the fuzzing files | 14:16.16 |
| Robin_Watts | Did anyone get a regression test mail about mupdf commit 642a59a4de683a1359733229943be285e3e45c4f ? | 14:17.15 |
| kens | Sorry I delete the cluster test emails | 14:17.38 |
| chrisl | "Convert argv to utf-8 and use regular getopt"? | 14:17.43 |
| Robin_Watts | chrisl: No, that's a later commit that mentions the earlier one in the regression results. | 14:18.05 |
| chrisl | No, oh that is weird!! | 14:18.08 |
| Robin_Watts | I suspect that the cluster is not sending emails for commits from people it doesn't recognise. | 14:18.36 |
| chrisl | "Add support for parsing GIF images." | 14:18.39 |
| Robin_Watts | chrisl: That's the one. | 14:19.01 |
| rayjj | kens: BTW, the trailing (bogus) -c on that user's gsArgs.Add("-dMaxPatternBitmap=67108864 -c"); doesn't do any harm since the next arg starts with '-' gsArgs.Add("-sCompression=none"); and any naked '-' terminates the sending of strings to the PS interp | 14:19.02 |
| chrisl | Robin_Watts: Yes, I have the cluster mail | 14:19.14 |
| kens | rayjj I was uncertain about that, I did mention it | 14:19.26 |
| Robin_Watts | OK, so it's just me that didn't get it. That's less wierd. | 14:19.27 |
| | weird. | 14:19.35 |
| kens | rayjj I still thnk its a bad idea and should be discouraged | 14:19.51 |
| | and teh rest of his config is largely lunacy | 14:20.04 |
| chrisl | Robin_Watts: about a third of the commit regression mails were being spam filtered for me, until I created a custom filter which specifically excludes them from spam scanning | 14:21.00 |
| rayjj | kens: agreed. Hard to tell where people come up with some of these options. | 14:23.44 |
| kens | rayjj you should see some of the ones on Stack Overflow :-) | 14:24.51 |
| Robin_Watts | chrisl: I have such a filter already, I believe. | 14:27.53 |
| | Certainly they are not in my spam bin. | 14:28.02 |
| kens | You could check your 'All Mail' and see if ts in there | 14:29.04 |
| | Well I've deleted everythign I can find in my Gmail and it *still* says I'm using 6.77 Gb I have no idea where | 14:31.00 |
| rayjj | kens: why do you care ? | 14:31.46 |
| kens | D'oh deleting the 'all mail' messages just moved them to the bin, now I have to delete them again..... | 14:32.00 |
| | rayjj we have a limit of 30Gb | 14:32.11 |
| Robin_Watts | I don't believe I have any regression emails in All Mail at all. | 14:32.32 |
| kens | Odd, I did until I deleted them, lots and lots of them | 14:32.50 |
| Robin_Watts | Maybe those get sent direct to my wss address. I was using @wss before I was using @artifex | 14:33.19 |
| kens | Its possible, GMail seems to be, well, arcane..... | 14:34.07 |
| Robin_Watts | GMail exists purely to feed the google monster. | 14:35.15 |
| | or it is the Alphabet monster now ? | 14:35.24 |
| kens | cookie monster :-) | 14:35.51 |
| chrisl | henrys: possibly the fuzzing tests pre-date using FAPI for PCL, that might explain the different behaviour with Bug 694683 | 14:36.58 |
| henrys | the corrupt font error happens when it is parsing the dl'd font, it's been there for ages. | 14:39.28 |
| chrisl | Oh, I thought you were saying that the invalid_font error *wasn't* happening | 14:40.04 |
| henrys | chrisl: sorry I guess that sentence was a bit ambiguous | 14:42.33 |
| rayjj | one last regression run to check to make sure I haven't tweaked anything, then push fast HT changes | 14:45.17 |
| henrys | I'm thinking about tacking on a week in Cuba to this Bahamas trip the way things are going... US flag raised at the U.S. embassy at cuba, first time in 50 years | 14:48.44 |
| kens | Are you allowed in yet, or still need an 'educational' component ? | 14:49.05 |
| Robin_Watts | henrys: Going to put faces to the names, eh? | 14:49.43 |
| henrys | I want to see the cars ... | 14:50.07 |
| | I don't know .. I have a friend US citizen that goes quite a bit by flying to some central american country first, but I don't know how exactly that works. | 14:52.02 |
| kens | is unsure | 14:52.17 |
| | Given it doesn't affect us Commie Europeans :-) | 14:52.33 |
| henrys | well there is the obligatory mob/syndicate/thuggery as things shift from left to right... we'll see how that goes. | 14:58.23 |
| pedro_mac | I reckon its all being lined up to be the next big theme park | 14:59.01 |
| henrys | hard to predict. it's amazing how these islands can have such different fates - haiti vs dominican repuplic for example. | 15:09.31 |
| rayjj | JUST A REMINDER: I just pushed the fast HT fixes that cause 1026 differences, so make sure and update your tree before doing any regression tests so you don't see all of those diffs | 15:14.14 |
| | I think I have a laptop battery problem. it used to charge while I was doing things (as long as I was using the 90w charger), but now it doesn't :-( | 15:16.25 |
| Robin_Watts | Hmm. Just spotted a thinko with the gproof stuff in mupdf. | 15:24.09 |
| | Aha, a fred. | 15:24.22 |
| fredross-perry | Robin_Watts: I am going to see if I can get proofing going in the mac/linux versions of gsview while I am at it. Iâm not using the gs api yet; is the a command-line way to generate the gsproof file? | 15:24.23 |
| henrys | Robin_Watts: your facebook post reminded me, I ended up getting a solar keyboard, haven't had a problem with it. Of course display light may have a few more photons then indirect light in a bathroom... | 15:24.42 |
| Robin_Watts | fredross-perry: mutool draw -o out.gproof in.pdf | 15:24.43 |
| fredross-perry | thanks | 15:25.22 |
| Robin_Watts | I just spotted a thinko with the gproof separations stuff. | 15:25.43 |
| | You can open a gproof file, then load the page. | 15:25.59 |
| | The number of separations isn't valid until you've run the page at least once. | 15:26.21 |
| | Not immediately sure how to fix that. | 15:26.40 |
| | except possibly to note it as a limitation. | 15:27.18 |
| | fredross-perry: I'm seeing the blank rendering too. Just looking into that now. | 15:29.17 |
| fredross-perry | swell. Hopefully itâs something simple. | 15:29.36 |
| | Also, is there/can there be a way to get information about the separations themselves? In particular, itâd be swell to know what color to associate with each, and maybe a name. | 15:30.35 |
| Robin_Watts | fredross-perry: That's there, I think. | 15:32.20 |
| fredross-perry | so I can look at exposing that up tino core then | 15:32.46 |
| | *into* | 15:32.49 |
| Robin_Watts | I thought I'd done that. | 15:33.03 |
| fredross-perry | lemme check... | 15:33.15 |
| Robin_Watts | MuPDFCore.getSep | 15:33.38 |
| | Returns name, and equivalent RGBA/CMYK values. | 15:34.00 |
| fredross-perry | oh sorry I see it. | 15:34.05 |
| Robin_Watts | or at least it should. Standard 'untested' comments apply :) | 15:34.12 |
| rayjj | is anyone else using VS 2015 ? | 15:46.55 |
| mvrhel_laptop | Hi Robin_Watts | 15:49.03 |
| | are you still awake? | 15:49.07 |
| Robin_Watts | mvrhel_laptop: I am. Can you give me a bit to sort some stuff out here? | 15:49.33 |
| mvrhel_laptop | ok. no problem | 15:49.51 |
| | Robin_Watts: I have an appt. I need to get to right now We can talk about this early next week if you are off when I get back. | 16:08.42 |
| Robin_Watts | mvrhel_laptop: When you get back. | 16:09.04 |
| | I'll be here a while | 16:09.09 |
| mvrhel_laptop | ok. thanks | 16:09.16 |
| mupdfhelpneeded | Hey guys, how do you save a document in mupdf? I'm trying to fill a form and then save it. | 16:13.01 |
| jogux | mupdfhelpneeded: which OS? | 16:14.20 |
| mupdfhelpneeded | I'm on Ubuntu 14.04 | 16:15.39 |
| Robin_Watts | mupdfhelpneeded: Form filling support for mupdf is not great on linux. | 16:23.48 |
| | It's implemented in the core library, but only really properly exposed in the app for android. | 16:24.24 |
| mupdfhelpneeded | Robin_Watts: Ahh I see...that's unfortunate | 16:24.33 |
| Robin_Watts | mupdfhelpneeded: Have you managed to fill in any forms? | 16:24.56 |
| mupdfhelpneeded | Yes | 16:27.01 |
| | It's kind of weird how it works though..I click an area such as first name, then in the terminal I get a prompt that says [(null)]. I hit enter and then I fill in data, hit enter again and it appears on the pdf | 16:27.41 |
| Robin_Watts | mupdfhelpneeded: Yeah, that's really just a hack so we could see that it was working. | 16:28.04 |
| | On Android, when you close the window it gives you an option to save the filled in form back. | 16:28.28 |
| | I don't know that that is implemented on linux. | 16:28.36 |
| mupdfhelpneeded | Oh ok, yea if I hit 'q' then nothing is saved | 16:29.57 |
| Robin_Watts | mupdfhelpneeded: so, that's the state of play. | 16:30.27 |
| | If you want to try to improve it, feel free. | 16:30.39 |
| mupdfhelpneeded | Robin_Watts: Alright, I might take a look. Thanks for the info. | 16:31.07 |
| Robin_Watts | chrisl: still here? | 16:53.22 |
| | Anyone fancy reviewing this: http://git.ghostscript.com/?p=user/robin/ghostpdl.git;a=commitdiff;h=c50adbe72f3e8a07c96127a4df9d78b422acf22a | 16:53.48 |
| | Just a tweak to the gs msvc files so that debugging can find the executables with the new directory restructure. | 16:54.14 |
| chrisl | Robin_Watts: Looks fine | 16:59.55 |
| Robin_Watts | Ta. | 17:00.04 |
| chrisl | Hmm, I always seem to have to set the executable for the debugger, so I just assumed it wasn't set before.... I wonder what's going on there..... | 17:01.25 |
| Robin_Watts | $(TargetPath) is set to the value given in Properties -> NMake -> Output | 17:02.26 |
| | And the Properties -> Debugging -> Command is set to $(TargetPath) by default. | 17:02.52 |
| chrisl | I assumed that stuff wasn't set because there's two exes - not that it matters | 17:04.07 |
| Robin_Watts | Well, that's odd. | 17:22.37 |
| | I run debugbin/gswin32c.exe -sDEVICE=gproof -r72 -o out.gprf -dFirstPage=1 -dLastPage=1 ../MyTests/tiger.pdf and it makes me an out.gprf file with the equivalent colors in. | 17:23.34 |
| | I copy that binary to the mupdf directory and rerun it, and I get 0's for the equivalent colors. | 17:23.55 |
| | oh, I'm so stupid. | 17:27.47 |
| mvrhel_laptop | Robin_Watts: I am back | 18:32.20 |
| Robin_Watts | mvrhel_laptop: Hi | 18:32.49 |
| mvrhel_laptop | is this a good time? | 18:33.13 |
| Robin_Watts | Sure. | 18:33.19 |
| mvrhel_laptop | ok. So with gsview, I have my own interface to call ghostscript to generate the gprf file that I need for a particular page and a desired resolution | 18:34.00 |
| | Currently that can't be opened directly with mupdf | 18:34.27 |
| | as it can only open a gproof file | 18:34.37 |
| Robin_Watts | mvrhel_laptop: I'm not following. | 18:35.13 |
| mvrhel_laptop | so there are 2 files | 18:35.21 |
| | in your design | 18:35.33 |
| Robin_Watts | Yes. | 18:35.38 |
| mvrhel_laptop | in the design it appears to me that mupdf is using a call to gs to generate the gprf file | 18:36.04 |
| Robin_Watts | You open a pdf file, then when someone enters the 'proof' mode, you generate a gproof file, and open that. | 18:36.10 |
| | You then have a mupdf instance running that's viewing that gproof file, and *THAT* calls gs as required. | 18:37.10 |
| mvrhel_laptop | I understand | 18:37.47 |
| | however in gsview I think we want something a bit different | 18:38.10 |
| Robin_Watts | Currently, there are 2 ways that mupdf can call gs. | 18:38.30 |
| mvrhel_laptop | I see that | 18:38.41 |
| | let me finish please | 18:38.47 |
| Robin_Watts | Sure, sorry. go on. | 18:38.53 |
| | (IRC needs an 'mvrhel is typing...' thing :) ) | 18:41.55 |
| mvrhel_laptop | So in gsview, we have a pdf file that is already opened and we are viewing it. gsview knows the page sizes of all the pages in the pdf file. gsview also has a very nice setup already to call ghostscript to generate a gprf file for a particular page at a specified resolution. I would like to be able to be able to not have mupdf generate the gprf file but be able to let it know that that... | 18:42.02 |
| | ...page is already run and available | 18:42.04 |
| | sorry | 18:42.07 |
| | so in mupdf right now generate_page does the call to gs with either the api or the process to have it create the gprf file | 18:42.44 |
| | what if I already have the file | 18:42.52 |
| malc_ | Robin_Watts: just visit a busy channel and you will regret ever making this remark | 18:44.44 |
| Robin_Watts | If I'm understanding you correctly, you're suggesting losing the gproof file, and letting gsview handle the calling of ghostscript, and then just having mupdf read the gprf files directly. | 18:44.54 |
| mvrhel_laptop | yes | 18:45.00 |
| Robin_Watts | mvrhel_laptop: Well, that kinda defeats the point of using mupdf at all. | 18:45.14 |
| mvrhel_laptop | not really | 18:45.24 |
| Robin_Watts | MuPDF handles the caching of images from each page within the store. | 18:45.56 |
| mvrhel_laptop | It also is handing the separations desired and I would hope taking advantage of the tiles and what is desired to be rendered inside the bounding box etc | 18:47.21 |
| Robin_Watts | yes. | 18:47.34 |
| mvrhel_laptop | I suppose I would look into seeing if I could add yet another gs call to get back to gsview to handle the call | 18:48.03 |
| | that is in render page add in some code to call the the dll that gsview has | 18:48.33 |
| Robin_Watts | mvrhel_laptop: Why should you need to add anything? | 18:48.37 |
| mvrhel_laptop | if you are fine with that | 18:48.39 |
| | well I don't want to call the process | 18:48.56 |
| Robin_Watts | You have a gs dll around already, right? | 18:48.57 |
| mvrhel_laptop | and I have call backs set up for gs api | 18:49.15 |
| Robin_Watts | and that provides exactly the interface that mupdf needs. | 18:49.22 |
| mvrhel_laptop | to get the std output | 18:49.23 |
| | and let the user know if there is an issue | 18:49.34 |
| Robin_Watts | Why can't the existing mupdf dll call the existing gs dll using the existing code? | 18:50.21 |
| | (i.e. just build with SUPPORT_GPROOF=1 USE_GS_API=1) | 18:50.39 |
| mvrhel_laptop | how does it currently find the dll? | 18:50.39 |
| Robin_Watts | waves hands - the usual way | 18:50.54 |
| mvrhel_laptop | ok | 18:51.01 |
| Robin_Watts | Can one DLL call another DLL that's loaded normally? | 18:51.23 |
| mvrhel_laptop | Robin_Watts: let me do some work on this and then you can review | 18:52.07 |
| Robin_Watts | I fully expect the code to need small tweaks per-platform. | 18:52.11 |
| | mvrhel_laptop: Are you imagining that when the user hits the 'proof mode' button the existing window change it's behaviour? | 18:53.32 |
| | s/change/will change/ | 18:53.50 |
| | or are you imaging that when you hit the 'proof mode' button, a new gsview window will open up containing the proofed file ? | 18:54.20 |
| mvrhel_laptop | Robin_Watts: I was concerned that for gsview, speed is going to be an issue and I am not sure that continuous scrolling is going to be possible. | 18:54.54 |
| | without some serious UI lag | 18:55.03 |
| Robin_Watts | mvrhel_laptop: Why? | 18:55.15 |
| mvrhel_laptop | it someone is zipping through the pages | 18:55.16 |
| | well because we are having to generate each page with gs and mupdf | 18:55.51 |
| | in addition to reading and writing to the disk | 18:56.01 |
| | it has to be slower than rendering right to a memory bit map | 18:56.14 |
| Robin_Watts | mvrhel_laptop: If that affects the UI speed, then the code is structured wrong already. | 18:56.20 |
| mvrhel_laptop | well when I say UI speed, I guess I spoke wrong | 18:56.41 |
| Robin_Watts | The existing way this stuff is all written has been done to avoid UI lag due to rendering times, right? | 18:56.48 |
| | When you flick pages, the UI can instantly display a blank page (or a thumbnail) of the correct size, right? | 18:57.12 |
| mvrhel_laptop | yes | 18:57.13 |
| Robin_Watts | So 'lag' in that sense shouldn't be an issue. | 18:57.24 |
| | There may be rendering delays when waiting for the actual page. | 18:57.40 |
| | But that will be the same regardless of the mechanism we use to call gs, right? | 18:57.52 |
| mvrhel_laptop | but if it launches rendering jobs and someone has moved on to the next page already and then the next and then the next it could get overloaded | 18:58.15 |
| Robin_Watts | Why is that any different to the existing way things work? | 18:58.40 |
| mvrhel_laptop | Robin_Watts: just due to the fact that it is going to take much longer to do these pages | 18:58.58 |
| | due to gs and mupdf doing the drawing in addition to the disk writing/reading | 18:59.10 |
| | it is just longer | 18:59.20 |
| | thats all | 18:59.22 |
| Robin_Watts | Right. | 18:59.26 |
| fredross-perry | mvrhel_laptop: Robin_Watts: I doubt users will want to go zipping thru pages while looking at separations. Rather they will probably want to examine the seps for a single page in detail. So Iâd be in favor of proofing one page at a time, in a separate window. | 18:59.57 |
| Robin_Watts | I don't see how changing the structure of the system to make mupdf open gprf files rather than gproof ones will make that any less of a problem. | 18:59.58 |
| | fredross-perry: I don't see people zipping through pages either. | 19:00.20 |
| mvrhel_laptop | Robin_Watts: ok 2 things | 19:00.26 |
| | The opening of gprf vs gproof is a different thing | 19:00.42 |
| Robin_Watts | I can imagine them carefully looking at each one in turn though. So being able to page flip is a plus, rather than forcing them to exit/ change page/reenter the proofing mode. | 19:00.51 |
| mvrhel_laptop | Robin_Watts: yes page flip is needed | 19:01.11 |
| | I agree | 19:01.25 |
| | for gsview, I was going to have the proof mode a bit different though | 19:01.43 |
| | instead of continuous scrolling the pages would be shown as individuals | 19:02.04 |
| | but I suppose I could see how it behaves in continuous scrolling | 19:02.26 |
| | anyway, let me work on the interface to gs in mupdf and have you review my changes. | 19:02.54 |
| Robin_Watts | I was about to say "can't we try it as continuous and worry about changing it if it proves to be too slow" :) | 19:02.59 |
| | mvrhel_laptop: What are you forseeing yourself having to change in mupdf? | 19:03.21 |
| mvrhel_laptop | yes | 19:03.27 |
| fredross-perry | If it takes âa whileâ to generate the proof of each page (it wort of looks that way on my tablet) then maybe you want to proof âon demandâ as it were. So, go into a âproov viewingâ mode, and generate a proof file for each page as you need them. | 19:04.06 |
| mvrhel_laptop | That was my original plan | 19:04.32 |
| Robin_Watts | fredross-perry: I don't see how what we have now isn't 'on-demand' ? | 19:04.52 |
| | The .gproof file is created instantly. no noticable lag there. | 19:05.18 |
| | Then we load pages 'on demand' from that. | 19:05.28 |
| | They are generated just as we need them. | 19:05.34 |
| fredross-perry | OK so thatâs cool. In the Android build, there is a significant delay after proofing, before I see the page again. Not sure what that time is made of. | 19:06.17 |
| Robin_Watts | That's the time taken to proof that page. | 19:06.34 |
| mvrhel_laptop | that is gs running the file and then mupdf opening it | 19:06.38 |
| Robin_Watts | Currently it's set to work at 300dpi. That could easily be a config option. | 19:07.06 |
| fredross-perry | When you say âproofing the fileâ, thatâs not âgenerating the .gproof fileâ, then? | 19:07.27 |
| mvrhel_laptop | Robin_Watts: so am I able to generate pages at different resolutions or is that fixed? | 19:09.04 |
| Robin_Watts | fredross-perry: No. The .gproof file is generated instantly; it's a simple file that says "This is the PDF file that we want to proof, it has X page of the following sizes..." | 19:09.35 |
| mvrhel_laptop | I would have thought the gproof file would have the "native" sizes of the pages but I would be able to run pages at different resolutions | 19:09.35 |
| Robin_Watts | and the gproof file specifies the required proofing resolution. | 19:10.11 |
| fredross-perry | OK. So what do we think is taking âa whileâ then, when I press the proofing button in Android? | 19:10.15 |
| mvrhel_laptop | ugh | 19:10.17 |
| Robin_Watts | fredross-perry: Loading/Running a page from the gproof file causes mupdf to call out to gs for it to render the .gprf file. | 19:11.03 |
| | (.gprf != .gproof) | 19:11.11 |
| | Then mupdf loads the data from that file for display. | 19:11.25 |
| | It's gs rendering to the .gprf and mupdf reading the .gprf back in that takes time. | 19:11.51 |
| | i.e. exactly the page specific work. | 19:12.11 |
| fredross-perry | So I think letâs definitely disconnect that from scrolling, in the user experience. | 19:12.20 |
| mvrhel_laptop | That was my thought | 19:12.37 |
| Robin_Watts | fredross-perry: As I said before, if the existing code doesn't already have that disconnect in, then the existing code is wrong. | 19:12.51 |
| fredross-perry | I havenât tried it with a multipage doc, .... | 19:13.19 |
| Robin_Watts | If a page takes 10 minutes to render, that should not affect the speed/smoothness with which you can scroll between pages. | 19:13.42 |
| mvrhel_laptop | I was just about to write that | 19:13.54 |
| | but you do want someone to know this is a "special" case | 19:14.10 |
| Robin_Watts | It *will* affect the length of time it takes for a sensible display to appear within the blank page placeholders, but that's an acceptable thing in 'proofing' mode, I feel. | 19:14.14 |
| mvrhel_laptop | and that it may take a bit | 19:14.15 |
| | having a different display mode can set that expectation | 19:14.35 |
| | someone scrolling through a 1000 page doc wondering why their pages are not appearing is frustrating | 19:15.02 |
| Robin_Watts | mvrhel_laptop: We could have a 'proofing' thumbnail rather than the usual blank page or something. | 19:15.02 |
| | mvrhel_laptop: I don't think that's really an issue here. | 19:15.15 |
| mvrhel_laptop | why? | 19:15.19 |
| Robin_Watts | People will have taken the explicit step of turning on proofing mode. | 19:15.29 |
| fredross-perry | So, FYI, I am âproofingâ a three-page PDF file thatâs all-text. it took about 30 seconds. And the display shows me three pages. I swipe to show page 2, and I am in for another 30 seconds it seems. | 19:15.39 |
| Robin_Watts | They know that that means it will take longer to get pages. | 19:15.45 |
| | fredross-perry: Yes. | 19:15.49 |
| | But if you swap back to page 1, it should be pretty instant. | 19:16.02 |
| fredross-perry | yes it is. | 19:16.10 |
| mvrhel_laptop | and that is going to be true in the windows case too | 19:16.42 |
| Robin_Watts | Returning to mvhrel's 'ugh'... | 19:16.50 |
| mvrhel_laptop | oh yes the resolution | 19:16.57 |
| | so if someone zooms in deeply | 19:17.05 |
| fredross-perry | I wonder why âproofingâ takes so long, when simply rendering a page at, say, 300 dpi, is very quick. | 19:17.11 |
| mvrhel_laptop | I need to generate a new gproof file? | 19:17.18 |
| Robin_Watts | mvrhel_laptop: The idea is that you set the resolution you want to proof at. | 19:17.38 |
| mvrhel_laptop | I see. so that should be a UI setting | 19:17.54 |
| Robin_Watts | Part of the desire for proofing is that you want to see how it all behaves at a specific resolution. | 19:18.00 |
| mvrhel_laptop | that simplifies things | 19:18.02 |
| Robin_Watts | Think of the fill rules etc. | 19:18.04 |
| mvrhel_laptop | yes | 19:18.07 |
| Robin_Watts | You have the freedom to zoom in on edges etc to check for fills etc. | 19:18.27 |
| mvrhel_laptop | ok fair enough | 19:18.41 |
| Robin_Watts | So yes, either a global setting. | 19:18.43 |
| | Or a popup value when you hit 'proof'. | 19:18.53 |
| mvrhel_laptop | ok I understand the reasoning there | 19:19.11 |
| Robin_Watts | I could imagine you hitting the proof button and then being asked what resolution? (either high/low or custom or something) | 19:19.38 |
| | fredross-perry: As to speed... | 19:20.42 |
| fredross-perry | or, you get 300 dpi to start, and when you go to choose a new resolution, all pages require re-rendering (but one ata time of course) | 19:21.06 |
| Robin_Watts | fredross-perry: Asking at the start of proofing seems reasonable to me (and that fits better with the fact that the resolution is baked into the .gproof file) | 19:21.52 |
| fredross-perry | The UI should not necessarily reflect the mechanics of getting a proof made, however. | 19:22.45 |
| | If speed were not an issue, I like the idea of reasonable default behavior, if the user changes nothing. | 19:23.23 |
| Robin_Watts | True, but in this instance the UI and the underlying mechanics would seem to marry up nicely I think. | 19:23.27 |
| | The purpose of a proof is to verify what final output will be. And the resolution is a fundamental part of that. | 19:23.54 |
| fredross-perry | Iâm speaking more philosophically. User-centric. | 19:24.00 |
| Robin_Watts | I'd imagine most users would set that once and never vary it. | 19:24.06 |
| fredross-perry | well, true enough. | 19:24.10 |
| Robin_Watts | Yes. I accept that at times we programmers tend to create UIs based on what happens below the surface when that's not appropriate. | 19:24.34 |
| fredross-perry | question to ask, who are the âproofersâ and what are they doing, and how do they want to do it? | 19:24.54 |
| Robin_Watts | The proofers are people running print shops. | 19:25.23 |
| fredross-perry | anyway, if you figure out the separation enble/disable thing, let me know. I have a button that cycle through the 4 seps, and I can see that I am getting something thatâs not pure white. But itâs mostly white. | 19:26.05 |
| Robin_Watts | The idea is that before they run a huge print run on a printer, they can 'proof' the final file on a tablet to have confidence that they are not about to print stuff that will look wrong. | 19:26.06 |
| fredross-perry | heretical statement #1: why are they doing this on a tablet at all? | 19:27.36 |
| | lunch, bbiab | 19:28.07 |
| mvrhel_laptop | Oh. Robin_Watts, we need to add a proofing profile to the gproof content | 19:28.08 |
| | and this needs to be handed to gs | 19:29.16 |
| | I will add that in the code and update the twiki if you are fine with that | 19:29.42 |
| | so fz_write_gproof_file will need to have an additional parameter | 19:31.20 |
| | if thats ok with you | 19:31.30 |
| | oh, actually it needs two profiles | 19:32.03 |
| | one for the target device and one for the proofing device | 19:32.23 |
| | so we have the "printer" that is would be printed on, the resolution and then the profile for our proofing device | 19:33.00 |
| Robin_Watts | mvrhel_laptop: OK. | 19:34.57 |
| | fredross-perry: The idea is that they can have a tablet with them on the print shop floor to avoid having to run back out to the back office to use a PC every time. | 19:38.08 |
| | fredross-perry: I have made progress on that. | 19:38.32 |
| | I had screwed the separation reading code up. | 19:38.44 |
| | and the separation assembly code. | 19:38.51 |
| | I am preparing commits now. | 19:38.57 |
| | fredross-perry, mvrhel_laptop: OK, so all the commits on robin/master except the last 2 are good to go. | 19:44.55 |
| mvrhel_laptop | ok | 19:45.09 |
| Robin_Watts | fredross-perry: That should get you something to work with. | 19:45.14 |
| | mvrhel_laptop: The colors I'm getting out of the cmyk conversion are still horrible though. | 19:45.35 |
| | (Currently I'm doing the really dumb r = 255 - k - c; thing) | 19:45.55 |
| mvrhel_laptop | Robin_Watts: ok. as soon as I get this up and running I will debug all the color issues | 19:46.02 |
| | Hopefully I will be viewing pages today with gsview | 19:46.17 |
| Robin_Watts | fredross-perry: Oh, the other thing about the speed... we haven't profiled either mupdf or gs with this. | 19:46.32 |
| | It's entirely possible that there are massive gains to be had in both ends just with a bit of tweaking. | 19:46.53 |
| | I'm still getting signed/unsigned warnings in load-gif.c (lines 166, 197, 214,531,532). Am I missing a commit from sebras? | 19:49.41 |
| | Ok, updated commits on robin/master. I've removed the last 2, so all should be good to go. | 20:01.22 |
| | Cluster testings running now. | 20:01.33 |
| fredross-perry | is it on rge forFred branch again? | 20:06.48 |
| | *the* | 20:06.53 |
| Robin_Watts | master | 20:12.19 |
| | tests passed. | 20:12.28 |
| fredross-perry | thanks, trying it now... | 20:22.11 |
| | I am now getting all white. See email in a few minutes... | 20:41.07 |
| | email server issues. stay tuned... | 21:00.20 |
| | Forward 1 day (to 2015/08/15)>>> | |
IRC Logs