| | <<<Back 1 day (to 2014/06/08) | 2014/06/09 |
| tor8 | Robin_Watts: ping | 10:26.50 |
| Robin_Watts | pong | 10:31.02 |
| tor8 | Robin_Watts: any thoughts on 695300? I have a proposed fix on tor/master but I wonder if it might just be better to not have the check at all (it seems like your pdfclean code already checks and replaces with null if the references are invalid) | 10:33.26 |
| Robin_Watts | So the problem is that pdf_new_indirect is being called with a negative num ? | 10:34.46 |
| tor8 | called with '0 0 R' | 10:34.55 |
| | and that throws an exception and then the whole file refuses to load | 10:35.05 |
| Robin_Watts | it seems to me that throwing an error there is exactly correct. | 10:35.06 |
| kens | I thought object 0 was the head of the free list and specified to always be free | 10:35.32 |
| Robin_Watts | The calling code should either catch the exception and cope better, or should know better than to call with a negative/zero numbered object. | 10:35.34 |
| tor8 | trying to resolve an invalid reference will return the null object | 10:35.36 |
| | IMO we don't want to throw errors when creating the pointer, only when dereferencing it. | 10:36.23 |
| | and not even then. when using a pdf_obj 'badly' we always return zero-valued values. | 10:36.45 |
| Robin_Watts | tor8: hmm. maybe. | 10:36.49 |
| tor8 | using a dictionary where a number is expected, we treat it as '0' | 10:37.15 |
| | we always to to be as lenient as possible towards idiot errors in pdf files | 10:37.56 |
| Robin_Watts | tor8: Fixing it like that seems reasonable. But I'd add a comment to that effect. | 10:38.17 |
| | otherwise we'll hit it again in 6 months. | 10:38.31 |
| tor8 | question is, would anything break if I removed the check and let 0 and < 0 indirect references live? | 10:38.47 |
| | in your pdfclean code | 10:38.54 |
| | commit 00f3869f8eecc202fe5f736825de5a5ee8ca4b3a | 10:39.08 |
| Robin_Watts | I don't know. | 10:39.28 |
| tor8 | introduced the checks, but it seems the fz_throw in pdf_new_indirect in that commit is redundant | 10:39.30 |
| | - if (o >= xref_len) | 10:39.43 |
| | + if (o >= xref_len || o <= 0 || opts->renumber_map[o] == 0) | 10:39.43 |
| Robin_Watts | Possibly I did belt and braces. | 10:39.47 |
| tor8 | well, we have a test file I guess I could test what happens if I remove the belt :) | 10:40.15 |
| | oh. segfault :( | 10:40.40 |
| | Robin_Watts: okay, fixed the segfault (sweepref was using a bad range check) | 11:01.52 |
| | Robin_Watts: new version on tor/master for review | 11:02.05 |
| Robin_Watts | lgtm. | 11:05.15 |
| | possibly we could cope with being asked to read an xref that has a 0 numbered object in (as long as that object is a free one) | 11:05.49 |
| | but I guess this will allow us to see if we have any such files in our test suite. | 11:06.07 |
| tor8 | I guess we could, but I'm not sure there's any benefit | 11:08.22 |
| | given how many assumptions about 0 being free in the code (and the spec requirement) | 11:08.49 |
| Robin_Watts | tor8: If a cluster test doesn't show any such files, I wouldn't worry. | 11:09.01 |
| tor8 | yeah. | 11:09.41 |
| | have you had time to look at the crash bug 695260? | 11:10.10 |
| Robin_Watts | tor8: no. | 11:10.34 |
| | though I suspect the fix is going to be to take on zenikos fix in addition to my one. | 11:10.52 |
| tor8 | okay. I was hoping you could do that before I do the 1.5 release | 11:11.10 |
| Robin_Watts | I will try to look later today. | 11:11.27 |
| tor8 | I find it hard to test/reproduce zenikos bugs that only show up on windows :( | 11:11.45 |
| | Robin_Watts: thanks. | 11:11.56 |
| Robin_Watts | tor8: Did you look at the commits on robin/master ? | 11:26.03 |
| tor8 | Robin_Watts: oh my, looks like I have to think a bit more on this commit | 11:26.32 |
| Robin_Watts | The post processing | 11:26.35 |
| | and the pre-populated buffer. | 11:26.44 |
| tor8 | Robin_Watts: yes. for the post processing hook, couldn't we add an END_OF_DATA operator instead? | 11:26.55 |
| Robin_Watts | tor8: ? | 11:27.05 |
| tor8 | and BEGIN_OF_DATA | 11:27.06 |
| | as pseudo-operators | 11:27.11 |
| | on begin-page / end-page | 11:27.17 |
| Robin_Watts | The idea is that I want to filter the existing page to get a buffer. | 11:27.29 |
| tor8 | for drawing watermarks before/after the page | 11:27.33 |
| Robin_Watts | Then I want to be able to pass that buffer to a new pdf-device and call various draw functions to place stuff on the page. | 11:27.57 |
| | As a user, I don't want to have to write my own filters to do that. | 11:28.30 |
| tor8 | right. I was thinking we could add a pdf-op-processor function for begin/end page that, as a callback, would do the same calls to the pdf-device as part of interpreting the page | 11:28.57 |
| | as a more generic way to hook into the filters | 11:29.23 |
| Robin_Watts | If I understand what you're suggesting correctly, I'd need to write my own filter to hook begin-data, end-data though, right? | 11:29.25 |
| tor8 | yeah. or some way to override individual functions in the filter once it's set up but before it runs | 11:29.46 |
| Robin_Watts | possibly we could have a filter that was constructed from a begin-data and end-data function and just passed all the others on. | 11:30.17 |
| tor8 | pdf_clean_page_contents could take two functions (begin/end-page procs) | 11:30.50 |
| Robin_Watts | It could. | 11:31.12 |
| | I will ponder on that. | 11:31.30 |
| tor8 | pdf_process_filter() then pdf_process_filter_override(opcode, function) | 11:31.34 |
| Robin_Watts | I don't think it's safe to override filter functions. | 11:31.58 |
| | because they get passed private data for the filter. | 11:32.08 |
| | and unless you are part of the filter itself, you shouldn't have that. | 11:32.22 |
| tor8 | hm. so another null-filter on top that can have overrides? | 11:32.32 |
| Robin_Watts | Having a new override filter seems safer though. | 11:33.02 |
| tor8 | I'm thinking if you want to rewrite images or colors or something specific as part of the mutool clean pipeline (possibly using some scripting interface using mujs or lua) | 11:33.08 |
| | yeah. you don't want to mess with the default filters. | 11:33.26 |
| Robin_Watts | fz_overrideable_filter(void *private_arg) | 11:33.39 |
| tor8 | given that they might be passing all sorts of state and private data between operators | 11:33.42 |
| Robin_Watts | then fz_filter_override(filter, op, function) | 11:33.53 |
| | Hmm. would need to think avoid how passon works with that. | 11:34.27 |
| tor8 | yeah, something like that. | 11:34.30 |
| | pdf_new_custom_filter() and then pdf_custom_filter_function(op, function) was what I was going to suggest | 11:34.37 |
| | or custom_processor and custom_processor_override | 11:35.17 |
| Robin_Watts | each function would need to pass on by default, and possibly could return an int saying whether to pass on or not. | 11:35.21 |
| | So, we could have a filter that (say) binned all images larger than a given size | 11:36.01 |
| tor8 | we could make then call pdf_process_op on the parent chain rather than have it implicit | 11:36.05 |
| | (and that'd be the default) | 11:36.12 |
| Robin_Watts | yes. | 11:36.30 |
| tor8 | in case the processer wants to decompose or replace some op with a sequence of others | 11:36.34 |
| | so each function would get the arguments and the underlying pdf_process | 11:37.12 |
| Robin_Watts | I need to look back at this stuff, but I'm sure it can be made to work. | 11:37.37 |
| | The key thing is to ensure that the normal case doesn't get any slower. | 11:37.46 |
| tor8 | yeah. I think it's worth tweaking a few times to get the API nice and usable for scripting. | 11:38.06 |
| | but I fear that should wait to post 1.5 :) | 11:38.19 |
| Robin_Watts | yeah. | 11:38.29 |
| tor8 | I believe more in adding a begin/end-page hook and custom overrideable content streams than pasting text buffers | 11:39.10 |
| | we might want to have begin/end-page hooks on the device level as well, though | 11:39.31 |
| | for if a client wants to use the device interface to add watermarks, rather than pdf operator calls | 11:40.12 |
| Robin_Watts | Ah, right, yes. | 11:40.52 |
| tor8 | or maybe even a complete overrideable device that just forwards normal calls | 11:40.54 |
| | and allows overriding individual device calls | 11:41.02 |
| | much in the same way as we just discussed for the op-processor | 11:41.13 |
| Robin_Watts | This method would only allow us to do watermarks by speaking pdf operators. | 11:41.16 |
| | where I was hoping to allow people to do it with device calls. | 11:41.26 |
| tor8 | yeah, so the same thing but at a later stage in the device interface after the interpreter | 11:41.47 |
| Robin_Watts | device calls being much more what people are used to. | 11:41.53 |
| tor8 | the device interface already has begin/end page calls | 11:41.57 |
| | so allowing a filter device that can add watermarks in response to a begin/end page call would be nice | 11:42.39 |
| | (and that one could do color conversions as well, to turn everything grayscale, etc) | 11:42.57 |
| Robin_Watts | I agree that we should sit on this until after 1.5 | 11:43.29 |
| tor8 | the pdf op-processor would let you add watermarks without running through the pdf-write device though | 11:43.35 |
| Robin_Watts | Yes, at the cost of having to speak pdf. | 11:43.59 |
| tor8 | yes. | 11:44.13 |
| | which is entirely reasonable, given that you want to preserve the pdf content stream | 11:44.39 |
| | and still be more robust than pasting text blocks | 11:45.00 |
| | (which might still be possible by recursively calling the pdf interpreter on some bit of text in the op processor) | 11:45.46 |
| | Robin_Watts: ping again | 14:01.38 |
| | test file tests/Ghent_V3.0/070_OutputIntent_ISOCoated1-v1_x3.pdf | 14:01.46 |
| | if you break it so that it runs through the repair code, the leftmost X ends up rendered with a different size... something fishy must happen with the repair code on that file | 14:02.23 |
| | it looks to me like it's getting the object numbers wrong on some of them | 14:05.45 |
| Robin_Watts | tor8: hmm. | 14:06.57 |
| | I have seen odd results with pdfclean that might be related. | 14:07.07 |
| tor8 | I suspect it's because the file has multiple revisions with the same object many times | 14:08.59 |
| | I see at least 3 instances of "22 0 obj" with different objects in that file | 14:09.23 |
| Robin_Watts | Ah. | 14:09.40 |
| tor8 | and the original xref points to the first, but the repair code picks up the third | 14:10.05 |
| Robin_Watts | I wonder if we care ? | 14:10.39 |
| | If you repair a file, then you can expect problems. | 14:10.55 |
| tor8 | I'd say not to worry, now that I've debugged the file | 14:11.11 |
| Robin_Watts | and really, the later version in a file is more likely to be the correct one, right? | 14:11.11 |
| tor8 | but it looked worrying because the commit that makes object number checking more strict had a few mistakes that caused it to run repair when it shouldn't | 14:11.46 |
| | yes, I would expect that a properly created file, with incremental sections, would expect you to use the last instance of an object | 14:12.13 |
| Robin_Watts | marcosw: Morning. | 14:22.21 |
| marcosw | morning Robin_Watts | 14:22.28 |
| Robin_Watts | Could we have a new email address at @artifex.com that we can use for smart office stuff? | 14:22.40 |
| | I was thinking sos@artifex.com (smart office support) | 14:22.51 |
| | That way scott can mail the customer queries there, and they can be stored safely for us to search on. | 14:23.09 |
| kens2 | or ignore :-) | 14:23.41 |
| Robin_Watts | if that could be copied to me/paul/joseph/pete (and anyone else who is interested) it'd be useful. | 14:23.44 |
| | kens2: indeed. | 14:23.51 |
| henrys | marcosw: Iâd prefer it have the same receivership as support. | 14:24.45 |
| marcosw | you mean an actual sos@artifex.com mailbox or just a forward? | 14:25.01 |
| Robin_Watts | henrys: but + joseph and pete ? | 14:25.02 |
| henrys | Robin_Watts: yes of course | 14:25.12 |
| Robin_Watts | henrys: joseph + pete don't get support, and a couple of times I have forgotten that :) | 14:25.32 |
| | marcosw: I was thinking a forward, but... | 14:25.42 |
| marcosw | a foward is easy to setup, I'll forward sos@artifex.com to support + joseph + pet | 14:26.19 |
| henrys | paulgardiner: yes byte squared never noticed them before. | 14:26.40 |
| paulgardiner | Hmmm! :-( | 14:26.54 |
| henrys | paulgardiner: simon bates ? | 14:28.27 |
| | http://www.bytesquared.com/about | 14:28.52 |
| | paulgardiner: there in Londo | 14:29.21 |
| paulgardiner | Not a name familiar to me | 14:29.22 |
| henrys | n | 14:29.23 |
| jogux_mac | had seen office2 around, but not otherwise been aware of them. | 14:31.02 |
| | they only do iOS afaik. | 14:32.18 |
| henrys | Iâll be in and out today, my son is âshipping outâ Thursday, helping him move some stuff. | 14:34.50 |
| Robin_Watts | Simon Bates was a radio 1 DJ back in the day... | 14:35.19 |
| rayjj | this domain transfer process is really honked up. Miles "buys" the domain, but then they send the response emails to him and I don't get all the info :-( | 14:52.11 |
| Etrius | I heard mupdf devs are about here | 15:09.16 |
| rayjj | Etrius: you've heard correctly | 15:10.17 |
| Etrius | Can I assume you're one of them? | 15:10.25 |
| kens2 | roflmao | 15:10.37 |
| rayjj | Etrius: no, but they _are_ here :-) | 15:10.38 |
| Etrius | :| | 15:10.47 |
| | well, this is only really a small question | 15:11.07 |
| rayjj | Etrius: If you have a question or comment, just go ahead | 15:11.08 |
| Etrius | does it have a firefox plugin? | 15:11.15 |
| rayjj | tor played with browser plugins a while ago. | 15:12.23 |
| kens2 | i THINK THAT'S DEFUNCT | 15:12.31 |
| | oops caps sorry | 15:12.36 |
| tor8 | that was a very very long time ago | 15:12.41 |
| rayjj | kens2: I think so, too. But since I mentioned tor, I figured he would respond. | 15:12.58 |
| tor8 | as it stands, no, there is no firefox plugin and unlikely there will ever be | 15:12.59 |
| Etrius | :/ | 15:13.03 |
| tor8 | google has deprecated the NPAPI plugin interface, so who knows what will happen to browser plugins in the future | 15:13.16 |
| Etrius | mmk, thanks anyway | 15:13.17 |
| kens2 | You cna always write one of course | 15:13.22 |
| Etrius | lol pls | 15:13.28 |
| | I can barely work IRC | 15:13.31 |
| tor8 | if you're on windows, I think sumatrapdf (which is based on mupdf) works as a plugin | 15:13.37 |
| Etrius | I'll give that a shot | 15:13.50 |
| | thanks | 15:14.02 |
| mvrhel_laptop | henrys: I am going to be out most of the day today. Alden's school has camp so I am going to be there. back in the late afternoon | 15:14.35 |
| kens2 | THe sumtrapdf site says it has a browser plugin for Firefox, chrome and opera | 15:14.37 |
| tor8 | kens2: yeah. I don't like plugins myself, so I've never actually tried it, but I remember seeing some mention of it. | 15:17.34 |
| kens2 | Specifically excludes Internet Exploder though | 15:17.56 |
| tor8 | I would much rather open a new window with a proper application than have some embedded stuff where keybindings don't work half the time | 15:18.10 |
| kens2 | Me too | 15:18.18 |
| | But some sites make it hard to download and save PDF files | 15:18.32 |
| tor8 | a firefox plugin should work on internet explorer as well, they all use the same NPAPI interface | 15:18.33 |
| | except that chrome is going to drop that in a version or two... | 15:18.47 |
| kens2 | I wouldn't know, but Sukmatra says 'no' | 15:18.52 |
| Robin_Watts | tor8: So, looking at bug 695300... | 15:29.55 |
| | At various points in the draw-device, we push the graphic state. | 15:30.25 |
| | and if we get an error, we pop the graphic state so it's back to how it was when we started the operation. | 15:30.51 |
| tor8 | Robin_Watts: yes. | 15:32.47 |
| Robin_Watts | I'm wondering if we shouldn't do that. | 15:32.48 |
| | Because of the nested nature of stuff like this, possibly if we get an error while allocating the bitmaps when we push a 'start clip', we should leave the state pushed, just with null bitmaps. | 15:33.29 |
| tor8 | the interpreter will keep pushing/popping state as if the error never happened. | 15:33.32 |
| henrys | mvrhel_laptop: got it | 15:33.34 |
| Robin_Watts | tor8: right. | 15:33.58 |
| | That means we need to update all the code to check whether we have a valid bitmap before every use. | 15:34.25 |
| tor8 | I thought we had an error stack state counter that just discarded (certain) commands until the state was rebalanced? | 15:34.29 |
| | or maybe that's just wishful hoping :) | 15:34.37 |
| Robin_Watts | tor8: hmm. Yes. | 15:34.59 |
| | That's in the fz_device level | 15:35.04 |
| | and the draw state is in the draw-device level. | 15:35.12 |
| | so maybe the problem is that the two are getting out of step... | 15:35.25 |
| tor8 | I thought, if the error in the draw-device level triggered, it would just leave the state unaffected and propagate the error to the fz_device level | 15:35.48 |
| | which would then omit commands until it sees the matching pop for the push that failed | 15:36.01 |
| Robin_Watts | yes, you're right. that's the theory. | 15:36.07 |
| kens | Goodnight all | 16:14.07 |
| el_mendi | Hi, is there any example of how to create an Image XObject? I mean, I don´t know how to introduce the stream data that contains the color information of the Image. | 16:23.42 |
| tor8 | el_mendi: pdf_update_stream() | 16:24.29 |
| mstefanko | hey guys, is it possible to use mupdf for conversion only with the ubuntu package? | 16:25.03 |
| tor8 | el_mendi: I assume that you already know how to create the dictionary object and add it to the PDF document | 16:25.05 |
| | el_mendi: if not, I can go into more detail | 16:25.24 |
| Robin_Watts | el_mendi: If you don't know how to do that, look in pdf-device.c at send_image | 16:25.36 |
| tor8 | mstefanko: conversion from and to what? | 16:25.41 |
| mstefanko | from pdf pages to png | 16:25.49 |
| Robin_Watts | mstefanko: You want mudraw, not mupdf. | 16:26.03 |
| tor8 | mstefanko: do you have a 'mudraw' command? | 16:26.04 |
| Robin_Watts | I have no idea if that's in the ubuntu package or not. | 16:26.11 |
| mstefanko | hm nope, it didn't come with the mupdf package, that must be it | 16:26.32 |
| Robin_Watts | mstefanko: Is there a mutools or mupdf-tools package? | 16:26.51 |
| mstefanko | it's the mupdf-tools, that was it :) | 16:26.58 |
| | thank you! | 16:27.08 |
| Robin_Watts | np. | 16:27.13 |
| mstefanko | although it didn't come with mudraw, weird | 16:28.47 |
| pihug12 | Hi! | 16:29.52 |
| | I got a quick question concerning MuPDF for Android : | 16:30.06 |
| | Is there an ARMv6 version available ? | 16:30.17 |
| mstefanko | ah i guess it's pdfdraw | 16:30.47 |
| Robin_Watts | mstefanko: Boy. They are well out of date then. | 16:32.15 |
| mstefanko | argh | 16:32.22 |
| Robin_Watts | phug12: There is a version on google play for armv6. | 16:32.39 |
| | and you can build your own from sources. | 16:32.45 |
| tor8 | 0.9 ... yeah, that's quite ancient | 16:32.55 |
| pihug12 | Robin_Watts: I can't find it on Google Play. :-/ There is only ARMv7a. | 16:37.36 |
| | Do you share the APK somewhere ? I don't have Google Play on all my Android devices. | 16:38.14 |
| Robin_Watts | pihug12: We do not. | 16:38.35 |
| pihug12 | Can the latest 1.4 version be compiled for ARMv6? | 16:39.31 |
| Robin_Watts | pihug12: Yes. | 16:49.16 |
| mstefanko | wow, so fast | 16:49.43 |
| Robin_Watts | just change the appropriate line in platform/android/jni/something.mk | 16:50.10 |
| pihug12 | OK I'll check with the F-Droid guys if they can update their builds. | 16:50.13 |
| Robin_Watts | where something might be 'Android' or 'Application'. I forget :) | 16:50.26 |
| pihug12 | I don't have enough skills to do it myself | 16:50.28 |
| | Yes, thats's the one : http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/android/jni/Application.mk | 16:52.04 |
| Robin_Watts | tor8: Fix on robin/master | 16:57.50 |
| | cluster push running now. | 16:57.55 |
| | My next job is to try to find the threading problem with mvrhel's file. | 16:58.25 |
| tor8 | Robin_Watts: LGTM if it passes | 17:16.05 |
| Robin_Watts | it passed. | 17:23.11 |
| el_mendi | First of all thank you for answer and help me | 17:49.39 |
| | So if I understand it I need to create an fz_image variable, put my image there, and then put it into the pdf_device with the function send_image? | 17:51.05 |
| | And after that call pdf_update_stream? | 17:51.52 |
| marcosw | Robin_Watts, et.al.: I've setup the sos@artifex.com email alias. Mail sent to that address will be forwarded to Pete, Joseph, and support. | 17:58.17 |
| mstefanko | mupdf is awesome, so fast and very efficient with the pdfs | 18:09.08 |
| | is there a steady source link to it that wouldn't change? | 18:09.28 |
| Robin_Watts | downloads.ghostscript.com | 18:14.12 |
| | or do you want the git repo ? | 18:14.24 |
| mstefanko | hm that looks like it has an outdated version of mupdf | 18:16.29 |
| | i mean this one, http://www.mupdf.com/downloads/ but i'm afraid that once e.g. 1.5 is released, the link would change | 18:16.47 |
| | yeah maybe there's an official github repo? | 18:16.54 |
| | oh i'm stupid, i didn't see the archive | 18:17.22 |
| Robin_Watts | git.ghostscript.com/mudf.git is the git repo. | 18:17.54 |
| | We don't use github. | 18:17.58 |
| tor8 | mstefanko: in mupdf.com/downloads/archive/ are permanent download links to old (and current) versions | 18:18.13 |
| mstefanko | oh wow you guys are very active http://git.ghostscript.com/?p=mupdf.git;a=summary | 18:19.27 |
| Robin_Watts | Hmm. I just modified the multi-threaded.c example so it works on windows. | 19:20.18 |
| | and made it load each of the 3 pages from mvrhels file, then render each one on a thread 1000 times. | 19:20.48 |
| | No problems show up here. | 19:21.02 |
| | I must be doing something wrong. | 19:22.05 |
| sebras | Robin_Watts: is it on robin/master? | 19:22.23 |
| Robin_Watts | sebras: No. | 19:22.31 |
| sebras | Robin_Watts: let me know if you push it. I'd like to take a look. | 19:22.47 |
| Robin_Watts | sebras: The lack of 'join' on windows is a pain. | 19:23.18 |
| sebras | Robin_Watts: how do they do that on windows? | 19:23.32 |
| | on windows? in windows? nvm. | 19:23.43 |
| Robin_Watts | sebras: Non-C things have access to join. | 19:23.57 |
| | but C things don't. | 19:24.03 |
| sebras | Robin_Watts: like C++? | 19:24.16 |
| Robin_Watts | Indeed. | 19:24.21 |
| sebras | oh. | 19:24.24 |
| Robin_Watts | foods. | 19:24.55 |
| | Forward 1 day (to 2014/06/10)>>> | |
IRC Logs