| | <<<Back 1 day (to 2014/03/12) | 2014/03/13 |
| chrisl | kens: ping | 09:09.44 |
| kens | pong | 09:09.49 |
| chrisl | Can you cast an eye over http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=9816ff81 please? | 09:09.59 |
| kens | Looking.... | 09:10.39 |
| | I see you are returning prn_done instead of code, whichpresumably prevents an error, wouldn't the error be better ? | 09:11.19 |
| chrisl | In which file? | 09:11.40 |
| kens | gdevdevn.c | 09:11.51 |
| | Its the first one in the diff | 09:11.58 |
| | I'm not saying its wrong, just curious | 09:12.10 |
| | Hmm, actually its a goto | 09:12.26 |
| chrisl | Yeh, it should still be returning code | 09:12.40 |
| kens | Really ? YOu sure ? | 09:12.52 |
| | ah its in base, nho wonder I can't find it | 09:13.37 |
| | OK prn_done returns code so that's OK | 09:14.10 |
| | Hmm substantial changes! | 09:16.25 |
| chrisl | There are quite a few, yes.... | 09:16.36 |
| kens | Well it all looks OK to me. Of course I could easily miss something in such a large change, but I guess it comiles and tests OK. | 09:21.18 |
| chrisl | It does. None of it is very complex, it just avoids too many cases of path strings allocated on the stac | 09:22.17 |
| | k | 09:22.21 |
| kens | Yes, its not complicated, its just that there's a lot to read ;-) | 09:22.39 |
| chrisl | Yeh, I don't expect you to read the entire thing, just following procedure...... | 09:23.10 |
| kens | :-) I did read it, but towards the end my eyes were glazing somewhat | 09:23.30 |
| chrisl | kens: sometime today, can you pen a paragraph or so about the pdfwrite colour changes, please? | 09:50.18 |
| kens | chrisl I'll try to, I'mtrying to sort out hte xref stream problem before the release | 09:50.39 |
| chrisl | kens: okay, let's delay the RC until Monday, then. That would probably be good to get fixed if possible | 09:51.28 |
| kens | That's what I thought, its proving intractable at the moment, mostly because I've never looked at the code before | 09:51.55 |
| | It 'looks like' the xref stream code assumes there will be only one xref stream, or at least that the first one will contain object 0. This turns out not to be true. | 09:59.00 |
| | Oh actually no forget that | 09:59.53 |
| | seems readxref is returning an error | 10:00.06 |
| | aha yes, a rangecheck, now to find out why | 10:00.52 |
| | Ah, looks like we use the /Size entry in the xref to set the size of the Objects and Generatiosn, but we *don't* account for the fact that the stream may start form a non-zero location. | 10:07.38 |
| | chrisl that's hte xref stream fix pushed, I'll go and start putting together release notes for you in a minute. | 10:36.09 |
| Jogu_ | morning | 10:37.54 |
| kens | Hi | 10:38.01 |
| Robin_Watts | For those people that missed it yesterday, Jogu_ pete_mcl are now (as joseph and pete on casper) doing contract work for us on epage. | 10:39.53 |
| kens | read it in the logs ;-) | 10:40.00 |
| Jogu_ | :) | 10:40.38 |
| chrisl | kens: given the area of the change, I'm still inclined to leave the RC until Monday.... | 10:47.38 |
| kens | chrisl up to you, I'm pretty confident of that one though. | 10:48.04 |
| chrisl | Okay, if I get up early enough tomorrow, I'll do it tomorrow, otherwise Monday..... | 10:48.48 |
| kens | No rush from my POV | 10:48.56 |
| kens | is rapidly assessing riding opportunities in California, based on Miles' last email | 10:49.25 |
| chrisl | Well, it *can* take most of the day, so if I don't start work until 10am, I might not finish by the end of the day | 10:49.45 |
| kens | Hmmm..... | 10:56.00 |
| | When I ran a cluster test it was fine, but the commit threw an error 'log files too big' | 10:56.23 |
| chrisl | That's less than helpful :-( | 10:56.51 |
| kens | Especially since its only on macpro | 10:57.01 |
| | I suspect its not real, or at least not connected to the commit | 10:57.24 |
| | But now I'm worried :-( | 10:57.40 |
| chrisl | Unless it's caused new warnings to be emitted? | 10:57.53 |
| kens | Well it shouldn't, I removed all my debugging code, and like I said, it passed a cluster push which I *thought* was the same as a commit run | 10:58.37 |
| chrisl | One of my commits at the meeting failed with an erroneous compile error..... | 10:59.32 |
| kens | Hmm, well I'll hope its nothign and ask marcos later | 10:59.49 |
| chrisl | Hmmm, where do these Acrobat2Tiff binaries keep appearing from on the cluster?? | 11:03.32 |
| kens | Huh ? I've never seen those before | 11:03.49 |
| chrisl | Most times I do a clustpush, I get: | 11:04.21 |
| | deleting tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Interop.Acrobat.dll | 11:04.30 |
| | deleting tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.xml | 11:04.30 |
| | deleting tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.vshost.exe | 11:04.30 |
| | deleting tools/Acrobat2Tiff/Acrobat2Tiff/bin/Release/Acrobat2Tiff.exe | 11:04.30 |
| kens | Hmm I'd neer noticed that | 11:04.49 |
| kens | tries it | 11:05.11 |
| | Yes I get that too | 11:05.59 |
| chrisl | Weird, because the files exist in my repo, so I don't know why it thinks it needs to delete them...... | 11:06.03 |
| Robin_Watts | chrisl: Are you using git push? | 11:08.43 |
| | or clusterpush ? | 11:09.08 |
| chrisl | clusterpush | 11:09.21 |
| Robin_Watts | no idea then :) | 11:09.58 |
| chrisl | It's not in the exclude lists.... oh well, I'm not going to worry about it..... | 11:11.04 |
| Robin_Watts | Bugger. I think the change in dates is bad for me :( | 11:21.00 |
| | Who has a problem with it? | 11:21.07 |
| kens | Possibly Henry | 11:21.16 |
| | Miles didn't say but I seem to remember Henry saying somethign | 11:21.41 |
| chrisl | I think Ray had something close to the original date | 11:21.49 |
| Robin_Watts | ISTR that henry said it had to be that weekend for him cos he had a race on the other possible date. | 11:22.00 |
| kens | Well maybe it is Ray then | 11:22.20 |
| Robin_Watts | ray had a sound gig the night before this date, AIUI. | 11:22.21 |
| | but he said he could manage SF cos it was close. | 11:22.37 |
| kens | chrisl did you intend to commit the struct ref_s change ? | 11:28.22 |
| chrisl | kens: yes | 11:28.29 |
| kens | OK NP | 11:28.33 |
| chrisl | I finally understood what he was on about, and I think his patch is the simplest solution after all | 11:29.24 |
| kens | Ah, OK I had thought there were still problems, no worries | 11:29.39 |
| | OK featuire changes on its way by email | 11:31.37 |
| chrisl | Thanks | 11:34.34 |
| | Hmm, somehow Distiller on Windows gets around the "Start in" shortcut setting :-( | 11:35.14 |
| Robin_Watts | chrisl: I think you're right about the GB_PACING_CHUNKY thing. | 11:35.36 |
| kens | That's an extension isn't it ? | 11:35.38 |
| Robin_Watts | I'll have a play some more after I have a run. | 11:35.46 |
| chrisl | Robin_Watts: it looked odd. I wondered if we shouldn't be using the gx_default_get_bits() for planar devices | 11:36.17 |
| | kens: extension? | 11:36.24 |
| kens | THe 'start in' right click is a UI tweask isn't it ? Not standard as installed | 11:36.50 |
| chrisl | No, I'm fairly sure it's standard | 11:37.24 |
| kens | Well, not important | 11:37.46 |
| kens | thinks we're going to have the August meeting shuffle in June this year.... | 11:38.24 |
| Robin_Watts | We were given the june dates back in december, right? | 11:41.23 |
| kens | I htink so yes | 11:41.35 |
| sebras | tor8: good morning! | 12:47.22 |
| Robin_Watts | chrisl: I *think* the pbm stuff is strange in the way it uses planar buffers. | 13:20.42 |
| | It tells the underlying device to use planar buffers, but it relies on the getbits call to return chunky bits. | 13:21.21 |
| kens | That sounds like some god-awful hack.... | 13:21.57 |
| Robin_Watts | kens: The whole use of planar buffer in this device is a hack. | 13:38.34 |
| | but the point of getbits is to be able to change formats. | 13:38.34 |
| | so the problem is in the device setup. | 13:38.34 |
| kens | OK fair enough | 13:40.58 |
| Robin_Watts | or rather in the setup for the getbits call. | 13:41.28 |
| | So that solves the overwrite, but there is still a planar problem in there. clist or halftone related I think. | 14:06.02 |
| | hola pedro_. | 14:06.17 |
| pedro_ | hi folks | 14:06.23 |
| henrys | the meeting stuff if my fault - sabrina's art event at which I'm supposed to help was rescheduled so I thought I'd ask Miles, looks like it won't work though | 14:16.02 |
| Robin_Watts | sympathises. | 14:18.06 |
| Jogu_ | morning henry. I was wrong about smartoffice btw; the current appstore release definitely does have the embedded general stuff in it (it sees our office non-airprint printer fine). I'm still very puzzled as to why it wouldn't see either of my home printers, and still convinced it did so in an older release :) | 14:18.59 |
| henrys | Jogu_: and it does not see my epson printer either I'll try again in a few minutes here. | 14:20.12 |
| Robin_Watts | Jogu_: How does it 'see' these printers? Is it any shared printer? | 14:21.01 |
| henrys | Jogu_: certainly it won't see very old printers | 14:21.05 |
| Jogu_ | henrys> my two home ones are modern HPs | 14:21.23 |
| | robin> I'm not sure exactly what the spec is. It should see a large number of printers that have built in ethernet or wifi I think. | 14:21.47 |
| | our office one that it seems okay is a samsung clx-3170 colour laser. | 14:22.15 |
| | which has an ethernet port on it. | 14:22.22 |
| Robin_Watts | Neither of my printers have built in ethernet or wifi. | 14:22.26 |
| kens | I'd be happy to reschedule the meeting even later, the end of June works for me too, and the September meeting is the end of the month also. | 14:24.30 |
| Jogu_ | henrys: I've sent you a contact request on skype too; would be good to have a chat when you have time about what work you want us to do in the near future, if any :-) | 14:24.33 |
| henrys | I'd like to set things up so everything goes through paulgardiner for now, his immmediate concern is this print business. | 14:26.18 |
| | paulgardiner: are you about? | 14:26.28 |
| paulgardiner | I am | 14:26.39 |
| henrys | but I'll set up skype in a moment here. | 14:26.42 |
| | paulgardiner: the calvary is here ;-) | 14:27.07 |
| paulgardiner | Woo hoo | 14:27.14 |
| | Just reading back through the discussion | 14:29.29 |
| henrys | Jogu_: actually the laptop I have skype on is being repaired can we simply go private here or should I install a skype? | 14:30.32 |
| | Jogu_: If it is lengthy I'll install skype | 14:31.05 |
| pedro_ | henrys> Jogu_ is on a call - should be back in 5 minutes. I think its just to discuss initial work | 14:31.40 |
| Jogu_ | sorry - can just go private here, that's fine | 14:32.03 |
| Jogu_ | just got a phone call from the amazon app store. boggle. apparently they're getting more agressive in persuading people to publish there :-) | 14:32.38 |
| henrys | paulgardiner: can you direct the work for Jogu_? I believe we agreed on priorities at the meeting - printing, layout bugs, build etc. If not obvious we should learn whatever they do not just have it done. | 14:35.14 |
| | Jogu_: my main concern is the difficulty of getting layout right. I assume with picsel's engineering group if these were problems easily addressed they'd not exist now. Leading me to believe the customer base for SOT might be more interested in content - not layout. One of the customers groups we'd like to approach, printer companies, will not be intereted in the product with the layout problems our testing is revealed. | 14:43.58 |
| | /is/has | 14:44.24 |
| Jogu_ | nods. I think it was a combination to be honest. We got to a certain point, then management were much more interested in spending money/time on other pie in the sky type stuff'; 6 years later microsoft etc have moved on a long way. | 14:45.01 |
| | it was also pretty much impossible to exactly match layouts when customers refused to give you enough rom budget to install more than one font, so at some point they just started to accept it wouldn't be perfect (much less of an excuse these days of course) | 14:45.44 |
| | I guess we really need to start looking through the issues - I presume the issues Robin showed me where whole pages of charts and tables vanish totally are likely to be the highest priority? though I guess maybe a pass through the top 50 docs xml office docs trying to classify exactly what problems there are might also help with priority? | 14:49.32 |
| henrys | Jogu_: so you think the issues can be dealt with? The other possibility is picsel engineering could not do it in which case I would doubt that we could. | 14:50.31 |
| Jogu_ | I'd really hope we can improve on it. I don't think picsel had much of a focus on it in the last 4 years+, so won't be surprised there may be some low hanging fruit in terms of interop with the latest MS releases of office, etc. | 14:52.05 |
| pedro_ | henrys: some of them can be, but older format variants (the OLE-based pre-xml files) were often poorly documented/not documented or just non-conformant | 14:52.06 |
| Jogu_ | whether we can get it to the level printer manufacturers want, not sure. | 14:52.29 |
| | ped> I think Robin had mentioned that the OLE ones seem like less of a priority | 14:52.42 |
| pedro_ | ok | 14:53.07 |
| henrys | pedro_, Jogu_ not worried about legacy | 14:53.31 |
| pedro_ | cool | 14:54.07 |
| Jogu_ | do you guys have a wiki or similar? | 14:55.57 |
| chrisl | Robin_Watts: thanks for looking at that buffer overflow bug (sorry, was dealing with a parent ranting about a grandparent!) | 14:56.48 |
| henrys | paulgardiner, marcosw have looked at most of the bugs. I would consider the most widespread first but I'll leave it to them. | 14:57.06 |
| chrisl | Jogu_: no we don't have a wiki..... | 14:57.33 |
| henrys | Jogu_: we do lean on bugzilla quite a bit for discussions about particular problems. | 14:58.07 |
| Jogu_ | where would things like, say, how to build for a particular customer get documented? | 14:58.13 |
| chrisl | We don't do builds for particular customers for gs or mupdf | 14:58.47 |
| henrys | Jogu_: there is an existing spreadsheet in the code base we were going to continue with that. | 14:58.47 |
| Jogu_ | okay dokey :) | 14:59.15 |
| henrys | Jogu_: is there something wrong with the spreadsheet you'd like to share with us? ;-) | 14:59.47 |
| Jogu_ | I'd need to check, but I don't think it documents how the build environments were actually setup | 15:00.13 |
| | eg. which version of xcode was used for example. | 15:00.19 |
| henrys | Jogu_: no it doesn't, but it would seem easy enough to add a column for tha. | 15:01.52 |
| chrisl | Jogu_: if the extra information gets too unwieldy for the spreadsheet, we're open to discussing other solutions | 15:02.40 |
| henrys | Jogu_: do you have git working okay on the epage repository it takes sometiime to check out, over 1G | 15:02.44 |
| Jogu_ | nods. if there's anything else I can just stick a text file in git alongside the spreadsheet or similar I guess. | 15:02.46 |
| | henry> yep, have cloned epage.git already | 15:02.57 |
| kens | Hmm, I just got kicked off for 'excess flood' | 15:04.21 |
| henrys | kens: another user as well so not just you. | 15:05.04 |
| kens | Weird because I didn't send anything.... | 15:05.23 |
| paulgardiner | Jogu_: we have that in a spreadsheet | 15:07.21 |
| | ... for SO that is | 15:07.21 |
| | We also have the old Picsel Wiki (we believe) but not yet in an accessible state | 15:07.24 |
| | Jogu_: true. Setting up the build environment is a bit hit and miss at the moment, although we've been told there may be documentation on the Wiki | 15:07.26 |
| Jogu_ | yeah, there should definitely be hints in old Picsel wiki ::-) | 15:09.16 |
| | iirc it was a relatively standard twiki, so shouldn't be too difficult to resetup, and the markedup files are all there in plain text in the filesystem anyway | 15:10.05 |
| henrys | Jogu_: just to verify: Picsel paid embedded general a per unit license fee (app store and OEM customers) for the print module. Right? | 15:24.30 |
| Jogu_ | henrys: I've replied to that privately | 15:35.37 |
| henrys | Jogu_: thanks, and yes a timesheet is fine. | 15:38.25 |
| Jogu_ | henrys: great, thanks | 15:39.51 |
| henrys | bbiab | 15:56.31 |
| ray_laptop | kens: I sent an email about horsing around in No. CA | 16:00.09 |
| | kens: let me know and I'll have my wife contact her | 16:00.42 |
| Robin_Watts | ray_laptop: I fixed bug 695090. | 16:17.43 |
| | I did once get a very odd effect, but I cannot reproduce it now. | 16:18.00 |
| kens | ray_laptop : thanks for the email, we'll have to wait and see what the staff meeting brings ;-) | 16:19.35 |
| henrys | paulgardiner, Robin_Watts: surprised there isn't more activity porting cups to android, running it on a raspberry pi is fairly popular. | 16:27.12 |
| kens | hrnrys I'm not clear on how CUPS would help on Android, the app would have to be able to produce some PDL on its own (or at least a bitmap) for it to use CUPS I think ? | 16:28.06 |
| | Without OS support printing is difficult | 16:28.27 |
| | Can you ask Android to give you a high resolution equivalent of the screen ? | 16:29.13 |
| Jogu_ | thought the taspberry pi foundation people activiely discouraged people from running android and point them at raspbian instead? | 16:29.42 |
| paulgardiner | A lot of these mobile solutions seem to work by just sending a file in it's orginal format | 16:29.52 |
| kens | paulgardiner : yes that's what I thought | 16:30.03 |
| | CUPS doesn't do general purpose file fromat conversion, you need to give it PCL, PDF, PostSc ript or a bitmap I think (I oculd be very mistaken) | 16:30.39 |
| paulgardiner | which makes me wonder what SO is doing. Sending the file to a print module has the potential of producing a layout that doesn't match the screen version | 16:31.01 |
| kens | I guess you could set up a relevant CUPS fiter if you had 'something' which would do the conversion | 16:31.07 |
| henrys | the upcoming print api for android will take a pdf or bitmap only I can't see how that is much different it can also provide a "PDF canvas" for the app to write to. but it will not support general file formats. | 16:31.35 |
| kens | paulgardiner : Yes, I think that is entirely possible. Of course, if the print module uses SO for its rendering, then it would be the same | 16:31.44 |
| paulgardiner | Now we have pdfexport working better, we could use that to give predictable layout, but I'd imagine that's not the current solution | 16:31.48 |
| Jogu_ | the print api out of the epage library was based on sending strips of high resolution bitmap [it may have changed] | 16:31.57 |
| paulgardiner | kens: yes exactly. Another reason why moving from Embeded General could have knock on effects | 16:32.23 |
| kens | henrys yes that's pretty much like CUPS. THe big point there is that it provides a PDF canvas, so if you spit an image onto it, then it will work.... | 16:32.34 |
| paulgardiner | Jogu_: oh okay. I'd doubt it has changed. | 16:32.51 |
| henrys | kens:right but you can give it a full pdf also, our app can do that now. | 16:33.47 |
| kens | henrys I wonder how they expect Android apps to produce a bitmap ? Surely that can't be the only way to draw things on the device ? | 16:33.51 |
| paulgardiner | ... although, having said that, I could see in the Android build that Software Imaging was supported by sending a file (I'm pretty sure) | 16:33.52 |
| Jogu_ | I really need to start getting my head around what has changed. | 16:34.10 |
| | paul> interesting. | 16:34.20 |
| kens | henrys yes, but also in that case you don't need CUPS. Presumably they have a PDF rendering engine built into Android | 16:34.25 |
| henrys | kens:the printing api is coming out in 4.4, I am wondering why nobody simply put cups on before. | 16:36.48 |
| kens | henrys presumably because there was no simple way to create a high resolution bitmap from the Android display. Without that, how would you print from an application ? | 16:37.25 |
| henrys | I thought there was and I thought you could produce pdf. | 16:38.30 |
| kens | You may be correct, I know next to nothign about Android | 16:38.43 |
| Robin_Watts | tor8: ping ? | 16:39.14 |
| | sebras: ping ? | 16:39.26 |
| henrys | paulgardiner: it seems to me if this print API is everything Google says it is, Software Imaging should go away and perhaps it is not a good idea to spend time on that, not sure. | 16:42.32 |
| Robin_Watts | henrys: There will always be devices that can't run 4.4 | 16:42.59 |
| henrys | Robin_Watts: of course, but how long will it be before requiring 4.4 or more is reasonable, not long the way the mobile market goes. | 16:44.21 |
| paulgardiner | Yeah, Im not sure either. I'd imagine we'd be unlikely to get a lot of new business from old versions | 16:44.38 |
| Robin_Watts | henrys: Most people last about 2 years with a phone. | 16:44.59 |
| | and often those phones are passed down to other people. | 16:45.08 |
| paulgardiner | So really our worry is upsetting current users | 16:45.09 |
| Robin_Watts | So figure on 4 years. | 16:45.14 |
| kens | chrisl are we building the release with XPSPrint compiled in ? | 16:45.58 |
| henrys | Robin_Watts: yes but it's common to update OS's these days. | 16:46.37 |
| Robin_Watts | henrys: My phone won't update past 2.3 | 16:46.49 |
| paulgardiner | It may be acceptable to support just Airpring on iOS and Google Cloud Print on Android | 16:46.55 |
| Robin_Watts | I'm getting Helens Galaxy S3 as soon as we get it back from the repair place, but that may well never run 4.4 | 16:47.26 |
| | and there is no way that the S3 can be called an 'old' phone. | 16:47.46 |
| chrisl | kens: I don't see why not | 16:48.39 |
| Robin_Watts | paulgardiner, sebras, tor8: mvrhel_laptop wants to be able to call pdfclean and pdfinfo as library things. | 16:48.58 |
| kens | chrisl in that case I'd probably better send you some words about that too.... | 16:49.01 |
| | It slipped my mind this morning | 16:49.18 |
| Robin_Watts | I've got a couple of commits on robin/master that should get us into the state where that works. | 16:49.29 |
| henrys | Robin_Watts: april - http://www.gottabemobile.com/2014/03/13/galaxy-note-2-galaxy-s3-android-4-4-release-details/ | 16:49.53 |
| chrisl | kens: I didn't know if we'd want to announce it, or sneak it out for interested parties to test, and announce it properly next time? | 16:50.21 |
| Robin_Watts | henrys: oh, ok :) | 16:50.28 |
| kens | chrisl OK then I shan't bother ;-) | 16:51.03 |
| chrisl | kens: that does mean we'll have to remember it next time! | 16:51.39 |
| Jogu_ | I'm not sure android 4.4 really solves the problem as such, at least not until all the printer manufacturers have developed their own print services app? or have they all committed to doing that? | 16:51.57 |
| Robin_Watts | Jogu_: There is an industry group talking about that now... mopria.org | 16:52.54 |
| | We are joining it, I think. | 16:53.07 |
| Jogu_ | robin_watts: ah... okay. but if that's the think, their API can be used be OS 4.4 too, from a quick read. (apologies if I'm going over ground you already went over!) | 16:54.57 |
| | their api can be used /pre/ 4.4, even. | 16:55.22 |
| henrys | Robin_Watts: I wish we could just strike a deal with general and leave things status quo⦠have some breathing room. | 16:56.49 |
| | Jogu_: apparently the print module contract ends end of march so we've got to do something ⦠a release without printing would be very bad. | 16:58.12 |
| Jogu_ | henry> yeah, I heard that :-( | 16:58.29 |
| Robin_Watts | mvrhel_laptop: I have 2 commits on robin/master. Once they go in, you should be able to call the clean and info stuff as library functions. | 17:12.33 |
| mvrhel_laptop | oh great. thanks Robin_Watts | 17:13.01 |
| Robin_Watts | np. | 17:13.07 |
| henrys | Jogu_: we joined mopria but I don't think much of it, my bet is google and apple will do as they please with android and iOS print workflow and the printer vendors will have to suck it up. | 17:16.26 |
| ray_laptop | mvrhel_laptop: I see why gsview would want the info function, but why the clean function (doesn't it automatically repair when opening a PDF ? Or are you going to offer some other 'save as' options that use the clean optins ? | 17:16.37 |
| | maybe the -g option ??? | 17:17.20 |
| mvrhel_laptop | ray_laptop: page extraction, linearization | 17:17.22 |
| ray_laptop | mvrhel_laptop: OK, thanks. I was just curious. For page extraction, what does mupdf do about off page links ? (I know that drives kens crazy) | 17:20.43 |
| mvrhel_laptop | ray_laptop: That would be a good question for Robin_Watts | 17:20.59 |
| ray_laptop | mvrhel_laptop: that question is probably not for you | 17:21.02 |
| | :-) | 17:21.10 |
| Robin_Watts | I can't remember. | 17:21.18 |
| | probably gets them wrong :) | 17:21.37 |
| mvrhel_laptop | :) | 17:21.42 |
| Robin_Watts | but there is scope for us getting them right :) | 17:21.54 |
| tor8 | Robin_Watts: pdfclean as a library thing sounds like a good idea | 17:23.29 |
| Robin_Watts | tor8: The changes on robin/master are the simplest steps to get towards that that I could do. | 17:24.19 |
| tor8 | Robin_Watts: looks reasonable to me. | 17:26.48 |
| Robin_Watts | both of them? | 17:26.58 |
| | (the fz_output_obj stuff too) | 17:27.10 |
| tor8 | first one LGTM | 17:27.18 |
| kens | mvrhel_laptop : we (GS) drops links that point to non-existent pages and warns the user | 17:33.54 |
| | Dests and such are basically impossible to get right in GS if you extract a subset of pages, if we preserve them then they will be wrong, so mostly we try not to preserve them if I can detect the user up to something sneaky like that. | 17:35.00 |
| | Goodnight all | 17:35.50 |
| ray_laptop | mvrhel_laptop: I am looking at reset_landscape_buffer. It is called outside the loop on 'j' for spp_out planes, but it seems to not move the data past the first plane | 18:32.01 |
| Robin_Watts | ray_laptop: Does it need to? | 18:33.32 |
| | Do we plot the first plane into the landscape buffer, then plot that out. Then repeat that for each plane? | 18:34.08 |
| ray_laptop | Robin_Watts: well the call to move_landscape_buffer is also outside the loop | 18:34.18 |
| Robin_Watts | i.e. do we reuse a single landscape buffer for all the planes. | 18:34.25 |
| | What does move_landscape_buffer do ? | 18:34.39 |
| ray_laptop | Robin_Watts: it moves the data but doesn't reset the pointers | 18:35.22 |
| Robin_Watts | So the for(j) loop does the plotting into the landscape buffer. | 18:37.04 |
| ray_laptop | they both are (probably) intended to move the byte we need to re-use for the next "strip" to the front of the buffer so the next lines in fill in after it | 18:37.31 |
| Robin_Watts | Then we call copy_mono or copy_planes to plot it through (all the planes from a single landscape buffer) | 18:37.33 |
| | Then we reset or move the data. | 18:37.47 |
| | Ah, so you're saying that they are only resetting or moving the first plane ? | 18:38.00 |
| | That does sound wrong, yes. | 18:38.58 |
| ray_laptop | Robin_Watts: as a result, I am getting stripes carried down the page every 32 lines because it updates the ht_landscape->curr_pos but doesn't move the data | 18:41.40 |
| Robin_Watts | ray_laptop: Right. That would fit with something I thought I saw earlier, but then could not reproduce. | 18:42.06 |
| ray_laptop | I've been working on the 4-bit mode. I guess that should occur as well with 1-bit mode. | 18:42.07 |
| | I'll try it with HEAD. | 18:42.24 |
| Robin_Watts | When you say "down" you mean "vertical stripes moving across the page" ? | 18:42.26 |
| ray_laptop | Robin_Watts: "down" to image which is plotted landscape from left to right | 18:42.54 |
| Robin_Watts | ray_laptop: Right. That's what I was seeing with the pkmraw bug you pointed me at earlier | 18:43.14 |
| ray_laptop | Robin_Watts: and yes, vertical stripes being carried along | 18:43.17 |
| Robin_Watts | so I can confirm that I've seen it with with 1bpp 4 colors, case. | 18:43.44 |
| ray_laptop | Robin_Watts: do you see it with the file (J8_landscape.ps) that was on the bug you fixed ? | 18:44.22 |
| | that's the main one I'm testing with. | 18:44.34 |
| Robin_Watts | yes. | 18:44.34 |
| | or at least I did. | 18:44.40 |
| | I then couldn't reproduce it, but I have to confess I didn't try very hard. | 18:44.51 |
| ray_laptop | Robin_Watts: OK. I'll confirm it, and then make sure my fix makes it go away. | 18:44.58 |
| | except for that issue, I have 4-bit per component planar (CMYK at least) working. | 18:46.02 |
| | whew!! OK, it fails with HEAD, so I'll fix it in the 4-bit patch. | 18:48.34 |
| | Robin_Watts: or do you think it should be a separate patch ? | 18:49.19 |
| Robin_Watts | ray_laptop: If there is a simple separate fix, having it separate would be nicer. | 18:49.46 |
| | but if the git foo required for that makes your head spin, don't worry :) | 18:50.03 |
| ray_laptop | This fails: debugbin/gswin32c -sDEVICE=pkmraw -o x.ppm -dMaxBitmap=400m -dUsePlanarBuffer J8_landscape.ps | 18:50.05 |
| | Robin_Watts: no, I can easily do it as a separate patch. | 18:50.25 |
| | Robin_Watts: can you look at the 'Fix output color values of pkm ...' patch? I'd like to push that one first | 18:51.42 |
| Robin_Watts | ray_laptop: Sure. | 18:51.53 |
| ray_laptop | the url is http://git.ghostscript.com/?p=user/ray/ghostpdl.git;a=commitdiff;h=6635a862fd4987b37484ca5fe15fb538d96ce47e | 18:52.13 |
| Robin_Watts | mvrhel_laptop: I've just pushed those pdfclean/info changes for you. Let me know if they make sense. | 18:52.38 |
| | ray_laptop: yes, that makes sense. | 18:53.35 |
| | You will probably get a warning though. | 18:54.05 |
| | max_value isn't used any more, I think? | 18:54.13 |
| ray_laptop | Robin_Watts: ok, right. I hadn't checked for linux compiler warnings. | 19:03.12 |
| mvrhel_laptop | Hi ray_laptop: sorry I missed you. Thanks for finding the issue with the buffer clean up. Not sure how that got by me | 19:31.14 |
| ray_laptop | mvrhel_laptop: I think it was intended to be in the loop, thus the test for 'allow_reset' to only reset the pointer things the last time through. | 19:38.57 |
| | that works, mostly, but now I have a blank vertical strip in the middle of the page :-( | 19:39.35 |
| | looking into why now. This stuff gives me a headache | 19:39.55 |
| mvrhel_laptop | ray_laptop: yes. I had to draw myself several pictures when I worked on this | 19:43.40 |
| | Robin_Watts: thanks for the pdfclean/info commit | 19:58.48 |
| | Forward 1 day (to 2014/03/14)>>> | |
IRC Logs