| | <<<Back 1 day (to 2012/12/16) | 2012/12/17 |
| kens | chrisl did you see this: | 09:29.03 |
| | http://www.theregister.co.uk/2012/12/17/windows_security_update_kills_fonts/ | 09:29.03 |
| chrisl | Nicely done MS!! | 09:30.34 |
| kens | :-) | 09:30.39 |
| chrisl | MS don't really give any details of what they're trying to fix..... | 09:31.53 |
| kens | I presume its a buffer overrun or something similar | 09:32.07 |
| | So a malicious font could cause a security hole | 09:32.26 |
| | I'm guessing the openType driver isn't affected by address space randomisation | 09:32.50 |
| chrisl | Well, they've certainly plugged the security hole! | 09:34.14 |
| kens | So it would seem... | 09:34.35 |
| chrisl | dons conspiracy theory foil hat..... | 09:36.39 |
| | Of course, maybe MS just don't want us using CFF OTF fonts | 09:36.55 |
| kens | Or adopting security patches ? | 09:37.35 |
| chrisl | My guess is someone who doesn't know much/anything about CFF, "fixing" an alleged problem found by some analysis tool | 09:39.08 |
| kens | Hmm,possibly, I didn't think MS were big on fixing stuff wihtout an exploit but I could be wrong | 09:39.38 |
| | Whatever they did, its obviously wrong. | 09:40.00 |
| | Or, of course, just possibly, there are an awful lot of broken fonts around that were previously handled.... | 09:40.29 |
| chrisl | I wonder if we'll have to implement the same "fix" to maintain compatibility..... ;-) | 09:40.58 |
| kens | Somehow I can't see customers pushing for that one. | 09:41.19 |
| Robin_Watts | chrisl: ping | 14:34.29 |
| chrisl | Robin_Watts: pong | 14:34.36 |
| Robin_Watts | So, I'm back on this damned Unicode crap again. | 14:34.48 |
| kens | I saw the reply :-( | 14:34.56 |
| chrisl | Oh, I've been trying to ignore it...... | 14:35.00 |
| Robin_Watts | At the moment I have a WINDOWS_NO_UNICODE define, which when used on windows, is intended to ensure that gs runs as it always has, just treating ascii codes as being 8 bit values. | 14:35.34 |
| chrisl | Yeh | 14:35.58 |
| Robin_Watts | And in his reply, sags makes reference to other OS that may also work in such a way (VMS, OS/2 etc) | 14:36.12 |
| chrisl | Do we care? | 14:36.27 |
| Robin_Watts | i.e. stuff that doesn't supply UTF8. | 14:36.30 |
| | Well, I was thinking that I could change the define from WINDOWS_NO_UNICODE to GS_NO_UTF8 | 14:36.47 |
| | And then any of these OS can build with GS_NO_UTF8 defined to get the old 8 bit clean pathway. | 14:37.10 |
| | What do you reckon? | 14:37.29 |
| chrisl | If you like. What do we have to change to make that 8 bit clean pathway? | 14:38.01 |
| Robin_Watts | I have new code that unpacks the args from whatever format they come in on, and repacks them into utf8. | 14:38.40 |
| | For WINDOWS_NO_UNICODE I need to make them repack into 8bit clean. | 14:38.57 |
| | And that's the same code for GS_NO_UTF8. | 14:39.07 |
| | So essentially, the extra work is just a friendly rename of the define. | 14:39.26 |
| chrisl | Okay, that's fine by me. I mean, my preference is just to say "the API has changed, we're using UTF-8", but others feel differently...... | 14:40.08 |
| Robin_Watts | chrisl: Right, but that means that ports to some systems that have historically worked will now break. | 14:41.00 |
| | At least now we offer a compatability path. | 14:41.10 |
| chrisl | Okay, we better make sure and test on DOS 5.x, then ;-) | 14:43.13 |
| Robin_Watts | I think I've got DOS 6.2 floppies in the drawer to my left... | 14:43.46 |
| kens | I have a dos 6 I htink | 14:43.54 |
| chrisl | Also, I would drop the GSDLL stuff - that has been deprecated for a long time | 14:44.00 |
| kens | also WINdows 95 :-) | 14:44.01 |
| Robin_Watts | chrisl: I would, but we call it :) | 14:44.14 |
| | kens: I have windows 3.1 floppies with the DOS 6.2 ones. | 14:44.26 |
| chrisl | Thus I gather that "deprecated" means something entirely different in the GS universe to what I'm used to! | 14:45.21 |
| kens | Concurrent DOS, CP/M ? | 14:46.04 |
| | That loon with an AmigaOS port ? | 14:46.16 |
| | I have an old amiga 500 somewhere | 14:46.30 |
| chrisl | Robin_Watts: sorry, I just can't believe this is *so* freakin' complicated | 14:49.05 |
| Robin_Watts | chrisl: Me either. | 14:49.14 |
| | I think we're iterating closer to a solution that's fairly nice. | 14:49.57 |
| chrisl | Just a bunch more API calls so we can maintain compatibility with the '80's........ | 14:51.24 |
| | But yeh, given that we apparently have to do that, changing to "GS_NO_UTF8" makes sense | 14:52.56 |
| sebras | for once I have a gs-related question. :) | 15:24.46 |
| | what controls the windows size that pops up when I do gs test.ps? | 15:26.29 |
| | I'm having a test.ps that I can view perfectly fine using gv, but when trying to view it through gs or doing ps2pdf it truncates the page size. | 15:26.58 |
| | (instead of scaling it). | 15:27.03 |
| | there's obivously some arcane argument to gs that I forgot to pass, but which one? | 15:27.32 |
| Robin_Watts | sebras: You mean the initial size of the window, or the extent of the window that can be scrolled around ? | 15:27.37 |
| | The initial size - god knows. | 15:27.46 |
| sebras | yes, the initial size. | 15:28.05 |
| Robin_Watts | The total size that can be scrolled around = the size of the device output. | 15:28.15 |
| | (Just to be clear, extent >= initial size, right?) | 15:28.43 |
| sebras | and resizing the window from gs just just gives me the same clipped page contents drawn indefinitely. | 15:28.51 |
| | I'm not sure what you mean by extent. | 15:29.19 |
| Robin_Watts | sebras: Right, that sounds like we're disagreeing with each other. | 15:29.26 |
| sebras | ok, set me straight. :) | 15:29.36 |
| | what am I missing? | 15:29.40 |
| Robin_Watts | The actual page size of the display device is potentially much larger than can be displayed on your monitor. | 15:29.56 |
| | hence the initial size that the window pops up may be smaller than the actual page extent. | 15:30.16 |
| | but you can scroll around the page contents within the window. | 15:30.25 |
| | hence the size at which the window initially appears is chosen (presumably) by some magic combination of the window manager/some code in gs. | 15:31.16 |
| kens | I htink the windo size is stored in the registry onWIndows | 15:31.40 |
| Robin_Watts | But the size of the extent (i.e. how much of the underlying window contents there are to scroll around), is determined from the size of the display device. | 15:31.42 |
| | kens: Righto, so kens == god in this case :) | 15:31.57 |
| chrisl | sebras: what platform? | 15:32.12 |
| kens | I'm sure that's not true | 15:32.12 |
| sebras | kens: but I'm not on windows (even at work! ;) ) | 15:32.15 |
| | chrisl: debian/testing. | 15:32.22 |
| kens | sebras, just commenting in passing | 15:32.27 |
| Robin_Watts | sebras: So, are you talking about the initial size of the window, or the actual size of the window contents ? | 15:32.44 |
| chrisl | Right, x11/x11alpha do have scroll bars...... | 15:32.45 |
| kens | but as Riobin says, window size != media size | 15:32.47 |
| Robin_Watts | yeah, window size and media size. Those are much nicer terms. | 15:33.06 |
| chrisl | sebras: the best way to scale the page is with the resolution - defaults to 72] | 15:33.17 |
| Robin_Watts | chrisl: I suspect (but I am not sure) that sebras is complaining that he's getting the wrong media size chosen. That's what I am attempting to clarify. | 15:34.03 |
| sebras | Robin_Watts: yes, I think that the media size is wrong. | 15:34.42 |
| chrisl | PS or PDF input? | 15:34.58 |
| sebras | ps. | 15:35.01 |
| | Robin_Watts: what's puzzling is that gv can show it perfectly fine. | 15:35.23 |
| chrisl | sebras: does the page fit in the x11 window? | 15:36.36 |
| kens | gv may be using the DSC comments to set the media size | 15:36.40 |
| sebras | chrisl: no. | 15:36.43 |
| Robin_Watts | sebras: -sPAPERSIZE=a4 ? | 15:36.53 |
| sebras | kens: that seems reasonable. | 15:36.56 |
| kens | whereas GS may be using the default, especially if its an EPS and has no media size request | 15:36.59 |
| sebras | Robin_Watts: now we're getting somewhere. | 15:37.16 |
| | Robin_Watts: if I use -sPAPERSIZE=a3 then I can see all contents. | 15:37.28 |
| kens | right so job does not request media size | 15:37.39 |
| sebras | kens: how would a job do that? | 15:37.49 |
| | unless I override it on the command line? | 15:37.58 |
| kens | <</PageSize [x y]>> setpagedevice | 15:38.05 |
| Robin_Watts | sebras: with postscript magic. | 15:38.05 |
| | sebras: So, gs picks a default. -sPAPERSIZE sets the new size. IF the job then called setpagedevice, that would override it. | 15:38.39 |
| sebras | http://pastebin.com/BxdN75Hb | 15:38.52 |
| Robin_Watts | So it may be that gv is running the job once through the bbox device to get the bbox, then setting the page size to that, and rerunning. | 15:39.07 |
| chrisl | gv probably processes DSC comments | 15:39.48 |
| kens | Robin_Watts : gv interpretets DSC comments | 15:39.51 |
| | see the %%BoundiongBox comments | 15:40.07 |
| sebras | kens: yes, there's one of those present. | 15:40.18 |
| Robin_Watts | kens: I haven't looked at the the file to see whether such comments are there. | 15:40.24 |
| kens | sebras gv uses that to make a media request | 15:40.37 |
| Robin_Watts | Using the bbox device would have the advantage of working even in the absence of such comments. | 15:40.40 |
| sebras | makes sense. | 15:40.51 |
| kens | Robin_Watts : yes, but a job should either contain a media request, or have %%BoundingBox comments (EPS) | 15:41.07 |
| sebras | is it possible to convince gs to interpret the DSC comments? | 15:41.12 |
| kens | sebras, you can have GS gran the comments, but you have to rpovide the code to do something with them | 15:41.35 |
| | grab* | 15:41.47 |
| | THere's a DSC hook or something | 15:42.03 |
| | In this case, it wouldn't really help because the comments are 'atend' | 15:42.14 |
| | whihch is a horrible Adobe kludge that makes it impossible to use on PostScript rips (as opposed to document management systrems) | 15:42.50 |
| sebras | kens: well, there are two PageBoundingBox comments though..? | 15:43.10 |
| kens | yes you could use those | 15:43.37 |
| | and teh Orientation key as well | 15:43.45 |
| | THere's a ProcessDSCHook or something in GS | 15:43.59 |
| | Ray is really the one to ask about this.... | 15:44.08 |
| | Let me do a grep | 15:44.13 |
| sebras | kens: I probably need a fair bit of pointers since I know very little about ps. | 15:45.33 |
| kens | You don't do it in PS I think, there's a DSC parser in gs/psi/dscparse.c | 15:46.04 |
| Robin_Watts | sebras: are you doing this for a single (or limited) set of files, or is this something you're going to need to use repeatedly? | 15:46.26 |
| sebras | Robin_Watts: probably just once. | 15:46.45 |
| Robin_Watts | Then I'd do it manually. | 15:46.53 |
| sebras | though this is an output file from graphviz, so I guess I might encounter the issue at a later time (or someone else will). | 15:47.11 |
| Robin_Watts | -sFixedMedia or something. | 15:47.14 |
| kens | If job does not request media then you don't need to set -dFixedMedia, that just stops the PostScript changing it | 15:48.22 |
| | -sPAPERSIZE is enough | 15:48.30 |
| Robin_Watts | kens: oh, sorry. I was thinking of the argument where you could supply the paper size as numbers. | 15:49.06 |
| | Maybe that's -sPAPERSIZE :) | 15:49.12 |
| kens | sebras yhou can capture DSC comments using the ProcessDSCCOmment switch which needs a PS procedure as an argument | 15:49.18 |
| | Robin_Watts : -dHEIGHTPOINTS etc I think | 15:49.36 |
| Robin_Watts | -sDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS ? | 15:49.52 |
| kens | -DDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS | 15:50.00 |
| Robin_Watts | -d, not -s. | 15:50.04 |
| kens | you cna also use -g | 15:50.08 |
| sebras | no one ever said using gs was easy... I guess the same goes for finding out what arguments to give it. | 15:50.45 |
| kens | THere are so many.... | 15:50.57 |
| sebras | ok, so my real file (that I can not share) will have all contents rendered if I use -sPAPERSIZE=a0. | 15:51.22 |
| | but -dDEVICE*POINTS=? worked better. | 15:52.39 |
| kens | note that you document has the origina not at 0,0 ut at 36,36 | 15:53.13 |
| | so you would also need to 'translate' it to get rid of that | 15:53.25 |
| sebras | so if this .ps would request a mediasize then it would not be embeddable? | 15:54.14 |
| | is this the reason DSC comments are used? | 15:54.24 |
| kens | partly yes | 15:55.09 |
| sebras | ok. is there a reason that tools such as ps2pdf does not use the ProcessDSCComment to provide a suitable hook when doing conversion of ps-files that have DSC comments? | 15:56.28 |
| kens | because maybe that was what you wanted, how should we know ? | 15:57.20 |
| chrisl | sebras: what do you usually expect an interpreter to do with a comment? | 15:59.03 |
| sebras | chrisl: kens: basically the same as gv, i.e. setting the mediasize to whatever is set by DSC comments. | 16:22.49 |
| kens | sebras chris's point is that interpreters (parsers, whatever) *ignore* commetns, they are, afterall, comments.... | 16:23.16 |
| | DSC comments are a way of adding 'metadata' to a language which doesn't support it | 16:23.39 |
| sebras | ah, yes that's right of course. but ps2pdf isn't generally thought of as an interpreter. | 16:23.59 |
| | I know it's a script, but ignorant users ---> sebras, wouldn't know that (until they start digging). | 16:24.47 |
| chrisl | I don't think Adobe Distiller reads DSC comments, at least, by default | 16:26.03 |
| sebras | chrisl: oh, that's surprising (to me). | 16:26.25 |
| Robin_Watts | sebras: Certainly we shouldn't be doing anything with them by default. | 16:26.25 |
| | It could be argued that it would be a useful feature for us to have (yet another) command line flag for us to deal with them. | 16:27.00 |
| | BUT... in the case of 'atend' comments, we can't really do that, as it means we'd be parsing the file twice. | 16:27.21 |
| kens | Robin_Watts : we do have a DSC parser built-in, what I haven't been able to find out is how to actrivate it | 16:27.25 |
| sebras | kens: :) | 16:27.38 |
| chrisl | sebras: well, I hate to sound like a broken record, but they are comments...... they are not intended for the PS interpreter, but for a prepropressor in the workflow | 16:28.01 |
| | kens: there is a "ParseDSCComments" distiller param | 16:29.35 |
| sebras | chrisl: I guess what I'm failing to understand is why ps2pdf doesn't contain this preprocessing step. (I agree that gs itself should not have it!) | 16:33.24 |
| Robin_Watts | because ps2pdf is a dump script that just wraps a call to gs ? | 16:33.47 |
| | s/dump/dumb/ | 16:33.55 |
| sebras | but maybe ps2pdf is just like mupdf -- just a sample application, that might work for you -- so this is the reason it doesn't do it. :) | 16:34.05 |
| chrisl | sebras: presumably because ps2pdf is just an extremely thin wrapper around gs.... | 16:34.06 |
| | kens: -c "<</ProcessDSCComment {pop pop (Found Comment\n) print flush}>> setuserparams" -d | 16:34.50 |
| | s/-d/-f | 16:34.59 |
| sebras | I looked at the gv code and it does appear to scan for DSC, before calling gs. | 16:35.29 |
| kens | chrisl yes but theres al;l of dscparse.c | 16:41.06 |
| | which does 'stuff' | 16:41.13 |
| sebras | ok, I think I have pesterd you guys enough now. :) now I know better why it doesn't work and how to workaround it. thanks for the help kens, rjw and chrisl. | 16:41.24 |
| chrisl | sebras: sorry it wasn't a more complete solution | 16:41.42 |
| | kens: I thought that was just the parser? | 16:41.51 |
| sebras | chrisl: no problem. I might try to submit some patch to ps2pdf that might do something similar to gv, and see if you'll take it. :) | 16:42.28 |
| | my track record for contributing to gs isn't that long (yet). | 16:42.51 |
| chrisl | sebras: we'd really rather people stopped using it...... | 16:43.04 |
| sebras | chrisl: oh, because of issues like this one? | 16:44.22 |
| chrisl | sebras: yes, and because it "hides" stuff which can end up confusing users (and us!) | 16:44.59 |
| mvrhel_laptop | good morning | 16:45.20 |
| chrisl | 'morning! | 16:45.33 |
| mvrhel_laptop | kens: reading over your email now... | 16:47.16 |
| kens | mvrhel_laptop : what I've done works, but.... | 16:52.03 |
| mvrhel_laptop | you mean just doing the alternate tint transform? | 16:52.29 |
| kens | yes, doign teh tint transform | 16:53.57 |
| mvrhel_laptop | kens: and you don't want to use the device ICC profile to define it but keep separations in their alternate tint color spaces. These could be ICC based or DeviceXXX which are different than the device profile. If you just wanted any ICC space you could just to the concretization and use the device ICC profile | 16:55.34 |
| kens | mvrhel_laptop : don't understand that | 16:55.59 |
| mvrhel_laptop | ok let me back up | 16:56.06 |
| | If you did the concretization of the color space, then the values you get back will be in an ICC color space. Just in the ICC color space defined by the device profile. | 16:56.48 |
| | The nice thing about this approach is that you can make sure that the object dependent stuff will just work | 16:57.08 |
| | An you just need to stuff in the appropriate device ICC profile as your color space | 16:57.34 |
| | The way you are doing it now, you could have 2 separation color spaces | 16:57.59 |
| | one with an alternate space that is RGB | 16:58.09 |
| Robin_Watts | mvrhel_laptop: Did you ever see "Scanners" ? | 16:58.13 |
| mvrhel_laptop | one with an altreante space that is CMYK | 16:58.21 |
| | and 2 different ICC profiles will need to be stuffed in | 16:58.38 |
| Robin_Watts | I think kens head just exploded. | 16:58.42 |
| mvrhel_laptop | I think I lost kens | 16:58.44 |
| | hehe | 16:58.45 |
| | Robin_Watts: yes. that is right. That is the movie with the exploding head | 16:58.58 |
| | hmm. I wonder if ken had to leave or if he has a network issue | 17:01.31 |
| | usually he says bye | 17:01.36 |
| Robin_Watts | yeah, I suspect a notwork issue. | 17:01.48 |
| mvrhel_laptop | I thought for sure we would not have power today. Big wind stor m last night. 2 feet of snow at the pass in the last 2 days. | 17:02.26 |
| Robin_Watts | mvrhel_laptop: What good is all that fresh powder if it doesn't take your power out, and give you a chance to ski on it guilt free? :) | 17:03.21 |
| mvrhel_laptop | exactly | 17:03.31 |
| henrys | chatting with my isp I think a turing test is in order | 17:08.58 |
| mvrhel_laptop | ha | 17:09.47 |
| henrys | I'll try the liar paradox and see if he goes into an infinite loop | 17:10.42 |
| Robin_Watts | henrys: Please hold while I check with technical support... | 17:12.18 |
| mvrhel_laptop | calling bombay | 17:12.36 |
| | kens: I am going to step out for about 15 minutes. | 17:13.48 |
| Robin_Watts | pictures mvhrel in the back garden with a shotgun aiming at the power cables. | 17:14.58 |
| henrys | probably best to disconnect from chat while they fix this. | 17:23.08 |
| mvrhel_laptop | Robin_Watts: back. I missed the power cable.... | 17:47.52 |
| kens | Hi mvrhel_laptop sorry, internet died | 17:49.05 |
| | I think I misunderstood the concept of concretize for the color space. | 17:49.57 |
| | IO ha dassumed I would get back values in the device space, not the ICC space for the device. | 17:50.16 |
| | So if my device was CMYK I assumed I would get CMYK values. You are saying what I get are 4 values for the ICC space associated with the device. So in order to get CMYK values I would still have to do the link thing. | 17:50.55 |
| | Which probably explains why the values I was getting looked 'odd' | 17:51.11 |
| | After calling concretize_color I still need to call gsicc_get_link() and icc_lin->procs.map_color() to get the actual process color values. | 17:52.50 |
| mvrhel_laptop | hi kens | 17:56.48 |
| kens | sdorry about the network outage | 17:57.04 |
| mvrhel_laptop | the device space is the ICC space for the device | 17:57.05 |
| kens | Hmm, well by device space I usually mean the process color model of the devioce. | 17:57.22 |
| mvrhel_laptop | yes | 17:57.26 |
| kens | BVut ICC is not a possible device color space (Process color model) | 17:57.49 |
| | Not for real devices anyway :-) | 17:58.04 |
| mvrhel_laptop | Yes it is | 17:58.13 |
| kens | Inkjets and so on don't use ICC inkms | 17:58.31 |
| mvrhel_laptop | The device's ICC profile defines the process color model for the device | 17:58.41 |
| kens | Yeah what I mwan when I say device space is gthe procvess color model of the device | 17:59.00 |
| mvrhel_laptop | But the inks define a color gamut | 17:59.04 |
| kens | Ie Gray, RGB or CMYK | 17:59.06 |
| mvrhel_laptop | and that is all captured with and ICC profile | 17:59.10 |
| kens | Lets not worry about terminology | 17:59.18 |
| | THe point is, after 'concretize'ing teh Indexed or whatever colour, its not in Gray/RGB/CMYK its in an ICC space | 17:59.59 |
| mvrhel_laptop | right. and when you do the call to concretize the color. You will map to the process color model for the device, which is defined by the device's ICC profile | 18:00.05 |
| kens | OK now I'm confused. | 18:00.14 |
| | Siomple question: | 18:00.22 |
| mvrhel_laptop | all color spaces are ICC | 18:00.28 |
| kens | If I do 'concretize color' and I have a CMYK device, are the values I get bacl CMYK or ICC components ? | 18:00.56 |
| mvrhel_laptop | yes :) | 18:01.04 |
| | both | 18:01.08 |
| kens | Uh, not helpful | 18:01.15 |
| mvrhel_laptop | they are CMYK values that are defined by an ICC profile | 18:01.27 |
| kens | So if I send them to an inkjet printer, what do I get ? | 18:01.44 |
| | Or an RGB display or whatever | 18:02.05 |
| mvrhel_laptop | well if you had made the proper ICC profile for your inkjet printer then you will get a lovely match to the display | 18:02.08 |
| kens | Hmmm | 18:02.20 |
| | I've forgotten my original question | 18:02.41 |
| mvrhel_laptop | hehe | 18:02.44 |
| | sorry | 18:02.45 |
| | let me see if I can simplify this | 18:02.56 |
| | So with concretize color we always map to the color space defined by the device | 18:03.17 |
| | which happens to be defined by an ICC profile | 18:03.39 |
| | the profile can be gray, RGB, CMYK or DeviceN based | 18:03.53 |
| | when we do the concretization, it will map to those device values that have a colorometric meaning in that ICC space | 18:04.28 |
| | so if I have a CMYK device | 18:04.35 |
| | and it happens to be a big press that does Forgra 39 inks | 18:04.59 |
| | and I use that profile for my devic | 18:05.11 |
| | then when I concretize I get a CMYK value that has a meaning back to a CIE value through the Forgra 39 ICC profile | 18:05.43 |
| | Like wise if I am printing to my little inkjet printer | 18:06.01 |
| | and I use an ICC profile that is for my inks and halftone method | 18:06.19 |
| | then I will get a different CMYK value that will give me the same CIE value on the paper as the big press did with the Fogra 39 profile | 18:06.48 |
| kens | OK so that is going frmo a CMYK back to a CIE. Whereas I am going forward. I assume that the input and output profiles are 'correct'. So an input colour uses an ICC profile to go to 'CIE' (or asome device-indepemndent space' and tehn uses the output profile to generate colour values 'correct' for that device. | 18:07.15 |
| | So when I concertize, the values I get can be used directly by the device in its native colour model. | 18:07.44 |
| mvrhel_laptop | yes | 18:07.51 |
| kens | Right. So that's what I thought originally. | 18:08.00 |
| | At least that is doing what I expect. | 18:08.21 |
| mvrhel_laptop | but if you want to use them internally, you can pack them as DeviceCMYK making sure to use an output intent or pack the profile as an object and use and ICC color space | 18:08.42 |
| kens | I don't want to use them internally, I just want to write them out. In this case as colour values in the specified colour space (Gray/RGB/CMYK) | 18:09.11 |
| mvrhel_laptop | so you want to do unmanaged color | 18:09.27 |
| kens | THat's what I was doing yesterday for PDF versions < 1.3 which don't support non-device spaces | 18:09.40 |
| | mvrhel_laptop : I'm happy with the code for going to those cases | 18:09.58 |
| | I'll assume that teh user has set up the profiles correctly. If they haven't, well they aren't doing colour management, their problem not mine. | 18:10.24 |
| | Today's problem is more subtl, and maybe I need to think about ti some more. | 18:10.39 |
| | I want to write colours in an ICCBased space, I htink in this case where the ICC space is the mapping from the input colour aspace. | 18:12.11 |
| | But maybe I have this upside-down | 18:12.26 |
| mvrhel_laptop | so you want to keep the source colors in the their original space | 18:12.36 |
| kens | No, I can do that already | 18:12.44 |
| | I want to write the ICCBased space we are using for converting from the input to CIE (I think) | 18:13.01 |
| | THIs is tghe case which has always tripped me up. | 18:13.23 |
| | 'device independent colour' | 18:13.32 |
| mvrhel_laptop | so for the source space DeviceGray, DeviceRGB, and DeviceCMYK you write out the ICC profile in the ICC manager | 18:14.27 |
| kens | Lol which profile ? | 18:14.40 |
| mvrhel_laptop | the defaultRGB, defaultCMYK, defaultGray profiles | 18:14.55 |
| kens | Hmm, OK | 18:15.05 |
| mvrhel_laptop | in the object pis->icc_manager | 18:15.07 |
| kens | OK. | 18:15.35 |
| | But then what are the colour values ? | 18:15.43 |
| | The original colour values ? | 18:15.51 |
| mvrhel_laptop | they are the same as they currently are | 18:15.51 |
| | yes | 18:15.53 |
| kens | OK. | 18:16.00 |
| mvrhel_laptop | no conversion required | 18:16.03 |
| kens | Fair enough | 18:16.07 |
| mvrhel_laptop | you are simply defining them | 18:16.13 |
| kens | But now, what about Separation/DeviceN | 18:16.20 |
| | Assumjing I don't want to write them as /Separation/DeviceN spaces, but want to use the alternates | 18:16.41 |
| mvrhel_laptop | with the sep and devicen spaces, you replace the alternate color Device space with the same default profiles | 18:16.42 |
| | oh | 18:16.47 |
| | you don't want sep and deviceN | 18:16.56 |
| kens | Not in this case, I want to write them as whatever the altrernate was | 18:17.24 |
| mvrhel_laptop | I was thinking you keep them in sep and deviceN and simply colormetrically define the alternate | 18:17.30 |
| kens | Uh | 18:17.43 |
| | I guess that's possible | 18:17.57 |
| mvrhel_laptop | so, lets look at separation for sec | 18:18.01 |
| | here is what will happen when I render it to tiff32nc | 18:18.13 |
| | lets say the alternate color space is DeviceRGB | 18:18.25 |
| | what will happen is the sep value will go through the alternate tint transfer | 18:18.41 |
| | to RGB | 18:18.46 |
| | this RGB is going to be assumed to be the ICC defaultRGB color space | 18:18.58 |
| | and will then be concertized to the CMYK profile defined for the tiff32nc device | 18:19.23 |
| kens | Hmm, I think what I want to do (probably) is write teh Separation with an ICCBased alternate, where the ICCBased space is tghe defaultRGB# | 18:19.53 |
| mvrhel_laptop | yes excactly | 18:20.05 |
| | this will minimize conversions | 18:20.16 |
| kens | I'd better check how Distiller handles this one. | 18:20.17 |
| mvrhel_laptop | and hence errors | 18:20.23 |
| | obviously if any of the source spaces are ICC based then you keep them as is. | 18:21.04 |
| kens | Yes, for this case I always do | 18:21.15 |
| | Other csaxses they get converted, depending on the strategy | 18:21.38 |
| mvrhel_laptop | once I get the CIE stuff fixed to output V2 profiles, you will want to use that profile for CIE color spaces | 18:21.40 |
| kens | mvrhel_laptop : Only for certain versions of PDF. | 18:22.00 |
| | For higher level versions I'm happy to use V4 profiles | 18:22.10 |
| mvrhel_laptop | right ok | 18:22.17 |
| kens | I think PDF 1.4 introduced support for V4 profiles, but I could be wrong, I'd have to check | 18:22.40 |
| | But PDF/A-1 doesn't support transparency and hence is limited to PDF 1.3 | 18:22.56 |
| | I was going to write out the CIE spaces as their ICC versions for now, and assume that you will get that fixed at somepoint, then I will sort my code out. | 18:23.44 |
| | I'mgoing to have to go and put my dinner on. | 18:24.00 |
| | I'll read this some more tomorrow, and think about it, thanks Michael | 18:24.17 |
| mvrhel_laptop | ok. kens. I am out tomorrow but will be back on line wed. | 18:26.17 |
| | Forward 1 day (to 2012/12/18)>>> | |
IRC Logs