| | <<<Back 1 day (to 2012/06/14) | 2012/06/15 |
| kens | Hi tor8 | 07:58.54 |
| tor8 | morning kens | 08:00.09 |
| kens | Can yo uhave a quick look at bubg #693124 and see if I'm talking rubbish ? | 08:00.34 |
| | I used Phil's 'combined.pdf' file as a test and it was indeed sent to support | 08:00.59 |
| tor8 | kens: no, you're right. we don't look at UserUnit in mupdf. | 08:07.11 |
| kens | AH, OK then I'll leave it with you :-) | 08:07.23 |
| | Its a dreadful Adobe kludge anyway | 08:07.55 |
| tor8 | indeed, wonder why they felt the need to add it? | 08:08.51 |
| | to save some math when converting from a 96 dpi format perhaps? | 08:09.06 |
| kens | Because Acrobat (NOT PDF) has a limit on page sizes | 08:09.08 |
| | Can't handler dimensions > 14,400 | 08:09.19 |
| tor8 | oh. that's ... crud. | 08:09.22 |
| kens | Yep | 08:09.25 |
| | So at 72 dpi (nominal user space) it has a page size limit of 200 inches | 08:09.50 |
| tor8 | kens: do you have a sample file somewhere? | 08:10.04 |
| kens | Up to version 4 it had a limit of 45 inches | 08:10.13 |
| | tor8 Phil sent a (large) file to support | 08:10.27 |
| | Its called combined.pdf | 08:10.33 |
| | Subject was 'GS 9.05: PDF using pdf_info.ps to gather page sizes' | 08:11.07 |
| tor8 | right, got it | 08:11.18 |
| kens | Page 1 shows the problem for me quite easily | 08:11.32 |
| | That was impressively quick tor8 | 08:49.06 |
| tor8 | kens: some fixes are easier than others :) | 08:52.52 |
| Robin_Watts | Morning all | 08:53.23 |
| | paulgardiner: ping | 08:53.31 |
| kens | Hi Robin_Watts | 08:53.37 |
| paulgardiner | Robin_Watts: hi | 08:53.45 |
| | Robin_Watts: Any more info on that bug? | 08:54.00 |
| | Robin_Watts: Also, what's the url for repos on casper other than my own? | 08:54.24 |
| Robin_Watts | I pushed some stuff onto the golden forms branch yesterday. | 08:54.27 |
| paulgardiner | Robin_Watts: read access obvously | 08:54.32 |
| Robin_Watts | golden robin@ghostscript.com:/home/git/mupdf.git | 08:54.57 |
| | origin robin@ghostscript.com:/home/git/user/robin/mupdf.git | 08:55.31 |
| paulgardiner | Oh. Silly me. Of course I get read access to your repo just by my usual log in | 08:56.24 |
| Robin_Watts | and I just pushed 3 more patches now. | 08:56.52 |
| | I fixed the first bug I found, but there is another one. | 08:57.10 |
| | tests_private\pdf\forms\v1.3\09+20anim+20fx-fo-dx-adr-mx.pdf | 08:57.41 |
| paulgardiner | Robin_Watts: so was thet failure to terminate just because of the initialisation of max_lines? | 08:57.45 |
| Robin_Watts | Yes. | 08:57.52 |
| | Open that, go to page 7, click on the big field in the middle and enter some text. | 08:58.10 |
| | Note how the text does not appear. | 08:58.16 |
| paulgardiner | Robin_Watts: Ah. I never tested multiline forms other than ones that specified variable font size. | 08:58.20 |
| | Robin_Watts: this great to have these tests already. | 08:58.49 |
| Robin_Watts | but when you click on the field again, the text is obviously making it as far as being the value. | 08:58.55 |
| paulgardiner | How did you find that with automated tests. Was it just that the earlier bug pointed you at that file? | 09:00.13 |
| kens | He he, I see Guillaume is now wrestling with teh fact that HP printers, and PCL, only work at integer multiples of 300 dpi, and he wants to print at 1600 :-) | 09:00.14 |
| kens | decides henrys can deal with that support email | 09:01.04 |
| Robin_Watts | kens: Print at 4800 and downscale by 3 ? | 09:01.16 |
| kens | I bet he won't like the performance | 09:01.38 |
| Robin_Watts | well, if you're just going to complain.... :) | 09:02.12 |
| kens | I'm not complaining, I'm leaving ti to Henry :) | 09:02.23 |
| Robin_Watts | paulgardiner: I ran the test, and looked at the output it produced. | 09:07.39 |
| | There was a field that didn't have writing in. | 09:08.01 |
| paulgardiner | The test inserts text into every text field? | 09:08.25 |
| Robin_Watts | The autogenerated test scripts just click onto every field and enter some text, and save out the page image. | 09:09.24 |
| paulgardiner | Ah right. Nice | 09:09.34 |
| | The change in pdf_app.c: fz_pass_event seems to return "whether the page needs redrawing after the event" rather than "whether the event has been handled" | 09:11.22 |
| | So I'm not sure how things are now whether it is safe to stop processing... you may have thought it out in more detail. | 09:12.24 |
| Robin_Watts | Well, we certainly don't want it carrying on to reprocess the click. | 09:13.48 |
| paulgardiner | Oh yeah It can call pdfapp_showpage again. I do see yout point. :-) | 09:15.31 |
| | Probably I should make sure that fz_pass_event does report whether the event was handled. In any case, I imagine Tor is replacing pdf_app.c | 09:17.12 |
| Robin_Watts | Without the return, run the same file as I mentioned earlier, and click and change the first field on the first page. | 09:17.32 |
| | Then note that as you move the mouse pointer over the page the page flips forward and backwards through the file. | 09:18.05 |
| paulgardiner | I wasn't doubting the change was needed - just unsure whether it was the complete fix. | 09:18.46 |
| Robin_Watts | I'd hope that the gtk viewer builds around pdf_app.c | 09:19.00 |
| | (or a more complex version of it) | 09:19.11 |
| paulgardiner | What's pdf_app.c for. Can't really use it for touch-screen based apps. Is it intended as the core for keyboard and mouse based apps? | 09:20.54 |
| Robin_Watts | The existing pdf_app.c is the core for the windows and linux apps. | 09:21.20 |
| tor8 | paulgardiner: Robin_Watts: pdfapp.c is just the common bits between the x11 and win32 viewers. | 09:21.22 |
| Robin_Watts | And now mujstest | 09:21.39 |
| tor8 | it's hardly been designed as a general purpose app, but with enough patches anything is possible ;) | 09:21.54 |
| paulgardiner | Ok. I should make sure fz_pass_event does the sensible thing in any case. | 09:22.48 |
| | I'd imagine we'll eventually have to move link handing into fz_pass_event because javascript might override the behaviour defiend by the list of links | 09:24.41 |
| | Robin_Watts: Did you run the tests over the full set of test files? | 09:25.39 |
| Robin_Watts | Not yet. | 09:25.55 |
| | This was literally the first file I've tried. | 09:26.16 |
| paulgardiner | Oh :-( I thought it was a small set of crashing files. | 09:26.35 |
| Robin_Watts | I haven't even generated the full set yet. svn is still checking stuff in. | 09:26.55 |
| paulgardiner | So 100% failure so far! | 09:27.01 |
| Robin_Watts | Actually, I lie. The v1.2 file passed. | 09:27.15 |
| | But that doesn't actually have any forms in it ;) | 09:27.26 |
| paulgardiner | I'll take what successes I can | 09:31.17 |
| | So we still have files with no fields in? I thought the check I use ensured they did. | 09:32.27 |
| | Or was it a file not from that set? | 09:32.43 |
| Robin_Watts | IT was the only v1.2 file from that set. | 09:35.50 |
| paulgardiner | Robin_Watts: that bug was white text on a white background. I've pushed a fix to my repo | 10:41.28 |
| Robin_Watts | Ah! | 10:41.35 |
| | Pushed to golden. | 11:28.13 |
| paulgardiner | Thanks | 11:29.22 |
| Robin_Watts | np. | 11:29.27 |
| | paulgardiner: In that same file, on page 3, the text entered into the top field is clipped. Is that to be expected? | 11:50.06 |
| | FILM TITLE: 36TestText has the top of the numbers/caps cut off. | 11:50.36 |
| paulgardiner | Robin_Watts: tops cut off: probably not expected | 11:52.00 |
| Robin_Watts | I have generated the .mjs files for all the forms files, and am committing them to cvs now. | 11:55.37 |
| | s/cvs/svn/ | 11:55.41 |
| | paulgardiner: on page 6 of that same file, there are 2 tickboxes. We click them, and they both tick. Presumably there is js or something to stop both actually being ticked at the same time? And presumably we don't support that yet ? | 11:58.08 |
| | In fact, there are LOTS of tickboxes on that page. | 11:58.33 |
| paulgardiner | At the moment we handle radio buttons via the checkbox code. Just not got around to that bit yet. | 11:59.40 |
| Robin_Watts | ok. | 12:01.00 |
| | 09+20tv+20anim+20fx-fo-dx-adr-mx.pdf page 5. The text sizes are all wrong for fields 2/3/4/5 | 12:03.26 |
| | tor8, paulgardiner: Perhaps we should have a better system for finding/reporting problems than me just mentioning them on here... | 12:05.07 |
| | Is it worth me opening a bug and then listing problems on there, and then paulgardiner can go through them at his leisure splitting them out into real bugs etc? | 12:05.47 |
| paulgardiner | Hmmm. I Ami looking at the wrong thing? Text sizes look ok to me | 12:06.31 |
| Robin_Watts | This is a different file to before. | 12:07.06 |
| paulgardiner | The radio button thing was in the report so not worth opening a bug for that... unless we maybe want to put the report list into bugs | 12:07.43 |
| | Ah | 12:07.55 |
| Robin_Watts | Actually... Acrobat gets it 'wrong' too. | 12:08.11 |
| | So it's probably a flaw in the file and you're behaving properly. | 12:08.23 |
| paulgardiner | Generally, bug reports would be good. | 12:08.28 |
| Robin_Watts | I don't want to overwhelm you with loads of known problems, or loads of instances of the same thing. | 12:09.16 |
| | paulgardiner: <unknown>:0: Uncaught ReferenceError: app is not defined | 12:14.46 |
| paulgardiner | I think if you don't find yourself taking up too much time preparing the bug reports. It shouldn't overwhelm me checking them. | 12:16.42 |
| Robin_Watts | Ah, ok. app.launchURL(...) and we don't yet provide an app object. | 12:17.38 |
| paulgardiner | Robin_Watts: ah that's a useful one. That's the app object missing from the DOM. I need a general way to react to bits we have yet to implement. | 12:17.44 |
| | Did it crash? | 12:18.01 |
| Robin_Watts | No, just gave a warning. | 12:18.09 |
| paulgardiner | That's good. May mean it then failed to run some script it could have otherwise. That's a useful file to keep a note of. | 12:18.55 |
| Robin_Watts | I'll leave the thing running while I go get lunch. | 12:19.20 |
| paulgardiner | Robin_Watts: great to have this working | 12:19.37 |
| Robin_Watts | In all the v1.3 files, only "app" is missing | 12:53.25 |
| | Just got a crash: tests_private/pdf/forms/v1.4/22043_tcs_drive_mastercard_de.pdf - execute_action is calling pdf_js_setup_event with doc->js == NULL | 13:01.49 |
| | paulgardiner: Dunno if you saw the last 2 lines from me. | 13:07.58 |
| | In all the v1.3 files, only "app" is missing | 13:08.00 |
| | Just got a crash: tests_private/pdf/forms/v1.4/22043_tcs_drive_mastercard_de.pdf - execute_action is calling pdf_js_setup_event with doc->js == NULL | 13:08.01 |
| paulgardiner | Yep. Got it ta. That was my internet deciding to jump from 17Mb to 20Mb | 13:08.59 |
| Robin_Watts | Has woodstock been upgraded then? | 13:10.50 |
| | Theoretical maximum for Hook Norton is 8Mbps/448. | 13:11.22 |
| paulgardiner | Yeah, a while ago, but then BT did some work that slowed it down for a while. | 13:11.26 |
| | 8M isn't bad though. | 13:11.48 |
| Robin_Watts | yes, especially as my line is actually pegged at the maximum, and I really seem to get it. | 13:14.05 |
| | OOh. Some properties here... ResetButton, MeasureButton, MoveButton, TurnButton,ZoomOutButton,ZoomInButton | 13:18.04 |
| | and "color is not defined" | 13:18.19 |
| | ../ghostpcl/tests_private/pdf/forms/v1.4/comnet3d | 13:18.29 |
| | v1.3/14766_zusatzkartenantrag_swiss1.pdf has some checkboxes that don't work. Is that expected? | 13:21.56 |
| paulgardiner | Robin_Watts: All these worth reporting. Some checkboxes not working is expected because some don't have appearance streams and I should be creating them | 13:28.26 |
| Robin_Watts | right. | 13:28.40 |
| paulgardiner | What were those properties? Properties of what? | 13:29.11 |
| Robin_Watts | <unknown>:7: Uncaught TypeError: Cannot read property 'ResetButton' of undefined | 13:29.49 |
| | presumably some js is being executed on a button click, and 'this' is probably supposed to be the button. so the missing properties will be button properties? | 13:30.31 |
| paulgardiner | Exactly | 13:30.49 |
| | Although I'm surprised those are properties and not methods... but perhaps that's just to do with the way it's reported. | 13:31.41 |
| Robin_Watts | paulgardiner: I'm going to try to open 1 bug per "class" of problems. | 13:36.29 |
| | with example files. Some of them will be repeats of what is in the report, but it will give us somewhere to track progress. | 13:36.56 |
| paulgardiner | Sounds good. I can split them up later if it makes sense to | 13:36.57 |
| Robin_Watts | It will assign you the bugs; what's your preferred email address for such things ? | 13:37.21 |
| | s/It/I/ | 13:37.27 |
| paulgardiner | A public area? | 13:43.17 |
| | I guess paul@glidos.net is already in the git repo. | 13:44.11 |
| Robin_Watts | ok. | 13:53.05 |
| | actually, I can't assign bugs to you. | 13:53.59 |
| | I'll just CC you. | 13:54.01 |
| | Oh. Have you got an account on bugzilla? | 13:54.44 |
| | IF not, can you make one please? | 13:55.00 |
| paulgardiner | ok | 13:55.15 |
| | Is an email address used in bugzilla any more likely to get picked up by spanners than one used in the public repo? | 13:58.44 |
| | spammers | 13:58.56 |
| | I'll use paulg.artifex@glidos.net | 14:00.19 |
| | Done | 14:02.11 |
| Robin_Watts | ok. | 14:17.34 |
| paulgardiner | Eek! I've found more information on form submission and I wish I hadn't! | 14:25.25 |
| kens | welcome to PDF .... | 14:26.16 |
| paulgardiner | I'm not sure I want to be welcomed to PDF any more. :-) | 14:30.09 |
| kens | People often say that after a while | 14:32.18 |
| Robin_Watts | kens: yeah, but paulgardiner has already been through the "oh my god" stage for PDF fonts, so he's used to it. | 14:33.57 |
| chrisl | Robin_Watts: anyone who is "used to PDF", doesn't know PDF very well........ | 14:35.39 |
| Robin_Watts | Hmm. So it's like quantum mechanics then? | 14:36.13 |
| chrisl | Exactly what I was thinking :-) | 14:36.24 |
| | These days, if you find out something new about PDF, and your reaction *isn't*: "OMFG, what were they thinking", you should probably go back and check it again....... | 14:38.12 |
| paulgardiner | chrisl: Damn! I'd hoped I'd misunderstood it. | 14:38.50 |
| chrisl | paulgardiner: Life's a b*tch, and so is PDF :-( | 14:39.46 |
| paulgardiner | :-) | 14:39.56 |
| chrisl | thinks: these are also all qualities shared by much of the Ghostscript/GhostPDL build "system"....... | 14:40.32 |
| paulgardiner | Oh! the F's in FDF stand for Forms and Format. That's not the word I had in mind at all! | 14:43.38 |
| Robin_Watts | ooh. tests_private/pdf/forms/v1.3/bcchangeform.pdf | 14:50.20 |
| | Try typing into the top left field of that one :) | 14:50.28 |
| paulgardiner | Oops. Yeah, I know what's causing that, | 14:54.25 |
| Robin_Watts | All the crashes I've hit so far seem to be down to doc->js being NULL in execute_action. Dunno if that means anything to you. | 15:19.50 |
| paulgardiner | Yeah. I think I've fixed it. Problem deflating streams containing javascript, which my error handling, um wasn't | 15:21.03 |
| Robin_Watts | ah, ok. | 15:22.14 |
| | have you pushed that onto your repo on casper? | 15:22.27 |
| paulgardiner | As for whether the streams are truly broken I'm unsure. | 15:22.27 |
| | Not yet. | 15:22.34 |
| | Pushed | 15:25.37 |
| Robin_Watts | Thanks. | 15:28.33 |
| henrys | Robin_Watts:is scaling to non integer multiple resolutions doable in the tiffscaled family say 600 to 400 or 800? I assume you've been following the discussion on support? | 15:30.56 |
| Robin_Watts | henrys: Currently, no. | 15:31.11 |
| | (Sorry. currently it's not doable. Yes I've been following) | 15:31.38 |
| | But... why not pdfwrite at 600dpi then render that ? | 15:31.55 |
| henrys | not doable or not supported now? | 15:32.02 |
| Robin_Watts | That takes care of the pcl resolution dependency, and the pdfwritten thing can be infinitely scaled, right? | 15:32.28 |
| | With the usual provisos about rops. | 15:32.34 |
| henrys | because pcl and pdfwrite are not compatible. | 15:32.41 |
| Robin_Watts | It's not doable without a change to the way we work. | 15:32.59 |
| | Render to 4800 and downscale by 3 :) | 15:33.17 |
| | I could implement a special case scaler, I guess. | 15:33.57 |
| henrys | well let's see what he says to my response. | 15:34.47 |
| Robin_Watts | Render at 600, scale to 400 is 3:2 downscaling. So for each block of 9 pixels, I'd produce 4 out. | 15:35.40 |
| | That's doable (a days work?) | 15:35.50 |
| henrys | well it may be needed, we'll see. | 15:36.52 |
| Robin_Watts | 600 to 800 is doable too, but less integer/inner loop friendly maths; that's 9 pixels in, 16 out. | 15:38.22 |
| henrys | kens:is any other support due? I didn't see anything. | 15:38.29 |
| kens | Nope, support is clean at the moment | 15:38.41 |
| henrys | Robin_Watts:well at least we'll have some option for him. | 15:41.03 |
| Robin_Watts | paulgardiner: That does indeed seem to solve it. | 15:44.41 |
| | paulgardiner: pdfcleaning the file (with decompression) runs without any errors. | 15:51.03 |
| paulgardiner | That's strange. | 15:52.07 |
| henrys | bbiab | 15:52.26 |
| paulgardiner | If you break on throw you can see the failure | 15:52.34 |
| Robin_Watts | yeah. I'll have a prod at it. | 15:52.52 |
| | I think it may be to do with whether we allow our streams to have a gzip header or not. | 16:16.52 |
| | It's a configuration option when building zlib. | 16:16.59 |
| kens | Time to go.... Goodnight folks | 16:37.33 |
| chrisl | Also time for me to head off - 'night all....... | 16:49.56 |
| Robin_Watts | paulgardiner: Ah. It's an encrypted file, and for some reason you're not getting the encyption in there. | 16:56.41 |
| | It might be because of where you are doing pdf_new_js. | 16:56.52 |
| | You ought to do the pdf_new_js after allowing for the file to be repaired... I'll keep fiddling. | 16:57.18 |
| | paulgardiner: Yeah, that solves it. | 17:00.59 |
| | tor8: ping | 18:47.45 |
| tor8 | yes? | 18:48.04 |
| Robin_Watts | At the moment, the decision about whether to use bgr or rgb is made in pdfapp based on _WIN32 | 18:48.22 |
| | Can I replace app->grayscale with app->colorspace ? | 18:48.38 |
| tor8 | correct. | 18:48.46 |
| | do anything you want with pdfapp.c, it's bound for a big refactoring soon | 18:49.00 |
| Robin_Watts | Cool. | 18:49.10 |
| tor8 | so I think we'll have two code bases for desktop viewers for a while | 18:49.23 |
| Robin_Watts | At the moment, pdfapp can turn the cursor into a pointy finger when it's over a link. | 18:49.54 |
| | but it has no way of detecting that it's over a field to turn it into a caret. | 18:50.10 |
| tor8 | right. | 18:50.47 |
| | a native widget would solve that automatically ;) | 18:50.54 |
| Robin_Watts | urm... | 18:51.36 |
| | native as in "native to the OS"? | 18:51.44 |
| | how ? | 18:51.49 |
| tor8 | yeah. a win32 edit control would set the cursor by virtue of being a separate window | 18:52.07 |
| Robin_Watts | Right, but not until you click on it. | 18:52.26 |
| | That's the situation we are in now. | 18:52.30 |
| | We might have fields on the page, but we have no way of knowing. | 18:52.43 |
| | When you click on one, then a window pops up and you can enter stuff. | 18:53.02 |
| tor8 | yeah. so we'll need some hittests against form controls to set the cursor | 18:53.10 |
| Robin_Watts | Either we need a 'is my cursor on a widget' test, or we need a way of enumerating widget rectangles. | 18:53.45 |
| tor8 | pdfapp_onmouse enumerates link rectangles | 18:54.11 |
| Robin_Watts | and coincidentally, I just added such an enumeration thing for the mujstest script generation. | 18:54.23 |
| tor8 | those enumerations could probably be abstracted into a library functions | 18:54.33 |
| Robin_Watts | I may play with that. | 18:55.21 |
| Gigs- | mvrhel: did you do something with planar that would have broken supressing colorants with SeparationOrder? | 19:29.29 |
| | I'm seeing really weird behavior. When I try to suppress Varnish with SeparationOrder it actually causes it to print with a tint transform. | 19:33.46 |
| ray_work | Robin_Watts: does mupdf use ICC profiles in ICCBased color spaces or does it use the Alternate tint transform ? | 19:34.02 |
| | Robin_Watts: (and tor) and does mupdf use any color management when rendering ? | 19:34.57 |
| tor8 | ray_work: alternate tint to a device colorspace only | 19:35.14 |
| | though I think for icc we don't even do that much | 19:35.30 |
| | so no, no color management at all | 19:35.45 |
| ray_work | tor8: thanks | 19:36.01 |
| | that's what I thought | 19:36.12 |
| tor8 | ray_work: it's on the todo list, and has been for a while, but since there's been no pressing need we haven't got round to it. | 19:36.22 |
| d3c | what's the minimum size of a PDF, approx.? I need to check for corrupt PDFs | 21:19.23 |
| | basically, how much will a completely empty PDF be? and is this even possible? | 21:20.55 |
| tor8 | d3c: very small, less than 1kb | 21:29.26 |
| | d3c: if you just want a quick check for a truncated PDF, it should always begin the file with %PDF and at the end %%EOF | 21:30.13 |
| d3c | tor8: thanks. %PDF\n and \n%%EOF ? | 21:31.08 |
| Robin_Watts | So, just reran the v1.4 files through mujstest. Only 1 SEGV now. ucm082348.pdf - looks like a NULL string. | 21:54.31 |
| mvrhel | Gigs-: you still here? | 22:35.25 |
| | the only reason that you would be getting it transformed would be if you left it out in the list of colorants | 22:37.34 |
| | or if you reached the maximum of colorants | 22:37.48 |
| | if you can open a bug for this, I can take a look | 22:37.58 |
| mlq | hello, i am using mupdf and i want to extract the images from a pdf; is there a way to access pdf_document->page_objs[x] without knowing mupdf-internal.h? | 23:24.00 |
| Robin_Watts | mlq: no. | 23:24.20 |
| mlq | Robin_Watts: okay, thanks | 23:25.24 |
| Robin_Watts | sorry | 23:25.33 |
| mlq | is this planned? the same probably applies for pdf_document->trailer, correct? but i think there will be fz_meta to extract information about the author etc? | 23:27.37 |
| Robin_Watts | It's not planned at the moment. | 23:33.59 |
| | If you want to extract images etc in a portable way, a better way is probably to implement your own fz_device, and run the page through that. | 23:34.34 |
| | That way it works with all the formats we support (pdf, xps, cbz), and you can get other information (like position etc) too. | 23:35.02 |
| mlq | okay, thanks for the hint | 23:41.40 |
| | Forward 1 day (to 2012/06/16)>>> | |
IRC Logs