| | <<<Back 1 day (to 2011/08/14) | 2011/08/15 |
| mvrhel2 | oops sorry about the long line on the commit | 02:38.05 |
| | robin_watts_mac: are you still in southeast asia? | 02:57.00 |
| Kunnis | vistaprint makes cheap cards, I got some, and I was pretty happy with them. | 04:41.44 |
| malc_ | robin_watts_mac: around? | 08:31.10 |
| kens | Still in the Far East probably | 08:37.06 |
| kens | thinks chrisl_away is not really away | 08:38.39 |
| chrisl_away | realises kens is right......... | 08:39.05 |
| kens | The email to the bug list was a clue ;-) | 08:39.23 |
| chrisl_away | I did change my status, but freenode claims "chrisl" is already in use....... | 08:39.48 |
| malc_ | kens: he's on vacation right? | 08:39.59 |
| kens | malc_ : I believe so, yes. I don't recall when he returns | 08:40.11 |
| malc_ | kens: then i'd better not bother him with mupdf issues for the time being :) | 08:40.29 |
| kens | chrisl_away : didn't you register it with NickServ ? | 08:40.30 |
| | malc_ : You can ask, but I doubt he'll be able to help much... | 08:40.43 |
| chrisl_away | kens: yes it's registered, I'm just trying to remember the syntax for the "kick" command | 08:41.09 |
| kens | Ah.... | 08:41.18 |
| | Mr Google ? | 08:41.21 |
| malc_ | kens: coders solidarity etiquette would not allow me to | 08:41.23 |
| kens | :-) | 08:41.30 |
| malc_ | \/kick <nick> | 08:41.37 |
| kens | That sounds like a good command :-) | 08:41.56 |
| malc_ | but it's for kicking out of the channel | 08:42.11 |
| | not out of the server | 08:42.14 |
| | this sortof thing is reserved for network admins | 08:42.26 |
| kens | Ray is our admin, and he too is (or was) on holiday | 08:42.45 |
| malc_ | for IRC network admins :) | 08:42.59 |
| kens | Not channel ? Oh | 08:43.09 |
| chrisl | Yay! It wasn't "kick" I was looking for, it was "ghost" - memory failed me | 08:49.27 |
| robin_watts_mac | mvrhel2: Yes, still in Vietnam. | 12:20.05 |
| mvrhel2 | hi robin_watts_mac | 12:20.19 |
| robin_watts_mac | malc_: (for the logs) Here. If you have questions, ask them, and I'll answer when I can. | 12:20.40 |
| mvrhel2 | hi kens | 13:37.53 |
| kens | hi mvrhel2 | 13:37.59 |
| mvrhel2 | I will look into 692372 today | 13:38.11 |
| kens | Thanks, I'm lost with it | 13:38.18 |
| mvrhel2 | did you have a particular file you were using? | 13:38.25 |
| | or is it all files | 13:38.27 |
| kens | I used tiger :-) | 13:38.33 |
| mvrhel2 | ok easy enough | 13:38.38 |
| | so the link cache is never going to rc count of 0? | 13:39.01 |
| kens | yes, but it doens' free the semaphore | 13:39.12 |
| mvrhel2 | oh. it should do that | 13:39.20 |
| kens | I wasn't sure, because it reuses the link later | 13:40.39 |
| | rc goes to 0, later it gets bumped back to 1 | 13:40.50 |
| mvrhel2 | oh not the link, I mean the cache | 13:41.07 |
| kens | Well, this is why I am confused I guess. | 13:41.20 |
| mvrhel2 | when the cache is shut down it should take care of everything | 13:41.24 |
| | it is true that links can have a count of 0 and not be released | 13:41.36 |
| kens | Well, that definiely doesn't happen. | 13:41.37 |
| | Indeed. | 13:41.45 |
| mvrhel2 | they are only released if we need more room for more links | 13:41.49 |
| kens | which is where I got too confused. | 13:41.54 |
| | I guessed that. | 13:41.59 |
| | But the semaphore remains. | 13:42.07 |
| mvrhel2 | ok. I will dig into it | 13:42.21 |
| kens | Later we allocate a new link and get a new semaphore | 13:42.22 |
| | Thanks | 13:42.25 |
| mvrhel2 | ah | 13:42.26 |
| | ok thanks for doing all the hard work to track it down :) | 13:42.44 |
| kens | It wasn't too bad, handle.exe helped a lot | 13:42.57 |
| | from SYs Internals | 13:43.04 |
| mvrhel2 | oh where do I get that | 13:43.04 |
| kens | Google for Sys internals handle :-) | 13:43.15 |
| mvrhel2 | ok | 13:43.18 |
| kens | Its on MS somewhere | 13:43.22 |
| | Microsoft site that is | 13:43.31 |
| mvrhel2 | found it | 13:45.48 |
| kens | Great. handle -s -p gs.exe works well. | 13:46.07 |
| | If you are using the customer's harness. | 13:46.22 |
| | or gswin32c.exe or whatever ;-) | 13:46.32 |
| mvrhel2 | yes | 13:46.41 |
| robin_watts_mac | mvrhel2: did you have a question for me ? | 14:01.21 |
| mvrhel2 | robin_watts_mac: no, just saying hello | 14:07.24 |
| kens | mvrhel2 sanity check please ? I have a PDF file which has a grpahics state which sets /CA == /ca == 0.8 and AIS true. Several rectangles are then drawn with this graphics state. Because no blending group is specified, I think this means hte blending space is the default for the device, and will give different results between CMYK and RGB ? | 14:21.56 |
| mvrhel2 | kens: yes that is correct | 14:22.35 |
| | you can see effect by pulling the file into photoshop and in one case specifying RGB and another CMYK | 14:23.09 |
| kens | Great, thanks mvrhel2, I doubt my Photoshop is new enough but the principle is what I wanted to check. | 14:23.37 |
| mvrhel2 | bbiaw | 14:28.32 |
| tkamppeter | I have a problem with the CUPS device: On http://bugs.ghostscript.com/show_bug.cgi?id=691922 is a PostScript input file, attached to comment #42, which is a color file, with appropriate settings for the CUPS Raster device embedded, the command line of gstoraster, /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -sDEVICE=png16m -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -c -f -_ raste | 14:31.47 |
| | rizes it in Grayscale, but color space of the raster is RGBW. | 14:31.47 |
| | Any PostScript expert who couls help me? | 15:06.35 |
| kens | Is it PostScript ? I could take a look, or maybe alexcher | 15:06.53 |
| | which of the many attachments ? | 15:07.21 |
| tkamppeter | If I send parameters to the CUPS device as PostScript command, like <</cupsColorSpace 17/cupsBitsPerColor 8/cupsRowStep 0>>setpagedevice the correct color space and color depth are selected but the document (any PS file) is converted to grayscale. If I give the same parameters as "-dcupsColorSpace=17 -dcupsBitsPerColor=8 -dcupsRowStep=0" on the command line, the document comes out in color. | 15:09.12 |
| | kens, the attachment to comment #42, as I already wrote. | 15:09.53 |
| kens | well adding the to setpagedevice only puts them in the page device dictioanry. Adding them on the command line puts them in (I think) system dict. | 15:09.59 |
| tkamppeter | kens, but now I tracked it down to arbitrary PS files. | 15:10.23 |
| | kens, what do I need to add to get them also into the system dict?: | 15:10.44 |
| kens | Well alex is more likely to help than me, but you need the relevant dict writable (system dict is no unless you add a switch) and then you just do /name <value> def | 15:11.24 |
| tkamppeter | Or can I add something to gdevcups.c that they go into system dict? There are many PPDs out there which put them only into page device. | 15:11.39 |
| kens | Sorry <dictname> begin /name <value> def end | 15:11.40 |
| | gdevcups should be able to ionterrogate the page dictionary, but this is a little out of my line. | 15:12.13 |
| tkamppeter | alexcher, can you help here? | 15:12.47 |
| kens | I'm kind of guessing a bit. But it looks like it is not picking them up from the pagde device dict | 15:12.50 |
| tkamppeter | kens, it is important that they get picked up from both the system dict (command line) and the page dict (PS commands generated by CUPS Raster PPD files). | 15:14.12 |
| kens | I'm looking at it Till, but this is a little out of my usual area, it may take me some time. | 15:14.34 |
| tkamppeter | kens, OK. | 15:14.59 |
| kens | If alex pops up then please ask him to look too, I need to go in 30 minutes | 15:15.23 |
| alexcher | kens: I'm back. | 15:16.16 |
| kens | Hi alex, could you look at Till's problem ? | 15:16.31 |
| alexcher | Yes, of course. | 15:17.11 |
| kens | Thanks | 15:17.15 |
| tkamppeter | alexcher, the problem is that gdevcups.c (CUPS device) has problems taking parameters through the page device, which worked formerly, as PPDs are made that way. The parameters are principally taken, as the output color space and color depth of the raster files is correct, only the page content is converted to grayscale. | 15:31.02 |
| chrisl | tkamppeter, kens, alexcher: I think the problem is that cups_set_color_info() doesn't reset the device ICC profile when the color space is changed to RGBW | 15:31.28 |
| kens | Ah! | 15:31.37 |
| tkamppeter | kens, chrisl, alexcher, can someone of you fix that? | 15:32.56 |
| kens | Not me, I have to go in 10 minutes | 15:33.09 |
| | sounds like a michael problem tho | 15:33.23 |
| chrisl | tkamppeter: I think we'll need mvrhel2 to at least give an opinion - but it looks to me as through the device profile will always be whatever color space the cups device was initialised to use. | 15:34.07 |
| | tkamppeter: if I change the of the cups_set_color_info() as here: http://pastebin.com/ieNwQkkk I get color output, but it's not a complete solution. | 15:35.05 |
| kens | Time for me to go, goodnight all | 15:38.47 |
| tkamppeter | chrisl, I see, it is RGBW-only. | 15:38.54 |
| henrys | alexcher, mvrhel2:are we settled on responding to the customer? | 15:39.34 |
| chrisl | tkamppeter: exactly. Now, the default color space is usually DeviceGray, so we might get away with just setting it back that way, but I doubt it :-( | 15:40.02 |
| tkamppeter | kens, chrisl, alexcher, or should one let gstoraster also supply the parameters on the command line if the input is PostScript? But this could have problems with mid-document changes of color space. | 15:40.25 |
| chrisl | tkamppeter: you wouldn't change the *device* color space in the middle of the document | 15:41.02 |
| tkamppeter | chrisl, I think also that this situation will not come up in daily printing. | 15:42.19 |
| chrisl | tkamppeter: what's the cupsColorSpace setting for CMYK? | 15:43.18 |
| tkamppeter | chrisl, it is 6. | 15:49.13 |
| alexcher | henrys: I don'y know the exact parameters. I'll make a template file which can be modified by the customer. | 15:49.42 |
| chrisl | tkamppeter: cool, thanks. I'll need mvrhel2 to confirm this, but I think my hack posted above might be halfway to the right answer - I think we may just have to set it back to DeviceGray when we change away from RGBW. | 15:50.47 |
| alexcher | tkamppeter: most devices cannot chenge the color model. So setting the color model by a command line argument should be OK. | 15:51.29 |
| tkamppeter | chrisl, alexcher, you find all color spaces in gs/cups/libs/cups/raster.h. | 15:52.35 |
| chrisl | tkamppeter: as alexcher says, normally devices cannot change color spaces once initialized, so the command line solution is likely the simplest - it looks like to support color space changes "in line", you'd need to extend that switch statement I hacked to cover *all* the cups color space options. | 15:57.29 |
| tkamppeter | chrisl, the command line solution would require to read the entire file in gstorater before passing it to Ghostscript to read the embedded PS command so that they can be converted to command line options. Your switch statement in gdevcups.c can move this work into GS which reads the file anyway. | 16:08.21 |
| | chrisl, what do these commands in the switch statement actually do, and which are specific to the actual color space? | 16:09.17 |
| | chrisl, and does this also not break individually supplied profiles from the user or from the PPD file? | 16:12.01 |
| chrisl | tkamppeter: the entire switch is on the cupsColorSpace value, and each case sets a suitable ICC profile for the given cups color space. As for what side effects, I can't answer that. | 16:13.23 |
| tkamppeter | chrisl, so we will need to ask mvrhel2? | 16:16.59 |
| chrisl | tkamppeter: yes, I think so. I'm not aware if there is a way to tell whether a profile is a "normal" one (DeviceRGB/CMYK/Gray) or one specified by the user. | 16:18.14 |
| | tkamppeter: it doesn't look to me as though the cups device makes any effort to use an ICC profile from the PPD as the Ghostscript device profile at all........ | 16:20.33 |
| tkamppeter | chrisl, gstoraster can supply a profile via "-sOutputICCProfile=...". | 16:23.08 |
| | chrisl, which profile will be used in such a case? The one from the command line or the one from the switch statement? | 16:23.56 |
| chrisl | tkamppeter: I *think* the one from the command line - the way it's setup just now, the device profile won't be overwritten in there. | 16:25.10 |
| | tkamppeter: indeed, as currently coded, the already installed profile takes precedence - which is kind of where the problem lies: if the cups device changes its color space, the ICC profile does not change to suit. | 16:29.26 |
| tkamppeter | chrisl, using you code from pastebin I get colored output, but I cannot get it back to gray by adding -sOutputICCProfile=/usr/share/ghostscript/9.04/iccprofiles/default_gray.icc | 16:35.15 |
| chrisl | tkamppeter: no, because the code I put in pastebin forcibly changes the profile for the RGBW case, overwriting the profile you specified on the command line, and never setting it for anything *other* than RGBW - when I said "currently coded" I meant "as committed to git". | 16:37.14 |
| | tkamppeter: I *think* the solution is going to be for cups_put_params() to check and record if the device profile was set by "-sOutputICCProfile=..." (NOTE: it doesn't care *what* it is set to, just that it was set that way), then use that information to know whether to override the existing the device profile in cups_set_color_info(), the cups_set_color_info() needs to have that switch at... | 16:58.07 |
| | ...the end to handle all the relevant/sensible color spaces from cups. | 16:58.09 |
| malc_ | tor8: anything i can do to help with http://bugs.ghostscript.com/show_bug.cgi?id=692429 ? | 17:17.47 |
| henrys | chrisl:do you know the proper way to specify -L in autoconf? In particular I am looking at a bug on the mac, fontconfig lib directory is discovered to be /opt/local/lib but the rest of the system stuff is in /usr/lib - the fontconfig library /opt/local/lib to be used for the entire system. It seems we need a way to specify -L for each library. | 17:25.05 |
| chrisl | henrys: "in autoconf"? You mean as part of configure, or when you run configure? | 17:27.14 |
| henrys | that should say: the fontconfig library directory is used for the entire system. | 17:27.18 |
| | when I compile ghostscript the only -L directive is /opt/local/lib we don't seem to give a default -L so it uses that for everything. | 17:28.37 |
| chrisl | Hmm, that's wrong, isn't it? Doesn't -L *add* to the library search path, not replace it? | 17:29.23 |
| henrys | maybe that is what it is doing but there are libraries added after the -L fontconfig that were autoconf'd using /usr/lib/. | 17:31.03 |
| chrisl | well, there's clearly a problem, but I think that *should* still work, as /usr/lib ought to be the linker's default search path, isn't it? | 17:31.56 |
| henrys | ah yes I see what you are saying it should work okay. | 17:33.48 |
| chrisl | Indeed, from gcc manual: "-Ldir Add directory dir to the list of directories to be searched for â-lâ." | 17:35.06 |
| henrys | maybe it is searching elsewhere if I modify ldt.tr with -L/usr/lib all is well. | 17:35.44 |
| tor8 | malc_: not so much an endless loop as just a very inefficient dictionary lookup | 17:36.59 |
| chrisl | henrys: it's possible, I suppose, that on Mac /usr/lib isn't the default library search path - what happens if you disable fontconfig? | 17:38.10 |
| malc_ | tor8: ah, after a breat detour into gdb i expected as much and gave it some time, it failed to completed page 2 after 8 minutes and i gave up | 17:39.07 |
| | s;breat;brief | 17:39.19 |
| tor8 | it's a dictionary with over 40000 entries | 17:39.39 |
| henrys | ah but wait from the man page:Directories specified on the command line are searched before the default directories. | 17:40.13 |
| | | 17:40.13 |
| malc_ | tor8: you could have said it in swedish, would have had same effect :) | 17:40.15 |
| tor8 | we probably should have a special case for huge dictionaries where we sort them or use a binary tree | 17:40.19 |
| chrisl | henrys: yes, command line setting take precedence, so? | 17:42.37 |
| henrys | the exact problem on the mac is we autoconf iconv with /usr/lib/iconv - use functions specific to that rev then autoconf sets the -L to /opt/local/lib and the system tries to link with iconv in /opt/local/lib which has a different (incompatible) api. But I thought this is an instance of something we are generally doing wrong with -L and -l | 17:42.40 |
| chrisl | henrys: we're never going to be able to handle that situation gracefully | 17:44.28 |
| malc_ | tor8: a hacky solution is to use interned strings and replace strcmp's with pointer comparisons.. but binary trees sounds a lot better | 17:47.53 |
| tor8 | even so it'll be a linear search through an average 20k+ list for every item inserted | 17:48.18 |
| malc_ | aye | 17:48.35 |
| henrys | chrisl:it seems to be a pretty common scene on the mac. mac ports sets up it's own libs and they are certain to be out of whack with the mac distribution. | 17:48.53 |
| tor8 | i might set a threshold over which a dict will get sorted and kept sorted for faster lookups | 17:49.17 |
| malc_ | tor8: btw. your glfont works great, question though, can i somehow reuse the mupdf's version of freetype instance and whether it's a good/worthwile idea at all | 17:50.12 |
| chrisl | henrys: well, the only think I can think of is to spot we're running on the mac, and hard code a preferred path - so we'd always check /opt/local/lib *first* | 17:50.21 |
| tor8 | malc_: you mean the FT_Library? | 17:50.38 |
| malc_ | tor8: yes | 17:50.43 |
| tor8 | don't know if it's big enough to bother reusing... | 17:50.53 |
| | but you should be able to use the built-in fonts at least | 17:51.02 |
| malc_ | tor8: i already do :) | 17:51.13 |
| tor8 | malc_: :) | 17:51.22 |
| malc_ | nimbus one's are no good (coverage is too small even for cyrillic) but droid sans does just fine | 17:51.50 |
| | but i'm thinking of using newly released andika for my own usage.. looks yummy | 17:52.22 |
| tor8 | oooh, there's a new release of andika? | 17:52.41 |
| malc_ | yep | 17:52.45 |
| | cyrillic supported! | 17:52.50 |
| tor8 | does it have kerning set up yet? | 17:52.59 |
| chrisl | henrys: the problem is we can't really have it use one (set of) search path(s) for one library, and another for other lib(s). | 17:53.10 |
| malc_ | tor8: no idea honestly, any special tag in ttf to look for? | 17:53.26 |
| tor8 | kern or GPOS | 17:53.40 |
| malc_ | kern is there | 17:53.43 |
| | ditto GPOS | 17:53.49 |
| | at least from the point of view of hex editor | 17:53.56 |
| chrisl | tkamppeter: I've done a bit of hacking around, and I think http://www.ghostscript.com/~chrisl/gdevcups.c does something pretty close to what we want - the main thing I'd like mvrhel2 to give an opinion on is whether I'm picking the "right" built-in ICC profiles for the color spaces involved (line 4057) | 17:55.37 |
| tor8 | malc_: no kern table, and my ttfdump tool doesn't crack the GPOS tables | 17:57.11 |
| | the lack of kerning is my one and only gripe with andika, other than that it's a great screen font | 17:57.37 |
| henrys | chrisl:right it does seem like a thorny mess, but I have a mess here I really can't uninstall one of the iconv without either breaking mac system or mac ports. Both are being kept up to date with latest releases. | 17:58.32 |
| chrisl | henrys: does "LDFLAGS=-L/opt/local/lib ./configure" work? | 17:58.53 |
| malc_ | tor8: i have another, which was rectified before by compact version.. that is the line height is way too big (due to vietnamese i suppose) | 17:59.04 |
| | tor8: btw http://www.connare.com/ihatecomic.pdf | 18:00.10 |
| tor8 | malc_: yeah | 18:00.14 |
| henrys | chrisl:probably that seems like a reasonable workaround I'll try it. | 18:00.24 |
| chrisl | henrys: actually, you might need: "LDFLAGS=-L/opt/local/lib" CFLAGS=-I/opt/local/include ./configure" | 18:00.34 |
| henrys | yet another reason not to have all these system third party libraries. | 18:00.55 |
| chrisl | henrys: I agree, but too late to change now :-( | 18:02.09 |
| tor8 | malc_: the GPOS table doesn't seem to have any kerning info either :( | 18:03.44 |
| malc_ | tor8: damned sil people, they should be hanged for this | 18:04.40 |
| | tor8: does droid sans has kerning? | 18:05.41 |
| chrisl | henrys: is this mac problem a customer issue? | 18:06.26 |
| henrys | chrisl:no | 18:06.38 |
| chrisl | Well, might it be worth asking the mac ports people for advice? We might not be the only ones to have this problem | 18:07.06 |
| tor8 | malc_: yes, but only in the GPOS table (which freetype doesn't look at -- freetype only gets kerning from the old fashioned pre-OpenType 'kern' table) | 18:08.07 |
| henrys | chrisl:that's an idea I thought I'd try a few other open source packages to see if they do something we don't. | 18:09.30 |
| malc_ | tor8: just ran ttfdump on linotype font i have here, is "table 'kern' 135900 21354" good? | 18:10.52 |
| chrisl | henrys: the main thing that springs to mind is if there is something like a "macports-config" utility, or an environment variable from which we can get the relevant paths, we could ensure we *always* search that path first - but we wouldn't be hard coding anything. | 18:11.13 |
| tor8 | malc_: yeah, that means freetype can use the kerning pairs :) | 18:12.00 |
| | they should be listed in a section further down the dump | 18:12.21 |
| chrisl | henrys: I'm packing up now, if you want me to look into the Mac problem, ping me here or by e-mail, and I'll do so. | 18:14.45 |
| mvrhel2 | oops. missed chrisl | 19:00.30 |
| chrisl_away | mvrhel2: I'm still available, just not really working | 19:09.46 |
| tkamppeter | mvrhel2, chrisl has posted a suggestion for the default ICC profile problem of gdevcups.c, as http://www.ghostscript.com/~chrisl/gdevcups.c, search for "icc_struct" in it and have a look at this switch statement. Are the selected default profiles correct? How can we add support for using our own profile via "-sOutputICCProfile=...", for example a profile from the PPD file or from colord? Will profiles embedded in the PDF input file be su | 19:40.08 |
| | pported? | 19:40.08 |
| chrisl_away | tkamppeter: that gdevcups.c I posted should work correctly with profiles specified with "-sOutputICCProfile=...", I put a check in so it won't override a command line specified profile. In general (mvrhel2 correct me if I'm wrong!) profiles embedded in PDF files will be input profiles, where we are messing with the output profile, here. | 20:03.36 |
| tkamppeter | chrisl_away, now I see the "if (!cups->user_icc) {" which you have added. I will try this version ... | 20:42.04 |
| | chrisl_away, mvrhel2, I tried now and without "-sOutputICCProfile=..." I get a colored output file (correct) but with "-sOutputICCProfile=/usr/share/ghostscript/9.04/iccprofiles/default_gray.icc" I get still colored output (should be gray). In addition, "-sOutputICCProfile=..." does not complain if the selected profile does not exist, like "-sOutputICCProfile=dfsdfsffsfs". | 20:59.20 |
| chrisl_away | tkamppeter: I see what the problem is: we get subsequent calls to cups_put_params() without the OutputICCProfile setting, so we lose the fact it's been set by the user. It's easy enough to solve, but does mean once the "-sOutputICCProfile=..." is set, it can't be "unset" | 21:11.00 |
| | tkamppeter: here's another http://www.ghostscript.com/~chrisl/gdevcups.c with that modification - since cups doesn't run Ghostscript as a jobserver, it should be fine. | 21:12.17 |
| tkamppeter | I will try. And CUPS indeed does not run GS as a job server, each job is done by a separate instance of GS. | 21:15.22 |
| | I have tried now, the "-sOutputICCProfile=/usr/share/ghostscript/9.04/iccprofiles/default_gray.icc" has no influence at all, and I do not know even whether the file path is correct, as it does not complain when it does not find a file. | 21:20.41 |
| | chrisl_away, ^^ | 21:20.53 |
| | mvrhel2, around? | 21:21.20 |
| chrisl_away | tkamppeter: well, I definitely see a difference - setting the gray profile results in grayscale output, setting color profiles results in color output - I don't know the details of how the ICC profile search path is setup, but I can rely on GS searching, or give an absolute path. | 21:26.01 |
| | tkamppeter: I also get warnings if the profile doesn't exist: ./base/gsicc_manage.c:864: gsicc_open_search(): Could not find /home/cliddell/artifex/ghostpdl/gs/iccprofile/default_.icc ./base/gsicc_manage.c:1108: gsicc_set_device_profile(): cannot find device profile | 21:31.04 |
| | tkamppeter: I need to pick this up in the morning, I'm too tired to do any more right now - can you double check that the build you tested actually had the revision I made (line 3031 should now be: "if (!cups->user_icc) {". You can put any more observations here, and I'll read them in the morning (my time). | 21:41.47 |
| tkamppeter | Sorry, forgot to copy the compiled libgs into place. Now it works for me. | 21:44.37 |
| | chrisl_away, ^^ all OK, will commit it now to the GIT and also issue a new package for Oneiric. | 21:45.31 |
| | chrisl_away, thank you very much for your help! | 21:48.24 |
| chrisl_away | tkamppeter: phew, I was getting worried! I would still like mvrhel2 to review the profile selection, though. | 21:49.03 |
| | tkamppeter: maybe you can catch mvrhel2 before you finish, or we can both yell at him tomorrow ;-) | 21:49.52 |
| | g'night! | 21:49.57 |
| tkamppeter | chrisl_away, good night, sems that mvrhel2 is off today. | 21:56.30 |
| | \ | 22:37.59 |
| | Forward 1 day (to 2011/08/16)>>> | |
IRC Logs