| | <<<Back 1 day (to 2012/07/25) | 2012/07/26 |
| Ch3rryC0ke | Hey there-- I'm trying to make a PDF annotation app, and am using mupdf for rendering. I have a few questions though as I'm running into some issues | 00:44.15 |
| | 1) Right now I'm using PDF Clown to write annotations to the file, but for some reason, mupdf does not render them (Acrobat does) | 00:45.09 |
| | How should I go about figuring out where the issue is-- whether its with mupdf or with pdfclown? | 00:45.55 |
| mvrhel | ugh 09-52.PS.plank.72.0 seems to segv all the time now | 05:39.29 |
| | Robin_Watts: The fix for 12-07C.PS was pushed | 05:42.43 |
| | sleep time | 05:51.04 |
| ray_laptop | got the fix for bug 693220 and tiffsep1 planar mode testing | 07:03.59 |
| kens | I saw the bug fix, quick work on the planar mode | 07:04.23 |
| chrisl | kens: I had a look, and I couldn't find any association between my commit and the seg faults - besides, they all seem to have stopped with Michael's last commit..... | 07:10.27 |
| kens | chrisl yes, I did think it wasn't you... | 07:10.41 |
| chrisl | I thought it worth checking | 07:10.58 |
| kens | Fiar enough :-) | 07:11.07 |
| chrisl | I wasn't too keen on the fix, anyway, but anything else I could think of was going to be quite a bit more complex...... | 07:12.06 |
| kens | I don't recall the fix now.... | 07:12.24 |
| | I'm having a quick look at Marcos's latest one | 07:12.34 |
| chrisl | It's the PDF word spacing problem - PDF requires that it only be applied to *single byte* character codes with the value 32 | 07:13.10 |
| kens | Oh yes, I did notice that you had to do work in the PDF interrpeter as well | 07:13.32 |
| | Wow, windiff is really slow on comparing these files.... | 07:14.05 |
| chrisl | I added a couple of custom operators for the PDF interpreter, since the PDF requirement isn't compatible with how PS (a)widthshow works | 07:14.46 |
| kens | Yes, that was what I saw | 07:14.58 |
| chrisl | I was surprised there were a couple of test suite examples which we were getting wrong before, too! | 07:15.33 |
| kens | I can't say I'm that surprised, I doubt if they have all ever been eyballed | 07:15.54 |
| chrisl | Possibly not - tbh honest, I had seen them before, but never compared our output with Acrobat's. | 07:16.52 |
| | kens: Interestingly, (for me) the default resolution takes virtually the same time as 300dpi - which seems odd | 07:20.24 |
| kens | Well it doesn't seem to do much rendering | 07:20.39 |
| | THere are some type 3 fonts, and that's most of it | 07:20.51 |
| | I don't see why there should be any great difference at any resolution | 07:21.04 |
| | We obviously don't check for duplicate halftones, since we emit the same one *many* times | 07:21.35 |
| chrisl | Oh, is there something about the halftone we use at 72 dpi that makes it slower to deal with? | 07:22.36 |
| kens | Its possible, but I can't see why, its not like we're doing any real rendering | 07:23.00 |
| chrisl | Actually, the halftones must be defined in the source file - didn't you change things so we don't write out the default halftone now? | 07:24.04 |
| kens | We don't write the default any more, no. | 07:24.18 |
| | But we do write any that are in the file | 07:24.32 |
| | I can't see any way we'd be using any halftones | 07:24.42 |
| chrisl | Okay, so the actual halftone can't be the difference: the ones from the input won't change based on resolution | 07:25.08 |
| kens | One of the functions is different its has a size of [16 16] in the 72 dpi output and [8 8] at 300 | 07:25.14 |
| chrisl | That's the opposite of what I'd expect..... | 07:26.03 |
| kens | Me too | 07:26.17 |
| | But I have no idea what it means | 07:26.25 |
| | The fonts are emitted in a differnt order, which makes them hard to compare | 07:26.43 |
| | But they look the same | 07:27.10 |
| chrisl | kens: comparing rendering times with ppmraw - 72dpi takes 22 seconds, and 300dpi takes 10 seconds. I don't think the difference is in ps2write/pdfwrite! | 07:27.59 |
| kens | That's rendering th eoriginal PDF file ? | 07:28.22 |
| chrisl | Yeh | 07:28.37 |
| kens | Ah, well in that case I think I will enter that in the bug report and drop it, you are right it doesn't seem to be me :) | 07:29.02 |
| chrisl | Even with bbox or -dNODISPLAY the 300 dpi times are consistently (but minutely) quicker than the 72 dpi ones - but not enough to be significant | 07:31.11 |
| kens | Well I've changed teh bug now :-) | 07:31.27 |
| | SOme of the text appears to be different at 72 dpi.... | 07:32.35 |
| chrisl | Hmmm, Monotype trying to baffle me with Truetype font "science" - well, that's not going to work! | 07:35.42 |
| kens | TrueType 'science' ? ROFL | 07:36.04 |
| chrisl | Well, it's a sort of L. Ron Hubbard style "science" | 07:36.40 |
| kens | Ick | 07:36.51 |
| | OK now that the resolution distraction is out of the way, back to emitting compressible strokes. Coffee first though | 07:37.23 |
| | OK well my quick and dirty implementation reduces the compressed content stream from 350039 to 241317, which is by far the biggest difference of anything I've tried | 08:10.36 |
| | Its still a long way from teh Distiller output (66343) but I think its enough to show the principle is sound | 08:11.10 |
| chrisl | kens: so did you get better compression with the matrix format? | 09:01.20 |
| kens | chrisl yes | 09:01.28 |
| | 110k reduction in compressed size | 09:01.36 |
| | Distiller manages even better | 09:01.48 |
| | But I haven't tried to optimise further, and I'm not going to, at least for now | 09:02.02 |
| chrisl | Hmm, shame :-( | 09:02.03 |
| kens | I suspect I could do more | 09:02.13 |
| | I'm just writing an email to support and teh customer | 09:02.35 |
| chrisl | I do find it surprising that any cares about 600k vs 200k nowadays | 09:02.54 |
| kens | So do I! | 09:03.01 |
| | One of the reasons I don't plan to do anything about this right now. | 09:03.15 |
| | I'm very unconvinced by the putative benefits | 09:03.31 |
| | Especially since this is a pathological case IMO | 09:03.41 |
| | Any benefit with 'ordinary' files would be difficult to detect I suspect | 09:04.12 |
| chrisl | Well, the fact that they admit our output interprets very slightly faster seems to me to make the change questionable..... | 09:04.42 |
| kens | Well their customer is apparently obsessed with teh size difference | 09:05.01 |
| | But since its slower, I'm not keen to make the change | 09:05.14 |
| chrisl | Customer's are not always right! | 09:05.40 |
| kens | Well in this case its a 'zero attention' customer. | 09:05.59 |
| | If it was customer #1 I might be inclined to add an option | 09:06.09 |
| chrisl | I actually meant the customer's customer is not right, in this case | 09:06.44 |
| kens | Ah... | 09:06.49 |
| | By the way, it really was too hot to hthink yesterday, I found a simpler way to achieve the goal this morning.... | 09:07.17 |
| chrisl | "Fake" the matrix values? | 09:08.16 |
| kens | No, I just hacked hte vector device path emission directly | 09:08.32 |
| | Previously I was trying to do it 'properly' by setting up the methods in the enumerator | 09:08.55 |
| chrisl | Oh, yeh, that would do it | 09:08.58 |
| kens | OK email sent | 09:09.44 |
| | We'll see what comes back | 09:09.55 |
| chrisl | Probably some b*tching about not being very helpful....... | 09:10.21 |
| kens | Perhaps, but given their situation..... | 09:10.43 |
| chrisl | That the engineer allegedly doesn't know about! | 09:11.33 |
| kens | Good grief, another of Doctor Who's assistants has died. | 09:11.38 |
| | relatively young again | 09:11.53 |
| chrisl | Yeh, it's getting to stage where I don't want to look at the BBC news site for fear of finding out who's died today :-( | 09:12.55 |
| kens | chrisl I just tried a quick hack to allow DCT on image sin ps2write and it seg faulted, not sure why | 09:45.13 |
| chrisl | Hmm, I don't think I got it to work, but I don't think it segfaulted.... | 09:46.18 |
| kens | I may be hacking it differently ;-) | 09:46.29 |
| chrisl | Very likely.... | 09:46.49 |
| | kens: IIRC, in setup_image_compression(), I changed the "lossless_template" declaration to "lossless_template = &s_DCTE_template" | 09:50.17 |
| kens | Oh, I'm trying to be even more clever and allow for downsampling and such as well | 09:50.40 |
| chrisl | That's not "quick hacking", then, that's attempting to do it right! | 09:51.10 |
| kens | Its a quick hack to see if I can get it working :) | 09:51.27 |
| | I'm not altering the code, just chaning variables | 09:51.37 |
| | changing | 09:51.41 |
| chrisl | I tried that, but gave up when I encountered the 13 million (or whatever) places the "lossless" flag is used! | 09:52.52 |
| kens | Ah well I'm trying to bbypass that | 09:53.08 |
| | I've given in and made a small code change | 09:54.00 |
| | If it doesn't work I'm going to give up on it for now | 09:54.12 |
| | No, stil crashes on an image | 09:55.08 |
| | No resource created for i, don't know why | 09:55.26 |
| chrisl | Oh, for goodness sake: I'm looking at the thing cust 532 sent this morning, and looking at one of their previous test jobs. Whoever created this file wanted to save space by (not following the recommendations!) and ommitting to embed the CIDFont - but then was quite to include >100k (in a 190k file) of what looks like the original application file! | 09:56.56 |
| kens | Excellent! | 09:57.13 |
| | Could be Illustrator ? | 09:57.23 |
| chrisl | No, I don't think so - they were obviously so "proud" of their application, they not included any of the creator etc keys in the file! | 09:58.36 |
| kens | Ah, of course, I see. Its an inline image so of *course* we haven't created a resource for it | 09:59.01 |
| chrisl | Hmm, some of metadata suggest this file thinks it's PDF/A-1b - but I thought PDF/A *had* to have all fonts embedded? | 09:59.39 |
| kens | Yes it does | 09:59.49 |
| chrisl | Terrific! What a heap of crap.... | 10:00.12 |
| kens | THey can be embedded but they must be present (to be legal, you can still *call* it PDF/A even if it isn't) | 10:00.18 |
| chrisl | Actually, I suspect the file may have been hacked around, and the PDF/A stuff just not removed after the hacking | 10:01.15 |
| kens | OK making inline images obey the filters and stuff is going to be a lot more work. At present we simply write the data straight into the page content stream. In order to allow auto-filtering and stuff to work we need to use the 'asides' stuff whcih works by writing several copies of the data, and choosing the best. But we leave the data in the 'aside'. In order to work with ps2write we need to copy the aside back to the main file, and delete the aside. | 10:02.31 |
| | So it can be done, but its not trivial | 10:02.57 |
| | All I really need to do is copy the data strem from the aside at the point where I currently write the reference to the XObject | 10:04.23 |
| | But for now I think I'll go and torture myself with Linearisation some more. I wonder what I was doing with it when I stopped.... | 10:05.11 |
| Robin_Watts | stabbing it repeatedly and compulsively with a knife? | 10:44.51 |
| sebras | tor8: hm.. my changes for FirstChar/LastChar may have to be modified! | 12:43.12 |
| | tor8: at least they are handled differently in pdf/pdf_font.c, something I didn't notice last night. | 12:43.34 |
| tor8 | sebras: okay, I haven't pushed yet so there's still time | 13:14.25 |
| sebras | tor8: great. I'll fix it tonight unless you have already done so by then. | 13:18.31 |
| tor8 | sebras: tell me what needs changing and I'll do it | 13:18.56 |
| sebras | tor8: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=fde6e1c8426c9356ba23e40407d05096fd6ac447 | 13:19.34 |
| | that patch handles out of range FirstChar/LastChar values differently than what is being done for non-type3 in pdf/pdf_font.c | 13:20.03 |
| | in pdf/pdf_font.c you basically assume first = last = 0; but I throw an exception. | 13:20.26 |
| | tor8: assuming zero is probably more robust. | 13:21.11 |
| tor8 | sebras: right. | 13:21.26 |
| sebras | N.B. I haven't considered whether the code below my change would survive assuming zero. | 13:21.56 |
| tor8 | sebras: it loops from first..last reading values from the array, so it should | 13:54.07 |
| | sebras: tor/master | 13:56.17 |
| Robin_Watts | I think we're going to need to buy at least one copy of Visual Studio 2010 and windows 8. Seems like WinRT is becoming important :( | 13:57.27 |
| tor8 | touches his nose. | 13:58.09 |
| Robin_Watts | People can buy it for me, as long as they buy me a laptop to run it on. Damned if I'm putting it on my main machine :) | 13:58.40 |
| | Could Vmware it I guess. | 13:58.58 |
| kens | assuming it works | 14:00.48 |
| Robin_Watts | yeah. They hardware accelerate *everything* graphical. | 14:01.18 |
| | so that might give problems. | 14:01.24 |
| | mvrhel: Morning | 14:08.33 |
| mvrhel | morning Robin_Watts | 14:08.47 |
| Robin_Watts | Vaguely good news. | 14:08.53 |
| | With your fix from last night in place all but one of the differences we get by pushing max components to 32 is down to bandheight changes. | 14:09.48 |
| | Some of those changes are non-trivial though, but that's a whole other issue. | 14:10.12 |
| | The final difference is in Bug692517.pdf (which is really .ps) | 14:10.35 |
| mvrhel | ok. are the issues all with psdcmyk? | 14:10.46 |
| Robin_Watts | I've got a cutdown file I'm poking at how, | 14:10.51 |
| | s/how,/now./ | 14:10.56 |
| | yes, all psdcmyk | 14:11.00 |
| mvrhel | ok. perhaps put a breakpoint at cmd_put_color to see if we are still doing that someplace | 14:11.38 |
| Robin_Watts | The Bug692517.pdf problem occurs at 72dpi with no clist. | 14:11.44 |
| mvrhel | oh | 14:11.56 |
| Robin_Watts | It's something inside an imagemask operation. | 14:12.04 |
| | I'll keep bashing at it. | 14:12.18 |
| mvrhel | ok I have to help get the kids breakfast and then I will be back to help | 14:12.35 |
| sebras | tor8: yup, that patch seems sane. but the maintainers of mupdf might complain about your short commit message... | 14:13.09 |
| Robin_Watts | sebras: Even I'd not whinge about that one (unless there was a particular example file that could be mentioned) | 14:15.14 |
| sebras | Robin_Watts: I know. I'm just teasing. :) | 14:15.33 |
| | I did agree with you last time and did put some more effort into the messages this time around. | 14:17.00 |
| Robin_Watts | I haven't looked at your latest set of patches (buried in gs at the moment), but it is appreciated! | 14:18.04 |
| | One day someone is going to start beating me with the sticks I've been beating other people with, and then I'll be in trouble :) | 14:18.35 |
| sebras | Robin_Watts: I think it goes both ways, I tend to complain about your trailing whitespace remember... :) | 14:19.41 |
| kens | didn't notice..... | 14:33.08 |
| chrisl | And there it is again..... | 14:33.37 |
| Robin_Watts | ponders upgrading the HD in the macbook. 1TB spinning disc for 77quid or... 480Gig for 400+... ouch. | 14:34.43 |
| | 480Gig SSD that is. | 14:34.56 |
| chrisl | Robin_Watts: I guess it depends what capacity you actually need | 14:35.38 |
| Robin_Watts | chrisl:Well, I'm up against the 256Gig limit in the current one now. | 14:36.03 |
| chrisl | I still reckon SSDs are a bit expensive for use as the main data disc | 14:37.46 |
| henrys | anyone know what this windows developer is asking for on support? | 14:38.29 |
| kens | a port | 14:38.36 |
| | to windows 8 | 14:38.41 |
| chrisl | I thought the Metro apps had similar restrictions to the C# stuff - limitations what you can do and how? | 14:39.49 |
| henrys | what is P/Invoke? | 14:39.50 |
| | kens:not sure what you mean, our dll should work on windows 8, why can't the api be used "metro style". | 14:42.06 |
| kens | metro requires 'managed code' | 14:42.39 |
| chrisl | kens: is "managed code" always bytecode, or can it be "native", do you know? | 14:45.08 |
| kens | as far as I know its native, but what do I know ? :-) | 14:45.44 |
| henrys | hmm I thought the definition of managed code was running on their virtual machine thus byte code. | 14:46.35 |
| kens | I plead total ignorance | 14:47.10 |
| chrisl | henrys: there seems to be some overlap: "managed code" has also been used to refer to code that only interacts with the .net framworks, and some other bits and pieces (i.e. not the crt library directly) | 14:48.18 |
| henrys | it's just difficult for me to believe that a simple C dll wouldn't be easy to integrate but MS should not be underestimated. | 14:50.20 |
| chrisl | I wonder if MS have done a porting guide - I wouldn't bet on it :-( | 14:50.54 |
| kens | You cna't use an 'old fashioned' DLL in Metro | 14:50.57 |
| henrys | by invoke does he possible mean exec/fork? and doesn't realize there is a C library api. | 14:51.04 |
| | ? | 14:51.09 |
| kens | You cna have an old fashioned app, but not a Metro certified one | 14:51.13 |
| | I have no idea what P/Invoke is. I could look up the MSVC help but it might not say | 14:51.45 |
| henrys | I found the docs... platform invoke. | 14:52.27 |
| Robin_Watts | My understanding is that you can run C/C++ code fine. But you are limited in the APIs you can use. | 14:52.55 |
| | Specifically there are limitations in how you can open files etc. | 14:53.27 |
| | (All subject to my crap memory). | 14:53.32 |
| | We've had questions asked about mupdf on Metro too. | 14:54.15 |
| henrys | I guess we should spec this out a bit so we can at least give him a complete answer. The "volunteers" are kens, Robin_Watts, alexcher, or chrisl, do you want me to pick or perhaps a web app to draw straws. | 14:54.36 |
| Robin_Watts | Actually, we could investigate this with MSVC 2010 express, as that builds for metro. | 14:54.36 |
| chrisl | touches nose | 14:54.55 |
| | I'm finding a lot of references to docs about porting iOS and Android apps, and web sites and stuff to Windows 8, but nothing so far about porting a Windows application to Win8 - how crap is that? | 14:56.35 |
| kens | surely ios and android apps are also c/C++ ? | 14:57.57 |
| Robin_Watts | henrys: I'm not averse to having a crack at it. | 14:58.03 |
| | at least in so far as seeing what the limitations are. | 14:58.26 |
| | I'd probably start with mupdf though, as it's (hopefully) a simpler job. | 14:58.38 |
| kens | Main thing is to find out what all these people are referring to I htnk | 14:59.11 |
| chrisl | kens: so far the "Porting guide" is all about the GUI style - not a "port" at all :-( | 14:59.16 |
| kens | Lol | 14:59.22 |
| henrys | Robin_Watts:if looking at mupdf tells us what the customer needs to know fine by me. | 15:00.34 |
| Robin_Watts | Well, I know that supposedly mupdf doesn't "just work". | 15:01.08 |
| henrys | I'll tell marcos to tell them you are studying it and he can respond to them. | 15:01.25 |
| | or maybe marcosw is here | 15:01.40 |
| Robin_Watts | so I'd like to try it and find out why. That may well point us towards problems in gs. | 15:01.44 |
| | I'd tell marcosw not to promise a timescale! | 15:01.57 |
| henrys | research problem no dates | 15:02.10 |
| chrisl | It *looks* like we'd need to "port" our file handling, low level memory handling, and any other interactions with the OS from the CRT to the WRT..... | 15:03.37 |
| henrys | that stuff is fairly well isolated in the ghostscript code and shouldn't be difficult to change. For I/O we'd just have more gp_* crap. | 15:06.18 |
| chrisl | Note that I don't know that that's *all* that will be required! | 15:06.45 |
| | "When you compile a new static library, if you make a call to a Win32 API that's excluded for Metro style apps, the compiler will raise error C3861, âIdentifier not found.â To look for an alternative method that's supported for the Windows Runtime, see Alternatives to Windows APIs in Metro style apps." | 15:07.37 |
| | Robin_Watts: *some* possibly useful info here: http://msdn.microsoft.com/en-us/library/windows/apps/hh700360.aspx | 15:08.46 |
| Robin_Watts | oh, there's a pattern with a clist. | 15:36.00 |
| | So it might be a cmd_put_color thing. | 15:36.23 |
| kens | OK off now, night all | 16:21.18 |
| mvrhel | henrys: I see the discussion about metro | 16:39.50 |
| | I am thinking of going to a this Metro build conference here in Redmond at the end of October | 16:40.12 |
| | at the mothership | 16:40.18 |
| Robin_Watts | mvrhel: That may be worthwhile. | 16:41.12 |
| mvrhel | http://www.buildwindows.com/ | 16:41.42 |
| | http://www.redmondpie.com/2012-microsoft-build-conference-to-come-to-redmond-on-october-30th/ | 16:42.10 |
| | I have a friend who in the Visual Studio marketing team (who would think there would be such a thing) who told me about it last night at the kids ball game | 16:43.07 |
| | s/in/is in/ | 16:43.34 |
| Robin_Watts | mvrhel: Is he one of the people responsible for putting all the MENUS IN CAPS BECAUSE IT MATCHES BING ? | 16:44.43 |
| mvrhel | I will ask him about that..... | 16:45.00 |
| Robin_Watts | Mac users: be aware that VMWare Fusion 3 doesn't work with Mountain Lion. A fact I only discovered *after* upgrading. | 16:46.30 |
| | So... it is a clist problem. | 16:49.26 |
| | And I'll repeat that for ray... | 16:49.41 |
| | So... it is a clist problem. | 16:49.43 |
| | :) | 16:49.46 |
| | I have a whole series of copy_mono_planes. | 16:50.00 |
| | The 1277th one is a copy_mono_planes at 606,2003 of 14x1 pixels. | 16:50.26 |
| | 1267th, sorry. | 16:50.35 |
| | The 1268th is a copy_mono_planes at 632 2003 of 10x1 pixels | 16:50.53 |
| ray_laptop | Robin_Watts: is this the digest of what you are seeing with the clist thing ? | 16:51.14 |
| | note that what I found will happen with DeviceN non-planar device and transparency | 16:51.45 |
| Robin_Watts | When we read them back, the 1267th looks plausible, but then we get lots of 'end_runs' and a tile_rect_short and a fill page. | 16:51.56 |
| | ray_laptop: This is a new-for-today clist problem :) | 16:52.18 |
| ray_laptop | Robin_Watts: OK. | 16:52.22 |
| | which bug ? | 16:52.26 |
| Robin_Watts | No bug as yet. | 16:52.32 |
| ray_laptop | which file and command line, then ? | 16:52.44 |
| Robin_Watts | When I push the component_max up to 32, I get 74 differences. | 16:52.49 |
| | Most of them are bandheight differences. | 16:52.55 |
| | 1 of them is not. | 16:53.14 |
| | Bug692517.pdf | 16:53.25 |
| | which is actually a .ps file. | 16:53.29 |
| | I have a cutdown file here. | 16:53.37 |
| | I'll keep bashing at it for a bit, as I've only just got to the stage of being able to trap its failure in the debugger. | 16:54.22 |
| ray_laptop | Robin_Watts: can you email me the cut down file ? | 16:54.30 |
| Robin_Watts | ray_laptop: If I get stuck, yes, but I'm not seeking to palm this off yet :) | 16:54.54 |
| | I'll make a bug and update it with cutdown file, and instructions for reproduction if I do want to hand it off. | 16:55.27 |
| ray_laptop | Robin_Watts: OK. so to find out if something is going bonkers in the creating of the clist 'cmd_write_band' is what scans the linked list of commands in the 'buffer' and collects commands for a band | 16:56.00 |
| Robin_Watts | We're working within a single band here when it goes wrong I think, so that's simpler than yesterday. | 16:56.43 |
| ray_laptop | so if you know the band, then you can enable a conditional breakpoint if there is something unique about the data sequence | 16:56.44 |
| | Robin_Watts: you set the BandHeight for a full page ? | 16:57.10 |
| Robin_Watts | no. | 16:57.16 |
| mvrhel | Robin_Watts is the the Arbor press file? | 16:57.49 |
| Robin_Watts | mvrhel: could be. | 16:58.07 |
| | picture of a blue vice. | 16:58.20 |
| mvrhel | its a picture of an arbor press? | 16:58.21 |
| | blue | 16:58.28 |
| | yes | 16:58.30 |
| | that one I just fixed a bug for a week or so ago | 16:58.46 |
| | I had a significantly cut down version of it | 16:59.04 |
| | not sure if I tossed it | 16:59.14 |
| Robin_Watts | Significantly cut down will probably mean it won't fail. | 16:59.56 |
| | I have 3 different cutdown versions here, and they fail in different ways. | 17:00.08 |
| mvrhel | ok. are you ever tripping on cmd_put_color? | 17:00.18 |
| Robin_Watts | no. | 17:00.25 |
| | not afaict. | 17:00.31 |
| mvrhel | pl | 17:00.32 |
| | ok | 17:00.36 |
| ray_laptop | mvrhel: what's a reasonable file that has several separations in it ? I want to make sure that tiffsep1 behaves with one or more of those ? | 17:02.08 |
| mvrhel | ray_laptop: like more than 8 you mean | 17:02.30 |
| | I have a simple one with just rect fills | 17:02.41 |
| ray_laptop | mvrhel: can you send it or upload it ? | 17:03.10 |
| mvrhel | yes | 17:03.18 |
| ray_laptop | mvrhel: thanks. | 17:03.26 |
| | making the tiffsep1 work in planar mode was so simple, that I must have missed something ;-) | 17:04.05 |
| mvrhel | oh you moved it to planar? | 17:04.18 |
| ray_laptop | mvrhel: yes | 17:04.23 |
| | and took compressed color encoding out of gdevtsep.c | 17:04.51 |
| | (it was disabled by default anyway) | 17:05.10 |
| | for a CMYK image, it worked fine, but that isn't saying much | 17:05.51 |
| mvrhel | ok. I sent you one with 9 spot rect fills plus it has transparency | 17:07.58 |
| ray_laptop | mvrhel: thanks | 17:09.21 |
| Robin_Watts | ray_laptop: ping? | 17:32.38 |
| | I think I see the problem with this. | 17:34.17 |
| ray_laptop | Robin_Watts: yes ? | 17:34.39 |
| Robin_Watts | But I'm not sure I see how to solve it. Can I run it past you? | 17:35.14 |
| ray_laptop | Robin_Watts: please, go ahead | 17:35.30 |
| Robin_Watts | In clist_copy_planes, we do a cmd_put_bits. | 17:36.13 |
| | That leaves a 9 byte gap for the command header, and then copies the first planes worth of data after it. | 17:36.54 |
| | Then we loop around and send subsequent planes. | 17:37.05 |
| | Then we go back and we fill in the 9 byte gap. | 17:37.18 |
| mvrhel | i remember watching this once | 17:37.28 |
| Robin_Watts | I think the problem is that while we are sending subsequent planes, the buffer fills up. | 17:38.01 |
| | and we copy the data away and we carry on filling up a new buffer. | 17:38.28 |
| mvrhel | it should be checking for sufficient space | 17:38.35 |
| Robin_Watts | but the 9 byte gap gets filled in too late. | 17:38.38 |
| | so the stuff that's been copied away isn't complete. | 17:38.49 |
| | What I'm seeing is that on playback I'm seeing the 9 byte gap still being all zeros. | 17:39.12 |
| | Does that make sense? | 17:39.26 |
| ray_laptop | Robin_Watts: so each plane has it's own 9 byte header ? | 17:39.41 |
| Robin_Watts | No. | 17:39.47 |
| mvrhel | Robin_Watts: do you see why we need to wait at all to do the fill? | 17:40.12 |
| Robin_Watts | We have a 9 byte header, then the first plane's data. | 17:40.19 |
| ray_laptop | I see -- the header gets written when we do the cmd_write_buffer | 17:40.34 |
| Robin_Watts | then a single byte (compression method) before each subsequent plane. | 17:40.49 |
| | mvrhel: I'm wondering the same thing. | 17:41.02 |
| ray_laptop | oops -- I have to run home. be back in less than 10 min. | 17:41.10 |
| Robin_Watts | mvrhel: I guess we should test code after the initial cmd_put_bits and if that doesn't fail, fill in the header there. | 17:41.55 |
| ray_laptop | ok, back. sorry | 17:47.25 |
| Robin_Watts | just testing a fix. | 17:47.43 |
| ray_laptop | Robin_Watts: that makes sense -- to fill in the header after the first plane's bits are written | 17:48.20 |
| | all except the compression flag can probably be filled in right away, can't it ? | 17:49.21 |
| Robin_Watts | probably. for simplicity I've kept the structure. | 17:51.59 |
| | All 3 versions of the SEGVng file now work. | 17:56.22 |
| | As does the original | 17:57.04 |
| | ray_laptop, mvrhel: http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=4fe9f763899eb79ef21b99b1f274557244327f13 | 18:05.58 |
| mvrhel | Hi Robin_Watts looks good | 18:27.06 |
| Robin_Watts | thanks | 18:27.31 |
| ray_laptop | Robin_Watts: I agree, look fine | 18:31.17 |
| Robin_Watts | mvrhel, ray_laptop: Thanks. | 18:35.53 |
| | ray_laptop: So the other differences with the MAX_COMPONETS stuff fall into 2 categories. | 18:36.30 |
| | 1) single pixel differences due to the change in bandheight. | 18:36.44 |
| | 2) bigger changes where data is missing due to banding. | 18:37.08 |
| | Do we have a bug where we are tracking banding problems? | 18:37.21 |
| ray_laptop | Robin_Watts: data missing due to banding no, iirc there is a bug with banding/page mode single pixel diffs | 18:43.01 |
| Robin_Watts | So, should I make a bug? | 18:44.00 |
| | ray_laptop: http://ghostscript.com/~regression/robin/ | 18:49.34 |
| ray_laptop | Robin_Watts: please -- another bug won't hurt | 18:53.27 |
| | mvrhel: are the CMYK all blank in that spots9 file ? | 18:53.51 |
| mvrhel | I think so | 18:53.57 |
| | ray_laptop: ^^ | 18:54.04 |
| ray_laptop | whew! I was having trouble imaging how CMYK worked with a file that had only CMYK and didin't when there were spot colors :-) | 18:54.49 |
| mvrhel | :) | 18:55.06 |
| ray_laptop | OK. One last clusterpush to make sure my recent changes didn't do anything stoopid, then commit | 18:55.47 |
| | alexcher scored some free beer -- all he has to do is fly to zurich ;-) | 19:04.08 |
| | I suppose I should have two separate commits for the bug fix and changing tiffsep1 over to planar mode :-/ too much trouble now, though | 19:05.55 |
| | at least both fixes intersect with usage of the tiffsep1 device | 19:06.28 |
| | does anybody have major heartburn over one commit with both a bug fix and an enhancement ? | 19:08.07 |
| | no response ? OK, I'll go ahead ;-) | 19:08.27 |
| Robin_Watts | I'll run through the component_max diffs tomorrow, either putting them in bugs, or having a look at them if they look funky. | 19:11.13 |
| | Beer in Zurich is stupidly expensive. It's almost worth the air fare :) | 19:50.33 |
| ray_laptop | OK. committed the fix for bug 693220 and change tiffsep1 to use planar (and get rid of compressed_color encoding there) | 20:27.26 |
| | time for lunch | 20:32.56 |
| | bbiaw | 20:33.05 |
| oasisfleeting_ | hello | 21:38.25 |
| | I'm encountering an issue when trying to split a pdf | 21:38.39 |
| | here is my function http://pastebin.com/zT9w6yDD | 21:39.24 |
| alexcher | oasisfleeting_: what issue ? | 22:00.32 |
| oasisfleeting_ | alexcher, thank you but nevermind. I have figured it out. | 22:00.55 |
| henrys | I wonder if that is really an ancient gs 5? | 22:01.43 |
| oasisfleeting_ | so here is my new function http://pastebin.com/1X4AVCLB but the images output are rather large | 22:21.13 |
| | any way to adjust that? | 22:21.23 |
| sebras | tor8 Robin_Watts: typo-patch over at sebras/master | 22:23.34 |
| alexcher | oasisfleeting_: use lower resolurion, use higher compression, consider using PNG for text abd drawings. | 22:25.08 |
| | oasisfleeting_: use lower resolurion, use higher compression, consider using PNG for text and drawings. | 22:25.22 |
| oasisfleeting_ | i thought $res='300x300'; was low | 22:25.47 |
| | am I wrong about that? | 22:25.50 |
| | where can I find a list of all the arguments i can use in the call to ghostscript? | 22:26.21 |
| alexcher | oasisfleeting_: 300 dpi is excessive for the web but OK for printing. | 22:26.54 |
| oasisfleeting_ | oh that's dpi | 22:27.06 |
| alexcher | oasisfleeting_: doc/Use.htm | 22:27.29 |
| oasisfleeting_ | hmm, my ghostscript says 8.7.1 but i don't see it on here http://www.ghostscript.com/Documentation.html | 22:27.48 |
| | i guess i'll just look at 8.63 | 22:28.00 |
| | i'm also getting this error Warning: the map file cidfmap was not found. | 22:28.31 |
| | err, warning | 22:28.35 |
| | use.htm thanks | 22:29.21 |
| alexcher | oasisfleeting_: Current version is 9.05 and we are about to release a next one. | 22:29.22 |
| oasisfleeting_ | my linux kung foo isn't strong enough for me to feel comfortable upgrading. I assume apt-get got the correct one when whoever installed it , installed it. | 22:32.50 |
| | i'll worry about it later. | 22:33.12 |
| alexcher | oasisfleeting_: build your own. | 22:37.56 |
| oasisfleeting_ | yea sure. I'd mess it up and be here for hours trying to get it running again | 22:38.35 |
| alexcher | oasisfleeting_: get the sources, e.g the current snapshot. decompress, say "configure" and "make", enjoy. | 22:40.53 |
| | oasisfleeting_: current snapshot has the lowest numberof knowh SEGVs than any other version. | 22:42.55 |
| | Forward 1 day (to 2012/07/27)>>> | |
IRC Logs