| <<<Back 1 day (to 2013/01/23) | 2013/01/24 |
Leolo_3 | épart | 01:26.59 |
BW^- | at http://www.ghostscript.com/download/ , it calls GhostXPS "interpreter/renderer". | 04:05.53 |
| doesd this currently mean, it has XPS generation in it already, no? | 04:06.07 |
mvrhel_laptop | no. It interprets and renders XPS content | 04:08.54 |
BW^- | mvrhel_laptop: aha. do you know where the mswinpr2 printer driver's sourcecode may be in the source repo? (either of ghostscript or gsview) | 04:40.25 |
| aha, it's base/gdevwpr2.c | 04:43.44 |
| hm i wonder about that gsview app | 04:45.11 |
sebras | tor8: the copyright footer at mupdf.com states 2012... | 10:37.30 |
Robin_Watts | Morning paulgardiner | 11:50.09 |
| Updated review up for you. | 11:50.14 |
| Morning tor8: Updated review up for you too, I think :) | 11:50.25 |
paulgardiner | Ok | 11:50.26 |
name | hi | 13:39.11 |
ghostbot | hello | 13:39.11 |
Robin_Watts | tor8, paulgardiner: ping | 14:30.51 |
| If I change left/right to do smart motion, should I leave up/down doing smart motion too? | 14:31.19 |
paulgardiner | Hmmm. Maybe not. | 14:32.11 |
| But you knew that alrady. Sorry not to have a more useful comment. :-) | 14:32.41 |
Robin_Watts | I had assumed that I'd go to just left/right, but having thought about it, I can't really see a reason why I should remove up/down | 14:33.47 |
| If you want to move down a pageful, then being able to tap the bottom of the page to do it, doesn't seem unreasonable. | 14:34.34 |
| paulgardiner: Updated patch online. | 14:53.23 |
paulgardiner | Robin_Watts: yeah that looks fine | 14:59.04 |
Robin_Watts | paulgardiner: Can you look at the next review too? | 15:01.03 |
| or maybe you already did. | 15:01.07 |
paulgardiner | Nope, but also looks fine. | 15:02.14 |
Robin_Watts | tor8 has a review up too... http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=010b12226a224788b2026e4c8fa2cee56ffb53a5 | 15:02.48 |
| Looks OK to me, but I don't quite understand how it helps with the current icon set - aren't they black already? | 15:03.14 |
tor8 | Robin_Watts: it's preparatory :) | 15:03.52 |
Robin_Watts | or is the intent that that should help with future icon sets? | 15:03.52 |
| Gotcha. | 15:03.59 |
| Then I shall push that one too. | 15:04.05 |
tor8 | Robin_Watts: so what's the plan for the smart paging and ui for it? | 15:04.12 |
| Robin_Watts: fab. | 15:04.16 |
| Robin_Watts: though I think it would be possible to do the tinting in the xml if that's preferable | 15:05.29 |
Robin_Watts | tor8: It's in now. Right and Down 'advance', and Left and up 'retreat'. | 15:05.43 |
| I'll upload an apk in a mo. | 15:05.52 |
tor8 | in fact, we could probably do the whole set of three different (doc, folder, up) icons in the xml as well | 15:06.08 |
| Robin_Watts: which has priority in the lower left corner? | 15:06.28 |
Robin_Watts | left | 15:06.45 |
| hmm. Maybe we should split the corner regions at 45 degrees or something? | 15:07.24 |
tor8 | Robin_Watts: nah. having left and right inch strictly is less confusing and easier to explain | 15:08.06 |
Robin_Watts | tor8, paulgardiner: It has been suggested that we should have a PDF file bundled in the application that should open on the first run to give instructions. | 15:15.22 |
| Possibly we should have a '?' icon to kick us back into it as a help thing too. | 15:15.46 |
| Any thoughts on that? Any idea how we'd code it? | 15:16.07 |
tor8 | Robin_Watts: like on the ios app? | 15:16.29 |
Robin_Watts | indeed :) | 15:16.35 |
tor8 | Robin_Watts: with difficulty... it'd have to be embedded in the app somehow (apk or something) and then some special tricks to get it to show | 15:19.40 |
Robin_Watts | Can you use an intent to load a doc from the apk? Probably not :( | 15:23.55 |
henrys | wow you guys had some snow | 15:24.48 |
Robin_Watts | yeah. | 15:24.58 |
henrys | kens:I don't know where you got the list of #include files for pl/dwmainc.c but I've fixed it up while working on something else. | 15:28.00 |
kens | henrys I'm not sure that was me | 15:29.37 |
| Oh actually yes it was, I think I stole them from regular GS | 15:29.56 |
| Was thre a problem ? It seemed to work OK | 15:30.15 |
henrys | no many of them didn't come from gs - there is no problem they just included stuff not used by the file | 15:31.04 |
kens | Fair enough | 15:31.11 |
| Hmm don't remember where I got those fomr at all now.... | 15:32.07 |
henrys | kens:yes some of them struck me as very odd. | 15:32.33 |
kens | Looks like I copied most of them from plmain.c | 15:32.44 |
henrys | no big deal of course | 15:32.49 |
| I've always wanted a tool that would go through the source and find unneeded includes. | 15:33.15 |
Robin_Watts | http://ghostscript.com/~robin/MuPDF.apk <- Latest version with smart motion + paths + tinting etc. | 15:33.34 |
kens | I wish there were such a tool, I could really use i for pdfwrite | 15:33.38 |
Robin_Watts | The problem is that such a tool could not be expected to reason about things like: | 15:34.32 |
kens | Yes, looks like I blindly copied the includes from plmain.c and then added the very few actually needed | 15:34.37 |
henrys | aha | 15:35.00 |
Robin_Watts | You include A, A includes B. You could have got away with just including B, but maybe that's not architecutrally what you wanted. | 15:35.09 |
kens | I#d be happy if it just said that a given include didn't appear to be used | 15:35.40 |
Robin_Watts | again for michael: http://ghostscript.com/~robin/MuPDF.apk <- Latest version with smart motion + paths + tinting etc. | 15:35.46 |
henrys | well the tools would probably have to be transitive or you would be overwhelmed with unused stuff from nested includes. | 15:36.58 |
tor8 | henrys: why would you be overwhelmed? if a header includes another one but doesn't use it itself, that's an error you want to fix. | 15:40.53 |
| Robin_Watts: going "back" puts you at the top of the previous page rather than an the bottom where you'd expect | 15:42.57 |
Robin_Watts | tor8: It shouldn't do. | 15:43.12 |
| Can you exactly describe the situation please? | 15:43.21 |
tor8 | Robin_Watts: it does if you have it zoomed in not all the way | 15:43.28 |
Robin_Watts | Device in portrait or landscape? | 15:43.38 |
tor8 | tablet, landscape, show half a (vertical) page | 15:43.50 |
| tapping right will show top, bottom, next top, bottom, next top, bottom, etc | 15:44.06 |
Robin_Watts | ooh, you're right. | 15:44.07 |
| Damn. Will fix. | 15:44.15 |
henrys | the issue is if your c file includes a header which includes a header you don't use - I think there would be so many cases of that in normal code that the output would be very noisy but maybe not. | 15:44.20 |
tor8 | henrys: ah, but the header that included it uses defs itself so they should end up being used. depends on how you do the analysis I guess. | 15:44.58 |
Robin_Watts | The best you could reasonably hope for would be that the tool could tell you that the C file directly included a header that was completely unnecessary. | 15:45.55 |
| but how would you write such a tool, short of repeatedly compiling the file commenting each include out in turn? | 15:46.18 |
| And even if you did that, how could you be sure that you actually got the right output? | 15:46.33 |
kens | hash the object file 'as is' hasdh each time you compile, if tha hashes are the same.... | 15:47.01 |
Robin_Watts | kens: compiling the same file twice in a row does not necessarily give you the same object file. | 15:49.04 |
kens | Really ? why not ? | 15:49.13 |
Robin_Watts | Sometimes there are unset padding bytes. Sometimes timestamps | 15:49.20 |
kens | OK well timestamps I can understand | 15:49.32 |
| Should be possible to come up with somethign though | 15:50.02 |
henrys | supposedly cppclean from google does something interesting with this, I'll put it on my todo list. | 15:50.09 |
chrisl | henrys: cppclean seems to have disappeared - the repository is empty..... weird | 15:55.32 |
Robin_Watts | someone ran it on itself. | 15:56.06 |
chrisl | It's odd that they should just pull it like that | 15:57.11 |
| You can get a version of it here: https://bitbucket.org/robertmassaioli/cppclean/overview | 15:58.46 |
henrys | that's odd | 16:06.13 |
chrisl | And it doesn't seem that useful either, at least in the state captured at the above site | 16:07.58 |
Robin_Watts | tor8: http://ghostscript.com/~robin/MuPDF.apk <- Fixed version? | 16:10.34 |
| paulgardiner, tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=f6d08c38bd1dcb25184d1529c49a12d0ba8117a7 That's the fix if one of you would review it please. | 16:11.43 |
henrys | now that I'm thinking of it more for each header file remove it does the system compile, if yes leave it out if not put it back and continue | 16:14.34 |
Robin_Watts | henrys: Right, but that's not safe in general | 16:15.20 |
paulgardiner | Robin_Watts: what does that fix? | 16:15.21 |
Robin_Watts | paulgardiner: Going back from the top of a page took you to the top of the previous page, not the bottom. | 16:15.50 |
| The code is now more similar between forward and backward after this change, so it feels right. | 16:16.12 |
henrys | well yes you would have to review each candidate for exclusion. | 16:16.13 |
paulgardiner | Robin_Watts: ok. That looks good. | 16:16.26 |
Robin_Watts | henrys: right, cos I could have a header than defines macro versions of things, or sets pragmas etc. | 16:16.41 |
| As kens said, you'd need to compare object files to be sure, and that has its own problems. | 16:17.09 |
| paulgardiner: Thanks. | 16:17.16 |
tor8 | Robin_Watts: could use a bit more fuzz... at some zoom levels it wants 3 taps per page, but the last tap only shows 5 more pixels or so | 16:21.12 |
| you scroll to keep 10% between the various taps right? | 16:21.39 |
Robin_Watts | tor8: Up/Down moves by 90% of a screen size. | 16:22.03 |
| Left/Right moves exactly a screenful. | 16:22.14 |
| tor8: Possibly we could be smarter if we had a content box for the page. | 16:22.47 |
tor8 | Robin_Watts: not on my pad it doesn't ... both left/right and up/down move the same amount | 16:23.04 |
Robin_Watts | No, sorry, I was unclear. | 16:23.21 |
| Upward/Downward motion on the page is by 90% of a screen size. | 16:23.33 |
| Motion between columns is by whole screen sizes. | 16:23.45 |
tor8 | oh right, hadn't tried column mode yet. | 16:24.11 |
| this actually makes a huge usability improvement! good idea you had there :) | 16:24.26 |
Robin_Watts | Right/Down and Up/Left call the same bits of code :) | 16:24.33 |
| tor8: Yes, I'm very pleased with it. | 16:24.48 |
| I guess we could consider doing the same in ios/desktop viewers. | 16:25.06 |
tor8 | my latest gripe was when we have the page take say 2.1 screens, the last .1 scroll is a bit annoying | 16:25.32 |
Robin_Watts | I suspect it would remove the continual requests we get for continuous scrolling. | 16:25.35 |
tor8 | I had it at 2.01 or so, and wondered why I had to tap twice to move to the next page | 16:25.45 |
Robin_Watts | tor8: It's annoying, but actually doesn't hurt much. | 16:25.51 |
tor8 | Robin_Watts: well, if it's small enough to be unnoticeable we should probably not do it (hence my request for fuzz) | 16:26.15 |
Robin_Watts | If we had a content box for each screen we could avoid a scroll if it was only going to reveal extra stuff outside the content box. | 16:26.30 |
tor8 | 10% of screen size is probably a safe bet | 16:26.51 |
Robin_Watts | Otherwise we run the risk of continually moving with half the last line cut off. | 16:27.07 |
tor8 | yes, we should definitely do this for the ios viewer | 16:27.14 |
Robin_Watts | tor8: I generated a test file by feeding text into PCL.exe and out of the pdfwrite device. | 16:27.34 |
| in that one, I have text all the way to the bottom of each page. | 16:27.43 |
| 10% would mean I missed a line or two. | 16:27.52 |
tor8 | ugh. unreadable! nobody (except you, in this one instance) does that! | 16:28.05 |
| but yes, I see your point | 16:28.14 |
| how about at the first/last taps per page, if we're within 10% of the edge, go to the edge? | 16:28.47 |
| since the 10% are used for overlap between each scroll, maybe make it 5% | 16:29.17 |
Robin_Watts | You mean extend the scroll amount to avoid future scrolls being stupidly small ? | 16:29.53 |
tor8 | yeah | 16:30.03 |
Robin_Watts | That might work. | 16:30.11 |
tor8 | hm. if we do it like this, the desktop viewer might get away with not having continuous scroll altogether. | 16:30.54 |
| what a shame I already implemented that for gtk+ :) | 16:31.01 |
| but still, this way of navigating makes a lot of sense with or without continuous scrolling | 16:31.15 |
henrys | anybody still use Igor's dwtrace? It would be nice to get rid of it if not. | 16:31.49 |
Robin_Watts | Is dwtrace the thing that shows what's actually being drawn ? | 16:32.44 |
henrys | yes | 16:35.44 |
Robin_Watts | So the same as vd stuff ? | 16:35.56 |
| I have this memory that the dwtrace stuff required another program running alongside gs, possibly a windows only thing, that output the visual debug. | 16:36.53 |
| I did ponder very briefly as to why we didn't have the visual debug stuff outputting postscript that we could pipe into another ghostscript instance... | 16:37.25 |
henrys | it only works on windows so I haven't used it much. | 16:39.17 |
Robin_Watts | but, no, I've never used it as is, and indeed whenever I've had to change the rendering code the visual debug has always just got in the way. | 16:39.52 |
| I'd be in favour of stripping it out unless someone else actually gets benefit from it. | 16:40.09 |
henrys | for me it is just another layer of foo to trip over. | 16:40.13 |
kens | I never use it | 16:41.08 |
henrys | I'll check with ray and mvrhel_laptop too. I think alexcher is mostly using linux now but he might want it occasionally | 16:42.11 |
| after the killer memory bug should be something easy for chrisl to do. | 16:44.19 |
| christ north korea is off the rails again. | 16:58.51 |
alexcher | henrys: I still have 1 Windows box left. | 17:07.02 |
Robin_Watts | alexcher: Do you ever use the dwtrace/visual debug stuff ? | 17:07.38 |
alexcher | No | 17:07.56 |
henrys | Robin_Watts:I have done a few diffs on windows vs. unix rasters (ppmraw) and don't see differences. Which files were giving us trouble, do you recall? | 17:12.11 |
Robin_Watts | I don't remember. | 17:15.50 |
| There is an issue due to 64bit windows and 64bit linux having different bitmap_raster settings. | 17:16.13 |
| which leads to different clist band heights (+/- 1) | 17:16.32 |
| which leads to differences. | 17:16.37 |
kens | Goodnight folks | 17:20.32 |
Robin_Watts | tor8, paulgardiner: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=803728934ce4e77c4a0dc778447883361cb78743 | 17:42.55 |
| tor8: http://ghostscript.com/~robin/MuPDF.apk <- New version with variably sized advance. | 17:51.38 |
henrys | ray_laptop:while working a bug I ran into: GPL Ghostscript GIT PRERELEASE 9.07: ../gs/base/gxclimag.c(825): end_image id = 236 != clist image id = 0! | 17:56.44 |
| GPL Ghostscript GIT PRERELEASE 9.07: ../gs/base/gxclimag.c(1067): end_image id = 236 != clist image id = 0! | 17:56.44 |
ray_laptop | well, looks like we finally need to make color_usage work correctly. It really should have been done previously :-( | 17:57.01 |
henrys | the file does print as expected | 17:57.04 |
ray_laptop | henrys: I don't think I've ever seen that message. | 17:57.29 |
henrys | I had to look at the code it wasn't familiar at all to me. | 17:57.59 |
Robin_Watts | ray_laptop: color_usage has always previously been done by hooking encode_color/decode_color before, right ? | 17:58.42 |
ray_laptop | henrys: can you open a bug that I can look at later ? | 17:58.50 |
Robin_Watts | Is that going to work with ICC stuff? | 17:58.50 |
henrys | ray_laptop:will do | 17:58.59 |
Robin_Watts | speak of the michael... | 17:59.25 |
ray_laptop | Robin_Watts: it works after the color has been encoded, yes, but generally that is what is expected | 17:59.26 |
mvrhel_laptop | hello | 17:59.59 |
ray_laptop | Robin_Watts: if a device ICC profile maps gray to the K channel that's what we want to know | 18:00.08 |
Robin_Watts | ray_laptop: So you think we can continue to use encode_color/decode_color ? Or we need to extend the ICC support to tell us ? | 18:00.33 |
ray_laptop | Robin_Watts: but if the device profile maps gray to some CMYK combination, then in order to render the colors accurately, we have to print in color mode to get the right color out | 18:01.32 |
Robin_Watts | ray_laptop: Right. | 18:01.46 |
mvrhel_laptop | that wont happen by default | 18:01.48 |
ray_laptop | mvrhel_laptop: what won't happen by default ?? | 18:02.01 |
mvrhel_laptop | graytoK I believe is set to happen by default | 18:02.02 |
| gray to a CMYK combo ray_laptop | 18:02.13 |
Robin_Watts | mvrhel_laptop: We've had a request from a new company that wants to support 'auto color' mode. | 18:02.17 |
mvrhel_laptop | yes | 18:02.22 |
ray_laptop | mvrhel_laptop: that depends on the device ICC profile being used, correct ? | 18:02.23 |
mvrhel_laptop | I read the comments and told ray_laptop that I would help if he needed it | 18:02.34 |
| ray_laptop: no | 18:02.45 |
Robin_Watts | previous attempts at this have been done whereby we print the whole file as color, and keep note of whether we used any color along the way. | 18:03.09 |
mvrhel_laptop | graytoK forces gray to map to the K component | 18:03.10 |
| regardless of the profile | 18:03.21 |
Robin_Watts | If we did, then we output as color, if not we convert to mono. | 18:03.29 |
mvrhel_laptop | assuming it is a CMYK device of course | 18:03.31 |
ray_laptop | mvrhel_laptop: I need help with the other questions more -- Q12, 13 in particular | 18:03.36 |
Robin_Watts | It sounds like with this 'grayToK' thing, we need to decide that up front before page rendering, right? | 18:03.49 |
mvrhel_laptop | decide what? | 18:04.12 |
| it is a command line option | 18:04.21 |
Robin_Watts | Decide whether to use grayToK or not. | 18:04.22 |
mvrhel_laptop | well it depends on what you put on the command line | 18:04.37 |
ray_laptop | mvrhel_laptop: is DeviceGrayToK true by default for all devices ? | 18:04.48 |
mvrhel_laptop | hold on let me look | 18:05.06 |
| I believe it is though | 18:05.17 |
ray_laptop | mvrhel_laptop: I see that is a standard device param. | 18:05.19 |
Robin_Watts | mvrhel_laptop: OK, let's start again. The customers requirement is that they can give us a file to print, and we'll use color if it needs it, or greyscale if that's sufficient. | 18:05.24 |
mvrhel_laptop | well the issue of source colors that are R=G=B would need to be dealt with | 18:05.58 |
Robin_Watts | Previously we've done that by rendering the file in color, then spotting at the end that we can get away with just greyscale, and converting the rendered color to greyscale. | 18:06.15 |
mvrhel_laptop | as well as CMYK source colors with no C, M or Y | 18:06.23 |
| Robin_Watts: ok | 18:06.43 |
Robin_Watts | With color management, I suspect that approach won't work any more ? | 18:06.50 |
mvrhel_laptop | why not? | 18:06.55 |
| depends if you want color management on | 18:07.18 |
ray_laptop | mvrhel_laptop: since color_usage is collected AFTER encode color C==M==Y is what we need to infer "no color" | 18:07.25 |
mvrhel_laptop | if you turn it off it will work | 18:07.26 |
Robin_Watts | I don't know if this customer was planning to have color mangement enabled - I was assuming that they were. | 18:07.54 |
mvrhel_laptop | unless you want color management on for the color case and dont care in the gray case | 18:08.03 |
ray_laptop | Robin_Watts: from their questions, it looks like they are using color management (or trying to) | 18:08.21 |
Robin_Watts | Suppose, for the sake of argument that they have color management enabled for both color and greyscale modes. | 18:08.37 |
| (i.e. if you choose 'print in color' you get color managed output, and if you choose 'print in greyscale' you also get color managed output). | 18:09.18 |
mvrhel_laptop | I understand | 18:09.28 |
ray_laptop | Robin_Watts: Since the clist gets written in color mode (always). They have to post process the raster lines down to just 'K' in order to print in Gray mode. | 18:10.00 |
Robin_Watts | It seems unreasonable to me to expect that in such circumstances we could do the 'print in color' thing, and spot from the values we get at the end that we could have got away with greyscale output. | 18:10.01 |
| and certainly it seems unreasonable that we could then magically go from the color output that we have to the greyscale output that we'd need to print. | 18:10.39 |
mvrhel_laptop | oh that magic would be easy | 18:11.02 |
Robin_Watts | That would 'just' require another profile, right? | 18:11.20 |
mvrhel_laptop | right | 18:11.31 |
Robin_Watts | OK, but the 'spotting that we could have used greyscale'... is that possible ? | 18:11.48 |
ray_laptop | mvrhel_laptop: so it sounds like that if they use DeviceGrayToK=true, then equal components will automatically get put on the K channel ? (similar to PS blackgeneration = 100%, undercolorremoval = 100%) ? | 18:11.55 |
mvrhel_laptop | no | 18:12.09 |
Robin_Watts | (who was that no to? me? ray? both? :) ) | 18:12.34 |
mvrhel_laptop | DeviceGrayToK only ensures that a gray source color maps to the K component directly | 18:12.41 |
| that no was for ray_laptop | 18:12.50 |
Robin_Watts | ok. | 18:12.59 |
ray_laptop | mvrhel_laptop: I thought that's what I said. | 18:13.04 |
mvrhel_laptop | hehe | 18:13.09 |
| you said equal components | 18:13.16 |
| that is not a gray source color in the sense of DeviceGray | 18:13.28 |
| vs. DeviceRGB | 18:13.32 |
Robin_Watts | ray_laptop: If I output R=G=B=50%, then that's NOT the same as output K=0.5 | 18:13.32 |
mvrhel_laptop | with R=G=B | 18:13.35 |
ray_laptop | mvrhel_laptop: gray souce color has equal components, right ? | 18:13.43 |
mvrhel_laptop | ha | 18:13.49 |
| DeviceGray is what DeviceGrayToK works on | 18:14.09 |
| if there is a DeviceRGB color, then it is not affected | 18:14.32 |
| even if R=G=B | 18:14.36 |
ray_laptop | mvrhel_laptop: Oh. OK. so only when in DeviceGray colorspace | 18:14.38 |
mvrhel_laptop | it will be mapped to a CMYK value with C, M and Y not equal to 0 | 18:14.53 |
| ray_laptop: right | 18:15.09 |
| that was to make sure we followed the Adobe spec | 18:15.18 |
ray_laptop | mvrhel_laptop: so we would need to collect C==M==Y info during clist writing to determine whether or not all colors can be done in gray | 18:15.34 |
Robin_Watts | Surely not? | 18:16.06 |
mvrhel_laptop | ray_laptop: I would argue we need to look at source colors of R=G=B and C=M=Y=0 | 18:16.08 |
| pre color management | 18:16.15 |
ray_laptop | if they even want that. Which I asked in my comment to bug 693583 | 18:16.22 |
Robin_Watts | In a color managed world you cannot say that C=M=Y -> greyscale. | 18:16.23 |
mvrhel_laptop | Robin_Watts: right | 18:16.37 |
Robin_Watts | (And the color_usage.or thing is just completely conceptually broken, IIRC. It can't be fixed) | 18:17.55 |
ray_laptop | mvrhel_laptop: source C==M==Y doesn't mean that we can print in K mode if the profile for that object type doesn't map to equal components. | 18:18.09 |
mvrhel_laptop | ray_laptop: that is true. | 18:18.33 |
| another approach is to add in a hook into the CMM that monitors colors | 18:18.50 |
ray_laptop | mvrhel_laptop: I am thinking of image object type profile that maps to a 'better' gray that has some of all of the components | 18:18.55 |
mvrhel_laptop | and looks for source colors that are non neutral | 18:19.02 |
Robin_Watts | and indeed, if I'm understanding right, destination C==M==Y doesn't mean we can print in K. | 18:19.02 |
mvrhel_laptop | that is true to | 18:19.23 |
| I was simply saying though, if it were up to me and I was designing what they want | 18:19.45 |
| I would look at source colors | 18:19.50 |
Robin_Watts | Right. It seems to me that the CMM has to be involved in a decision about whether a given set of colors is all effectively greyscale or not. | 18:20.11 |
mvrhel_laptop | R=G=B and C=M=Y=0 and make my decision base at this | 18:20.13 |
| It is true that I could construct a case where this would fail | 18:20.27 |
| but it would cover 99.99% of the cases | 18:20.37 |
ray_laptop | mvrhel_laptop: I'm not sure they want it based on source colors or device color. I probably should get that clear | 18:20.38 |
Robin_Watts | mvrhel_laptop: Could we do some magic whereby we take the final color rendering, map it greyscale, then back to color, and see if we get the same (within a small %age) values again? | 18:21.24 |
| If we do, then greyscale is fine. If we don't, it's not. | 18:21.38 |
mvrhel_laptop | Robin_Watts: we can map it to CIELAB and look for colors that are not neutral | 18:22.05 |
Robin_Watts | Right. | 18:22.25 |
ray_laptop | mvrhel_laptop: that's an extra conversion step that will impact performance. These guys seem performance sensitive. | 18:22.44 |
mvrhel_laptop | if we want to do things in Device space, that may make sense | 18:22.45 |
| yes I agree | 18:22.49 |
| ray_laptop: | 18:22.53 |
| that is expensive | 18:22.56 |
| that is why I think if we have any images in RGB or CMYK it is going to be color | 18:23.17 |
ray_laptop | mvrhel_laptop: the clist collection method (after encode color) _is_ in device space | 18:23.18 |
mvrhel_laptop | and we only look at the graphic colors coming in | 18:23.29 |
Robin_Watts | Could we map 0...255 back from Gray to CMYK, then look for colors that were not in that set ? | 18:23.37 |
mvrhel_laptop | Robin_Watts: if DeviceGrayToK is true that will always occur | 18:24.13 |
Robin_Watts | mvrhel_laptop: I don't believe it's uncommon to see greyscale images as RGB (with R==G==B). or indeed as CMYK (with C==M==Y == 0) | 18:24.22 |
ray_laptop | mvrhel_laptop: that depends on what image object profile they use, but I agree that generally, for good color quality an image profile will use more than just K for gray | 18:24.28 |
Robin_Watts | so just detecting 'I have an RGB image therefore I must print in color' will mean we end up printing in color when we could have printed in greyscale. | 18:25.26 |
mvrhel_laptop | Robin_Watts: I think you want real color managment with such images | 18:25.31 |
Robin_Watts | That kind of thing really annoys end users. | 18:25.33 |
ray_laptop | mvrhel_laptop: so if they have an image object profile that is designed for full color images, then we won't know if the source was all gray | 18:25.42 |
mvrhel_laptop | but these are questions for the customer | 18:25.45 |
ray_laptop | mvrhel_laptop: I agree that we need to know what they want | 18:26.00 |
Robin_Watts | Of course we want to consult with the customer. Please excuse my questions here, as I'm trying to understand this stuff. Color science is still magic to me. | 18:26.35 |
ray_laptop | calling it color "science" is a stretch. Too subjective IMHO to be called science ;-) | 18:27.22 |
Robin_Watts | Supposing we DID just render to color, and supposing we had a fast way of spotting that the output we got was greyscale, the overhead of converting from color -> grey is not massive, right? | 18:27.44 |
ray_laptop | CMM == Color Mangling Magic | 18:27.46 |
mvrhel_laptop | you just dont have a calibrated eyeball | 18:27.50 |
ray_laptop | mvrhel_laptop: my eyeball is fine -- it's just everybody else that can't agree with me ;-) | 18:28.24 |
Robin_Watts | had his eyeballs calibrated last week. 3d scans etc. | 18:28.41 |
ray_laptop | Robin_Watts: yeah, they do that here too, but it isn't useful for contacts | 18:29.15 |
Robin_Watts | The optometrist was worried that one eye had higher pressures than the other. I had it retested multiple times, over multiple days. | 18:29.34 |
| And in the end they resorted to testing it the old fashioned way, rather than with the "puff of air" thing, and it was fine. | 18:29.58 |
| Apparently I just jump like a girl when they use the puff of air thing, and the readings are way off :) | 18:30.18 |
mvrhel_laptop | I have been at the upper end of the scale on eye pressure for years for some reason. | 18:30.31 |
Robin_Watts | ray_laptop: Scanning checks for floaters/macular degeneration etc. | 18:30.57 |
ray_laptop | I used to be, but then it came down. When it was high with the puff test, they used the 'direct contact' THAT WAS SPOOKY | 18:31.11 |
Robin_Watts | Given I had a bleed in one eye a few years ago, I'm keen to watch it. | 18:31.12 |
| Yeah, the direct contact thing was what they did for me. | 18:31.30 |
| but back to the matter at hand... | 18:31.59 |
| Supposing we DID just render to color, and supposing we had a fast way of spotting that the output we got was greyscale, the overhead of converting from color -> grey is not massive, right? | 18:32.09 |
ray_laptop | mvrhel_laptop: so can you take a crack at their questions 12 and 13 (and maybe 14) ? | 18:32.10 |
mvrhel_laptop | ray_laptop sure | 18:32.32 |
| so Q12 is easily done with the device link profile stuff I did for customer 330 | 18:33.30 |
ray_laptop | Robin_Watts: right, converting from equal CMY to K for gray printing is pretty easy, CMY+non-zeroK is not hard, but has to be decided how to handle | 18:33.31 |
Robin_Watts | ray_laptop: That's NOT what I asked. | 18:33.47 |
mvrhel_laptop | ray_laptop: I will write up a little blurb about that | 18:33.47 |
ray_laptop | Robin_Watts: but usually the device colors will either all be CMY with K==0 or C=M=Y=0 and non-zero K | 18:34.17 |
mvrhel_laptop | and I think I have a solution for Q13 too | 18:34.41 |
Robin_Watts | In a color managed world, "the color output being greyscale" does NOT imply that "C==M==Y". | 18:34.42 |
ray_laptop | Robin_Watts: if a printer (as defined by its profile) has to use unequal CMY to get gray, then it (probably) can't be printed with K (and get the same color) | 18:35.57 |
Robin_Watts | ray_laptop: I'm not sure I believe that. | 18:36.44 |
ray_laptop | Robin_Watts: which basically (I think) what we are saying we need to ask the cust. If the source colors are gray (in whatever colorspace), is that what they want to print in grayscale with just K | 18:37.15 |
Robin_Watts | The worry I have here is that we're going to go back to the customer, and the customer isn't going to have a clue, and we're going to go ahead and code a 'fudge' that involves working with device colors etc, but is NOT color correct, and then when we come to ship the customer will say "but this isn't what we wanted". | 18:38.12 |
ray_laptop | Robin_Watts: the magic DeviceGrayToK would help map to K, but it wouldn't handle the case where colors are defined in RGB or CMY with equal components and happen to convert (using whichever profile for that object) to unequal components | 18:39.04 |
Robin_Watts | right. | 18:39.21 |
| There are I think some things that we can be sure of. 1) If we print in color when we should have printed in greyscale, lots of people will complain like hell, because we'll be using color inks when they really don't want us to. And the customer will whinge back at us. | 18:40.13 |
ray_laptop | Robin_Watts: well, collecting the info when we collect the color_usage isn't that hard (or slow) so doing it with device colors is pretty easy. | 18:40.25 |
mvrhel_laptop | Again I suspect source colors of R=G=B and C=M=Y=0 is what the would want to define as print in gray | 18:40.36 |
| I need to update my color document with all the new stuff | 18:40.49 |
| I thought I did that already | 18:40.54 |
ray_laptop | mvrhel_laptop: how hard is it to do it in the CMM for source colors (just collect one value for the entire page and stick it in the device struct) | 18:41.01 |
Robin_Watts | Saying "Well, it was an RGB image in the file that just happened to be a greyscale one and we didn't spot that" will not win us any fans. | 18:41.09 |
| mvrhel_laptop: You may be right, but that's not color correct. | 18:41.44 |
mvrhel_laptop | ray_laptop: it would not be too hard except for the case where whole buffers are being converted it would be time consuming | 18:41.57 |
henrys | in a normal printing profile I wouldn't expect gray to result in equal CMY in device space. It would be simple enough to verify this with something like a HP color printer profile and use little cms to convert colors | 18:42.03 |
mvrhel_laptop | Robin_Watts: it is color correct in the sense when I look at the file with AR on my screen I see gray | 18:42.55 |
| with those source colors | 18:43.03 |
| that I suspect would be what one would want | 18:43.28 |
Robin_Watts | OK. How do you cope with ICC colors then? | 18:43.59 |
| i.e. colors specified in an ICC color space in the file? | 18:44.12 |
ray_laptop | mvrhel_laptop: for whole buffers, I think we can just punt and rely on the source colorspace being DeviceGray. Otherwise assume color | 18:44.26 |
Robin_Watts | How do you spot that the source colors are grey with that ? | 18:44.28 |
mvrhel_laptop | ray_laptop: that would be doable | 18:44.44 |
| Robin_Watts: I agree that one can construct a source case that breaks my suggestion | 18:45.09 |
| and if someone is doing ICC source colors, odds are good that they don't expect to be viewing a gray image | 18:45.35 |
ray_laptop | Robin_Watts: of ICCBased colors, we'd have to rely on the tint transform (which we DON'T want to do) | 18:45.36 |
Robin_Watts | ok, so humour me, and let's consider the 'gold standard' solution that would work correctly in all cases. | 18:45.55 |
ray_laptop | Robin_Watts: but if the tint transform colorspace is DeviceGray, then we can use that | 18:46.11 |
sebras | Robin_Watts: yo! did you see a mupdf bugreport from google play somewhere? | 18:46.31 |
ray_laptop | Robin_Watts: gold is too expensive (compute time) | 18:46.33 |
Robin_Watts | We render in color, we spot that all the colors are greyscale, and then we convert. That would work in all cases (but might be too slow). | 18:46.43 |
| right? | 18:46.52 |
sebras | Robin_Watts: I asked my friend to have a look at the app and he managed to crash it. told me that he reported it via googles reporting tool, but I'm unsure where it ends up...? | 18:47.17 |
ray_laptop | Robin_Watts: I'm not sure what you mean by 'we render in color' Source colors are all pre-rendering | 18:47.30 |
mvrhel_laptop | Robin_Watts: right. I understand what you could do. You render it to CMYK, then push the CMYK values through the CMM, look that they are all neutral, if so, then convert to gray | 18:48.05 |
Robin_Watts | ray_laptop: For my conceptual gold standard solution we don't do anything with source colors. We just render the entire thing in color. | 18:48.16 |
ray_laptop | Robin_Watts: if we want 'page uses color' to be based on source colors, then we do that BEFORE any CMM | 18:48.23 |
Robin_Watts | mvrhel_laptop: Right, and that would give the correct results in all cases. (100% of the time, not 99.9%) | 18:48.39 |
mvrhel_laptop | hehe. I am going to fix my documentation and let you two go at it | 18:48.55 |
| Robin_Watts: but yes you are correct | 18:49.09 |
Robin_Watts | No, I think I'm done. I just wanted to be sure that I understood what the 'right' solution was. | 18:49.26 |
mvrhel_laptop | Robin_Watts: that would be the gold standard | 18:49.37 |
ray_laptop | Robin_Watts: When you say 'render in color' and are looking at device colors, (after conversion) you don't know if the source colors were gray and just happened to map to something with unequal components | 18:49.39 |
Robin_Watts | I can see that it's lot of extra computation - unless we could find a trick to make it faster, it would be too expensive for real world use. | 18:50.11 |
mvrhel_laptop | ray_laptop: I think his point is that the thing the customer would like, is to print a page a K only if it was all neutral when printed with CMYK | 18:50.21 |
| that ultimate decision would require looking at the CMYK values of the final rendered output | 18:50.49 |
Robin_Watts | Right. | 18:50.58 |
ray_laptop | mvrhel_laptop: but the colors that are 'neutral' in CMYK is not known | 18:51.01 |
mvrhel_laptop | ah | 18:51.08 |
| but the CMM can tell us that | 18:51.12 |
| we have a device profile | 18:51.16 |
| and can convert from DeviceCMYK to CIELAB | 18:51.24 |
ray_laptop | mvrhel_laptop: right an look at AB | 18:51.39 |
mvrhel_laptop | and tell by looking at the CIELAB values that it was all neutral | 18:51.43 |
| right | 18:51.45 |
Robin_Watts | sebras: I have 2 crashes reported on the google developer console. | 18:52.02 |
mvrhel_laptop | ray_laptop: I am going to update some docs and then I will have answers for Q12 and Q13 | 18:52.34 |
Robin_Watts | Both relate to a java.lang.NullPointerException in 'android.net.uri$StringUri.<init>' | 18:52.39 |
ray_laptop | mvrhel_laptop: OK. so for every device profile that a device has (all the object types) we'd have a table of 255 'neutral' CMYK colors and check against that | 18:52.47 |
Robin_Watts | ray_laptop: That was my thought. | 18:52.58 |
| although, I suspect that doesn't quite work. | 18:53.15 |
mvrhel_laptop | there are more than 255 CMYK colors that are gray | 18:53.37 |
Robin_Watts | as I bet that as we move towards black, there are more 'neutral' colors than you'd expect. | 18:53.50 |
| sebras: But that's all the information I have. | 18:54.35 |
| oh, I lie. | 18:54.45 |
| I'll look for those crashes now. If he has a file and a description of what he was doing to trigger this, I'd love to see it. | 18:55.21 |
ray_laptop | mvrhel_laptop: thanks (in advance) for helping answer those other questions (12, 13, 14) | 18:56.11 |
mvrhel_laptop | np | 18:57.23 |
henrys | ray_laptop, mvrhel_laptop:we are discussing getting rid of dwtrace, do either of you use it? | 19:01.01 |
mvrhel_laptop | henrys: I do not use it | 19:01.29 |
| ray_laptop you still there? | 19:06.59 |
| henrys: do you know if the customer will upgrade to 9.07? | 19:07.15 |
| to do some of the color stuff they want to do, it will be necessary | 19:07.28 |
henrys | well then I guess they will :) | 19:07.48 |
mvrhel_laptop | the stuff I did for customer 330 will not go to waste.... | 19:07.54 |
| bbiab | 19:08.58 |
Robin_Watts | "Schneller PDF ReaderKein Schnick-Schnack, minimalistisch und flott." | 19:11.02 |
| I have no idea what that means, but "Schnick-Schnack" sounds great. | 19:11.19 |
| "Faster PDF Reader No frills, minimalist and fast." apparently. | 19:11.53 |
| "Kein Schick-Schack" means "no frills". | 19:12.34 |
henrys | git gets weird working on a shared directory from unix on dos. when I do a diff it reports all the file permissions have changed but they aren't different. | 19:14.51 |
Robin_Watts | henrys: Well, the file permissions are faked, right? | 19:15.28 |
| msys fakes the permissions based on what it reads from the dos file system. But the dos file system ones are faked from the unix ones. | 19:16.23 |
| So somewhere in the round trip of fakery something is going wrong. | 19:16.40 |
henrys | yea so best not to commit on a shared directory god know what will screw up. | 19:18.04 |
Robin_Watts | once you've got something into git you should be fine; git diff HEAD~1 will show you the differences, and if that looks believable you're OK. | 19:18.49 |
sebras | Robin_Watts: he has. he's attempting to open a pdf from a gmail-message apparently. | 19:36.54 |
Robin_Watts | sebras: I have a fixed version here. | 19:37.27 |
| sebras: In the automated report, I see a backtrace and a user mesage of: "I tried to open a pdf file included in a mail in Gmail." | 19:38.25 |
| I have a version here that shouldn't crash, but it won't open the file either. | 19:38.48 |
sebras | Robin_Watts: ah, and it all comes through some app admin panel over at google play? | 19:40.09 |
| no mails? | 19:40.12 |
Robin_Watts | it does. | 19:40.19 |
| I haven't see any such mails. | 19:40.24 |
ray_laptop | henrys: I don't use visual trace (never have, and probably won't ever use it) I don't mind if it goes away | 19:46.15 |
| (sorry I was off doing emails) | 19:46.35 |
| now heading off to lunch.... | 19:47.17 |
henrys | great I think that's everybody | 19:47.23 |
ray_laptop | I'm still marked as away at lunch anyway :-) | 19:47.45 |
henrys | my first push from the dos command line⦠boom! | 20:05.52 |
| well it looks sane enough | 20:06.57 |
sebras | paulgardiner: Robin_Watts that uri looks really funky: content://gmail-ls/messages/username%40gmail.com/1555/attachments/0.1/BEST/false | 20:38.20 |
| paulgardiner: InputStream is = getContentResolver().openInputStream(uri); // opens the content:// url above neatly. | 21:02.10 |
| paulgardiner: after this one can read the data and is.available() tells me that there are the correct number of bytes available. | 21:02.41 |
| paulgardiner: I guess we should just read all the data into a buffer and then add a MuPDFCore interface for parsing a pdf from an in-memory buffer. | 21:03.27 |
tor8 | henrys: I fairly regularly use git on shared folders between virtualboxed linux and windows | 21:17.55 |
| henrys: linux guest on windows host, with the folder residing on an NTFS partition in dos. git running on the linux guest, seeing the files through the "shared folder" device. | 21:18.32 |
| file permissions are wonky, and git status is dog slow probably because it can't rely on the file stamps so checks the contents of all the files | 21:19.18 |
| but in general it works | 21:19.24 |
henrys | tor8:yes I have a mac os x host and a windows guest - doing git diff reports a change on every single file because the permissions are different. That sort of makes using the shared folder too annoying for me. Have you worked around that? | 21:23.37 |
tor8 | henrys: hmm. so you're doing the opposite. | 21:24.34 |
| henrys: try git config core.filemode false | 21:24.51 |
henrys | hang on setting up | 21:27.39 |
| that seems to fix it briliant | 21:28.53 |
| I can't see why this shared folder stuff is so slow - why can't they fix this? | 21:29.41 |
Robin_Watts | sebras: Thanks. That's good info. I'll look into fixing it tomorrow. | 21:38.12 |
tor8 | henrys: with unix guest it's fast .. probably because it's a native kernel driver not emulated network smb mounts or how it works on windows | 21:39.07 |
sebras | Robin_Watts: an alternative is of course to have MuPDFCore use the InputStream directly. | 22:28.07 |
| but they can't really seek, so... | 22:28.15 |
| Robin_Watts: if the InputStream indicates a really large file, then we might want to write the data to a temporary file that can be accessed by path. | 22:29.03 |
BW^- | is there any way to make a PDF or PS to [Open]XPS conversion using unix tools today?? | 23:03.59 |
| Forward 1 day (to 2013/01/25)>>> | |