| | <<<Back 1 day (to 2012/07/26) | 2012/07/27 |
| sebras | tor8: ah now I know what's wrong with that poppler bugzilla pdf I mentioned last night over at https://bugs.freedesktop.org/show_bug.cgi?id=44488. | 00:32.50 |
| | tor8: there are indeed two trailers in the file. the first one has reference to objectnumbers that seem sane, the second have references to objectnumbers that are now what they are claimed to be (Root doesn't point to Catalog e.g.) | 00:33.57 |
| | tor8: so if I provoke a repair by forcing repaired == 1 in pdf_init_document() I can actually see the pages of the pdf. | 00:34.54 |
| | tor8: albeit with all of those annoying warning: ignoring invalid character in hex string: | 00:35.10 |
| | tor8: the reason for this is that immediately after the first trailer (at offset 0x57940) you have a startxref, and offset and a %%EOF comment. after that your are in the middle of an object's stream as indicated by endstream (at offset 0x5efb0). | 00:36.58 |
| ray_work | don't linearized PDF's have multiple xrefs ? | 00:40.30 |
| | A PDF can have as many xref entries as it wants -- also "edited" PDF's have multiple xrefs | 00:41.26 |
| sebras | tor8: so pdf_repair_xref() together with pdf_lex() try to make sense in parsing this binary data as if was a normal file, and get as far as offset 0x57b73 where it finds a '>' which is normally followed by another '>' to mark the end of a dict, but at 0x57b74 mupdf finds 0xcd which causes the first warning about a lexical error where '>' is unexpected. then at offset 0x57bbb repair finds '<' which is parsed as if it was a hex-string which cause | 00:43.02 |
| | ray_work: they can, however if the last trailer entries doesn't point to a catalog containing the page array then the pdf is kind of broken. | 00:44.22 |
| | ray_work: but one can force mupdf to try to repair the file by scanning through the file for viable objects and reconstruct the structure. which is does successfully but it spews a lot of warnings into the log while doing so. and the question was why. | 00:46.12 |
| | the reason being that the first trailer starts in the middle of an object. and this means that the repair process will be confused when it is trying to repair binary data. | 00:48.12 |
| | anywy I think I might have filled up the ircbacklog for tor8, so I bid you guys farewell for tonight! :) | 00:48.41 |
| ray_laptop | WinRT -- yuck. I vote for P/Invoke unless someone (João) wants to give us some (major ?) bucks. WinRT seems to be very C++ (read "bloat") focused | 07:28.01 |
| | Maybe we can presume that P/Invoke invoking our DLL (hopefully in a sandbox) will satisfy him. | 07:29.36 |
| | Robin_Watts: if you have any better insight, I'd appreciate your input | 07:30.17 |
| | MS is SUCH a royal pain !!!!! | 07:30.39 |
| | g'nite | 07:32.51 |
| kens | I did look at it a bit last night with a growing sense of dismay | 07:36.10 |
| | It looks like MS is trying hard to get everyone to write 'portable' code using their own Intermediate COmmand Language, which seems to be something like Java and uses JiT compilation on the target | 07:36.56 |
| | Of course this cuts off any legacy code and it looks like even MS have realised that won't work, so you can still use C & C++ but you can't use the Win32 APIs you have to use the new WinRT APIs | 07:37.50 |
| sebras | tor8: there are a few functions in pdf/pdf_xref.c where we tolerate accessing xref->table[num] where num == 0, this while requiring num > 0 in pdf_load_obj_stm(). is this really consistent? isn't obj 0 supposed to always be free? | 07:54.57 |
| chrisl | kens: I reckon it will be a pain, mainly because so many places fopen and co directly, rather than through a central API - there may well be other similar pains, too :-( | 08:01.16 |
| kens | chrisl we do 'often' use the GS stream API, but not always, pdfwrite is an offender on this. | 08:01.47 |
| | Also many of the other devices I think | 08:02.00 |
| | Looking at what the guy was saying, I think MuPDF is a better fit for tehm anyway, I was going to suggest that someone might want to tell tehm that. | 08:02.33 |
| | But... I guess its still something we need to look at :( | 08:02.57 |
| | We do already have gp_seek and friends, I presume we could 'easily' add gp_fopen ect as well and use that throughout | 08:03.50 |
| chrisl | I wonder how smart the MS Metro-fier thing in VS is - if we implemented fopen etc ourselves, through WinRT, would it cough on that? | 08:05.31 |
| kens | No idea, but it sounds kind of hacky | 08:05.57 |
| chrisl | I've seen similar things done before - if you're system doesn't have bcopy(), provide our own bcopy(), for example..... | 08:07.06 |
| kens | Yes, I just wonder if the Metro stuff will whinge. Apparently it throws compiler errors if you try to use dis-allowed API calls | 08:07.39 |
| | I doubt its smart enough to know that you've defined an routine with the sane name as an API | 08:08.07 |
| chrisl | That's why I wondered how "smart" it was. If MS actually want to people to port older code to the "new world", they'd be dumb not to have covered that solution to the problem. | 08:08.41 |
| kens | THis is MS.... | 08:09.00 |
| chrisl | Yes :-( | 08:09.52 |
| | This is why I think *all* that kind of interaction should be through a core API, then we only have to change one place for any port..... | 08:10.31 |
| kens | Yes, that's why I was wondering if we should do the painful thing and define a gp_fopen and so on | 08:11.01 |
| | And then rewrite everything to use it.... | 08:11.16 |
| chrisl | It wouldn't actually take very long, assuming gp_fopen() would have the same definition as fopen().... | 08:12.00 |
| kens | Well that was my thinking, yes | 08:12.13 |
| | I think hte gp_fseek and so on are the same as the regular ones | 08:12.26 |
| | But I've only looked ath them very briefly to do with 64-bit file accesses | 08:12.51 |
| chrisl | Of course we couldn't use FILE * either, but making it a void * would be easy enough | 08:13.14 |
| | But that means changing the device API........ | 08:13.30 |
| kens | Good point | 08:13.31 |
| | Oh, we can't change the device API :-) | 08:13.41 |
| chrisl | Yeh, I guess we might get away with typedefing FILE when required - oh, it is all just hacky :-( | 08:14.26 |
| kens | Its all going to be hacky. We are moving away from a 'C' world | 08:14.48 |
| | We could always just hope Windows 8 dies horribly | 08:15.04 |
| chrisl | I don't really understand why we have the Ghostscript "file system" API, but fail to use it consistently..... | 08:15.34 |
| kens | And which other Ghostscript API do we use consitently ? :-) | 08:15.53 |
| chrisl | True, but I'm assuming the file system API has always been there, right from LL1 | 08:16.24 |
| kens | I'm not certain that's true, but I don't really know | 08:16.40 |
| chrisl | I thought PS had always used the "%device%" style | 08:17.40 |
| kens | Hmm | 08:17.59 |
| | Adobe did, but there were no devices in level 1 | 08:18.15 |
| | In fact early devices didn't have disks | 08:18.29 |
| | Adobe has always used a Unix-like %diskn%/../.. convention | 08:18.59 |
| chrisl | Well, in the end, it means more pain for whoever tackles this than it really ought to be :-( | 08:19.43 |
| kens | There's no getting away from the pain | 08:19.56 |
| | I expect this is something we will have to talk about in September | 08:20.07 |
| chrisl | Well, change the APIs *now* so we don't suffer the same pain again..... | 08:20.23 |
| kens | I can agree with that :-) | 08:20.39 |
| | Its possible someone may have to get a Windows 8 system in place in order to really investigate this. Presumably whichever sucker does that will also get the job of doing the port. | 08:21.14 |
| kens | nominates Robin_Watts because he's not here yet to defend himself | 08:21.39 |
| chrisl | No, I think you just need the latest VS - we're not actually making a Metro app, just a Metro compatible libary, which should work on Win7, too. | 08:22.12 |
| kens | Hmm, well if you say so. | 08:22.33 |
| | Of course I don't have a Windows 7 system :-) | 08:22.42 |
| chrisl | No, it's MS that says so - I don't have anything that disproves the claim (yet?) | 08:23.24 |
| chrisl | agrees with kens: Robin_Watts is clearly the man for the job....... | 08:23.47 |
| | WTF? Handle errors in the error handler better...... what next? Ghostscript should make coffee?!?!? | 08:33.37 |
| kens | He's opened another new one ? | 08:37.57 |
| | I see he still can't tell the difference between a crash and graceful exit | 08:38.24 |
| | I don't understand his comments either. Clearly we do check for a stack underflow, that's the error we are reporting.... | 08:39.08 |
| | Yet again a link to their bug tracker and no specimen file. | 08:40.21 |
| | Ah, he seems to be claiming that he is having to extract the error manually | 08:41.21 |
| chrisl | What they're complaining about is that the error in the handler causes gs to exit | 08:41.41 |
| kens | Yeah | 08:41.48 |
| | Well if your error handler is broken, what do you expect ? | 08:41.59 |
| | I think I want to see an example in our error handler | 08:42.10 |
| chrisl | I'm pretty sure it says in the PLRM that the error handler is not error tolerant | 08:42.42 |
| kens | Well how can it be ? | 08:42.49 |
| | Also, I had to go read their bug thread to understand what he was talking about | 08:43.07 |
| | I don't think this is something we should be interested in personally | 08:43.29 |
| chrisl | Yeh, logically - but if it's in black'n'white in the ref manual, it would save a bit of arguing | 08:43.38 |
| kens | OK I'll go look | 08:43.46 |
| | I can't see anything like that in the PLRM | 08:46.23 |
| | However the action of the interprter to errors makes it clear that there *should* be an object on nthe stack | 08:46.58 |
| | You shouldn't be invoking the error handler outside the environment of the error handler, and its reasonably allowed to assume that its got an object on the stack. | 08:47.29 |
| | Personally I think its a daft request and would close it, but I'll leave it to Alex ;-) | 08:47.56 |
| | Hopefully this means he's running out of things to report.... | 08:48.17 |
| chrisl | Yes, me too. As far as handling errors during *real* error handling - what happens when you do "stop" outside the server loop? | 08:48.56 |
| kens | Err, don't knwo | 08:49.12 |
| | Hmm, if I try to exitserver I get an invalidaccess error | 08:50.04 |
| | I guess hte password isn't 0 | 08:50.11 |
| chrisl | As you say, it's a dumb idea - I just hope Alex doesn't waste time dealing with it | 08:51.07 |
| kens | I'd rather he did the SMask problem | 08:51.25 |
| chrisl | I was more worried about the reporter arguing, than Alex actually working on the "problem" | 08:52.09 |
| kens | Yeah, that's a likely possibility | 08:52.28 |
| | At least he's labelled it minor | 08:52.45 |
| chrisl | Hmm, can we add a "pointless" category? | 08:54.02 |
| | Actually, you know on QI they have the klaxon thing for certain sub-standard answers? We need a bugzilla enhancement that does something like that! | 08:57.54 |
| kens | And a big screen to go with it :-) | 08:58.53 |
| chrisl | And he's not finished yet :-( | 08:59.14 |
| kens | Oh good grief | 08:59.23 |
| | I wonder if he is supplying a linearised PDF to dumphints.ps | 09:03.51 |
| chrisl | Dunno, I just tried it, and it gave me a typecheck error in "known" | 09:04.25 |
| kens | It looks to me like it expects a linearised PDF, since it is trying to extract a hint stream | 09:04.45 |
| chrisl | Yes, I did use an (allegedly!) linearised PDF, still got the error | 09:05.14 |
| kens | Well, I have to say I don't really know (or care) | 09:05.28 |
| | severity should be minor at best since its a utility, not part of GS | 09:05.55 |
| chrisl | Personally, I'd say it's for "internal"/debugging use only, and not intended for end users | 09:07.14 |
| kens | Well, we do ship it though. | 09:07.29 |
| | But it doesn't look very useful to me | 09:07.40 |
| chrisl | Well, I guess Ray will have an opinion, but I'd either remove it, or put in a "tools" directory in svn-private, where it can rest in peace! | 09:08.59 |
| kens | I'd just kill it myself. *I* don't know what it was intended for, and I'm the most likely to use it I'd have thought | 09:09.34 |
| chrisl | Reading the comments, it looks like someone used it to help reverse engineer what Adobe was doing for their linearised output. | 09:10.17 |
| Robin_Watts | I bought parallels for the Mac yesterday. | 10:09.38 |
| | There is a button on that to download a free windows 8 VM. | 10:09.48 |
| | Sadly... no space left on the macs HD for it. | 10:09.57 |
| kens | ah, so its yours now hten Robin_Watts | 10:09.59 |
| Robin_Watts | yeah, it's mine, for a while at least. | 10:10.14 |
| | If it's undocumented and usused, kill it. | 10:12.24 |
| kens | That's what I think too | 10:12.39 |
| Robin_Watts | That way if someone is using it they'll tell us. And they can always grab it out of git. | 10:12.50 |
| kens | I don't believe anyone is using it... | 10:13.41 |
| | In fact I think the same could be said for most of the contents of /lib | 10:18.23 |
| chrisl | Clearly, no one's using it, otherwise someone would have noticed it doesn't seem to work! | 10:18.43 |
| | Still, I'd like wait for the colonial cousins to have a chance for some input before taking the action - I guess I'll update the bug | 10:20.32 |
| Robin_Watts | chrisl: Hmm. | 10:54.18 |
| | I've got a git checkout on peeves. | 10:54.27 |
| | I change into gs. | 10:54.32 |
| | I ./autogen.sh | 10:54.37 |
| | I make | 10:54.39 |
| | and I get an error about missing jbig2dec/os_types.h | 10:54.53 |
| | am I missing something obvious? | 10:55.27 |
| | I must be doing something wrong, cos this clearly works for other people etc. | 10:59.21 |
| | Hmm. I ran autogen.sh again it this time the file appears to be there. wierd. SOrry! | 11:00.50 |
| kens | Od,, but.... | 11:02.24 |
| Robin_Watts | Did you all read Gabe Newells comments on Win 8? | 11:09.31 |
| | http://www.theregister.co.uk/2012/07/26/gabe_newell_windows_8/ | 11:12.04 |
| kens | Yes, read it yesterday | 11:12.17 |
| | Not enthusiastic about windows 8 ;-) | 11:12.37 |
| Robin_Watts | Well, I'm damned if I can reproduce this bmpcmp difference. | 11:23.35 |
| | http://ghostscript.com/~regression/robin/compare2.html <- Number 70. I can't manage to get the output to look anything like that either with or without my changes. | 11:24.30 |
| | ah, but on Page 3, maybe... | 11:26.26 |
| | bingo. | 11:27.06 |
| sebras | tor8: you read the logs, right? | 11:46.00 |
| tor8 | sebras: yes :) | 12:48.57 |
| sebras | tor8: did it help any? | 14:00.12 |
| chrisl | Robin_Watts: sorry, I missed your question earlier: I did remove jbig2dec/os_types.h from git a while back, so something may have gotten a bit confused by that..... | 14:26.31 |
| Robin_Watts | ooooh, this bug might be to do with the fact the clist gets played back several times... | 15:20.25 |
| tor8 | Robin_Watts: sebras: patch on tor/master for bug 693198 | 15:29.56 |
| henrys | alexcher:I think 693115 is the last blocker - how is that going? | 15:34.38 |
| sebras | tor8: which one? I can only see the whitespace one...? | 15:36.29 |
| | tor8: and 693198 seems to be about adding width/height to the xml output!? | 15:37.07 |
| tor8 | sebras: yes, that one. | 15:40.24 |
| sebras | tor8: oh... gitweb and my browser clipped the patch name to "Consistent use of whitespace in XML in trace device..." | 15:41.23 |
| henrys | Robin_Watts:I'm running fusion 4 on mountain lion | 15:41.34 |
| sebras | tor8: now when I look at the patch itself I noticed that this was not the entire commit messages... | 15:41.55 |
| henrys | well 4.1 | 15:42.00 |
| Robin_Watts | henrys: Well, if parallels can't solve the problem pretty sharpish I'll just get Fusion 4. | 15:42.55 |
| | I'm pondering replacing the drive in the macbook too; 1TB drives seem to make sense at this point. | 15:43.25 |
| sebras | tor8: seems sane as far as I can tell. though personally I would make two separate patches. | 15:45.05 |
| henrys | yes I have 750 G but if you are going to go through the trouble of putting an HD in do an SSD you can bill miles. | 15:45.06 |
| Robin_Watts | Oh joy, this bug is definitely to do with replaying the clist multiple times giving different results. | 15:45.24 |
| | henrys: tempting. | 15:45.47 |
| | I bet that would up the battery life for flights too. | 15:45.58 |
| | I worry that putting a large SSD in this macbook would cost more than the macbook is now worth though. | 15:46.28 |
| henrys | ssd prices seem to be in freefall also, not sure if that is the economy and just a temporary thing. | 15:55.13 |
| Robin_Watts | henrys: really? | 15:55.34 |
| | HD prices have been high of late because of floods in thailand. | 15:55.48 |
| | they are starting to come down again, but aren't there yet. | 15:55.59 |
| | cheapest 480GB 2.5" ssd I can find is 375 quid | 15:56.50 |
| | actually, 512GB for 309UKP. | 15:57.59 |
| | or a funky 1TB for only 2 grand! :) | 15:58.37 |
| henrys | I see 5122GB crucial 399 USD. | 15:59.33 |
| kens | Time to buy some more stuff for the meeting | 15:59.56 |
| Robin_Watts | That sounds like the usual GBP to UKP conversion rate. | 16:00.02 |
| | kens: marcosw is gonna need a bigger car at this rate. | 16:00.22 |
| henrys | what is the exchange now | 16:00.47 |
| | ? | 16:00.48 |
| kens | ~1.5 | 16:00.56 |
| Robin_Watts | 1.63 | 16:01.02 |
| kens | Oh, that high ? | 16:01.13 |
| Robin_Watts | oh, actually... 1.55 or 1.58 depending on whether you're buying or selling. | 16:01.38 |
| kens | :-) | 16:01.56 |
| henrys | well marcosw might be able to dig up something cheaper in the valley micro center sale or something. | 16:02.42 |
| Robin_Watts | mdev->num_planes = 0x3c5710 smells wrong to me :) | 16:03.59 |
| | Right. So the profile handle is being dropped for this color space. | 17:00.36 |
| | I think I need mvrhel to get any further. | 17:00.44 |
| marcosw_ | henrys: sorry I'm late, but did you want to have a support meeting? I don't have anything particular to discuss. | 17:04.57 |
| henrys | marcosw_:no let me see if anything is assigned to support | 17:05.21 |
| marcosw_ | there are a couple of bugs, I think. | 17:05.43 |
| henrys | marcosw_:so can you dispatch those as time permits and we'll skip the meeting? Don't see anything important. | 17:06.39 |
| kens | Time to go, goodnight all | 17:07.00 |
| marcosw_ | will do. | 17:07.01 |
| | night | 17:07.04 |
| henrys | night kens | 17:07.08 |
| Robin_Watts | Aha, a mvrhel_laptop | 17:09.09 |
| mvrhel_laptop | hi Robin_Watts | 17:09.16 |
| Robin_Watts | mvrhel_laptop: You available to talk? | 17:09.22 |
| mvrhel_laptop | yes. | 17:09.28 |
| Robin_Watts | (Helen is convinced my job is "annoying michael") | 17:09.34 |
| | I've been looking into another problem that showed up on the component max stuff. | 17:10.02 |
| mvrhel_laptop | ha. no you always have great problems to work on | 17:10.07 |
| Robin_Watts | but it's not actually related to the component max. | 17:10.11 |
| | http://ghostscript.com/~regression/robin/compare2.html | 17:10.22 |
| | Number 70. | 17:10.27 |
| | I've cut the file down to the stage where it's just a single grey gradient (image). | 17:11.02 |
| | Let me upload that for you... | 17:11.09 |
| | 29-07A.PS in my casper home dir. | 17:11.27 |
| mvrhel_laptop | ok hold on | 17:12.00 |
| Robin_Watts | So it's a grey indexed image with values from 0...255 | 17:12.11 |
| | And it extends into 3 bands. | 17:12.20 |
| | The first time it gets called, the values are correctly mapped to 0,0,0,k values (i.e. greys) | 17:12.42 |
| | All the subsequent times it gets rendered, the color mapping comes back differently (FF,FF,FF,?) | 17:13.25 |
| | Because of the way the psdcmyk device works, this means we get correct results for the C plane in the first band, and all subsequent bands and components come out wrongly. | 17:14.56 |
| | I've traced it through, and by breakpointing the IMAGE_SET_GRAY(run); (gximono.c line 708) it looks to me like the profile_handle of the colorspace has been lost. | 17:16.07 |
| | Does that make sense? Do you want a command line so you can see for yourself ? | 17:16.48 |
| mvrhel_laptop | is that within same band? | 17:16.48 |
| | so you are saying that within each band it is mapped differently? | 17:17.18 |
| Robin_Watts | No, all the calls in the first band are fine. | 17:17.30 |
| | Then the colorspace is finalised and the handle goes away. | 17:17.48 |
| mvrhel_laptop | it should be in the clist | 17:17.55 |
| | and the next band should get it | 17:18.10 |
| Robin_Watts | Then we draw another band, and there is no handle when we arrive back on the first call on the second band. | 17:18.11 |
| mvrhel_laptop | ok. let me get the file and try to run it | 17:18.29 |
| Robin_Watts | I suspect a reference counting slip or something. | 17:18.32 |
| | gs/debugbin/gswin32c.exe -o ref.psd -r300 -sDEVICE=psdcmyk -dMaxBitmap=10000 29-07A.PS | 17:18.54 |
| mvrhel_laptop | do I need to bump up to 32 on the client color to see this? | 17:21.26 |
| Robin_Watts | I am running @32, but I believe it occurs without. | 17:22.19 |
| mvrhel_laptop | ok | 17:22.26 |
| | compiling and running.... | 17:23.02 |
| | ok. So I am getting just the thin red strip no blue and yellow like your output 70 has | 17:26.06 |
| Robin_Watts | Perfect. | 17:26.15 |
| | As I say, it's very cut down. | 17:26.24 |
| mvrhel_laptop | let me see if I can catch the missing profile in gximono | 17:26.28 |
| Robin_Watts | It SHOULD be a black page with a grey graduated band on it. | 17:26.44 |
| | we see a black page with a thinner red graduated band on it. | 17:26.55 |
| mvrhel_laptop | Robin_Watts: ok let me step through this | 17:30.54 |
| Robin_Watts | For what it's worth... the color space is created in clist_playback_band and then thrown away at the end. | 17:31.41 |
| mvrhel_laptop | oh where is this? | 17:34.06 |
| Robin_Watts | And it is a different colorspace instance the second time than the first - but it has the same cmm_icc_profile_data pointer. | 17:34.06 |
| mvrhel_laptop | Robin_Watts: ^^ | 17:34.49 |
| Robin_Watts | hold on, just getting back thre. | 17:34.56 |
| | IN clist_playback_band, in read_set_color_space, we call gs_cspace_build_ICC | 17:35.53 |
| | (It's event 181419 for me in memento) | 17:36.02 |
| mvrhel_laptop | ok | 17:36.06 |
| Robin_Watts | The next time the rc changes is... | 17:36.31 |
| | Balls. I cocked up, will need to rerun, sorry. | 17:38.53 |
| mvrhel_laptop | Robin_Watts: ok I see it | 17:40.36 |
| | first time it has the buffer | 17:40.45 |
| | next time it does not | 17:40.48 |
| Robin_Watts | line 2247 of clist_playback_band. | 17:40.49 |
| mvrhel_laptop | same hash code | 17:40.52 |
| Robin_Watts | yeah. | 17:40.56 |
| | I'm hoping that for someone that understands what's going on, it's not far from here to the fix :) | 17:41.21 |
| mvrhel_laptop | Robin_Watts: ok I have to take off for a bit. | 17:44.29 |
| | Now that I see this I can work on it today | 17:44.35 |
| | I am back at the tire dealer | 17:44.47 |
| Robin_Watts | mvrhel_laptop: Cool. I'm about to stop for the weekend then. | 17:44.49 |
| mvrhel_laptop | stupid car had an alignment issue | 17:44.53 |
| | worn control arms.... | 17:45.00 |
| | sigh | 17:45.02 |
| Robin_Watts | mvrhel_laptop: Ah, ok, could have been worse... | 17:45.04 |
| | (nails only appear in your tyres just after you've bought new ones) | 17:45.22 |
| mvrhel_laptop | Robin_Watts: have a good weekend and thanks for finding this | 17:45.35 |
| | that is probably 90 percent of the work | 17:45.40 |
| Robin_Watts | no worries. Thanks for taking it off my hands :) | 17:45.46 |
| | you too. | 17:46.01 |
| mvrhel_laptop | ttyl | 17:46.02 |
| | Robin_Watts: so as far as I can tell the icc stuff is working as expected there is something else strange going on. The icc profile handle is not needed on the subsequent calls since the icc mapping is using the link created from the first time that it was created | 19:54.56 |
| Robin_Watts | oh, ok. | 19:55.10 |
| mvrhel_laptop | I am trying to catch it when it puts this red color in place | 19:55.23 |
| Robin_Watts | bbs, sorry. | 19:55.30 |
| mvrhel_laptop | just with a conditional bp | 19:55.31 |
| | of the first and second colorant being different | 19:55.42 |
| | but I never have that occur | 19:55.47 |
| | in the rect fill | 19:55.57 |
| | it is weird. on that one line all the colorants are correct except the Cyan one | 19:56.54 |
| | which is stuck at 0% | 19:57.08 |
| | hmm | 20:02.06 |
| | I wonder if there is some funny business or confusion on the gray_to_k mapping | 20:02.26 |
| | aha | 20:03.40 |
| | ok | 20:05.03 |
| | that is what is going on | 20:05.14 |
| | Robin_Watts: so I have found the issue at least. Now I just need to understand why it is screwing up | 20:06.03 |
| | I have to run a few errands and will beat on this later. | 20:06.57 |
| Robin_Watts | mvrhel_laptop: Remember that the psdcmyk device is odd in that it's run several times. | 20:10.54 |
| mvrhel_laptop | yes | 20:11.01 |
| Robin_Watts | We render the whole page 4 times. | 20:11.03 |
| | So we never write "just red". | 20:11.14 |
| mvrhel_laptop | oh | 20:11.21 |
| Robin_Watts | We write CMYK right the first time, but only read C out. | 20:11.28 |
| | Then we get it wrong every other time. | 20:11.34 |
| | hence we see red in our .psd output | 20:11.42 |
| mvrhel_laptop | hmm | 20:12.17 |
| | oh I see one time we may write out FF FF FF FF and then next time 00 00 00 00 | 20:13.06 |
| | but read out the FF of C the first time | 20:13.15 |
| | and then 00 for M the next time | 20:13.23 |
| | hence my breakpoint is never hit | 20:13.31 |
| | ok | 20:13.43 |
| Robin_Watts | yeah. | 20:15.19 |
| mvrhel_laptop | so are lightness in the other channels does not match AR either | 20:16.06 |
| | that is, the gradient starts out whiter in AR | 20:16.20 |
| Robin_Watts | I've not even thought about that. | 20:16.35 |
| mvrhel_laptop | this is pointing to a transfer function issue also | 20:17.37 |
| | oh | 20:18.14 |
| | it could be due to AR being RGB | 20:18.22 |
| | and ignoring the transfer function | 20:18.30 |
| | that is likely | 20:18.33 |
| | oh | 20:20.11 |
| | I think I see | 20:20.28 |
| | yes. so if the model is CMYK with adobe we match the gradiant | 20:23.12 |
| | need to read the PS spec for a sec | 20:23.57 |
| | Robin_Watts: ok. So I have it fixed | 20:42.22 |
| | I will cluster push to see what explodes | 20:42.57 |
| | basically needed to add in one more piece of information into the minimal needed ICC information | 20:43.18 |
| | which is that this was a gray source space | 20:43.24 |
| | so then we know to do the gray to K mapping | 20:43.32 |
| | otherwise we end up doing it OK the first time and then subsequent times we screw it up since we think it is undefined | 20:43.55 |
| | that was a subtle one | 20:44.26 |
| | is there a bug associated with this? | 20:44.55 |
| | Robin_Watts: ok I did a clusterpush to see what changes | 20:50.49 |
| | now I will head off for a few errands | 20:50.56 |
| Robin_Watts | mvrhel_laptop: No, no bug. | 20:51.54 |
| ray_work | Robin_Watts: I thought you were stopping for the weekend (about 3 hours ago) ;-) | 20:53.34 |
| | laptop locked up when trying to go to standby, had to power down :-( | 20:54.15 |
| | but other than that, it hadn't been rebooted for a couple of weeks | 20:54.53 |
| | of course, peeves hasn't been rebooted for 512 days | 20:55.48 |
| | (but it keeps saying "reboot required") | 20:56.04 |
| Robin_Watts | ray_work: The Olympics opening ceremony is on. So I'm hiding. | 20:56.14 |
| ray_work | Robin_Watts: I see -- it's still dragging out ? They don't show it here for 5.5 hrs | 20:56.51 |
| Ch3rryC0ke | Hey there-- I'm trying to figure out why certain annotations in files don't display in mupdf. Where should I start? | 21:04.56 |
| Robin_Watts | Ch3rryC0ke: We only display annotations that have embedded appearance streams. | 21:07.34 |
| ray_work | Ch3rryC0ke: annotations are hit and miss in general. Does the annotation have a Normal appearance stream ? I'm not sure how many of the 'standard' appearance streams Tor has done ( | 21:07.38 |
| Robin_Watts | We don't do appearance stream synthesis (on the master branch). | 21:08.15 |
| Ch3rryC0ke | I'm not sure.. I'm still a PDF spec newbie. I'm trying to build a PDF annotator app, and I'm using mupdf as the renderer, and right now trying out different libraries to write the annotations out. I'm having mixed results. | 21:08.33 |
| | What is a good tool to actually see what streams are in the file for the annotations? | 21:08.54 |
| ray_work | a lot of annotation appearances expect to be built in, like Squiggly and Stamp | 21:09.00 |
| Robin_Watts | emacs ? | 21:09.05 |
| ray_work | pdfclean -d (to make it viewable) | 21:09.23 |
| | Ch3rryC0ke: you can watch annotation being drawn by stepping through the PDF (even if it is the original PDF) using gs -dPDFSTEP | 21:10.20 |
| Ch3rryC0ke | @ray_work: I see.. so far I've tried using iText with simple highlights and squigglies. And I've also tried PDFClown with all different types. | 21:11.01 |
| ray_work | Ch3rryC0ke: that's if you can't easily find the object by looking at the decompressed PDF | 21:11.07 |
| | Ch3rryC0ke: with the decompressed output you'd look for /Type /Annot | 21:13.30 |
| | Ch3rryC0ke: if it doesn't have an /AP entry then mupdf won't draw it | 21:14.21 |
| | Ch3rryC0ke: ghostscript (gs) implements most of the annotation types (without needing and AP stream) | 21:16.04 |
| Ch3rryC0ke | OK so for the simple highlight, the highlight shows up as | 21:19.33 |
| | <</Rect[60.68 749.17 94.02 735.3]/Subtype/Highlight/Contents()/QuadPoints[60.68 749.17 94.02 749.17 60.68 735.3 94.02 735.3]/C[1 1 0]/P 2 0 R>> | 21:19.36 |
| | And no /AP entry | 21:20.27 |
| ray_work | Ch3rryC0ke: yep. ghostscript will display it, but not mupdf (yet) | 21:21.10 |
| Ch3rryC0ke | OK- And with the other annotation types I tried, similar thing. Annotations without /AP streams, e.g.: | 21:21.35 |
| | <</Type /Annot /Subtype /Square /P 5 0 R /Border [0 0 0 ] /Rect [50 462 150 492 ] /IC [1 0 0 ] /Contents (þÿ | 21:21.36 |
| | <</Type /Annot /Subtype /Ink /P 5 0 R /Border [0 0 0 ] /Rect [50 512 150 542 ] /InkList [[50 542 70 532 100 522 ] ] /Contents (þÿ | 21:21.42 |
| ray_work | it isn't really that difficult to synthesize the appearance -- if you want to do it, we'll be grateful :-) | 21:21.51 |
| Robin_Watts | There is code in the forms branch that synthesises some. | 21:22.20 |
| Ch3rryC0ke | @ray_work -- can you give me some pointers on what to read / where to start to do that? If so, then I'm willing to try :) | 21:22.26 |
| Robin_Watts | SumatraPDF has some more. | 21:22.26 |
| Ch3rryC0ke | How similar is ghostscript to mupdf? I'm asking because I did a bit of work to get mupdf compiling in a Win 8 metro app, and so wondering if it will be possible to get gs running in Metro as well. | 21:23.54 |
| ray_work | Ink is one of the simpler ones -- the 'Stamp' is particularly messy because it has 14 predefined appearances | 21:24.20 |
| Robin_Watts | Ch3rryC0ke: gs is very different. | 21:24.36 |
| ray_work | putting it mildly | 21:24.45 |
| Robin_Watts | mupdf is small and compact. gs is huge and sprawling and hairy. | 21:24.53 |
| ray_work | but it is just a C app that builds with nmake under VS | 21:25.08 |
| | Ch3rryC0ke: what's special about a metro app ? | 21:25.24 |
| Robin_Watts | We'd be very interested in seeing the changes you made to make mupdf work under Metro. | 21:25.25 |
| Ch3rryC0ke | OK, if I had to put an order of preference to the annotations I want, I want to get: text markups (highlight/squiggly/striketrhgouh), ink with various colors and thickness, then basic geometries (square/circle/line), and then the rest. | 21:26.06 |
| Robin_Watts | Because we are planning to start looking at what's involved in making gs and mupdf metro apps very soon. | 21:26.09 |
| ray_work | gs has fairly limited actions with the OS -- temp files and file I/O are required, but ... | 21:26.15 |
| Ch3rryC0ke | OK cool.. I've actually already got a metro app version of mupdf, I haven't implemented everything (like text selection), for example, or multi-threaded viewing etc, but I have the basic view one page at a time type of app working | 21:26.53 |
| ray_work | gs has spawns threads if you select multu-threaded rendering, but that isn't required | 21:27.07 |
| | Ch3rryC0ke: and if gs is painting to a window (the 'display' device) then it uses a thread for the Window separate from the interpreter thread | 21:28.10 |
| Ch3rryC0ke | Ah I see.. there is probably a more optimal setup than what I tried. Right now I built a C# metro app, which calls into a C/C++ WinRT component that contains the mupdf code, and that passes back the bitmap info, which the C# app then renders. It would probably be better to write a C/C++ DirectX app where you can get an actual handle to the window/display device. | 21:30.02 |
| | ray_work: Can you give me a bit more info on where to start to synthesize the appearance for those annotation types? | 21:31.01 |
| ray_work | Ch3rryC0ke: I don't know offhand, but from what Robin_Watts said, I would suggest looking at the forms branch or sumatrapdf source | 21:32.36 |
| | I have to go run an errand. back later... | 21:34.58 |
| Ch3rryC0ke | OK | 21:36.03 |
| mvrhel_laptop | what is up with the segv in 09-52.PS.plank.72 | 23:04.05 |
| mvrhel | ok that has a few progressions | 23:16.25 |
| mvrhel_laptop | quit | 23:22.26 |
| | Forward 1 day (to 2012/07/28)>>> | |
IRC Logs