| | <<<Back 1 day (to 2015/07/19) | 20150720 |
| Robin_Watts | Morning fredross-perry. | 15:14.00 |
| fredross-perry | morning! | 15:14.20 |
| Robin_Watts | I need to talk to fredross-perry and mvrhel_laptop about the state of play with the gproof stuff at some point. | 15:14.26 |
| mvrhel_laptop | Robin_Watts: sounds good | 15:14.38 |
| Robin_Watts | Are you both about for a few minutes now ? | 15:14.49 |
| mvrhel_laptop | I am | 15:14.57 |
| fredross-perry | i am as well. | 15:15.18 |
| mvrhel_laptop | need a break from windows managed code hell for a bit | 15:15.24 |
| fredross-perry | phone? | 15:15.36 |
| Robin_Watts | no, on here is fine. | 15:15.44 |
| mvrhel_laptop | oh phone would be hard here | 15:15.47 |
| | everyone else is sleeping.... | 15:15.53 |
| fredross-perry | ok | 15:16.00 |
| Robin_Watts | So, I've got a version of MuPDF on android that works with libgs.so, and seems to be behaving itself. | 15:16.17 |
| fredross-perry | very good | 15:16.30 |
| mvrhel_laptop | nice | 15:16.33 |
| Robin_Watts | I've updated http://twiki.ghostscript.com/do/view/MuPDF/GhostProof with build instructions. | 15:16.34 |
| | and I'm tidying the code now. | 15:16.47 |
| | (the versions on my repos should work, but I'm just polishing) | 15:17.03 |
| | There is a bunch of 'Todo' stuff listed on that wiki page. | 15:17.22 |
| mvrhel_laptop | cool. when do you think that will be committed? | 15:17.24 |
| Robin_Watts | mvrhel_laptop: Soon, I hope. Paul is reviewing now. | 15:17.40 |
| mvrhel_laptop | ok | 15:17.44 |
| Robin_Watts | I was vaguely hoping that Fred could look at the android UI stuff ? | 15:18.26 |
| | and michael could look at the gs stuff. | 15:18.56 |
| fredross-perry | sure | 15:19.04 |
| | you mean look at completing the todo items? | 15:19.18 |
| Robin_Watts | It's possible that I might be able to do more of the gs stuff if mvrhel_laptop can just point me at the correct thing to do. | 15:19.27 |
| | fredross-perry: Yes. | 15:19.30 |
| mvrhel_laptop | Robin_Watts: ok. I will look over the gs code today. This is all in your repos still correct? | 15:20.09 |
| Robin_Watts | mvrhel_laptop: Yes. | 15:20.25 |
| mvrhel_laptop | ok | 15:20.29 |
| | Robin_Watts: Thanks a bunch for pushing this far with this | 15:21.49 |
| Robin_Watts | No worries, it's been fun. | 15:22.00 |
| mvrhel_laptop | updating from your repos now. Seeing if I can run it... | 15:22.57 |
| fredross-perry | so weâll need your latest mupdf repo as well? | 15:23.12 |
| Robin_Watts | fredross-perry: Yes. | 15:23.19 |
| mvrhel_laptop | brb. need to restart this machine | 15:27.22 |
| rayjj | morning, all | 15:37.28 |
| Robin_Watts | morning, ray. | 15:37.37 |
| mvrhel_laptop | morning ray | 15:37.58 |
| rayjj | Robin_Watts: so what is remaining on the gs side ? | 15:37.59 |
| Robin_Watts | See the twiki page. | 15:38.34 |
| | "The GS device needs work. Performance improvements would be good - potentially we could improve a lot - do some profiles. Equivalent colors don't appear to being produced (for CMYK at least). RGB is generated dumbly, so spots aren't showing up at all at present. ICC profile needs to be output." | 15:38.44 |
| rayjj | and do you have the code in mupdf to synthesize RGB from a subset of the spot colors ? | 15:38.48 |
| Robin_Watts | rayjj: I do. It's untested, but it's there. | 15:39.02 |
| | It relies on the equivalent spot colors written into the .gproof file. | 15:39.18 |
| | and those are all 0's at the moment, cos that's what I'm seeing in the gs device. | 15:39.33 |
| | And I have no UI to turn separations on/off and hence for those to be needed. | 15:39.47 |
| | I'm hoping fred can do the UI bits. | 15:40.07 |
| rayjj | Robin_Watts: I see. It should be simple to track down the spot equivalent colors | 15:40.25 |
| Robin_Watts | I need to add a couple of JNI functions for that. | 15:40.34 |
| | rayjj: Yes, hopefully. That was what I meant by maybe michael could point me at what I need to tickle to make them get generated. | 15:40.55 |
| rayjj | We usually won't have ICC profiles for the spot colors, so I assume that you want the ICC profile for the CMYK ? | 15:41.15 |
| Robin_Watts | rayjj: Asking me questions like that will only serve to show up my ignorance. | 15:41.48 |
| rayjj | Robin_Watts: if Michael still has work on the app side, I can dig that out. I've been through that code with tiffsep | 15:41.58 |
| Robin_Watts | When Michael wrote the spec for the file, he included a space for an ICC profile to be put into. Currently there is nothing there. | 15:42.13 |
| mvrhel_laptop | rayjj: I was going to spend a little time looking this over | 15:42.28 |
| Robin_Watts | rayjj: I am reluctant to drag you into this - you have enough on your plate as it is, right? | 15:42.34 |
| rayjj | mvrhel: did you intend that there is a single ICC profile that usually will be that of the device's CMYK (so we can create a link to sRGB) ? | 15:43.23 |
| mvrhel_laptop | hold on ray trying to straighten out an issue here | 15:43.41 |
| rayjj | Adobe offers the user a choice of which CMYK (US SWOP Coated, Uncoated, ... and myriad others) | 15:44.21 |
| | so the gproof file should include the ICC profile for what gs used to create the CMYK so we can map it back to RGB correctly | 15:45.07 |
| | if I understand correctly | 15:45.17 |
| mvrhel_laptop | rayjj: ok so back to your question. the format could include a profile which a consumer could use to properly map the RGB content. | 15:46.37 |
| | we will have it in sRGB likely since mupdf does not use icc profiles | 15:46.53 |
| | so there will not be a profile in the content at this time | 15:47.01 |
| | on top of that, there is very little color management control of displays in the android environment.... | 15:47.32 |
| | so, for the time being we will create our color managed proof in sRGB | 15:48.03 |
| | if someone looks at separations, they wont see something that is color managed but which is using the equivalent color values for the spots | 15:48.36 |
| rayjj | mvrhel: so the format will not have any profile for the CMYK (or spot colors, if gs had it) ? | 15:48.41 |
| mvrhel_laptop | rayjj: maybe in the future | 15:48.56 |
| | right now no | 15:48.58 |
| | mupdf can't even use the rgb profile | 15:49.08 |
| | much less an N color icc profile | 15:49.14 |
| rayjj | (it's probably unlikely that we sould have a spot color ICC profile) | 15:49.17 |
| mvrhel_laptop | ghostscript can use them | 15:49.29 |
| henrys | I decided to get a buzz cut but was pretty specific I wanted a large clipper size, but he used a really small one and started in the back of my head and by the time I saw it, it was too late. The summary is I'm bald. | 15:49.36 |
| mvrhel_laptop | haha | 15:49.46 |
| | send us a pic | 15:49.48 |
| rayjj | mvrhel: I was just thinking that the format might allow for future enhancement on the mupdf side | 15:49.54 |
| Robin_Watts | henrys: Welcome to the club! | 15:49.59 |
| mvrhel_laptop | rayjj: it does | 15:50.03 |
| | there is plenty of room for enhancement | 15:50.15 |
| Robin_Watts | henrys: Post a photo as a followup to Helens one on Facebook :) | 15:50.26 |
| mvrhel_laptop | did helen get a buzz cut too? | 15:50.37 |
| henrys | Robin_Watts: I really like helen's hair, looks good | 15:50.54 |
| Robin_Watts | henrys: Wouldn't suit you though :) | 15:51.08 |
| fredross-perry | Henry: youâll have to assume a more badass demeanor, now that youâve got the haircut for it | 15:53.39 |
| Robin_Watts | mvrhel_laptop: When I first knew her, she had a buzzcut. | 15:53.52 |
| | mvrhel_laptop: But no, she just had a new coat of blonde put on last week. | 15:54.29 |
| henrys | fredross-perry: yeah you get to tell a nazi skin head your stuff isn't on schedule... | 15:54.32 |
| Robin_Watts | henrys: oops. Are the skull tats showing now? | 15:54.50 |
| mvrhel_laptop | Robin_Watts: check logged onto facebook. tell her it looks good | 15:55.06 |
| henrys | http://www.ghostscript.com/~henrys/WIN_20150717_133320.JPG | 15:55.10 |
| mvrhel_laptop | no way | 15:55.23 |
| | you do look a little scary | 15:55.37 |
| | you just need a few tattoos on your neck | 15:55.50 |
| henrys | my hair grows fast ... | 15:55.50 |
| marcosw | it's quite a change from when I first met you... | 15:56.10 |
| henrys | after this I'm going back to the ponytail | 15:56.37 |
| | marcosw: one extreme to the other... | 15:58.13 |
| marcosw | You could play Daniel Day-Lewis' younger brother: <http://odeon.typepad.com/silverscreen/DanielDayL_Grani_981830_400.jpg> | 15:59.52 |
| rayjj | Robin_Watts: I don't understand the comment that "Equivalent colors don't appear to being produced (for CMYK at least)." The equivalent colors are only for spot colors and are in terms of CMYK. | 16:01.17 |
| henrys | marcosw: it really comes off great in the really good looking actors, but I'm not one of those folks | 16:01.46 |
| rayjj | Robin_Watts: so if there was an equivalent color for, say Cyan, in CMYK it would just be 1, 0, 0, 0 | 16:02.04 |
| fredross-perry | henrys: yes SIR!! | 16:02.18 |
| Robin_Watts | henrys: Senior Drill Instructor Stiles. | 16:03.09 |
| henrys | fredross-perry: I get a lot of that... | 16:03.11 |
| rayjj | hmm... my cable internet is down. I had to turn on my phone hotspot | 16:03.25 |
| Robin_Watts | rayjj: For each colorant, I expect to get the equivalent rgb colors. | 16:04.04 |
| | but for cmyk at least (haven't looked at spot colorants) the equiv_cmyk_colors returned from the devn stuff in gs are all 0. | 16:04.32 |
| marcosw | rayjj: peeves and peeved have been up and down since yesterday, presumably you can't run them over your phone :-) | 16:05.23 |
| Robin_Watts | marcosw: I'm going to do some bmpcmps, so that would be a bad idea :) | 16:06.26 |
| rayjj | Robin_Watts: OK, that's to be expected. As I said, for DeviceN devices the equivalent colors are CMYK, so it doesn't make sense to have them in gs. So what the gproof device needs is to convert _ALL_ of the colors to RGB equivalents ? | 16:06.41 |
| | mvrhel: is that ^^^ what you intended ?? | 16:06.58 |
| Robin_Watts | rayjj: The gproof file format has equivalent colors in RGBA and CMYK. | 16:07.21 |
| marcosw | speaking of the cluster, it should now work with chrisl_away's build_consolidation branch. | 16:07.35 |
| Robin_Watts | The devn params are supposed to be able to return both rgb and cmyk values. | 16:07.45 |
| | Hence it's certainly NOT what I would expect. | 16:08.00 |
| henrys | great news marcosw | 16:08.05 |
| mvrhel_laptop | rayjj: the intent is for the proof file to have both rgb and cmyk equivalent colors | 16:08.28 |
| | like Robin_Watts said | 16:08.34 |
| | The alpha value would indicate some level of opacity | 16:09.18 |
| rayjj | Robin_Watts: OK, so gs needs to generate the RGB for the C, M, Y and K components using the CMYK ICC profile->sRGB and put those in the table | 16:09.21 |
| Robin_Watts | rayjj: Yes. | 16:09.39 |
| | I suspect that gs will do this if I just prod the right nerve... | 16:09.54 |
| fredross-perry | Robin: trying to follow the build instructions. Not finding Makefile.android. | 16:10.22 |
| Robin_Watts | fredross-perry: Let me check... | 16:10.36 |
| | fredross-perry: OOps. Change into 'gs' then look :) | 16:11.04 |
| rayjj | Robin_Watts: it takes some calls to the CM to get the CMYK->RGB link, then convert the CMYK to sRGB (I assume we want sRGB and not something else like the Adobe extended RGB) | 16:11.10 |
| rayjj | can't recall what that is called, offhand | 16:11.35 |
| mvrhel_laptop | rayjj: I am working on it now | 16:11.43 |
| rayjj | mvrhel: OK. | 16:11.53 |
| marcosw | henrys: do you know when chrisl_away plans to commit the build_consolidation branch to master? I'd like to be around to see make sure the cluster and the local regressions work as expected. | 16:12.02 |
| mvrhel_laptop | actually bbiab | 16:12.51 |
| Robin_Watts | marcosw: I think he was holding off until the cluster was ready. | 16:13.20 |
| henrys | marcosw: not sure, I think he thought it would take you longer .... | 16:13.21 |
| fredross-perry | RObin: not there either. | 16:13.22 |
| Robin_Watts | fredross-perry: What branch are you on? | 16:13.32 |
| fredross-perry | prob the main branch (of your repo) | 16:13.51 |
| henrys | marcosw: so I don't know if I can safely say he's ready | 16:14.02 |
| Robin_Watts | fredross-perry: You want the android_mupdf_gs_so branch | 16:14.18 |
| fredross-perry | nm, I see now Iâm supposed to be on another branch. | 16:14.35 |
| | is there a similar branch for mupdf? | 16:15.50 |
| marcosw | henrys: there is a regression with the build, but nothing that would stop a switchover: <http://bugs.ghostscript.com/show_bug.cgi?id=696097> | 16:18.12 |
| Robin_Watts | fredross-perry: No. master branch for mupdf at the mo. | 16:18.49 |
| fredross-perry | kewl | 16:18.56 |
| Robin_Watts | If it changes, I'll update the twiki. | 16:18.57 |
| | Is chrisl about today? | 16:22.47 |
| | I just pushed to mupdf golden, and the github mirroring barfed. | 16:23.09 |
| | fredross-perry: I'm going to have a look at adding some JNI functions to get separation names/colors and enable/disable separations now. | 16:27.30 |
| fredross-perry | sure | 16:27.46 |
| henrys | Robin_Watts: trying to reboot the indie stuff... Miles agreed to reopening the thread. | 16:46.12 |
| Robin_Watts | henrys: Cool. | 16:46.29 |
| marcosw | I'm going to reboot casper, it has pending updates. | 17:00.44 |
| chrisl | marcosw: as far as I'm concerned, I'm happy to commit the branch whenever - I've just pushed fixes for the issues you raised over the weekend, so...... | 17:08.46 |
| marcosw | chrisl: go ahead and commit. the cluster is backed up with mupdf tests, so it won't run until later today but I'll be around. | 17:12.40 |
| chrisl | marcosw: I must admit, I'm a bit nervous about committing this, because I'm *sure* this will cause git confusion to somebody..... | 17:22.23 |
| henrys | chrisl: good exercise ;-) | 17:24.10 |
| chrisl | henrys: well, basically, I have my branch squashed to a single commit, and pulled over to master, so it is ready to rock any time | 17:24.52 |
| henrys | chrisl: we agree to keep the old branches though right? | 17:25.28 |
| chrisl | Yes, the branch remains complete, and will get push to the repo, too | 17:25.57 |
| Robin_Watts | chrisl: Push it, and we can prod people to update at the meeting tomorrow. | 17:26.33 |
| | And that gives us a few days before I go on holiday so we can help people over any git problems. | 17:26.55 |
| chrisl | takes deep breath....... | 17:27.45 |
| henrys | what could possibly go wrong ? | 17:28.15 |
| chrisl | We'll find out...... I guess I should write a mail about it | 17:28.52 |
| Robin_Watts | chrisl: The cluster might take a while to get to your stuff... sorry. | 17:33.10 |
| chrisl | Robin_Watts: No worries - I'm just a little annoyed as it's taken this long for a mupdf commit to show that my approach to the github mirroring can't (I think) be made to work :-( | 17:34.18 |
| Robin_Watts | chrisl: Ah, what's the problem? | 17:34.44 |
| chrisl | I didn't realise that the git hook scripts get run as the user doing the "push" | 17:35.45 |
| Robin_Watts | some setuid magic? | 17:35.57 |
| chrisl | That has some fairly horrid security implications | 17:36.25 |
| Robin_Watts | I'm sure I had to setuid something... probably the svn access scripts or something. | 17:36.40 |
| chrisl | I'm wondering about using a hot folder + cron job type approach. | 17:37.04 |
| Robin_Watts | chrisl: A cron job that pulled and then pushed every hour would do. | 17:37.27 |
| fredross-perry | Robin: - have you been building libgs.so using OSX, or a real linux box? | 17:37.51 |
| Robin_Watts | fredross-perry: real linux in a VM. | 17:38.04 |
| chrisl | Robin_Watts: I suppose - I had hoped to have something triggered by a push, but I suppose..... | 17:38.11 |
| fredross-perry | Hmm. ok | 17:39.17 |
| Robin_Watts | fredross-perry: What problem are you seeing? | 17:39.53 |
| fredross-perry | I was trying to build it in OSX. So picking the right toolchain, etc. | 17:40.31 |
| Robin_Watts | There are notes in the makefiles swearing at OSX for changing the suffix from .so just to be awkward. | 17:40.35 |
| | fredross-perry: I'd just use the prebuilt libgs.so, in your case. | 17:41.05 |
| fredross-perry | thatâs what I am thinking too | 17:41.17 |
| b80905 | Robin_Watts: Hi. What's up? | 17:46.28 |
| Robin_Watts | b80905: The price of food in Greece. | 17:47.04 |
| b80905 | Robin_Watts: So what about that patch of mine? Remember it? | 17:48.55 |
| Robin_Watts | b80905: You'll have to be more specific, sorry. | 17:49.09 |
| b80905 | Robin_Watts: More precisely, this one http://bugs.ghostscript.com/show_bug.cgi?id=696066 | 17:50.05 |
| Robin_Watts | ah, right, that one. | 17:50.32 |
| | That's not going to get looked at before I go on holiday at the end of this week. | 17:50.46 |
| | But next week, Tor is back. | 17:50.52 |
| | And that's more Tor's baliwick than mine. | 17:51.04 |
| | So you may want to stop by next week and speak to him. | 17:51.29 |
| chrisl | What the hell are "marks"? | 17:52.34 |
| Robin_Watts | chrisl: It's a feature of the mupdf viewer. You can mark pages and jump between marks. Before my time. | 17:53.20 |
| chrisl | Oh, interesting | 17:53.53 |
| mvrhel_laptop | Robin_Watts: so I am running through the device. The spot color equiv. CMYK values are in there. There are not equiv. colors for CMYK. Since they are 1 0 0 0 for C for example | 17:54.51 |
| | So, we just need to clean that up, and create the RGBA values | 17:55.13 |
| | I can work on that if you want | 17:55.29 |
| Robin_Watts | mvrhel_laptop: Right. It's the rgba ones I care about. | 17:56.45 |
| b80905 | Robin_Watts: What's his IRC nickname? Tor? | 17:56.57 |
| mvrhel_laptop | One issue is that we don't really have access to the color manager here. I need to think a bit about this | 17:57.01 |
| Robin_Watts | Also, the current conversion from cmyk -> is crap. | 17:57.02 |
| | b80905: Yeah. tor8 or tor5 or something. | 17:57.13 |
| | mvrhel_laptop: Oh, rats. I didn't realise that. | 17:57.33 |
| mvrhel_laptop | likely we just need to get a few things set up in the device ahead of time | 17:58.36 |
| | to create our link transform | 17:58.48 |
| | and store it in the device for access | 17:58.55 |
| | then we can blast away | 17:59.09 |
| | give me a bit to poke around then I will see what your thoughts are on what I come up with | 17:59.39 |
| chrisl | Robin_Watts: Okay, the mupdf github will now be updated every hour - it seems to be working, and was much easier to do than using the git hooks | 18:22.21 |
| Robin_Watts | chrisl: Fab. | 18:22.54 |
| mvrhel_laptop | Robin_Watts: I am thinking about adding another profile type to the structure | 18:30.28 |
| | cmm_dev_profile_t | 18:30.30 |
| | which will be more of a post render profile | 18:30.44 |
| | that a device could use how it sees fit | 18:30.51 |
| | in our case, we will use this to store our RGB profile | 18:31.02 |
| Robin_Watts | OK. | 18:31.08 |
| mvrhel_laptop | and we will then use it in our conversion | 18:31.14 |
| Robin_Watts | Oh, you want to add that to ALL gx_device's ? | 18:31.26 |
| mvrhel_laptop | well it will be there accessible if another device would want to use it | 18:31.43 |
| Robin_Watts | So this is a gs wide extension rather than a specific change to just the gproof device? | 18:32.07 |
| mvrhel_laptop | Any case where a device would want to do post color management it could use it | 18:32.12 |
| | yes | 18:32.26 |
| Robin_Watts | I'm happy to nod along with that pretending I understand all the implications :) | 18:32.27 |
| | Is just 1 profile enough? | 18:32.44 |
| mvrhel_laptop | well, there really are no implications other than that the size of the cmm_dev_profile_t gets one address biffer | 18:32.46 |
| | bigger | 18:32.50 |
| Robin_Watts | Might we end up with devices that want n profiles rather than 1 ? | 18:33.14 |
| mvrhel_laptop | Robin_Watts: possibly. right now we have an array of profiles for the device. we could have an array of post render profiles too | 18:33.44 |
| Robin_Watts | (tag specific profiles etc) | 18:33.58 |
| mvrhel_laptop | yes | 18:34.16 |
| Robin_Watts | mvrhel_laptop: If we're going to add it, then adding an array might be the most general thing, yes. | 18:34.24 |
| mvrhel_laptop | ideally, gs will have already done that | 18:34.25 |
| | but, it might be that someone wants to do it that way | 18:34.37 |
| | especially since we can have the tag information | 18:34.48 |
| Robin_Watts | presumably we add this to the cmm_dev_profile_t so that gs handles the profiles for us, rather than just adding a profile to our device structure ? | 18:35.23 |
| mvrhel_laptop | it seem like the natural place for it to go, and one that provides options for other devices. that is my opinion | 18:36.06 |
| Robin_Watts | Then let's go with that. | 18:36.16 |
| | I am deeply hazy on all this stuff, so I'll trust you. | 18:36.38 |
| mvrhel_laptop | ok. I will do this as two separate parts. One is to add the new member as well as the mechanism to set it. then I will add the code to use it in the proof device | 18:37.13 |
| Robin_Watts | mvrhel_laptop: Cool. | 18:37.23 |
| | Oh, wait... | 18:37.33 |
| | Chris has just pulled the rug out from under us. | 18:37.48 |
| mvrhel_laptop | uh oh | 18:37.52 |
| Robin_Watts | So, you probably want to update to the new master, and add the new stuff there. | 18:38.11 |
| mvrhel_laptop | ok. | 18:38.25 |
| | then we can pull it into your repos? | 18:38.31 |
| Robin_Watts | I'll bring the gproof device up onto the new directory structure. | 18:38.33 |
| | then I can rebase that on top of your improvement. | 18:38.49 |
| mvrhel_laptop | that sounds good | 18:38.54 |
| | so a question about command line options... | 18:39.11 |
| | you usually have good thoughts about this sort of thing | 18:39.19 |
| | we need to have a way where we can specify a profile. question is what do we do if one is not specified | 18:40.01 |
| | it would be for a device that needs it | 18:40.20 |
| Robin_Watts | Use a 'standard' default ? | 18:40.21 |
| mvrhel_laptop | hold on phone | 18:40.51 |
| | Robin_Watts: let me think a bit more about this | 18:42.42 |
| Robin_Watts | sure. | 18:42.48 |
| mvrhel_laptop | lunch time now... | 18:42.53 |
| Robin_Watts | mvrhel_laptop: I'm going to head off soon, I suspect. | 18:43.43 |
| | I will bring the gs device up to date tomorrow. | 18:43.51 |
| | fredross-perry: First cut at the JNI functions to read/enable/disable separations is on my mupdf master branch now. | 18:45.10 |
| fredross-perry | thanks | 18:45.23 |
| Robin_Watts | fredross-perry: When you enable/disable a separation, you'll need to invalidate the page to redraw it. | 18:45.50 |
| fredross-perry | ok | 18:46.01 |
| Robin_Watts | and when you flip pages you'll need to re-read separations. | 18:46.11 |
| | Hmm. I've not thought about enabled/disabled separations persisting across page flips either. | 18:46.40 |
| | We may need to talk about that :) | 18:46.51 |
| fredross-perry | if re-reding the spes, or re-rending is expensive, we can consider cacheing the seps or render results per-page. | 18:50.37 |
| | âspesâ = âsepsâ | 18:50.52 |
| Robin_Watts | The page is cached as a bitmap at the android level. | 18:51.52 |
| | That's what needs to be invalidated. | 18:52.01 |
| | The page contents are held as a set of tiled images at the mupdf level. | 18:52.22 |
| | Those images scale and render very quickly. | 18:52.35 |
| | When you enable/disable a separation, the decoded images will get flushed from the cache, and the next render will hit the file to decode them again. | 18:53.08 |
| | The alternative is to hold all the separations in memory for all the images, and that would be too expensive for some files I think. | 18:53.31 |
| | So we expect some slowdown on separation changes. | 18:53.41 |
| | but for normal panning/zooming within a page it should be pretty bloody fast. | 18:54.03 |
| | reloading images from file is still quite quick compared to gs actually rendering the file. | 18:55.28 |
| | chris: The VS solution has some configuration issues. Looking at them now. | 19:05.08 |
| chrisl | Robin_Watts: Oh, did I forget to update for the revised targets? | 19:06.53 |
| Robin_Watts | Debug seems to build 'Release-contrib' for everything. | 19:07.12 |
| chrisl | For which product? | 19:07.46 |
| Robin_Watts | ghostscript. | 19:08.02 |
| | Well, for all of them. | 19:08.07 |
| | Pretty much everything builds Release-contrib. | 19:08.16 |
| | I have fixed it here. | 19:08.20 |
| | I'll stick up a commit for review later. | 19:08.28 |
| chrisl | I, um, don't understand that..... | 19:09.16 |
| Robin_Watts | Top commit on my master fixes it. | 19:10.20 |
| | I'll rebase it down when the build finishes. | 19:10.34 |
| chrisl | I *really* don't understand that because I don't think I changed any of that stuff...... ho-hum | 19:11.47 |
| Robin_Watts | Just blame MSVS. Works for me. | 19:20.42 |
| chrisl | Robin_Watts: BTW, you expressed interest in if I got a Home Signal femtocell box from Three - and I finally got around to sorting that out last week. It's working out pretty nicely | 19:21.25 |
| Robin_Watts | oh, cool. | 19:22.08 |
| | Ah, and the solution still has all the ghostscript stuff in a filter called 'gs. | 19:23.17 |
| chrisl | I had the usual double dose of "have you tried" from first and second line support...... then they agreed, sent it out next day delivery | 19:23.19 |
| | Robin_Watts: do you see a folder called "test" in the solution?? | 19:25.47 |
| Robin_Watts | I do. | 19:25.52 |
| chrisl | Hmm, I wonder what happened to the rename/hide commit, then...... | 19:26.23 |
| | I'll sort that out later | 19:27.04 |
| Robin_Watts | Oh... You have the files in the solution multiple times? | 19:27.30 |
| chrisl | I thought each project had all the source files it used in it | 19:28.11 |
| Robin_Watts | The old solution deliberately only had each file in the solution once. | 19:28.15 |
| | Because otherwise when I search for something (Ctrl-Shift-F, blah) it lists every file 4 times. | 19:28.39 |
| | I had all the common files in 'ghostscript', and only the specifics in pcl/xps etc. | 19:29.07 |
| chrisl | I thought I'd imported each existing project - I guess not | 19:29.51 |
| | Robin_Watts: I can tidy that up if you don't want to be bothered | 19:30.56 |
| Robin_Watts | I'm just preparing what I think is a fixed version here. | 19:31.28 |
| | I'll push it to my repo and you can check to see that you're happy with it before we unleash it. | 19:31.48 |
| chrisl | I'm happy with it if you are..... | 19:32.09 |
| Robin_Watts | chrisl: I am tempted to suggest that the VS solution/projects should live in a win32 dir. | 19:38.08 |
| | cos VS craps all sorts of files (.pdb etc) there. | 19:38.32 |
| chrisl | Robin_Watts: I'd rather a windows directory, but yes. I was also thinking of moving the msvc.mak file there, too | 19:39.28 |
| Robin_Watts | chrisl: yeah, windows, better name. | 19:39.40 |
| chrisl | Well, we have win64 now, too - don't know if you heard ;-) | 19:40.26 |
| Robin_Watts | OK, 2 commits on robin/master then. If you're happy, I'll push. | 19:43.50 |
| | (I haven't moved them to 'windows') | 19:44.04 |
| chrisl | Sure, those look fine | 19:44.35 |
| Robin_Watts | Doing a test rebuild. Will push when that completes. | 19:44.55 |
| chrisl | I'd like to raise the idea of the windows directory at the IRC meeting tomorrow - get other's feedback on it | 19:45.11 |
| Robin_Watts | actually, I want to understand all and ghostpdl before I push this. | 19:48.03 |
| | And that'll need to be tomorrow. | 19:48.17 |
| | mvrhel_laptop: Updated version of the gprf device is on my MASTER branch. | 19:48.36 |
| chrisl | Robin_Watts: "all" builds all if you build the solution, ghostpdl is just there so we can play with it easily | 19:49.44 |
| | So, the ghostscript, ghostpcl, ghostxps and ghostpdl projects are all marked as "don't build", the only project marked as "build" in the solution is "all" | 19:51.15 |
| | marcosw: it looks like the cluster wasn't happy with the new directory layout, or something | 20:20.17 |
| mvrhel_laptop | Robin_Watts: ok. I am going to change venue will then update | 21:24.07 |
| | oh the visual studio solution is now just in ghostpdl | 22:09.41 |
| | seems like it and the project files should be in a subfolder | 22:09.55 |
| | maybe that has already been talked about | 22:10.03 |
| | just looks a little messy now | 22:10.37 |
| | of course I am the last person to talk about messes | 22:10.50 |
| Robin_Watts | mvrhel_laptop: Yes, Chris and I spoke about moving it earlier | 22:18.24 |
| mvrhel_laptop | oh ok good | 22:19.35 |
| Robin_Watts | ooh, these ghostpcl targets don't look right. | 22:55.01 |
| | Nor do the ghostxps ones. | 22:55.21 |
| | oh, wait, ignore me. | 22:56.05 |
| | chrisl: (For the logs). Another commit on robin/master that adds an 'All' target in the nicest way I can think of. | 23:14.43 |
| | Namely that I've added various 'all' targets to the msvc makefile, and we just call them. That neatly sidesteps all the problems. | 23:15.08 |
| | Forward 1 day (to 2015/07/21)>>> | |
IRC Logs
