| | <<<Back 1 day (to 2014/03/10) | 2014/03/11 |
| kens | Hi chrisl paulgardiner | 10:43.06 |
| paulgardiner | Hi kens | 10:43.24 |
| | hi chrisl | 10:43.33 |
| chrisl | Hi folks | 10:44.10 |
| | Broadband is acting up :-( | 11:05.34 |
| kens | Mine also | 11:05.44 |
| jroo | I'm trying to cross compile GhostPDL but don't have much success. I was able to get the build system to use my cross compiler by patching makefiles and configure script but the build breaks when the build tries to run generated binary. | 12:02.16 |
| | Does anyone know if someone has managed to cross compile it? | 12:02.30 |
| kens | GS has been cross-compiled, but its not totally trivial | 12:02.47 |
| | You will probably need help from chrisl | 12:02.54 |
| Robin_Watts | jroo: Look for CCAUX | 12:03.03 |
| kens | what target are you cross-compiling for, and if I may ask, why ? :-) | 12:03.13 |
| Robin_Watts | CCAUX is used for building "auxiliary" binaries. i.e. ones to run on the cross compiling host. | 12:03.33 |
| chrisl | jroo: cross compiling GhostPDL will be a bigger challenge that Ghostscript. | 12:03.50 |
| jroo | arm and powerpc because I need to convert PCL to PS on those devices | 12:03.56 |
| | so I would need only the tools to convert pcl to PS | 12:04.15 |
| kens | THa's pretty much everything | 12:04.33 |
| | Though at least you only need Ghostpcl, not xps or GS itself | 12:05.06 |
| jroo | Robin_Watts, ok, thanks. I'll check if I get stuff working by adjusting that variable | 12:07.31 |
| chrisl | Also a challenge will be that the GhostPDL builds were never modified to use the TARGET_ARCH_FILE option | 12:07.56 |
| | So the generated arch.h will be wrong for the target architecture | 12:08.17 |
| | I don't think there's any real support for cross compiling in the GhostPDL builds :-( | 12:09.16 |
| jroo | I came to that conclusion also.. It might be that the program generating PCL files needs to be modified to generate PS or PDF files | 12:09.54 |
| chrisl | jroo: If you're not in a huge hurry, you can open a bug, and I will look at adapting what we have in the Ghostscript build into the GhostPDL builds, but it won't be this week, and probably not next | 12:11.01 |
| jroo | I modified the CCAUX variable to be my cross compiler but the build seems to run echogs command on the build machine | 12:13.11 |
| | and that command is built using the cross compiler | 12:13.19 |
| chrisl | No, you need CCAUX to be the native compiler, and CC to be the cross compiler | 12:13.56 |
| | CCAUX builds tools to run on the host, not the target | 12:14.23 |
| jroo | ah, got it in the wrong way :) | 12:14.36 |
| | well at least the build is now running | 12:15.11 |
| | thanks for pointing that out | 12:15.38 |
| chrisl | But one of the tools it builds is genarch which generates a header describing the platform (arch.h), as genarch runs on the host, it will create an arch.h for the host archtitecture, which will probably be wrong for your target | 12:16.29 |
| jroo | This is work related, i.e. I'm investigating how our customer's device could support more printers. One option would be to just convert PCL to PS so that there would be no need to modify the report generation. | 12:17.06 |
| | So this isn't that urgent for now but we would need to know if this is even possible. | 12:17.19 |
| | That will be wrong but I probably could just generate that header myself and copy the manually generated file to correct directory and that would probably skip generation of that fil | 12:18.11 |
| chrisl | It's definitely possible, but it needs some work to properly support it in the GhostPDL builds | 12:18.16 |
| jroo | s/fil/file/ | 12:18.16 |
| chrisl | No, genarch would overwrite your header. You'd need to change the section in the makefiles that runs generch to copy your file instead | 12:19.30 |
| jroo | Ok. Some more patching after configure then I guess (I known I'm not doing this in "the proper" way but I just try to get a working binary). | 12:22.59 |
| | If I'm able to get a working cross compiled binary I could list the stuff I was required to do for it | 12:26.47 |
| chrisl | Well, the two things normally required in GS are to set CC to the cross compiler, CCAUX to a native compiler, and TARGET_ARCH_FILE to a predefined arch.h file. | 12:28.14 |
| | er. three things..... | 12:28.14 |
| | jroo: so, if you open gs/base/lib.mak, and search for "$(GLGEN)arch.h :" | 12:29.59 |
| | The next line should be "$(EXP)$(GENARCH_XE) $(GLGEN)arch.h $(TARGET_ARCH_FILE)" | 12:30.25 |
| jroo | Yes, I found that already after you mentioned the TARGET_ARCH_FILE | 12:30.32 |
| chrisl | And you can change that to something like: | 12:30.54 |
| jroo | So basically replacing that rule to copy the predefined file (I generated it already on the target device) | 12:31.00 |
| chrisl | $(CP_) <my arch.h file> $(GLGEN)arch.h | 12:31.14 |
| jroo | Thanks for the help. I need to leave from work now but I'll continue trying this out tomorrow and maybe I need to ask still some more questions but this has helped a lot already | 12:32.06 |
| chrisl | jroo: that's fine as I'm as I'm about to go out for a bit, too! | 12:33.45 |
| kens | lunches | 12:34.10 |
| henrys | marcosw:are you about? | 15:56.06 |
| | mace:any reason the picsel site is so slow? | 16:02.08 |
| mvrhel_laptop | hi kens. | 16:07.22 |
| | A couple questions for you. | 16:07.28 |
| kens | Hi mvrhel_laptop | 16:07.29 |
| | go ahead, but my repsonses may not make much sense today | 16:07.40 |
| mvrhel_laptop | reading the documentation. is it true that PDFACompatibilityPolicy is used for PDF/X and PDF/A? | 16:08.29 |
| | I am going to have PDFACompatibilityPolicy set to 1 as we talked about | 16:08.42 |
| kens | Yes, its an unfortunate name with hindsight | 16:08.45 |
| mvrhel_laptop | ok np | 16:08.49 |
| kens | I'm not sure what would have beenbetter though | 16:09.04 |
| mvrhel_laptop | kens: also in pdfa_def.ps | 16:09.12 |
| kens | Ummm, was that a question ? | 16:09.50 |
| mvrhel_laptop | is srgb.icc the profile that is being used as it is? | 16:09.52 |
| | the header says ISO Coated sb. icc | 16:10.05 |
| kens | mvrhel_laptop : its just an example, you *must* configure it before use (pdfa_def.ps that is) | 16:10.19 |
| mvrhel_laptop | kens: I understand. for it to work though, do I need to drop in my file pat for srgb.icc in that file | 16:10.59 |
| | also there is the line /OutputConditionIdentifier (sRGB) % Customize | 16:11.18 |
| kens | Well you need to supply 'some' ICC profile, it doesn't matter which one especially, as far as I understand it :-) | 16:11.38 |
| mvrhel_laptop | kens: ok, just the mismatch between the header and the code had me a little confused | 16:12.00 |
| kens | mvrhel_laptop : Yes that needs to be correct, as per hte OutputIntent Profile | 16:12.02 |
| | Let me just grab the PDF/A spec | 16:12.22 |
| mvrhel_laptop | kens; can you send me that spec? | 16:12.34 |
| | I dont think I have it | 16:12.37 |
| kens | Sure | 16:12.43 |
| mvrhel_laptop | then I wont need to bug you | 16:12.48 |
| | as much ;) | 16:12.54 |
| kens | Its licenced to Mile :-) | 16:12.56 |
| | Miles* | 16:13.00 |
| mvrhel_laptop | is there one for the PDFX too? | 16:13.17 |
| | kens ^^ | 16:13.24 |
| kens | Yes | 16:13.26 |
| | And PDF/A-2 | 16:13.30 |
| | Just a moment | 16:13.35 |
| mvrhel_laptop | ok | 16:13.37 |
| | we don't do PDF/A-2 do we? | 16:13.46 |
| kens | Sure we do | 16:14.12 |
| mvrhel_laptop | ok. so that brings me to the next thing then.... | 16:14.29 |
| kens | Slow down, I can't keep up ;-) | 16:14.46 |
| mvrhel_laptop | oh I see dPDFA | 16:14.52 |
| kens | If you just say -dPDFA you get A-1 | 16:15.15 |
| mvrhel_laptop | -dPDFA=1 or -dPDFA=2 | 16:15.15 |
| kens | Yes | 16:15.19 |
| | OK I've mailed the PDFA-1, PDF/A-2 and PDF/X-3 specs | 16:16.01 |
| mvrhel_laptop | kens: ok great. | 16:16.10 |
| kens | I do have PDF/X-1 but we can't produce that yet, also PDF/VT which we also can't produce, but if anyone wants those, I have them | 16:16.39 |
| mvrhel_laptop | kens: so also, when we do this (that is transform the pdf to a X or A type) with an output intent profile specified with the appropriately modified PDFA_def.ps or PDFX_def.ps we really need to included -dOutputICCProfile="output intent profile" which will end up being used in your new color management of PDF | 16:17.59 |
| | where "output intent profile" is the profile used for the output intent obviously | 16:18.22 |
| | in that sense, the colors are really in that space specified by the output intent | 16:18.37 |
| | When you do the documentation, I think that should be included | 16:18.53 |
| | I will have it set up that way in gsview | 16:19.07 |
| kens | You lost me Michael, I thought that was the OutputIntentProfile | 16:19.12 |
| mvrhel_laptop | kens: but lets say I have a PDF file | 16:19.26 |
| | and lets say that I am going to PDFX | 16:19.58 |
| | CMYK | 16:20.09 |
| | lets say that I have a special profile that I am going to use for my output intent | 16:20.42 |
| | let say also that I have an RGB image in the file that has an ICC profile associated with it | 16:21.20 |
| kens | Hold on,if its RGB how canit have an ICC profile ? | 16:21.51 |
| mvrhel_laptop | sure. In my original document that I am transforming to X | 16:22.13 |
| kens | Your original document is a PDF file you said. So either the image is RGB or its ICC it can't be both | 16:22.32 |
| mvrhel_laptop | so I have a source PDF file | 16:22.32 |
| | it has an RGB ICC profile | 16:22.47 |
| kens | SO its an ICCBased image then | 16:22.55 |
| mvrhel_laptop | yes | 16:22.59 |
| | but the color space is RGB | 16:23.07 |
| kens | So it will be converted to CMYK | 16:23.14 |
| mvrhel_laptop | yes | 16:23.18 |
| kens | The colour space will be ICCBased not RGB | 16:23.28 |
| mvrhel_laptop | to what color space will it be converted? | 16:23.29 |
| kens | mvrhel_laptop : whatever the ProcessColorModel is that you selected with PDF/X | 16:23.52 |
| mvrhel_laptop | kens: ok let me back up | 16:24.03 |
| kens | So Gray or CMYK | 16:24.04 |
| mvrhel_laptop | kens: in the PDF-X document, is the color space DeviceCMYK or ICC based CMYK? | 16:24.24 |
| kens | DeviceCMYK | 16:24.34 |
| | THat's why there's an OutputIntent | 16:24.44 |
| mvrhel_laptop | kens: so what destination profile did you use, when you transformed the Source ICC RGB image to CMYK? | 16:25.04 |
| kens | Whatever was set up in Ghostscript | 16:25.19 |
| mvrhel_laptop | I was thinking you used the device profile | 16:25.22 |
| | hehe | 16:25.25 |
| | ok. That is why you need to say -sOutputICCProfile="output profile" | 16:25.55 |
| | where output profile is the path for the output intent | 16:26.08 |
| kens | Yes, that allows you to go back from the CMYK values to a device-independent space | 16:26.15 |
| mvrhel_laptop | other wise the default CMYK SWOP profile will be used | 16:26.20 |
| kens | Well that's a colour management issue as far as I see it | 16:26.36 |
| mvrhel_laptop | kens: the DeviceCMYK values that get packed into the PDF/X document have to be in the OutputIntent Color space | 16:27.02 |
| kens | mvrhel_laptop : they have to be in DeviceCMYK | 16:27.16 |
| mvrhel_laptop | other wise the outputintent profile is useless | 16:27.22 |
| | kens: yes they are DeviceCMYK | 16:27.29 |
| | but with the output intent profile, you are telling the user what DeviceCMYK means in the docuement | 16:27.48 |
| kens | And teh OutputIntent profile allows you to go back to a device-independent space, so you can colour manage the output for different devices | 16:27.54 |
| henrys | apparently the Smart Office end user questions are flowing in at about 10 per hour to Scott ;-) | 16:27.57 |
| Robin_Watts | henrys: App store questions ? | 16:28.18 |
| | Doesn't surprise me at all. | 16:28.24 |
| kens | mvrhel_laptop : From my perspective, its up to the user to get the colour management right. | 16:28.31 |
| henrys | yes | 16:28.31 |
| mvrhel_laptop | that is why when the transformation to CMYK during your creation occurs, you have to specify -sOutputICCProfile on the command line | 16:28.41 |
| | kens: yes. but the user needs to know what to do | 16:28.45 |
| kens | mvrhel_laptop : I guarantee 99.9% of users don't know and cannot be educated | 16:29.04 |
| mvrhel_laptop | that is why I am saying that the documentation needs to include the use of -sOutputICCProfile | 16:29.11 |
| kens | They want it 'to work' | 16:29.16 |
| mvrhel_laptop | kens: well, I suspect if its not in the manual they wont | 16:29.44 |
| kens | mvrhel_laptop : IMO that is a colour management question and they should consult the colour management documentation | 16:29.47 |
| mvrhel_laptop | even the 0.1 % | 16:29.55 |
| kens | My guess is the 0.1% know what they are doing and will *start* by reading the colur management documentation | 16:30.27 |
| | I'll try and remember to mention it somewhere when I rewrite the documentation | 16:31.12 |
| mvrhel_laptop | kens: If you want, when you get ready to do the documentation, I may help with the color part if you are fine with that. This is a nice tool and I would hate for it not be used due to poor documenation | 16:32.02 |
| kens | I may chuck it ascross to you then when I'm that far along | 16:32.26 |
| mvrhel_laptop | There are a few subtle points that many will not understand | 16:32.35 |
| | including me... | 16:32.40 |
| kens | Me too I suspect | 16:32.45 |
| mvrhel_laptop | together we can likely pull it all together then. | 16:33.06 |
| kens | :-) | 16:33.14 |
| | We should be close to being able to produce properly colour managed PDF files now, I think | 16:33.36 |
| mvrhel_laptop | yes. It is really nice what you have done kens | 16:33.58 |
| kens | Most of the work is yours Michael,I just retro-fitted it to pdfwrite | 16:34.21 |
| mvrhel_laptop | hmm A and X specs have not made it yet | 16:34.32 |
| kens | Oh damn,I zipped them, I bet GOggle put it in spamor ate it. | 16:34.55 |
| | I'll try again | 16:35.01 |
| | Hmm, now Eudora doesn't want to send mail..... | 16:36.36 |
| | OK on its way now, you'll have to rename the file to '.zip' | 16:37.49 |
| mvrhel_laptop | kens: got it. thanks. | 16:41.55 |
| kens | Ahgood, thanks for letting me know | 16:42.01 |
| Robin_Watts | I'm going to have power cuts here on and off tomorrow, so may not be contactable. | 16:43.10 |
| mvrhel_laptop | kens: oh wow. this is an interesting document | 16:46.06 |
| kens | Which one ? | 16:46.13 |
| | I cna't say I found any of them compelling reading :-) | 16:46.25 |
| mvrhel_laptop | kens: the PDF/A-1 document | 16:46.28 |
| | I see that if we have a DeviceGray color space | 16:46.44 |
| | and a DeviceRGB output intent | 16:46.54 |
| kens | If you need any more PDF specs, I have a few of them..... | 16:46.57 |
| mvrhel_laptop | then I am supposed to define the DeviceGray color space using a conversion of the OutputIntent profile | 16:47.17 |
| | that is something that I have not been doing | 16:47.24 |
| | also, you can have multiple output intents | 16:47.48 |
| kens | Hmm, I think I need to look at that bit of the sepc | 16:47.51 |
| mvrhel_laptop | do define the DeviceCMYK and DeviceRGB color spaces | 16:48.00 |
| | s/do/to/ | 16:48.09 |
| kens | I don't think we can emit multiple OutputIntents, but I may be wrong | 16:48.20 |
| mvrhel_laptop | kens: this is more for me dealing with rendering PDF-A not creating it | 16:48.42 |
| | so you need not worry | 16:48.47 |
| kens | Oh OK, fair comment | 16:48.53 |
| | I have no idea what the GS PDF interpreter does with this lot at the moment | 16:49.29 |
| mvrhel_laptop | just that I have the option -dUsePDFX3Profile which is supposed to use the output intent as the color space for the source colors that are Device colors | 16:50.04 |
| | and that works with 1 intent | 16:50.18 |
| kens | Oh, I wasn't asware of that | 16:50.20 |
| mvrhel_laptop | but does not treat DeviceGray correctly it appears | 16:50.40 |
| | likely these are rare events | 16:50.47 |
| | but something for me to tuck away in the back of my head | 16:51.00 |
| kens | Hmm, I'm not certain that PDF/X-3 can have multiple intents | 16:51.01 |
| | I'm sure its rare to ver rare though ;-) | 16:51.12 |
| mvrhel_laptop | maybe not | 16:51.13 |
| | so PDF-A1 can have output intent that is RGB or CMYK | 16:52.13 |
| kens | Hmm the spec references Adobe Technical note 5413 | 16:52.19 |
| | I shoiuld go get that too I htink | 16:52.32 |
| | PDF/X3 spec says the OutputIntent shall xontain exactly one OutptuIntent object | 16:53.12 |
| mvrhel_laptop | and PDF-A2 is the same, just mainly adds transparency | 16:53.37 |
| | kens: ok. that is good to know | 16:53.57 |
| kens | Yes PDF/A-2 basically just uses a higher level of PDF> WHen A-1 was created transparency was too flaky to rely on | 16:54.05 |
| mvrhel_laptop | ok | 16:54.11 |
| | so PDF-A could have DeviceCMYK and DeviceRGB both as long as we had output intents for these. However, I would just keep doing what you are doing as it too is valid | 16:55.06 |
| kens | Hmm, I htought you could only use Gray, and either RGB or CMYK in PDF/A-1 | 16:55.52 |
| mvrhel_laptop | oh you are right | 16:56.34 |
| | soffy | 16:56.36 |
| | sorry | 16:56.38 |
| kens | NP | 16:56.45 |
| mvrhel_laptop | then it escapes me why you would have multiple output intents | 16:57.45 |
| kens | I can't see any reason why you would, especially since the spec says : | 16:58.21 |
| | "If a file's OutputIntents array contains more than one entry, then all entries that contain a DestOutputProfile | 16:58.21 |
| | key shall have as the value of that key the same indirect object" | 16:58.21 |
| mvrhel_laptop | so they all point to the same thing | 16:58.38 |
| kens | Exactly :-) | 16:58.48 |
| mvrhel_laptop | nice spec writing | 16:58.57 |
| kens | Maybe you cna have an OutputIntent that doesn't have a DestOutputProfile | 16:59.13 |
| mvrhel_laptop | perhaps. | 16:59.30 |
| | I need to see what /OutputConditionIdentifier (sRGB) means | 16:59.57 |
| | that is in the pdf spec I think | 17:00.04 |
| kens | I'm reading the PDF spec atm, page 970 | 17:00.16 |
| mvrhel_laptop | oh I see | 17:00.34 |
| kens | Having intents for other than PDF/X looks like one reason | 17:00.49 |
| mvrhel_laptop | its just a string describring the profile | 17:00.55 |
| | so someone could read this | 17:01.04 |
| kens | I think that's the only reason its there yes | 17:01.11 |
| mvrhel_laptop | I may stick the profile name in there | 17:01.13 |
| | kens: also one final thing | 17:01.41 |
| kens | OK | 17:01.49 |
| mace | henrys: fasthosts is crap :) i'm about ready to move it to my servers | 17:01.59 |
| mvrhel_laptop | if I want to not fool with the file Title now, do I remove /Title (Title)? | 17:02.34 |
| | and it will use the current title? | 17:02.42 |
| henrys | mace:great thanks | 17:02.46 |
| kens | You need to remove the whole pdfmark | 17:02.51 |
| | It will use the existing Title if present anyway, that one is just for a default as its presence is a requirement in the spec | 17:03.15 |
| mvrhel_laptop | kens: ah ok | 17:03.35 |
| | I understand | 17:03.42 |
| | thanks kens, you cleared up much for me | 17:04.06 |
| kens | NP Michael, I'm going off now (still pretty tired, and I may have picked up a cold on the first flight) | 17:04.34 |
| | If you have more questions put them here and I'll read the lgos tomorrow | 17:04.46 |
| | logs* | 17:04.51 |
| | Goodsnight all | 17:04.58 |
| ray_laptop | kens: g'nite | 17:05.06 |
| | chrisl: I have a segfault in chunk_free_object called from jpeg_free. | 17:06.09 |
| mvrhel_laptop | ray_laptop: still need to review you patch. I will do that today | 17:06.15 |
| | s/you/your/ | 17:06.20 |
| chrisl | ray_laptop: if you can send me the details by e-mail, I'll look at it tomorrow | 17:06.45 |
| ray_laptop | chrisl: is this something you have knowledge about (ISTR that you did these changes) | 17:06.56 |
| | chrisl: OK. | 17:07.02 |
| chrisl | ray_laptop: Yeh, I was the last to have my fingers in there | 17:07.15 |
| | ray_laptop: I did find some cases of the libjpeg memory being freed in strange, out of order ways, so I may have missed one (or more) | 17:08.16 |
| ray_laptop | mvrhel_laptop: thanks. As I said, no rush. Yesterday the patch had #undef HAVE_SSE2 in it, so I took that out. Then this AM I discovered that it wouldn't compile. I've fixed that and pushed it now | 17:08.29 |
| | mvrhel_laptop: at least what I sent to the (potential) customer had the #undef in it, so it will build for them. I looked back over the email and now I need to do the SSE 4-bit implementations since they have a CPU with SSE | 17:11.21 |
| mvrhel_laptop | ray_laptop: ah. ok | 17:12.48 |
| | that should give them a nice speed-up on files with images | 17:13.06 |
| ray_laptop | mvrhel_laptop: at least it did for me. | 17:13.37 |
| | I'm going to work on the planar CMYK 4-bit next (even before the SSE 4-bit). I discovered that the pkmraw device can be set for 4-bit, planar | 17:15.03 |
| Robin_Watts | ray_laptop: Having a generic C version for all possibilites seems sensible rather than doing SSE accelerations. | 17:22.47 |
| ray_laptop | Robin_Watts: I have the generic C version -- I did that first | 17:26.11 |
| Robin_Watts | For the planar CMYK 4-bit stuff? | 17:26.30 |
| ray_laptop | The planar uses the same low level 'threshold_*' functions | 17:27.10 |
| Robin_Watts | I was attempting to agree with your plan to do a planar CMYK 4-bit version in C before doing SSE optimisations. | 17:27.23 |
| ray_laptop | I don't expect planar to take much time | 17:27.28 |
| | mvrhel_laptop: Robin_Watts: in the current code I use 'copy_color' for the non-planar mode, but I am tempted to use copy_mono/copy_planes with the hackish trick from mem_mapped4_copy_color | 17:29.46 |
| Robin_Watts | ray_laptop: I might be able to make more sense of that sentence if I could remember what the hackish trick was | 17:30.47 |
| | were you missing "... for the planar mode" at the end of that sentence? | 17:31.41 |
| | copy_color seems sensible for a non-planar mode. | 17:32.37 |
| | copy_planes (or multiple calls to copy_mono) seems correct for planar mode stuff. | 17:32.54 |
| mvrhel_laptop | yes | 17:33.00 |
| ray_laptop | Robin_Watts: I hadn't used copy_planes before. I didn't realize that it could handle depth > 1, but now I see that it does | 17:37.16 |
| Robin_Watts | ray_laptop: Right. If it were not for the need to handle depth > 1 we wouldn't have needed copy_planes. | 17:38.01 |
| | (IIRC) | 17:38.09 |
| ray_laptop | mvrhel_laptop: I compared gx_ht_threshold_landscape to gx_ht_threshold_landscape_sub -- the only thing different is the name. Do you know why we have both, or is one no yet done ? | 17:53.02 |
| | mvrhel_laptop: I know that the additive one works | 17:53.49 |
| mvrhel_laptop | ray_laptop: gosh it has been so long. I am sorry. I thought I had made and adjustment someplace else to handle the additive/subtractive issue so that I could avoid having separate procedures | 17:54.44 |
| | s/and/an/ | 17:54.51 |
| | I know that CMYK was working | 17:55.10 |
| | i.e. subtractive | 17:55.15 |
| | I had not even tried a gray (additive) case | 17:55.25 |
| | that I remember | 17:55.31 |
| | oh | 17:56.57 |
| | yes I was def. working with a CMYK device at the time I did this | 17:57.24 |
| | since we were doing planar output | 17:57.37 |
| ray_laptop | for the portrait mode, there are two different functions used: gx_ht_threshold_row_bit_sub_1 vs. gx_ht_threshold_row_bit_1 (my renamed functions) | 17:58.17 |
| | and the C code differs for those. One checks if (*contone_ptr++ < *thresh_ptr++) for additive and (*contone_ptr++ > *thresh_ptr++) for the subtractive case | 17:59.25 |
| | mvrhel_laptop: well, I'll test them out and let you know. | 18:00.49 |
| mvrhel_laptop | ray_laptop: let me look at the code real quick. will take a break from pdfa/x output in gsview | 18:01.37 |
| | ray_laptop: so I see two tests for polarity | 18:03.36 |
| | one in gxht_thresh_planes which is used for the portrait case | 18:04.10 |
| | and another that is used for the landscape case | 18:04.32 |
| | and you are saying that in the portrait case the SSE code is identical? | 18:06.15 |
| | gawd this makes my head hurt. | 18:08.51 |
| | hmmm yes, it looks like there could be an issue here | 18:10.08 |
| | with additive vs. subtractive | 18:10.15 |
| SpNg | I'm running ghostscript binaries form another a binary. I was looking reviewing 'top' on my box, and I noticed numerous processes reporting gs <defunct> what would cause this? | 18:18.31 |
| chrisl | SpNg: at a guess, you're not running with -dBATCH ? | 18:20.43 |
| SpNg | chrisl: let me check | 18:20.57 |
| chrisl | SpNg: Generally speaking, "defunct" means the parent has not "acknowledged" the completion of the child process.... | 18:22.33 |
| SpNg | chrisl: looking at my commands, it looks like I'm running -dBATCH on about 75% of them. | 18:23.18 |
| | do I need to run -dBATCH and -dNOPAUSE together? | 18:24.13 |
| chrisl | Without -dBATCH gs will drop to the GS> prompt and wait for input | 18:24.13 |
| | -dBATCH is not the same as -dPAUSE | 18:24.29 |
| | -dBATCH is not the same as -dNOPAUSE, I mean | 18:24.38 |
| SpNg | ok | 18:25.33 |
| chrisl | SpNg: you also often get defunct processes with you don't retrieve the child process exit status with something like wait() | 18:29.15 |
| SpNg | chrisl: interesting. I can add that to the code. | 18:30.21 |
| chrisl | SpNg: on most Unix like systems, the process cannot complete until the exit status has been reported - hence a defunct process is one that is "complete", but cannot be destroyed (and it's resources returned to the OS). | 18:33.28 |
| Robin_Watts | chrisl: I can't see how you'd get defunct processes from the the lack of -dBATCH then. | 18:34.17 |
| chrisl | Robin_Watts: some systems won't clean up a process with data in the I/O buffers | 18:34.55 |
| | Robin_Watts: but in truth, I doubt that's true of any modern "proper" OS | 18:35.16 |
| | Anyway, I have to go.... | 18:36.39 |
| mvrhel_laptop | need to head out for a bit | 19:00.06 |
| | Forward 1 day (to 2014/03/12)>>> | |
IRC Logs