| | <<<Back 1 day (to 2015/04/27) | 20150428 |
| mvrhel_laptop | aha!. rayjj digging in this altona nightmare. | 05:03.27 |
| | discovered that with -dUseFastColor I am still using ICC profiles in blending color space conversions! | 05:03.48 |
| | that is not right | 05:04.01 |
| pipitas | mvrhel_laptop: So this is actually a helpful nightmare? :-) | 09:41.17 |
| Robin_Watts | kens: Good answer on that bug. | 13:59.37 |
| kens | THe 'critical' one ? | 13:59.47 |
| Robin_Watts | yeah. | 13:59.52 |
| kens | Well they might be a customer..... | 14:00.03 |
| Robin_Watts | peak memory use of 33Meg in mudraw | 14:02.18 |
| kens2 | THen 1.7Gb seems odd | 14:03.47 |
| Robin_Watts | It might be a genuine android specific cockup. | 14:04.19 |
| norbertj | hi guys, I entered a bug 695967 on the performance for (pcl 2 pdf) pdfwrite. I think it will be for Ken as being the owner of pdfwrite. | 14:04.19 |
| Robin_Watts | but I'll not start looking til I hear back. | 14:04.38 |
| kens2 | norbertj : is this urgent for you ? I'm trying to get some other work finished and so not doing bugs for the moment | 14:06.20 |
| henrys | norbertj: have you inherited that stuff I thought another part of the company was doing pdfwrite stuff? | 14:06.32 |
| kens2 | Robin_Watts : fromtehir own websit e it sort of looks like they maybe *should* be a customer, even if they aren't | 14:06.58 |
| | Especially if they are building MuPDF themselves | 14:07.08 |
| norbertj | kens2: just finish that stuff. Not inherit, but we are also picking this up. | 14:07.15 |
| | henrys: Not inherit, but we are also picking this up. | 14:08.41 |
| | kens2: I uploaded a testfile on peeves, with a readme. And I do have workaround to get some better performance, by doing some heuristics on the time it takes to convert a page. But that is not foolproof (thought about that only for half an hour). | 14:11.20 |
| kens2 | Its not likely to be anythign simple unfortunately. | 14:11.42 |
| | It almost never is with pdfwrite, and PCL is a whole different nest of snakes, one I'm less familiar with | 14:12.14 |
| norbertj | kens2: I did some timings per page, and the more pages there are the longer (exponentialy?) it takes to convert. But if converting 1pdf/page it's very fast. I did not yet investigate much further (just started measuring with pdfwrite last friday) | 14:14.39 |
| kens2 | Then its probably searching the hashes for duplicate 'something', colour space, image, font, etc. | 14:15.09 |
| | Not doing so would lead to inefficient PDF files | 14:15.20 |
| | Is ths recent code you are using ? THere was a bug in there a while back | 14:15.38 |
| norbertj | kens2: overall I'm content with the performance for pdfwrite (out-of-the-box), it's just one testfile that was very different. The code is 9.17 (or master doesn't matter). | 14:16.00 |
| kens2 | Its probably something unusual then. It may be another case like the last one I fixed. | 14:16.25 |
| norbertj | If you look at the testfile I think it's mostly scanned bitmaps (looks like there is a background in there). And l think lots of small bands of image. | 14:17.11 |
| kens2 | In that case we were searching all cached objects to try and match an object of a specific type, and we didn't stop if we found a match either, we always tested all the objects | 14:17.19 |
| | norbertj : I couldn't tell that from a PCL file wihtout help.... | 14:17.55 |
| | Or spending a lot of time decoding it | 14:18.10 |
| norbertj | kens2: this is probably the case. The number of image-objects grows very fast. | 14:18.11 |
| henrys | norbertj: probably dual profiles would tell ken and I exactly what's happening. | 14:18.13 |
| norbertj | kens2: I looked at the pdf output with acrobat, this gave me the hint of the many image-objects. | 14:18.32 |
| kens2 | It could be some kind of rasterops thing..... | 14:18.56 |
| | AH no, we ignore rasterops for pdfwrite, can't be that | 14:19.06 |
| norbertj | henrys: I'll see if I can make some profiles | 14:23.57 |
| kens | Good grief, its a 92 Mb PCL file :-( | 14:25.35 |
| henrys | kens: why don't I look at it first and come up with something simple if norbertj's profiles don't tell us everything. | 14:26.20 |
| norbertj | +kens: yes, 144 pages (I think scanned) | 14:26.28 |
| kens | henrys I'm happy for someone else to look at it :-) | 14:26.44 |
| henrys | kens: assign it to me so I remember, I'm leaving right after the meeting. | 14:28.47 |
| kens | I noticed you had a holiday yes. I'll change the assignement now | 14:29.02 |
| | henrys I read the readme file and it looks to me like it will probably need to come back to me, if you can profile it though that might give me a clue where to go hunting. | 14:30.28 |
| norbertj | +kens: note that with -sDEVICE=bit -r600 -dLeadingEdge=3 (our device) it's about 10secs riptime (-sOutputFile=nul) and converttime with pdfwrite > 5000secs. So it should not be the pxl interpreter. | 14:30.28 |
| henrys | anyway meeting time. | 14:30.54 |
| norbertj | +kens: and with -sOutputFile=page%d.pdf it's much faster, about 70 secs. on same pc. | 14:30.57 |
| kens | Yes I read the readme | 14:31.11 |
| norbertj | +kens: going home now, Will make the profiles tomorrow. | 14:31.31 |
| kens | Its not caching, exactly though, I suspect its searching for duplicate objects | 14:31.32 |
| | norbertj : OK the profiles will hel pme a lot, thanks | 14:31.44 |
| henrys | tor8: you sent out an epub.txt file when you started the project. Can you refresh that so we can see what's done and undone, or maybe you discovered new stuff while implementing? | 14:32.14 |
| Robin_Watts | twiki page! | 14:32.38 |
| henrys | Robin_Watts, tor8 I agree! | 14:32.57 |
| | hmm we have a lot of bugs now. | 14:33.43 |
| | mvrhel_laptop: can somebody help with these? It looks like you might be a overloaded? | 14:34.06 |
| mvrhel_laptop | henrys: rayjj is working with the halftoning bug | 14:35.08 |
| henrys | jogux: we did look at that service some time ago - I don't know what happened with it. We do get tipped off by the community also. | 14:35.50 |
| jogux | henrys: oh right, I thought that was a new one, could be wrong. | 14:36.11 |
| mvrhel_laptop | henrys; so I am working on the altona stuff which is going to be a bit involved | 14:36.16 |
| | and I need to fix a few gsview things that Robin found | 14:36.26 |
| | that brings me to a question | 14:36.31 |
| Robin_Watts | jogux: One problem is that even when we know an app uses our stuff, google/apple won't withdraw the app. | 14:36.40 |
| henrys | mvrhel_laptop: can fredross-perry work on gsview | 14:36.41 |
| | ? | 14:36.42 |
| | Robin_Watts: I thought Apple would and Google would not. | 14:37.10 |
| Robin_Watts | henrys: hmm. maybe, possibly. | 14:37.23 |
| mvrhel_laptop | if I already labeled a point in the repos as beta, how does that work with respect to commits from there. should I start using some subsubindex in release number | 14:37.39 |
| Robin_Watts | mvrhel_laptop: Label another point as beta.2 ? | 14:37.56 |
| mvrhel_laptop | Robin_Watts: oh good idea | 14:38.06 |
| jogux | Robin_Watts: it seems feasible to me that there are some big apps that are using the code and not paying. | 14:38.40 |
| mvrhel_laptop | henrys: most of the fixes will take me only a day so it is not too bad. | 14:38.41 |
| | the altona stuff is going to take a bit of time though. | 14:39.11 |
| henrys | mvrhel_laptop: gamma is next ;-) | 14:39.23 |
| Robin_Watts | henrys: Don't make him angry. You won't like him when he's angry. | 14:39.47 |
| mvrhel_laptop | grrr | 14:39.59 |
| rayjj | on the halftone bug, I gave Jasper a work around, but haven't heard anything. Maybe Marcos can pulse him ? | 14:40.03 |
| fredross-perry | I could look at gsview/win, perhaps | 14:40.37 |
| henrys | but how'd we get to 13 customer bugs? | 14:40.44 |
| mvrhel_laptop | The altona stuff is interesting. A wacky thing I could not understand that was going in on Acrobat 9 is not happening in Acrobat DC | 14:40.46 |
| | I am going to upgrade | 14:40.52 |
| rayjj | maybe Miles can point his hot shot legal beagle at Apple and Google ;-) | 14:41.01 |
| mvrhel_laptop | Acrobat DC has a pile of features | 14:41.03 |
| kens | henrys, like I said, I've been ignoring mine for now | 14:41.35 |
| Robin_Watts | henrys: customer_bugs += smartoffice_customer_bugs | 14:42.13 |
| kens | Only 4 are ghostdocs | 14:42.46 |
| henrys | Robin_Watts: right I think some of those need to booted to enhancements. | 14:42.53 |
| | rayjj: what's left on norbert's performance issue? | 14:43.28 |
| | my last one should be fixed next week. | 14:44.20 |
| jogux | henrys: Robin_Watts : yeah, Iâd say two are non-reprocudible (so should be closed) and the add button difficult to access / need to select text ones are enhancements. | 14:44.52 |
| rayjj | henrys: I can only partly reproduce it (a much smaller decrease in performance than he reports). I guess the next step is to profile to see if there are any optimizations to regain the difference | 14:44.52 |
| henrys | marcosw: did you see the logs about release numbers? | 14:45.10 |
| tor8 | henrys: I'll update epub.txt and mail out a new copy | 14:45.35 |
| henrys | tor8: okay and somebody will add it to the twiki if you want or you can do it. | 14:45.58 |
| marcosw | henrys: no, I didn't. looking now. | 14:46.28 |
| Robin_Watts | I can drop it into the twiki if required. | 14:46.31 |
| henrys | fredross-perry: has the big white space been fixed in gsview I saw rayjj mention it? I think that's a good one to fix, if we can? | 14:48.21 |
| marcosw | henrys: the answer is I point customers to this page for downloads: <http://www.ghostscript.com/~customer/releases/ghostpdl/>. | 14:49.00 |
| rayjj | henrys: that was only something I saw in linux | 14:49.04 |
| Robin_Watts | fredross-perry has made the background darker I believe. I'd like it to be still darker. | 14:49.04 |
| fredross-perry | yes. | 14:49.05 |
| | Actually itâs the background color being too light. | 14:49.17 |
| marcosw | at least that's what I've always done in the past. | 14:49.18 |
| fredross-perry | just uploaded. | 14:49.24 |
| henrys | fredross-perry: I also reported a bug about zoom only going to 400% vs. Adobe 6400%, but it's assigned to mvrhel_laptop, I wonder if you can work on that also as mvrhel_laptop is swamped. | 14:49.40 |
| kens | marcosw from scanning back emails, you 'normally' send customers direct to the latest link. | 14:49.47 |
| fredross-perry | sure | 14:50.06 |
| henrys | actually I don't feel strongly about that bug if you guys don't think it important. | 14:50.07 |
| marcosw | kens: I think that's only when they ask for the latest release; if they just want to know where to download the commercial release I thought I send them to the general download page. In either case, I don't think there is room for 9.16/9.17 confusion. | 14:51.21 |
| fredross-perry | mine goes to 500%. Easy to change to any number we like. | 14:51.30 |
| kens | marcosw : fair enough | 14:51.36 |
| henrys | tor8: and you were going to do another release? | 14:52.22 |
| mvrhel_laptop | There is going to need to be some tiling working to make that work | 14:52.55 |
| | the zoom to 6400 that is | 14:53.09 |
| henrys | tor8: I wanted that to go before the newsletter since you are fixing an obvious thing that figures prominently in the letter? | 14:53.40 |
| mvrhel_laptop | fredross-perry, are you rendering tiles of the page for this case | 14:53.41 |
| | otherwise we are going to run into problems with memory etc | 14:54.08 |
| fredross-perry | no, not really. So zooming that big is not going to work for me simply. | 14:54.26 |
| Robin_Watts | mvrhel_laptop: You render the entire page at the required zoom? | 14:54.32 |
| henrys | I'm at the end of my meeting list. Anybody else have meeting business? | 14:54.34 |
| mvrhel_laptop | yes, and fredross-perry does too | 14:54.44 |
| Robin_Watts | I looked into code signing certificates. | 14:54.48 |
| mvrhel_laptop | that is not going to work | 14:54.50 |
| Robin_Watts | We can get a 3 year cert for $195 that will work for windows apps/drivers and on macos. | 14:55.08 |
| | So it'll cover everything we need. | 14:55.18 |
| kens | Sounds good to me | 14:55.26 |
| | that's much cheaper than I expected | 14:55.35 |
| Robin_Watts | I think we should just bite the bullet and get it. Further discussion will only cost us more than that in time :) | 14:56.01 |
| henrys | mvrhel_laptop: I reported it because we had an old gsview user report a bug at high zoom. | 14:56.02 |
| | Robin_Watts: yeah we'll get it, thanks for looking into it. | 14:56.24 |
| kens | Robin_Watts : at that price I'm inclined to say we should get it just to do signing of the .inf file.... | 14:56.32 |
| Robin_Watts | kens: yeah, it will do that, but also let us sign exes too. | 14:56.53 |
| tor8 | henrys: yes, we should probably make a 1.7b release with the epub fixes that I did last week | 14:57.00 |
| kens | test_pcl2pdf.pcltest_pcl2pdf.pcltest_pcl2pdf.pcltest_pcl2pdf.pcltest_pcl2pdf.pcltest_pcl2pdf.pclIndeed, all I mean is that its worth that much just to get rid of those people :-) | 14:57.12 |
| mvrhel_laptop | henrys: yes. that is an issue that needs to be fixed. | 14:57.12 |
| tor8 | the font-size^2 thing is pretty bad :( | 14:57.15 |
| Robin_Watts | mvrhel_laptop: We can talk more about the zooming stuff after the meeting. | 14:57.34 |
| henrys | okay moving over to skype for the next meeting. | 14:58.36 |
| fredross-perry | bye | 14:58.51 |
| rayjj | kens: I agree. The nice thing is that they claim that the certificate is OK for driver signing also. When I looked a year ago there was a different category (more expensive) needed for drivers | 14:59.45 |
| kens | rayjj Yep, the fact that we cna do other stuff just makes it totally compelling | 15:00.05 |
| mvrhel_laptop | Robin_Watts: that would be great | 15:00.21 |
| rayjj | oh, this is wonderful (*NOT*) I have a test case where I take out the "Do" for an image, and I get one color in the resulting pgm, but if I then remove the XObject from the Resources dict, I get a different color. Both differ by 1 count (0xce vs 0xcf) | 15:24.31 |
| kens | If you remove the XObject from teh resources dict it may inherit a different image from teh page resources dict | 15:25.18 |
| rayjj | kens: If I remove it from the Resources it _should_ be undefined, and I removed the 'Do' so it wouldn't be referenced at all | 15:32.33 |
| kens | rayjj it won't be undefined if the page level Resources defines an XObject with the same name | 15:32.57 |
| rayjj | how changing the Resources to remove an unused XObject can affect the colors is worrisome | 15:33.06 |
| | kens: this was the page level. I have it simplified down to a *very* simple file | 15:33.34 |
| | It is comparefiles/Bug694437.pdf | 15:33.53 |
| kens | Fair enough, obviously I can't see your file so I thought I should mention one possibility | 15:33.56 |
| rayjj | (or modified from that) | 15:34.01 |
| | mutool clean -d was run, then I replaced the Im5 Do with blanks | 15:35.09 |
| kens | I'd have to look at the file, mine was just a general point | 15:35.49 |
| mvrhel_laptop | Oh interesting. Adobe DC has a setting for the default Transparency blending space | 15:36.38 |
| chrisl | mvrhel_laptop: 'bout bloody time! | 15:36.58 |
| mvrhel_laptop | yes | 15:37.02 |
| rayjj | kens: don't bother with the file. I'm going to continue to track it down | 15:37.55 |
| chrisl | fredross-perry: have you updated the Linux and Mac GSViews since yesterday morning? (Just checking if I should update the downloads again)? | 15:37.58 |
| Robin_Watts | mvrhel_laptop: OK. Finished in the SOT meeting, | 15:38.35 |
| mvrhel_laptop | Robin_Watts: ok | 15:38.40 |
| jogux | Robin_Watts: btw⦠my impression was that the only way to get a proper mac gatekeeper approved signing key was with a mac dev account ($99/year or something) | 15:39.01 |
| Robin_Watts | mvrhel_laptop: The way the android app handles zooming is that for each page, we hold 2 images. | 15:39.14 |
| fredross-perry | I did, but I am just noticing a serious performance issue. So stay tuned. | 15:39.36 |
| mvrhel_laptop | Robin_Watts: I recall that tor8 had some sort of tiling in the ios app | 15:39.43 |
| Robin_Watts | https://www.comodo.com/e-commerce/code-signing/code-signing-certificate.php?key5sk0=2128&key5sk1=77275ba453d871abb1b0ce0c112b8466bfc81a7d | 15:39.46 |
| | "Code Sign Apple Mac software for MacOS 9 and OSX." | 15:40.04 |
| mvrhel_laptop | He had a low res scaled up and would render the current viewport has the desired res I thought | 15:40.35 |
| Robin_Watts | mvrhel_laptop: The way the android app works is that we have 2 bitmaps per page. | 15:40.36 |
| mvrhel_laptop | s/has/at/ | 15:40.47 |
| Robin_Watts | The first one is the page rendered at the right resolution for 'fit to screen'. | 15:41.01 |
| mvrhel_laptop | i.e a screen viewport? | 15:41.29 |
| chrisl | fredross-perry: okay - can you drop an e-mail as before? So I'm sure not to miss it, if I'm not here | 15:41.42 |
| mvrhel_laptop | not sure I understand what you mean Robin_Watts | 15:41.46 |
| jogux | Robin_Watts: I think that must be pre-gatekeeper stuff. I definitely believe gatekeeper only accepts actual Apple certiificiates. | 15:41.47 |
| Robin_Watts | We use that for quick redraw (just scale that up/down as required to fill the area being redrawn. | 15:41.48 |
| fredross-perry | yes I will email | 15:41.57 |
| mvrhel_laptop | ok when you say "right" resolution | 15:42.04 |
| chrisl | Thanks | 15:42.07 |
| mvrhel_laptop | you mean native? | 15:42.07 |
| | like 72dpi | 15:42.16 |
| | or to fit to screen | 15:42.28 |
| | actually | 15:42.30 |
| Robin_Watts | mvrhel_laptop: When we start MuPDF on Android, we scale a page so that it just fits into the screen. | 15:42.33 |
| mvrhel_laptop | I understand | 15:42.33 |
| | yes | 15:42.39 |
| Robin_Watts | But we could get away with that bitmap actually being any size - the essential thing is that it's something we can use to quickly do a 'low quality' redraw. | 15:43.22 |
| mvrhel_laptop | yes | 15:43.31 |
| | like I am using my thumbnails | 15:43.38 |
| Robin_Watts | Exactly. | 15:43.44 |
| mvrhel_laptop | but those are much smaller | 15:43.47 |
| rayjj | kens: I found out why removing the XObject (that is unused) causes the color to change. The XObject is examined to see if it uses transparency, and it does, so we install the pdf14 compositor. | 15:43.56 |
| kens | Well that makes sense | 15:44.13 |
| jogux | Robin_Watts: https://www.google.co.uk/search?client=safari&rls=en&q=os+x+certificate+gatekeeper&ie=UTF-8&oe=UTF-8&gfe_rd=cr&ei=7ak_VYz6D8LH8genm4HYBQ seems to have a few âgatekeeper only accept Apple certsâ type results. | 15:44.25 |
| Robin_Watts | The second bitmap we hold is a 'patch' bitmap. | 15:44.27 |
| rayjj | even though we never draw that object | 15:44.42 |
| Robin_Watts | jogux: Rats. Fair enough. $99 is not a dealbreaker though. | 15:44.51 |
| jogux | per year of course :-) | 15:45.00 |
| Robin_Watts | especially if we want to sell stuff through the app store. | 15:45.05 |
| jogux | nods. | 15:45.22 |
| Robin_Watts | mvrhel_laptop: Imagine that we have our page zoomed in. | 15:45.35 |
| rayjj | then, if we are using the clist, some bands use the pdf14 compositor and others don't so the color shifts depending on whether that band needs transparency | 15:45.55 |
| Robin_Watts | consider the patch of that page that intersects with the screen viewport. | 15:45.56 |
| | That's the bitmap we hold for our 'high quality' bitmap. | 15:46.17 |
| rayjj | so now I can explain my bmpcmp strangeness | 15:46.20 |
| Robin_Watts | hence however much we zoom in, the HQ bitmap is never more than a screen in size. | 15:47.19 |
| mvrhel_laptop | Robin_Watts: right. I see how that can work nicely. I need to think a bit about how best to make that work with the wpf structure that I am using for display. | 15:48.22 |
| Robin_Watts | If we pan the page, we can (theoretically at least) pan the contents of the bitmap and then draw the strips round the edge. | 15:48.37 |
| | It's been a while since I looked at the android code so I can't swear exactly what it does, but that's the gist of it. | 15:49.04 |
| | mvrhel_laptop: Do you get called to redraw the pages within the window? | 15:49.37 |
| mvrhel_laptop | the wpf listview is in essence a collection of bit maps that have a particular size | 15:49.45 |
| Robin_Watts | Or do you have to give the window a list of bitmaps ? | 15:49.53 |
| mvrhel_laptop | list of bitmaps | 15:50.02 |
| Robin_Watts | hmm. That's not nice :( | 15:50.23 |
| mvrhel_laptop | no | 15:50.25 |
| | I suspect I am going to have to do something a bit different for the zoom in case | 15:50.39 |
| Robin_Watts | Can you overlay anything on top of the listview? | 15:51.09 |
| mvrhel_laptop | yes | 15:51.15 |
| | I can | 15:51.17 |
| | and that is what I am thinking | 15:51.23 |
| Robin_Watts | i.e. could you have the pages as a list of thumbnails? | 15:51.24 |
| | (and have them scaled) | 15:51.27 |
| mvrhel_laptop | yes, and I can draw a high res image over top | 15:51.39 |
| | I believe I should be able to do this | 15:51.53 |
| Robin_Watts | and then overlay hq patch bitmaps for the 'current' oages. | 15:51.55 |
| | In android we can get away with 3 hq bitmaps (current page, page + 1, page -1) | 15:52.19 |
| mvrhel_laptop | yes, the fact that I can "draw" search rects and rects for text links | 15:52.22 |
| Robin_Watts | I suspect that as you allow zooms to get lower than the android app does, you'll need to cope with more than just 3 pages at worse. | 15:52.58 |
| | but the total size of the bitmaps in play will never exceed the size of the screen, so you are bounded at least. | 15:53.27 |
| mvrhel_laptop | Robin_Watts: ok. I think I know how I will do this. | 15:56.44 |
| | Robin_Watts: when you say lower than the android app does, what do you mean? | 15:57.22 |
| Robin_Watts | mvrhel_laptop: On the android app, the furthest you can zoom a page out is so that it fits the height or width of the screen. | 15:58.10 |
| | (whichever results in the smaller page). | 15:58.22 |
| mvrhel_laptop | oh | 15:58.25 |
| | zooming out is easy | 15:58.32 |
| Robin_Watts | i.e. you can never zoom the page down so that you have a border on all 4 sides. | 15:58.39 |
| mvrhel_laptop | ok that works ok on gsview. Its the extreme zoom in that is the bigger issue | 15:59.06 |
| Robin_Watts | consequently, because of the distances we use between pages, you can never have parts of more than 3 pages on the screen at once. | 15:59.15 |
| | (in fact, you can never have more than 2 I think) | 15:59.32 |
| mvrhel_laptop | ok. fredross-perry did you follow all of this. You should probably do the same on you zoom-in on the linux side. I guess I should add in some capability in my api to hand a rect off to mupdf to use in | 16:03.52 |
| | clipping | 16:04.07 |
| | fredross-perry: are you using my interface to mupdf? | 16:04.32 |
| fredross-perry | I am using a copy of your interface (muctx.cpp, .h) | 16:05.14 |
| mvrhel_laptop | ok | 16:05.20 |
| | I will update it to use a rect | 16:05.38 |
| kens | I'm off, night folks | 16:06.25 |
| Robin_Watts | fredross-perry: Are you in a similar position to mvrhel? Do you have to provide a list of bitmaps for your display class to use? | 16:08.38 |
| | Or do you get a callback to draw each visible page? | 16:09.11 |
| fredross-perry | I am drawing only visible pages. I run through the documnt to get all the page sizes so I can set up the geometry of the scrolling area. Then I can compute when a page is visible, and draw it then. I draw at low-res while scrolling so the user can see pages going by. | 16:10.36 |
| | But even with a single-page doc, zooming to 6400% willbe a problem unless I do something more. | 16:11.19 |
| Robin_Watts | fredross-perry: So, you are free to keep just 'patches' for the 'current' pages then. | 16:11.31 |
| fredross-perry | i could. | 16:24.38 |
| mvrhel_laptop | So, Acrobat DC allows me to change the page level transparency blending space. It appears that Adobe uses CMYK by default | 17:37.42 |
| | even if the target device is RGB | 17:38.20 |
| | also, blending spaces are not using default ICC profiles if they have been specified as DeviceCMYK or DeviceRGB | 17:39.01 |
| marcosw | I'd like to reboot casper for updates. | 17:48.39 |
| | chrisl and sebras: you two are both logged on. | 17:48.53 |
| mvrhel_laptop | I see that Adobe is definitely doing a dumb conversion of DeviceRGB into DeviceCMYK values if we are going into a transparency group that is DeviceCMYK. However, for the base buffer, they are doing the ICC conversion | 21:28.42 |
| | that is if the target device is CMYK and I am drawing a Device RGB value in, I do the ICC conversion | 21:29.07 |
| | if I have pushed a group that has a DeviceCMYK blending color space, I do the dumb conversion of the Device RGB values | 21:29.35 |
| | now to check the case when the source colors are actually ICC defined | 21:29.49 |
| | and I am drawing into a trans group that is defined in terms of DeviceCMYK | 21:30.12 |
| | to convert or not to convert | 21:30.17 |
| rayjj | mvrhel_laptop: I saw on the logs you mentioned that Adobe is doing a "dumb conversion" from RGB -> CMYK. Do you know what they are doing BG=UCR=100%, BG=UCR=0% or something else ? | 22:20.51 |
| | The key is (obviously) what does and doesn't go into the K channel, and do is it reversible ? | 22:21.38 |
| rayjj | suspects 100% BG+UCR since at least that is (sort of) reversible | 22:22.05 |
| | i.e., sort of like our "GrayToK" option | 22:22.36 |
| sebras | marcosw: no worries. I'm back! | 23:26.34 |
| mvrhel_laptop | rayjj have not gotten that far yet. looking at icc cases now | 23:37.49 |
| | Forward 1 day (to 2015/04/29)>>> | |
IRC Logs