| | <<<Back 1 day (to 2014/03/04) | 2014/03/05 |
| Robin_Watts | paulgardiner: One possible idea might be to ask the customer to send us back exactly what Picsel sent them :) | 10:30.21 |
| tor8 | fantastic... now I remember why I try to avoid flying with US airlines. | 10:31.24 |
| paulgardiner | Robin_Watts: Yeah, I wondered that. I guess we aren't trying to give an illusion of greater knowledge than we really have. | 10:31.33 |
| tor8 | online checkin never f*cking works... | 10:31.33 |
| Robin_Watts | paulgardiner: Just say that in the transition between companies you want to ensure that no information has been lost. If he could share the previous set of deliverables with us, we can ensure that we get him a matching set and avoid several iterations. | 10:32.52 |
| paulgardiner | Yeah sounds good. Will do | 10:33.17 |
| Robin_Watts | tgvbuild.py has a -libonly flag. | 10:33.28 |
| | There appear to be -iphone-sdk={4.2,4.3,5.0,5.1,6.0,6.1,7.0} and -iphone-arch=armv{6,7,7s} | 10:35.00 |
| paulgardiner | I don't suppose the library displays the build command used to build it. That would be far too useful. | 10:35.02 |
| Robin_Watts | and -ios | 10:35.06 |
| | -define=ALIEN_IPHONE_LIBRARY | 10:35.29 |
| | and a -iphone-login flag too. | 10:35.45 |
| paulgardiner | Hmmm. What do you think htat means. | 10:36.09 |
| Robin_Watts | Ah. and a -no-thirdparty-print flag. | 10:36.15 |
| | No idea. I'm just having a quick look to see if I was hallucinating the lib build. | 10:36.44 |
| | -ios-ql-features. Whatever they are. | 10:37.10 |
| paulgardiner | Difficult to think how we can do much other than guess at the ones a particular customer needed unless it is documented somewhere. | 10:38.07 |
| Robin_Watts | tor8: Any luck ? | 10:59.47 |
| | I've just hit an interesting problem in pdf-interpret.c | 11:15.01 |
| | We can currently only cope with a single 'name' object on the stack. | 11:15.31 |
| tor8 | Robin_Watts: nope. aa.com won't let me check in at all, and ba.com (once you get past the seemingly broken website) only recognizes the return half of the flight... | 11:15.35 |
| Robin_Watts | tor8: Ass. | 11:15.50 |
| | Want me to try from here? | 11:15.55 |
| tor8 | Robin_Watts: I figured I'll try again in a few hours once the AA leg is within 24 hours, but I expect no more luck. | 11:16.48 |
| Robin_Watts | tor8: Ah, you're on the same flight as us? Of course. | 11:17.20 |
| tor8 | yeah, but I've got the troublesome connection to check in for | 11:17.48 |
| Robin_Watts | tor8: Log into skype, and let me try to check in here for you. | 11:18.08 |
| tor8 | "We are unable to process your request. You may request online check-in with the operating carrier or you may check in at the airport." | 11:18.35 |
| | Robin_Watts: sure. one minute while I dig out skype. | 11:18.52 |
| stars | Mupdf question... is there a way to detect <small> in stext-output.c? like the way do sub and sup? | 11:31.46 |
| tor8 | stars: only by looking at the font size | 11:32.48 |
| stars | tor8: Font size vary for the same font converted to smallcaps? | 11:34.23 |
| | tor8, Similarly I am looking for all caps also | 11:34.55 |
| tor8 | stars: hm. well, if the font is a true small caps you might be able to get it from the font name, but for faked small caps it's all done by changing the font size | 11:35.18 |
| Robin_Watts | tor8: So the problem I have is that I get "/OC /Blah BDC" in the stream. | 11:35.51 |
| | and we only keep 1 name in the csi. | 11:36.07 |
| tor8 | Robin_Watts: right. | 11:36.19 |
| Robin_Watts | so either I need to make it keep 2 names, or I need to spot us reading a second name, and keep the second one as an obj. | 11:36.36 |
| tor8 | you know, long long ago, we had a real stack of pdf_objs... but that was really way too malloc happy for me | 11:36.39 |
| Robin_Watts | Keeping 2 names would keep the existing behaviour with potentially broken streams. | 11:37.34 |
| tor8 | thought it might make sense to have a limited depth stack of struct { int type; union { pdf_obj *obj; float num; }} | 11:37.37 |
| | I'd say make it keep 2 names | 11:39.11 |
| | BDC is the only operator that takes two names right? | 11:39.32 |
| | that and I guess DP | 11:40.22 |
| | though on second thought, it might make sense to turn the second name into a pdf_obj for symmetry | 11:41.01 |
| | tag properties BDC normally expects a dictionary as the properties | 11:41.23 |
| | not that we actually handle any of the marked content operators | 11:41.36 |
| stars | tor8, the info you gave is leading me a way.... thanks! | 11:42.37 |
| Robin_Watts | tor8: The only problem with turning the second name into a pdf_obj is that it's a change to the way streams might be interpreted. | 11:44.52 |
| | At the moment, if we have: | 11:44.56 |
| | /Foo /Bar cs | 11:45.05 |
| | then the cs will just see /Bar as csi->name | 11:45.17 |
| | i.e. the /Foo is dropped silently. | 11:45.41 |
| tor8 | right. | 11:45.52 |
| Robin_Watts | If we make the /Bar become an obj, then the cs will start to see /Foo. | 11:46.11 |
| | I am tempted by the second name thing. less mallocing too. | 11:46.26 |
| tor8 | Robin_Watts: yeah. nametop and name[0], name[1]? | 11:46.41 |
| Robin_Watts | means the operators have to be a bit smarter. | 11:46.48 |
| | either that or just name, name2 :) | 11:47.01 |
| tor8 | Robin_Watts: well, you got to keep track of when you have /Foo /Bar BDC and /Foo /Bar <<stuff>> BDC | 11:47.24 |
| | or just /Foo <<stuff>> BDC | 11:47.35 |
| | though I guess you could use the absence of a csi->obj as a queue to look for name2 | 11:48.13 |
| Robin_Watts | We'll never have /Foo /Bar <<stuff>> BDC | 11:48.17 |
| | exactly. | 11:48.20 |
| tor8 | s/queue/cue/ | 11:48.24 |
| | Robin_Watts: broken files... we'll never havv /Foo /Bar cs either ;) | 11:48.46 |
| Robin_Watts | I'm going to go for that, it's simpler. | 11:48.47 |
| | tor8: in theory, no :) | 11:49.01 |
| tor8 | but broken files are broken, no need to worry about them too much | 11:49.02 |
| Robin_Watts | actually, sod it, I'm going to do the object thing, because it gives neater code. | 11:49.36 |
| tor8 | there will be fewer special cases in the BDC handling code if you make it an object | 11:49.58 |
| paulgardiner | There's a vaultize-features flag | 11:50.07 |
| tor8 | paulgardiner: eh? | 11:51.26 |
| Robin_Watts | tor8: obscure picsel build flags #204 | 11:52.03 |
| tor8 | ick. you've scared me with all that talk about the FBS | 11:52.35 |
| kens | Why is it that domestic crises crop up whenever I'm due to fly to the US ? | 13:49.10 |
| chrisl | Oh, you too? Hmmmm :-( | 13:50.23 |
| sebras | tor8: next time maybe you can travel to .us using this? http://goo.gl/cVDdGo | 14:03.14 |
| kens | THere's a short video of it taking off too | 14:03.34 |
| | Kind of slow htough for a trip to the US and no passenger cabin at the moment | 14:03.49 |
| sebras | kens: yes, but it would have been cool. :) | 14:04.34 |
| kens | It would be very cool indeed. | 14:04.45 |
| | Back to the age of the airships I say, as long as it copmes equipped with WiFi | 14:05.03 |
| | Actually, if it had WiFi we could have a meeting on borad | 14:05.15 |
| sebras | kens: mm, but there is a chance that the meetings will be longer as the airship can stay in the air for up to three weeks!. | 14:07.00 |
| chrisl | But it can "land" almost anywhere! | 14:07.29 |
| Robin_Watts | has checked in online. | 14:09.55 |
| chrisl | also has..... | 14:10.22 |
| kens | too | 14:10.31 |
| | tor8 :-P | 14:10.37 |
| chrisl | I'm not sure I need the 2/3 page of adverts with the boarding pass! | 14:11.39 |
| kens | Hmm I didn't get that (I don;t htink) | 14:11.58 |
| Robin_Watts | There was an option to print without the crap. | 14:12.03 |
| chrisl | So there was, never notice that.... | 14:12.53 |
| kens | Nor did I but it still came without garbage | 14:13.15 |
| Robin_Watts | I got bitten in hawaii, and consequently ended up paying for printing the last page or something. | 14:13.43 |
| tor8 | meh, still no luck checking in :( | 14:14.41 |
| kens | Very odd... | 14:14.55 |
| tor8 | kens: do you still want to borrow my kobo aura hd? | 14:15.13 |
| kens | I'd certainly like to look at it if you're bringing it along | 14:15.33 |
| tor8 | kens: it's the unholy combination of a european and an american airline that they *still* haven't managed to solve online checkin for :( | 14:15.37 |
| | kens: then I'll bring it and you can borrow it for the trip | 14:15.56 |
| kens | Thanks tor8 | 14:16.02 |
| tor8 | I'll make sure to load it up with some books too | 14:16.07 |
| kens | Even better ;-) | 14:16.15 |
| tor8 | there's bound to be something you'll enjoy :) | 14:16.16 |
| kens | I'm easily pleased (I used to read breakfast cereal packets at the table) | 14:16.38 |
| tor8 | I'm sure there's something more interesting than that in my ebook library :) | 14:17.25 |
| kens | has no doubt | 14:17.38 |
| | My parents had a policy of no books at the table | 14:17.58 |
| | HmmGlobal Graphics share price just jumped 15% or so. | 14:18.50 |
| chrisl | Ah, my parents had a policy of no table.... | 14:18.56 |
| Robin_Watts | tor8: Various small commits on robin/master | 14:19.33 |
| kens | oH GG has 'major contract with office printer manufacturer' | 14:19.37 |
| chrisl | Doesn't say who | 14:20.02 |
| kens | No it doesn't, interesting | 14:20.08 |
| Robin_Watts | I've got to add %o support to the vsnprintf one after lunch. | 14:20.27 |
| kens | Half the money in the first year | 14:20.35 |
| chrisl | Seems optimistic | 14:21.23 |
| tor8 | Robin_Watts: bottom three LGTM | 14:21.28 |
| Robin_Watts | Thanks. | 14:22.13 |
| | I fear the third one may still be giving me grief though - either that or my bmpcmp is lying. | 14:22.37 |
| | will look after lunch. | 14:22.40 |
| henrys | paulgardiner: surely they'd have to have a library build, what else would they send to an OEM? sdkbuild.py I imagine, no? | 14:32.02 |
| paulgardiner | henrys: sure it was clear they had a library build of something, but they've been supporting OEMs with products long before SmartOffice. They've had OEMs for various file viewers and browsers. My worry was based on there AFAIK not being a SO library when I last worked for them and lots of knowledge of how they did business. | 15:04.41 |
| | It is okay though. We have the database of releases. I can see what was sent last time and even the build command. | 15:05.11 |
| | Well I say okay. I guess I still don't know exactly what state of development the library is. | 15:06.51 |
| Robin_Watts | The "database of releases" is a spreadsheet file that alex pointed us at this morning :) | 15:07.43 |
| henrys | Robin_Watts, paulgardiner : we've been told bipartate management will take action against employees talking to us if it doesn't go through lesley, Geoff said the employees were warned so we can take it to be *their* responsibility but, nonetheless, I'd feel bad if we got someone in trouble. | 15:54.58 |
| Robin_Watts | henrys: OK. | 15:55.30 |
| paulgardiner | Yeah okay. We hadn't realised it was an altogether ban on the subject. | 15:56.42 |
| henrys | paulgardiner: is the spreadsheet in the git tree | 16:02.14 |
| | ? | 16:02.15 |
| paulgardiner | It is in one of the cvs repos. It wasn't pased to us. We were just told where it was | 16:02.51 |
| | One of the cvs repos we now own | 16:03.06 |
| Robin_Watts | ~robin/sauce/picsel/docs/releases/Release_Tracking_Sheet.xls | 16:03.39 |
| henrys | that is really nice to have, I fear there are other nuggets like this that we should be aware of but wouldn't know to look without help | 16:06.14 |
| paulgardiner | Yes. We have others we can talk to, but not with knowledge as up to date. | 16:08.35 |
| henrys | paulgardiner: we do have the benefit of timestamps in the cvs tree, anything say 2013 should probably be looked at. | 16:13.48 |
| paulgardiner | Yes. Useful suggestion. | 16:15.49 |
| | Gah! "Sorry, \epoc32\gcc\bin\g++.exe is not supported" Should I be surprised at that from an Android build? | 16:17.50 |
| Robin_Watts | paulgardiner: I bet that's being used for a c pre proc | 16:18.24 |
| chrisl | That's the old Psion SDK isn't it? | 16:19.00 |
| paulgardiner | Possibly. It may have been coincident with first attempted compilation of a cpp file | 16:19.34 |
| Robin_Watts | paulgardiner: What branch are you on? | 16:19.45 |
| chrisl | I wonder what happened to the EPOC OS..... | 16:20.22 |
| paulgardiner | smart-products-v2_1-release-branch | 16:20.42 |
| | with some of my own changes. | 16:20.50 |
| Robin_Watts | paulgardiner: Really? | 16:21.38 |
| | My git repo doesn't have that in. | 16:21.43 |
| | found it. | 16:22.37 |
| paulgardiner | ah good.... would have been very odd otherwise. | 16:23.01 |
| | chrisl: I think you're right. Symbian and all that. | 16:23.54 |
| Robin_Watts | OK, on that branch scripts/tgvbuild.py mentions it. | 16:24.25 |
| | On master it doesn't. | 16:24.30 |
| chrisl | paulgardiner: Ah, Symbian, yes, that's what EPOC became, I remember now. The 5D offices were across the road from their office.... | 16:24.49 |
| Robin_Watts | chrisl: Simon Street? | 16:25.20 |
| | Near Marylebone ? | 16:25.35 |
| chrisl | Erm, no near Waterloo | 16:25.44 |
| | It was still Psion back then | 16:26.03 |
| Robin_Watts | yeah, we visited them when they were Psion. | 16:26.21 |
| chrisl | Possibly Ufford Street? | 16:27.09 |
| paulgardiner | Robin_Watts: and drove most of the way back without the computers we'd taken to give demos, IIRC :-) | 16:27.12 |
| Robin_Watts | paulgardiner: They were your computers. I claim it was your fault. | 16:27.31 |
| | chrisl: Could be. I forget street names. | 16:28.00 |
| | along with most other things these days. | 16:28.08 |
| paulgardiner | I can accept that. </soa quote> | 16:28.16 |
| chrisl | Robin_Watts: As do I - I only worked there for a few months | 16:28.27 |
| Robin_Watts | Oh, bugger. | 16:29.31 |
| | I have pdf filtering working really nicely. | 16:29.54 |
| | It will even build me a new resource dictionary for the page with everything that the page stream uses in it. | 16:30.18 |
| | but this one particular page has a Type 3 font in it that uses another font. | 16:30.34 |
| | And that other font isn't used anywhere else on the page. | 16:30.57 |
| | so my code is dropping that font from the resource dictionary. | 16:31.11 |
| | I need to walk all the fonts, check to see if they are Type 3's, then walk all the char procs to see what resources they use. | 16:31.59 |
| chrisl | I thought the subsidiary font still needed to be "declared" in the resource dicts | 16:32.57 |
| Robin_Watts | chrisl: It is declared in the resource dict of the page. | 16:33.36 |
| | But I filter the page contents, and detect that it's not used, so I drop it. | 16:33.52 |
| | basically I can't drop any resource that might be used in a Type 3 font used by the page. | 16:34.16 |
| chrisl | Hmm, then yeh, you'll have to check the char procs | 16:34.50 |
| Robin_Watts | Or I can just refuse to drop stuff if there is a Type 3 used. | 16:35.05 |
| chrisl | That would be easier..... | 16:35.21 |
| | Robin_Watts: Boundary Row was the street where Psion were (and 5D moved to)..... | 16:38.36 |
| paulgardiner | Maybe I need to take the Qt SDK off my path | 16:44.30 |
| henrys | paulgardiner: Approved_products gives the last release number for this customer FWIW | 17:02.27 |
| | Approved_Products_Index.xls | 17:02.57 |
| paulgardiner | Yeah that cooresponds to the version in the other file. | 17:04.41 |
| | Looking consistent at least. | 17:06.50 |
| ray_laptop | mvrhel_laptop: are you available ? | 17:08.00 |
| mvrhel_laptop | ray_laptop: I am | 17:08.15 |
| ray_laptop | I fixed one of cust 532's problems with 'page_is_monochrome', but now I am seeing that with transparency, it is using the lcms | 17:09.14 |
| mvrhel_laptop | ray_laptop: you mean with Fastcolor it is using lcms? | 17:09.41 |
| ray_laptop | and the usefastcolor is not set for the pdf14clistRGB device | 17:09.52 |
| mvrhel_laptop | ah | 17:09.56 |
| | during the device set up it probably is not getting copied from the target | 17:10.17 |
| | that is during the pdf14 device set up | 17:10.50 |
| ray_laptop | I haven't looked at the current code (this is 9.06 based). As a result a 'gray' is getting remapped to something close (but not exactly) neutral 0.973 -> 0xfafaf9 | 17:11.31 |
| mvrhel_laptop | ray_laptop: sure. if it is going through ICC that can happen | 17:12.04 |
| ray_laptop | mvrhel_laptop: so, the question is, should the pdf14 device be compatible with UseFastColor ?? | 17:12.30 |
| mvrhel_laptop | yes. this is a bug that needs to be fixed | 17:12.42 |
| henrys | Robin_Watts, paulgardiner : those documents seem to suggest we have fewer potential oem's than I'd thought. | 17:13.02 |
| ray_laptop | if it's still in the current code, it means that 'Fast' is not fast with transparency pages | 17:13.24 |
| mvrhel_laptop | ray_laptop: I can fix it in the head and then you can port it to their version if you want | 17:13.25 |
| | ray_laptop: I suspect it is in the head also since I have not fixed this problem ever | 17:14.05 |
| ray_laptop | mvrhel_laptop: OK. But are you busy ? This is urgent for them, and it's my top priority, so if you are busy I will muddle through | 17:14.17 |
| mvrhel_laptop | and I doubt anyone else has stumbled upon it | 17:14.21 |
| ray_laptop | mvrhel_laptop: right. Most people don't care if their RGB device has inexact neutrals | 17:14.56 |
| mvrhel_laptop | ray_laptop: I have a call at 10am. I can stop working on gsview and fix this today I would think. | 17:14.57 |
| | it should be straight forward | 17:15.38 |
| ray_laptop | mvrhel_laptop: let me give it a quick shot, then check with me after your call before you start. | 17:15.48 |
| mvrhel_laptop | ok | 17:15.55 |
| ray_laptop | If I fix it, I'll mention it here | 17:16.01 |
| mvrhel_laptop | sounds good | 17:16.06 |
| ray_laptop | mvrhel_laptop: thanks | 17:16.12 |
| mvrhel_laptop | np | 17:16.25 |
| tor8 | Robin_Watts: hm, I thought type3 fonts had their own resource dictionaries (and only use the page resource dictionary as a fallback for broken files) | 17:18.49 |
| Robin_Watts | tor8: perhaps this is a broken file. | 17:19.07 |
| | I think everything *should* have it's own resource dictionary now, but possibly it was permitted for it not to have in the first version. | 17:19.41 |
| | tor8: Some updated commits on robin/master for you. | 17:20.14 |
| | Slightly tweaked version of the last one of the 3 you looked at before. | 17:20.42 |
| kens2 | Type 3 font Resource dicts are optional but 'stroingly recommended' | 17:20.50 |
| Robin_Watts | Then the vsnprintf one is ready to go now (subject to my current test passing) | 17:21.10 |
| kens2 | OKI'm packing up, see you all tomorrow/Friday/Saturday | 17:27.21 |
| henrys | paulgardiner: have you guys sent these documents to miles, he should have the names in here? | 17:28.00 |
| Robin_Watts | henrys: I haven't. I doubt paulgardiner has. | 17:32.49 |
| henrys | I'll send it along and copy you guys. | 17:33.07 |
| ray_laptop | mvrhel_laptop: all fixed. I just added (in gs_pdf14_device_copy_params, after line 1873): | 17:45.43 |
| | dev->icc_struct->usefastcolor = profile_targ->usefastcolor; | 17:45.45 |
| mvrhel_laptop | ray_laptop: exactly | 17:45.54 |
| ray_laptop | putting it in HEAD next | 17:45.56 |
| mvrhel_laptop | great thanks | 17:46.01 |
| ray_laptop | mvrhel_laptop: can you look at the commit and bless it ? | 17:49.14 |
| | (on my git repo) | 17:49.21 |
| mvrhel_laptop | sure hold on | 17:49.27 |
| | ray_laptop: looks right | 17:52.23 |
| tor8 | Robin_Watts: I shall have to look them over tomorrow. see you then! | 17:57.32 |
| Robin_Watts | tor8: no worries. see you later! | 17:57.44 |
| ray_laptop | mvrhel_laptop: hmm... I'm still getting a call into gscms_transform_color from image_init_colors. It's during clist playback. The 'dev' does have icc_struct->usefastcolor set, however (the pdf14RGB device) | 17:59.20 |
| mvrhel_laptop | ray_laptop : on phone lets chat in a bit | 18:00.05 |
| ray_laptop | mvrhel_laptop: OK. I'll dig in the meantime... | 18:00.17 |
| mvrhel_laptop | ray_laptop: off of phone | 19:07.57 |
| Robin_Watts | Rats. My filtering doesn't cope with inline images. There is a FIXME in there that I'd forgotten about. | 19:13.32 |
| | Something to do on the phone, I guess. | 19:13.43 |
| | s/phone/plane/ | 19:15.33 |
| mvrhel_laptop | Robin_Watts: so does the svg output in mupdf work? | 19:16.33 |
| Robin_Watts | It does. | 19:16.40 |
| mvrhel_laptop | great | 19:16.43 |
| | I am adding a few save as features on gsview | 19:16.55 |
| Robin_Watts | Cool. | 19:17.07 |
| mvrhel_laptop | I have gs doing conversions to its various devices | 19:17.07 |
| | but I wanted to add a save as with mupdf | 19:17.24 |
| | looking at the code it looks like I can do png, pcl, pnm, pwg and svg | 19:17.51 |
| Robin_Watts | ppm, pgm, pbm | 19:18.05 |
| | oh, pnm, right, sorry. | 19:18.16 |
| | yeah. | 19:18.22 |
| ray_laptop | mvrhel_laptop: can we discuss what I am seeing ? | 19:18.30 |
| mvrhel_laptop | Robin_Watts: what about pdf? when we have an input ps file, it gets distilled to a pdf file that mupdf then renders | 19:18.56 |
| | but it is a temp file | 19:19.07 |
| | in the system | 19:19.09 |
| Robin_Watts | mvrhel_laptop: So 'save as' should just copy the temp file. | 19:19.13 |
| mvrhel_laptop | I would like to do a save of that | 19:19.15 |
| | ah yes | 19:19.19 |
| | good point | 19:19.21 |
| | duh | 19:19.23 |
| Robin_Watts | Phew, dodged that one | 19:19.31 |
| mvrhel_laptop | Robin_Watts: thank you for using your higher powers of reasoning | 19:19.45 |
| ray_laptop | rather than 'copy' can't we rename (mv) ? | 19:19.55 |
| Robin_Watts | ray_laptop: Not if you want to keep it open and save as again. | 19:20.11 |
| mvrhel_laptop | if the file is open, a mv will not work | 19:20.15 |
| | ray_laptop: ok what are you seeing | 19:21.06 |
| ray_laptop | mvrhel_laptop: I am seeing that images end up having their colorspace as ICC. The 'gsicc_get_link' is the place that is supposed to plug in the 'nocm' depending on usefastolor | 19:23.33 |
| | mvrhel_laptop: but the 'index' is 0xc (ICC) so it never does this even though the original colorspace was RGB or Gray | 19:24.09 |
| | the check it is failing is index < gs_color_space_index_DevicePixel | 19:24.46 |
| mvrhel_laptop | ray_laptop: we don't really carry around DeviceRGB or DeviceGray colors spaces in the code. They are all ICC. What should happen is that the get link should be returning a link from the dumb color space | 19:25.43 |
| | dumb cmm sorry | 19:25.55 |
| ray_laptop | now with RGB images, it's more or less OK, performance-wise, because it gets detected as 'identity' based on the num_comps, but for gray it goes through the lcms transformation | 19:25.57 |
| mvrhel_laptop | ok that is not correct. | 19:26.19 |
| ray_laptop | mvrhel_laptop: in get_link the call to gsicc_get_default_type returns ICC | 19:26.47 |
| mvrhel_laptop | ray_laptop: I will need to step through with a file | 19:27.05 |
| | let me make an file with a gray image | 19:27.24 |
| | and start up gs | 19:27.44 |
| ray_laptop | mvrhel_laptop: _sometimes_ I am seeing it return the correct index | 19:28.07 |
| mvrhel_laptop | huh? | 19:28.18 |
| | in that case, can you share your file with me | 19:28.32 |
| | ray_laptop: ^^ | 19:28.36 |
| | do I have to worry about cosmic rays? | 19:28.53 |
| ray_laptop | the profile_data->default_match has DEFAULT_NONE | 19:29.07 |
| Robin_Watts | We only have one ray :) | 19:29.24 |
| | but he is cosmic. | 19:29.32 |
| ray_laptop | mvrhel_laptop: oops. someone at the door... | 19:29.36 |
| mvrhel_laptop | yes | 19:29.36 |
| | ray_laptop: it is going to best if you can share the file with me | 19:30.11 |
| | as I am having trouble understanding | 19:30.23 |
| | Robin_Watts: so there is no pdf output device with mupdf if I have opened an xps file is there? | 19:31.38 |
| | i.e. a pdfwrite device | 19:31.47 |
| Robin_Watts | mvrhel_laptop: Well, we have a pdfwrite device. | 19:31.52 |
| | It doesn't work very well. | 19:31.58 |
| | It tigers. | 19:32.03 |
| ray_laptop | mvrhel_laptop: I will send the file. Clearly I need to understand why this particular image has profile_data->default_match==DEFAULT_NONE | 19:32.06 |
| Robin_Watts | but it doesn't text. | 19:32.07 |
| mvrhel_laptop | well it needs to get up to speed with the modern generation. they are all about texting | 19:32.28 |
| Robin_Watts | Well, it might text, but it doesn't font. | 19:32.43 |
| mvrhel_laptop | Robin_Watts: ok thanks | 19:33.00 |
| | ray_laptop: ok when I get the file, I will have a look | 19:33.17 |
| henrys | mvrhel_laptop: this discussion reminds me... those strtok calls are not thread safe, I am not sure if that is of practical concern. | 19:34.18 |
| mvrhel_laptop | henrys: is this in the xpswrite device? | 19:34.51 |
| | I am only allowing 1 instance of gs at this point | 19:35.05 |
| Robin_Watts | gsicc_cache.c line 1159 ? | 19:35.10 |
| | and gsicc_manage.c | 19:35.39 |
| henrys | yes your icc code | 19:35.56 |
| Robin_Watts | We should fix it. It's donkeywork though, doesn't need to take mvrhel's time. | 19:36.26 |
| henrys | you mean I have to do it ? ;-) | 19:37.13 |
| mvrhel_laptop | oh you mean my code. oops | 19:37.35 |
| Robin_Watts | I was vaguely going to volunteer, but I can't promise when. | 19:37.45 |
| henrys | I'm not real worried about it but ray_laptop and cosmic rays made me think of it. | 19:38.47 |
| mvrhel_laptop | well, since it is my mess, I will feel bad having someone else have to deal with it. I will add this on the todo list | 19:38.59 |
| ray_laptop | mvrhel_laptop: that's OK, I cleaned up one of henrys' messes a bit ago, so he "owes one" ;-) | 19:40.42 |
| henrys | mvrhel_laptop: there is a strtok_r on most platforms but I think it best to avoid any strtok stuff. | 19:41.08 |
| mvrhel_laptop | henrys: I was just going to ask that | 19:41.23 |
| henrys | mvrhel_laptop: is this code that can be running at the same time in separate threads? | 19:42.22 |
| ray_laptop | mvrhel_laptop: I sent the file. In clist_begin_typed_image (gxclimag.c: 687) the pim->ColorSpace is ICC | 19:44.03 |
| mvrhel_laptop | henrys: it is in some very specialized color stuff relating to setting up colorant names. I can probably count on one hand the number who are likely using this but it should be fixed | 19:45.36 |
| Robin_Watts | It's in dscparse.c as well within psi. | 19:46.11 |
| henrys | Robin_Watts: yes and pcl as well | 19:46.42 |
| | pjl parser | 19:46.47 |
| Robin_Watts | Do we need a gs_strtok ? A portable version of strtok_r ? | 19:47.14 |
| mvrhel_laptop | that would be nice | 19:47.19 |
| ray_laptop | mvrhel_laptop: the image starts out as DeviceGray (Image9) | 19:47.34 |
| mvrhel_laptop | ray_laptop: hold on it will take me a sec | 19:47.49 |
| | still waiting on file.... | 19:48.01 |
| | did you mail it from peeves.... | 19:48.14 |
| ray_laptop | mvrhel_laptop: I emailed it from here, but I just put it up on casper:/home/ray/Mono_01_lottery_1.5.pdf | 19:51.08 |
| | it's only 51Kb | 19:51.25 |
| mvrhel_laptop | ok let me grab it from there | 19:51.25 |
| henrys | Robin_Watts: I guess, I don't like the strtok interface at all though. A good interface would not step on the string being tokenized. You'd have an initialize function, a next token and an enumeration to hold the state (position in the string). But maybe I'm being too particular | 19:52.10 |
| mvrhel_laptop | You have a good point. I remember when I first saw what strtok did many many years ago and thought it really odd. Having a common set up though that is shared in the code where this is needed would be nice thought | 19:53.48 |
| | s/thought/though | 19:54.03 |
| | ray_laptop: so I have the file. | 19:56.57 |
| | I was just looking it over | 19:57.03 |
| | so the only images that I see are the tiny bullet point images? | 19:57.14 |
| | they are like 2x2? | 19:57.28 |
| | I hope these are not the performance problem. in any event starting it up now | 19:58.46 |
| | ray_laptop; ok running file with -dUseFastColor. | 20:02.47 |
| | I have breakpoints in the lcms code to catch it doing any real color management | 20:03.12 |
| | and I caught it doing a fill... | 20:03.55 |
| | oh I need your fix | 20:04.25 |
| | with the pdf14RGB device | 20:04.30 |
| | let me pull that in | 20:04.32 |
| | oh ray_laptop have you not committed that to the head yet? | 20:05.59 |
| | will fix here | 20:06.16 |
| | ok rerunning now with that fix | 20:08.16 |
| | ray_laptop: so I am confuse | 20:09.04 |
| | d | 20:09.06 |
| | it runs with out ever using lcms | 20:09.16 |
| | which is correct | 20:09.23 |
| | are you seeing it use lcms? | 20:09.27 |
| | or is there some other issue? | 20:09.39 |
| | oh let me try in clist mode | 20:11.18 |
| | ok now I caught it | 20:13.04 |
| ray_laptop | sorry. 3!!! phone calls | 20:13.10 |
| mvrhel_laptop | ray_laptop: np | 20:13.20 |
| | let me look this over for a sec | 20:13.26 |
| ray_laptop | mvrhel_laptop: the issue is the colorspace is getting switched over to ICC by the gx_install_DeviceGray function | 20:14.28 |
| mvrhel_laptop | that is not the issue | 20:14.41 |
| | the issue is that the cmm procs are wrong | 20:14.51 |
| ray_laptop | well, that is incompatible with the check in gsicc_get_link that forces in the nocm link | 20:15.32 |
| | the index < gs_color_space_index_DevicePixel check fails because of that | 20:16.23 |
| Robin_Watts | henrys: When you looked at "Release_Tracking_Sheet.xls", did you fall into the same trap I did and not scroll upwards? :) | 20:16.42 |
| mvrhel_laptop | ray_laptop: you are going to have to give me a few minutes | 20:16.56 |
| ray_laptop | mvrhel_laptop: np. | 20:17.03 |
| mvrhel_laptop | ok. I see what you mean. so the UseFastColor is only used for Default color spaces. ICC color spaces are still handled with lcms | 20:18.36 |
| | let me dig a bit more though | 20:18.51 |
| henrys | Robin_Watts: OMG | 20:19.21 |
| Robin_Watts | I think Miles' count of 64 = current ones. | 20:20.10 |
| | There have clearly been many more than that in the past. | 20:20.30 |
| mvrhel_laptop | ray_laptop: I see the default_match value is wrong | 20:21.09 |
| ray_laptop | mvrhel_laptop: default_match ?? | 20:22.52 |
| mvrhel_laptop | hold on | 20:23.13 |
| ray_laptop | mvrhel_laptop: Oh, in the gs_input_profile, right | 20:24.13 |
| mvrhel_laptop | it is how I detect if the profile was a "real" profile from the source document vs. one that was substituted for DefaultGray, DefaultRGB, DefaultCMYK or a CIEBased color space. We use this for the fastcolor and for pdfwrite | 20:24.19 |
| | yes | 20:24.22 |
| | so this should be DEFAULT_GRAY | 20:24.48 |
| | which would return gs_color_space_index_DeviceGray | 20:24.56 |
| | which is less than gs_color_space_index_DevicePixel | 20:25.16 |
| | but someone, likely the clist image code is messing around with it | 20:25.42 |
| | that is just a guess | 20:25.49 |
| | need to see why it is getting set to ICC | 20:26.06 |
| ray_laptop | mvrhel_laptop: I'll try to catch that. | 20:26.53 |
| mvrhel_laptop | hmm it is DEFAULT_GRAY | 20:27.17 |
| | and fast color is true | 20:27.39 |
| | weird | 20:28.23 |
| | oh pdf14_begin_type_image | 20:29.26 |
| | is using a profile with a default match that is the output device profile | 20:29.44 |
| | so it is creating an image | 20:29.52 |
| | and it really is an ICC image | 20:30.00 |
| | as it is in the device color space | 20:30.06 |
| | but the conversion should be the identity | 20:30.30 |
| | but it is not :( | 20:31.56 |
| | oh nevermind | 20:32.56 |
| | I was going out to rgb | 20:33.00 |
| | ok | 20:33.02 |
| | ok so the default_match in this profile is def wrong | 20:35.08 |
| | it is set to DEFAULT_NONE | 20:35.28 |
| | need to figure that one out | 20:35.40 |
| | has to be occurring in gsicc_init_profile_info | 20:36.07 |
| | or not..... | 20:36.32 |
| | basically we need to find where this profile is coming from, as it is not quite getting set up properlyl | 20:38.34 |
| ray_laptop | mvrhel_laptop: right, that's what I'm trying to catch. | 20:46.31 |
| mvrhel_laptop | ok. I think I will need to catch this in the icc writing code out to the clist | 20:47.36 |
| | ok so that is all clear | 20:48.42 |
| | so every profile written to the clist is fine | 20:50.00 |
| | so it has to be in the reading and likely something missing in the pdf14 code... | 20:50.17 |
| | ray_laptop ^^ | 20:50.27 |
| ray_laptop | mvrhel_laptop: in gxclrast.c read_set_colorspace the clist_icc_color_t doesn't contain a 'default_match' so it never gets changed from DEFAULT_NONE | 20:52.00 |
| | so we probably have to write that so we can read it back | 20:52.20 |
| mvrhel_laptop | ok, well yes, that would be an issue | 20:52.28 |
| ray_laptop | because otherwise, there is no way for the clist reader to know the profile is one of the defaults | 20:52.53 |
| | I'll look at fixing that. I have to run a quick errand. bbiab. | 20:53.35 |
| mvrhel_laptop | right. | 20:54.31 |
| | I would be surpised it is not getting written out | 20:54.40 |
| | actually I am surprised it is not getting read too | 20:54.50 |
| | sighe | 20:54.52 |
| | sigh | 20:54.54 |
| | off to lunch | 20:55.48 |
| ray_laptop | mvrhel: (for the logs) I see what's going on. the default_match is being checked in gsicc_get_link BEFORE the profile is read from the clist with gsicc_get_profile_handle_clist (from gsicc_get_link_profile) | 21:36.56 |
| | mvrhel: after that the default_match is valid. So using the default_match wihen the "profile_handle" is NULL is not valid | 21:42.56 |
| | mvrhel: I _could_ try and re-work the logic so that we detect that case, and re-factor the loading to do that in get_link instead of get_link_profile, or I could move the default_match up into the clist_icctable_t struct | 21:46.23 |
| | mvrhel: actually, I meant the clist_icc_color_t struct | 21:51.22 |
| | mvrhel: I tend toward the re-factoring, moving everything in the case if (cms_input_profile == NULL) into a new function: gsicc_get_profile_handle | 21:56.50 |
| | then we can make sure and call that before looking at default_match | 21:57.15 |
| | (if the profile_handle == NULL) | 21:57.28 |
| | mvrhel_laptop: do you have any input? The simpler change is to add it to the "header" that gets written to the icctable | 23:36.56 |
| mvrhel_laptop | ray_laptop: let me check | 23:38.37 |
| | ray_laptop can you show me what you have done? | 23:41.08 |
| | ray_laptop: have to head out now. we will have to chat about this either tonight / tomorrow morning or at the staff meeting | 23:42.21 |
| | Forward 1 day (to 2014/03/06)>>> | |
IRC Logs