| | <<<Back 1 day (to 2011/07/13) | 2011/07/14 |
| mvrhel2 | henrys: are you around? | 02:30.55 |
| | hmm. a doe and two fawns just walked through the front yard | 03:02.51 |
| henrys | I'm back | 03:07.39 |
| mvrhel2 | oh hi henrys | 03:10.43 |
| | I was going to do some testing on Ray's patch but I got tied up replying to customer 711 | 03:11.05 |
| | do you want me to send you the patch? | 03:11.11 |
| | ray was having trouble having it compile on the cluster. | 03:11.25 |
| | it was working on his machine | 03:11.32 |
| | and on peeves for him | 03:11.36 |
| henrys | the results are here: http://www.ghostscript.com/cgi-bin/clustermonitor.cgi?report=ray | 03:13.24 |
| | it is a link error with gsicc_set_icc_directory undefined. | 03:13.49 |
| mvrhel2 | ah ok | 03:14.01 |
| henrys | it works for you on windows? | 03:14.30 |
| mvrhel2 | windows is forgiving about this sort of thing at times. I have run into this before | 03:14.50 |
| | it somehow finds it even if it is not in the header | 03:15.05 |
| | i find this to be a pain | 03:15.13 |
| | ok. let me do a check out of 9.03, and apply his patch and fix it and then do the push | 03:15.57 |
| | oh I have to go and do something first. | 03:16.07 |
| | bbiab | 03:16.09 |
| henrys | well send me his patch and I'll figure it out. the patch at the url is against head which is confusing. | 03:16.17 |
| marcosw_ | henrys: what's the status of the compiles inits 0 issue? I ran a test this morning and still saw failures. | 03:27.59 |
| | henrys: never mind the previous comment, there was an error in my testing script | 03:32.18 |
| henrys | x11 and some odd devices should still fail but most other devices should be okay. | 03:33.36 |
| mvrhel2 | henrys ok sending you the patch. i hope it is against 9,03 | 03:36.18 |
| | henrys: ok just sent it | 03:37.30 |
| marcosw_ | henrys: the problem I had with my test script is that I'm using "%rom%Resource/Init/gs_cet.ps" for the cet files, which is clearly wrong for the compile inits 0 case. | 03:42.05 |
| mvrhel2 | henrys: looks like he forgot to add gsicc_manage_h in lib.mak for gslibctx.c | 03:44.12 |
| | windows was happy with the #include | 03:44.52 |
| | not sure why it worked on peeves for him | 03:45.07 |
| | henrys: do you want me to see if I can cluster push it? | 03:46.02 |
| | or do you have it | 03:46.10 |
| | bedtime reading. bbiab. | 03:47.21 |
| henrys | that wouldn't cause a link error - missing gsicc_manage.h | 03:47.43 |
| mvrhel2 | it would if it is not defined in lib.mak | 03:50.39 |
| | have to read. brb | 03:50.52 |
| marcosw_ | henrys and mvrhel2: there may be an issue finding icc profiles with compile inits 0, I'm still checking. | 04:05.48 |
| mvrhel2 | ok I am back. | 04:13.05 |
| | marcosw_ this is with ray's patch? | 04:13.14 |
| marcosw_ | possibly not. It's from a06634a969ea9b0db2d0840d8641847247056145 (which is from last night). | 04:14.03 |
| mvrhel2 | oh. yes. there is still an issue. | 04:14.16 |
| | ray was moved the whole icc directory into the lib_ctx to do away with all of this | 04:14.39 |
| | but it his patch has a problem | 04:14.49 |
| | I am going to test it in a bit | 04:15.05 |
| | with a fix | 04:15.08 |
| marcosw_ | I was just writing an email to you documenting the problem, I guess I don't have to send it :-) | 04:15.10 |
| mvrhel2 | sorry about the confusion | 04:15.24 |
| | how do a do a git command line hard reset to the 9.03 tag | 04:15.36 |
| henrys | git checkout ghostpdl-9.03 | 04:15.53 |
| mvrhel2 | ok thanks | 04:15.57 |
| henrys | I see the problem. | 04:16.11 |
| mvrhel2 | oh is it different than what I said | 04:16.23 |
| henrys | yes mkromfs_0 for some reason requires gslibctx.o but he moved the icc function into libctx but didn't add its source module. | 04:17.40 |
| mvrhel2 | oh | 04:18.00 |
| | ok | 04:18.17 |
| henrys | don't see how it could possibly compile on windows. | 04:18.17 |
| | well it should compile but not link. | 04:18.26 |
| mvrhel2 | let me turn off compile inits and try | 04:18.58 |
| henrys | hopefully we won't have a dependency avalanche. | 04:19.00 |
| mvrhel2 | yes | 04:19.06 |
| henrys | it should only fail with compile inits 1 | 04:19.41 |
| mvrhel2 | oh. it builds on windows in that case | 04:19.55 |
| | but that uses gsromfs1.obj | 04:20.27 |
| | I am not even going to pretend to understand how this builds... | 04:20.41 |
| | oh never mind. I had COMPILE_INITS=0 | 04:21.33 |
| | and it built | 04:21.35 |
| | let me try 1 | 04:21.38 |
| henrys | I can fix it but I'd like to understand why windows works. | 04:22.04 |
| | or if it doesn't | 04:22.13 |
| mvrhel2 | please go ahead and do you fix. you do need to add in the dependency in lib.mak | 04:23.04 |
| | I am compiling windows now without your fix. | 04:23.14 |
| | to see if it builds | 04:23.20 |
| henrys | okay | 04:25.34 |
| | we need to do this differently I don't think we want to add all the dependencies gsicc_manage to mkromfs | 04:49.36 |
| | is rayjj here? | 04:50.02 |
| | mvrhel2:I'll send ray email | 04:53.44 |
| mvrhel2 | henrys: so windows built | 04:53.46 |
| | and in linux is built for me | 04:53.51 |
| | s/is/it/ | 04:54.29 |
| henrys | you should have a line like this: | 04:54.29 |
| | gcc -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long int" -I./base -I./obj/ -Izlib ./base/mkromfs.c -o ./obj/aux/mkromfs_0 ./obj/aux/compress.o ./obj/aux/deflate.o ./obj/aux/zutil.o ./obj/aux/adler32.o ./obj/aux/crc32.o ./obj/aux/trees.o ./obj/aux/gscdefs.o | 04:54.31 |
| | ./obj/aux/gsmisc.o ./obj/aux/gpmisc.o ./obj/aux/gslibctx.o ./obj/aux/gp_getnv.o ./obj/aux/gp_unix.o ./obj/aux/gp_unifs.o ./obj/aux/gp_unifn.o ./obj/aux/gp_stdia.o ./obj/aux/gsutil.o ./obj/aux/memento.o -lm -ldl -lm -liconv | 04:54.31 |
| | Undefined symbols: | 04:54.31 |
| | "_gsicc_set_icc_directory", referenced from: | 04:54.34 |
| | _gs_lib_ctx_init in gslibctx.o | 04:54.37 |
| | | 04:54.40 |
| mvrhel2 | let me do a clean build in linux | 04:54.51 |
| | windows I did a clean build and it was OK | 04:55.00 |
| | do you want me to have compile inits 1 or 0 | 04:55.15 |
| henrys | 1 | 04:55.42 |
| mvrhel2 | ray is going to be back a bit late tonight I think | 04:56.55 |
| henrys | I can see from inspection the line above will not link, gslibctx has the new icc function how would it be found without gsicc_manage.o in the list? | 04:58.11 |
| mvrhel2 | henrys: did you add in the dependency into to lib.mak? | 04:58.16 |
| | s/into to/into/ | 04:58.36 |
| henrys | no | 04:59.20 |
| mvrhel2 | oh I added that. I don't think it will link in linux without that | 04:59.35 |
| | oh never mind | 05:00.11 |
| henrys | I can't think why having a header file would matter but I'll try adding it. | 05:00.12 |
| mvrhel2 | I do get the error now | 05:00.15 |
| | exactly where you said | 05:00.22 |
| | after a clean build | 05:00.39 |
| henrys | yea it's unfortunate because gsicc_manage has so many dependencies the mkromfs line would be really large. | 05:01.40 |
| | if it were added. | 05:01.53 |
| mvrhel2 | ok. I think I see what you mean | 05:04.43 |
| | ugh | 05:04.47 |
| | so it is in the mkromfs build where it is building in gslibctx | 05:06.28 |
| | this is getting beyond my level of usefulness | 05:06.53 |
| | brb | 05:06.59 |
| | ok. I am back | 05:31.01 |
| | I wonder if gsicc_set_icc_directory should be ripped out of gsicc_manage.c | 05:34.12 |
| | henrys: there really is no reason that it has to be in there. there really are no dependencies to the icc stuff with these chagnes | 05:35.47 |
| | let me try one thing | 05:37.21 |
| henrys | well I had a second agenda - I don't like libctx being a dependency in the first place, but there are probably simpler solutions. | 05:38.41 |
| mvrhel2 | well I am thinking of just turning gsicc_set_icc_directory into gs_lib_ctx_set_icc_directory and having it in gslibctx.c | 05:39.22 |
| henrys | yup or a separate module for it without deps. | 05:39.48 |
| mvrhel2 | yes that would work too. there is a call to gsicc_set_icc_directory in zusparam.c | 05:40.21 |
| henrys | so you did get it to fail on windows right? | 05:40.37 |
| mvrhel2 | for setting the user param | 05:40.38 |
| | no windows built | 05:40.42 |
| | I don't know why | 05:40.49 |
| | I have run into this sort of thing before though | 05:41.12 |
| | well windows manages to do a link that does not occur on linux | 05:41.24 |
| | s/well/where/ | 05:41.29 |
| henrys | well I don't see libctx on the windows dependency list so it should work. | 05:43.02 |
| | I have no idea why he would need that to build the romfs but I didn't drill into it. | 05:44.18 |
| mvrhel2 | ok. I am checking on moving gsicc_set_icc_directory right now. I will see if that solves the issue | 05:45.51 |
| henrys | okay if there's another one for me to look at let me know, I am going back to see if I can reproduce the memory regression reported by 711 haven't had much luck with that one. I know they aren't upgrading but I'm worried that we've regressed, chris fixed the time problem. | 05:48.20 |
| mvrhel2 | I thought chrisl had fixed that | 05:48.37 |
| | oh sorry I read to slow | 05:48.48 |
| | his was the time issue | 05:48.59 |
| | the extra 1MB could be ICC profile stuff. If you use ps_cmyk.icc as default_cmyk.icc do you see a reduction? | 05:54.14 |
| | henrys ^^ | 05:54.32 |
| henrys | I wanted to look at ram stuff, rom has been analyzed: http://bugs.ghostscript.com/show_bug.cgi?id=692335 | 05:57.55 |
| | granted the profiles may weigh into the ram problems as well, but I want to have a look. | 05:59.16 |
| mvrhel2 | ok. well the icc profile buffer of data is carried around in ram too by littleCMS and by us. I probably need to see about us freeing our copy of the data after we have gotten our profile handle | 05:59.53 |
| | but as a quick check just using ps_cmyk.icc as default_cmyk.icc may make a dent | 06:00.27 |
| | aha. my machine was moving to a crawl due to yet another adobe update | 06:03.29 |
| | ok. trying linux build with my fixes | 06:06.32 |
| | windows build worked (but that means nothing we already learned) | 06:06.43 |
| | I need a faster machine | 06:09.42 |
| | henrys: so that built on linux with compile inits 1 | 06:15.05 |
| | let me see if it runs | 06:15.29 |
| | and it runs | 06:16.10 |
| | let me build with compile inits 0 | 06:16.19 |
| | henrys: is there an easy way to do this or do I need to run ./autogen.sh --disable-compile-inits | 06:17.19 |
| | I will just go ahead and do it that way | 06:17.57 |
| henrys | yes that is the easiest way. | 06:22.23 |
| mvrhel2 | ok that works too | 06:23.51 |
| | so I think we are good | 06:23.54 |
| | let me clusterpush this | 06:24.02 |
| | oh it will test against the master though not against 9.03 but I guess that is OK | 06:24.48 |
| | now to see if I can amend ray's patch | 06:26.21 |
| henrys | you just do git diff and mail it back to him or did you want to commit it now. | 06:28.06 |
| mvrhel2 | well, I have his patch in as a commit locally. I think I can amend that commit with my fixes and then send him a new patch | 06:28.42 |
| | if it does OK on the cluster, I think it should be committed to the 9.03 tag if that is possible. but I will leave that to the git experts | 06:29.27 |
| | it would be nice to have a single patch to apply to that tag | 06:29.54 |
| | which I think I can make | 06:29.59 |
| henrys | we'll talk to chrisl in the morning it is a big change which makes me nervous. | 06:30.25 |
| mvrhel2 | yes | 06:31.47 |
| | there he is now... | 06:31.52 |
| chrisl | morning guys | 06:31.59 |
| mvrhel2 | morning chrisl | 06:32.07 |
| | henrys: ok I locally have an updated patch now | 06:32.28 |
| | let me punt that off to everyone | 06:32.55 |
| henrys | I just pulled the current code and get a compile error: base/gs.mak:434: *** multiple target patterns. Stop. | 06:33.05 |
| chrisl | henrys: current master? | 06:33.40 |
| henrys | yes | 06:33.49 |
| mvrhel2 | when could that have happened? | 06:35.16 |
| chrisl | henrys: what platform? Linux seems okay..... | 06:35.32 |
| henrys | macpro | 06:35.37 |
| chrisl | Oh, maybe the Luratech changes? Did you rerun autogen.sh? | 06:36.23 |
| mvrhel2 | chrisl. so we may have a fix for the icc directory stuff. it is a fairly big change for being right before a release. | 06:36.51 |
| | I am running a cluster test now. | 06:36.56 |
| | on my linux machine here it ran fine with and without compile inits to the X11 device | 06:37.14 |
| | I am going to email you the patch | 06:37.25 |
| henrys | yes I did, I could have a toolchain problem also - I had some problems with the mac today | 06:37.37 |
| chrisl | mvrhel2: yes, I'm not entirely happy with it (Ray seemed a bit nervous, too), but we have a customer expecting it :-( | 06:38.21 |
| mvrhel2 | yes | 06:38.29 |
| | really it simplifies things dramatically | 06:38.43 |
| | so we are getting away from something that was getting rube goldberg like | 06:39.08 |
| | or at least it had that feel to me | 06:39.17 |
| chrisl | It felt that way to me, too. I'm not saying it's not a good solution, but it's a lot to pack in the day of/before a release, even for just one customer...... | 06:40.13 |
| mvrhel2 | yes | 06:40.24 |
| chrisl | henrys: I can't see anything at that point in gs.mak that springs out as possibly being affected by the Luratech changes. BUT I couldn't test it on Mac (my G4 Mac MIni is waiting on a replacement HDD being fitted) - I meant to ask you to try it, but forgot. | 06:42.04 |
| mvrhel2 | chrisl: ok just sent you the email (and cc'd tech so that everyone can beat on it a bit) | 06:42.34 |
| henrys | seems to be a problem only on the mac server - my mac laptop is fine. I'll look at it tomorrow. | 06:43.02 |
| chrisl | henrys: Okay, that's good (from my POV, less so from yours) | 06:43.27 |
| mvrhel2 | huh my cluster push did not run | 06:43.43 |
| | wtf | 06:43.55 |
| | crap xps did not build | 06:44.28 |
| | ugh. | 06:44.46 |
| | all the stuff in the other languages | 06:44.53 |
| chrisl | mvrhel2: try doing your clusterpush from the ghostpdl directory, rather than the ghostpdl/gs directory? | 06:45.05 |
| mvrhel2 | well the problem is some of the things ray ripped out were used by the other languages. | 06:46.00 |
| chrisl | Oops :-( | 06:46.15 |
| mvrhel2 | they all need to set up the directory in the lib_ctx too | 06:46.16 |
| | henrys: I am not going to be able to fix this tonight | 06:46.30 |
| chrisl | henrys: the customer only wants Ghostscript, right? | 06:47.25 |
| mvrhel2 | basically where gsicc_sync_iccdir and gsicc_init_device_profile_struct occur we need to replace with | 06:47.26 |
| | gs_lib_ctx_set_icc_directory | 06:47.42 |
| | ah. hi ray_laptop: | 06:47.57 |
| chrisl | mvrhel2: the good news (such as it is) is that the patch applies cleanly to the 9.03 branch. | 06:48.30 |
| henrys | let's deal with this tomorrow. I've had enough. | 06:48.38 |
| mvrhel2 | I sent you an updated patch that fixed the issues we were having, but I just discovered that we need to have the other languages do the properly to the initialization. | 06:48.45 |
| | let me see if I can do that real quick | 06:48.51 |
| | maybe it wont be too bad | 06:49.00 |
| | quick question for ray_laptop or henrys | 06:50.28 |
| | gs_lib_ctx_init is already run by the other languages yes? | 06:50.43 |
| | so actually this should be real easy | 06:50.53 |
| | just need to get rid of gsicc_sync_iccdir in the other languages | 06:51.30 |
| | ok let me try another patch to you chrisl | 06:52.36 |
| | and another clusterpush | 06:52.42 |
| | after I make sure gxps builds | 06:52.55 |
| henrys | mvrhel2:yes the other languages have to run that ASFAIK | 06:53.46 |
| mvrhel2 | ok should have this fixed shortly | 06:54.00 |
| henrys | going to bed see you in the morning! | 06:55.40 |
| mvrhel2 | good night | 06:56.05 |
| ray_laptop | g'nite mvrhel2 | 06:56.53 |
| | mvrhel2: thanks for finding the missing dependency | 06:57.17 |
| mvrhel2 | ha I am not off to bed yet | 06:58.13 |
| | I was saying good night to henrys | 06:58.19 |
| ray_laptop | I've had more time to think on it, and I like the lib_ctx method better than the previous approach | 06:58.31 |
| mvrhel2 | 2 minutes before my computer turns into a pumpkin | 06:58.43 |
| ray_laptop | mvrhel2: did you move the set_icc_dir into gslibctx.c ? | 06:58.52 |
| mvrhel2 | yes | 06:58.59 |
| | ok gxps builds now | 06:59.07 |
| | pushing again | 06:59.10 |
| ray_laptop | I haven't checked email -- did you send me a patch back ? | 06:59.17 |
| mvrhel2 | yes. but I am creating yet another one now | 06:59.26 |
| | that will let pcl and xps build | 06:59.36 |
| ray_laptop | mvrhel2: so do you want to finish it in the AM, then ? | 06:59.50 |
| mvrhel2 | well I just pushed let me make the new patch and mail it out. maybe chrisl can beat on it a bit during his day | 07:00.22 |
| | chrisl :) | 07:00.28 |
| ray_laptop | after we have a chance to look at the regression runs and all discuss it one last time ? | 07:00.29 |
| mvrhel2 | yes that makes sense | 07:00.52 |
| | I want to see the regression at least kick off | 07:01.00 |
| | it didnt build last push due to the pcl xps issue | 07:01.11 |
| ray_laptop | I'll be up early then. Sleep well, mvrhel2 | 07:01.12 |
| mvrhel2 | ok. tty tomorrow | 07:01.32 |
| | ok mailing out another patch | 07:03.31 |
| | looks like it is building this time | 07:05.05 |
| | uhoh. two machines idle... | 07:06.37 |
| | grrrr | 07:07.32 |
| | chrisl: are you there? | 07:07.53 |
| | that is weird. why would the cluster get an abort command | 07:08.59 |
| chrisl | mvrhel2: yes, I'm here | 07:09.13 |
| mvrhel2 | ok I am mailing the patch. If you can clusterpush it chrisl that would be great | 07:09.19 |
| chrisl | Sure, no problem | 07:09.29 |
| mvrhel2 | I am falling asleep here | 07:09.31 |
| | thanks | 07:09.32 |
| chrisl | mvrhel2: okay, I've got the patch - now you can push off to bed! | 07:10.18 |
| ray_laptop | thanks chrisl | 07:10.26 |
| mvrhel2 | looks like my cluster push is restarting for some reason | 07:10.35 |
| | anyway I leave it all in your capable hands | 07:10.44 |
| | good night | 07:10.48 |
| chrisl | good night! | 07:11.09 |
| ray_laptop | aborting again !!! | 07:12.31 |
| | interesting. i7 went from 'DOWN' to 'Abort command received' | 07:13.41 |
| chrisl | Grrr, does Windows Update reset its own settings? I *know* I stopped it installing updates automatically, and its gone back to doing that - BAD OS, that's naughty! | 07:13.53 |
| | ray_laptop: I'm doing ghostpdl and ghostscript builds now, once they build, I'll do a clusterpush | 07:14.49 |
| ray_laptop | chrisl: it is a pain if it does that, but I haven't seen it automatically do updates for the past couple of weeks (even tho' it's bugging me to update) | 07:15.03 |
| | chrisl: on Windows or on linux ? (and with COMPILE_INITS=0 ?) | 07:15.53 |
| chrisl | Linux, currently COMPILE_INITS=1 | 07:16.16 |
| | undefined reference to gsicc_sync_iccdir in psitop.c | 07:16.54 |
| ray_laptop | going to apply mvrhel's latest patch to peeves | 07:17.12 |
| | chrisl: I'll load michael's patch and fix that. | 07:17.37 |
| chrisl | it looks like a simple oversight. | 07:18.07 |
| ray_laptop | grrr... Windows is giving me Patch format detection failed. | 07:20.07 |
| | do I need any options to git am ??? | 07:20.19 |
| | oh,, I forgot to run the patch into stdin. | 07:21.19 |
| chrisl | ray_laptop: git apply <patch> worked for me | 07:21.51 |
| | ray_laptop: it looks to me like it just needs the call to gsicc_sync_iccdir() deleted from psitop.c:ps_impl_set_device() | 07:23.09 |
| ray_laptop | chrisl: I've done that. Just to get us on the same page, I'll go ahead and push it (once it builds on Windows) | 07:24.05 |
| | it's easier than passing patches around, unless you want to do it that way | 07:24.24 |
| chrisl | ray_laptop: that's fine with me. | 07:25.14 |
| ray_laptop | building ... | 07:26.38 |
| chrisl | ray_laptop: these changes will go onto the master branch, won't they? | 07:27.34 |
| ray_laptop | chrisl: we'll discuss that tomorrow. They won't go in directly since there will be some conflict with the tagfix changes in the master branch | 07:28.52 |
| | chrisl: for now we just wanted to get them into 9.03 | 07:29.08 |
| chrisl | ray_laptop: okay, fine. It just makes a difference to how I'll deal with it (normally, I'd prefer to have the changes on master, and cherry-pick them onto the branch). | 07:29.58 |
| ray_laptop | chrisl: we'll let cust 850 be our beta tester for the approach ;-) | 07:34.10 |
| chrisl | ray_laptop: very fair! If it all goes horribly wrong, it might make them think twice before forcing us into an unscheduled release........ | 07:36.05 |
| ray_laptop | chrisl: OK. I pushed on to the 9.03 branch. Please check to make sure that it has the psitop.c change in it -- my local 'status' is giving me confusing messages about it | 08:07.05 |
| | chrisl: it built for me on Windows and linux | 08:07.28 |
| chrisl | ray_laptop: okay, will do. | 08:08.30 |
| ray_laptop | chrisl: what are you running on the cluster ? | 08:09.05 |
| chrisl | ray_laptop: same as you | 08:09.23 |
| ray_laptop | (probably the same thing as I am -- the patched code with the psitop fix | 08:09.31 |
| chrisl | ray_laptop: the only thing with your change is that you've left the return value check in after removing the function call - it is benign, if a little confusing | 08:11.35 |
| ray_laptop | hmm... i spotted that and took it out (but maybe that's the confusing status message) | 08:12.23 |
| chrisl | well, it won't affect the clusterpush. | 08:13.07 |
| ray_laptop | strange.. it's back in. I'll remove it and try to amend the previous commit (wish me luck) | 08:13.30 |
| kens | ping chrisl | 08:16.39 |
| chrisl | pong kens | 08:17.04 |
| kens | An interesting new wrinkle with teh CIDFont substitution business | 08:17.18 |
| | Since Alex changed the PDF interpreter to run in a 'stopped' context, we no longer get an error when a CIDFont is missing | 08:17.47 |
| | Or more accutately, we generate the error, but the interpreter carries on with the next content stream (if any) | 08:18.06 |
| chrisl | Yeh, I know, it confused me a bit. Maybe that should be one of the exceptions? | 08:18.20 |
| kens | And does not exit with an error, contrary to the warning message | 08:18.23 |
| | Are there exceptions ? | 08:18.34 |
| chrisl | I believe so. I can check at some point..... | 08:18.56 |
| kens | I think that would be good. | 08:19.05 |
| chrisl | Or it may be a command line option, that reinstates the old behaviour - not sure | 08:19.39 |
| kens | Also, promtped by Ray's commit erlier, the error message outght to have a flush to prevent i being split by other messages. | 08:19.40 |
| | The error message is in pdf_font.ps in findCIDFont | 08:20.48 |
| | In fact I think all the 'print' strings ought to be flushed in that routine. | 08:21.20 |
| chrisl | Yep, I agree | 08:22.04 |
| ray_laptop | kens: I think pdfformaterror _does_ flush output | 08:22.11 |
| kens | One thing I was thining was to leave the behaviour alone and change the message to say 'some text may not render correctly' | 08:22.12 |
| | ray_laptop : it doesn't use that. | 08:22.22 |
| ray_laptop | kens: Oh, I wasn't sure. Most of the pdf interp warnings use that | 08:22.42 |
| kens | ray_laptop : its not the PDF itnerpreter, its the CIDFont substitution code | 08:23.00 |
| | chrisl some people might be happier with getting 'something' out than getting an error. At least until they realise much of their file doesn't work. | 08:23.50 |
| ray_laptop | kens: I see. I agree that error messages should flush. I don't think Alex will mind if you any of those you stumble across | 08:24.03 |
| kens | The loon I've been dealing with on comp.text.pdf would have been happy. | 08:24.11 |
| | ray_laptop : its Chris's area this one, which is why I'm not doing it myself ;-) I'm interested in whether having the CIDFont jump out and carry on, or stop with an error, is more desirable. | 08:24.58 |
| chrisl | kens: it's not exceptions to using stopped, but a flag to return to the old behaviour: PDFSTOPONERROR | 08:25.19 |
| kens | chrisl then I would change teh error message in the CID font code to say something other than 'will exit with error'. | 08:26.00 |
| | Also makes the question of whether this is better rather moot. | 08:26.32 |
| chrisl | I think issue a (stern) warning and carry on is a close equivalent of what Acrobat will do | 08:26.34 |
| kens | Agreed, which is why I eas mentioning it. Of course it will still abort the content stream, but *something* will come out (even if its just a blank page) | 08:27.00 |
| | But in that case the message should be modified. | 08:27.13 |
| chrisl | Okay, I'll update the file............. | 08:27.17 |
| ray_laptop | chrisl: looks like it ran OK. I'll leave warning cleanups to you (if you want). It is just a branch. | 08:27.24 |
| kens | Problem is the behaviour with PS and PDF is now different (PS will still error) so careful phrasing may be required. :-) | 08:27.42 |
| ray_laptop | chrisl: can you test COMPILE_INITS=0 with x11aplha on linux | 08:27.52 |
| | now I am really off to sleep... | 08:28.29 |
| kens | Night Ray | 08:28.36 |
| chrisl | ray_laptop: quick test with x11alpha shows it works - and good night! | 08:30.04 |
| | kens: I don't think it needs *that* careful phrasing. Errors and warnings are only relevant to the current job. I'm certainly not going into lengthy explanation of the thing in a warning message! | 08:31.26 |
| kens | Not lengthy explanations, no, but it won't exit in PDF any more. | 08:31.55 |
| chrisl | kens: so, if PDFSTOPONERROR is true, then the message stays the same | 08:35.20 |
| | If it's not true is will say: "Will continue, but content may be missing." | 08:36.00 |
| kens | I was thinking of repahrsing the error to say something like 'Interpreter may exit wirth error, some content will be missing form the output' | 08:36.02 |
| | PostScript may or may not continue, and the CIDFonts code is used there too. | 08:36.34 |
| chrisl | This doesn't affect Postscript | 08:37.03 |
| kens | Missing CIDFonts ? | 08:37.21 |
| chrisl | the code in pdf_font.ps is for PDF files | 08:37.51 |
| kens | Oh fine, in that case your text is better. | 08:38.05 |
| chrisl | The Postscript case, I don't *think* has the same fallback logic in it. | 08:39.19 |
| kens | OK, I thought it did, but its much less relevant there. | 08:39.43 |
| chrisl | I think I found that the Postscript case is more conservative, but I only glanced at it. | 08:40.56 |
| kens | OK, its more important for the PDF itnerpreter anyway | 08:41.08 |
| chrisl | Now I need to remember a job that bounces of the missing CIDFont code........ | 08:50.01 |
| kens | I can sen dyou one if you like. | 08:50.13 |
| | Or you can send me a patch | 08:50.18 |
| chrisl | kens: thanks, I should have plenty, but it's remember the file name.... I'll let you know | 08:51.33 |
| kens | OK | 08:51.38 |
| chrisl | kens: I give up, can you mail me a test file, please? | 08:54.14 |
| kens | :-) | 08:54.19 |
| | On its way I'm afraid its 500Kb | 08:54.49 |
| | OK, gone | 08:55.01 |
| chrisl | Ta | 08:55.09 |
| kens | chrisl can you give me the new error message when you're happy please ? I can add it to the FAQ entry I'm about to send round. | 08:56.44 |
| chrisl | If you use PDFSTOPONERROR it will still say: "The substitute CID font "xxxx-yyyy" is not provided either. Will exit with error." | 08:59.47 |
| kens | OK, and if not ? | 09:00.02 |
| chrisl | it will say: "The substitute CID font "xxxx-yyyy" is not provided either. Will continue, but content may be missing." | 09:00.38 |
| kens | Great, thanks. | 09:00.47 |
| Robin_Watts | tor8: you here | 11:27.54 |
| | ? | 11:27.56 |
| tor8 | Robin_Watts: yes. just read your patch. | 11:28.13 |
| Robin_Watts | I have an idea for doing knockout. | 11:28.25 |
| | basically to do knockout, we need to push/pop a group around EVERY item in the group. | 11:28.56 |
| tor8 | doesn't knockout involve two alpha channels? (much like the shape pixmap you added for non-isolated) | 11:29.14 |
| Robin_Watts | does it ? | 11:29.59 |
| | My gut feeling was that we could do it with a reuse of stuff we already had. | 11:30.12 |
| tor8 | I read somewhere about making a distinction between shape and opacity alphas | 11:30.21 |
| Robin_Watts | but I don't want to have to alter every single drawing op. | 11:30.33 |
| tor8 | but reading about this stuff generally knocks me out (sorry, bad pun) | 11:30.36 |
| Robin_Watts | so I had the idea of adding new entrypoints to the device interface. | 11:30.51 |
| | 'preobject' and 'postobject'. | 11:31.00 |
| | Which would do nothing except in the knockout case when it would push/pop the extra group. | 11:31.41 |
| tor8 | hmm, is this for the fill-then-stroke drawing modes? | 11:32.27 |
| Robin_Watts | no, it's for knockout. | 11:32.41 |
| | To do a non-isolated knockout group, I reckon we do an isolated group as normal. | 11:33.02 |
| | Call that group A. THEN, before every object in group A, we push another non-isolated group B which copies the original background in (not the background from group A). | 11:34.22 |
| | then we draw the object, then we blend that back to group A. | 11:34.34 |
| | Thus every object 'knocks out' the previous ones. | 11:34.47 |
| tor8 | right. don't you need to store the opacity alpha for each object in a mask (separate from the shape mask) as well? | 11:36.54 |
| Robin_Watts | tor8: sorry, had to step away. | 11:46.04 |
| | by pushing the second non-isolated group, we end up with 2 shapes. | 11:46.19 |
| | 1 for the group as a whole, 1 for the individual objects. | 11:46.32 |
| | http://ghostscript.com/~robin/Isolation2.pdf | 11:47.53 |
| | I updated the test file to show knockout too. | 11:48.11 |
| henrys | kens:did I miss a reply from marcos to Tom, seems like it should have been answered right away? | 15:13.02 |
| | hi tkamppeter - getting ready for your release? | 15:16.31 |
| kens | henrys, sorry, wasn't paying attention. I don't believe there has been a reply to Tom | 15:17.03 |
| | I did post on IRC last nigh, but you'd gone off to get something to eat I think. | 15:17.18 |
| tkamppeter | henrys, do you mean the Feature Freeze of Oneiric mid-August? | 15:17.19 |
| kens | henrys, I think it needs marcos to reply, since he's trying to battle with Adobe. | 15:17.51 |
| henrys | tkamppeter:yes I assumed it would get very busy just before the freeze. | 15:18.44 |
| | kens:agreed, I'll nag | 15:20.27 |
| kens | Thanks. | 15:20.32 |
| mvrhel2 | good morning | 15:30.48 |
| kens | Morning michael | 15:31.00 |
| mvrhel2 | chrisl: so it looks like you got things working | 15:34.31 |
| chrisl | mvrhel2: oh, good morning! Yes, Ray was a bit late and we got there. | 15:35.04 |
| mvrhel2 | great | 15:35.12 |
| henrys | so the fix is just on 9.03? | 15:35.37 |
| mvrhel2 | I think for now it is, but I think we should go ahead and put it in the master. | 15:36.03 |
| chrisl | henrys: for now. Ray wanted to discuss whether this was "the fix", or whether another bright idea would be better long term. | 15:36.23 |
| henrys | but it was cluster pushed locally right? | 15:37.04 |
| mvrhel2 | It is a variable that really should not be changing but set one time during startup so having it in lib_ctx is not the end of the world to me | 15:37.18 |
| | unlike the graphic tag object which changes with every object.... | 15:37.30 |
| chrisl | henrys: yes, several times now. | 15:37.45 |
| | mvrhel2: So I've run a couple of files through every device in the default Unix build, there are a couple of crashes (due to bad configuration) but none that I've seen are regressions with the ICC stuff. | 15:38.21 |
| mvrhel2 | ok. I want to double check that setting the ICCDir to something different works too | 15:38.45 |
| henrys | mvrhel2:just a nit but it seems like we would have caught this early and perhaps future problems if we didn't have a "default", in this case it looks like having a default is more likely to mask problems than provide robustness. | 15:39.38 |
| mvrhel2 | a default value for the directory you mean? | 15:40.12 |
| chrisl | I think, before the scheduled release, I will try to run a larger selection of files through every device. | 15:40.23 |
| mvrhel2 | chrisl: has the patch been applied to a 9.03 branch in the master? | 15:41.25 |
| henrys | mvrhel2:yes. | 15:41.26 |
| chrisl | mvrhel2: it's up on casper, yes. | 15:42.03 |
| henrys | and if there is a default it shouldn't be "%rom", it should be like the other resources - but that is a minor point. | 15:42.33 |
| mvrhel2 | henrys: ok. I think part of the problem was that when I started the project I didn't quite understand how gs found its resources. | 15:44.03 |
| chrisl | mvrhel2: and you do now? It still confuses the hell out of me at times! | 15:44.37 |
| mvrhel2 | I didnt say that ;) | 15:44.48 |
| chrisl | :-) | 15:44.53 |
| henrys | chrisl:yes a baffling mess AFAICT | 15:45.13 |
| ray_laptop | morning, all | 15:45.55 |
| kens | Hi ray | 15:46.07 |
| mvrhel2 | good morning ray_laptop | 15:46.18 |
| ray_laptop | chrisl: thanks for banging on 9.03. Did you try with and without %rom% (COMPILE_INITS=0 and 1) ? | 15:46.49 |
| chrisl | ray_laptop: I've done both, but mostly COMPILE_INITS=0 - I figure with the rom file system, it gets the most use anyway. | 15:47.38 |
| henrys | chrisl:the bbox and x11 device were problems before. | 15:48.34 |
| ray_laptop | chrisl: well, we should make sure that when COMPILE_INITS=1 that we can set an explicit directory using -sICCProfilesDir=___ | 15:48.43 |
| chrisl | henrys: I tested *all* devices in the default Linux build, in a limited fashion. | 15:49.12 |
| ray_laptop | henrys: the x11 and bbox worked for me with COMPILE_INITS=0 | 15:49.24 |
| henrys | great | 15:49.35 |
| mvrhel2 | ray_laptop: I was just about to test that | 15:49.48 |
| | at least on windows | 15:50.07 |
| chrisl | mvrhel2: oh, good, if you don't mind doing that - you'll be better able to tell if the results are as expected. | 15:50.23 |
| henrys | ray_laptop:I did want to follow up on this dependency list for mkromfs on unix vs windows that broke the original patch. Why are those dependencies needed? | 15:50.49 |
| mvrhel2 | I have some funky profiles I will specify in another directory to see if it works | 15:51.00 |
| ray_laptop | henrys: which ones ? | 15:51.31 |
| henrys | ray_laptop:I sent mail last night - of course it could have rejected as spam. | 15:52.05 |
| | but libctx is a dependency on unix and not on windows for mkromfs | 15:52.26 |
| ray_laptop | henrys: BTW, if the dependencies that caused the breakage were for mkromfs, that would explain why I was able to build on peeves. Since I was interested in fixing COMPILE_INITS=0, I built with --disable-compile-inits | 15:53.00 |
| henrys | ray_laptop:I sent mail to that effect last night did you get it? | 15:53.23 |
| ray_laptop | henrys: I got the email, but it didn't say what makefile the dependency came from | 15:53.54 |
| henrys | oh I thought the spam thing bit me again. | 15:54.33 |
| | in unix-aux | 15:54.44 |
| ray_laptop | henrys: thanks | 15:54.50 |
| | why the heck is memento on the MKROMFS_OBJ list ? (a side issue) | 15:56.02 |
| henrys | I guess so you can test mkromfs.exe | 15:56.33 |
| ray_laptop | it only seems to be on MKROMFS_OBJS_0 | 15:56.54 |
| tkamppeter | henrys, what I am currently doing is to package a current snapshot of 9.03. | 15:57.39 |
| chrisl | ray_laptop: it wouldn't make sense to use memento on a build which uses shared library. | 15:57.53 |
| | tkamppeter: what's the date of the pending feature freeze? | 15:58.22 |
| henrys | mvrhel2:so configuring to use the simple profiles seems a bit hokey to me. Shouldn't there be some configuration option for it? | 15:58.32 |
| mvrhel2 | henrys: we could do that. | 15:58.58 |
| Robin_Watts | ray_laptop: Because if you do a memento build, you have -DMEMENTO defined, and that causes mkromfs to want memento. | 15:59.10 |
| mvrhel2 | henrys: hold on one sec | 15:59.35 |
| | chrisl: so setting the directory when compile_inits =1 works fine | 16:01.08 |
| | it found and used a funky profile that I had | 16:01.19 |
| henrys | wonders how exactly to advise the customer to use the simple profiles and copy them over the complex ones seems like we haven't thought the problem much. | 16:01.27 |
| mvrhel2 | henrys: ok now about that | 16:01.40 |
| ray_laptop | henrys: on the subject of libctx, it looks like gputil.c includes gs_next_ids and gp_unifs.c uses string_match | 16:01.49 |
| chrisl | mvrhel2: excellent, thanks for testing that. | 16:02.02 |
| mvrhel2 | having the icc dir in the libctx makes a lot of sense. should have done that long ago | 16:02.46 |
| ray_laptop | chrisl: mvrhel2: henrys: So we are OK with shipping 9.03 ? | 16:02.52 |
| mvrhel2 | I am fine with it | 16:03.01 |
| ray_laptop | for the record I am, too | 16:03.10 |
| henrys | I'm good I think the customer penny wise and pound foolish - but whatever. | 16:03.24 |
| chrisl | I'm as happy with it as I can be, given the circumstances. | 16:03.45 |
| | ray_laptop, henrys: But I won't have to time to get the release done tonight. | 16:04.32 |
| mvrhel2 | henrys: so we could readily have a compile time option that sets a different set of defaults for the default profiles in gsicc_manage.h | 16:05.03 |
| | in the normal case it uses the ones that match adobe | 16:05.19 |
| | which we have now | 16:05.22 |
| | or we have a small ram option which uses the ps ones I made | 16:05.41 |
| | to leave them out of the ROMFS would require someone to do some work in the code that builds that | 16:06.12 |
| | right now it grabs everything in that directory | 16:06.27 |
| | henrys: is that what you are thinking? | 16:06.57 |
| | ah, the only problem is these names are also in gs_lev2.ps | 16:08.08 |
| | crap | 16:08.11 |
| | see gs_leve2.ps line 655 | 16:08.24 |
| henrys | I think we should have an option that says "USE_SMALL_PROFILES" and everything should just work without any manual changes. | 16:08.51 |
| | oh a problem. | 16:09.00 |
| mvrhel2 | henrys: you mean a command line option? | 16:09.13 |
| henrys | no compile time. | 16:09.24 |
| kens | Time for me to head off, see you all tomorrow | 16:09.28 |
| henrys | bye kens | 16:09.41 |
| mvrhel2 | bye kens | 16:09.44 |
| ray_laptop | having the -P directory (source directory) for the mkromfs command line should be doable for USE_SMALL_PROFILES. The destination directory can be the same | 16:10.03 |
| henrys | for a first round USE_SMALL_PROFILES could only affect romfs? | 16:10.52 |
| mvrhel2 | USE_SMALL_PROFILES would be doable on the c side to set the defaults there but I am not sure what do to with the PS interpreters hardcoding of the profile names | 16:11.09 |
| ray_laptop | We just take out of lib.mak: -P $(GLSRCDIR)$(D)..$(D) iccprofiles$(D)* and replace it with a variable | 16:12.08 |
| mvrhel2 | any thoughts about the interpreter? | 16:13.29 |
| henrys | I haven't looked at the code recently but you have to change the filenames right? | 16:13.30 |
| Robin_Watts | Why does the USE_SMALL_PROFILES option have to change the filenames ? | 16:13.53 |
| ray_laptop | mvrhel2: the small profiles can have the same names, but live in a different directory, right | 16:13.54 |
| Robin_Watts | right, so it's a pure mkromfs thing ? | 16:14.07 |
| henrys | yes if you permanently changed the names so they match the hardwired ones and put the in a different directory that would work. | 16:14.41 |
| mvrhel2 | I was thinking that we just have a different DEFAULT_GRAY_ICC, DEFAULT_RGB_ICC and DEFAULT_CMYK_ICC in gsicc_manage used if USE_SMALL_PROFILES is set | 16:14.43 |
| Robin_Watts | mvrhel2: Right, different profiles, but in the ROM filing system with the same names. | 16:15.11 |
| mvrhel2 | but the ps stuff bothers me | 16:15.14 |
| ray_laptop | if they are in a separate directory, then it will work for COMPILE_INITS=0 by changing the default ICCProfilesDir (e.g. from iccprofiles/ to iccprofiles.ps/) | 16:15.18 |
| Robin_Watts | iccprofiles.small | 16:15.33 |
| mvrhel2 | no the ROMFS would not need them as far as the c code is concerned | 16:15.34 |
| | ie we would have #define DEFAULT_CMYK_ICC "ps_cmyk.icc" | 16:16.05 |
| ray_laptop | mvrhel2: why don't we need to change the romfs case ? | 16:16.06 |
| Robin_Watts | mvrhel2: Why change the filenames at all? | 16:16.21 |
| mvrhel2 | and we would not include default_cmyk.icc in the ROMFS | 16:16.24 |
| | it would not be needed | 16:16.30 |
| ray_laptop | mvrhel2: I like the idea of the same names and different directories | 16:16.31 |
| henrys | mvhrel2:in large profile mode you need all the profiles right? so that is somewhat confusing. | 16:16.33 |
| mvrhel2 | yes | 16:16.39 |
| | depends upon if you like have multiple copies of the same object in your ROMFS | 16:17.21 |
| ray_laptop | mvrhel2: why doesn't romfs need the ps_cmyk.icc -- are you going to pickle it into the source without romfs ? | 16:17.27 |
| mvrhel2 | they are already in the romfs | 16:17.39 |
| | they have to be in there | 16:17.45 |
| | for soft mask rendering | 16:17.53 |
| ray_laptop | there is NO romfs when COMPILE_INITS=0 | 16:18.01 |
| Robin_Watts | romfs can presumably cope (or be made to cope) with the same object being in there with different names (but only being represented once) | 16:18.03 |
| mvrhel2 | ray_laptop; sorry misread your statement | 16:18.15 |
| Robin_Watts | but (as ray says) that doesn't help with compile_inits=0 | 16:18.17 |
| ray_laptop | romfs won't care | 16:18.18 |
| mvrhel2 | without romfs, nothing is pickeled in the source | 16:18.34 |
| | lets back up for a second | 16:18.59 |
| | and talk about only compile_inits = 1 | 16:19.13 |
| ray_laptop | if we put the small profiles in iccprofiles/small/ | 16:19.19 |
| mvrhel2 | ps_gray.icc, ps_rgb.icc, ps_cmyk.icc are always needed for softmask rendering | 16:19.57 |
| ray_laptop | and label them default_rgb.icc then the softmask code can look for iccprofiles/small/default_rgb.icc | 16:20.03 |
| mvrhel2 | they could also be used for the defaults when USE_SMALL_PROFILES is set | 16:20.20 |
| | so, I was saying that if USE_SMALL_PROFILES was set, and compile_inits was 1, we should not have any "default" profiles in the romfs | 16:20.57 |
| | rather the code should just use ps_gray etc as the defaults | 16:21.20 |
| | if compile inits was 0, it should also, just use ps_gray etc as the defaults | 16:21.39 |
| ray_laptop | mvrhel2: mkromfs can cope with populating the %rom%iccprofiles/ from iccprofiles/small/* | 16:21.59 |
| mvrhel2 | ray_laptop: so I am a bit confused though. are you wanting to have 2 copies of ps_gray etc? | 16:22.53 |
| | in the romfs? | 16:22.58 |
| | one called ps_gray.icc and one called default_gray.icc? | 16:23.19 |
| ray_laptop | mvrhel2: no, two copies of default_rgb.icc (no ps_ names) | 16:23.24 |
| mvrhel2 | even though they would be the same profile | 16:23.32 |
| | now I am very confused | 16:23.38 |
| henrys | chrisl:my time max memory feature just returns 0 on linux I guess it isn't fully supported on all platforms. | 16:23.44 |
| mvrhel2 | which is nothing new | 16:24.08 |
| ray_laptop | when we USE_SMALL_PROFILES the %rom%iccprofiles/ would get filled with the profiles (named default_*.icc) from the iccprofiles/small/ directory | 16:24.34 |
| chrisl | henrys: odd. Try running without options, you should get a memory use summary on the default output. | 16:24.40 |
| henrys | actually minor page faults / 4096 seems close | 16:25.23 |
| mvrhel2 | ray_laptop: so the romfs which already has ps_gray, ps_rgb will also have profiles that came from this small directory which will probably contain the profiles ps_gray etc but with different names | 16:25.26 |
| ray_laptop | mvrhel2: there won't be ANY ps_*.icc anymore | 16:25.53 |
| mvrhel2 | oh but they are needed for softmask rendering | 16:26.05 |
| | even right now | 16:26.11 |
| | when we render internally in a softmask we have to use these profiles | 16:26.26 |
| | so they are always there | 16:26.36 |
| | in the romfs | 16:26.41 |
| ray_laptop | mvrhel2: when USE_SMALL_PROFILES=0 (the default) we populate %rom%iccprofiles/* and %rom%iccprofiles/small/* | 16:26.58 |
| | the small profiles only live in %rom%iccprofiles/small/ | 16:27.22 |
| mvrhel2 | ok. I am still confused. let take the case of USE_SMALL_PROFILES=0 | 16:27.52 |
| | in that case, the romfs would contain everything it has now | 16:28.06 |
| | which includes the ps_gray, ps_rgb, ps_cmyk, lab, default_gray, default_rgb, default_cmky | 16:28.26 |
| ray_laptop | and the softmask logic can search for "small/default_rgb.icc" (the %rom%iccprofiles/ will come from the icc directory default) | 16:28.38 |
| tkamppeter | henrys, I get | 16:28.46 |
| | No rule to make target `src/jerror.h', needed by `soobj/sjpegc.o' | 16:28.50 |
| mvrhel2 | I was saying that when we have USE_SMALL_PROFILES=1 romfs would only have | 16:28.59 |
| | ps_gray, ps_rgb, ps_cmyk, lab | 16:29.06 |
| | no defaults | 16:29.09 |
| tkamppeter | is there some new dependency in 9.03? | 16:29.13 |
| mvrhel2 | as the code will use the ps_* for defaults | 16:29.24 |
| ray_laptop | mvrhel2: NO. there is no longer any ps_rgb.icc (the file is renamed to default_rgb.icc and moved by us into small/default_rgb.icc) | 16:29.38 |
| mvrhel2 | how will softmasks work? | 16:29.48 |
| henrys | tkamppeter:chrisl is probably the one to talk to - are you using shared libs? | 16:29.52 |
| mvrhel2 | they need the ps_rgb, ps_gray, ps_cmyk profiles | 16:30.02 |
| ray_laptop | we are NOT doing this for 9.03 (we are discussing 9.04 or later) | 16:30.04 |
| | mvrhel2: they need the contents. It doesn't matter what they are called | 16:30.25 |
| tkamppeter | henrys, I am using system libs as far as possible. | 16:30.36 |
| | chrisl, hi | 16:30.44 |
| mvrhel2 | so I will need to change the transparency code to be dependent upon USE_SMALL_PROFILES | 16:30.54 |
| ray_laptop | there isn't going to be a 9.03 GPL release, right ? | 16:31.02 |
| henrys | no | 16:31.14 |
| mvrhel2 | I guess that takes interpreter out of the problem | 16:31.23 |
| henrys | no 9.03 GPL | 16:31.24 |
| ray_laptop | mvrhel2: that was the goal | 16:31.38 |
| tkamppeter | henrys, no 9.03 GPL? Which version will be the release in August? | 16:31.57 |
| mvrhel2 | ok. ray_laptop; it took me a bit to come around but I see now | 16:32.00 |
| henrys | tkamppeter:9.04 | 16:32.10 |
| tkamppeter | henrys, is 9.03 already out? Or what will 9.03 be used for? | 16:32.36 |
| mvrhel2 | ray_laptop: ok. this makes sense to me now. so how does compile_inits 0 with USE_SMALL_PROFILES work | 16:33.12 |
| henrys | tkamppeter:we are doing an out of band release for a special customer. | 16:33.21 |
| mvrhel2 | how are the small profiles copied into default_*.icc | 16:33.35 |
| chrisl | tkamppeter: we are still planning to hit the original planned date for the August release, it's just will be called 9.04 instead. | 16:33.59 |
| henrys | tkampetter, chrisl:let's get a look at this compile error. | 16:34.49 |
| ray_laptop | mvrhel2: sorry. wife asked a Q. | 16:35.42 |
| mvrhel2 | np | 16:35.58 |
| | thats why I am at the coffee shop..... | 16:36.09 |
| tkamppeter | chrisl, henrys, OK, so I will start testing snapshots now, independent which numbber they rae. | 16:36.49 |
| ray_laptop | with USE_SMALL_PROFILES=1 (or whatever) the mkromfs command line gets the profiles from (disk) iccprofiles/small/* and puts them into %rom%iccprofiles/ | 16:37.00 |
| mvrhel2 | put what about if compile_inits is 0 | 16:37.31 |
| henrys | tkamppeter:okay and report bugs as you see fit, I don't know how well chrisl tests the shared library configurations. | 16:37.44 |
| mvrhel2 | s/put/but/ | 16:37.47 |
| ray_laptop | mvrhel2: or we could put the profiles in %rom%iccprofiles/small and just change the default icc_dir for USE_SMALL_PROFILES=1 | 16:38.35 |
| tkamppeter | chrisl, can you help me on my proplem which I mentioned above? | 16:38.56 |
| ray_laptop | if we change the default path, it'll work for COMPILE_INITS=0 | 16:38.57 |
| chrisl | tkamppeter: I'm looking at it now. I assume it's happened with the libjpeg update | 16:39.20 |
| marcosw_ | sorry for being late for the support meeting | 16:39.46 |
| mvrhel2 | I feel like ray_laptop is playing a game of 3 card monte with me :) | 16:39.56 |
| ray_laptop | sorry | 16:40.04 |
| mvrhel2 | hehe | 16:40.07 |
| | I am just having trouble keeping up | 16:40.24 |
| ray_laptop | I did throw in an alternative | 16:40.28 |
| | we could _either_ have small profiles always live in iccprofiles/small/ or %rom%iccprofiles/small/ and set the default dir depending on USE_SMALL_PROFILES | 16:41.31 |
| henrys | marcosw_:I don't think we really need to have one unless you want to I sent you email about customer stuff. | 16:41.38 |
| ray_laptop | also when USE_SMALL_PROFILES=1 we don't populate %rom%iccprofiles/*.icc -- it'll only contain %rom%iccprofiles/small/*.icc | 16:42.21 |
| mvrhel2 | ray_laptop: and in the case, when COMPILE_INITS=1 would we avoid copying the large profiles and also having doubles | 16:42.29 |
| | oops asked too slow | 16:42.38 |
| | ok | 16:42.43 |
| ray_laptop | mvrhel2: but you got it, yes | 16:42.52 |
| henrys | marcosw_:I seem to have written the mail to myself which might be confusing. | 16:43.01 |
| mvrhel2 | ray_laptop: so does this make the most sense? I guess we are doing it this way to get around the fact that the names are hardcoded in the ps interpreter | 16:43.46 |
| ray_laptop | mvrhel2: the softmask need for small profiles could also be gotten around by pickling them into the C code even when COMPILE_INITS=0 -- those could also be the "fallback" when we can't find a profile | 16:44.31 |
| | I have to run an errand. bbiab | 16:44.57 |
| mvrhel2 | right. | 16:45.01 |
| | henrys: you started this. do you have any thoughts | 16:45.42 |
| marcosw_ | I haven't checked my email since last night, so I'll do that know. Did mvrhel2 or you figure out the not finding of the icc profile issue for the compile inits 0 case. | 16:45.57 |
| mvrhel2 | marcosw_: I believe it all works now in the 9,03 tag | 16:46.21 |
| chrisl | Robin_Watts: your fixing of the dependencies in lib.mak broke the shared library build for jpeg - haven't tried the others yet :-( | 16:46.23 |
| Robin_Watts | chrisl: Howso? | 16:46.42 |
| chrisl | It's checking for headers in gs/jpeg/ | 16:47.04 |
| marcosw_ | mvrhel2: okay, I'll pull a copy of that and run it both with the compile inits 0 and compile inits 1 case through the regression files. Presuming it passes we should be able to release it. I assume you've minimally verified the windows build works | 16:47.19 |
| | . | 16:47.19 |
| henrys | mvrhel2:seems to get ugly because of the softmask requirement for the simple profiles. | 16:47.21 |
| | the hardwired names are really not so terrible to me. | 16:47.44 |
| Robin_Watts | chrisl: right, so previous the dependencies were wrong for non-shared libs, now they are wrong for shared libs, but right otherwise. | 16:47.52 |
| mvrhel2 | marcosw_: I tested windows with and without compile_inits | 16:48.17 |
| Robin_Watts | So at worst, I changed the brokenness around a bit :) | 16:48.24 |
| chrisl | Robin_Watts: well, both cases build before, now one doesn't - I'd say that's more broke - I wish we didn't have to worry about shared libs :-( | 16:48.56 |
| mvrhel2 | henrys: if it wasnt for the ps interpreter having the names hard coded, I think the fix would be quite easy | 16:49.23 |
| Robin_Watts | mvrhel2: Are the names hardcoded in .ps files ? | 16:49.59 |
| mvrhel2 | yes | 16:50.02 |
| Robin_Watts | Can the ps not be made to try those first and if they aren't found, fall back ? | 16:50.19 |
| henrys | I am fine with any solution you concoct that doesn't make me look like a meathead when I talk to the customer - as it is now. | 16:50.44 |
| mvrhel2 | oh it could first look for default_rgb and then ps_rgb | 16:50.54 |
| | that is what we should do | 16:51.00 |
| | alexcher are you around | 16:51.13 |
| chrisl | tkamppeter, Robin_Watts: I'll fix this jpeg (and any other) dependency stuff tomorrow after I've sorted out the 9.03 release. | 16:51.17 |
| mvrhel2 | Robin_Watts finds the easy answer | 16:51.30 |
| Robin_Watts | You can always trust me to find a solution that passes it off to someone else :) | 16:51.56 |
| tkamppeter | chrisl, OK, tell me when you have done so and I will do the next test build after that. | 16:52.00 |
| | chrisl, I am on Oneiric FYI. | 16:52.23 |
| chrisl | tkamppeter: do you know what version of libjpeg is going to be used in Oneiric? | 16:52.37 |
| marcosw_ | chrisl: I'm doing final testing on the 9.03 release candidate today, will let you know tonight (my time) if it's good to ship. Presuming no issues we can release on Friday, assuming that works with your schedule. | 16:52.48 |
| chrisl | marcosw_: yes, that should work. I'd hoped to have the release prepped today, but haven't had time :-( | 16:53.26 |
| marcosw_ | and today is almost over for you :-) | 16:53.48 |
| tor8 | chrisl: I'm banging on the mupdf/ghostscript bridge, and now I'm about to start on fonts... any pointers where to start? I've got an FT_Face and I want a gs_font, encodings and metrics not necessary | 16:54.04 |
| | the ghostxps code has a lot of special cases for truetype and opentype/cff fonts, but none of that is really useful | 16:54.52 |
| chrisl | tor8: you could look at the FAPI_font structure, it's got some extra opaque stuff in there for holding the font scaler's own data, so you could probably use that. | 16:55.29 |
| tor8 | I seem to recall you had some build_char procs that use the freetype outline extraction somewhere? | 16:56.01 |
| alexcher | mvrhel2: yes | 16:56.28 |
| marcosw_ | btw, can I ask another stupid git question?: Why does "git checkout ghostpdl-9.03" work but when I do "git tag" does ghostpdl-9.03 not show up? | 16:56.36 |
| chrisl | tor8: Yeh, but that's all tied in to using the PS interpreter stuff. | 16:56.52 |
| | marcosw_: because ghostpdl-9.03 is a branch, not a tag. | 16:57.05 |
| mvrhel2 | Hi alexcher: I dont know if you followed the above thread, but how hard/easy would it be to have the code in gs_lev2.ps around line 638 look for default_gray.icc profile first, if it fails then look for ps_gray.icc | 16:57.47 |
| chrisl | tor8: if you're feeling brave, you can look in psi/zfapi.c and psi/fapi_ft.c - but it is not nice in there :-( | 16:57.53 |
| mvrhel2 | likewise with rgb and cmyk | 16:57.53 |
| | actually that wont work though | 16:58.13 |
| tor8 | chrisl: I was just about to ask if those two files were the latest shiniest stuff :) | 16:58.14 |
| | I'll take a peek in there, now that I know where to start digging | 16:58.30 |
| mvrhel2 | ray_laptop: question for you | 16:59.05 |
| marcosw_ | right. I should be doing "git branch -r" | 16:59.06 |
| alexcher | mvrhel2: I'ls just a small matter of programming. | 16:59.25 |
| mvrhel2 | Robin_Watts had a suggestion that the ps code looks first for default_rgb and if not found look for ps_rgb.icc | 16:59.45 |
| chrisl | tor8: I think the shine might be rather tarnished! What I would like to do is split out the PS interpreter dependent stuff in zfapi.c, and have a language independent interface in "base". | 17:00.10 |
| ray_laptop | mvrhel2: if I am forcing the issue, it is also pretty straightforward to be able to get options that exist in C up into the PS interpreter | 17:00.24 |
| Robin_Watts | That way people can add default_rgb on a path if they wanted to, and still have it work. | 17:00.33 |
| mvrhel2 | that would seem to be ok for the compile_inits 1 case but I am not sure how we make sure it doesnt find a default_rgb when compile_inits is 0 | 17:00.39 |
| ray_laptop | goes to check logs ... | 17:01.05 |
| Robin_Watts | mvhrel2: Surely we WANT to let them provide a default_rgb if they want? | 17:01.06 |
| chrisl | tkamppeter: I will certainly let you know when I've got the shared lib build going again. | 17:01.09 |
| mvrhel2 | if someone has USE_SMALL_PROFILES | 17:01.14 |
| | Robin_Watts: not if they specify USE_SMALL_PROFILES | 17:01.31 |
| Robin_Watts | The purpose of USE_SMALL_PROFILES is to keep the rom size down (in the =1 case), and the base install size down (in the =0 case) | 17:01.40 |
| mvrhel2 | then is would use the ps_*.icc profiles | 17:01.41 |
| tor8 | chrisl: maybe I should try working off the gs_font struct and attempt a "clean room" implementation. (hah! as if that'll ever work...) | 17:01.48 |
| mvrhel2 | and the ram size doewn | 17:01.50 |
| Robin_Watts | oh, right. | 17:02.00 |
| | Can we include different .ps files into the build according to USE_SMALL_PROFILES ? :) | 17:02.28 |
| tkamppeter | chrisl, great, thanks in advance. | 17:02.38 |
| mvrhel2 | that is what I was wondering | 17:02.42 |
| | Robin_Watts: that is a coding excecise for someone | 17:03.10 |
| | other than me | 17:03.14 |
| ray_laptop | mvrhel2: Robin_Watts: that'd work. But we can also get the setting from the C code up into the PS easily enough. We do this for LOTS of other stuff like 'product' and 'version' | 17:04.03 |
| chrisl | tor8: as I said, the FAPI_font structure is just a super set of the gs_font struct with some extra opaque pointers. I'd be surprised if you needed more than that. | 17:04.26 |
| tor8 | chrisl: yeah, it looks like it should be just a matter of initializing all the structs properly. | 17:05.04 |
| ray_laptop | but having a .ps file that gets included into the INITFILES list is also provided for by the .dev concept | 17:05.15 |
| mvrhel2 | ray_laptop: you are probably in the best position to know the cleanest easiest way to do this | 17:06.19 |
| ray_laptop | for a simple example, look at psi/int.mak usedsc.dev: it does: $(SETMOD) $(PSD)usedsc -include $(PSD)dscparse -ps gs_dscp | 17:06.32 |
| chrisl | tor8: you might have to move the definition into "base", and you'll have to be careful of the destructor, you don't want it trying to free an actual set of FAPI data. | 17:06.34 |
| ray_laptop | the SETMOD with the -ps option tells us to include a ps file in the INITFILES | 17:07.16 |
| mvrhel2 | essentially, if USE_SMALL_PROFILES is set, the interpreter should make use of the ps_*.icc profiles, and likewise in the c code DEFAULT_RGB_ICC and friends should be set to ps_*.icc | 17:07.35 |
| Robin_Watts | tor8: sebras: http://ghostscript.com/~robin/out.png | 17:07.51 |
| mvrhel2 | and if compile_inits is 1 the default_*.icc profiles should not be in the romfs | 17:07.58 |
| | question is, who wants to sign up for this.... | 17:09.13 |
| ray_laptop | mvrhel2: well, the least change is questionable. I still like the idea of pickling the ps_*.icc ICC's into the C code (independent of %rom% / COMPILE_INITS). That way softmask always has them and they can be the fallback defaults | 17:09.30 |
| | mvrhel2: this is for 9.04, right ? | 17:10.16 |
| | if so, then I'll do it. | 17:10.28 |
| mvrhel2 | ray_laptop: yes it would be nice to get it in for 9,04 | 17:10.29 |
| ray_laptop | it's not a show stopper for 9.04, right ? (we haven't committed it to a customer have we ?) [marcos?] ;-) | 17:11.21 |
| henrys | it would be nice to have something for the customer soon. | 17:11.52 |
| mvrhel2 | ray_laptop: ok thanks. you are obviously best suited for this since it operates at multiple levels | 17:12.04 |
| | the current solution is clunky and we don't want henrys to look too much like a meathead ;) | 17:12.42 |
| ray_laptop | mvrhel2: how come ps_gray.icc is BIGGER than the other gray profiles ? | 17:13.01 |
| henrys | not more than usual | 17:13.03 |
| | at least | 17:13.06 |
| mvrhel2 | ray_laptop. good question. let me look at that. | 17:13.22 |
| ray_laptop | and we have a duplicate 'sgray.icc' that is EXACTLY the same as default_gray.icc | 17:14.25 |
| mvrhel2 | yes. | 17:14.42 |
| ray_laptop | I still think having different directories for different schemas of ICC profile might make sense | 17:14.57 |
| chrisl | tor8: after the current release related insanity is over, we can talk properly about a proper, language independent FAPI | 17:15.05 |
| mvrhel2 | sgray.icc is needed for jpeg2000 support | 17:15.16 |
| | it just happens to also be our default | 17:15.23 |
| tor8 | chrisl: yeah, I'll just bang out something prototyping enough to get raster working for now | 17:15.45 |
| Robin_Watts | tor8: Did you commit my last patch ? | 17:16.05 |
| chrisl | tor8: okay, great - it might actually inspire me to get on with the pcl/pxl/xps integration! | 17:16.25 |
| sebras | Robin_Watts: out.png looks really nice at first glance. | 17:16.35 |
| mvrhel2 | so ps_gray.icc at 416 bytes vs. default_gray.icc at 394 bytes differs due to my inclusion of a black point in ps_gray.ps | 17:16.40 |
| | ps_gray.icc | 17:16.46 |
| | i mean | 17:16.48 |
| sebras | Robin_Watts: haven't checked the mupdf code for some time though. I'd better sync it down once tor8 has merged all your patches. | 17:17.04 |
| mvrhel2 | default_gray.icc has a gamma of 2.2 | 17:17.06 |
| | ps_gray.icc has a gamma of 1 | 17:17.12 |
| | the default matches what AR does | 17:17.26 |
| | I could rip the black point out of ps_gray.icc but I dont think the 22 bytes is the big issue ;) | 17:18.18 |
| | the killer is the cmyk profile | 17:18.50 |
| chrisl | ray_laptop: (sorry to butt in, but I'm almost out of time) The script and instructions for the commercial release? If you could get that to me today, then I can press ahead with the release first thing (my) morning. | 17:19.01 |
| mvrhel2 | the swop cmyk profile is a beast | 17:19.04 |
| tor8 | Robin_Watts: I have not pushed it yet | 17:19.50 |
| Robin_Watts | tor8: Do you forsee major problems with it? | 17:20.04 |
| | I am about to tidy up my code to make a second commit to add knockout support. | 17:20.36 |
| mvrhel2 | marcosw_ did you see the email from the 9,03 customer? | 17:20.39 |
| tor8 | I wanted to ask why the image painting functions take an extra argument, wouldn't the same approach you use for paths and text work there too? | 17:20.49 |
| mvrhel2 | do we know if issue 2 is still a problem? | 17:21.01 |
| Robin_Watts | tor8: We don't have a mechanism for saying "paint the alpha from this image into this pixmap" | 17:21.25 |
| mvrhel2 | I just tested this on windows and it worked fine | 17:21.26 |
| | I will test on linux | 17:21.45 |
| Robin_Watts | Given that we're running through the alpha doing some of the required calculations already, it seems silly to then redo that again in a new bunch of code for the shape plane. | 17:22.14 |
| tor8 | Robin_Watts: image masks used for clipping do it, but I guess that's only for 1-component images | 17:22.20 |
| mvrhel2 | ray_laptop: do you need anything from me with respect to the icc profiles? | 17:23.01 |
| tor8 | Robin_Watts: right. | 17:23.15 |
| Robin_Watts | tor8: If there is a neater way to work, I'll do it, but I couldn't see it at the time. | 17:23.28 |
| mvrhel2 | chrisl: what is the freeze date to get stuff in for 9.04? | 17:23.44 |
| marcosw_ | mvrhel2: do you mean the email titled "Open issues for 9.03"? | 17:23.55 |
| mvrhel2 | marcosw_ yes | 17:24.04 |
| Robin_Watts | If we're worried about the speed hit, we can specialise those functions. | 17:24.05 |
| tor8 | neater ways can be figured out later :) I'm not averse to changes later | 17:24.05 |
| Robin_Watts | but a single call to bilerp will outweigh the extra cost, I think. | 17:24.30 |
| marcosw_ | I just checked my email for the first time since last night, so I saw it a few minutes ago. | 17:24.39 |
| Robin_Watts | and I saved a repeated bilerp in some functions. | 17:24.47 |
| tor8 | Robin_Watts: for most pdf images with no inline alpha channel, I think we could make an even simpler function for filling the shape buffer. but that means adding a flag to the image structs, and I haven't got around to that yet | 17:24.57 |
| mvrhel2 | ok. let I am checking now that the 9,03 candidate works for item 2 on linux now | 17:25.07 |
| tor8 | it'd mean a lot more image painting functions for one | 17:25.10 |
| mvrhel2 | windows was fine like I said | 17:25.18 |
| tor8 | Robin_Watts: yeah, I'm not too concerned about the speed implications | 17:25.37 |
| Robin_Watts | tor8: Well, we could usefully refactor the image painting functions, so that they all take a common struct as an argument. | 17:25.42 |
| | Thus keeping the number of params down. | 17:25.55 |
| chrisl | mvrhel2: I'd really like some time around the July 22nd, but in practice, maybe July 27th, if we're going to release at the end of the first week in August, it really can't be later. | 17:25.57 |
| tor8 | Robin_Watts: yeah, the number of arguments is a bit silly in those functions | 17:26.11 |
| Robin_Watts | (sorry, meaning we'd pass a pointer to the struct rather than the struct itself) | 17:26.12 |
| | Then it's a lot easier to only specialise the functions we want to. We have the most general one, and offer optimised ones where it matters. | 17:26.54 |
| mvrhel2 | chrisl: ok. I think I just need to get in one thing related to the rendering intent in place and update the docs on all the color changes for the graphic object dep color management | 17:27.03 |
| | oops | 17:27.14 |
| tor8 | and for performance we should probably pass matrices by pointer instead of by value (taking care not to clobber it, though) | 17:27.14 |
| Robin_Watts | tor8: const :) | 17:27.33 |
| tor8 | *shudder* I am allergic to const | 17:27.47 |
| chrisl | hmm, chatzilla go "bang"! | 17:27.50 |
| mvrhel2 | ha | 17:27.53 |
| | as I was saying chrisl I think I just need to get in one thing related to the rendering intent in place and update the docs on all the color changes for the graphic object dep color management | 17:28.08 |
| | all the big parts that I promised the customers this spring are in there | 17:28.33 |
| Robin_Watts | tor8: I have knockout groups working, but I'm going off the 'pre' 'post' things. | 17:28.49 |
| | I might just hardwire calls into every drawing function - seems neater. | 17:29.16 |
| chrisl | mvrhel2: okay, well docs you can change up the last minute! It would be nice to keep high risk things to a minimum for while, though! | 17:29.17 |
| Robin_Watts | mvrhel2: Are we still looking at sorting planar halftoning etc for 9.04 ? | 17:29.52 |
| chrisl | tkamppeter: can you confirm the actual freeze date for Oneiric? | 17:30.05 |
| ray_laptop | Robin_Watts: I think that can be independent of the release -- it is mostly driven by company R which is a long shot | 17:31.19 |
| | IMHO | 17:31.27 |
| Robin_Watts | ray_laptop: I thought norbert and co were interested in that too ? | 17:31.36 |
| tkamppeter | chrisl, will do ... | 17:31.40 |
| mvrhel2 | Robin_Watts: that would be nice but it will take some significant effort to make that | 17:32.07 |
| Robin_Watts | (or maybe that's halftoning, but not planar) | 17:32.10 |
| ray_laptop | Robin_Watts: might be. They have more experience doing development work between releases, however | 17:32.17 |
| tkamppeter | chrisl, ... August 11, so I need the 9.04 release some days before. | 17:32.37 |
| mvrhel2 | Robin_Watts: the color thresholding will only work for planar right now | 17:32.48 |
| tkamppeter | chrisl, https://wiki.ubuntu.com/OneiricReleaseSchedule | 17:32.55 |
| Robin_Watts | mvrhel2: Sure. Just wanted to know what the customers you visited in your Europe trip were expecting. | 17:32.57 |
| mvrhel2 | oh they only wanted the object dep color management base upon source object | 17:33.21 |
| chrisl | tkamppeter: ah, great, thanks. So aiming for the first in August for 9.04 is the right thing, then! | 17:33.27 |
| Robin_Watts | ok. | 17:33.30 |
| mvrhel2 | I have the working except for getting the rendering intent part working | 17:33.36 |
| | that should be pretty minimal fix to get that going | 17:33.48 |
| | I have some cool source profiles that I made to demonstrate it all working | 17:34.21 |
| ray_laptop | is feeling good about getting this tag stuff sorted out so that the type specific profiles might actually work | 17:34.32 |
| mvrhel2 | yes. without that none of it would have worked | 17:34.46 |
| | pretty much after that was in place it was done | 17:34.54 |
| | thanks ray_laptop | 17:35.01 |
| tkamppeter | chrisl, yes. | 17:35.34 |
| mvrhel2 | I tested both with output profiles and input profiles and it all works in clist and non clist modes | 17:35.51 |
| | like I said, just need to wrap up with the rendering intent | 17:36.10 |
| chrisl | ray_laptop: I sent a mail about it, but the script and instructions for the commercial release? If you could get that to me today, then I can press ahead with the release first thing (my) morning. | 17:39.42 |
| mvrhel2 | ray_laptop: you are probably best suited to port the icc_dir fix over to the head also | 17:46.13 |
| | I hate to pile things up on you | 17:46.21 |
| | but... | 17:46.24 |
| | you the man | 17:47.01 |
| marcosw_ | mvhrel2: in terms of the "Open issues in 9.03" email, the first issue was fixed weeks ago, so I assume is no problem for 9.03, but is the second issue fixed as well? | 17:50.27 |
| mvrhel2 | marcosw_: In windows second issue is fine. | 17:56.14 |
| | checking now in linux | 17:56.18 |
| marcosw_ | thx | 17:56.21 |
| mvrhel2 | to be honest I don't know when that was ever broke | 17:56.31 |
| JediMaster | hi all, I'm running 9.02 and I'm having problems trying to convert a pdf into a jpeg (using image magick, getting the same error through ghostscript on the command line when trying to just read the pdf) | 18:02.46 |
| | http://pastebin.com/z7YySP5e here is the full error | 18:03.29 |
| Robin_Watts | JediMaster: Does the same PDF open in Acrobat ? | 18:04.11 |
| JediMaster | yes | 18:04.15 |
| Robin_Watts | If you save it out of acrobat, does it then work in gs ? | 18:04.28 |
| JediMaster | well rather it opens in adobe reader | 18:04.42 |
| | don't actually have acrobat | 18:04.46 |
| Robin_Watts | Right, that's what I meant. | 18:04.50 |
| | Acrobat (including Reader) often silently fixes broken files. | 18:05.15 |
| | If the version it saves out opens in gs, then it shows that it was a broken file (but we'd still be interested in seeing it, so we can maybe fix gs). | 18:05.47 |
| JediMaster | this pdf is being generated through PHP/TCPDF and includes embedded postscript fonts, so not too suprised =) | 18:05.58 |
| | just not sure what I changed to stop it working now lol | 18:06.08 |
| Robin_Watts | If Acrobats saved version still fails, then that's (more of) an indication that the file is fine, and gs is at fault. | 18:06.23 |
| JediMaster | ok, don't have access to acrobat at the mo =( | 18:06.45 |
| Robin_Watts | Regardless, I suspect we'd be interested in seeing the file. Can you visit http://bugs.ghostscript.com/ and open a bug there please ? | 18:06.55 |
| | and attach your pdf? | 18:07.00 |
| JediMaster | sure | 18:07.14 |
| Robin_Watts | Thanks. | 18:07.18 |
| JediMaster | Robin_Watts: bug # 692343 | 18:15.57 |
| henrys | ray_laptop:chrisl_away seems to be working pretty hard to get this script from you. Is there some problem with transferring now? Should you do this release? | 18:17.04 |
| ray_laptop | henrys: I'm going to try it now that the luratech 'auto select' should be working. | 18:17.45 |
| mvrhel2 | marcosw_: no problems setting the output profile in linux with 9.03 with tiff32nc | 18:19.26 |
| JediMaster | + ./base/saes.c:152: s_aes_process(): invalid aes padding byte (0xa7) | 18:29.56 |
| | is this encryption related? | 18:30.00 |
| ray_laptop | Robin_Watts: tor8: what does it mean when I see this: | 18:30.07 |
| JediMaster | just noticed the AES there | 18:30.08 |
| Robin_Watts | JediMaster: Sounds like it. | 18:30.08 |
| ray_laptop | checking out git tag ghostscript-9.02 | 18:30.09 |
| | Unlink of file 'gs/base/genht.c' failed. Should I try again? (y/n)? | 18:30.10 |
| Robin_Watts | it means it's tried to delete a file (possibly before putting a replacement in its place) and wasn't able to. | 18:30.40 |
| ray_laptop | Robin_Watts: typing 'y' seemed to work OK, but it is rather disconcerting | 18:30.45 |
| Robin_Watts | It probably means that some other thing had it open on your system. | 18:30.58 |
| | Windows? | 18:31.00 |
| ray_laptop | is that a bug we can report upstream ? | 18:31.04 |
| Robin_Watts | Could be antivirus. | 18:31.07 |
| ray_laptop | Robin_Watts: yes, Windows | 18:31.10 |
| Robin_Watts | I suspect that they would tell you not to worry. | 18:31.29 |
| | I had lots of problems ages ago with cvs with the Nokia MServer stuff. It would check every file created to see if it was a media file. | 18:32.22 |
| | which meant if you created files and then quickly accessed them, you used to catch it with its fingers in the cookie jar, and your access would be refused. | 18:32.54 |
| | CVS just crashed. Git it seems copes, albeit with a prompt to let you know something is going on. | 18:33.15 |
| | tor8: sebras New commit in my mupdf.git repo on casper that does knockout groups. | 18:44.01 |
| mvrhel2 | hmmm something seems to be mucked up with the icc directory in the head | 18:52.20 |
| ray_laptop | mvrhel2: we need to move the profiledir to the lib_ctx ;-) | 18:54.02 |
| mvrhel2 | yes. this is weird though. | 18:54.37 |
| Robin_Watts | JediMaster: I can reproduce your bug here. | 18:54.57 |
| mvrhel2 | I am worried that I may have broke something with my changes to make the rendering intent work | 18:55.09 |
| ray_laptop | chrisl_away: do you have 64-bit Windows ? | 18:55.51 |
| mvrhel2 | apparently a rebuild fixed the issue. must have been something left over from my 9.03 checkout | 19:02.10 |
| | whew | 19:02.19 |
| | ok cool the source rendering intent settings are working | 19:02.59 |
| ray_laptop | after a co I usually do a clean and build (Rebuild) | 19:03.07 |
| mvrhel2 | yes. learned my lesson there | 19:03.19 |
| Robin_Watts | If only our makefile dependencies worked... | 19:03.54 |
| mvrhel2 | now I just need to add in the rendering intents for the output and then I think it will be time to right up all of this. | 19:04.40 |
| | I have a cool example where I have the same profile that has radically different AtoBx tables for its rendering intents to demo the case where the source profiles are driving the intents which is what the customers in Europe wanted | 19:06.48 |
| | Robin_Watts: how do I do a hard reset of my linux get to the current master | 19:07.59 |
| Robin_Watts | git reset --hard ? | 19:08.09 |
| mvrhel2 | oh yes | 19:08.24 |
| | nevermind I think the issue is that my co is 9,03 | 19:08.38 |
| | so I probably need to do git checkout --hard master | 19:10.05 |
| | ? | 19:10.08 |
| Robin_Watts | git reset --hard will throw away all changes from your current HEAD. | 19:10.38 |
| | then do: git checkout master | 19:10.46 |
| mvrhel2 | that is fine | 19:10.49 |
| | ok | 19:10.51 |
| Robin_Watts | The former makes sure the latter can proceed with no problems. | 19:11.07 |
| | As ever with git there may be other ways to do it, but that's the way that I'd be most comfortable doing it. | 19:11.32 |
| mvrhel2 | gotcha | 19:12.22 |
| | ok. seem to have it up to date now | 19:13.17 |
| | thanks | 19:13.20 |
| Robin_Watts | np. | 19:13.23 |
| mvrhel2 | ok. lunch time. bbiaw | 19:17.18 |
| ray_laptop | lunch for me, too | 19:17.45 |
| mvrhel2 | Robin_Watts: so maybe tomorrow you ray and I can chat a bit about the planar stuff | 19:17.51 |
| Robin_Watts | mvrhel2: Sure. | 19:17.58 |
| ray_laptop | after the 9.03 dust settles... | 19:18.07 |
| mvrhel2 | yes | 19:18.10 |
| | ok bbiaw | 19:18.32 |
| Robin_Watts | I may have a quick look at making the pattern accumulator base it's "chunky or planar" choice on gxdso_is_native_planar | 19:19.15 |
| | tor8: You here? | 19:22.02 |
| | JediMasters bug (692343) looks to be a difference in how we deal with the padding at the end of aes encrypted streams. | 19:22.33 |
| | You, ralph and larsu look to be the people responsible for the code in there. | 19:23.14 |
| chrisl | ray_laptop: I do have 64 bit Windows, yes. | 19:34.03 |
| henrys | marcows_: I can't reproduce 711's memory problem gsmem.ps seems to peak lower in head than 8.71. They are running the program under gdb which implies a debug build, we aren't going to fix mem problems in debug builds. | 19:36.24 |
| marcosw_ | does the debug build use more memory than the production build? | 19:36.58 |
| henrys | I don't know | 19:37.49 |
| | I can't think of any significant allocations offhand. | 19:38.28 |
| marcosw_ | Is this bug 692335? | 19:39.17 |
| henrys | no that's rom this is ram | 19:40.01 |
| | see there original mail there is no bug. | 19:40.16 |
| | their | 19:40.24 |
| marcosw_ | Found it, It was hidden in a thread about converting color to black. | 19:41.15 |
| | I'll open a bug for the memory issue and see if I can reproduce it, either in the debug build or the release build, otherwise I'll contact the customer for clarification. | 19:43.51 |
| henrys | I think Robin_Watts introduced item (3) - Robin_Watts if you are busy I can look at that - let me know. | 19:44.41 |
| ray_laptop | the debug build has larger code size as well as using more RAM (slighty) for extra debug allocations | 19:46.11 |
| | some of the structures have debug info included IFF #defined(DEBUG) | 19:46.47 |
| henrys | marcosw_:and finally chrisl fixed the time issue that should be reported back. | 19:47.17 |
| marcosw_ | I saw that 692338 had been fixed and was just writing that in an email to them (along with information on the bug that I just opened and asking them to see if they are testing with the debug or production build). | 19:48.10 |
| henrys | 692338 is the relevant bug and with that I'll leave this customer with you. | 19:48.24 |
| | ray_laptop:so we'll just track the profile configuration option with the rom size bug or do you want a separate enhancement bug? | 19:50.40 |
| JediMaster | Robin_Watts: I can confirm reducing the encryption down to RSA 128Bit "fixes" it | 19:53.05 |
| ray_laptop | henrys: mvrhel and I have discussed the options and pickling in the "required" small profiles seems best. Otherwise when a user changes ICCProfilesDir to point to their profiles, we'll have problems with softmask andd JPX decode if they didn't make copies in their directory | 19:56.17 |
| | henrys: the rom size will then involve copying the correct set to the %rom% which is easy with mkromfs. Do we seriously want to worry about the 'install' size ? | 19:57.56 |
| henrys | the install size? - we just want the exe to be smaller because the profiles are smaller - I guess I don't understand something. | 20:04.45 |
| ray_laptop | henrys: sorry -- was working in the script and it didn't pop up since you didn't mention "ray". I was asking whether or not we are concerned with the amount of disk space 'installed' when COMPILE_INITS=0 and they do 'make install' | 20:19.32 |
| henrys | no we don't care about that. (well I don't) | 20:20.18 |
| ray_laptop | darn! I have the script working, but the 64-bit build crashes the 'makensis.exe' | 21:42.09 |
| | we may have to revert to the winzipse for 64-bit installer | 21:50.15 |
| | :-( | 21:51.32 |
| | well, at least for 9.03, I am pretty sure cust 850 doesn't rely on our pre-built binaries. | 21:52.09 |
| cryptopsy | how can i use gs to create a pdf viewing script where i can maneuver through pages but also be able to delete them? right now i use gs to split a doc into pages then xpdf each page individually, | 22:27.45 |
| | the problem with this is you can't scroll back/fwd through pages, and xpdf doesn't provide a var, to use with an extenral script, for current page | 22:28.19 |
| | xpdf provides a variable for 'current-file', which is what i use | 22:29.29 |
| | ultimately its better to avoid xpdf altogether | 22:29.39 |
| Robin_Watts | henrys: I'll look into (3) tomorrow. | 22:55.54 |
| | cryptospy: So you're using xpdf just to display a single page PDF ? | 22:59.27 |
| ray_laptop | cryptopsy: gsvew uses GS to scroll through pages of a PDF without having to create PDF's of individual PDF's | 23:10.36 |
| | cryptopsy: but it sort of sounds like you want to interactively determine which pages of a PDF get sent to a destination PDF (am I close?) | 23:11.41 |
| cryptopsy | no i just want to delete pages from a pdf file as im viewing it | 23:17.59 |
| | and it doesn't have to be that responsive; i can just flag the delete pages and it will process it on closing | 23:18.19 |
| Robin_Watts | cryptopsy: Sounds more like a job for a tweaked mupdf to me. | 23:18.40 |
| cryptopsy | i hardly use my pdf tool; i don't zoom, search etc | 23:19.03 |
| | if i can somehow display pdfs with gs, i will script with it | 23:19.23 |
| ray_laptop | Robin_Watts: is the pdf output of mupdf adequate to the task of skipping pages | 23:19.27 |
| Robin_Watts | Use mupdf to load the pdf and flick through the pages, add a new key to mark a page for deletion (and you can probably indicate it by changing the border on the displayed image to red or something). | 23:19.53 |
| | Then when you exit, that gives you a list of pages to keep. | 23:20.05 |
| ray_laptop | cryptopsy: with gs, you can use PS commands to open the PDF file, render individual pages, read a response from stdin as to whether or not to add the page to a file of "kept" pages | 23:20.44 |
| Robin_Watts | Then you call pdfclean with the list of pages to keep. | 23:21.09 |
| | (pdfclean being a part of mupdf) | 23:21.15 |
| ray_laptop | cryptopsy: (infile.pdf) (r) file runpdfbegin 1 pdfpagecount { dup dopdfpages _____ } for | 23:21.54 |
| cryptopsy | what syntax is that | 23:22.11 |
| Robin_Watts | mupdf is a cleaner option, IMHO. Saves completely taking the PDF to bits and reassembling it. Also saves having to speak postscript, and understand the vagaries of the gs PDF interpreter. | 23:22.37 |
| ray_laptop | where ____ is your PS to read stdin for 'y' or 'n', and write out the page number to a file that contains page numbers you want to keep. | 23:22.38 |
| | cryptopsy: that is PS input to GS | 23:22.56 |
| Robin_Watts | also it'll more neatly let you cope with moving both back and forwards in the file. | 23:23.01 |
| ray_laptop | Robin_Watts: as long as you add custom keys to whatever applet it is (which is ???) | 23:23.33 |
| Robin_Watts | ray_laptop: mupdf has a simple viewer. It's easy to add keys to it. | 23:23.55 |
| ray_laptop | Robin_Watts: that's fine as long as the learning curve is small. If you are reasonably PS fluent, you don't have to struggle with modifying mudf applets (pdfshow ??) and add keys and building mupdf. | 23:25.24 |
| | Robin_Watts: It may be better than last time I tried it, but it was about 4 hours, of -- Oh, you also need to install ... | 23:26.01 |
| Robin_Watts | Building mupdf is dead simple. Unpack 2 zip files, run the solution or type make. | 23:26.27 |
| | The second zipfile being all the dependencies. | 23:26.43 |
| ray_laptop | Robin_Watts: it may be better. I was working with the git repo (which was missing some stuff at the time) | 23:27.01 |
| Robin_Watts | (or git checkout + 1 zipfile if you prefer) | 23:27.04 |
| ray_laptop | Robin_Watts: and there were version problems with the 'thirdparty' stuff at the time. (I still don't know why the thirdparty .zip isn't in the repo -- or if it is) | 23:28.05 |
| Robin_Watts | It isn't. It's on mupdf.com. | 23:28.44 |
| ray_laptop | I had to find tor to ask where to get the thirdparty stuff for windows, and then it still didn't build without tweaking | 23:28.45 |
| | Robin_Watts: I'll try again and see what I trip over. :-) | 23:29.24 |
| cryptopsy | mupdf depends on jbig2dec, why? | 23:29.25 |
| Robin_Watts | I think you had a bad experience. It's generally pretty easy. | 23:29.38 |
| ray_laptop | cryptopsy: because PDF includes JBIG2 | 23:29.41 |
| | and JPX and Flate and LZW | 23:29.58 |
| cryptopsy | xpdf does't depend on it | 23:29.59 |
| Robin_Watts | Then xpdf doesn't decode jbig2 images :) | 23:30.15 |
| cryptopsy | neither does ghsotscript | 23:30.17 |
| ray_laptop | cryptopsy: they may have their own 'built in' jbig2 decoder | 23:30.20 |
| Robin_Watts | ghostscript does use jbig2dec. | 23:30.39 |
| ray_laptop | cryptopsy: and the GS sources include the jbig2dec | 23:30.41 |
| Robin_Watts | It's just shipped as part of gs. | 23:30.46 |
| cryptopsy | ocool | 23:30.50 |
| | cool* | 23:30.52 |
| ray_laptop | GS also includes jasper (includes the sources) | 23:30.55 |
| cryptopsy | i like jasper | 23:31.05 |
| ray_laptop | jasper is used for JPX on gs, mupdf uses openjpeg | 23:31.18 |
| | jasper is a slow pig | 23:31.28 |
| | gs will (when we get time) be switching to openjpeg | 23:31.53 |
| Robin_Watts | It's a question of target; gs is targetted at 'large' machines, where it's most important to include everything, so we ship everything it needs. | 23:31.56 |
| | mupdf is (more) targetted at embedded devices, where you'd really rather not include multiple copies of libs if you don't need to. | 23:32.23 |
| cryptopsy | why does ghostscript package include jbig instead of just requesting it as a dependancy | 23:32.36 |
| ray_laptop | the shipment is mostly to avoid download issues and version skew problems. | 23:32.37 |
| Robin_Watts | hence it builds with system libs by default - but we make it easy to drop in replacements. | 23:32.52 |
| cryptopsy | ah okay | 23:33.01 |
| ray_laptop | cryptopsy: gs can be built using SHARED_***=1 (and does if configure finds the packages) | 23:33.13 |
| Robin_Watts | If there was a tagline for mupdf if would be "No Bloat". | 23:33.19 |
| cryptopsy | good | 23:33.32 |
| Robin_Watts | (or "silly tabs", one of the two :) ) | 23:33.35 |
| tor8 | xpdf includes their own jbig2 and jpeg2000 decoders | 23:33.44 |
| cryptopsy | ray_laptop: then that means that my distro didn't package it correctly | 23:33.45 |
| ray_laptop | but we've had problems with old and new versions of shared libs not being 100% forward/backward compatible | 23:34.00 |
| Robin_Watts | distros are obsessed with repackaging things to use the system libs. It causes all sorts of problems. | 23:34.17 |
| cryptopsy | the distro can specify which jbig lib to depend on | 23:34.23 |
| ray_laptop | a recent example was a change to libpng | 23:34.24 |
| | and lcms 2 is MUCH different to lcms 1 | 23:34.35 |
| | (but at least lcms differentiated their packages) | 23:34.55 |
| tor8 | Robin_Watts: I vaguely recall having to tweak something with the padding in AES encryption recently. | 23:35.18 |
| ray_laptop | and hunting around to find sources for an older version of a package that works isn't as easy as having the sources in gs tree | 23:35.39 |
| Robin_Watts | tor8: Ah, well, if you can remember, the same patch might work back into gs. | 23:35.41 |
| tor8 | something about a border condition when the block size was an even multiple of 16 | 23:36.13 |
| ray_laptop | tor8: can you git bisect on mupdf to find out where it was fixed ? | 23:36.20 |
| tor8 | does mupdf handle the file? | 23:36.23 |
| ray_laptop | (rather than trying to remember) | 23:36.44 |
| tor8 | + fitz/filt_basic.c:461: read_aesd(): partial block in aes filter | 23:38.36 |
| | \ fitz/stm_read.c:83: fz_fill_buffer(): read error; treating as end of file | 23:38.36 |
| | warning: premature end of data in flate filter | 23:38.36 |
| | warning: ... repeated 2 times ... | 23:38.36 |
| | looks like a broken file, unless mupdf has a bug as well | 23:39.07 |
| | Robin_Watts: uhm, I think I spotted a typo in cbf50e33, line 290 | 23:40.31 |
| | if (fz_is_dict ... should be if (!fz_is_dict I think | 23:41.14 |
| Robin_Watts | That's the line checking the crypt filter is a dictionary? | 23:48.02 |
| | yes, probably, sorry. | 23:48.13 |
| | We should ask JediMaster to put the unencrypted version of the file on the bug too to compare it. | 23:49.53 |
| | gs opens it fine. | 23:50.03 |
| | Not gs. AR. | 23:50.09 |
| | bedtime for me. Night all. | 23:50.23 |
| | Forward 1 day (to 2011/07/15)>>> | |
IRC Logs
