| | <<<Back 1 day (to 2012/04/12) | 2012/04/13 |
| mvrhel | Robin_Watts: for the logs. there is an issue with my branch when running the 051_Ghent file that maros posted. The issue is only in one of the spot channels. | 04:12.59 |
| | so i am not sure what we want to display when that is the case | 04:13.26 |
| | in bmcmp | 04:13.28 |
| | now to figure out what the problem is. | 04:13.48 |
| | wtf. something to do with it being more than one page | 04:20.05 |
| | I need to see what the trunk does with this | 04:25.58 |
| | well that is wrong also. when you run a file with psdcmyk and it has multiple pages, it just renders page 2 | 04:29.45 |
| | both the trunk and the branch do that | 04:29.58 |
| | henrys: any idea what would cause that? | 04:30.10 |
| | I wonder what tiffsep does | 04:30.19 |
| | ok for some reason tiffsep drops page 1. I recall there being a bug for this. Is this the issue that chrisl was going to fix? | 04:32.22 |
| | in any event, my trunk has an additional bug that the pages have garbage in the spot plane | 04:33.27 |
| | when nothing should be drawn there | 04:33.40 |
| | it is like the filll page failed to clear it | 04:33.50 |
| | henrys: is there anything special that is done as we go from page to page while rendering that I am not aware of? | 04:35.38 |
| | and I am not aware of much.... | 04:36.14 |
| | ok. so the issue is that with the current code, if page 1 had a spot color A, then page 2 will create a separation for spot color A even if page 2 did not have spot color A. | 04:57.55 |
| | in the case of my code, I was trying not create a separation for spot color A when we do page 2 (which would seem to make sense to me) but apparently something has not been properly updated with the information | 04:59.04 |
| | and so it is getting garbage in the spot channel for page 2 | 05:01.31 |
| | ok found it | 05:04.42 |
| | I am thinking that the devn separation list should be freed on each page | 05:13.42 |
| | interesting. it doesn't appear that free_separation_names is ever called | 05:15.30 |
| | that would imply that if I had a new spot on each page, I would reach my maximum | 05:15.50 |
| | even though each page has a separate spot | 05:16.06 |
| | if I had the time, I would make an example file like that | 05:28.48 |
| | ok psdcmyk device now a page only has spot set for that page. need to fix tiff sep now | 05:35.39 |
| | ok cool. tiffsep now behaves the same | 05:44.40 |
| | morning chrisl | 05:55.07 |
| | time for bed | 05:55.10 |
| chrisl | morning mvrhel | 05:55.18 |
| | mvrhel: the missing page(s) problem with tiffsep that I've got is caused because when the separations change, the device is closed and reopened by the put_params() - closing the device closes the output file, when we reopen the file to carry on with the output, we truncate it. | 05:55.35 |
| mvrhel | ah. I have noticed that | 05:55.55 |
| | I do need the device to be reopened when the separations change though | 05:56.09 |
| chrisl | Yep, my intention is to change it so we keep the file open during a close/reopen when it comes from put_params | 05:56.42 |
| | But (obviously) go ahead and close the output files when the close device comes from anywhere else...... | 05:57.39 |
| mvrhel | ok but we will still be getting a call to tiffsep_prn_open when the separations change? | 05:58.09 |
| | that is, when they are different on the next page | 05:58.35 |
| chrisl | mvrhel: yes, the device method call sequence won't change at all | 05:58.52 |
| mvrhel | oh I understand what you are saying now | 05:59.13 |
| | you are talking about keeping the file open | 05:59.19 |
| | gotcha | 05:59.22 |
| | ok | 05:59.26 |
| | I am slow right now. well I am always slow. just slower than normal | 05:59.38 |
| | have a good day | 05:59.51 |
| chrisl | Have good night :-) | 05:59.59 |
| hpj | MuPDF developers here? Why does the new version no longer offer "Document Properties" besides "About MuPDF"? | 06:30.05 |
| chrisl | hpj: the MuPDF developers won't be around for a few hours yet - they should see your question in the logs, though, if you want to hang around...... | 06:33.38 |
| hpj | sure thing, thx | 06:36.25 |
| | so european guys, heh? | 06:36.44 |
| | could be asian nighthawks, too, but i don't really believe that | 06:37.23 |
| chrisl | European, yes | 06:37.33 |
| Robin_Watts | hpj: hi | 09:27.30 |
| | What OS are you running mupdf on? | 09:28.11 |
| hpj | windows | 09:30.52 |
| Robin_Watts | I'm not sure it's ever had a document properties. | 09:31.25 |
| hpj | but yes | 09:31.34 |
| | i'm been using mupdf for quite some time now | 09:31.46 |
| | maybe two years | 09:32.07 |
| | and it had that feature as long as i know it | 09:32.24 |
| Robin_Watts | What sort of information did it display? | 09:33.16 |
| hpj | one sec | 09:34.55 |
| | i have to find an old copy | 09:35.01 |
| Robin_Watts | Please. | 09:35.12 |
| | tor8 is the man who'd know for sure, but he's away. | 09:35.25 |
| hpj | my last dl was before dl moved to googlecode | 09:37.17 |
| | so back when the dl was hosted on the mupdf site | 09:37.47 |
| | ok, here we go | 09:38.43 |
| | this mupdf.exe has the date 2010-08-25, but can't garantee it's the original file date, may be the date of my download | 09:39.48 |
| | and it has, below "About MuPDF..." the menu entry "Document Properties..." | 09:40.27 |
| | which lists the following: | 09:40.37 |
| | File | 09:40.41 |
| | Format | 09:40.42 |
| | Encryption | 09:40.45 |
| | Permissions | 09:40.49 |
| | (empty line) | 09:40.56 |
| | Title | 09:40.59 |
| | Author | 09:41.01 |
| | Subject | 09:41.03 |
| | Keywords | 09:41.06 |
| | Creator | 09:41.08 |
| | Producer | 09:41.12 |
| | Created | 09:41.15 |
| | Modified | 09:41.16 |
| | in an application-modal dialog titled "Document Properties" | 09:41.58 |
| | with a single button "Okay" | 09:42.08 |
| Robin_Watts | Right, so it went away: http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=af7f17d4b497a1cb9920112079e7170195cca5e3 | 09:46.54 |
| | We generalised the viewer to do pdf and cbz in a single app, and it got deleted then. | 09:47.36 |
| | I wonder if tor meant to reintroduce it? | 09:47.50 |
| | hpj: I'll ponder on it for a bit. Thanks for telling us. | 09:48.10 |
| hpj | while i'm added it, something else i'd like to report: | 09:49.11 |
| | the "About" dialog's list of key shortcuts is incomplete | 09:49.45 |
| | lacking, for instance, the very important "/" for searching the doc | 09:50.03 |
| | which led me to believe mupdf can't perform search for a long time | 09:50.18 |
| | cosmetically, it's debatable if "About" is such a good name for a dialog whose main purpose it to show shortcut keys | 09:51.06 |
| | older versions don't even list the version number -- now it does | 09:51.25 |
| Robin_Watts | I'll look into that later today. | 09:54.56 |
| | thanks again. | 09:54.59 |
| hpj | sure thing | 09:56.52 |
| | question about the rendering: | 09:57.13 |
| | it appears to me that mupdf's anti-aliasing is quite blurry | 09:57.47 |
| | especially with thin-stroked typefaces | 09:58.15 |
| | like the standard tex documents | 09:58.29 |
| | at standard solution, the result is often that entire letters end up without a single fully black pixel | 09:59.25 |
| | the resulting readability is really not that great, compared to acrobat or even other pdf renderers | 10:00.09 |
| | google's pdf renderer is also quite blurry, but i believe it has imporved somewhat in the past months | 10:00.57 |
| | the one used in google docs and in the chrome browser | 10:01.35 |
| Robin_Watts | kens,chrisl,paulgardiner, anyone else: ok, gents, I've been bashing my head against this for long enough. Can I run a problem past you to see if any of you have bright ideas? | 11:58.03 |
| | I have a test file (Bug689189.pdf) that gives different results when it's renderer as is, and when I pdfclean it to decompress it first. | 11:58.41 |
| kens | Hmm, | 11:58.57 |
| | SHouldn't do. | 11:59.01 |
| Robin_Watts | valgrind gives it a clean bill of health. | 11:59.03 |
| kens | well memory layout will be different | 11:59.42 |
| Robin_Watts | I've disabled shadings and images, and I still see differences. | 12:00.19 |
| paulgardiner | Do you see the same differences in all viewers? | 12:00.19 |
| kens | What sort of differences are you seeing Robin ? | 12:00.36 |
| | Also, is this GS or MuPDF ? | 12:00.48 |
| Robin_Watts | It looks to be differences in antialiasing along the edges of paths. | 12:00.49 |
| | mupdf. | 12:00.51 |
| | (either paths or clip regions, I guess) | 12:01.00 |
| kens | That *is* odd. | 12:01.08 |
| paulgardiner | Could it be the accuracy at which floats are pretty printed? | 12:01.27 |
| Robin_Watts | paulgardiner: That's a good point. I'd been assuming it was only mupdf that showed differences. | 12:01.31 |
| | paulgardiner: I don't believe we lex and then write out. | 12:01.45 |
| | the decompression is a purely textual thing. | 12:01.53 |
| paulgardiner | Ah | 12:01.57 |
| Robin_Watts | I added some code to print the output of the lexing stage. | 12:02.17 |
| | and the output for both compressed/uncompressed files is the same. | 12:02.32 |
| paulgardiner | That is weird! | 12:02.57 |
| Robin_Watts | (and I printed floats as "%x", *(int *)&buf->f to allow for representational differences. | 12:03.10 |
| kens | Can you dump the display list for each PDF ? | 12:03.33 |
| | and compare or differences | 12:03.44 |
| Robin_Watts | kens: OF course I can! | 12:03.46 |
| | fabulous idea. | 12:03.49 |
| | And I see differences. Thanks. | 12:08.18 |
| kens | No problem | 12:08.25 |
| | I'd be interested to know why when you find out :-) | 12:08.35 |
| Robin_Watts | I'm seeing tiny differences in the content bboxes for clippaths, and in shading matrices. I bet I'm going to kick myself when I find out why. | 12:09.24 |
| kens | Yeah, it'll be obvous once you know :-) | 12:09.42 |
| Robin_Watts | oh, balls. | 13:32.53 |
| | The pdfclean alters the mediabox. | 13:33.04 |
| kens | Oh dear that would explain it I expect | 13:33.17 |
| Robin_Watts | It goes from 2125.98 to 2125.984 | 13:33.18 |
| | The streams are done textually, the pdf objects (like the mediaboxes) are read in, and then written out :( | 13:33.50 |
| | actually it goes from 2125.984 to 2125.98, so we're not using enough accuracy when writing out. | 13:34.30 |
| kens | Right, I was a bit surprised by the extension ;-) | 13:34.46 |
| Robin_Watts | paulgardiner: Were you hoping to have a meeting today? | 13:50.24 |
| paulgardiner | Easy either way really. Fri is a good day for me, but if Tor is back next week then might be better to wait. | 13:52.03 |
| Robin_Watts | My memory is that tor was out from the 4th for 2 weeks? | 13:52.22 |
| | If that's right, I'd not expect to see him until the end of next week. | 13:52.45 |
| paulgardiner | Oh ok. In that case, today is better than next Tues for me, but I'm happy either way. | 13:54.32 |
| Robin_Watts | Well, I'm available. We can wait to see what henrys thinks. | 13:56.32 |
| paulgardiner | Yeah, ok. Sounds like a plan. | 13:57.14 |
| kens | Robin_Watts : I don't hitnk my branch is working correctly | 14:09.47 |
| | I'm getting lots of diffs from cluster pushing, but my branch is supposed to be up to date | 14:10.04 |
| Robin_Watts | How many commits on your branch ? | 14:10.24 |
| kens | When I switch back to 'master' nothing changes. When I cluster push from there it copies *lots* of files | 14:10.27 |
| | Robin_Watts : none yet | 14:10.33 |
| Robin_Watts | git logg -5 and paste ? | 14:10.44 |
| kens | From master or branch ? | 14:10.52 |
| Robin_Watts | Either. | 14:11.05 |
| kens | $ git logg -5 | 14:11.32 |
| | * c361c83 (cluster/ken) WIP on master: 3590806 Modified to not ignore error co | 14:11.32 |
| | |\ | 14:11.32 |
| | | * 75c5fd6 index on master: 3590806 Modified to not ignore error codes, no expe | 14:11.32 |
| | |/ | 14:11.32 |
| | | * 87aff11 (HEAD, tmp_mem_branch) Support HPGL style path handling. | 14:11.33 |
| | |/ | 14:11.33 |
| | * 3590806 (origin/master, master) Modified to not ignore error codes, no expecte | 14:11.34 |
| | * 1b355f6 Fix 692970 - device reference counting incorrect. | 14:11.34 |
| | (END) | 14:11.35 |
| | Thats on my branch | 14:11.53 |
| Robin_Watts | SO tmp_mem_branch has 1 extra commit. | 14:12.05 |
| kens | It chouldn't | 14:12.12 |
| | shouldn't | 14:12.19 |
| | I wonder if this is due to when you accidentally comiited the HPGL path stuff ? | 14:12.55 |
| Robin_Watts | I suspect so, sorry. | 14:12.59 |
| | so: git checkout tmp_mem_branch | 14:13.06 |
| | git stash | 14:13.10 |
| kens | Nothign to stash | 14:13.15 |
| | I have removed all my changes chasing this ;-) | 14:13.23 |
| Robin_Watts | git reset --hard HEAD~1 | 14:13.24 |
| kens | OK now at 3590806 | 14:13.49 |
| Robin_Watts | OK. Sorted then. | 14:14.00 |
| kens | WHich looks right | 14:14.01 |
| | OK thanks, lets see if this works ;-) | 14:14.08 |
| Robin_Watts | Sorry :( | 14:14.09 |
| kens | No problem, I should have realised what was going on myself | 14:14.25 |
| | If these two cluster runs are OK I will be happy and can go back to head scratching over seg faults.... | 14:15.17 |
| henrys | kens:the tech mahindra vb help should probably go to Scott | 14:47.08 |
| kens | henrys I sent ti to Scott and Miles as well | 14:47.29 |
| | THe one that came in on support as well as Bugzilla | 14:47.38 |
| henrys | oh did you cc: support and I missed it? | 14:48.44 |
| kens | I thought I did.... | 14:48.55 |
| | i certainly intended to | 14:49.20 |
| henrys | ah I see it, sorry | 14:50.43 |
| kens | No problem | 14:50.53 |
| Robin_Watts | http://dl.dropbox.com/u/209/zxcvbn/test/index.html <- Interesting. | 14:55.38 |
| kens | Doesn't do anything for me, let me allow it to script | 15:05.51 |
| | Umm, password cracker ? | 15:06.22 |
| | Oh, evaluator | 15:06.38 |
| henrys | it's amazing how much theoretical work has gone into making solid block ciphers and public key encryption generally and then we protect it all with crap passwords. | 15:07.51 |
| Robin_Watts | paulgardiner used to work for a company that proved things correct/incorrect. They found flaws in various protocols that were believed to be secure. | 15:09.04 |
| | Basically, encryption is hard :) | 15:09.14 |
| kens | Well my old password has a crack time of 4 days | 15:09.28 |
| Robin_Watts | You're very trusting putting live passwords into it :) | 15:11.06 |
| henrys | Robin_Watts:perhaps holes in how the encryption is used - but I can assure you he didn't find a hole in AES or something like that. | 15:11.42 |
| kens | 'old' password | 15:11.48 |
| Robin_Watts | henrys: No, indeed. | 15:12.08 |
| | but a hole in SSH, say, would be as bad, effectively. | 15:12.39 |
| paulgardiner | Yeah, it was Bill Roscoe from Oxford University that was mainly behind the security work. I remember a demo we were giving to a customer where the customer suggested a well known protocal to analyse and Bill found 13 different previously unknown flaws in it. | 15:14.48 |
| marcosw | I'm switching to the password "Ba9ZyWABu99[BK#6MBgbH88Tofv)vs$w" it has a crack time of centuries. Please don't tell anyone. | 15:14.51 |
| henrys | and all you people have macpro logins damn. | 15:15.18 |
| Robin_Watts | marcosw: Can you put that in an email please? I'll forget what not to tell people otherwise. | 15:15.33 |
| henrys | how's your back marcosw? | 15:16.17 |
| paulgardiner | Me too. I don't want to accidently find I'm using the same password as you. | 15:16.18 |
| marcosw | henrys: better but not perfect. It's supposed to take 3 days for the swelling to go down completely. | 15:17.10 |
| Robin_Watts | marcosw: Is this a permanent cure, or a stop gap? | 15:17.28 |
| marcosw | Robin_Watts: there is a 75% chance that it will permanent, but may take 2 or 3 shots. | 15:19.12 |
| Robin_Watts | Well, let's hope it works! | 15:19.54 |
| henrys | marcosw:so it has a 75% chance of healing itself and the epidural gets you through the pain? | 15:24.50 |
| Robin_Watts | henrys: Do you know when tor8 is due back ? | 15:27.47 |
| marcosw | No, the shot was steroids which are supposed to reduce the swelling and allow the nerves to return to there normal location (along with exercise and physical therapy). I had already tried oral steroids, muscle relaxants, and physical therapy by itself, none of which appeared to make an difference. The most annoying thing is that it's in my right arm and the two most painful things were driving and using a computer (particularly a mouse). My injury is | 15:28.23 |
| | between C6 and C7, which is apparently a pretty common area. | 15:28.24 |
| henrys | remembers his wife screaming "epidural" when the reality of "natural" sunk in. | 15:28.24 |
| | Robin_Watts:let me search my mail. | 15:29.02 |
| Robin_Watts | remembers seeing an episode of Northern Exposure, where Fleischman took a pre-natal class, and he said "The only 4 words you need to remember are "I want my Epidural!"". | 15:29.42 |
| henrys | marcosw:I guess epidural is just a deliver mechanism I didn't understand that. | 15:30.04 |
| marcosw | If you are really curious see <http://www.spine-health.com/conditions/herniated-disc/cervical-herniated-disc-symptoms-and-treatment-options>. Injections are are the final step before surgery. | 15:30.47 |
| henrys | Robin_Watts:the 18th | 15:32.15 |
| Robin_Watts | will not send an email back to support saying "Dial 911". | 15:32.26 |
| | So that's next wednesday - which with jetlag may mean thursday or friday before we see him on here? Do we want to have a paulgardiner meeting before then ? | 15:33.20 |
| henrys | I think we should have one Tuesday if we have stuff to talk about. | 15:34.10 |
| marcosw | what in the heck is wrong with the cluster now!?!? | 15:34.31 |
| henrys | paulgardiner:it would be better for me to get the status report Monday, tuesday morning is hectic and I don't have time to carefully read it. Is that okay? | 15:35.06 |
| | or we can push back the meeting a day. | 15:35.25 |
| paulgardiner | Yes sure. I'd been wondering whether we could shift it from Tuesdays to Fridays though. | 15:36.57 |
| | Not if that is awkward for anyone else, but if all days are fairly equal for most people Fri would be better for me. | 15:38.25 |
| henrys | that's fine and tor would be available for the next one. Tor probably won't like it but he's pretty fussy ;-) | 15:38.26 |
| Robin_Watts | paulgardiner: Do you have any burning issues you'd like to get discussed before next friday ? | 15:38.53 |
| paulgardiner | Nothing burning, but I have worked Mon and today this week, so I have a little progress I could mention. | 15:39.37 |
| | henrys: If Tor doesn't like Fri, no problem going back to Tues. | 15:40.02 |
| henrys | I don't think he likes Tues either so I imagine Fri will be just as good. | 15:41.12 |
| | I can't remember what the issue was maybe interfering with dinner which is a time (not day) issue. | 15:41.48 |
| marcosw | false alarm re. the cluster. looks like here was an internets problem with casper, none of the nodes were able to connect at 14:59 UTC, casper detected this, waited 10 minutes, and then restarted the cluster job, which is the way it's supposed to work. | 15:43.23 |
| henrys | I don't know how many read the email from the PDF in javascript guy. He mentioned a C -> JS conversion, I googled and couldn't find anything. Does such a beast really exist? | 15:46.35 |
| Robin_Watts | "and as there is a way to convert C/C++ code to JavaScript" | 15:47.36 |
| | Emscripten | 15:48.02 |
| | You feed the C into llvm, and it generates its internal structure. | 15:48.20 |
| | That then gets processed out as javascript. | 15:48.31 |
| | But please tell me we're not seriously considering relicensing. | 15:48.59 |
| | https://github.com/kripken/emscripten/wiki | 15:49.52 |
| | Quick! Port ghostscript! :) | 15:50.09 |
| henrys | I hope not but ray pushed it off to Miles and I haven't had a chance to talk to miles about it. | 15:51.32 |
| | don't forget our pdf interpreter is written in postscript - we aren't much better off. | 15:52.19 |
| Robin_Watts | ahem, mupdf. | 15:55.07 |
| henrys | obviously I was talking about ghostscript | 15:55.25 |
| | he he we need a ps -> js solution. | 15:55.59 |
| Robin_Watts | Peter could do it. With macros. | 15:58.53 |
| henrys | seriously I don't see how this will work for them. Chrome has a C based pdf solution that will always outputperform their solution, doesn't make sense. More folks will use chrome I guess. | 15:59.12 |
| Robin_Watts | As much as I like mozilla, they've lost the plot a bit recently; firefox has become bloated and slow. | 15:59.47 |
| | I've been trying to track down why mupdf renders differently on macs | 16:01.02 |
| | and I've found at least one case - radial shadings. | 16:01.12 |
| | I think it's to do with sinf and cosf giving different results. | 16:01.25 |
| | I wonder about writing our own simple table based version. | 16:01.43 |
| henrys | Robin_Watts:is the gapto filling in my court now? | 16:02.13 |
| Robin_Watts | I believe so. | 16:02.26 |
| | Sorry, should have updated the bug. | 16:02.34 |
| henrys | I must have missed the commit that fixed the stroking. | 16:03.03 |
| Robin_Watts | oh, wait... | 16:03.34 |
| | Damn. I ran a cluster test before committing to verify it didn't break anything, and forgot about it. | 16:04.12 |
| | So it's still mine. | 16:04.16 |
| | And it looks like it turned up problems :( | 16:04.34 |
| henrys | you showed me a bunch of problems that we thought should be addressed by modifying gl/2 but I need that code as a patch or checked in. | 16:05.37 |
| Robin_Watts | yes. | 16:06.31 |
| henrys | the bmpcmp output you had seemed to fix the stroking issues. | 16:06.34 |
| Robin_Watts | And before I checked it in, I wanted to do one last run to make sure it didn't affect anything without it being enabled. | 16:06.56 |
| | so I ran that check, and forgot about it. | 16:07.02 |
| | And it seems it DOES effect stuff, so I need to see why. | 16:07.17 |
| henrys | oh okay | 16:07.35 |
| Robin_Watts | This is very odd. I can't see why anything in my patch should make a difference unless we turn on hpgl mode. | 16:12.21 |
| | (We only get gapto's if hpgl mode is turned on, and the only changes to the path code, only affect gaptos) | 16:12.49 |
| ray_laptop | kens: I suppose you noticed I closed that pesky 8.63 bug. I doubt Miles will be able to get them onboard as a customer, but I'm fairly certain we would regret it if he did | 16:14.47 |
| kens | ray_laptop : chrisl just told me you'd closed it. | 16:15.30 |
| henrys | geez I was hoping we'd give them a try that's a 1 billion dollar company. | 16:17.45 |
| kens | Well, I did leave them an opening to come back, but for me 9.05 works OK | 16:18.21 |
| henrys | okay good enough | 16:19.09 |
| Robin_Watts | Really? They are 1 billion dollar company, or they are working for a 1 billion dollar company? | 16:19.49 |
| henrys | ray_laptop:maybe best to send a suggestinon that the bug be closed to kens next time, at least I would prefer that if it were my bug. | 16:21.12 |
| ray_laptop | hmm... the 11-13.PS CET (that got SEGV in my clusterpush yesterday) reports: GPL Ghostscript GIT PRERELEASE 9.06: .\base\gscscie.c(180): 0x2576f50 has ref_count of -1! with -Z? | 16:21.16 |
| | henrys: OK. Sorry, kens | 16:21.55 |
| henrys | Robin_Watts: Tech Mahindra is a billion dollar company that's all I'm saying. | 16:22.01 |
| kens | NP | 16:22.03 |
| Robin_Watts | henrys: right. | 16:22.13 |
| | I wonder if they are the ones that keep phoning me to tell me there is a problem with my PC... | 16:22.44 |
| ray_laptop | IMHO, we should be more assertive with closing nuisance bugs -- possibly even to the point of closing a bug as INVALID until they attach all the requested info and have them REOPEN it | 16:23.14 |
| | that way if they can't figure out how to reopen the bug we get rid of them. | 16:23.50 |
| kens | Based on the fact that they *are* a big company, and I'd sent them along to Scott, I wanted to leave i open for a bit. But my later comments were more sharply worded | 16:24.06 |
| henrys | I do wonder what they're up to. Someone has outsourced that project to them. | 16:25.43 |
| ray_laptop | kens: yes, I noticed that you cc'ed Scott and Miles so they could investigate whether or not these guys need a license. Thanks | 16:29.52 |
| henrys | kens:I guess ray_laptop's email should be enough to find the pointer to freed memory in the pdf server. That's a good idea to change the index - I always stupidly added a static counter to the code and stopped it conditionally ... | 16:30.10 |
| ray_laptop | henrys: I hoped it might be useful to others. | 16:31.09 |
| kens | got to go night all. | 16:31.24 |
| ray_laptop | bye, kens | 16:31.29 |
| marcosw | henrys: do we want to have a support meeting today? | 16:32.24 |
| Robin_Watts | henrys: Hmm. All the changes disappeared when I bmpcmped them. | 16:32.28 |
| | No, ignore me, being stupid. | 16:32.46 |
| henrys | marcosw:I didn't read the report yet do you think we need one? | 16:36.06 |
| | the 2 customer issues seem to be dispatched okay. so nothing to do? | 16:38.18 |
| marcosw | henrys: the only question i had was http://bugs.ghostscript.com/show_bug.cgi?id=692968 | 16:38.46 |
| henrys | what does chrisl say? | 16:39.56 |
| chrisl | Huh, I though alexcher had taken that bug...... | 16:40.18 |
| | It's really not a "Font" problem at all | 16:40.31 |
| ray_laptop | marcosw: I think we should close it. We are following the spec. Why should we arbitrarily ignore the AP stream and draw something else ? | 16:40.37 |
| marcosw | ray_laptop: everyone else does | 16:41.00 |
| henrys | chrisl:It was assigned to you so I assumed there was something you wanted to add. | 16:41.14 |
| ray_laptop | marcosw: if everyone else jumped in the lake, would yoou do it ? ;-) | 16:41.31 |
| chrisl | henrys: no, as I said, I thought Alex had reassigned it when he commented - I guess I was wrong...... | 16:41.43 |
| henrys | not matching acrobat and preview is painful, there is nothing we can do? | 16:42.17 |
| Robin_Watts | Are they perhaps synthesising an an appearance stream because they support editing? | 16:42.49 |
| henrys | and is it just viewing -- what if the file is rendered to tiff? | 16:43.27 |
| chrisl | FWIW, I think at most it could be an enhancement - we *are* compliant with the spec | 16:43.34 |
| marcosw | I can try filing this as a bug with Adobe and claiming it's a bug in Acrobat, but I don't think I could explain it to them (i.e. "Acrobat displays the apparently correct character, but our analysis of the PDF stream says that it should be displaying a Thorn followed a y with umlauts."). | 16:43.50 |
| chrisl | marcosw: the other interpreters aren't wrong either - the spec allows either approach. | 16:44.27 |
| marcosw | so we should have a command line option to pick which behavior we use? | 16:45.04 |
| ray_laptop | chrisl: how are you supposed to arbitrarily come up with an appearance stream that happens to match what the creator intended ? | 16:45.12 |
| henrys | so can we add some words quoted from the spec and put it in the bug. What's there now seems a bit weak. | 16:45.13 |
| ray_laptop | the whole point of an AP stream is for the creator to control the appearance | 16:45.53 |
| chrisl | ray_laptop: I was about to say: in *this* case there is enough information for us to (fairly) unambiguously create an appearance as intended - I don't think that is true in the general case. | 16:46.11 |
| marcosw | henrys: rendering the file to tiff from acrobat also generates a '$'. | 16:46.52 |
| | If I turn on Print Production Output Preview in Acrobat the $23,800 goes away but a '$' appears in a different place (and in a different font). | 16:49.15 |
| chrisl | Whatever way you look at it, it's not a bug | 16:51.19 |
| ray_laptop | marcosw: stepping through the file with -dPDFSTEP and -dNOTRANSPARENCY the $__________ is shown first, then the other text "overprints" it later | 16:51.45 |
| marcosw | This is a P1 customer who hasn't reported many other bugs in the recent past. | 16:52.08 |
| chrisl | How does that change the classification? | 16:52.23 |
| ray_laptop | I couldn't find cust 780 | 16:52.26 |
| henrys | I guess it isn't clear to me why we can't emulate the behavior. | 16:53.17 |
| | after buying into the fact that is not strictly a bug. | 16:53.51 |
| chrisl | henrys: we're talking about synthesizing the appearance stream - so, what heuristics does Acrobat implement to do that? | 16:54.41 |
| marcosw | chrisl: We tend to do things for P1 customers that go beyond fixing bugs. | 16:55.31 |
| henrys | the same one's as preview ;-) | 16:55.34 |
| | what does xpdf do with this? | 16:55.55 |
| marcosw | ray_laptop: they are listed in the support list that Joann sent out on 3.22.12. | 16:56.17 |
| chrisl | marcosw: I'm not saying we shouldn't do it, but it's not a bug, and being a P1 customer doesn't make it a bug...... | 16:56.22 |
| henrys | chrisl:but seriously it does seem like we might be missing something obvious if Preview gets it. | 16:56.51 |
| chrisl | henrys: the point is, it's going to take quite a lot of work to reverse engineer whatever Acrobat does to get the results it does - is that a good use of our time? | 16:58.29 |
| marcosw | From their point of view it's a bug, both Acrobat and Apple Preview display a '$', which in the context of the rest of the document is reasonable. We display a thorn and a ÿ, which I still don't see how the appearance stream code be affecting, at least not for normal definitions of appearance. | 16:59.17 |
| chrisl | marcosw: Alex explained quite clearly in the bug comment why that's happening - we *are* compliant with the spec, we *are* working as intended, therefore *not a bug*! | 17:00.20 |
| henrys | maybe a compromise is to spit out the relevant section of the manual to the customer with an explanation but if they push back I think we have to try and figure it out. | 17:00.39 |
| marcosw | Alex said the appearance stream was "incorrect". | 17:01.01 |
| chrisl | marcosw: it is incorrect: it's using a multibyte string with a single byte font | 17:01.29 |
| marcosw | so what if we ignore appearance streams that do that? | 17:02.05 |
| chrisl | marcosw: how would we tell? | 17:02.28 |
| henrys | chrisl:what is Adobe doing exactly I think part of the problem here is the analysis in the comment isn't complete. | 17:02.31 |
| chrisl | henrys: It fully explains why our output looks the way it does | 17:03.02 |
| henrys | chrisl:it does not say what font and character adobe is using. | 17:03.21 |
| marcosw | chrisl: you could ask alexcher to tell you what heuristics he used to determine that the appearance stream was incorrect and then program an expert system to emulate his process. | 17:03.48 |
| chrisl | marcosw: "visual inspection of the string based on experience" is hard to implement in software...... | 17:04.27 |
| henrys | does it substitute a double byte font or use a different encoding. | 17:04.33 |
| | ? | 17:04.34 |
| chrisl | I can't remember, I did look at it briefly.... let me have a quick look | 17:05.15 |
| henrys | is alexcher around? | 17:05.20 |
| marcosw | so it's reasonable to specify multibyte string with a single byte font in an appearance stream. | 17:05.27 |
| henrys | maybe we should just wait for him since he's already studied it. | 17:05.44 |
| chrisl | marcosw: how do we tell it's a multibyte string, and not just a string with funky character codes in it? | 17:05.56 |
| | henrys: Acrobat is using Helvetica just like we are, but it's using a single byte string from another entry in the annotation dictionary | 17:08.36 |
| henrys | well at least let's assign it to alexcher and resume discussion with him when he's around. | 17:11.35 |
| ray_laptop | I think what Acrobat is doing is simply using the /V (value) field and picking an arbitrary font. The font is clearly different to what we use. | 17:12.23 |
| henrys | chrisl:it does seem to me with about an hour of tweeking the encoding and checking what acrobat does a pattern would present itself. | 17:12.52 |
| chrisl | ray_laptop: Acrobat is getting the font from the /DA | 17:13.04 |
| ray_laptop | Object 31 is the Annotation the the /v value and it has /AP << /N 30 0 R >> | 17:13.11 |
| henrys | marcosw:can you change it back to alexcher? | 17:13.28 |
| chrisl | henrys: this isn't an encoding issue - Acrobat doesn't use the stream with the multibyte string in it at all | 17:13.34 |
| henrys | it never uses it? | 17:13.53 |
| chrisl | No, it totally synthesizes it's own based on other information in the annotation dictionary | 17:14.19 |
| henrys | oh I thought is wasn't using it because it detected a mismatch. | 17:14.53 |
| ray_laptop | henrys: I think chrisl is right -- it is using the /DA and /V | 17:15.16 |
| chrisl | FWIW, I'm not arguing against doing the work, I just think we need to be clear that what we have is not wrong, and prioritize it with that in mind...... | 17:16.32 |
| henrys | then I guess if alexcher can't think of anything we'll push back and make it an enhancement. But comment #2 in the bug is not enough for the customer. We need a complete explanation with quotes from the spec. etc. | 17:17.48 |
| ray_laptop | chrisl: henrys: The other issue is that we need to decide WHEN to ignore the AP and when not to (yet another option?) | 17:18.02 |
| henrys | and maybe the bug report to Adobe would be useful, they may give us info about their heuristics. | 17:18.48 |
| ray_laptop | IMHO, ignoring the AP stream by default is a bad idea | 17:18.50 |
| chrisl | ray_laptop: I agree, I think if we go ahead with it, then the synthesized appearance should be the option, and the AP is the default | 17:19.36 |
| | ray_laptop: of course, AP is an option entry - I thought it was required..... | 17:20.13 |
| henrys | marcosw:do you have xpdf installed somewhere? | 17:20.32 |
| | or maybe chrisl could check that. | 17:20.42 |
| chrisl | xpdf matches Acrobat | 17:20.55 |
| ray_laptop | henrys: the one thing we can point out is that by ignoring the AP, the positioning of the text is incorrect since the "2 3.3355 Td" is ignored | 17:21.52 |
| Robin_Watts | mvrhel, marcosw: I see the problem with bmpcmp and psdcmyk that's producing the stripey output. | 17:22.25 |
| mvrhel | oh good | 17:22.35 |
| | did you commit a fix? | 17:22.53 |
| Robin_Watts | It's in the png writing code. I'd only tested the bmp writing code, and the cluster writes pngs, sorry. | 17:22.55 |
| | I've just this second spotted the problem. | 17:23.04 |
| ray_laptop | hi, mvrhel. I'm looking into a ref counting problem with CIE colorspaces (ref count goes to -1) | 17:23.12 |
| mvrhel | ok. let me know when you fix it and then I will rerun my bmpcmp | 17:23.23 |
| | ray_laptop: ok | 17:23.31 |
| | ray_laptop: if you need me for anything let me know, otherwise I am pushing on with tiff sep. did you see the interesting issue that I ran across last night? | 17:25.51 |
| chrisl | henrys: I've reassigned that bug to Alex - if he's snowed under, he can punt it back to me, at least for a write up - I'm out of time today. | 17:26.39 |
| mvrhel | darn forgot to add in the -t 5 in the bmpcmp run | 17:26.56 |
| henrys | okay great. Let's see how alexcher weighs in. | 17:27.08 |
| chrisl | Cool, I'm off now - goodnight all! | 17:28.10 |
| henrys | bye chrisl | 17:28.22 |
| | marcosw:any other bugs - I hope not. | 17:29.00 |
| | ? | 17:29.01 |
| ray_laptop | mvrhel: yes, I saw that you tripped over the missing 1st page bug that chrisl_away is working on | 17:29.44 |
| mvrhel | ray_laptop: well yes. but the thing that I also found is that when printing multiple pages with a %d in the output file name, we end up doing an output for a separation when printing page 2 for a spot that is only on page 1 | 17:30.53 |
| ray_laptop | mvrhel: yes, I saw that. Sounds like a definite bug. | 17:32.42 |
| mvrhel | it is fixed now in the branch that I have | 17:33.09 |
| | Robin_Watts: is that the fix? | 17:41.09 |
| Robin_Watts | IS what the fix? | 17:41.18 |
| mvrhel | oh I thought you did a fix | 17:41.34 |
| | sorry | 17:41.36 |
| | for the stripy output | 17:41.48 |
| Robin_Watts | I just did a bmpcmp, and it didn't die, so I'll commit it. | 17:42.10 |
| mvrhel | ok. I will try my bmpcmp after that | 17:42.25 |
| Robin_Watts | OK. go for it. | 17:42.41 |
| ray_laptop | mvrhel: the ref count problem is due to the 'restore finalize' discovering the cie abc colorspace in a chunk that will be subject to restore, decrementing and freeing it, then LATER finding another instance of it in 'gmem' (during alloc_restore_all). | 17:44.34 |
| mvrhel | ray_laptop: not sure I follow that | 17:50.17 |
| | so someone was still pointing to it then? | 17:51.08 |
| | are we missing an increment some place | 17:51.13 |
| marcosw | henrys: Sorry, I had to step out. The other P1 bug that isn't going well is <http://bugs.ghostscript.com/show_bug.cgi?id=692982>. Ken says in an email that there is a setdistillerparams that forces the output to RGB. | 17:53.08 |
| ray_laptop | mvrhel: one instance is in lmem->stable_memory, the other is in gmem -- the 'rc' structure has memory == lmem->stable_memory, so the problem is (partly) having a chunk in gmem that points to something that is in lmem (although 'stable_memory' should be "safe" since it is not normally subject to save/restore) | 17:55.03 |
| henrys | okay reading it | 17:55.42 |
| ray_laptop | mvrhel: I think I can fix it by setting the pcs->finalize to NULL so that it won't get called again | 17:55.48 |
| marcosw | henrys: when I convert the file to PDF via Distiller and then saveas TIFF using the Colorspace:determine automatically it generates a monochrome file. | 17:58.22 |
| ray_laptop | in gs_cspace_final gscspace.c:98+ if the rc.ref_count was 1 upon entry (sort of ugly) | 17:59.06 |
| henrys | marcosw:so why is this a bug? | 17:59.39 |
| ray_laptop | mvrhel: we have to do it in a way that avoids checking the rc.ref_count after the memory is freed, so check the rc BEFORE doing the finalize | 18:00.22 |
| | have to run an errand bbiab | 18:00.38 |
| marcosw | because we used to generate a monochrome tiff file and acrobat still does (I just checked, the distiller generated PDF files monochrome as well: BitsPerComponent 1 /ColorSpace /DeviceGray /DecodeParms ) | 18:00.40 |
| mvrhel | ok | 18:00.41 |
| henrys | marcosw:oh nvm | 18:00.42 |
| | sorry | 18:00.44 |
| marcosw | so either Ken is wrong or distiller ignores the setdistillerparams | 18:01.29 |
| henrys | can we assign it back to kens with that question, I think michael can't do much with this one until we understand that. | 18:02.21 |
| | it seems it should go to kens or has he punted on it? Was there email about this one I possibly missed. | 18:05.57 |
| | ? | 18:05.58 |
| mvrhel | Robin_Watts: still some stripy images. I will take a look closer to see what the diffs are between the trunk and the branch with these | 18:06.29 |
| | assuming those check out ok, I think I am down to 1 or 2 issues | 18:06.49 |
| Robin_Watts | mvrhel: Damn. | 18:06.54 |
| mvrhel | Robin_Watts: did you fix get pushed to all the clusters? | 18:07.21 |
| | s/you/your/ | 18:07.26 |
| | I recall marcosw having to do something special to make that happen | 18:07.45 |
| | but maybe I am wrong | 18:07.58 |
| Robin_Watts | Should have been. I fixed it blind, because I can't easily test the png writing here, so let's assume it's my cockup. | 18:08.15 |
| mvrhel | ok. I am going to go beat on my shading issue now in this | 18:08.59 |
| | Robin_Watts: not critical but the images are upside down too | 18:11.56 |
| marcosw | henrys: kens said that he was going to follow up but never did. I'll add the contents of his email and the results of my experiment with distiller to the bug and assign it to him. | 18:17.12 |
| henrys | okay | 18:17.36 |
| marcosw | mvrhel: you are correct, the bmpcmp.c changes don't get pushed automatically I'll fix that so they do and push this one manully. | 18:18.03 |
| mvrhel | ok. so Robin_Watts, there is hope... | 18:18.20 |
| Robin_Watts | marcosw: Don't bother. | 18:18.30 |
| | I've just tested and spotted a problem with my fix. | 18:18.37 |
| marcosw | okay, why not | 18:18.37 |
| Robin_Watts | And it's a pain :( | 18:18.50 |
| marcosw | okay, I'll fix the code so that when you do push bmpcmp.c it will propagate to the nodes. are you also adding multi-page psd support to bmpcp? | 18:19.21 |
| Robin_Watts | marcosw: I thought I already had... | 18:19.39 |
| mvrhel | no it seems to just do the 1st page | 18:19.51 |
| marcosw | mvrhel: maybe there aren't any differences on page 2+? :-) | 18:20.17 |
| Robin_Watts | Does more than one when I run it locally. | 18:20.22 |
| mvrhel | oh no it does show multiple pages | 18:20.23 |
| | sorry | 18:20.31 |
| | all is good then | 18:20.41 |
| Robin_Watts | I have a plan, I think. | 18:20.46 |
| mvrhel | a plan is a good start | 18:20.56 |
| | more than what I have in trying to figure out this shading issue | 18:21.18 |
| Robin_Watts | mvrhel: currently spots aren't shown in the rgb diff at all. | 18:25.44 |
| | Did you say you wanted to talk about that ? | 18:25.51 |
| mvrhel | well, I was wondering about it. | 18:26.25 |
| | if there is a diff in a spot plane what is shown? | 18:26.38 |
| Robin_Watts | You see the red/green markings where the diffs are. | 18:26.59 |
| | but the spot itself causes no image. | 18:27.09 |
| mvrhel | ok | 18:28.11 |
| marcosw | we could hack things such that we use tiffsep instead and then treat each of the spot colors as a monochrome file. | 18:28.27 |
| Robin_Watts | So if you've got a picture of a cat in the CMYK channels, and you have a spot of a cross across it, and the only difference between your 2 test files is in the spot, you'll see a cat, with (some section of) a red/green cross on top of it. | 18:28.28 |
| mvrhel | I suppose it would be hard to show the gray scale of the spot | 18:28.50 |
| Robin_Watts | When forming the CMYK image, I could treat the spots as K. | 18:29.00 |
| mvrhel | no I was thinking of a CMYK + 3 spots resulting in 4 images | 18:29.25 |
| Robin_Watts | My new plan is to map down from CMYK + spots to CMYK (after doing the diff). Then I convert from CMYK to RGB, scribble the diff on top, and then write it out. | 18:29.54 |
| | Outputting more images is harder. | 18:30.18 |
| mvrhel | but awful useful... | 18:30.30 |
| | otherwise, I am going to have to go and render them myself | 18:30.59 |
| | to check | 18:31.01 |
| Robin_Watts | I'd be more tempted to add support for the mapping of spots to CMYK. | 18:33.09 |
| mvrhel | That would be even better | 18:33.56 |
| | I could help you with that | 18:34.10 |
| Robin_Watts | OK. That doesn't fundamentally change the structure of the code. | 18:34.28 |
| mvrhel | right | 18:34.32 |
| Robin_Watts | It just means that I will need to extend the function I'm currently writing. | 18:34.39 |
| | So, let me fix the stripey thing first. | 18:34.48 |
| mvrhel | ok. | 18:34.51 |
| | marcosw: is there a way for me to run a clusterpush with just psdcmyk at 300dpi? | 18:38.01 |
| marcosw | probably using the filter option but you'd have to ask Robin_Watts about that; it's his hack. | 18:38.34 |
| mvrhel | more Rube Goldberg fun | 18:38.53 |
| | ;) | 18:39.04 |
| Robin_Watts | -filter=psdcmyk.300 | 18:39.07 |
| mvrhel | cool. easy enough | 18:39.14 |
| | now get ready to watch things explode | 18:39.22 |
| Robin_Watts | All I do is grep the filename for the given filter. | 18:39.24 |
| | Or is it --filter? | 18:39.37 |
| | I wrote an email to tech so I wouldn't have to remember :) | 18:39.46 |
| mvrhel | let me find the email | 18:39.56 |
| Robin_Watts | I suspect it's -filter= | 18:40.17 |
| mvrhel | hmm that finished awfully quick. | 18:49.38 |
| | and it did not do anything. does psdcmyk.300 have to be part of the normal test to be used? | 18:50.13 |
| | marcosw or Robin_Watts? | 18:50.20 |
| Robin_Watts | mvrhel: Yes. | 18:50.32 |
| mvrhel | because with a normal clusterpush.pl we just do 72 dpi | 18:50.36 |
| | ok that is the issue then | 18:50.39 |
| Robin_Watts | All it does is take the list of files it would usually do, and filter them. | 18:50.48 |
| mvrhel | ok | 18:50.52 |
| marcosw | do we want to add 300 dpi psdcmyk file test to the cluster, at least temporarily? | 18:51.20 |
| mvrhel | I am really going to want to test 300 dpi with psdcmyk before pushing this big of change | 18:51.27 |
| | marcosw: yes. I suppose so. | 18:51.43 |
| | I have already run across one file that was ok at 72 but not at 300 | 18:51.59 |
| | on my own | 18:52.02 |
| marcosw | give me a minute and I'll make it so. | 18:52.10 |
| | I should probably asked if you want page mode or display list (or both). | 18:52.52 |
| mvrhel | for 300 do display list. the page mode is covered at 72 for the most part | 18:53.15 |
| marcosw | done.. | 18:53.36 |
| mvrhel | its good to go already? | 18:53.50 |
| bfig | hello | 18:53.52 |
| mvrhel | marcosw? | 18:53.55 |
| marcosw | yes. good to go. | 18:54.05 |
| mvrhel | wow you are fast | 18:54.11 |
| | thanks | 18:54.12 |
| bfig | i'm wondering about png16m in linux. http://www.gnu.org/software/auctex/manual/auctex/Installation-under-MS-Windows.html <- this guide mentions it | 18:54.25 |
| Robin_Watts | OK. stripey bmpcmp stuff pushed. | 18:54.28 |
| mvrhel | cool thanks Robin_Watts | 18:54.42 |
| marcosw | it was a one line change to build.pl, everytihing else should work as is (fingers crossed) | 18:54.44 |
| bfig | because i am doing some latex and this .png stuff is a problem | 18:54.46 |
| Robin_Watts | bfig: png16m works. | 18:54.47 |
| | I use it all the time both under windows and linux. | 18:55.03 |
| bfig | but where do i get it? apt-cache search png16m returns 0 results | 18:55.06 |
| Robin_Watts | bfig: It's built into ghostscript. | 18:55.18 |
| bfig | ok | 18:55.22 |
| | then my problem must come from other place | 18:55.29 |
| Robin_Watts | gs -sDEVICE=png16m -r300 -o out.png input.ps | 18:55.40 |
| bfig | do i need to manually set -sDEVICE ? | 18:55.52 |
| Robin_Watts | IF you don't specify a device, you will get the default one. | 18:56.15 |
| bfig | well anyway, auctex and the latex/tex layers below it should take care | 18:56.17 |
| Robin_Watts | Which is usually the display device. | 18:56.22 |
| bfig | shouldn't they? | 18:56.25 |
| | ie, i want to know why latex + ps + png == kaboom | 18:56.43 |
| Robin_Watts | IME latex/tex are as user friendly as a condom full of sand. | 18:56.47 |
| mvrhel | had not heard that one before | 18:57.02 |
| | the pdf latex work flow is much nicer | 18:57.19 |
| Robin_Watts | So... where was the psd spec again... | 18:57.59 |
| mvrhel | hold on | 18:58.05 |
| | http://www.adobe.com/devnet-apps/photoshop/fileformatashtml/PhotoshopFileFormats.htm#50577409_pgfId-1030196 | 18:58.34 |
| | let me look how we store the mappings | 18:59.04 |
| Robin_Watts | henrys: hpgl stuff pushed. | 18:59.09 |
| mvrhel | 1007 or 03EF is the identifier for the mapping resource | 19:00.19 |
| | which is Obsolete .... | 19:00.34 |
| Robin_Watts | I see an 03EF | 19:00.36 |
| mvrhel | i this manual | 19:00.39 |
| | in this manual | 19:00.43 |
| Robin_Watts | OK. so it's a DisplayInfo structure. | 19:04.35 |
| mvrhel | yes | 19:04.41 |
| Robin_Watts | which is... what ? | 19:04.50 |
| mvrhel | trying to find that | 19:04.55 |
| | in an old manual... | 19:04.59 |
| Robin_Watts | Found it. | 19:09.04 |
| | http://www.fileformat.info/format/psd/egff.htm | 19:09.10 |
| mvrhel | I dont see the display info in there | 19:16.47 |
| | need to head out to lunch with wife. | 19:16.53 |
| | bbiab | 19:16.56 |
| marcosw | adding psdcmyk @ 300 dpi with banding produced some new seg faults: | 19:23.59 |
| | tests_private/comparefiles/Bug692217.pdf.psdcmyk.300.1 i7a Seg_Fault | 19:24.08 |
| | tests_private/ps/ps3cet/11-21.PS.psdcmyk.300.1 meters Seg_Fault | 19:24.08 |
| | tests_private/ps/ps3cet/29-07K.PS.psdcmyk.300.1 macpro Seg_Fault | 19:24.08 |
| | Since mvrhel is changing this code I'll wait until after his commit before filing bugs for these. | 19:24.49 |
| Robin_Watts | mvrhel, marcosw: New bmpcmp pushed that reads the spot color information and applies it when converting down to cmyk. | 19:39.17 |
| | It's entirely possible that the color information is inverted or something. | 19:39.45 |
| marcosw | Robin_Watts: that was fast. | 19:51.39 |
| Robin_Watts | it seems vaguely plausible in the one set of files I have to test it :) | 19:52.25 |
| Robin_Watts | goes for food. Have a good weekend all! | 19:52.45 |
| rschmitty | anyone around with mupdf experience? | 19:53.31 |
| | I'm trying to do: mudraw -o %d sample.pdf | 19:57.09 |
| | I see it processes in cpu and cmd line waits, then finishes, but i dont see any files output | 19:57.26 |
| mvrhel | nice Robin_Watts! | 20:13.07 |
| | aha. segvs at 300dpi caught | 20:14.14 |
| | thanks for adding psdcmyk.300 marcosw | 20:14.25 |
| | lots of work to do but getting there | 20:15.17 |
| henrys | rschmitty:try -o %d.png | 20:17.28 |
| rschmitty | aha! /facepalm. Thank you that did it | 20:19.49 |
| mvrhel | ok. shading issue fixed. on to clist segvs | 20:32.42 |
| | I suspect these are in the pattern trans area based on the file list | 20:33.40 |
| | fun! | 20:33.45 |
| | as suspected. violation in the pattern code during clist playback | 20:37.27 |
| | marcos: ping | 20:39.56 |
| | aha. pattern accumulator bit depth is wrong | 21:13.19 |
| | ok. that was an easy fix | 21:25.00 |
| | I believe I am getting close to having this finished | 21:31.18 |
| | good deal segvs are fixed | 22:11.55 |
| | now testing Robin_Watts bmpcmp fixes..... | 22:12.37 |
| | darn a few issues still at 300dpi | 22:25.06 |
| | but these should be easy to fix | 22:25.10 |
| | bbiaw | 22:25.14 |
| marcosw | mvrhel: I'm back. | 22:40.01 |
| | did you ping me for something? | 22:40.18 |
| Bo98 | Ok, I've compiled MuPDF for android. To use it in my existing eclipse project do I simply copy all the files from the android directory into my project? | 22:54.03 |
| Robin_Watts | Bo98: I don't use eclipse myself. | 23:01.49 |
| | But paulgardiner might know when he's next around. | 23:02.07 |
| Bo98 | Ok | 23:02.29 |
| Robin_Watts | mvrhel: Are the colors right ? | 23:02.39 |
| Bo98 | I'll come back later and check if he's on | 23:03.22 |
| | Forward 1 day (to 2012/04/14)>>> | |
IRC Logs