| | <<<Back 1 day (to 2012/05/13) | 2012/05/14 |
| Robin_Watts | tor8: ping | 09:53.53 |
| tor8 | Robin_Watts: morning! | 09:54.58 |
| Robin_Watts | Morning. | 09:55.02 |
| | I had an idea about linearized support over the weekend. | 09:55.15 |
| tor8 | funny exasperated bug report that last one, WE NEED MUPDF IN C# NAO! | 09:55.26 |
| Robin_Watts | Yes, I just added a comment. | 09:55.35 |
| tor8 | d'oh! | 09:55.59 |
| | I didn't notice the double post until now :) | 09:56.19 |
| | okay, so about linearization? | 09:56.24 |
| Robin_Watts | My existing plan was to write the file out once to find all the offsets, then seek back to the start, and write it out again knowing all the offsets. | 09:56.34 |
| tor8 | wait, shouldn't you spell it "linearisation"? | 09:56.39 |
| Robin_Watts | Indeed. It's correctly spelt linearisation, but adobe gets it wrong, so I'm torn.... | 09:57.05 |
| tor8 | we spell colo[u]rspace wrong everywhere so keep misspelling ;) | 09:57.41 |
| Robin_Watts | It dawned on me last night that if we clone all the fprintf etc entry points as fz_fprintf, we could have a special 'null' output device which we dumped to just to find the offsets. | 09:58.23 |
| | It dawned on me last night that if we clone all the fprintf etc entry points as fz_fprintf, we could have a special 'null' output device which we dumped to just to find the offsets. | 09:58.49 |
| tor8 | argh, stupid wifi drivers on the new macbooks keep failing randomly :( | 09:58.51 |
| Robin_Watts | so the first pass would be a null one to find the offsets, then the second pass would be a real one to write the file. | 09:59.15 |
| | No temp files, no need to seek. | 09:59.22 |
| tor8 | Robin_Watts: what about opening with "w+" so you can seek back and overwrite for the backpatching pass? | 09:59.33 |
| Robin_Watts | It's not just a backpatching pass. | 09:59.57 |
| | We need to know all the offsets for every page so we can write the hint table, which has to go in the middle. | 10:00.18 |
| tor8 | you know the maximum size for both the linearisation params dict and the first xref. the hints table, you should know how big that is up front too or am I wrong about that? | 10:00.40 |
| Robin_Watts | so it needs to be 2 whole passes (or to use temporary files and copy data) | 10:00.41 |
| | We don't know the size of the hint table. | 10:00.57 |
| tor8 | Robin_Watts: we used to have write support with all the streams and filters once. major source of bugs that was. | 10:01.27 |
| | but it let us print to memory buffers etc | 10:01.39 |
| Robin_Watts | If we knew we have '/dev/null/' we could do an output pass to that, then again to the real file. | 10:02.15 |
| tor8 | yeah, but I don't think we can rely on that | 10:02.31 |
| Robin_Watts | (assuming ftell on /dev/null gives that same offsets - which is questionable I guess) | 10:02.34 |
| | Indeed, hence my thought that we could clone fprintf etc,and implement our own device. | 10:03.02 |
| | It would mean we could pipe the output. | 10:03.29 |
| | which is always nice. | 10:03.40 |
| | brb | 10:04.01 |
| tor8 | yeah, we could add a wrapper printf that either just counts and swallows, or forwards to a real file. do you think it'll be small enough to just keep in pdf_write.c ? | 10:05.00 |
| Robin_Watts | I don't know. | 10:09.09 |
| | My instinct would be to put it in it's own file. | 10:09.32 |
| | but I have to make this version work first. | 10:09.58 |
| naveen_ | Hey Robin..Is Base64 decoding available in muPDf? | 10:40.06 |
| Robin_Watts | Morning | 10:40.23 |
| naveen_ | Morning Robin.. | 10:40.40 |
| Robin_Watts | That's not a standard PDF decoder is it? | 10:40.49 |
| naveen_ | No I think.. | 10:41.09 |
| Robin_Watts | So, no. | 10:41.17 |
| naveen_ | :) ok. | 10:41.27 |
| Robin_Watts | why do you need it? | 10:41.38 |
| naveen_ | i need to decrypt a key that is encoded in base64 | 10:42.05 |
| Robin_Watts | Ah, I see. | 10:43.37 |
| | tor8: I see the problem here. | 11:07.47 |
| | pdf writing is a 'destructive' event currently. | 11:08.17 |
| | If you decompress streams in one pass, then when we come to do the second pass, it thinks the streams are decompressed already. | 11:09.19 |
| kens2 | Robin_Watts : has been watching too many reruns of Red Dwarf :-) | 11:13.29 |
| Robin_Watts | I haven't seen a rerun of red dwarf in years. but that is one of my favorite meme's from the series :) | 11:14.01 |
| kens2 | :-) | 11:14.07 |
| | I think Dave keeps rerunning them | 11:14.19 |
| Robin_Watts | I'm sure. Last I heard, they'd actually commisioned a new series. | 11:14.47 |
| kens2 | Yes, I think I heard that too. | 11:14.59 |
| Robin_Watts | tor8: png | 12:19.38 |
| | ping, even | 12:19.42 |
| sebras | Robin_Watts: I think he's out for a long lunch so be patient. | 12:28.04 |
| Robin_Watts | np. | 12:28.12 |
| kens2 | Hmm | 12:42.38 |
| | Robin_Watts : I think something is up with the cluster | 12:42.47 |
| | My last commit hasn't entered the queue for testing yet | 12:43.04 |
| | forget that, its my browser | 12:43.19 |
| | not updating for some reason | 12:43.25 |
| Robin_Watts | Lunchtime. bbs. | 13:14.03 |
| galtgendo | is there any interest in gsx rewritten a bit to make it (potentially) build against gtk3 ? | 14:52.22 |
| chrisl | galtgendo: I see no reason that would we turn down such a patch, but I doubt we'd do the work ourselves (any time soon) | 14:56.27 |
| Robin_Watts | chrisl: <StupidQuestion>What is gsx?</StupidQuestion> | 14:57.30 |
| henrys | well it would be a regression - are they simple compile errors? | 14:57.35 |
| galtgendo | OK, just to make sure about a thing: gsx is meant only for unix/macos, right ? | 14:57.47 |
| henrys | I know gs worked with gtk don't know bout gtk3. | 14:58.21 |
| | gsx is the old name for the exe that used the shared lib... | 14:59.58 |
| | shared lib and gtk | 15:00.30 |
| galtgendo | cause I already have a patch, but a certain change there makes it use glib unix specific API | 15:00.41 |
| Robin_Watts | But we don't supply the gsx source (any more?) right? | 15:01.17 |
| chrisl | Yes, gsx in built when you do a make so | 15:01.40 |
| henrys | chrisl:oh I thought it was deprecated. | 15:02.00 |
| Robin_Watts | AH, so that's why I've not seen it. | 15:02.06 |
| galtgendo | (and from the looks of it, while there seems to be win32 API looking similar, it's description would suggest it wouldn't be working right) | 15:02.30 |
| chrisl | henrys: I assumed it was unsupported, which is why we wouldn't want to do work on it, if someone else wanted to, I don't see a reason to turn it down | 15:03.00 |
| | galtgendo: IIRC, the Windows exe and gsx use the "display device" API, so they will look similar | 15:03.39 |
| | galtgendo: FWIW, I'm happy to review a patch for it, but I'll say up front, I'd like it if it didn't break the current compatibility with (I assume) gtk2 | 15:05.11 |
| henrys | IMHO support it or remove it from the documentation. I don't know the difference between gtk+ and gtk3 we don't say anything about the latter. | 15:05.58 |
| | gtk+ may very well work okay. | 15:06.41 |
| chrisl | gtk+ comes in 1.x, 2.x and 3.x versions, he's talking about gtk+ 3.x.x | 15:07.30 |
| galtgendo | well, I'm talking about g_io_channel_unix_new - while there is g_io_channel_win32_new_fd, its description isn't very promising | 15:08.02 |
| chrisl | galtgendo: like I say, gsx is Unix only, so if what you've got works on Unix, that's fine. | 15:09.14 |
| | I have to head off...... ttfn | 15:09.52 |
| galtgendo | anyway, my patch doesn't break gtk2, only modifies the source to be possible to build with minimal #ifdef against gtk3 | 15:14.30 |
| Robin_Watts | galtgendo: That sounds great. If you go to bugs.ghostscript.com you can make a new bug there, and attach your patch to it. | 15:16.51 |
| | List it as a "build bug" and it will get assigned to chris. | 15:17.06 |
| kens2 | henrys, taht commit I did a little earlier seems to resolve the major problems with pdfwrite/ps2write and 'one file per page' output. | 15:20.07 |
| | I cna now complete both teh PDF reference manual and the PLRM | 15:20.19 |
| henrys | yes I saw that -- really nice. | 15:20.24 |
| kens2 | I hope so :-) | 15:20.29 |
| | Still need to check the proper 'server mode' working | 15:20.39 |
| | Looking for more memory leaks | 15:20.47 |
| galtgendo | Robin_Watts: only one catch, unless I'd go for *excessive* ifdefing, I'd need to drop gtk1 | 15:20.50 |
| kens2 | I think we cna live with dropping gtk 1 :-) | 15:21.07 |
| henrys | kens2:without increasing memory usage? | 15:21.16 |
| kens2 | henrys I hope the memory won't increase, if it does I have leks to find ;_0 | 15:21.36 |
| | I have to run for a checkup at the dentist, will be back later | 15:22.02 |
| henrys | okay | 15:22.12 |
| ray_laptop | I guess I missed kens | 15:41.08 |
| henrys | ray_laptop:ping? | 15:41.19 |
| ray_laptop | henrys: pong | 15:41.28 |
| henrys | the potential customer you are working with ... they still aren't signed up, do you think we should have scott push them. | 15:42.29 |
| | ? | 15:42.35 |
| ray_laptop | I'll email kens, but for the logs, one way to test pdfwrite server mode doesn't really need a custom application since the pdfwrite device is closed and re-opened when the OutputFile changes. | 15:42.59 |
| henrys | I don't think scott will do anything unless one of us says something. | 15:43.26 |
| Robin_Watts | ray_laptop: Yes, I believe he knows that. | 15:43.46 |
| ray_laptop | so a simple PS program that processes a list of files, setting the file name for each file, can do the same thing as a C 'server' app would | 15:43.52 |
| | henrys: scott was copied on the email and has been waiting for an update from me to ping them | 15:44.28 |
| henrys | oh okay | 15:45.02 |
| ray_laptop | but I'll ring him up and see if he is going to ping them, or if not, what he is waiting for. | 15:45.07 |
| | calling scott ... | 15:45.56 |
| | he's on the other line and will call me right back. | 15:46.48 |
| | cust 532 is getting ansy again :-( | 15:47.05 |
| | good thing I am already working on their issue | 15:47.25 |
| henrys | Robin_Watts:did you test your path code with dashed lines - seems to be broken? it might be easier to look in postscript for you or I can put my world on a public branch. | 15:52.03 |
| Robin_Watts | henrys: I thought I did. | 15:52.20 |
| | What are you expecting it to do? Restart the dash pattern after each gap? | 15:52.54 |
| henrys | I have frequent disappearing graphics with dash mode - look like some of the path coordinates are wrong (negative) | 15:54.08 |
| | I know I said the project wasn't important but I realized I'm very close to finished so I thought I'd spend a bit more time on it. | 15:55.37 |
| Robin_Watts | henrys: OK. I'll have a look when I get this linearisation stuff to a parkable state. | 15:56.53 |
| henrys | no hurry | 15:58.02 |
| ray_laptop | henrys: just got off the phone with Scott-san. He is going to ping them again on the time frame for business discussions. | 16:07.24 |
| mvrhel | hmm the issue that Gemma just sent looks like an anti-alias issue | 16:13.47 |
| henrys | mvrhel:probably best to let marcos do the bisect if you don't know off the top of your head. | 16:18.37 |
| mvrhel | henrys: right | 16:20.19 |
| Robin_Watts | mvrhel: Hmm. | 16:20.42 |
| | "Web based" could well be an image. | 16:20.54 |
| mvrhel | could be | 16:21.04 |
| | I am not going to fool with it now though | 16:21.10 |
| Robin_Watts | which would fit with her assertion that interpolation isn't working. | 16:21.12 |
| | And a bisect ain't going to tell us anything other than "the tiffsep changes broke it" | 16:21.32 |
| mvrhel | there were other commits than that | 16:21.47 |
| | marcos did not give her a patch | 16:21.53 |
| Robin_Watts | ok. | 16:22.07 |
| jellenagels | Hi guys, anyone here who made the android mupdf library ? I have quick question. | 16:27.56 |
| | or at least, the android-connection to the c-library. | 16:28.16 |
| Robin_Watts | jellenagels: Ask your question :) | 16:28.47 |
| jellenagels | I'm trying to create a thumbnail of 1 page. | 16:29.08 |
| | the first page of the pdf-file. | 16:29.16 |
| Robin_Watts | ok. | 16:29.22 |
| jellenagels | This is the code: http://i.jnagels.be/Screen%20Shot%202012-05-14%20at%2018.29.20.png | 16:29.37 |
| | But it shows error in logcat: http://i.jnagels.be/Screen%20Shot%202012-05-14%20at%2018.29.50.png | 16:30.03 |
| Robin_Watts | OK. | 16:30.20 |
| jellenagels | as you can see, i pass "1" as page. not -2 ^^ | 16:30.22 |
| | do you perhaps know what the problem is? | 16:30.44 |
| Robin_Watts | I think you're assuming too much. Let me check the code. | 16:30.54 |
| | The MUPDFCore interface is not really a public one - it's specific for the viewer. | 16:32.28 |
| | The only defined 'public' interfaces are the ones defined in fitz.h and mupdf.h (i.e. C level ones). | 16:33.03 |
| | In order to make the android port, we've wrapped the C library with some simple classes to expose just the functionality we need. | 16:33.49 |
| | As such those interfaces should be considered subject to change. | 16:34.12 |
| | But if you're prepared to accept that... | 16:34.36 |
| jellenagels | i know they are subject to change :) | 16:35.06 |
| Robin_Watts | The existing android app does: | 16:35.12 |
| jellenagels | it's just, i see almost the same code in "PageView.java" to draw the page | 16:35.23 |
| Robin_Watts | core = new MuPDFCore(path); | 16:35.28 |
| | You're right. That does seem odd. | 16:40.45 |
| | gotoPageInternal is being called with -2 for some reason... | 16:41.36 |
| jellenagels | yeah, and i can't see why. | 16:41.53 |
| | i didn't change anything to the source or something. | 16:42.05 |
| | actually, i just did a fresh checkout of the source-zip | 16:42.18 |
| Robin_Watts | Ah, right. | 16:42.31 |
| | gotoPage is being called with numPages == 0. | 16:43.02 |
| jellenagels | so i should countPages() first | 16:43.17 |
| Robin_Watts | You need core.countPages(); | 16:43.18 |
| | yeah. | 16:43.20 |
| jellenagels | let's check it out ^^ | 16:43.31 |
| | but that'll probably fix the issue ! | 16:44.07 |
| | thanks a lot! | 16:44.12 |
| Robin_Watts | no problem. | 16:44.42 |
| | Like I say, these interfaces are "just enough to make the android viewer work". | 16:45.02 |
| jellenagels | indeed :) too bad :p | 16:46.37 |
| | there's nothing out there for android at the moment. | 16:46.47 |
| | all other libraries are based on yours | 16:47.03 |
| | hmz, doesn't seem to be fixed. | 16:47.29 |
| Robin_Watts | Presumably you now see something different on logcat though? | 16:50.20 |
| | What does countPages return ? | 16:50.32 |
| jellenagels | hm, something is wrong with my eclipse/device here. i'll check it out and i'll get back to you in a bit. | 16:55.22 |
| Robin_Watts | jellenagels: I find that I sometimes have to uninstall the app from the device before installing a new version. | 16:56.05 |
| jellenagels | i normally don't have issues with that, but it might be with all the native-code, that it get's fucked up | 16:56.34 |
| galtgendo | Robin_Watts: filed the patch at bug 693038 | 17:00.36 |
| Robin_Watts | galtgendo: Thanks. | 17:09.36 |
| | galtgendo: So, where did you get your gs source? | 17:17.24 |
| Robin_Watts | pops to station to get helen. bbs. | 17:18.13 |
| galtgendo | well, indirectly from ghostscript.com..., but that wasn't quite my point | 17:19.47 |
| Robin_Watts | galtgendo: So what was your point, exactly. The modification to bugzilla was done by me, and it's very deliberate. If you've got a genuine objection, please state it. | 17:57.58 |
| mvrhel | Robin_Watts: quick question for you. So it appears with the slow file with the fills and strokes with transparency, that the fill paths are an issue | 18:01.33 |
| galtgendo | Robin_Watts: well, first of all, the I-'sort of'-know-what-I'm-doing case, then the fact it was redundant in this case | 18:01.40 |
| mvrhel | I was thinking that it was the strokes that were the problem | 18:02.03 |
| | perhaps it is both? | 18:02.07 |
| galtgendo | OK, so it's a bit of a corner case here | 18:02.28 |
| mvrhel | they both set lop_pdf14 | 18:02.35 |
| | does it make sense to wrap the fills and the strokes in knockout groups? | 18:03.05 |
| Robin_Watts | mvrhel: I wasn't expecting the fills to be slow. | 18:03.13 |
| mvrhel | right now if I disable only the strokes with the lop_pdf14 it is taking forever | 18:03.34 |
| | let me disable only the fills | 18:03.40 |
| Robin_Watts | galtgendo: Even in your case, we'd prefer a patch on top of our code rather than code from anywhere else. | 18:04.04 |
| | mvrhel: My memory of this bug is that it runs much faster when transparency is disabled,and I thought profiles pointed to it being the stroking code that was slow. | 18:05.07 |
| galtgendo | just call it my EULA click wrap allergy | 18:05.23 |
| mvrhel | Robin_Watts: if I disable lop_pdf14 for both strokes and fills it flies through the file | 18:05.39 |
| Robin_Watts | Right. lop_pdf14 is only *read* in lop_is_idempotent | 18:06.01 |
| | Ah. | 18:06.25 |
| | lop_is_idempotent makes a difference in the fill code too; it's used to decide whether to use the scanline or the trap fill. | 18:06.55 |
| mvrhel | ok | 18:07.00 |
| | so if I do a knockout around the fill also then we will be faster | 18:07.22 |
| Robin_Watts | in this case, yes. | 18:07.52 |
| | Just pondering.... | 18:08.19 |
| mvrhel | there is obviously a disadvantage to adding another buffer and popping that buffer to composite | 18:08.22 |
| | not sure what the lesser of two evils is | 18:08.53 |
| | the diff in this file is dramatic | 18:08.57 |
| Robin_Watts | Usually we prefer to fill using traps than scanlines in case we are going to a (somewhat) higher level output device that has code for handling trapezoids. | 18:09.09 |
| | BUT... in the transparency case we'll be going into a pdf14 device anyway, right? So it'll be broken down to scanlines anyway. | 18:09.34 |
| mvrhel | not in the clist case. | 18:09.49 |
| | we would still have trap fills | 18:09.56 |
| | I think | 18:10.09 |
| Robin_Watts | the transparency fills etc that we are dealing with here happen *post* clist, though, right ? | 18:10.28 |
| | i.e. in the rasterisation phase ? | 18:10.40 |
| mvrhel | right. the fill path from the clist is getting broken down to scan line fills | 18:11.36 |
| | during clist playback | 18:11.48 |
| Robin_Watts | actually, this may not make any odds. | 18:11.55 |
| | The current situation is that we'll render using scanlines, and it'll be slow. | 18:12.15 |
| | The new situation would be that you push a transparency group, we'll render using traps, but because of the group it'll go into the transparency device and be turned into scanline fills anyway. | 18:13.04 |
| mvrhel | but for some reason those happen much faster | 18:13.29 |
| Robin_Watts | Suck it and see, I guess :( | 18:13.29 |
| mvrhel | and I mean *much* faster | 18:13.42 |
| Robin_Watts | I suspect it's because someone has done a strokepath and then a fill. | 18:13.50 |
| | so the filled shape has lots of lines that intersect. | 18:14.00 |
| | Is this PS or PDF? | 18:14.10 |
| mvrhel | pdf | 18:14.12 |
| Robin_Watts | odd, then. | 18:14.20 |
| | Maybe it's just a convoluted path. | 18:14.31 |
| mvrhel | let me add the group around the fill and see what happens | 18:14.32 |
| | It may be worth while to do a timing compare with this fix | 18:14.59 |
| | on the cluster | 18:15.08 |
| Robin_Watts | One option would be to only enable the knockout group method if the path is above a certain complexity. | 18:15.42 |
| mvrhel | that needs to be decided in the PS interpreter code | 18:15.58 |
| | I leave that as an exercise for the student | 18:16.09 |
| | or as another professor used to say "how to do this is intuitively obvious to the most casual observer" | 18:17.23 |
| Robin_Watts | tor8, sebras: I've pushed a work in progress patch to make pdf_write have the option to output linearized files. | 18:38.28 |
| | Everything is there, I think, except the generation of the hint stream. | 18:38.41 |
| | There is scope for us producing more optimal files (we could sort objects within pages, and regenerate content streams/split them as appropriate), but as a first step, this at least produces something that fulfills the specification, I believe (except for the lack of the hint stream). | 18:40.13 |
| sebras | Robin_Watts: hint stream? | 20:04.39 |
| mvrhel | alexcher: I just sent marcos an email and cc'd tech. You may have some input on this that may help in the testing. | 20:08.17 |
| | second day of 80+ here in the seattle area. not too common in may. bbiaw | 20:18.52 |
| henrys | I keep getting asked about power profiling and know absolutely 0 about it. | 21:53.07 |
| | Robin_Watts, tor8:do we have iOS rom space numbers? And ram space for a job like PLRM | 21:54.23 |
| | we may have a new customer - yeah! | 21:54.36 |
| tor8 | henrys: ios .app is 6.5mb | 22:41.02 |
| Robin_Watts | henrys: cool. | 23:09.23 |
| | Forward 1 day (to 2012/05/15)>>> | |
IRC Logs
