| | <<<Back 1 day (to 2011/09/27) | 2011/09/28 |
| NoSu | This one telling of its usage: http://stackoverflow.com/questions/6183479/cropping-a-pdf-using-ghostscript-9-01 and this one with the same senario as me with an already existing cropbox: http://stackoverflow.com/questions/5797841/cropping-a-pdf-adding-crop-box-using-ghostscript | 00:19.38 |
| mvrhel2 | good night all | 04:32.20 |
| henrys | wonders if there are cliff notes for the latest batch of 70 emails from marcos. | 05:15.33 |
| tkamppeter | chrisl, alexcher, (or someone else) can you have a look at http://bugs.ghostscript.com/show_bug.cgi?id=692540, it is not yet assigned, so due to this no developer has seen it yet, but it can be something simple to quickly fix. | 06:57.32 |
| kens | tkamppeter, is there any PostScript file and command line there ? I can't see one. It'll get much more attention if it can be reproduced without using a third-party application | 06:58.48 |
| | Is the 'input' attachment PostScript ? It says its text. | 06:59.25 |
| tkamppeter | kens, yes, the input is PostScript. | 06:59.48 |
| kens | My guess is the 'zooming' is done by changing resolution, which has switched into banding mode, but that's just a guess | 07:00.19 |
| tkamppeter | kens, it only does not have the magic string for auto recognition in the first line. | 07:00.24 |
| chrisl | tkamppeter: can this be reproduced outside of xdvi? | 07:01.23 |
| kens | chrisl I think so, using the 'input' attachemnt | 07:01.35 |
| | Its really Alex's though I suspect it will end up with Ray | 07:01.49 |
| | Well, simply running the PostScript fails, because it is referencing the EPS files and using full directory paths unique to Till's machine. | 07:04.13 |
| chrisl | Yes, I just tried it | 07:04.38 |
| kens | I'd guess that the first instances can be removed. | 07:05.20 |
| chrisl | with the paths sorted, I then get a stack underflow error | 07:07.59 |
| kens | Not too good.... | 07:08.28 |
| chrisl | So, as a starting point, I think the Postscript might be broken | 07:08.58 |
| kens | The EPS or the DVI-generated PostScript ? | 07:09.18 |
| chrisl | I don't know, and I'm not really inclined to go digging. | 07:09.55 |
| kens | I'm inclined to agree. I may look more later. | 07:10.16 |
| chrisl | FWIW, when I render @300dpi to the x11alpha device, I the entire grid appears, then about half of it seems to be erased, I think, when the error occurs. Could be related, maybe not..... | 07:11.55 |
| | The EPS seems to render just fine - it really only contains an image (well, colorimage - doh!) | 07:25.20 |
| | God, that Postscript is awful :-( | 07:39.01 |
| kens | Looks it | 07:39.55 |
| chrisl | It ignores the boolean from the read op! | 07:40.44 |
| kens | read as in 'read from file' ? | 07:41.05 |
| chrisl | Yes | 07:41.30 |
| kens | That's pretty poor, if the file is not present then it will fail to catch the error | 07:41.57 |
| chrisl | In this case, we're running out of data in the file, ignoring the boolean and trying to compare the read byte with a number on the stack - hence the stackunderflow error, I think | 07:43.15 |
| kens | Well that's odd, why doesn't it happen at other resolutions ? | 07:43.53 |
| chrisl | I get it happening all the time | 07:44.38 |
| kens | Oh, so that's different to Till's experience | 07:44.56 |
| TeknoJuce | hello kens | 07:50.26 |
| kens | Hello TeknoJuce | 07:55.41 |
| TeknoJuce | did you happen to read the backlog by chance with NoSu | 07:58.38 |
| kens | Yes. | 07:58.44 |
| | I always review the overnight logs | 07:58.55 |
| TeknoJuce | is there a way to use ghost script to modify all the current boxes in a pdf that already has them in place? | 07:59.57 |
| | http://pastebin.com/RCLY3VJ1 | 08:00.52 |
| kens | No. The PDF interpreter picks the relevant ones up from the input PDF file and sets up pdfwrite to emit them. Ray's comments are correct. You either need to modify the PDF itnerpreter, or better do as he suggested and add an override in the pdfwrite source code. | 08:01.13 |
| | Or alternatively, use the pdfopt code to rewrite teh PDF file. If you re-interpret the file you stand a chance of things goign awry and data *will* be altered. | 08:01.56 |
| | If all you want to do is modify the CropBix then its better to use a tool which just does that. | 08:02.13 |
| | Using GS is a pile driver to crack a nut. | 08:02.23 |
| TeknoJuce | do you know of one? | 08:02.30 |
| kens | Not off hand, no, it woldn't be hard to write one, but the usage is so limited that it probably wouldn't be worth anyone's while | 08:02.57 |
| | pdftk would be my bet, even if it doesn't do it, it would be possible to modify it to do so | 08:03.47 |
| TeknoJuce | gs was the only thing I could find that hit on anything related to pdf manipulation and the crop/bleed/trim/etc boxes | 08:03.48 |
| kens | Yes, but it does a *lot* more than that. This is a relatively simple manipulation. | 08:04.17 |
| TeknoJuce | if i did a string replace on those values in the pdf file to the proper values do you think it would possible corrupt other encoding some how in the pdf? | 08:06.03 |
| kens | Yes. | 08:06.09 |
| | Unless you are careful to make sure that the strings are *exactly* the same length | 08:06.27 |
| | PDF is a binary format | 08:06.32 |
| TeknoJuce | ah damn | 08:06.43 |
| kens | There cna also be more than one CropBoz in a PDF file. | 08:07.14 |
| TeknoJuce | adobereader seems to only obey the first one made | 08:07.52 |
| kens | There can be one per page | 08:08.02 |
| | optionally | 08:08.06 |
| | I'm not sure Ray is correct about the CropBox being in the Catalog though, I think its only in the Page dictionary. But I would need to check the reference | 08:09.35 |
| TeknoJuce | what would be the negative side effects to gs by making it able to modify all the box values | 08:09.40 |
| kens | More proliferation of switches and paramteres, and someone would have to code it. | 08:10.09 |
| TeknoJuce | how complex would you think it is to add something like that | 08:11.05 |
| kens | Ray suggested using the existing TrimBox code as a template. I haven't looked at it so I don't know how much work thre is. Its probably not too hard, especially if there is code which does something simlar | 08:11.44 |
| TeknoJuce | do you happen to know off hand what the command to manipulate the existing TrimBox I didnt seem to notice anything like that in use doc just some triggers to specify whether or not it uses the trip or crop box | 08:14.33 |
| kens | I don't believe there is such a switch/parameter | 08:15.02 |
| | There is a witch for PDF/X otuput called PDFXTrimBoxTomediaBoxOffset | 08:15.30 |
| | switch | 08:15.34 |
| | Looks like what you want | 08:16.07 |
| | It adds a specified offset (4 ofsfets) to the MediaBox and sets teh TrimBox to that. | 08:16.44 |
| | You could reasonably easily use a similar switch to set the CropBox from a similar switch | 08:17.03 |
| TeknoJuce | ah I was hoping for something like how I attempted to use the pdfmark, 14.-c "[/CropBox[32.4 43.2 937.554 1672.56]/BleedBox[32.4 43.2 937.554 1672.56]/ArtBox[32.4 43.2 937.554 1672.56]/MediaBox[0.0 0.0 969.954 1715.76]/TrimBox[32.4 43.2 937.554 1672.56] /PAGES pdfmark" ^ | 08:17.30 |
| kens | THat won't work. | 08:17.41 |
| | You would need one switch per Box, teh somethign like: | 08:18.42 |
| | -sSetTrimBoox=[100, 100, 100, 100] -sSetCropBox=[100, 100, 100, 100] | 08:18.42 |
| | and so on | 08:18.42 |
| TeknoJuce | yeah that would be totally acceptable sorry I didnt see your comments after trimboxtomediabox I thought that was just making one box the same co-ords as the other box | 08:22.22 |
| kens | No, its adding a specified amount to each side of the box. | 08:22.42 |
| | It would be straight-forward to use a specific value instead of adding it. | 08:23.00 |
| | However, at the moment I can't see where teh CropBox is being written by pdfwrite..... | 08:23.25 |
| TeknoJuce | :/ | 08:23.35 |
| kens | Well, its got to be in there somewhere..... | 08:24.38 |
| TeknoJuce | when I used the pdf mark code and deleted the first cropbox in the code it strangely enough made the page crop properly :S | 08:24.42 |
| kens | Well you shouldn't have two CropBox entries in teh page dictionary. | 08:25.12 |
| | Anyways, if someone wants to put a patch together for it, I'll certainly consider it for inclusion in a future version. | 08:25.44 |
| | If nobody wants to do the work, then you cna open an enhancement request for it, but I should warn you that its unlikely I'll ever get round to implementing it. | 08:26.26 |
| TeknoJuce | if you had to toss out a time frame of how long it would guestimatly take you to code something like that what do you think? | 08:27.52 |
| kens | I suppose a day or so. | 08:28.03 |
| | Including testing obviously | 08:28.13 |
| TeknoJuce | Even though your analogy with the large smashing device and a nut thing I find it strange that nobody has ever requested anything like that as the only other tool that can really do it is like distiller/etc | 08:30.28 |
| kens | Well what you want to do is relatively simple, just change some numbers in the page dicitonary. | 08:30.59 |
| | You could do that by parsing the file, modifying the numbers and updating the xref table. | 08:31.16 |
| | Potentially decompressing the data stream. | 08:31.27 |
| TeknoJuce | that may sound simple for the likes of you :) | 08:31.46 |
| kens | If you use GS it will interpret the entire PDF file down to its marking operations, then use the marking operations to construct a totally new file from the ground up. | 08:31.56 |
| | Objects may be transformed in the process. | 08:32.18 |
| | For example; text rendering modes may be converted into sequences of stroke and fill, instead of text. | 08:32.41 |
| | Text in obscure font types may be converted into bitmaps | 08:33.00 |
| TeknoJuce | I noticed that the news papers colours we're all off after I first tried a render of it | 08:33.08 |
| kens | Shading dictionaries may be converted to images. | 08:33.12 |
| TeknoJuce | and the fonts were all jaggy around their edges | 08:33.23 |
| kens | That sounds liek you might eb using an old version. | 08:33.48 |
| | Or the file contains transparency | 08:34.03 |
| TeknoJuce | then I used that prepress setting and it seem to fix it | 08:34.04 |
| kens | Oh well if you use PDFSETTINGS then it probably downsampled images, amongst other thigs. | 08:34.30 |
| | It might also alter the default colour space and convert everything to RGB. | 08:34.45 |
| TeknoJuce | I first didnt use that pdfsettings and thats what seem to happen | 08:34.57 |
| kens | Best not to use those without good reason | 08:34.58 |
| | The default settings are to preserve everything. | 08:35.15 |
| | As unchanged as possible | 08:35.25 |
| TeknoJuce | I was using the stable release that is currently on the website | 08:35.28 |
| | ideally if you are like anything like xbmc than that is old code :D | 08:35.58 |
| kens | Its a few weeks old | 08:36.11 |
| | You can always pull a code snapshot from the repository and build it. | 08:36.26 |
| TeknoJuce | I will check out this pdftk as you say the only thing I want to do seems pretty simple and it says it uncompress pdf page streams for editing the pdf code in a text editor | 08:41.24 |
| kens | Indeed it does. | 08:41.37 |
| | Amongst many other things | 08:41.43 |
| TeknoJuce | though not sure how quick that would be to uncompress change recompress for batches of files | 08:42.17 |
| kens | FWIW Ghostscritp can do that too, as can MuPDF | 08:42.19 |
| | I owuld say much quicker than interpreting the PDF file, and creating a new one. | 08:42.39 |
| | Since interpreting the file requires decompressing and reading the entire contents. | 08:43.05 |
| TeknoJuce | yeah I would like to touch the document as less as plausible as its a newspaper design the way it is for a purpose | 08:43.33 |
| | not sure if I would ruffle a few feathers if stuff in it is all off | 08:43.55 |
| kens | THen I would suggest *not* using GS+pdfwrite as it will (like I said) competely rewrite the file. | 08:44.00 |
| | We do have customers who do that, but htey have good reasons | 08:44.30 |
| TeknoJuce | I noticed that how the pdf afterwards was more readable line by line after gs hit it | 08:44.50 |
| kens | You could read it ? Sounds like it wasn't compressed..... | 08:45.07 |
| TeknoJuce | well the encoding instead of mass chucks of data it was more line by line | 08:46.16 |
| kens | Oh, well that's a comparatively minor part of hte content. The real changes would be in the page contents whcih are usually compressed. | 08:47.03 |
| TeknoJuce | what is fwiw ghostscript? | 08:47.54 |
| kens | For What Its Worth, Ghostscript... | 08:48.17 |
| TeknoJuce | oh haha thought it was a fork or something | 08:48.32 |
| kens | The only fork of GS is GPL Ghostscript, which isn't very different. There was ESP Ghostscript, but that is ancient history now. | 08:49.16 |
| TeknoJuce | well if you hear or think of anything else that can help me, if I cant get any of your other notes working please let me know I am 24/7 on irc freenode for xbmc.org | 08:53.55 |
| | thanks for your information so far | 08:54.06 |
| kens | No problem. | 08:54.11 |
| chrisl | kens, tkamppeter: I'm giving up on 692540 - the PS is just too weird. I think it should be referred to the xdvi people to create a simple/sensible example that illustrates the problem. TBH, it's using a lot of Ghostscript-specific operators which I would term as being "internal use only", and further subject to change without notice etc...... | 08:56.17 |
| tkamppeter | chrisl, OK, will tell the reporter of the bug that it is an XDVI bug and he should report it there ... | 09:06.27 |
| | chrisl, can you also comment on the bug report? Thanks. | 09:06.50 |
| chrisl | tkamppeter: I'll update the bug in a bit - I'm not totally sure that it's an xdvi problem, but I think even if it isn't, it'll need the xdvi devs' input for us to resolve it, without wasting a fair amount of time. | 09:08.17 |
| tkamppeter | chrisl, OK. | 09:11.09 |
| kens | Heading off, back in a couple of hours. | 09:23.11 |
| Robin_Watts | turns the aircon on. | 11:41.26 |
| | Crap. | 12:11.16 |
| kens | aircon not working ? :-) | 12:11.53 |
| Robin_Watts | I had hoped to call getbits to convert the T plane passed to strip_copy_rop from planar to chunky. | 12:11.57 |
| | But in order to be able to read from a planar T plane, we need to know the raster and the height of the T plane. | 12:12.44 |
| | (so we can work out the plane to plane offset) | 12:13.00 |
| | We have the raster offset, but we don't have the height. | 12:13.36 |
| | And I can't see a way of passing it in | 12:13.42 |
| kens | Then you either need to change the interface or make it a global or something I guess | 12:14.03 |
| Robin_Watts | Not only that, but the default code doesn't know about planar format. | 12:14.13 |
| | That's all handled in the device. | 12:14.18 |
| kens | Starting to sound like the wrong approach.... | 12:14.31 |
| Robin_Watts | and if I make an explicit check for 'are we planar' and then jump back to the device routine that'll have the effect of always linking it in whether it's needed or not. | 12:14.53 |
| | So yeah... | 12:14.56 |
| | The alternative approach is pretty icky. | 12:15.17 |
| | I have to expand the T plane to a temporary chunky buffer before making the strip copy rop call. | 12:15.52 |
| kens | Robin_Watts : got a minute ? | 12:50.08 |
| Robin_Watts | sorry, was at lunch. | 13:41.28 |
| | go for it. | 13:41.30 |
| kens | I'm hacing some trouble trying to do the stroke/fill colour stuff. | 13:41.48 |
| Robin_Watts | oh, eck. | 13:42.01 |
| kens | The colours stored in pgs->color[x].dev_color always seem to have the type 'non' instead of 'pure' and the PDF code only deals with pure colours. | 13:42.32 |
| | Now when the 'current' colour is passed in I see that it has a type of 'pure'. | 13:43.00 |
| | an you tell me where pgs->color[] get set please ? I only see it being used in gs_swapcolors | 13:43.22 |
| Robin_Watts | Let me refresh my memory on this stuff. | 13:43.54 |
| LTScribble | Does anyone know what version of GPL is ghostscript under? | 13:44.14 |
| kens | I'm not surprised you can't remember, I'm having that problem myself. Been a long time since I looked at colour handling in pdfwrite | 13:44.20 |
| | LTScribble doesn't the LICENCE file tell you ? | 13:44.37 |
| Robin_Watts | Version 3, I believe. | 13:44.52 |
| kens | thought it was 2 but is prepared to be wrong | 13:45.06 |
| | LICENCE says version 3 | 13:45.35 |
| Robin_Watts | OK, so before my changes we had a single 'color_space', 'ccolor' and 'dev_color'. | 13:47.11 |
| kens | Which are the same as in the gs_drawing_color structure I think | 13:47.39 |
| | Ah, actually not. | 13:48.03 |
| Robin_Watts | The color operators would set ccolor, and that would 'clear' dev_color. | 13:48.24 |
| kens | Mm, OK | 13:48.44 |
| Robin_Watts | Before a color operation was used, a call was made to 'resolve' dev_color. | 13:48.45 |
| | Let me try and find that call... | 13:48.55 |
| kens | Please. | 13:49.01 |
| | I'm guessing I may have to do the same in order to use dev_color | 13:49.15 |
| Robin_Watts | (gx_unset_dev_color is where it's unset) | 13:49.35 |
| kens | so gx_set_dv_color maybe ? | 13:49.54 |
| Robin_Watts | yes, looks like it. | 13:50.07 |
| | That's an EVIL macro that must be destroyed. | 13:50.31 |
| | Seriously. | 13:50.34 |
| kens | Its a macro ? ! | 13:50.39 |
| Robin_Watts | Yes. | 13:50.47 |
| kens | Well that explains why my grep didn't find it.... | 13:50.57 |
| | Was looking in *.c | 13:51.08 |
| Robin_Watts | Ctrl-Shift-F in VS works well. | 13:51.10 |
| kens | Yes, that too | 13:51.20 |
| | I use both at different times | 13:51.29 |
| Robin_Watts | #define gx_set_dev_color(pgs)\ | 13:51.33 |
| | if ( !color_is_set(gs_currentdevicecolor_inline(pgs)) )\ | 13:51.35 |
| | { int code_dc = gx_remap_color(pgs);\ | 13:51.36 |
| | if ( code_dc != 0 ) return code_dc;\ | 13:51.39 |
| | } | 13:51.40 |
| kens | Yes, I have it here now | 13:51.43 |
| Robin_Watts | Having a return inside a macro is unforgivable. | 13:51.43 |
| kens | I think it mentions that in the C code somewhere | 13:51.53 |
| | With an exclamation mark in the comment | 13:52.01 |
| Robin_Watts | That may well have been me :) | 13:52.09 |
| kens | No, I think its older than that. | 13:52.31 |
| | SO basically it calls gx_remap_color. WHich is no good to me as I don't want to set the colour which is currently in the graphics state, I want the other one. | 13:53.04 |
| | I'll have to find out what gx_remap_color is doign. | 13:53.18 |
| Robin_Watts | So you want to gs_swapcolors_quick, then call that ? | 13:53.37 |
| kens | Essentially. I was hoping to do it with just the colours directly from the array. | 13:53.59 |
| | I'm in C here, not PostScript so I should be able to go with what I have. | 13:54.15 |
| Robin_Watts | If I was you, I'd get it working using gs_swapcolors_quick() and then optimise it later. | 13:54.27 |
| | All the remap stuff assumes it's working with color[0] currently, IIRC. | 13:54.52 |
| kens | Yeah, it looks like that will work, and its probably easier than meddling with gx_remap_color | 13:55.02 |
| Robin_Watts | Yeah, gz_remap_color uses gs_currentcolorspace_inline and gs_currentcolor_inline and gs_currentdevicecolor_inline etc. | 13:55.34 |
| kens | Bascially I need to get the 'stroke' and 'fill' colours independently, but that looks doable | 13:55.36 |
| Robin_Watts | gx_remap_color could be altered to take the color number too... | 13:55.46 |
| kens | OK thanks, that tells me where to go nest at least. | 13:56.00 |
| | This is a horrible mish-mash of work in pdfwrite and work in the PDF itnerpreter, its not at all pleasant | 13:56.23 |
| | Thanks for your time. | 13:56.32 |
| Robin_Watts | #define gx_set_dev_color(pgs) (color_is_set(gs_currentdevicecolor_inline(pgs) ? 0 : gx_remap_color(pgs) | 13:57.04 |
| | That'd be a much nicer macro. | 13:57.11 |
| kens | Doesn't check the return code though ? | 13:57.33 |
| Robin_Watts | Then the callers of each macro would be responsible for checking for a non zero return code and handling it. | 13:57.34 |
| | Makes the return explicit rather than hidden. | 13:57.50 |
| | hence removing my objection to it. | 13:57.58 |
| kens | Right, which probably isn't that bad, I don't think it gets called in that many places | 13:58.01 |
| | Which IMO means it doesn't need to be a macro ;-) | 13:58.21 |
| Robin_Watts | I see 10 places. | 13:58.30 |
| kens | That's not many | 13:58.38 |
| Robin_Watts | I don't object to macros if they are clear and well defined in meaning. | 13:58.58 |
| kens | Please don't make any changes until I've got this mess straightened out though :-) | 13:59.02 |
| | I also *much* prefere macro names which make it clear they are macros | 13:59.19 |
| Robin_Watts | But hiding returns is unforgivable. | 13:59.26 |
| kens | And not functions | 13:59.29 |
| Robin_Watts | I dunno about that; it's often nice to have macros behave (as much as possible) as if they are functions. The difference is just an implementation detail that shouldn't concern the reader of the code. | 14:00.20 |
| kens | It annoys me intensely as I can't debug into a macro. | 14:00.50 |
| Robin_Watts | But hidden control changes in macros (like returns or gotos) breaks the "principle of least surprise". | 14:00.50 |
| kens | On the whole I don't like macros much. | 14:01.07 |
| Robin_Watts | I've done a lot of work on code for embedded devices where every cycle counts; hence macros can really help to avoid function call overheads. | 14:01.47 |
| kens | I'd rather just see the code reproduced in the source. | 14:02.08 |
| Robin_Watts | but yes, I've written code that uses function calls in debug builds and macros in release before. | 14:02.24 |
| | (but that's a whole new source of bugs unless you're very careful) | 14:02.45 |
| kens | Yeah, and that can be even more confusing, especially if someone screws up one fo them, but not the other.... | 14:02.49 |
| | (JasPer authours, are you there ...?) | 14:03.01 |
| | Anyway, to code! | 14:03.50 |
| chrisl | marcosw_: ping? | 14:04.07 |
| kens | thinks chrisl is being highly optimistic | 14:04.21 |
| chrisl | He has just raised and edited a bug, so he is awake....... | 14:04.40 |
| kens | Hah, you can run but you can't hide..... | 14:04.57 |
| chrisl | But yeh, it is a bit early - I thought it an hour later over in SF | 14:06.26 |
| chrisl | thinks I might have to get a more modern Mac at some point - an G4 Mini doesn't really cut it, these days :-( | 14:07.32 |
| Robin_Watts | thinks it's a shame that Apple don't see MacOS X VMWare images. | 14:08.18 |
| | s/see/sell/ | 14:08.26 |
| | Cos there are lots of people that would fork out for one of them, but are reluctant to buy a real mac. | 14:09.18 |
| chrisl | Yeh, that would be excellent! Although, they'd probably charge so much, "e-bay special" metal would be probably still be cheaper | 14:09.33 |
| henrys | so apple should sell mac os x images so they'll sell less hardware ;-^ | 14:10.44 |
| | chrisl:the imac is probably a good deal. | 14:10.56 |
| chrisl | henrys: I'd prefer a Mac Mini, less real estate! | 14:11.25 |
| Robin_Watts | henrys: No, they could pitch it right so that they'd sell to people that wouldn't otherwise buy a mac. | 14:11.33 |
| marcosw_ | chrisl: morning | 14:12.41 |
| henrys | Robin_Watts:according to apple those people are just temporarily confused. They might be right the way they're growing. | 14:13.06 |
| chrisl | hi marcosw_, it was to say, if you have time to try the lipo thing, that would be great - I'd have to login to Henry's machine, so it would be a bit of pain for me. | 14:13.32 |
| marcosw_ | no problem. I'll have time this afternoon. | 14:13.56 |
| chrisl | And I spent a good while yesterday looking for a utility like that, but I missed it :-( | 14:14.04 |
| Robin_Watts | henrys: Ah, but that was the cult of Jobs... | 14:14.05 |
| | henrys: Lion is a huge step back from Snow Leopard afaict. | 14:14.51 |
| | And Ubuntu 11 is horrible compared to 10. | 14:15.03 |
| henrys | yes I am disappointed | 14:15.11 |
| | chrisl:a hackintosh is possible, I won't tell if you don't. | 14:15.39 |
| | dual boot no new machine. | 14:16.09 |
| Robin_Watts | I moved from Ubuntu 11 on a Live flash drive to Ubuntu 11 installed properly on a flash drive on Company I's board. | 14:16.25 |
| | Now, the times have dropped to 5 minutes something. | 14:16.39 |
| | And the oprofile profile looks plausible. | 14:16.54 |
| chrisl | henrys: I tried hackintosh and other variants a few years ago, but I never got OS X to run right - it "worked", but only sort of.... | 14:16.58 |
| Robin_Watts | chrisl: A perfect simulation of Lion then. | 14:17.14 |
| chrisl | Robin_Watts: Ubuntu's new UI is dreadful, isn't it? I've been using Linux for >15 years, and Ubuntu for >5 years, and it took me a *long* time to find out how to get a terminal window up - not using that! | 14:18.05 |
| henrys | my only issue with lion is performance, in particular finder going crazy and taking a cpu. | 14:18.09 |
| Robin_Watts | Their new 'gestures' are all useless - they removed all the previous useful ones :( | 14:18.43 |
| chrisl | Looks like I can get a used core2 Mac Mini for £200-£300 - that might be the way to go....... | 14:19.10 |
| henrys | I never was big on gestures and I've gotten used to backward scrolling. | 14:19.17 |
| LTScribble | Thanks for the info about the GPL. Does anyone know if Artifex are still dealing with commercial licenses as there website is dead? | 14:25.51 |
| kens | We still do commercial licencing, I will check the website | 14:26.12 |
| | http://www.artifex.com works for me | 14:26.27 |
| chrisl | and me..... | 14:26.34 |
| LTScribble | strange, just times out for me | 14:27.25 |
| chrisl | LTScribble: you can contact sales@artifex.com for commercial enquiries | 14:28.20 |
| kens | Which country are you in LTScribble ? | 14:28.32 |
| LTScribble | UK | 14:28.40 |
| kens | Hmm, well so are Chris and I so it is unlikely to be a routing problem | 14:28.55 |
| | We have different ISPs | 14:29.03 |
| chrisl | Hmmm, Dell seems to have stopped selling the Zino mini-PC - that's a shame :-( | 14:29.47 |
| Robin_Watts | works for me too (another UKer, on another ISP) | 14:29.52 |
| chrisl | I have seen artifex.com got through a period of time outs for me, but not for quite a long time. | 14:31.10 |
| LTScribble | how peculiar | 14:31.32 |
| | okay, I've got the e-mail address via google cache. Thanks. | 14:33.02 |
| henrys | hmm the artifex website now has a fixed layout? The page doesn't expand with the frame in either chrome or firefox. | 14:46.43 |
| chrisl | I hadn't noticed that before | 14:47.34 |
| henrys | I am sure it is recently introduced, miles has had somebody workign on the web page I'll report it to him. | 14:49.36 |
| | amazon's new kindle looks pretty cool, nice price too. | 15:52.13 |
| Robin_Watts | silk sounds interesting. | 15:58.48 |
| | henrys: Sounds like they REALLY need a PDF viewer :) | 16:09.12 |
| henrys | we really did try | 16:10.13 |
| | I sent mail about indenting. | 16:11.28 |
| Robin_Watts | 193Meg of maill! | 16:14.45 |
| henrys | marcosw_:you don't have a duplexor in the 4500 do you? Trying to figure out why our results are different for 2p.pcl | 16:14.50 |
| Robin_Watts | Interesting. The UK doesn't get the option of the kindle touch. | 16:18.51 |
| | or the ad sponsored one. | 16:18.56 |
| henrys | marcosw_ has dropped several mail bombs - restarting servers I assume. | 16:19.02 |
| kens | joy :-( | 16:19.11 |
| Robin_Watts | I wonder what stops you buying the ad sponsored one in the states and just bringing it here. | 16:19.24 |
| marcosw_ | henrys: both of my printers have duplexors, but I'd be surprised if thet is the difference. | 16:33.44 |
| | while I was looking into the casper email problems I realized that the daily regression emails hadn't been going out since I upgraded my iMac to Lion. | 16:35.07 |
| arthurf | I have a damaged PDF that fails outright in Ghostscript v9.00. Failing is good in that case and returns an exit code of 1. In v9.04, a warning message is displayed, content is omitted, and an exit code of 0 is returned. | 16:45.49 |
| kens | Correct. I f you don't want that thn set -dPDFSTOPONERROR | 16:46.21 |
| arthurf | Perfect. Thank you. | 16:46.37 |
| Robin_Watts | mvrhel2: I need a sanity check with respect to the direction I'm taking with this strip_copy_rop stuff. | 17:13.58 |
| | Can you tell me when you have a few minutes to talk please ? | 17:14.22 |
| kens | Right off now, night all | 17:20.46 |
| henrys | needs mvrhel2 too! gxclist.c:"fixme: Also, if icc_cache_cl is not included in the writer, 64bit builds will seg fault */" | 17:21.07 |
| mvrhel2 | really? | 17:21.41 |
| Robin_Watts | TADA!!!!!! | 17:24.31 |
| mvrhel2 | Robin_Watts: oh good. does that mean you dont need me | 17:27.58 |
| henrys | mvrhel2: 691652 icc_cache_cl is invalid when enumerating pointers hence my question about you comment. | 17:30.31 |
| mvrhel2 | henrys: this only happens on 64 bit ? | 17:31.12 |
| | oh yes | 17:31.35 |
| henrys | I don't have a 32 bit machine. | 17:31.41 |
| mvrhel2 | I remember thsi | 17:31.42 |
| | let me see if the issue happens on my machine | 17:31.55 |
| Robin_Watts | mvrhel2: I'd like your opinion as to whether there is a better way to be doing this. | 17:33.04 |
| henrys | -Z\? will show when the enumeration returns a bogus pointer. | 17:33.15 |
| Robin_Watts | henrys: Really? How does it know? | 17:33.34 |
| ray_laptop | Robin_Watts: it searches the chunk list to find the object | 17:34.11 |
| Robin_Watts | What if it points to something not in a chunk ? | 17:34.31 |
| ray_laptop | then it should not be enumerated | 17:35.15 |
| Robin_Watts | So all gc-able stuff needs to be inside a chunk allocator ? | 17:35.54 |
| ray_laptop | if it is supposed to be in a chunk and it's not, then it will print the error message | 17:36.16 |
| henrys | there are severaly conditions where it will report a bad object see - ilocate 551, I realize memento might be useful if that is the direction of this. | 17:36.17 |
| Robin_Watts | henrys: I am ashamed to admit that I hadn't thought of Memento yet :) | 17:36.46 |
| ray_laptop | Robin_Watts: not a chunk manager chunk, but a chunk of the ialloc allocator (both the chunk manager and the GC (ialloc) use chunks) | 17:37.03 |
| Robin_Watts | oh gawd. language overload. OK. | 17:37.26 |
| ray_laptop | chunk is a bit overloaded. sorry | 17:37.48 |
| Robin_Watts | The rop stuff uses chunk to mean something else as well :) | 17:38.15 |
| ray_laptop | gc structures should not enumerate pointers if they aren't also allocated as gc structures | 17:38.43 |
| Robin_Watts | Right, that makes perfect sense. | 17:38.59 |
| henrys | but anyway I thought mvrhel2 might have something quick to say about the clist/icc comment otherwise I can keep digging. Note this is the pattern clist usage not regular clies. | 17:39.29 |
| | s/clies/clist | 17:39.42 |
| ray_laptop | mvrhel2: I thought you were going to set a data breakpoint (and use -Z@) to find out who was freeing the icc_cache_cl ? | 17:40.07 |
| mvrhel2 | I am doing that now | 17:40.19 |
| | switching out of my work on the overprint stuff | 17:40.31 |
| | hold on | 17:40.34 |
| henrys | and the comment is a bit obscure or maybe I'm not parsing it correctly. | 17:41.33 |
| ray_laptop | mvrhel2: BTW, I just did the commit that ref_count decrements the icc_ stuff in the imager_state. That passed a cluster test and seems OK from the debugger | 17:41.57 |
| mvrhel2 | great | 17:42.07 |
| | so that fixes the handle issue? | 17:42.13 |
| ray_laptop | but your bug pre-dates that change so a pre-mature free of the clist elements shouldn't be an issue | 17:42.43 |
| | mvrhel2: yes, it fixes the handle issue (I hope for the last time). We just all have to be careful when using semaphores to make sure to get a gx_semaphore_free done sometime | 17:43.52 |
| mvrhel2 | yes | 17:44.01 |
| ray_laptop | I need to update the bug with the commit so that Marcos can notify Raed. | 17:44.37 |
| henrys | mvrhel2:so you are taking this one over? | 17:48.02 |
| mvrhel2 | well, let me see if I get the crash first | 17:48.19 |
| | so far it is just running and running | 17:48.24 |
| henrys | okay | 17:48.27 |
| | did you use -Z\? | 17:48.38 |
| mvrhel2 | I was just using the command line that you used on comment 4 | 17:49.38 |
| henrys | I would think the data breakpoint would be fouled by relocation. | 17:49.40 |
| mvrhel2 | yes and data breakpoints are fragile to relocation | 17:50.17 |
| | s/and/any/ | 17:50.22 |
| ray_laptop | if the structures are large enough to go into their own chunk, they'll never be reloc'ed | 17:50.57 |
| mvrhel2 | this structure is not that large | 17:51.20 |
| | gawd this is slow | 17:51.40 |
| ray_laptop | you can also place a breakpoint on the: RELOC_VAR(cdev->writer.icc_cache_cl); | 17:52.13 |
| henrys | with -Z@ I can get it to infinite loop it isn't very slow. | 17:52.29 |
| mvrhel2 | right now I am just seeing if I get the crash | 17:52.30 |
| | oh maybe that is what I am doing | 17:52.42 |
| ray_laptop | so that you can update your data breakpoint when (if) it gets reloc'ed (sort of a pain). | 17:52.48 |
| henrys | I imagine if you break now you should be in the mess. | 17:52.57 |
| mvrhel2 | it was off in the middle of a color interpolation | 17:53.43 |
| ray_laptop | just got an update from cust 532 -- back to their stuff ... | 17:55.01 |
| henrys | it crashes for me in less than 10 seconds without memory debugging options | 17:55.09 |
| mvrhel2 | that does not happen for me | 17:55.18 |
| | it is still chugging | 17:55.26 |
| henrys | you're 32 bit? | 17:55.41 |
| mvrhel2 | yes | 17:55.46 |
| henrys | well I'll see if I can track it down further. | 17:56.24 |
| mvrhel2 | the file finished | 17:56.29 |
| | rerunning with -Z@? | 18:04.03 |
| | ok so it ran fine iwht -Z@? | 18:11.37 |
| | with | 18:11.45 |
| henrys | why woudn't the code work 64 bit like the comment says? | 18:13.14 |
| | just curious | 18:13.21 |
| | you are storing this table in max band + 1 I know the pattern stuff just uses 1 band in special case code. Has this been accounted for? | 18:15.07 |
| mvrhel2 | henrys: good question | 18:16.21 |
| | I don't remember why I wrote that comment. other than I recall having something odd going on with this part and 64 bit so I made the comment | 18:16.55 |
| ray_laptop | I'll test on 64-bit Windows ... | 18:17.28 |
| Robin_Watts | Damn. My TADA was premature :( | 18:20.12 |
| | Is it too late to claim that the planar device was a really bad idea? | 18:20.48 |
| henrys | Robin_Watts:yes a bit late. | 18:22.36 |
| Robin_Watts | better try and fix it then. | 18:23.14 |
| mvrhel2 | planar is a good idea | 18:24.23 |
| Robin_Watts | mvrhel2: Not for anything involving ROPs it's not. | 18:24.38 |
| mvrhel2 | laser printers love planar data | 18:24.52 |
| Robin_Watts | I'm prepared to believe that for 1 bit halftoning, planar data is better. | 18:25.32 |
| | When we start to think about n-bit halftoning, I strongly suspect that we'd be better off staying in contone all the way through and then having optimised chunky -> n bit halftoning code at the end of the pipeline. | 18:26.21 |
| henrys | Robin_Watts:maybe you can get chris to add memento to autoconf so it is a bit more like the project files. | 18:26.42 |
| Robin_Watts | henrys: make debug XCFLAGS="-DMEMENTO" ? | 18:27.07 |
| | But you'd rather "make memento" ? | 18:27.27 |
| | and have a separate build dir/exe ? | 18:27.47 |
| henrys | well you added special directories and stuff... | 18:27.53 |
| mvrhel2 | Robin_Watts: yes as we approach contone bit depth, doing color conversion -> planar-> halftone makes sense at the end | 18:27.53 |
| | brb | 18:28.16 |
| Robin_Watts | OK. Either chrisl or I can add that. I'll talk to him about it. | 18:28.18 |
| ray_laptop | I think 4-bit CMYK for PCL with Rops is the bad idea. Planar or not. | 18:34.03 |
| henrys | ray_laptop:are you able to see the problem on 64 bit windows? It does seem to corrupt memory and fail differently with different options for me. | 18:35.27 |
| ray_laptop | this file (bug 691652) has _lots_ of pages and pattern-clist on just about every page. -Z@$?: | 18:35.30 |
| | henrys: still running. Definitiely NOT right away | 18:35.47 |
| Robin_Watts | planar CMYK with ROPs, irrespective of bitdepth; in order to even attempt it, you need to 'break the planarness' by pulling each pixel together, do the rop, and then split it out again. | 18:35.47 |
| | The moment you're doing that, I suspect you're better off keeping it all together in the first place. | 18:36.15 |
| ray_laptop | not seeing ANY messages from ilocate and no problems -- not sure what page I'm on. | 18:36.30 |
| | latest page was at 350 seconds ... | 18:37.13 |
| henrys | I just recompiled with MEMENTO and can't get it fail either. | 18:37.21 |
| | I haven't updated to your most recent change though. I wonder if that is related. | 18:39.06 |
| ray_laptop | mvrhel2: BTW, you can change the chunk size to a smaller value and it _might_ prevent reloc in most cases: -M# | 18:40.46 |
| ray_laptop | hasn't ever tried that option :-/ | 18:41.10 |
| henrys | lunch | 18:43.02 |
| ray_laptop | henrys: just finished -- no problems on Win64. 22 pages in 515 seconds | 18:43.03 |
| | now I'm _really_ going off to work on cust 532 issue ... | 18:44.09 |
| mvrhel2 | ray_laptop: ok so I am not completely crazy then | 18:46.03 |
| henrys | I wonder if this got fixed somehow I updated my code and can't reproduce it. | 19:17.28 |
| | I'd think I was crazy if the reporter didn't have the exact same problem. | 19:17.53 |
| Robin_Watts | mvrhel2: I'm going to give up for the night fairly soon. Any chance of talking before I do? | 19:19.08 |
| mvrhel2 | Robin_Watts: I am sorry. I have to head out right now. Parent teacher conference. Can we chat tomorrow morning about it? | 19:36.37 |
| Robin_Watts | Sure. | 19:36.44 |
| mvrhel2 | is there anything that I can look at tonight? | 19:36.46 |
| | or this afternoon | 19:36.51 |
| | to be up to speed | 19:37.02 |
| Robin_Watts | No, I've not got anything committable yet. | 19:37.12 |
| | I'll burble the outline of the problem here, so you can read it in your logs when you get back and mull it over. | 19:38.12 |
| | The problem I'm seeing here is that this PCL file is setting up a pattern tile. Because we are going to a planar device, that's being set up as a planar buffer. | 19:39.24 |
| | We then use the 'rop source' device with that pattern tile as it's texture. | 19:39.47 |
| | When we have to 'fill rectangle' in that device, it does a strip_copy_rop with the pattern tile as T. | 19:40.40 |
| | strip_copy_rop assumes that S and T are in chunky format. | 19:41.23 |
| | The solution I have in mind, and that I'd like your opinion on is as follows: | 19:41.59 |
| | 1) When we come to call strip_copy_rop from the tiling stuff, we spot that it's a planar tile, and set an extra bit in the 'lop'. | 19:42.35 |
| | 2) The planar devices strip_copy_rop spots this bit (lop_t_is_planar) and allocates a temporary chunky buffer, converts t into it, then does the strip_copy_rop, then frees the buffer. | 19:43.35 |
| | I'm having some problems with the code at the moment, but I haven't run into any showstoppers (yet!). | 19:44.08 |
| | It's possible that we can (for common cases) implement the rop cores that know about t being planar, and hence avoid the extra call - but I want to get the general case working first. | 19:45.00 |
| | However, this does beg the question - is this the right approach at all? | 19:45.30 |
| | It means that we end up converting the T into chunky form on every strip_copy_rop (until we do optimised versions at least). | 19:46.12 |
| | It might be nicer to spot that the tile that's used as the rop source is planar and convert it to chunky once and for all when we open the rop source device. | 19:47.20 |
| | But that probably requires a greater understanding of the pattern tile cache than I currently have. | 19:47.43 |
| henrys | in my new found capacity as "bisect bitch" I found the bug 691652 was fixed in http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=36925c8f0864e8ecd54625011696d4bcdbc26fcc | 20:23.35 |
| | next bug... | 20:27.36 |
| mvrhel2 | henrys: are you here | 21:28.55 |
| henrys | yup what's up | 21:30.25 |
| | ? | 21:30.27 |
| mvrhel2 | oh. I glanced a bit at the xps bugs | 21:30.39 |
| henrys | great | 21:30.50 |
| | I closed your bug that you already fixed ;-) | 21:31.16 |
| mvrhel2 | I am pretty sure they are *not* all color related. However, I am pretty familiar with these files. If you want me to start taking what I consider to be the low hanging ones, I could work a bit on them after I wrap up this overprint bug | 21:32.00 |
| henrys | sure and if there is any evidence they aren't graphics assign them back to tor. | 21:32.48 |
| | s/graphics/color | 21:32.57 |
| mvrhel2 | ok | 21:33.39 |
| | also, next week I am off to Maui with the family but I will still be working. Just my hours may be a little bit shifted. I bought tickets for super cheap about 6 months ago. With our lack of summer here my wife pressed me to get us some place where there is sun. | 21:36.58 |
| | although the last month here has been quite pleasant | 21:37.40 |
| henrys | that's great I like Maui but I've been there 3x ... | 21:37.49 |
| mvrhel2 | yes. I think this is my 4th time... I suppose I should think of going someplace else but it is convenient from here | 21:38.36 |
| sebras | this was a nice graph: http://qa.debian.org/popcon.php?package=mupdf | 22:16.28 |
| mvrhel2 | ah. I think I found an easy fix for bug 692494 | 22:25.59 |
| | sebras. that is a pretty cool graph | 22:26.13 |
| | turns out the current color is valid when we check for nonzero components | 22:26.52 |
| | but for some reason we check the encoded device value which is fraught which gets quantized | 22:27.39 |
| | to zero | 22:27.41 |
| Robin_Watts | mvrhel2: You here now ? | 23:07.42 |
| | mvrhel2: I think I recommended it last time, but the submarine trip is really worth doing. Your kids will love it. Make them wear something red. | 23:09.55 |
| | Aha! | 23:26.14 |
| | I have the rop stuff working in non-clist mode. | 23:26.30 |
| | henrys: oops. Have I been changing whitespace unnecessarily? | 23:28.27 |
| | My editor is set to strip trailing spaces off the end of lines, but I think that's it. | 23:29.11 |
| | Forward 1 day (to 2011/09/29)>>> | |
IRC Logs