| | <<<Back 1 day (to 2012/02/15) | 2012/02/16 |
| sebras | tor8 Robin_Watts: there is a patch at sebras/master to take care of NaN and Inf in the ps function evalution. I could have tested for those in ps_push_real() in most (all?) cases, which makes for a shorter patch. Still I opted for the verbose solution because I believe it is more readable. | 00:08.37 |
| Robin_Watts | sebras: OK. | 00:08.56 |
| | In general, I think it's better to do as you've done, which is to avoid hitting the errors where possible. | 00:24.44 |
| | (i.e. detect that you will divide by zero, not that you have divided by zero) | 00:25.01 |
| | I don't follow the sqrt case. | 00:26.23 |
| | Why isn't it if just if (r1 >= 0) ? | 00:26.52 |
| sebras | Robin_Watts: d'oh! ?-) | 00:57.16 |
| | fixed. | 00:57.55 |
| | tor8 Robin_Watts: I opted for adding "Does not throw exceptions." for the time being. | 00:58.32 |
| Robin_Watts | ok. | 00:59.26 |
| | pdfdraw is dead, long live mudraw. | 00:59.52 |
| tor8 | \o/ | 01:00.03 |
| Gostega | hello | 09:53.46 |
| ghostbot | bonjour | 09:53.46 |
| Gostega | after reading the install doco at http://ghostscript.com/doc/current/Install.htm I noticed that there is a sort of unattended installation, however seems only if you have the setupgs.exe from a "zip file" | 09:54.25 |
| | can't seem to find the zip file download anywhere on the site (only the gs905w32.exe), could anyone point me to this | 09:55.00 |
| chrisl | Gostega: sorry, that needs revised - we now use the NSIS installer which takes different options | 09:55.21 |
| Gostega | I see thanks, would you be able to assist with the silent/unattend options for the new installer? | 09:55.47 |
| chrisl | Gostega: have a look here: http://ghostscript.com/FAQ.html fifth entry | 09:56.50 |
| Gostega | thanks very much. I had been trying with lowercase /s | 09:57.42 |
| | thanks for your time | 09:57.44 |
| chrisl | np, again, sorry for the out of date doc - I'll be sure and update it for next release | 09:58.05 |
| Gostega | np cheers ;) | 09:58.33 |
| chrisl | Robin_Watts: where do we stand on Gemma's problems? | 11:29.40 |
| Robin_Watts | chrisl: Siorry, just back from run. | 12:16.58 |
| | The compressed encoding stuff is basically insoluble as we are. | 12:17.28 |
| | (AIUI) | 12:17.34 |
| | There is 1 issue remaining that I know of other than that. | 12:17.59 |
| | Where a shading comes out far too black. | 12:18.11 |
| | I'm going to try to cut that file down after I have a shower. | 12:18.51 |
| | I'm coming late to this particular party, so... | 12:19.14 |
| | compressed colours are just an issue for the separations? | 12:19.38 |
| | Bah. | 12:19.46 |
| | compressed colours are just an issue for the composite plane, not the separations? | 12:19.54 |
| | Could we just generate the separations, and then make the composite plane from that in the device? | 12:20.11 |
| chrisl | Robin_Watts: I suppose we could post process the plates to generate the contone preview *but* I have no idea whether the device has access to the tint transform for each plate | 12:23.05 |
| sebras | http://www.armware.dk/RFC/rfc/rfc1890.html | 12:58.34 |
| | oops. | 12:58.42 |
| Robin_Watts | has previous life flashbacks. | 12:59.08 |
| sebras | Robin_Watts: ? | 13:12.32 |
| | oh.. | 13:12.40 |
| Robin_Watts | streaming video/audio etc. | 13:14.50 |
| sebras | Robin_Watts: this is what I'm working with when I'm not busy with mupdf and documentation nowadays. | 13:15.29 |
| Robin_Watts | armware is J Kortinks company, right? | 13:16.35 |
| sebras | Robin_Watts: no, no, I'm working with streaming video/audio at Axis Communications, that's why I accidentally linked to the streaming RFC. | 13:17.24 |
| | I don't know anything about armware. | 13:17.37 |
| Robin_Watts | My first contract when I left uni was doing software video/audio decompressors, and that lead to porting realaudio and doing a videophone etc. | 13:19.16 |
| | tor8: Did you see the email to support from the mupdf company? | 14:22.15 |
| | They've given me a file that shows the problem. | 14:22.25 |
| | but I'm fielding another one of their developers on skype at the moment, and trying to get to look at Gemmas problems. | 14:23.02 |
| chrisl | Robin_Watts: (sorry my parents turned up) I'm suspicious that WMB1102317A01.pdf is an overprint problem | 15:19.35 |
| Robin_Watts | It is exactly an overprint problem. | 15:19.45 |
| chrisl | Overprint interacting with interpolate? | 15:20.25 |
| Robin_Watts | I have it cut down here to a single black rectangle, with a separation image overprinted on top of it. | 15:20.36 |
| | the output of the interpolated image is being plotted via gx_default_copy_color, which calls into overprint_generic_fill_rectangle | 15:21.28 |
| | which calls gx_overprint_generic_fill_rectangle | 15:22.16 |
| | which calls get_bits_rectangle. | 15:22.39 |
| chrisl | So, why does the interpolated image take a different route to the non-interpolated one - surely the interpolated image is just a bigger image....... | 15:23.53 |
| Robin_Watts | Urm... | 15:23.58 |
| tor8 | Robin_Watts: send me the file and I'll take a look. it's probably a missing tounicode or some synthetic boldening gone wrong. | 15:24.15 |
| Robin_Watts | Suppose my output components are: | 15:24.22 |
| | 0000,0000,0000,ffff,0000 | 15:24.47 |
| | and I'm plotting an image of 0000,0000,0000,0000,ffff over the top. | 15:25.10 |
| | overprint with OPM=1 says I should get what ? | 15:25.20 |
| chrisl | Oh, god, I need to look up the spec.... | 15:25.53 |
| | I *think* you should get 0000,0000,0000,0000,ffff because it's an image - but not sure - reading now..... | 15:27.36 |
| Robin_Watts | My reading of the spec says that regardless of the value of OPM, we should end up with 0000,0000,0000,ffff,ffff in this case. | 15:27.40 |
| | Oh, images are different ? | 15:27.47 |
| chrisl | I *thought* so, but that's one reason I need to check the spec | 15:28.14 |
| Robin_Watts | Nonzero overprint mode doesn't apply to images. | 15:29.08 |
| | BUT... Nonzero overprint mode doesn't matter in the example I just gave, right ? | 15:29.35 |
| chrisl | Okay, so yes, I think you're right we'd expect 0000,0000,0000,ffff,ffff in your example | 15:31.59 |
| Robin_Watts | So... Ghostscript is doing the right thing, and acrobat isn't. | 15:34.11 |
| | I think I've just convinced you that black is white :) | 15:34.28 |
| chrisl | Acrobat is overprinting | 15:34.39 |
| Robin_Watts | From what you've just said, if we print a single separation image on top of a color in another separation, that other color shouldn't be affected. | 15:35.40 |
| chrisl | Yes, with overprint true | 15:36.40 |
| Robin_Watts | /OP 1 /op 1 /OPM 1 is what we have, I believe. | 15:37.30 |
| | oh, no. We have /OP false /OPM 1 /op true | 15:38.01 |
| | Right so overprint isn't on for stroking, but is on for everything else. | 15:39.19 |
| chrisl | Robin_Watts: okay, is our output right without interpolation in play (it looks "righter")? | 15:39.49 |
| Robin_Watts | Our output matches acrobat if I disable interpolation. | 15:40.22 |
| | BUT... I don't understand what 'right' is any more. | 15:40.38 |
| | My understanding is that without overprint if I put an image in one separation over the top of a black rectangle, all the black should be removed in the relevant area. | 15:41.28 |
| chrisl | Yes, that's what should happen. | 15:41.51 |
| Robin_Watts | With overprint, my image will only affect the separation in play. | 15:41.58 |
| | But overprint is clearly turned on here, and yet acrobat (and gs when not interpolating) is treating overprint as being off! | 15:42.27 |
| | http://ghostscript.com/~robin/cutdown3.pdf | 15:43.11 |
| chrisl | When I use Acrobat's overprint preview - emulate overprint makes the image darker, and disabling it makes the image lighter, so clearly there is something in play...... | 15:43.12 |
| Robin_Watts | oh, do you have to enable something in acrobat to get it to overprint ? | 15:43.32 |
| chrisl | Do you have Acrobat Pro? | 15:43.46 |
| Robin_Watts | I do. | 15:43.49 |
| chrisl | Okay, Advanced->Print Production->Output Preview (Acro 9 at least) | 15:44.40 |
| Robin_Watts | Gottit. | 15:44.58 |
| | Right. | 15:45.00 |
| | In that case, gs is matching acrobat in interpolated case, but not the non-interpolated case. | 15:45.25 |
| chrisl | For me, Acrobat with overprint isn't as dark as ours - it looks more like blending that overprinting | 15:45.59 |
| | But I was using the file Gemma supplied...... | 15:47.16 |
| Robin_Watts | Presumably subtle differences are going to be down to the profiles in play. | 15:52.19 |
| | I am sure I haven't got my acrobat set up correctly for my monitor etc. | 15:52.37 |
| chrisl | I'm not sure - there is one difference between your cutdown file, and the one I cut down - your one does a fill in DeviceGray, but I *think* the original file does it in /Separation /All (I need to cut this down a bit more) | 15:54.15 |
| Robin_Watts | I think the original does an Image in DeviceGray, then another Image on top. | 15:55.11 |
| | I removed the first Image in favour of a rectangle, because taking 2 Images into the shower is just madness. | 15:55.36 |
| chrisl | OKay, that makes sense - I thought it was doing a fill as well. | 15:56.19 |
| Robin_Watts | Actually, I may have cut the file down too far. | 15:57.59 |
| | I'm not seeing the interpolate/no interpolate difference any more :( | 15:58.11 |
| chrisl | Hah! "The effect produced by such overprinting is device-dependent and is not defined by the PDF language." - we're covered! | 15:59.04 |
| Robin_Watts | OK. I have a less cutdown file that shows the difference. Let's see what's different about it. | 15:59.25 |
| | http://ghostscript.com/~robin/cutdown3.pdf <- better cutdown version. | 16:15.42 |
| | I'm back to thinking that our non-interpolated one is closer to acrobat. | 16:16.02 |
| chrisl | We agree on that, then! | 16:17.19 |
| Robin_Watts | tor8: Sorry. Have just mailed the file. | 16:24.01 |
| | tor8: It's worth noting that he's on 0.7, so stuff may have been fixed since then. | 16:24.42 |
| | Ah, the problem is unrelated to overprinting. | 16:46.15 |
| chrisl | Not handling 16 bits per sample properly? | 16:47.34 |
| Robin_Watts | Could be. | 16:49.27 |
| | Nope. Only 8bpc | 16:53.07 |
| chrisl | But the interpolated image data is 16bpc isn't it? | 16:54.31 |
| Robin_Watts | Not as I remember it. | 16:55.17 |
| | Maybe it's failing to do the indexed lookup before interpolation. | 16:55.34 |
| chrisl | Oops..... | 16:55.54 |
| Robin_Watts | Well, there's something weird going on alright. | 17:40.20 |
| | For a start, the non interpolated stuff only writes out in the K plane. | 17:40.59 |
| | The interpolated stuff is writing out in the C,M,Y,K planes. | 17:41.10 |
| | But also, the non-interpolated stuff is writing values around 9, 10 or so, whereas the interpolated stuff is writing values around 240 or so. | 17:42.08 |
| | Damn. Michael is out today and tomorrow, isn't he ? | 17:55.11 |
| chrisl | If he's well enough to ski, yes | 17:55.23 |
| Robin_Watts | This is a colour thing I think. | 17:55.40 |
| | The code is taking the interpolated results (which are in an ICC based DeviceGray space), but it thinks there are in a non-ICC based CMYK space. | 17:56.51 |
| | So it's concretising them back to something bonkers. | 17:57.12 |
| chrisl | That's a shame, I thought I had an idea, there, but it's not that...... | 17:57.51 |
| Robin_Watts | well, I could be wrong. | 17:58.02 |
| | What were you thinking ? | 17:58.09 |
| chrisl | There's a flag in image_render_interpolate() "device_color", but it's being set to true when we're dealing with an indexed space | 17:59.16 |
| | There is then a conditional on that flag, and the code we follow for !device_color has code specifically to handle indexed spaces | 18:01.37 |
| Robin_Watts | I'm looking at just that code now. | 18:02.21 |
| | line 678 ish? | 18:02.32 |
| chrisl | Yep | 18:02.41 |
| Robin_Watts | pcs->type indicates an ICC color with 1 component. | 18:03.19 |
| | Sorry. | 18:03.37 |
| | pcs->type indicates an Indexed color with 1 component. | 18:03.47 |
| | pcs->base_space->type indicated an ICC color with 1 component. | 18:04.03 |
| chrisl | Well, I don't count Indexed as being a "device_color"..... | 18:04.12 |
| | I changed line 679 to "if (pcs->cmm_icc_profile_data != NULL || pcs->type->index == gs_color_space_index_Indexed) {" and got not unplausible results (hedge hedge.....) | 18:04.51 |
| | But I think all that's done is circumvent the ICC workflow, which isn't what we want | 18:05.58 |
| Robin_Watts | Previously we WEREN'T using the icc workflow. | 18:06.30 |
| chrisl | Oh, erm... not sure, then. I'm not filled with confidence with the comment in there - the comment seems to contradict the logic of the conditional | 18:07.59 |
| Robin_Watts | Let's walk through this. | 18:08.35 |
| | pactual_cs is the actual colorspace we are using (so in our case, it's not Indexed, it's what we index into - an ICC Gray space) | 18:09.15 |
| | pconcs = the space we get when we concretise colors from pactual_cs - which in this case is still the ICC Gray space. | 18:10.07 |
| | AH! | 18:10.34 |
| | Then we're testing to see if we have profile data - if we do, it's not a device_color. | 18:11.01 |
| | Surely we should be testing pactual_cs there? | 18:11.12 |
| chrisl | Yes, that would make sense | 18:12.54 |
| Robin_Watts | And look at the if (device_color) clause. | 18:13.08 |
| | If we're calling pconcs->type->remap_concrete_color, wouldn't we expect to be passing pconcs in, not pactual_cs ? | 18:13.42 |
| | oh, but if device_color is true, then pconcs == pactual_Cs | 18:14.50 |
| chrisl | So it doesn't matter then | 18:15.10 |
| Robin_Watts | I have simplified code that uses pconcs->cmm_icc_profile_data instead. | 18:16.55 |
| | And that looks MUCH better. | 18:17.12 |
| | That's worth a clusterpush I think. | 18:17.22 |
| chrisl | Yes, I've made similar changes locally, and it does seem to do what I would expect, where it didn't before | 18:18.08 |
| | IIRC, Michael did say he'd be checking his e-mail, so it might be worth punting him a mail. | 18:19.27 |
| | Oh, heck - I have to go. I'll check the logs later....... | 18:19.54 |
| Robin_Watts | If it tests out OK I'll commit it and then send him a mail asking for a sanity check. | 18:19.58 |
| | Thanks for your help chrisl! | 18:20.03 |
| chrisl_away | No problem - it was a nice break from Type 1 patterns! | 18:20.19 |
| Robin_Watts | Tea! | 18:26.13 |
| | marcosw_: Guten Tag | 18:35.16 |
| marcosw_ | morning, I'm back in California, so no more Guten Tag. | 18:36.15 |
| Robin_Watts | Ah, ok. | 18:36.22 |
| | Various things... | 18:36.25 |
| | 1) I noticed that CLUSTER_UNTESTED doesn't work for mupdf commits. | 18:36.38 |
| | 2) pdfdraw is no more. It was renamed mupdfdraw for a while, then removed completely and replaced by mudraw. | 18:37.18 |
| | mudraw does pdf and xps. | 18:37.24 |
| | I've hacked run.pl about a bit to cope with that by copying mudraw as pdfdraw | 18:37.55 |
| | but this may be an opportunity to fix that properly and test xps files too. | 18:38.10 |
| | 3) Gemmas issues; I think (assuming the cluster test goes OK) that I have a fix for her last issue other than the compressed encoding one which we can't fix easily. | 18:39.23 |
| | I was going to do her a zipfile of exes - would you rather do that ? | 18:39.35 |
| | actually, maybe *I'd* rather you did it, as my builds will say "GPL Ghostscript" where yours might say something different. | 18:42.07 |
| mekapses | So, i'm having a weird problem which I think is ghostscript finding fonts. I've set GS_FONTPATH & GS_LIB. The script I use works under the command line, but when I try to get it to run under apache, I just get blank pages. Permissions seem fine, I think. Can give more infoâ¦. | 18:53.52 |
| Robin_Watts | Can you capture the backchannel output from ghostscript running under apache ? | 18:54.47 |
| mekapses | I'm just getting the standard GPL Ghostscript 9.02: Unrecoverable error, exit code 1. | 18:57.18 |
| ray_laptop | morning, all | 18:59.37 |
| | mvrhel is taking the day off, correct ? | 19:00.02 |
| Robin_Watts | ray_laptop: He is. | 19:00.19 |
| | today and tomorrow. | 19:00.25 |
| ray_laptop | There's a bug from cust 532 that I thought he could help with, but I guess not (they want a fix NOW! -- as usual) | 19:01.13 |
| Robin_Watts | customers, eh? :) | 19:01.28 |
| ray_laptop | Robin_Watts: I found the cause of most of the regressions with the image rotation patch -- starting another clusterpush shortly | 19:02.01 |
| Robin_Watts | Ah cool. I got sucked into other things I'm afraid. | 19:02.17 |
| ray_laptop | Robin_Watts: np. | 19:02.29 |
| Robin_Watts | How did the op go? | 19:02.43 |
| ray_laptop | Robin_Watts: good. The surgeon had said 3-4 hours and he was out talking to us after 3.5. The repair on both wrists looks good (to him -- I am not enough of a radiologist to be able to tell for sure) because he was able to position the pieces of the joint bones so the form a smooth surface (no steps) | 19:04.50 |
| | plates in both wrists with 9 screws in one and 5 in the other | 19:05.25 |
| Robin_Watts | So no lasting damage? | 19:05.26 |
| ray_laptop | Robin_Watts: no way to know until after healing and PT | 19:05.43 |
| Robin_Watts | but it's looking good? | 19:05.53 |
| | Did they say how long healing/PT will take? | 19:06.21 |
| ray_laptop | as well as can be for now and the pain is well controlled and Karen is chipper this AM | 19:06.23 |
| | They haven't said about PT but when I broke my wrist I had about 8 weekly PT sessions. My wrist wasn't back to full flexibility until about 4 months after surgery | 19:07.54 |
| | the surgeon said that he stopped counting at 20 pieces in the left wrist :-/ | 19:08.34 |
| Robin_Watts | OWW! | 19:08.42 |
| ray_laptop | Robin_Watts: back to the image rot patch -- it basically is OK, but it doesn't work right for other than 8 bpp, so I just added that check. I can investigate what's going on with 1bpp after getting them a patch for the current concern | 19:10.58 |
| | the nice thing about optimization patches is that it's easy to ignore the "hard" cases. :-) | 19:11.41 |
| Robin_Watts | yeah. | 19:12.18 |
| ray_laptop | the more I think about the tile cache issue the more I think I just need to store the tiles (compressed) in (one or more) pseudo bands and have a cache of uncompressed tiles when rendering. | 19:14.54 |
| Robin_Watts | ray_laptop: That sounds ideal as a long term solution. | 19:16.09 |
| | I'd be worried about promising them that any time soon though. | 19:16.29 |
| ray_laptop | every tile could be in a unique pseudo-band (in a group of TILE_PSEUDO_BAND + tile_id) | 19:16.33 |
| | Robin_Watts: I'm being careful not to promise (or even mention) anything to them on this | 19:18.20 |
| Robin_Watts | I'm hoping that they'll come back and say "We can up the bandheight to 1024 and that solves all our problems!" | 19:19.08 |
| ray_laptop | I have mentioned that I have an improvement for the PWTT coming, but haven't given them a date. I'd rather just surprise them | 19:19.18 |
| | Robin_Watts: right -- that and/or using uncompressed tiles | 19:19.45 |
| Robin_Watts | MuPDF customer is complaining that new code is slower than old code. | 19:20.16 |
| ray_laptop | Robin_Watts: yeah -- passing the context everywhere ;-) | 19:20.49 |
| Robin_Watts | And it transpires that they have put lots of smarts into their old code to do delayed image loading. | 19:20.51 |
| | On pages with no bitmaps - just as fast. | 19:21.09 |
| ray_laptop | so they just have to port their optimizations over (again and again) or give them to us to incorporate | 19:21.55 |
| Robin_Watts | Yes, exactly. | 19:22.04 |
| ray_laptop | having been on the customer end there were some hacks that I didn't want Peter to see, but on something central like the memory based clist, I didn't have any trouble convincing my management to give the code to Artifex. | 19:23.19 |
| Robin_Watts | Well, it's something that we want to do anyway (and it's been planned for). | 19:23.47 |
| | and the recent changes make it easier to do safely. | 19:23.59 |
| marcosw_ | Robin_Watts: I've been having chrisl_away do the builds for Gemma, she needs both 64 and 32 bit builds and I haven't gotten my 64 bit Windows 7 system to the point where it can compile ghostscript yet. | 19:37.53 |
| Robin_Watts | Ok. | 19:38.03 |
| marcosw_ | Also, when did mupdfdraw change to mud raw? that must have been recent. I assume mupdf change to mu at the same time... | 19:38.23 |
| | ^mudraw^mudraw^ | 19:38.35 |
| | ^mud raw^mudraw | 19:38.44 |
| Robin_Watts | I'm just trying to convince myself that the bitmap changes are all progressions. They all seem to be in CUPS, which is a pain ,cos I can't easily view cups files. | 19:38.55 |
| | I think we want to change mupdf to muview | 19:39.07 |
| | but that's not happened yet. | 19:39.18 |
| | ray_laptop: I mentioned to chrisl_away earlier, the idea that maybe we could do tiffsep differently. | 19:47.30 |
| | Produce all the different separations, and then form the composite from that in the device, when compressed colors wouldn't be an issue. | 19:48.03 |
| ray_laptop | Robin_Watts: you mean using multiple passes for up to 4 separations per pass ? | 19:48.34 |
| Robin_Watts | I don't know enough to know whether we have all the required info at that point though. | 19:48.35 |
| | Can we only do 4 separations per pass without hitting this problem ? | 19:48.55 |
| | Then yes, that's what I meant :) | 19:49.14 |
| ray_laptop | Robin_Watts: we can only do 8 8bit colors in 64-bits | 19:49.33 |
| Robin_Watts | So why isn't that 8 separations per pass? because we need to pack down into a 32 bit int ? | 19:50.10 |
| ray_laptop | Robin_Watts: I'm not sure if we can run with just the separations, however, without the CMYK part. | 19:50.11 |
| | If we can run without the CMYK then we _could_ run CMYK + 4 spot colors on the first pass and up to 8 more on each subsequent pass | 19:51.06 |
| Robin_Watts | but that would be no good, right? | 19:51.32 |
| | because the CMYK we got back would be incomplete? | 19:51.57 |
| | actually, maybe it wouldn't... | 19:52.40 |
| ray_laptop | Robin_Watts: as long as we 'automagically' read back the separations (including c, m, y, k) when we create the composite then it should be OK | 19:53.55 |
| Robin_Watts | ray_laptop: If we're going to regenerate the CMYK composite, why bother getting the core to generate it at all ? | 19:54.39 |
| | actually, let's backtrack a bit. | 19:54.50 |
| | IF Gemma just wants the composite, why do we need to run with any of the other separations at all ? | 19:55.15 |
| ray_laptop | Robin_Watts: the "merge" into the composite CMYK takes the info from the tint transform when factoring in the data from the separations | 19:55.31 |
| Robin_Watts | Right, but presumably that would happen regardless of whether we're actually storing the separation itself into memory? | 19:56.26 |
| ray_laptop | Robin_Watts: If we want a CMYK composite and the data is all on "Pantone Red 270" we have to map that color into M+Y (or whatever) | 19:56.37 |
| Robin_Watts | Right. Presumably we still go through the drawing process for all the objects drawn in "Pantone Red 270" anyway. | 19:57.33 |
| ray_laptop | Robin_Watts: the problem is with overprint -- we can be merging the "Pantone Red 270" onto M and Y planes that already have some info | 19:57.43 |
| Robin_Watts | It's just when we get to writing bytes into the final stored page, we won't have a byte to represent Pantone Red 270. | 19:58.31 |
| | For non-overprinted stuff, writing pantone red to a pixel will clear all the other pixels - that's easy for us to do regardless of whether we actually store pantone red. | 20:00.03 |
| | For overprinted stuff, writing pantone red to a pixel will not change the other pixels, right ? | 20:00.23 |
| | hence what goes into the composite is "whatever was there before + pantone red". | 20:00.50 |
| | (oh, blending might bugger this all up of course) | 20:01.02 |
| ray_laptop | Robin_Watts: correct, writing overprinted Pantone Red will not change other planes (such as M), but the composite M is the merge of pantone red and the previous M at that pixel | 20:01.41 |
| Robin_Watts | And can we not calculate that without having access to the previous value of Pantone Red? | 20:03.26 |
| ray_laptop | Robin_Watts: oops -- bbiaw. have to go... | 20:09.26 |
| | sorry | 20:09.28 |
| Robin_Watts | np. | 20:09.31 |
| | tor8: ping ? | 20:25.00 |
| tor8 | Robin_Watts: yes? | 21:31.03 |
| Robin_Watts | Just to check you got that file ? | 21:31.29 |
| | And to see what you think about the idea of renaming the mupdf viewer muview. | 21:31.58 |
| henrys | I really like pdf to be in the name why can't we just have a product called muxps that runs the same code? | 21:37.08 |
| | assuming that is the motivation for the name change. | 21:38.00 |
| Robin_Watts | Well it's a viewer that views pdf,xps,cbz,... | 21:41.35 |
| | Hence muview seems like a better name to me. | 21:41.57 |
| | In the same way we have GhostPCL, GhostScript and GhostXPS, all as part of GhostPDL we have MuPDF, MuXPS, MuAnythingElse as part of the Mu technologies. | 21:42.53 |
| henrys | if you are going to keep all the sub-names I guess it is okay. | 21:46.59 |
| | Miles is not going to be thrilled to change all the brochures and marketing stuff. | 21:48.09 |
| Robin_Watts | I wasn't imagining we'd stop calling it MuPDF. | 21:53.58 |
| | Just that the name of the viewer should change to something that emphasises it's larger nature. | 21:54.31 |
| | but maybe one for the agenda? | 21:54.41 |
| henrys | yeah I'll add it to the agenda for discussion. | 21:55.05 |
| tor8 | Robin_Watts: I got the file, all text comes out as '????' for me in that one | 21:56.17 |
| | I like the idea of muview, but mupdf as the name has more reputation | 21:56.50 |
| Robin_Watts | tor8: Does that look like a problem with mupdf or with the file? (I haven't looked to see if it can be searched in Acrobat) | 21:57.25 |
| | Being called by the boss. back later. | 21:57.36 |
| henrys | tor8:have you had a chance to review paul's work? | 21:58.21 |
| tor8 | Robin_Watts: looks like the file, sumatrapdf (with zenikos patches to be more optimistic about guessing) just gives me gibberish | 21:58.55 |
| henrys | if there are complaints we need to let him know quickly I don't like the business of ringing folks up a long time after... | 21:59.19 |
| tor8 | Robin_Watts: mac os x preview.app can't copy the text either | 21:59.42 |
| | henrys: I prodded Robin about a few things, but I don't see anything major that we can't fix ourselves quickly | 22:00.24 |
| sebras | tor8: can you build the android app? | 22:00.50 |
| henrys | okay great | 22:00.55 |
| sebras | tor8: I tried but my sdk is too old. | 22:01.04 |
| tor8 | I haven't got my machine set up for recent android development, I ought to see about that. I've still got ancient versions of the sdk and ndks | 22:01.07 |
| sebras | tor8: hm.. I wonder if it would be possible to script virtualbox to run several machines to compile mupdf for each target. | 22:01.58 |
| | just to make sure that nothing is accidentally broken. | 22:02.08 |
| tor8 | Robin_Watts: looking at the file in detail, it's got no encoding information in the pdf at all | 22:02.55 |
| | with /Encoding /Identity-H and nothing else | 22:03.36 |
| | the truetype file has no 'post' table to reverse the gid:s, and no cmap. so it's really impossible! | 22:04.42 |
| sebras | tor8: did you peek at sebras/master and the function evalution checks I added? | 22:39.12 |
| | tor8: Robin noticed a thinko which I fixed. | 22:39.32 |
| | Forward 1 day (to 2012/02/17)>>> | |
IRC Logs