| | <<<Back 1 day (to 2012/04/02) | 2012/04/03 |
| mvrhel | aha. one last thing to add to the clist | 03:28.33 |
| | of course it is not a trival change... | 03:49.03 |
| | trivial | 03:49.08 |
| | done for the night | 04:50.28 |
| | figured out what I need to do in the clist. better to do it while I am awake... | 04:50.48 |
| Leper | I was fairly excited to see MuPDF grew android support | 05:27.59 |
| | but after isntalling it on a Kindle Fire it doesn't seem to be usable | 05:28.18 |
| | before I file a bug I was just wondering if there was something obvious I was missing | 05:30.51 |
| robin_watts_mac | Leper: Hi | 09:52.09 |
| | In what way does mupdf on the Kindle Fire not seem to be usable? | 09:52.11 |
| | We've tested it on Froyo/Gingerbread phones, and ICS tablets. | 09:52.39 |
| | The Fire is slightly odd of course... | 09:52.47 |
| | paulgardiner: Leper was complaining that the android app wasn't working on a Kindle Fire. | 10:22.34 |
| | but he hasn't given details of *how* it wasn't working. | 10:22.53 |
| | Leper: If I fall off the net, I will read logs. | 10:23.06 |
| | Thunder and Lightning here - keep getting power cuts. | 10:23.36 |
| paulgardiner | Ok. I'll keep an eye out for his comments. | 10:24.21 |
| | Thunder and Lightning? I bet that's real Thunder and Lightning over there. Enjoy. | 10:24.53 |
| robin_watts_mac | paulgardiner: Do we have a meeting scheduled this week to discuss forms work ? | 12:28.25 |
| paulgardiner | Yep. And may be handy because I've just run into a difficulty. | 12:29.01 |
| robin_watts_mac | When ? | 12:29.08 |
| paulgardiner | 17:30, after the main meeing. It's 13:29 here now. | 12:29.55 |
| robin_watts_mac | Right. I'll be long in bed by then. | 12:30.11 |
| | It's 18:30 here, and I'm in the air all tomorrow. | 12:30.46 |
| paulgardiner | Do you have a moment now, dare I ask? | 12:31.08 |
| robin_watts_mac | Yes. | 12:31.18 |
| paulgardiner | Up until now, I've only had to change which appearance stream is being displayed, or alter an existing one. But now I need to construct one from scratch. | 12:32.23 |
| robin_watts_mac | Right. | 12:32.33 |
| | Did you look at SumatraPDF.patch ? | 12:32.56 |
| | I'm pretty sure that the last email we had from zeniko specifically OK'd us using the sections of that that do AP synthesis. | 12:33.49 |
| paulgardiner | I want to make the thing I construct as much as possible like a stream from the doc, so it wont confuse the rest of MuPDF. But that means creating a new indirect object. | 12:33.50 |
| | Haven't looked at SumatraPDF. Was it just one patch? | 12:34.22 |
| robin_watts_mac | OK... I believe we can do that. In fact, I believe we DO do that in at least one of the tools. | 12:34.25 |
| paulgardiner | pdfclean perhaps | 12:34.42 |
| robin_watts_mac | It's a diff between our supplied mupdf and the sumatraPDF version. | 12:34.50 |
| | As such it's got LOTS of stuff in it, not all of which is relavent. | 12:35.14 |
| | And indeed some of it we don't want. | 12:35.22 |
| paulgardiner | Oh I see. I thought you'd given me a link to a svn repo. | 12:35.38 |
| robin_watts_mac | History suggests that some of the fixes are spot on, and some are done in ways we don't agree with. | 12:35.47 |
| | Do you have the link? I can hunt for it if not, | 12:35.58 |
| paulgardiner | I don't sorry. | 12:36.31 |
| robin_watts_mac | http://software.zeniko.ch/sumatrapdf/SumatraMuPDF.patch | 12:37.09 |
| | I can't promise that it works the right way. | 12:37.55 |
| | But it's probably worth looking over. | 12:38.04 |
| paulgardiner | Definitely worth a look | 12:38.22 |
| robin_watts_mac | search for pdf_create_annot and look after that. | 12:39.41 |
| paulgardiner | One problem with creating a new indirect object is coming up with a fresh num and gen - especially as one may not had read all the existing ones in the file | 12:39.46 |
| robin_watts_mac | We always read the entire xref at startup. | 12:40.05 |
| | Hence we always know the maximum num and gen. | 12:40.16 |
| paulgardiner | That's handy. | 12:40.30 |
| robin_watts_mac | So creating a new indirect object is not a problem (he said confidently :) ) | 12:40.46 |
| paulgardiner | I think I've just seen why the other thing I was worried about isn't a problem. | 12:41.17 |
| robin_watts_mac | Right. pdf_new_indirect | 12:41.54 |
| paulgardiner | I was worried about MuPDF attempting to load the stream, but I will have ensured that it is stored, so pdf_load_xobject will go to store | 12:42.25 |
| robin_watts_mac | It's used from inside apps/mupdfclean.c | 12:42.40 |
| | (and various places in pdf/*.c, but the apps/*.c is not an 'internal' use) | 12:43.02 |
| | paulgardiner: You mean, you'll have ensured that the stream is stored as a buffer in memory, so any normal accesses through mupdf will read from that store? | 12:43.40 |
| paulgardiner | Yep. | 12:43.51 |
| | ... I think. | 12:43.55 |
| robin_watts_mac | yes. Hopefully there is refcounting in the right place there so that we can safely replace the buffer when we regenerate (or at least detect when it's not safe to regenerate) | 12:44.32 |
| paulgardiner | I'd seem pdf_new_indirect, but it was choosing num/gen, and ensuring the indirect thing resolved correctly that was worrying | 12:44.35 |
| | ref counting as looked sane so far. | 12:44.56 |
| | s/as/has/ | 12:45.33 |
| robin_watts_mac | mupdfclean.c does funky renumbering etc when it garbage collects unwanted objects. | 12:45.34 |
| | xref->len gives you the maximum xref object number I think. | 12:46.04 |
| | And gen = 0. | 12:46.08 |
| paulgardiner | Magic. | 12:46.14 |
| | So I can just shove a new one on the end of the table | 12:46.34 |
| robin_watts_mac | Yes. I believe so. You may need to ensure there is room in the table etc, but I don't think that's a problem. | 12:47.19 |
| | (Lots of mupdfclean should arguably be split out to be library functions, rather than being at the app level) | 12:47.44 |
| | Ideally all our 'tools' should be thin wrappers around library functionality, but mupdfclean knows about internals. | 12:48.13 |
| | so the renumbering and gc of objects should possibly be extracted back into a separate part of the lib. | 12:48.45 |
| paulgardiner | Sounds like I should give mupdfclean a good look over in case I can easily break out some existing functions. | 12:48.51 |
| robin_watts_mac | (I'm sure tor8 will have opinions on this when he comes on line) | 12:48.58 |
| | We didn't get time to do that for 1.0 | 12:49.07 |
| | paulgardiner: That would be good. | 12:49.19 |
| | I suspect that if we DO pull stuff from mupdfclean to the lib we should take care to ensure we don't introduce additional dependencies. | 12:50.18 |
| | (i.e. we put it all in new object files so that they don't add any weight to apps that don't need that functionality) | 12:50.53 |
| | I think I broke something in my 1.0 work that has caused lots of font data to get linked into tools that don't really need it :( | 12:51.24 |
| | I'm going to have to go help pack in a bit. Any remaining bits of clear water left that I can muddy before I go? :) | 12:52.08 |
| paulgardiner | No. Things could hardly be more opaque. :-) | 12:53.15 |
| | Actually, that's sorted out the problems I think. | 12:53.34 |
| robin_watts_mac | cool. | 12:53.39 |
| paulgardiner | Where you flying next? | 12:54.22 |
| robin_watts_mac | Kathmandu -> Delhi, Delhi -> Heathrow. | 12:56.56 |
| | Land at 18:30 tomorrow. | 12:57.04 |
| sebras | robin_watts_mac: Taiwan here I come! :) | 14:10.34 |
| | robin_watts_mac: have a safe trip home. | 14:10.52 |
| mvrhel | good morning | 14:39.22 |
| kens | morning michael | 14:39.33 |
| mvrhel | hi kens: so I looked only a little at that weird tiffsep bug just to see if my planar stuff fixed it. unfortunately it did not but it should not be too difficult to catch this issue | 14:42.59 |
| kens | I didn't look at it at all I'm afraid, it just came to mind when you said you were doing tiffsep and overprinting | 14:43.35 |
| robin_watts_mac | Morning mvrhel | 14:44.07 |
| mvrhel | hi robin_watts_mac. | 14:44.33 |
| | robin_watts_mac: when my wife returns this weekend with the kindle fire, I can do some mupdf testing also on it if you need me to (reading the logs) | 14:46.26 |
| robin_watts_mac | mvrhel: Thanks, but Leper hasn't told us exactly what's wrong. It may be that it's just not behaving as he expects. | 14:47.04 |
| mvrhel | ok | 14:47.13 |
| paulgardiner | I can quite imagine that there's a very complicated problem specific to the Kindle Fire. I think I'll need to have one here for some considerable time. Did that sound convincing? :-) | 14:51.15 |
| robin_watts_mac | paulgardiner: The Kindle fire is strange. Amazon have crippled it so you can't use the Market on it (without rooting it). | 15:18.46 |
| | They want you to get all your apps/content from Amazon. | 15:19.01 |
| henrys | robin_watts_mac:the bhutan fb pics are incredible wow! | 15:19.29 |
| robin_watts_mac | henrys: Yeah. The last day (Tigers Nest + Festival) were just fab. | 15:20.14 |
| kens | robin_watts_mac : what is your Facebook account ? | 15:20.19 |
| robin_watts_mac | robinjohnwatts | 15:20.59 |
| kens | thanks | 15:21.02 |
| henrys | I didn't realize adobe had released a free epub reader - Digital Editions. | 15:24.37 |
| | good thing we got snow today ... 0 precipitation in March, amazing we didn't have more fires. | 15:26.23 |
| tkamppeter | chrisl, hi | 15:28.22 |
| chrisl | tkamppeter: hi | 15:28.31 |
| tkamppeter | chrisl, I did not report the recent problems to Cairo, but other GS slowness problems got reported to Cairo and Cairo got improved for them. For another Cairo bug report I will need your help so that you explain exactly what is wrong in Cairo's PDF output. | 15:30.14 |
| henrys | marcosw_:if you can reproduce the cert vulnerability just make it bountiable and shelly can work on it. | 15:32.06 |
| chrisl | tkamppeter: the issue is very simple: the cairo PDFs use PDF transparency constructs *always*, even when painting opaque objects - which is just pointless. Secondly, they set the bounding box for every transparency group to be the entire page - since we have to allocate a buffer to hold the group, we can end up dealing with several multiples of the memory for a single page raster | 15:34.16 |
| mvrhel | yes. they need to get this fixed | 15:38.02 |
| | tkamppeter: I have set up all my travel plans for the open printing summit. | 15:38.54 |
| chrisl | unfortunately, it's not strictly "wrong" according to the spec :-( | 15:39.06 |
| kens | But it is inefficeint. | 15:41.43 |
| tkamppeter | mvrhel, great, I am looking forward to meet you there. | 15:41.50 |
| kens | so Is the one I looked at recently where everything is nested latyer upon latyer deep | 15:41.57 |
| chrisl | mvrhel: might there be scope to spot, when we push a group, that the contents of the group we're pushing will obscure the previous group (amongst other things!), and share the buffer between the new and previous groups? | 15:42.12 |
| Leper | in re MuPDF on the Fire, I just can't figure out how to open a pdf in MuPDF at all | 15:42.46 |
| tkamppeter | chrisl, kens, another problem are crashes in clist mode (https://bugs.launchpad.net/ubuntu/+source/ghostscript), does someone know from what these come? Can GS be fixed to avoid this? | 15:43.54 |
| Leper | it's easy enough to start up MuPDF but then... the menu button doesn't do anything and there's nothing obvious I can do to make it the default viewer for pdf | 15:44.11 |
| kens | tkamppeter : segv should not happen at all, ever. | 15:44.23 |
| | So that's a bug | 15:44.27 |
| mvrhel | chrisl: that would be difficult without actually drawing it. maybe if you new you were about to fill a region that covered the whole drawn_in rect of the current group and you knew the opacity | 15:44.35 |
| kens | tkamppeter : 'indefinitely long running' could mean almost anythign, including being the result of a Cairo PDF ;-) | 15:45.05 |
| paulgardiner | Leper: it lists only the PDF files in the dowloads directory, which isn't ideal, but it does announce itself as a displayer of PDF files, so any File Manager should be able to trigger it. | 15:46.11 |
| kens | tkamppeter if you would care to raise bug reports in Bugzilla we can try to reproduce. We'll ened the source files of course. | 15:46.26 |
| Leper | hmmm ok, lemme poke around and see if I can shuffle my pdfs | 15:46.45 |
| chrisl | mvrhel: I'd kind of thought that if the *group* was opaque, we could simply draw straight onto the underlying group buffer, and avoid the final compositing operation when we pop it. | 15:46.47 |
| tkamppeter | kens, this bug looks actually like a Cairo problem, but up to now I did not succeed to make the original reporter attach the input file. If he does not send it, the bug will get victim of expiring in 60 days ... | 15:47.05 |
| kens | tkamppeter : the 'long running' one says it is resolved if he removes transparency, so my guess is that its a transparency complication problem | 15:47.24 |
| mvrhel | if it were a knockout group that is possible. that optimization should already be in though | 15:47.33 |
| | I would hope.... | 15:47.36 |
| ray_laptop | kens: I was able to reproduce that to the pbmraw device on my laptop. | 15:47.55 |
| kens | ray_laptop : which ? | 15:48.07 |
| tkamppeter | kens, I would like to, but did not get any files to reproduce from the users. | 15:48.13 |
| ray_laptop | kens: that's the Ausgabe that file bug mentions hl1250 | 15:48.29 |
| kens | tkamppeter : there's not a lto we cna do if we cna't reproduce it, I'm sure you appreciate that. | 15:48.32 |
| ray_laptop | the long running job. Originally I thought it was because the guy mentioned a Pentium 3 with 312Mb RAM | 15:49.16 |
| kens | Ah. | 15:49.22 |
| ray_laptop | but it is slow even on my laptop. | 15:49.29 |
| tkamppeter | kens, yes. Many bugs simply expire because users report the bugs and forget them, or they even cannot reproduce them themselves. | 15:49.32 |
| kens | yes, but I susepct its a pointless transparency Cair file ray_laptop | 15:49.48 |
| | since it works OK with no transparency | 15:50.03 |
| ray_laptop | oops -- doctor called me be back later. | 15:50.11 |
| kens | But if it reall is that slow maybe Michael should look at it | 15:50.19 |
| chrisl | mvrhel: I think we might fast track the compositing for knockout groups, but always seem to allocate a new buffer for a new group. | 15:50.56 |
| mvrhel | chrisl: perhaps. are they even using knockout groups in the cairo output | 15:51.54 |
| kens | mvrhel they use so many.... | 15:52.08 |
| chrisl | mvrhel: no, I just went to look, and they are (so far) non-knockout :-( | 15:52.26 |
| | tkamppeter: tbh, I can't see how a conforming PDF consumer can avoid a performance hit with these Cairo files - maybe not as a bad as we see with GS just now, but still........ | 15:56.06 |
| henrys | I guess we should start the meeting. I really didn't have anything other than to encourage folks to review the meeting agenda and see if there is a project that can be chipped away at. | 15:59.54 |
| | the bugs look really good. | 16:00.18 |
| kens | I've made some progress with the memory management in pdfwrite/ps2write, but its going to be a long job | 16:00.36 |
| | I also need to start a local branch for it, so I'll talk to Robin about it when he gets back | 16:00.59 |
| henrys | mvrhel you had a request for marcosw_, not sure if he's here. | 16:01.06 |
| mvrhel | I may have this tiffsep planar stuff wrapped up this week. it is a big change though and I want to talk to marcosw_. just typing that henrys... | 16:01.24 |
| | of course it leads to minor color count diffs in tiff sep and psdcmyk output. | 16:01.58 |
| henrys | alexcher:are you out of bugs? | 16:02.29 |
| | customer bugs? | 16:02.38 |
| alexcher | henrys: No. | 16:02.58 |
| henrys | looking at tor8 mooscript branch would be useful. | 16:03.12 |
| | robin_watts_mac:it looks like we will need the special filling after all I've been working again with them. | 16:04.01 |
| chrisl | mvrhel: cluster testing tiffs is problematic because they're not streamable (so the piped output doesn't work), and the headers include time and date info, so just md5 summing the output doesn't work. | 16:05.31 |
| mvrhel | hmm. I would think we would have the same issue with psdcmyk | 16:05.54 |
| chrisl | Which, the not streamable, or the time and date thing? | 16:06.37 |
| henrys | maybe marcosw_ is traveling today? I know he was off to somewhere. | 16:06.48 |
| mvrhel | chrisl: no I guess there is not a date there | 16:08.01 |
| | not sure about streamability | 16:08.28 |
| chrisl | Is psdcmyk compressed? | 16:08.43 |
| mvrhel | it can be but not in a lossy manner | 16:09.10 |
| | we dont compress it | 16:09.28 |
| henrys | mvrhel:anyway I would just send a short email to marcosw_ and tell him at a high level what you need and he can figure out something or suggest something different or ignore you completely ;-0 | 16:09.31 |
| chrisl | We did discuss tiff testing with Marcos a while back, and he did have some ideas for working around those problems - even if it can't be done quickly for the cluster, there may be other options to help you. | 16:10.19 |
| henrys | kens:I keep forgetting to update the pdfwrite server bug with the memory violation, I'll definitely do that today. | 16:10.22 |
| | tor8:anything for the meeting. | 16:10.29 |
| mvrhel | yes. well I have a little script here that I run to compare the psdcmyk files but it is slow compared to having all the diffs shown to me from output from the cluster | 16:10.33 |
| henrys | alexcher:you have 0 bugs in the bug aging report is the report broken (missing something). | 16:11.30 |
| | ? | 16:11.31 |
| chrisl | mvrhel: Personally, I'd like to see tiff output added to our testing - it's still a widely used format, despite its limitations...... | 16:12.06 |
| alexcher | henrys: I have a few P2 pugs left. I don't know the logic behind the bug aging report. | 16:12.57 |
| | henrys: I have a few P2 bugs left. I don't know the logic behind the bug aging report. | 16:13.16 |
| mvrhel | henrys: I have gotten a few emails from customer #330. He is actively working on getting upgraded to the lastest version of gs and it sounds like I will need to spend a little time with him getting a few things hooked up for named color support | 16:13.21 |
| | I will forward you the email | 16:13.26 |
| henrys | alexcher:they ought to be enhancements or not have bug numbers. | 16:13.33 |
| mvrhel | he has quite a laundry list of needs actually.... | 16:14.11 |
| henrys | mvrhel:okay. I'll talk to miles about the revenue picture. I thought they were sinking fast in which case it may not be a great investment. | 16:15.52 |
| mvrhel | ok yes. let me know | 16:16.04 |
| henrys | of course if it is generally worthwhile stuff ... | 16:16.06 |
| mvrhel | yes | 16:16.10 |
| henrys | anybody else? if not let's adjourn. | 16:17.06 |
| | alexcher all of your p2 customer bugs are ennancement the bug aging report is correct, you have 0 bugs congratulations !!! | 16:19.01 |
| marcosw_ | sorry I'm late | 16:19.17 |
| henrys | it's all in the bookkeeping ;-) | 16:19.23 |
| | marcosw_:read above | 16:19.40 |
| marcosw_ | just did. mvrhel wants me to run a test or document how he can do it. details in an email. | 16:20.04 |
| henrys | alexcher:I would say mooscript is more important than any of the P2's | 16:20.15 |
| Leper | paulgardiner, ok, moved my PDFs out of Documents and into Download and now indeed they all show up in mupdf | 16:20.34 |
| henrys | marcosw_:and further up the cert vulnerability | 16:20.55 |
| Leper | and mupdf supports links... which is awesome | 16:21.00 |
| mvrhel | marcosw_: so my goal is to have bmpcmp output for the tiffsep composite output like we have now when I run bmpcmp after a regression run. I will wait for your email.. | 16:21.07 |
| paulgardiner | Leper: ah good | 16:21.10 |
| Leper | I'll beat on things and file any bugs I find | 16:21.47 |
| henrys | robin_watts_mac:did you have anything from your perch on the world? | 16:21.57 |
| paulgardiner | Leper: Great. Thanks. | 16:21.58 |
| henrys | robin_watts_mac:oh actually you are a bit lower then me. so nvm. | 16:23.13 |
| | alexcher:so the bug aging report does not include enhancements. | 16:26.10 |
| alexcher | henrys: OK | 16:27.14 |
| henrys | paulgardiner, tor8:should we do the forms meeting? Still doesn't look like a lot to discuss. | 16:30.25 |
| | oh I guess tor isn't here. | 16:30.54 |
| | paulgardiner:I suggest we postpone the meeting until tor8 and robin_watts_mac are back on duty. | 16:33.14 |
| paulgardiner | I've gotten a bit further than when I sent the email. I now look to be creating appearance streams, and so I can insert text into more of the fields on my test doc than I could earlier, though not all of them. | 16:33.32 |
| | henrys: Sounds sensible. I needed some info earlier, but I managed to catch Robin. | 16:34.04 |
| | There's some aspects of Sumatra's patch that we may want to discusss, but as you say, best to wait for Tor and Robin. | 16:35.07 |
| henrys | at some point when we are about on IRC we'll reschedule I don't want to wait until next Tuesday. | 16:35.45 |
| ray_laptop | sorry I missed the meeting -- I had a doctor's appt this AM (only time I could get) -- finished now | 16:35.49 |
| paulgardiner | henrys: Yeah sure. | 16:36.49 |
| ray_laptop | mvrhel: is there a general reason why colors will differ with planar vs. encoded color ? (except for non-encodeable, of course) | 16:37.15 |
| mvrhel | there seems to be a rounding diff | 16:37.31 |
| ray_laptop | mvrhel: Oh, OK. maybe some "preparation" of the color value in the encoding before looking it up. | 16:38.36 |
| mvrhel | ray_laptop: what I need to do is to make a simple case and see where the diff is coming from | 16:38.40 |
| | and see if I can get them to do the same | 16:38.55 |
| | thing | 16:38.59 |
| ray_laptop | that differs from the way you are reducing the color to 8 bit | 16:39.03 |
| mvrhel | yes | 16:39.12 |
| | I think robin_watts_mac had done some rounding fixes not too long back vs. the simple bit shift approach | 16:39.47 |
| marcosw_ | chrisl: any news on <http://bugs.ghostscript.com/show_bug.cgi?id=692459>? the customer is asking and it's been a while since you "volunteered" to look into it. | 16:39.52 |
| ray_laptop | mvrhel: it probably is not worth spending very much time on as long as the differences are trivial | 16:40.07 |
| mvrhel | the only reason to do it, would be so that I can get rid of the noise and see any real diffs | 16:40.33 |
| | ray_laptop: clist question for you | 16:40.45 |
| chrisl | marcosw_: I know what needs doing, it's a few days work - but I'm hoping to put it off until mvrhel is done with his current work on tiffsep | 16:41.54 |
| ray_laptop | mvrhel: is the stuff that cust 330 different to what customer 190 needs (since they are in the same market) ? | 16:42.04 |
| | mvrhel: go ahead w/ your clist question (or call if you want) | 16:42.20 |
| kens | OK I'm heading off, night veryone | 16:42.36 |
| ray_laptop | bye, kens | 16:42.41 |
| chrisl | marcosw_: and given that customer's status, I didn't feel it was my top priority....... | 16:43.28 |
| mvrhel | ray_laptop: I have to add in the capability for rect_fill with the devn color. I am trying to figure out if I need to add in a cmd_opv_hl_rect command. I dont see an easy way otherwise for there code to "know" that it will be using the devn color that it current has | 16:43.54 |
| henrys | I guess 330 still has good status, they are still full support for some reason I thought they had tumbled, maybe somebody else. | 16:43.55 |
| mvrhel | s/there code/the code/ | 16:44.13 |
| henrys | so alexcher do you agree mooscript is the priority, we really do want to get that project going. | 16:44.57 |
| mvrhel | ray_laptop: customer 330 is pushing way ahead in their use of gs compared to customer 190. It really is a good thing since he is going to actually use this stuff | 16:45.03 |
| henrys | 190 is now my hell. | 16:45.57 |
| marcosw_ | chrisl: the latest customer list from Joanne shows customer 393 as "Full Support". was there a change in status that I missed? | 16:45.58 |
| ray_laptop | mvrhel: yes. Since some paths writing the clist write rectangles (like decomposed images) you need to use the hl variant of fill_rect instead of the other. | 16:46.10 |
| alexcher | henrys: Yes, the only problem is that I cannot find 'mooscript' anywhere in the bug tracker or mail log. | 16:46.12 |
| henrys | alexcher:it is a branch in the public git repo | 16:46.35 |
| mvrhel | ray_laptop: that is exactly the case I have now. it is a devn image that i getting chopped into rects | 16:46.54 |
| henrys | remotes/origin/mooscript | 16:46.58 |
| mvrhel | with the new color type | 16:47.01 |
| | s/that i/that is/ | 16:47.19 |
| ray_laptop | mvrhel: you don't need to bother with correcting the typos -- I'm used to reading logs from kens ;-) | 16:47.51 |
| mvrhel | ray_laptop: looking at gxcldev.h around line 89, what opcode should I use? | 16:48.30 |
| chrisl | marcosw_: I thought 393 were a support only customer - and I think they're probably used up all the hours they had.......... | 16:48.30 |
| mvrhel | can I use 0xd0 ? | 16:48.54 |
| ray_laptop | probably mvrhel's work alone is enough to have used up cust 393's hours (assuming they are hourly) | 16:49.23 |
| mvrhel | this thing is easy 3 to 4 weeks time | 16:49.50 |
| ray_laptop | mvrhel: sure -- just pick one that is no longer used. I'll have a quick look to see if there is a better one. | 16:50.04 |
| mvrhel | I think the rect fill ones need the lower nibble to be 0 | 16:50.46 |
| marcosw_ | chrisl: my reading of their status is that they have infinite hours of support (since they have to pay after a certain number of hours it's not really infinite, but you know what I mean). | 16:51.06 |
| mvrhel | I could make this project take an infinite number of hours... | 16:51.46 |
| | ray_laptop: so how arecmd_op_fill_rect_short and cmd_op_fill_rect_tiny generated? | 16:53.25 |
| alexcher | mvrhel: 1 hour on the 1st week, 1/2 hours on the 2nd week, and so on. | 16:53.27 |
| mvrhel | alexcher: very good! I love math jokes | 16:53.47 |
| chrisl | marcosw_: nevertheless, although the risk is low, I'd rather not chance clashing with mvrhel's work, unless we have really good reason | 16:54.08 |
| ray_laptop | mvrhel: oops. you also need to check gxclpath.h -- 0xd0 is already cmd_op_misc2 | 16:54.11 |
| mvrhel | ah yes the extended commands | 16:54.46 |
| | I thought there were more some palce | 16:54.57 |
| ray_laptop | mvrhel: there are several deprecated codes in the 0xf? rnage | 16:55.14 |
| marcosw_ | chrisl: I agree, the issue has been open for months, so waiting until mvrhel commits his changes make sense. | 16:55.27 |
| chrisl | marcosw_: I actually didn't think they had pushed back on 692459, which was why I was ignoring it for now | 16:56.52 |
| mvrhel | ray_laptop: ok I will need to look this over. my worry is that the rect fill stuff currently concants with the command op in the lower nibble and I am hoping to just use the existing cmd_write_rect_cmd with the new op command | 16:57.14 |
| ray_laptop | mvrhel: feel free to reorganize them if you want a set of values with common upper bits. It looks like f1, f2, f4, f5, f7, f8, fa, fb, fd, fe are available (and probably ff) | 16:57.17 |
| marcosw_ | henrys: I'm looking at the cert email, there are 79 issues in their .7z file. | 16:57.21 |
| | so it may take me a while to get through them :-) | 16:57.33 |
| ray_laptop | mvrhel: that's why I suggested re-ordering the existing ones | 16:57.47 |
| marcosw_ | chrisl: true, 459 isn't a big issue for them at the moment, but they are clearly in the midst of a release or something, since they reported several issues and wanted updates on others. | 16:58.22 |
| mvrhel | ray_laptop: ok . gotcha. so I could move the current f? ones to new spots making 0xf? avaiable | 16:58.35 |
| marcosw_ | so I figured we might as well fix one before they complain about it. | 16:58.46 |
| ray_laptop | mvrhel: let me look at cmd_write_rect ... | 16:59.48 |
| chrisl | marcosw_: I'll take a quick look tomorrow - we *might* be able to solve *this* particular issue in another way. | 17:00.03 |
| | henrys, marcosw_: if you're going to punt these cert issues to Shelly, I should mention he's off traveling for a few weeks........ | 17:00.14 |
| tkamppeter | chrisl, kens, mvrhel: https://bugs.freedesktop.org/show_bug.cgi?id=48260 | 17:00.56 |
| ray_laptop | mvrhel: I don't think you can use cmd_write_rect_cmd -- it assume that the HIGH nibble has variants for normal, short and tiny | 17:02.38 |
| mvrhel | ray_laptop: ok. | 17:03.21 |
| | so I will need to write a new function with my command op and the rect information | 17:03.57 |
| chrisl | tkamppeter: cool, thanks! FWIW, I took page 12 of the test file for Bug 692959, and had Acrobat render it @600dpi, and it took 1 minute 13 seconds (admittedly in a virtual machine), so GS taking 54 seconds (from Ray's test) doesn't seem too bad | 17:04.21 |
| ray_laptop | mvrhel: VERY ugly bit of code -- has constants of 0x10 and 0x20 (you know how much I hate constants that are "magic") | 17:04.23 |
| mvrhel | ray_laptop: ok in the case, I will write something new. we will not have short or tiny variants though at this point | 17:04.59 |
| | only a normal rect | 17:05.09 |
| | are you fine with that? | 17:05.14 |
| ray_laptop | mvrhel: short and tiny are much more likely since the primary usage will be from decomposed images and maybe gradients | 17:05.41 |
| mvrhel | ray_laptop: oh | 17:05.54 |
| ray_laptop | mvrhel: but this is only for devn, so I'm not that upset about the clist being larger | 17:06.16 |
| mvrhel | so, should I consider having 3 new op codes then, but not worry about packing in the lower nibble? | 17:06.39 |
| ray_laptop | mvrhel: what would you pack into the lower nibble ? | 17:07.00 |
| mvrhel | I dont' know. I just see that this was what the current cmd for rect fill was doing so I assumed that there was a reason and an advantage to do it with the rect command | 17:07.46 |
| | if not, then I will just write out an opcode and then the parameters and move on | 17:08.05 |
| ray_laptop | mvrhel: probably as long as we have a single byte dx, dy (short) variant as well as the "full_size" that is enough | 17:08.37 |
| mvrhel | ray_laptop: ok, I will add in those two. | 17:09.04 |
| ray_laptop | mvrhel: after all the x and y are full range values, right ? | 17:09.10 |
| mvrhel | thanks for walking me through this | 17:09.12 |
| ray_laptop | doesn't recall if coordinates are 'packed' -- going to check | 17:09.36 |
| mvrhel | yes. I was wondering what was going on in the rect cmd. I just read that the lower 4 bits are used for something | 17:09.53 |
| | anyway. pushing on | 17:10.22 |
| tkamppeter | chrisl, kens, can someone give me a patch for 9.05 to fix bug #692419. Thanks. | 17:13.17 |
| chrisl | tkamppeter: just do a git bisect on it | 17:14.28 |
| ray_laptop | mvrhel: OK, the cmd_putw and cmd_put2w look like they have variable length | 17:14.29 |
| mvrhel | oh based upon the data lenght | 17:18.47 |
| | zeros avoid... | 17:19.21 |
| ray_laptop | mvrhel: I hadn't looked at this area for a few (10+) years. So, it looks like the tiny and short variants rely on the distance between the previous rectangle (from the state) being cllose so they don't need to use 'cmd_put_rect' whiich writes the variable length values for x, y, w, h | 17:19.27 |
| mvrhel | ray_laptop: yes. I was hoping to avoid having to rewrite any of this.... | 17:20.03 |
| ray_laptop | mvrhel: let's just keep it simple and use a single op and always use cmd_put_rect | 17:20.07 |
| mvrhel | ok good | 17:20.14 |
| ray_laptop | separations for devn will all be host based and so the clist size is not an issue (IMHO) | 17:20.48 |
| mvrhel | exactly | 17:20.56 |
| ray_laptop | mvrhel: sorry it took a bit of digging (refreshing my understanding of the clist) before getting around to an answer | 17:22.03 |
| mvrhel | no reason to be sorry. you just saved me a bunch of time | 17:22.18 |
| ray_laptop | mvrhel: but you will need a new function to use instead of cmd_write_rect_cmd | 17:22.22 |
| mvrhel | yes | 17:22.28 |
| | but I will not need to do all those tests to determine what variant to write | 17:22.59 |
| ray_laptop | mvrhel: agreed. and that simplifies the writing and the reading | 17:23.28 |
| mvrhel | yes | 17:23.35 |
| | it appears to me that 0xd1 is available | 17:25.19 |
| | and it fills in a hole since all the other 0xd* values are used | 17:27.00 |
| ray_laptop | mvrhel: looks like 0xd0 and 0xd1 are available | 17:35.46 |
| | mvrhel: maybe I'll use up 0xd0 for 'fillpage' (since it also uses HL color) | 17:36.14 |
| | mvrhel: that'll give me the excuse to go in and get rid of that nasty hack for 0 width 0 height fill_rect meaning 'fillpage' | 17:38.41 |
| mvrhel | yes. I just read that "special" case yesterday | 17:39.09 |
| | ok. got the writer side done. I will get the reader in place when I get back. have to go pickup the car at the shop. | 17:39.38 |
| ray_laptop | mvrhel: OK. TTYL | 17:39.52 |
| | I have to leave the coffee shop now anyway ... | 17:40.22 |
| | cust 532 has another issue on the 6thgen product :-( Hopefully it will be easy -- at least it is reproducible on the simulator | 18:41.52 |
| robin_watts_mac | henrys: special filling? | 23:08.18 |
| henrys | 692809 | 23:10.25 |
| robin_watts_mac | mvrhel: Yes, I added a b | 23:10.38 |
| | color rounding, which removed a lot of lcms vs non lcms diffs (which just looked like it added lots of 1 bit diffs in the cluster of course) | 23:11.41 |
| | Ah, right. | 23:18.08 |
| henrys | where are you now? dehli? | 23:23.21 |
| | bbiab | 23:24.09 |
| robin_watts_mac | henrys: just waking up in Krapmandu, about to go get on a plane. | 23:37.44 |
| | Happy Birthday Henrys! | 23:47.18 |
| mvrhel | hey happy birthday henrys | 23:51.22 |
| | robin_watts_mac: hope you have a good flight | 23:51.46 |
| sebras | q | 23:52.21 |
| | Forward 1 day (to 2012/04/04)>>> | |
IRC Logs