| | <<<Back 1 day (to 2013/09/26) | 2013/09/27 |
| mvrhel_laptop | ok. very close to having nonisolated knockout transparency groups working in gs. at least it is working on the files that Robin_Watts had given me. need to clean up a few things and do a general cluster push to see if I broke anything | 05:10.01 |
| | looks like I broke the isolated knockout group case. will fix that tomorrow | 05:23.30 |
| jhabjan | hi | 10:40.05 |
| ghostbot | hey | 10:40.05 |
| jhabjan | anyone around? i have a question about gs api stdio | 10:40.55 |
| | stdin exactly | 10:40.59 |
| kens | Don't ask to ask, just ask | 10:41.14 |
| jhabjan | :) thanks | 10:41.32 |
| | ok, i saw different kind of gs stdin implementation | 10:41.52 |
| | gsdll_stdin(void *instance, char *buf, int len) | 10:42.22 |
| | if i got it right, len parameter returns size of allocated bytes for the *buff | 10:42.57 |
| | right? | 10:42.59 |
| | returns = give | 10:43.25 |
| kens | lenis the length of the buffer, including the trailing 0 | 10:43.31 |
| jhabjan | so, for instance, if len = 1, then buf can accept only 1 byte ? | 10:44.35 |
| kens | No 0 bytes, because its a C string (I htink) and therefore the last byte must be 0 | 10:45.00 |
| jhabjan | hm.. | 10:45.24 |
| | if i have: (%lineedit)(r)file | 10:46.00 |
| | len always say's 1 | 10:46.20 |
| kens | Its not at all clear to me what you mean, or expect | 10:46.48 |
| | The first part of that is PostScript and establishes a file | 10:47.02 |
| jhabjan | i have postscript that prompts for some input | 10:47.20 |
| kens | Hmm, that's highly device-dependent, usually, it won'r work | 10:47.44 |
| jhabjan | when (%lineedit)(r)file is executed by the ghostscript, in C# i got the stdin callback | 10:47.53 |
| kens | Yes, the stdin callback is asking for stdin input. | 10:48.18 |
| jhabjan | the device is "display" | 10:48.20 |
| | yes, it's asking for stdin input, but len value is always 1 | 10:49.22 |
| kens | So it wants one byte, what's the problem ? | 10:49.45 |
| | By the way, this isn't the Ghostscript API, its just the interface to the Windows DLL. | 10:50.35 |
| jhabjan | si if i want to execute 'pstack' through stdin, i need to return byte per byte and \n at the end to execute it | 10:50.54 |
| | so in case of "pstack" i will need to pass that in 7 callback calls | 10:51.23 |
| | is that correct? | 10:51.26 |
| kens | Yes, and again, what's the problem ? THe interpreter asks for a byte, you should give it 1, unless I'm seriously mistaken about the callback, which is possible | 10:51.33 |
| jhabjan | there is no problem | 10:51.45 |
| | i just want to be sure that i'm hadnling stdin callback properly | 10:52.01 |
| | as i saw different kind of implementation of the stdio | 10:52.14 |
| kens | well, there's more than one way to solve a problem | 10:52.52 |
| jhabjan | for instance: | 10:52.55 |
| | / Adjust fir the case where the data provided is less than that requested | 10:52.56 |
| | if ((size_t)len > gs->m_stdinbuf.Length()) | 10:52.56 |
| | len = gs->m_stdinbuf.Length(); | 10:52.56 |
| | which confused me.... | 10:53.12 |
| | why someone is trying to set the len | 10:53.23 |
| | etc.. | 10:53.26 |
| kens | I don't know where yo ugot that fomr | 10:53.26 |
| jhabjan | IdePS | 10:53.42 |
| | source code | 10:53.45 |
| kens | if you return fewer bytes than requested, you need to tell the interpreter that you only provided 'nm' bytes | 10:53.48 |
| jhabjan | i got that | 10:54.04 |
| kens | SO if the itnerp[reter requested 256 bytes, and you only have 255 you need to set *len to 255 | 10:54.14 |
| | As to what some C++ application is doing, I can't really say in isolation like that | 10:54.44 |
| jhabjan | by *len you mean return value ( not the parameter ) | 10:55.57 |
| kens | Yes looks like it | 10:56.23 |
| jhabjan | ? | 10:56.23 |
| | as len is not defined as out (ref) parameter | 10:56.34 |
| kens | I htought it might pass a pointer to len but it doersn't seem to | 10:56.40 |
| jhabjan | just found this in gsview: | 10:58.35 |
| | static int __stdcall gsdll_stdin(void *instance, char *buf, int len) | 10:58.54 |
| | { | 10:58.54 |
| | int ch; | 10:58.54 |
| | int count = 0; | 10:58.54 |
| | while (count < len) { | 10:58.54 |
| | ch = fgetc(stdin); | 10:58.54 |
| | if (ch == EOF) | 10:58.54 |
| | return 0; | 10:58.55 |
| | *buf++ = ch; | 10:58.55 |
| | count++; | 10:58.56 |
| | if (ch == '\n') | 10:58.56 |
| | break; | 10:58.57 |
| | which enplanes me everything | 10:59.12 |
| | kens: thanks | 11:00.58 |
| kens | NP | 11:01.03 |
| Robin_Watts | So, despite me specifically telling Len that if I didn't get new timings by the end of yesterday I wouldn't be able to achieve much today, and him assuring me that he'd get them to me... nothing. | 11:24.38 |
| kens | This seems to be pretty par for the course | 11:24.55 |
| Robin_Watts | oh, I lie. It's arrived, sorry. | 11:24.57 |
| kens | lol | 11:25.04 |
| | He did say your changes made gains on each page, but it wasn't obvious (to me) how much | 11:25.33 |
| Robin_Watts | Indeed. but it seems that the improvements are 'enough' now. | 11:26.31 |
| kens | iS THAT WITHOUT rAY'S GRAY jpeg STUFF ? | 11:26.51 |
| | Hmm I thought I fixed that caps lock... | 11:27.05 |
| Robin_Watts | Hard to say. Supposedly he spoke to Ray yesterday - either I didn't get that email, or it was done by phone. | 11:27.23 |
| | So we now need to look at performance on this new product, about which we know... nothing. | 11:27.49 |
| kens | :-( | 11:28.05 |
| Robin_Watts | And the times he's sent me, as a .csv file, are actually a .zip file. | 11:31.39 |
| kens | well that explains why I couldn't open it | 11:32.02 |
| Robin_Watts | Won't open as an xps file, despite there being a _rels and a docProps and an xl dir. | 11:32.22 |
| kens | so, basically, broken then ? | 11:32.38 |
| Robin_Watts | Hmm. OpenOffice document. | 11:32.54 |
| kens | My OpenOffice wouldn't read it as a .csv | 11:33.11 |
| Robin_Watts | no, it's a docx. Opened it now. | 11:33.25 |
| kens | Yes, it opens for me when it has the right extension... | 11:33.51 |
| | But is meaningless to me :-) | 11:34.42 |
| Robin_Watts | OK, so total time is down to 20.6 seconds from the 25.x it was before. | 11:34.48 |
| | which is pretty much the 20% they wanted. | 11:34.56 |
| kens | Impressive, good job you two did | 11:35.01 |
| Robin_Watts | I can only assume that ray sent his stuff along, cos I wasn't expecting my stuff to make that much of a difference. | 11:35.36 |
| kens | I guess so, pity nobody told you | 11:35.54 |
| | Anyway, lunch time | 11:36.14 |
| Zaister | Hello, anyone here involved in mupdf? | 12:39.21 |
| Robin_Watts | Zaister: Yup. | 12:39.32 |
| Zaister | Robin_Watts: ah | 12:39.39 |
| | i found an error in one of your recent commits | 12:39.50 |
| Robin_Watts | Which one? | 12:40.02 |
| Zaister | in include/mupdf/pdf/document.h | 12:40.04 |
| | for the stucture pdf_obj_read_state_s | 12:40.17 |
| | the syntax is off there with the name of the stuct at the end | 12:40.38 |
| | the commit in question is f5f7c0e4dd83257f526b158e3998970717852a0e | 12:40.58 |
| Robin_Watts | so it is. | 12:41.13 |
| Zaister | mupdf build even with this error, but I'm working on a mupdf generator for Okular, and the linker complains about it | 12:41.42 |
| Robin_Watts | oh ass, and that was one of mine :) | 12:41.46 |
| Zaister | various "multiple definition of `pdf_obj_read_state_s'" messages there | 12:42.15 |
| | yep :) | 12:42.21 |
| Robin_Watts | OK, fix is on my repo. I'll get that pushed to golden as soon as tor7 can look it over. | 12:45.14 |
| | tor7: ping | 12:45.17 |
| | Thanks for the report. | 12:45.25 |
| Zaister | thanks too | 12:45.53 |
| Robin_Watts | You are doing a mupdf generator for Okular? | 12:46.00 |
| tor7 | Robin_Watts: LGTM. | 12:46.13 |
| Robin_Watts | You mean a MuPDF backend for Okular ? | 12:46.18 |
| | Mupdf reads content and feeds it into Okular? | 12:46.26 |
| | tor7: Thanks. | 12:46.37 |
| | Zaister: Fixed on golden then. | 12:46.44 |
| Zaister | thank | 12:46.57 |
| | and yes, I'm using mupdf inside okular | 12:47.07 |
| | that was originally started by Pino Toscano but is unmaintained and I've adapted it to work with current mupdf sources, but it is still unfinished | 12:48.07 |
| | I can't print from it yet, or do a decent text export | 12:48.26 |
| Robin_Watts | Zaister: Cool. Let us know how you get on. | 12:48.39 |
| Zaister | sure | 12:48.43 |
| | I got to that because poppler is excruciatingly slow with a bunch of PDFs I use a lot, and mupdf is FAST | 12:49.29 |
| Robin_Watts | lunches. bbs. | 12:49.54 |
| Zaister | sure | 12:50.07 |
| Vignesh | Hi buddies, I am using MuPDF in my android application. Whenever i have opened pdf file via my Application. Android app will crashed with following errors and Exception. | 13:13.31 |
| | java.lang.NullPointerException at com.artifex.mupdfdemo.MuPDFActivity.onPause in MuPDFActivity.java on Line 726 at android.app.Activity.performPause in Activity.java on Line 5106 at android.app.Instrumentation.callActivityOnPause in Instrumentation.java on Line 1225 at android.app.ActivityThread.performPauseActivity in ActivityThread.java on Line 2825 at android.app.ActivityThread.performPauseActivity in ActivityThread.java on | 13:13.32 |
| Robin_Watts | Vignesh: Hmm. | 13:30.54 |
| | I'd put some printlns in there and watch to see where exactly in onPause it's crashing. | 13:31.20 |
| | possibly we need an if (edit != null) around the last 2 lines ? | 13:32.00 |
| | I don't understand that last bit - you need paulgardiner, who won't be back until next week. | 13:32.26 |
| Vignesh | OOh ok thanks for your reply robin. | 13:41.22 |
| | The crash is occur in the MuPDFActivity.java file. | 13:42.49 |
| | I am sending local url path like this Robin. To this method openFile() in MuPDFActivity.java Robin. | 13:47.06 |
| Robin_Watts | Vignesh: I suggested what you should try above. | 13:47.27 |
| | If you're getting a crash in the onPause method of MuPDFActivity, then put some println's in there to see where it's actually crashing and why. | 13:48.12 |
| | The only thing I can see is that 'edit' might be coming back as null, and so calling edit.whatever would give a null pointer exception. | 13:48.46 |
| Vignesh | ok sure. I will put try and Catch blocks in that method as well as println() also. | 13:49.30 |
| Robin_Watts | Solving the problem with try/catch is wrong. | 13:50.00 |
| | You should avoid the exception being thrown rather than trying to cope with it, I think. | 13:50.16 |
| | but if that helps you track it down, sure. | 13:50.24 |
| Vignesh | now i got FATAl error | 14:21.19 |
| | see my log Robin | 14:21.24 |
| | 09-27 19:44:16.129: D/ACRA(1911): Wait for Toast + worker ended. Kill Application ? true 09-27 19:44:16.129: E/AndroidRuntime(1911): FATAL EXCEPTION: main 09-27 19:44:16.129: E/AndroidRuntime(1911): java.lang.ExceptionInInitializerError 09-27 19:44:16.129: E/AndroidRuntime(1911): at com.artifex.mupdfdemo.MuPDFActivity.openFile(MuPDFActivity.java:239) 09-27 19:44:16.129: E/AndroidRuntime(1911): at com.artifex.mupdfdemo.MuPDFAc | 14:21.25 |
| | I have put println() in Onpause() but now i got error in On open file da.. | 14:22.17 |
| Robin_Watts | Vignesh: So you used to be getting an error in onPause, and now you've changed the code, and you're now getting an error in openFile ? | 14:22.30 |
| Vignesh | No Robin, i didn't change anything in code. | 14:23.30 |
| Robin_Watts | You put println's in, right? That's changing the code. | 14:23.49 |
| Vignesh | Just put if(edit !=null) and println statement only robin | 14:24.11 |
| Robin_Watts | ok. | 14:24.25 |
| Vignesh | Yeah it's right robin. | 14:24.45 |
| Robin_Watts | It's possible that the if (edit != null) has solved the problem that you were seeing in onPause, and now you're getting further, and it's falling over in openFile. | 14:25.23 |
| Vignesh | This is my line : System.out.println("Edit : "+edit.toString()); | 14:25.52 |
| Robin_Watts | Is that inside the if (edit != null) test ? | 14:26.18 |
| | If it was me, I'd want to confirm what was going on - I'd take the println's out, but leave the if (edit != null) and see if it still went wrong in openFile. Then I'd temporarily take the if (edit != null) out to see if the problem goes back to onPause. | 14:27.20 |
| Vignesh | I have added that code top of the If Statement. | 14:28.42 |
| Robin_Watts | Vignesh: Inside the if statement, or before the if statement ? | 14:29.04 |
| | if (edit != null) { println(...); ... } or println(...); if (edit != null) { ... } | 14:29.40 |
| Vignesh | println(...); if (edit != null) { ... } | 14:31.23 |
| Robin_Watts | So if edit is null, you'd be doing null.toString(); | 14:43.27 |
| | which would, I think, throw an exception. | 14:43.44 |
| | tor7: ping | 15:18.59 |
| tor7 | Robin_Watts: hey. | 15:20.05 |
| Robin_Watts | So I'm looking into mupdf hanging on a fuzzed file. | 15:20.23 |
| | and I've figured out why, and I'm trying to think how best to solve it. | 15:20.34 |
| | In fz_dash_lineto | 15:20.44 |
| | we've got a line from x=-300000000 or thereabouts to x=500. | 15:21.15 |
| tor7 | ohhhh... that's not going to be fun. | 15:21.31 |
| Robin_Watts | with a dash pattern of [1.9,1.9] | 15:21.35 |
| | so we're fine until we're going around the loop and used hits 1<<25 or so. | 15:21.59 |
| tor7 | we can't clip usefully before stroking, either | 15:22.17 |
| Robin_Watts | at this point used += 1.9 doesn't change the value of used, and the loop becomes an infinite one :) | 15:22.23 |
| | Well, we COULD put some code at the start of this function to spot a and b being outside the gel's clip box. | 15:23.30 |
| | and if they are, 'skip over' the bit of stroking that's outside the box. | 15:23.53 |
| tor7 | Robin_Watts: yeah, but we'd need a fuzz of the linewidth at least | 15:24.31 |
| Robin_Watts | But we have potential problems there due to the fact that dashcaps etc might show up. | 15:24.47 |
| | yeah, as you say. | 15:24.50 |
| tor7 | I think doing a clip of the straight line segments that are being stroked might work | 15:24.59 |
| Robin_Watts | Is a fuzz of the linewidth enough do you think? | 15:25.11 |
| | Do we do triangle caps? | 15:25.35 |
| tor7 | expand the scissor rect by linewidth should work, I believe | 15:25.36 |
| Robin_Watts | Those are twice the linewidth, right ? | 15:25.43 |
| tor7 | yes, for XPS we do | 15:25.45 |
| Robin_Watts | I forget if we hold linewidth = the actual width of the stroke, or linewidth = the amount the stroke extends to either side of the central line. | 15:26.43 |
| | I'll fuzz it by linewidth*2 :) | 15:27.07 |
| tor7 | Robin_Watts: I've looked over Zeniko's dozen or so patches on zeniko/master and found nothing terribly wrong with them. if you've given them an eye, I think we could take them on as is. | 15:28.16 |
| Robin_Watts | I haven't looked. I'd forgotten about them entirely with Lens stuff. Let me look quickly now. | 15:28.40 |
| | Would anyone else find it useful to have a 'gs' and 'mupdf' link on the dashboard next to each user to open the webgit view on their gs/mupdf repos ? | 15:29.55 |
| | tor7: I dislike the second part of http://git.ghostscript.com/?p=user/zeniko/mupdf.git;a=commitdiff;h=bb443af39d8bf4b53c01fc98e8105da22f010fd9 | 15:33.38 |
| | And how does: http://git.ghostscript.com/?p=user/zeniko/mupdf.git;a=commitdiff;h=be1f95b69a6c9d62e4ff2017d9d5c9c3a2782274 help us? | 15:35.46 |
| | All that change can stop is a warning, right? | 15:36.21 |
| tor7 | Robin_Watts: it does TRYLATER throw and *then* a warning | 15:36.39 |
| Robin_Watts | right, so if it runs out of data because we haven't got data yet, it'll throw. That's right, I think. | 15:37.22 |
| tor7 | the EOF marker one is the only one I have some doubts about | 15:37.25 |
| Robin_Watts | So you're good with the second half of the first one I flagged up? It was coded that way to allow us to pass fz_opts = NULL to mean 'default options'. | 15:38.19 |
| tor7 | but I suspect reading past the end will consume *more* data than desired in the bugs he references | 15:38.50 |
| Robin_Watts | tor7: Ah. | 15:39.13 |
| tor7 | in case the data terminator (like in ASCIIHex) is missing | 15:39.16 |
| Robin_Watts | I will look again with that in mind when I get to the end :) | 15:39.38 |
| tor7 | Robin_Watts: I figured the options passing is all up to you to decide on | 15:40.04 |
| | I do prefer being able to pass NULL though | 15:40.47 |
| | so drop the second hunk of bb443af | 15:41.03 |
| | Robin_Watts: I think I've figured out how to do stencil masking with both clip masks and winding-counting | 15:41.57 |
| | now I just have to debug my attempt to do it... :( | 15:42.06 |
| Robin_Watts | cool. How ? | 15:42.08 |
| tor7 | by using 4 bits in the stencil mask as a clip-depth counter rather than using bit planes | 15:42.30 |
| | and then a glCoverPath step with color writing disabled, to coalesce the NV_path_rendering bit planes down into the counter | 15:43.00 |
| | so there's 4 bits (16 clip depths allowed) for the clip mask, and 4 bits (16 windings allowed) for the nvidia path rendering machinery | 15:43.37 |
| Robin_Watts | So in the clipdepth bits, n would mean "this pixel is unclipped at depths 0 to n-1" ? | 15:44.27 |
| tor7 | yup | 15:44.42 |
| Robin_Watts | clever. | 15:44.47 |
| | I like that a lot, I think. | 15:45.15 |
| tor7 | so then to add a clip, I'll just bump the stencil value by 1 if the pixel is currently visible | 15:45.31 |
| Robin_Watts | especially if you can store 'n' in the clipstack, so it's not 16 nested clips, but 16 nested non-rectangular clips. | 15:45.43 |
| tor7 | and popping the clip, I draw (with color writing off) a fullscreen quad, with stencil set up to set stencil=n-1 if stencil == n | 15:46.13 |
| Robin_Watts | tor7: Presumably it has to be "set the stencil value to n+1 if the pixel is currently >= n" | 15:46.21 |
| tor7 | yeah, rectilinear clips will just set the scissor test and not affect the stencil buffer | 15:46.43 |
| Robin_Watts | I think if you use my rule, popping the clips don't have to do anything. | 15:46.52 |
| tor7 | Robin_Watts: you need to clear the values to add new clip masks at the same depth (since writing a new stencil value only touches the pixels that pass the stencil test) | 15:47.40 |
| Robin_Watts | We never add a new clipmask at the same depth. | 15:48.05 |
| tor7 | otherwise I'd have to write a new stencil value for *all* pixels when pushing a new clip mask | 15:48.06 |
| | pushclip, draw stuff, pop clip, push new clip, draw more stuff, pop clip | 15:48.21 |
| | draw stuff and draw more stuff happen at the same clip depth, but with different masks | 15:48.39 |
| Robin_Watts | Right. | 15:48.49 |
| | Either you have to do a full screen operation on the push, or on the pop. | 15:49.01 |
| tor7 | yeah, pretty much | 15:49.08 |
| Robin_Watts | With my scheme I think you can do a full screen operation on the push, and nothing on the pop. | 15:49.17 |
| tor7 | which is what I was trying to avoid, but it comes out much saner this way | 15:49.20 |
| | and with the scissoring in effect, it shouldn't be prohibitively expensive | 15:49.32 |
| Robin_Watts | and given we have to do an operation on the push no matter what, it might as well be a full screen one. | 15:49.39 |
| tor7 | Robin_Watts: yeah. there's a few approaches I'm going to try, once I can get the magic state machine voodoo working... | 15:50.12 |
| | it's clipping, but not the right stuff :( | 15:50.37 |
| Robin_Watts | OK. Let me know if you want me to try to come up with a simple example ( a 3 pixel screen should be enough :) ) | 15:50.38 |
| | Morning ray_laptop. | 15:50.52 |
| | So, you've spoken to Len? Was that by phone, or was there an email I missed? | 15:51.10 |
| tor7 | Robin_Watts: yeah. if you've got any simple test files with lots of nested non-rectilinear clips lying around, toss 'em my way | 15:51.23 |
| | anyway, need to head out for dinners | 15:51.34 |
| Robin_Watts | tor7: I was going to do a text walkthrough of my idea. | 15:51.54 |
| | multiple dinners! Excellent. | 15:52.05 |
| tor7 | Robin_Watts: right. do it by email :) | 15:52.08 |
| | I'm a hobbit! Multiple breakfasts too! | 15:52.32 |
| Robin_Watts | *You* are NOT a hobbit. | 15:52.45 |
| | Unless there are two of them stood on each others shoulders. | 15:52.54 |
| tor7 | 1) My feet aren't hairy enough ;) | 15:52.58 |
| ray_laptop | Robin_Watts: Len called me fairly late last night. He mentioned that they had met the performance goals, and they had another problem to hand me | 15:52.59 |
| tor7 | 2) What you said... | 15:53.05 |
| Robin_Watts | ray_laptop: So do they have your jpeg stuff? | 15:53.21 |
| ray_laptop | Robin_Watts: no, I hadn't gotten it to them yet. I had just finished looking at (most of) the bmpcmp's | 15:53.57 |
| Robin_Watts | Looking at the new timings they sent (it's a .docx, not a .csv by the way) it looks like the big saving was on page 1 where they have saved 3 seconds in the transfer of the file, I think. | 15:54.07 |
| | So well done for spotting that! | 15:54.12 |
| | They've kept quiet about the exact reason, so I suspect it was something quite simple and a bit embarassing :) | 15:54.32 |
| ray_laptop | Robin_Watts: yes, I'm glad that they dealt with that | 15:54.48 |
| Robin_Watts | ray_laptop: So the pressure is off until they drop the details of the new product on us. | 15:55.09 |
| mvrhel_laptop | good morning | 15:55.13 |
| Robin_Watts | Morning mvrhel_laptop | 15:55.22 |
| ray_laptop | Robin_Watts: probably something like a debug mode that writes the data out a serial port or something | 15:55.24 |
| | gonna have to reboot. My laptop is r...e...a...l...l...y slow and my AV is wanting me to. :-( | 15:59.09 |
| kens | Goodnight folks | 15:59.09 |
| ray_laptop | nite, kens | 15:59.15 |
| Robin_Watts | Night kens | 15:59.16 |
| | ray_laptop: They say the new one is like the 6th gen. That was a 600dpi mono printer was it? Or was it color ? | 15:59.41 |
| | Morning henrys. | 16:07.41 |
| | Is your house move imminent? | 16:07.59 |
| henrys | Robin_Watts: we are getting close, but I've learned buying an old house is not something to be sure about ... | 16:09.08 |
| Robin_Watts | oh, so the sale is definite yet ? | 16:09.26 |
| | s/is/isn't/ | 16:09.31 |
| henrys | waiting now on an appraisal | 16:10.23 |
| | Robin_Watts: FWIW, when amongst cows I like to keep my dogs next to, not under, the cows. | 16:32.31 |
| Robin_Watts | henrys: The dog was well away from the cows. Sadly not well away from where the cows had been :) | 16:33.09 |
| | If I'd been there, we wouldn't have been in that field at all. | 16:33.30 |
| mvrhel_laptop | hmm ran across an odd thing that I had done, which is a source of problems. Anytime I have had a color space mismatch between adjacent transparency groups, I always was forcing them to be isolated. | 17:08.10 |
| | Instead, I need to go ahead and do a color conversion on the background buffer | 17:08.39 |
| | or backdrop as they call it | 17:08.50 |
| Robin_Watts | mvrhel_laptop: Fun. | 17:09.19 |
| | Are you still thinking that you can get away without the extra alpha plane ? | 17:09.34 |
| mvrhel_laptop | yes. I was very close to having this working, then stumbled upon that. Robin_Watts I don't know about the extra alpha yet. | 17:09.58 |
| Robin_Watts | well, best of luck with it. | 17:10.16 |
| mvrhel_laptop | yes. hopefully I should have it sorted out by next week | 17:10.37 |
| | kitten refuses to sleep for some reason.... purring very loudly | 17:10.55 |
| | need to head out for bit | 17:12.00 |
| Robin_Watts | mvrhel_laptop: That's a sign that it needs more caffiene. | 17:14.45 |
| zeniko | Robin_Watts: (or for the log) Thanks for review and landing. | 18:56.53 |
| Robin_Watts | zeniko: Ah, hi | 18:57.01 |
| | I changed 1 commit, and didn't push 2. | 18:57.15 |
| | In the 'preserve /Encrypt' one, I removed some lines. | 18:58.03 |
| zeniko | The one you changed: passing NULL for fz_opts currently doesn't work - you dereference it e.g. for do_incremental without NULL check. | 18:58.21 |
| Robin_Watts | OK, so I should fix that :) | 18:58.33 |
| zeniko | Similarly, later on for continue_on_error and errors. | 18:58.53 |
| Robin_Watts | ok. | 18:58.58 |
| zeniko | It might be clearer to do a single NULL-check at the start of the function, | 18:59.35 |
| Robin_Watts | I still have the "tolerate inline images" one and the "tweak pdf_parse_file_spec" one. | 18:59.41 |
| zeniko | and in that case just use a local copy of the structure with the default values instead. | 18:59.51 |
| Robin_Watts | zeniko: yes, that might be clearer. I will think on it. | 19:00.16 |
| | I need to think about the images one a bit. | 19:00.34 |
| | presumably there is a reason why we read the EOF marker. | 19:00.46 |
| | just removing the code feels wrong to me. | 19:00.54 |
| zeniko | The question is then, could you unread whatever you've read in case there's no EOF marker at all? | 19:01.17 |
| Robin_Watts | zeniko: Yes, I think maybe we should be using fz_read_byte there, possibly in a loop. | 19:01.51 |
| | but AIUI, the existing code copes with their being extra crap information at the end of an inline image, but gets confused if the EOF marker isn't there and overreads. | 19:02.54 |
| | Your code copes if the EOF marker isn't there, but doesn't cope if there is extra crap information at the end of the inline image. | 19:03.24 |
| zeniko | So far, I've only see progressions when removing that code (in your as well as my test suite). | 19:03.38 |
| Robin_Watts | So, ideally we'd like to find a way that works with both. | 19:03.39 |
| | Well, that's a good argument :) | 19:03.53 |
| | but I'd like to think on it for a bit. | 19:04.07 |
| zeniko | Additional garbage should else be ignored/skipped by the interpreter, shouldn't it? | 19:04.08 |
| Robin_Watts | it may cause the interpreter to bale out, I think. | 19:04.29 |
| | The pdf_parse_file_spec one... I think that maybe there might be a slight revision of yours that would be better. | 19:05.16 |
| zeniko | IIRC, the interpreter throws away garbage bytes until finding 'EI' | 19:05.16 |
| Robin_Watts | zeniko: Ah, if that's the case, then I'm a lot happier. | 19:05.33 |
| zeniko | (that's in pdf_run_BI in pdf-interpret.c) | 19:05.53 |
| Robin_Watts | I think I'd rather the pdf_parse_file_spec thing checked first for DOS on windows, and if it didn't find it, looked for Unix then Mac. | 19:06.20 |
| | On Unix it should look for Unix, then DOS, then Mac. | 19:06.34 |
| | On Mac it should look for Mac then Unix then DOS or something like that. | 19:06.47 |
| zeniko | The point is that the Unix and Mac paths are likely to mean nothing under Windows and vice versa (else they wouldn't be OS specific to start with). | 19:07.03 |
| Robin_Watts | Right, but some people may call this as an informational thing. | 19:07.23 |
| zeniko | (Also, IIRC Mac means paths for OS9 and older.) | 19:07.28 |
| Robin_Watts | and maybe the paths they get back will just be filenames. Or will at least have an informative filename in. | 19:07.45 |
| | so I'd like to return the information if it's there and let the caller cope with the fact that the filename may not really be valid (which it ought to be doing anyway). | 19:08.13 |
| zeniko | The problem is that /UF might be a valid fallback path which will be more useful than /Mac under any recent oS. | 19:09.02 |
| Robin_Watts | ok, so we use Mac as the last resort. | 19:09.40 |
| | Possibly we should change the API for pdf_parse_file_spec to be better. | 19:11.07 |
| zeniko | The spec reads: "Consumer applications running on a particular platform should use the appropriate platform-specific entry (DOS, Mac, or Unix) if available." | 19:11.34 |
| Robin_Watts | Like we could pass a preferred entry type in, and say whether we'd like a URL or a file. | 19:11.43 |
| | Basically you've exposed an internal function into the API without us really being sure if the function is the right shape. | 19:12.21 |
| | Again, I need to think on it a bit. | 19:12.29 |
| zeniko | URL or not is another distinction, the FileSpec is either a path or a URL (the latter, if /FS has the name /URL). | 19:14.09 |
| Robin_Watts | zeniko: right. | 19:14.23 |
| zeniko | For the path, there would have to be a way to specify whether the best fit for a given platform is needed or ...(?) | 19:14.37 |
| Robin_Watts | Yeah, I'm thinking we'd take an enum { FZ_FILESPEC_DOS, FZ_FILESPEC_UNIX, FZ_FILESPEC_MAC, FZ_FILESPEC_ANY } or something | 19:15.22 |
| | which would set the preference for what was retrieved. | 19:15.31 |
| | and we'd take a bool for URL or not. | 19:15.44 |
| zeniko | The question is then, which of these the link loading code would use? | 19:16.04 |
| Robin_Watts | If we ask for a URL and we only have a file, we can turn it into a file://URL ? | 19:16.06 |
| | zeniko: We could have an entry in the context where the caller can set his preference ? | 19:16.43 |
| | So the caller would set that at startup, then when he loads the links he'd get what he wanted. | 19:17.19 |
| | How does that sound? (I'm making this up as I go) | 19:17.34 |
| zeniko | I'd rather try to do the Right(tm) thing without further fiddling requirements | 19:18.15 |
| | (which is what the spec suggests) | 19:18.22 |
| Robin_Watts | zeniko: I think (as usual) the spec is impossible to follow in a sane way. | 19:18.41 |
| zeniko | and leave the inspection use case to the basic pdf_dict_gets... dance | 19:18.47 |
| | I'd say, 3.10.2 (in the PDF 1.6 reference) is quite clearly formulated for a change. | 19:19.42 |
| Robin_Watts | Either we have an API to allow us to just return exactly what is in the file, and let the caller sort it out, or we have to encapsulate the querying in a powerful enough way to let the user drive it. | 19:19.46 |
| | Possibly fz_link should have all the entries in it, along with an is_url field, and the caller can do what they want. | 19:20.54 |
| zeniko | Doesn't that complicate code both in MuPDF and for the caller? | 19:21.46 |
| Robin_Watts | The alternative is to offer an API that the caller *can't* drive to see exactly what the information is. | 19:22.32 |
| | I dislike having to part cook information before passing it back to the caller. | 19:23.01 |
| | Either it should be unabiguously cooked, or left raw. Half cooking only leads to stomach aches (to abuse the metaphor) | 19:23.43 |
| zeniko | I'd argue that my implementation proposal does all the cooking required. | 19:24.04 |
| Robin_Watts | zeniko: With your code, I *cannot* get to the raw versions. | 19:24.44 |
| | and I have no way of knowing which one it came from. | 19:24.53 |
| | and no way of knowing if it was a URL or not. | 19:25.04 |
| zeniko | Robin_Watts: Sorry, had to run mid-sentence. | 19:58.56 |
| Robin_Watts | no worries. I've got to go in a second too. | 19:59.09 |
| zeniko | So for the logs then: | 19:59.36 |
| | The pdf_parse_file_spec patch fixes a function which currently doesn't work as expected in most cases (in particular for viewer applications for which links are extracted) | 20:00.23 |
| | and it exposes that same function as a curtesy for however else might need it as a helper the way it is. | 20:00.41 |
| | To get further details (in particular which path was used and whether's it's a URL), a caller has to inspect the FileSpec pdf_obj itself. | 20:01.42 |
| | For the pdf_parse_action case, the URL check is exposed through ld.launch.is_uri (and should probably be exposed the same way for the GoToR case through ld.gotor.is_uri) | 20:03.28 |
| | and having a single, platform specific file_spec makes things easier for the viewer application. | 20:04.00 |
| | Anyway, no hurry on getting this or a different patch in, we've got things patched the way we need for SumatraPDF to behave as we and our users expect it. | 20:05.36 |
| | Robin_Watts: Good night! | 20:05.48 |
| ray_laptop | Robin_Watts: I sent my JPEG -> Gray optimization changes over to Len. They should be straightforward enough, but if you spot something, let me know. | 20:38.37 |
| | Robin_Watts: and I'd like input on making this an option for the HEAD code (since that's already done). | 20:39.11 |
| mvrhel_laptop | bbiaw | 21:02.15 |
| Robin_Watts | ray_laptop: For the logs. I think you should check it in on master, but hide it behind a command line flag. -dFASTGREYJPEGS or something ? | 23:24.37 |
| | Forward 1 day (to 2013/09/28)>>> | |
IRC Logs