| | <<<Back 1 day (to 2011/08/23) | 2011/08/24 |
| henrys | my suggestion would create a tiling bitmap - just create it later when the pattern is painted, instead of passing the tile through the pipeline as it is now. | 00:10.24 |
| mvrhel2 | oh. | 00:27.51 |
| | that would not be slower | 00:27.54 |
| | but right now the reason we usually run the clist is if the pattern will not fit in a bitmap | 00:28.13 |
| | so we end up running the clist for each tile drawing | 00:28.24 |
| | that is weird | 00:29.46 |
| | I have some diffs in pdfwrite | 00:37.41 |
| robin_watts_mac | mvrhel2: Knockout groups? or non isolate groups? | 00:41.50 |
| mvrhel2 | robin_watts_mac: are you on the plane? no this was just forcing clist for planar devices when doing patterns | 00:42.25 |
| robin_watts_mac | When looking at mupdf I spotted that it does tiling by creating a pattern bitmap, then playing it back repeatedly. | 00:42.35 |
| | That fails for non-isolated groups. | 00:42.52 |
| | might that be a reason why we can't do what henrys was suggesting in gs ? | 00:43.18 |
| mvrhel2 | hmm. not sure about that. I would think if the pattern were transparent we could do what ever we needed | 00:43.50 |
| | that is, if it had a transparency layer | 00:44.00 |
| | oh I see | 00:44.11 |
| | what you mean | 00:44.14 |
| | we need to initialization | 00:44.23 |
| | s/to/the/ | 00:44.29 |
| | that sounds like an interesting test case to create | 00:44.46 |
| | hmmm I think it could still be made to work | 00:45.14 |
| | anyway that is another problem.... | 00:45.47 |
| | need to figure out why my clusterpush failed | 00:45.55 |
| | oh these are the same diffs as showed up with http://ghostscript.com/cgi-bin/clustermonitor.cgi?report=ebc42b7b7b27977bac17a9f5a9f0626bcfdf8a16 | 00:47.29 |
| | that makes no sense as I did do a git up | 00:47.53 |
| robin_watts_mac | (not on plane yet. Just got up, going to have breakfast, then check in. Flight in 5 hours) | 00:48.38 |
| mvrhel2 | robin_watts_mac: ok. have a good flight | 00:48.58 |
| | when you get back and are awake, lets talk about this planar/pattern stuff | 00:49.25 |
| robin_watts_mac | ok. | 00:49.34 |
| mvrhel2 | basically we are not doing the proper procs for copying | 00:49.35 |
| | the pattern is planar | 00:49.43 |
| | the destination is planar | 00:49.50 |
| | but we are going through the tile clip device | 00:50.00 |
| robin_watts_mac | So it's hackery in the rats nest that is getbits that's needed. | 00:50.19 |
| mvrhel2 | I was going to have it do copy_plane but the clip device has mucked things up | 00:50.23 |
| | yes | 00:50.28 |
| robin_watts_mac | Yes, the clip device is a pain in the ass. | 00:50.37 |
| mvrhel2 | and this is a special clip device | 00:50.49 |
| robin_watts_mac | I had to extend that a bit just before I came away, I think. | 00:50.50 |
| | "special"? | 00:51.18 |
| mvrhel2 | tile clipper device | 00:51.35 |
| | I don't recall stumbling upon this one before | 00:52.02 |
| | in gxclip2.c | 00:52.15 |
| | mask clipping for tiles | 00:52.28 |
| | for patterns | 00:52.34 |
| | excuse me | 00:52.36 |
| | so we have our mask bit map | 00:52.55 |
| | and our bit map (which is now planar) | 00:53.05 |
| robin_watts_mac | Can't look now, but will try to have a quick look on the plane. | 00:53.23 |
| mvrhel2 | and we want to do a copy_plane | 00:53.30 |
| | if you can add a copy_plane for the gxclip2.c device that would probably solve our issue | 00:53.56 |
| robin_watts_mac | Might be worth having a quick look at my recent commits in case one is in a parallel case to this. | 00:54.04 |
| mvrhel2 | I wont fool with it if you are going to look at it | 00:54.08 |
| robin_watts_mac | I'll look at it when I get back, sure. | 00:54.23 |
| mvrhel2 | or on your 15 hour plane ride.... | 00:54.33 |
| | :) | 00:54.35 |
| robin_watts_mac | No access to bugzilla on the plane, so it all depends if I can reproduce it before I get on board. | 00:55.18 |
| | Was going to look at colour rounding on the flight. | 00:55.28 |
| mvrhel2 | oh let me email you a file | 00:55.30 |
| | that has a simple pattern fill | 00:55.48 |
| | ok no worries. I wont send it | 00:56.09 |
| | enjoy your flight | 00:56.24 |
| | hmmm why is my bmpcmp not running | 00:58.19 |
| robin_watts_mac | i you have a simple file, pleae send it. | 00:58.37 |
| | s/i/if/ | 00:58.42 |
| mvrhel2 | ok | 00:58.49 |
| | it is sent | 00:59.58 |
| | I think something is screwed up with the cluster | 01:01.08 |
| | henrys; ok, if you update now if the target is planar patterns are forced into the clist case | 01:03.59 |
| | hmm commit is slow.... hold on | 01:04.14 |
| | what is going on | 01:04.46 |
| | the world's smallest commit is taking forever | 01:05.03 |
| | there it goes | 01:05.24 |
| | ok. off to dinner. robin watts_mac: have you posted pictures anywhere from your trip? | 01:06.08 |
| robin_watts_mac | yeah, let me get you a link. | 01:16.36 |
| | http://www.facebook.com/media/set/?set=a.1929948419552.2093444.1567483821&type=1 | 01:17.33 |
| | That's a very edited selection; we have taken about 1500 between us :) | 01:18.16 |
| robin_watts_mac | heads out. | 02:21.10 |
| malc_ | tor8: hi. i was wondering the substitute font (droid) only has one style (regular) what happens if the document uses italic/bold/whatever version which is being substituted with droid sans, does mupdf requests artificial slanting or emboldening? | 10:49.35 |
| tor8 | malc_: correct. | 10:49.49 |
| malc_ | tor8: reason being, yesterday i've noticed that Ascender made "Open Sans" available under apache license, open sans with multiple styles that is | 10:51.06 |
| | given that open sans is dervied from droid (or vice versa) maybe it makes sense to use that instead.. just a thought | 10:51.34 |
| tor8 | oooh, got a link? | 10:51.46 |
| malc_ | http://www.fontsquirrel.com/fonts/open-sans | 10:52.16 |
| henrys | kens:don't we want to error out when the allocation of the clippath fails? | 14:09.44 |
| kens | henrys we do, at a higher level | 14:10.23 |
| | Its hte freeing as part of the error handling that fails | 14:10.32 |
| | We detect the null allocation and run a clean up routine, which assumes the paths are all OK | 14:10.58 |
| | Makes sense ? | 14:11.12 |
| henrys | oh I see sorry I didn't understand that. | 14:12.23 |
| kens | No problem. | 14:13.06 |
| | never sure how much to write in a log. | 14:13.19 |
| henrys | for 692457 is the PCL okay, if not assign it to me. | 14:14.28 |
| kens | PCL rendering is fine, its a pdfwrite issue | 14:20.08 |
| | Don't knwo what yet, need to cut down the file. | 14:20.25 |
| henrys | I can do that quickly if you want may not get to it before you leave today. | 14:24.26 |
| kens | Would help, yes please | 14:24.39 |
| | no rush, I'm still doing Alex's bugs | 14:24.47 |
| henrys | will do | 14:25.01 |
| kens | thanks | 14:25.05 |
| henrys | pcl has an underline command I suspect that is the issue. | 14:31.21 |
| kens | AH, that may be it, yes, I ha dno idea there was such a thing | 14:31.36 |
| henrys | mvrhel2:I meant to bring up at the meeting the status of your/alexcher's customer that wanted a customer screen. Is that finished up? | 16:00.53 |
| mvrhel2 | I have not seen any emails | 16:01.22 |
| | I had hoped that alex had introduced himself and made some progress on it. alexcher? | 16:01.46 |
| | henrys: we should be good to try some time testing with the color thresholding on I believe | 16:03.32 |
| henrys | for now we just need to stick a different screen in gs_init.ps right? That will fix the customer's immediate issue, if we want to make a project out of it and do fancy custom screen installation that's fine but let's get something to the customer fast. | 16:04.08 |
| mvrhel2 | henrys: yes. so he is going to have a set of *.ps files that will have different screens for different resolution ranges. if alexcher is able to create a gs_init.ps that picks out the right one (basically like our selection of two hafltones based upon resolution but with them external to gs_init.ps due to the size of the screens) | 16:05.59 |
| kens | Custom BeginPage that pulls the HWResolution and selects a screen ? | 16:06.38 |
| mvrhel2 | unfortunately I don't know where we are in this process. it would seem to be something that alexcher could do quickly for them and put is some dummy screens | 16:06.46 |
| | kens: we already do this in gs_init.ps | 16:06.57 |
| henrys | I don't think the size of the screen matters they have no disk, based on their rom size complaints. | 16:06.58 |
| mvrhel2 | I was just thinking of making the file cleaner though | 16:07.18 |
| kens | Do which mvrhel2 ? Select a screen ? | 16:07.20 |
| mvrhel2 | have 5 screens of 128x128 is a bit messy in one file | 16:07.30 |
| henrys | mvrhel2:fair enough | 16:07.41 |
| mvrhel2 | kens: yes. we set our hafltone based upon resolution | 16:07.44 |
| kens | OK | 16:07.47 |
| mvrhel2 | there is some magic threshold | 16:08.05 |
| kens | Theres a Halftone Resource category, couldn't we pull the files fro tehre ? | 16:08.07 |
| mvrhel2 | this customer wants multiple thresholds | 16:08.14 |
| kens | Is that a probelm ? Can't we have that as a Resource ? | 16:08.39 |
| mvrhel2 | kens: I don't know how alexcher wants to handle it | 16:08.55 |
| kens | OK | 16:08.59 |
| | I'll shut up now :-) | 16:09.05 |
| mvrhel2 | well you can bring it up with alexcher :) | 16:09.22 |
| kens | Probably take longer to discuss than to do | 16:09.35 |
| mvrhel2 | I dont' know. I am not sure it is done yet.... | 16:09.46 |
| | And it has been almost a month | 16:09.58 |
| kens | is reluctant to get involved | 16:10.29 |
| mvrhel2 | hehe | 16:10.32 |
| | to late | 16:10.35 |
| henrys | how do they select the screen, manually on the command line? | 16:12.29 |
| mvrhel2 | henrys: right now you mean? | 16:12.48 |
| kens | I would think they just set the resolution and it picks the best one | 16:12.50 |
| mvrhel2 | yes | 16:12.55 |
| | that is what they want | 16:12.59 |
| henrys | well gs_init.ps already does that so it is simple enough to expand that logic. | 16:13.28 |
| mvrhel2 | using the gen_patt code I sent, they are creating custom screens | 16:13.40 |
| | henrys: I agree | 16:13.43 |
| | I think even I could do it | 16:13.53 |
| kens | Maybe best to do so and send them something soon. | 16:14.08 |
| henrys | I vote for you and ken to take it over. | 16:14.15 |
| kens | :-( | 16:14.20 |
| mvrhel2 | ok. let me send them and email to see where they are | 16:14.28 |
| | I will cc you in ken | 16:14.31 |
| kens | Not tonight anyway, I'm off shortly | 16:14.38 |
| mvrhel2 | I would like to talk to alexcher first though | 16:14.43 |
| | to see what has or has not been done | 16:14.53 |
| henrys | okay whatever you guys decide - just want to get something to them. | 16:15.00 |
| kens | Suggest you talk to Alex while I'm away :-) | 16:15.01 |
| mvrhel2 | ok. I will send him an email | 16:16.12 |
| alexcher | I'm here. | 16:16.45 |
| henrys | so if it is just resolution the device can return the default halftone and the logic in gs_init.ps won't be used. | 16:17.33 |
| mvrhel2 | alexcher: just sent you an email | 16:18.25 |
| | did you respond to the customer about the halftone screens/ | 16:18.44 |
| | ? | 16:18.46 |
| | or rather the logic for them to select their screen | 16:18.59 |
| alexcher | I'm doing this now. | 16:19.14 |
| mvrhel2 | Have you sent them an email at all? | 16:19.25 |
| alexcher | I don't have screens, I don't know their resaolutions. I'll write a template. | 16:20.35 |
| mvrhel2 | exactly | 16:20.49 |
| henrys | I think we last agreed alexcher would set this up and give instructions to marcosw_ to communicate with the customer. | 16:20.50 |
| mvrhel2 | ah ok | 16:20.55 |
| henrys | but if alexcher wants to communicate with the customer that is fine too. | 16:21.27 |
| mvrhel2 | but I think we should send them a tickler message that something is coming sometime. I feel like we went a bit dark on this | 16:21.28 |
| henrys | agreed | 16:21.51 |
| | I'll ping marcos | 16:22.02 |
| mvrhel2 | alexcher, do you have a date when you think you will have the template done? | 16:22.14 |
| kens | Don't forget he's on vacation from tomorrow | 16:22.17 |
| mvrhel2 | alexcher is? | 16:22.47 |
| kens | No, marcos | 16:22.55 |
| mvrhel2 | oh marcos | 16:22.55 |
| kens | :-) | 16:23.00 |
| alexcher | I'll do it today. | 16:23.00 |
| henrys | kens:right I'll just send something if I don't hear back from him. | 16:23.23 |
| kens | OK | 16:23.29 |
| mvrhel2 | alexcher: ok thanks | 16:24.47 |
| | alexcher: are you going to send it to marcos or to the customer yourself? | 16:25.13 |
| alexcher | I'd rather send the message to support for review first. | 16:26.14 |
| mvrhel2 | sounds good | 16:26.24 |
| | henrys: so we should be good to go ahead and do some testing with the color thresholding | 16:27.16 |
| | Do you want me to help with that? Otherwise I am going to spend a little time on the simple CMM | 16:27.39 |
| | maybe I should do a clusterpush with the color thresholding on | 16:28.07 |
| henrys | right I saw that. I'll try to have a look at that today. I really wanted a fuzzy compare with a chunky device to test both planar and thresholding. | 16:28.12 |
| | robin_watts_mac said something could be done to that effect. | 16:28.26 |
| mvrhel2 | right | 16:28.53 |
| | What would be nice is the following: | 16:29.13 |
| | add plank to the test suit (it outputs pam output) | 16:29.28 |
| | and then we can turn off and on the fast thresholding | 16:29.41 |
| | diffs will only be in the plank device | 16:29.48 |
| | since we only test for planar devices | 16:29.57 |
| henrys | right well let's see if we can get marcosw to do that before he leaves. | 16:30.14 |
| mvrhel2 | that would be great | 16:30.21 |
| henrys | but that doesn't test the plank device which is my first concern. | 16:30.38 |
| mvrhel2 | I understand | 16:30.48 |
| | we can still do that test externally | 16:31.23 |
| kens | Heading off for the night, night all | 16:31.25 |
| henrys | mvrhel2:right | 16:31.31 |
| mvrhel2 | by externally I mean off the cluster | 16:31.33 |
| henrys | bye kens | 16:31.35 |
| | we should just need planc right? | 16:32.41 |
| mvrhel2 | plank is the 4 bit CMYK planar device | 16:33.00 |
| | I think this is what we want | 16:33.04 |
| | planc is 32 bit CMYK I think | 16:33.16 |
| | see gdevplan.c line 28 | 16:34.31 |
| henrys | oh my bad | 16:34.36 |
| | okay mail sent to marcos | 16:36.00 |
| | alexcher, mvrhel2:if this will *really* be done today I probably don't need to send a status update to the custumer. If I can send him a working result by this evening that should be fine otherwise I will send them an update. Let me know. | 16:45.26 |
| alexcher | henrys: I'm writing a default halftone that checks the current resolution and adjust itself. This is easy and should work on any PS interpreter. | 16:48.05 |
| henrys | okay but that doesn't really answer my schedule question. | 16:50.53 |
| alexcher | henrys: Yes, it will be ready in 1 hour. | 16:51.39 |
| henrys | mvrhel2:do you need to try out alexcher's stuff with a few screens? | 16:52.52 |
| | before I send it off? | 16:53.00 |
| alexcher | henrys: I'm using a line screen and change the angle depending on the resolution. This is a demo. I don't have real halftones. | 16:54.06 |
| mvrhel2 | henrys: no I think they are fluent enough to use the template and add their stuff | 16:54.38 |
| henrys | okay | 16:56.04 |
| alexcher | henrys; the template is ready. We have a bug in ghostscript that doesn't set default halftone in some cases. The bug should be easy to fix. | 17:20.35 |
| henrys | did I mention we want to send something to the customer that works? | 17:25.28 |
| ray_laptop | mvrhel2: is this for Freek ? Have they said that they want line screens (vs. the stochastic) ? | 17:33.53 |
| mvrhel2 | ray_laptop: they liked what they were seeing with genpat | 17:34.20 |
| | last I talked with them they were creating the linearization | 17:34.38 |
| ray_laptop | mvrhel2: OK. So alex just needs to select from the various thresholds, right ? | 17:34.54 |
| mvrhel2 | they want to have different ones for different resolutions | 17:35.17 |
| | and want that to occur in the gs_init PS code | 17:35.53 |
| ray_laptop | mvrhel2: right, they'd need different linearization applied -- could all start from the same genpat data | 17:35.56 |
| mvrhel2 | yes. they are creating those | 17:36.10 |
| alexcher | mvrhel2: the screen is done, see my message. | 17:36.36 |
| ray_laptop | They don't have to modify genpat if they use the setpagedevice 'Install' proc that sets the default graphics state | 17:36.40 |
| mvrhel2 | ray_laptop: I think they are generating the screens off-line with baked in linearizations and then picking those for different resolutions. | 17:37.35 |
| | maybe you should take over on the support for them with respect to all of this though | 17:38.03 |
| ray_laptop | mvrhel2: that's fine. if they just put each PS output from the linearization into a separate file, named by the resolution somehow, then doing a ___ /Halftone findresource sethalftone is trivial | 17:38.54 |
| | where ___ is the unique name based on the resolution | 17:39.14 |
| mvrhel2 | ray_laptop: ok that is more along the lines that I was thinking | 17:39.19 |
| ray_laptop | IMHO the more we can keep customers from modifying the code we distribute, the easier it is to support them and get them to keep current | 17:40.05 |
| mvrhel2 | yes | 17:40.13 |
| | ok. well ray_laptop, maybe you can look over what alexcher just sent to support and see if it is an OK solution | 17:41.02 |
| | if it is ok, then henrys is going to send it off to them I believe. I can quietly exit from this... | 17:42.03 |
| henrys | ray_laptop:you can send out something directly if you like I was going to do it becuase marcos leaves soon. | 17:43.46 |
| ray_laptop | mvrhel2: I think having files named separately will be easier (that they put in the %romesource/Halftone/ directory) | 17:44.53 |
| mvrhel2 | I agree | 17:45.07 |
| | I think I mentioned that above on IRC | 17:45.30 |
| | at least the part about putting them each in different files | 17:45.49 |
| ray_laptop | mvrhel2: the question about alex's 'template' is that it isn't clear when/how to run it, plus while it defines the /Default Halftone resource, it doesn't do the 'sethalftone' | 17:46.27 |
| mvrhel2 | ray_laptop: this is why I am having you review it :) | 17:46.48 |
| alexcher | ray_laptop: A halftone resource doesn't need to change the current halftone. | 17:47.50 |
| | ray_laptop: It is run by PS interpreter at the page device initialization. | 17:48.47 |
| ray_laptop | I think that by adding it into an 'Install' proc, it will get run when the device is changed | 17:49.21 |
| henrys | why aren't we using this "currentdevice /HalftoneDefault gsgetdeviceprop" ... have the device provide the halftone? | 17:50.13 |
| alexcher | ray_laptop: .setdefaulthalftone is alredy run by setpagedevice | 17:50.34 |
| ray_laptop | alexcher: when they change the resolution, what will re-run the template in order to change the /Default /Halftone resource ? | 17:53.28 |
| henrys | maybe I am missing something but using the /HaftoneDefault they would only have to modify their already changed device. | 17:53.31 |
| ray_laptop | henrys: returning a dict type parameter from a device isn't all that easy | 17:54.04 |
| alexcher | ray_laptop: Yes, the resolution is changed by "setpagedevice" | 17:54.04 |
| ray_laptop | alexcher: I understand that the .getdefaulthalftone and .setdefaulthalftone will get run when the resolution is changed, but what/how does your template get re-run then ? | 17:55.26 |
| henrys | ray_laptop:okay hopefully you and alexcher can resolve this soon, I think we did drop the ball with the customer and we should get something to them soon. | 17:56.35 |
| alexcher | ray_laptop: so you say that findresource will return a resource that was defined earlier in memory? | 17:57.48 |
| ray_laptop | alexcher: findresource will search memory first, then the 'external' (%rom%Resource/) resources | 17:58.35 |
| | by loading the Halftone Resource at Install time, then it can use whatever resolution is set. | 17:59.47 |
| | iirc, this customer has different X and Y resolutions (not uncommon with printers) so we need to take into account both | 18:00.38 |
| alexcher | ray_laptop: I agree that Install approach will always work. | 18:01.11 |
| | ray_laptop: I don't know exact resolutions. My file can be modified to do something else in this case. | 18:02.17 |
| | ray_laptop: BTW, how the fonts that mutate depending on the resolution work? Theu should have the same problem. | 18:03.54 |
| ray_laptop | the Halftone name can be generated as something like: currentpagedevice /HWResolution get aload pop cvi exch cvi 10 string cvs (x) concatstrings exch 10 string cvs concatstrings cvn | 18:05.19 |
| | then if the resolution is 100x200 the Halftone resource would simply be named 100x200 | 18:06.14 |
| alexcher | ray_laptop: The name is used for CRD selection based on rendering intent. I doubt we are going to implement this. | 18:07.13 |
| ray_laptop | alexcher: you mean the Halftone name ? (which is used by 'findcolorrendering' ?) | 18:10.56 |
| alexcher | ray_laptop: yes | 18:11.14 |
| ray_laptop | alexcher: since that all depends on a ColorRendering ProcSet resource being defined that has a GetHalftoneName I don't think that is a problem | 18:12.27 |
| | of course, the one thing that they will have to change is to modify psi/psromfs.mak to get the Halftone directory added to the list of Resource directories :-( | 18:14.18 |
| | mvrhel2: do you think having 5 128x128 hex encoded threshold arrays going to be objectionable to them ? | 18:15.25 |
| alexcher | ray_laptop: PS part is working already but it needs CRD's for all the combinations. | 18:15.46 |
| ray_laptop | alexcher: what are you talking about ? (how did CRD's come into the discussion) ? | 18:16.28 |
| mvrhel2_ | ray_laptop: I don't know how many they really want to have now what size. | 18:17.14 |
| | s/now/nor | 18:17.20 |
| ray_laptop | for the customer under discussion, they are pickling in the TRC so they only need a single CRD (it's monochrome anyway) | 18:17.45 |
| henrys | these are the folks complaining about rom size but we have dropped that considerably by pulling the cmaps. | 18:17.56 |
| alexcher | ray_laptop: findcolorrendering returns a crd name that depends on the halftone name, and something else. | 18:18.00 |
| ray_laptop | alexcher: findcolorrendering ONLY does that if the ColorRendering ProcSet is defined (which we don't) [ I'm looking at gs_lev2.ps] | 18:19.10 |
| alexcher | ray_laptop: we do. | 18:20.32 |
| ray_laptop | alexcher: in the real world, nobody will use findcolorrendering. It doesn't even take into account the media or ink type. And with ICC colors, we don't use CRD's | 18:20.51 |
| | alexcher: sorry -- I missed that the resource was defined in gs_lev2.ps (instead of in the Resource/ProcSet directory) | 18:22.36 |
| | but we don't use findcolorrendering, right ? | 18:22.50 |
| alexcher | Try /aaa findcolorrendering -> /DefaultColorRendering false | 18:24.06 |
| ray_laptop | alexcher: so, can we ignore the findcolorrendering issue ? | 18:24.12 |
| alexcher | ray_laptop: probably, but I cannot make this decission. | 18:25.42 |
| ray_laptop | not that it's at all important, but we probably (for consistency) should have the default ColorRendering name just be /Default (like for other resource categories) | 18:27.36 |
| alexcher | ray_laptop: Is far as I remember, we match Adobe in this respect. | 18:28.43 |
| ray_laptop | alexcher: since we are talking about a method for this specific customer -- to add an Install proc when they start up gs, then findcolorrendering is not an issue for them | 18:28.55 |
| alexcher | As far ... | 18:28.58 |
| | ray_laptop: Yes, of course. | 18:29.18 |
| ray_laptop | alexcher: that may be -- I haven't checked what name Adobe returns by default | 18:29.28 |
| | and it looks like if the Halftone Resource has a /HalftoneName defined in it, it will be used automatically by the GetHalftoneName in the aforementioned ProcSet | 18:31.10 |
| | alexcher: do you agree that the Install proc should find the appropriate Halftone Resource, then define it as /Default _and_ do sethalftone ? I think the definition as Default is needed in case HalftoneMode == 1 since it actually uses the Default, not the halftone given | 18:33.48 |
| | and we are recommending that the customer have HalftoneMode 1 set so that files with halftones defined in them don't cause problems | 18:34.41 |
| alexcher | ray_laptop: Yes, I agree. | 18:34.45 |
| ray_laptop | alexcher: OK, so I'll email my recommended .ps file that will set up the Install proc (and instructions for what else they need to do) for your review and michael's. Just a few minutes (I _do_ want to test it) :-) | 18:36.43 |
| alexcher | ray_laptop: OK | 18:37.06 |
| ray_laptop | mvrhel2: see above line, and expect email shortly | 18:37.11 |
| mvrhel2 | ok sounds good | 18:37.18 |
| ray_laptop | mvrhel2: alexcher: instructions and file for Freek sent. Please call if questions -- I will be running errands... | 20:12.24 |
| Robin_Watts | Home. | 20:52.41 |
| | mvrhel2: I fixed the color rounding issue for the tiffsep device on the plane home. | 20:53.01 |
| | It was using compressed encoding which meant it was a fun and exciting trip through some new code. | 20:53.34 |
| | I'll tidy that up and test it in the next few days. | 20:53.52 |
| | I didn't have the energy to look at the planar stuff, but I'll look at that tomorrow. | 20:54.16 |
| henrys | hey Robin_Watts welcome back. We missed ya' | 20:58.08 |
| Robin_Watts | got back to a customs bill for Company I's board :( | 20:59.49 |
| henrys | well just expense it. | 21:07.31 |
| Robin_Watts | will do. | 21:07.48 |
| | I thought we'd escaped it. | 21:08.01 |
| henrys | alexcher can you please test ray_laptop solution then we'll get something out the to the customer - good to check if somebody can set it up and run it before we send it out. | 21:13.14 |
| mvrhel2 | Robin_Watts: welcome home | 22:43.58 |
| | good news about the color rounding | 22:44.12 |
| | henrys: I am working on some SSE2 improvements to the interpolations in lcms which seems to be our primary performance bottleneck | 23:55.43 |
| | I *think* this will not be too hard to do | 23:55.54 |
| | the dumb cmm will of course help with this too | 23:56.36 |
| | Forward 1 day (to 2011/08/25)>>> | |
IRC Logs