| <<<Back 1 day (to 2013/12/11) | 2013/12/12 |
Robin_Watts | ray_laptop: Really? | 00:49.29 |
| ray_laptop: I believe their 'raw' output always pads the lines to multiples of 16. | 00:54.27 |
| And your code no longer does that. | 00:54.33 |
| I may have got the padding wrong, but it looks like you have no padding at all. | 00:54.46 |
mvrhel_laptop | hmm. looks like for the higher resolution printing with the surface I am going to need to do a bit of banding in the windows 8 app. | 06:30.53 |
| done for tonight | 06:30.58 |
Giulio | hi | 09:01.33 |
ghostbot | hola, giulio | 09:01.33 |
Giulio | is there someone? | 09:02.05 |
| I've a question about mupdf for Android | 09:02.23 |
| Is there a way to scroll pdf vertically and not horizontally? | 09:03.28 |
oznt | Giulio, it's a bug \ missing feature | 09:34.13 |
| already reported it ... | 09:34.17 |
| unfortunately i don't have the time to fix it myself ... | 09:34.28 |
| http://bugs.ghostscript.com/show_bug.cgi?id=691330#c46 | 09:35.14 |
Giulio | ok, thanks for answer...Did you have an idea on how to implement it? Because I think it's an Android feature not a C++ behavior, right? | 09:38.11 |
oznt | Giulio, i think so | 10:00.54 |
| you will have to look in the code of the android gui, nut mupdf it's self | 10:01.19 |
Giulio | Yes, ok. thanks :) | 10:11.23 |
sebras | Giulio: mupdf is implemented in C, not C++, except som thirdparty libraries. | 10:12.41 |
Giulio | yes yes, I know :) my fault | 10:17.40 |
sebras | Giulio: btw, if you do end up with a patch for the java code then do send it as an enhancement bug in bugzilla. mupdf do appreciate suggested patched. ;) | 10:19.59 |
| patches. | 10:20.02 |
Giulio | Ok, I'll try to do something.. | 10:21.39 |
tor8 | Robin_Watts, morning. | 10:34.25 |
Robin_Watts | tor8: Morning | 10:34.37 |
tor8 | the number replaces all old numbers you may have on file | 10:34.49 |
Robin_Watts | ok. | 10:34.56 |
tor8 | and I may soon be in a mental state fit to receive your ideas on JNI locking and contexts | 10:35.08 |
Robin_Watts | tor8: I hope to soon be in a fit state to try to communicate them :) | 10:35.30 |
kens | feels fine today | 10:36.39 |
Robin_Watts | tor8: So, locking. | 11:34.42 |
| My idea is to introduce some new functions: fz_lock_document(doc, ctx); and fz_unlock_document(doc); | 11:35.33 |
| The first one locks the document, and rebinds ctx to doc. | 11:36.27 |
| The latter one unlocks it. | 11:36.46 |
tor8 | right, so a document can be passed between threads and use the locking in the JNI layer to make it all transparent? | 11:37.24 |
Robin_Watts | Yes. | 11:37.33 |
| Likewise we will need fz_device_lock and fz_device_unlock. | 11:37.53 |
tor8 | what about fz_device, fz_stream and pdf_object and the other objects that have embedded contexts? same deal there? | 11:38.06 |
Robin_Watts | pdf_objects have a document inside them, not a context. | 11:38.39 |
| so the same fz_document_lock suffices there. | 11:38.52 |
tor8 | so pdf_object will lock the document implicitly? | 11:39.00 |
| or internally | 11:39.19 |
Robin_Watts | tor8: I think we'll need a new set of pdf_object function that take ctx as an arg, and do the lock, yes. | 11:39.38 |
tor8 | let's wait with pdf_object. I think lock/unlock for documents and contexts makes sense. | 11:40.20 |
| and it makes it explicit that they should be used in one thread at a time | 11:40.31 |
| something else I wonder about here: should we maybe provide some standard locking implementations? depend on pthreads and win32 locks by default? | 11:41.02 |
| or does that wreak havoc with java? | 11:41.09 |
Robin_Watts | tor8: I prefer our current 'agnostic' approach. | 11:41.26 |
| we do provide example implementations in the code in docs. | 11:41.49 |
| for pthreads at least. | 11:42.01 |
tor8 | okay. | 11:42.07 |
Robin_Watts | And we'll provide jni ones too as part of the jni bindings. | 11:42.34 |
| I'll need to extend the locking stuff a bit to cope with the doc locking too, I think. | 11:43.21 |
| I will bash on this a bit and see how it turns out. | 11:44.37 |
tor8 | Robin_Watts: anything to make the locking more explicit and easy to get not-wrong gets my approval :) | 11:46.11 |
| I never liked the ctx argument, but everyone bashes my head in about how bad TLS is... | 11:46.13 |
| maybe passing an explicit ctx and not embedding it in fz_document, fz_stream and fz_file is better despite the argument count bloating.... | 11:46.53 |
| eh, make one of those fz_device | 11:47.08 |
| otoh, they are not thread safe, so I'm not sure what would be gained, maybe explicit locking is a better solution | 11:47.46 |
Robin_Watts | Passing an explicit context everywhere is probably the solution we should have gone with to start with. | 12:02.33 |
| It's a low level ache that avoids larger pain elsewhere :) | 12:03.12 |
| but it still doesn't give us thread safety to file access etc. | 12:03.29 |
tor8 | yeah. a bit annoying to change now though, for the majority of calls. | 12:09.47 |
| maybe we should bite the bullet and fix it fon non-device, non-document cases though | 12:09.47 |
Robin_Watts | I am tempted to fix it for stream cases, yes. | 12:10.34 |
tor8 | just do it :) | 12:13.30 |
Robin_Watts | tor8: I had a potential customer ask whether we did progressive load of XPS the other day. | 12:31.36 |
| I'm guessing our .zip file handling uses the central directory at the end of the fle ? | 12:32.02 |
| file | 12:32.06 |
tor8 | we read and use the central directory, yes. | 12:33.55 |
| adding a progressive mode shouldn't be all that much work, if required | 12:34.11 |
Robin_Watts | ok. I don't think it's a priority for them, but we might want to consider that at some point. | 12:34.23 |
tor8 | we basically ignore all of the .rels crap, but there are a few hindrances to progressive loading that may bite us | 12:34.57 |
| like the start part, which is usually (90% of the cases) the last file in the zip | 12:35.43 |
| now, we could use heuristics to just crap all over the document structure and look for fixed names (Documents/1/Pages/%d.fpage) which should work for most files | 12:36.18 |
| but will fail spectacularly when it doesn't | 12:36.33 |
Robin_Watts | tor8: If we have control over the fetch, then that needn't be a problem. | 12:36.36 |
| We could offer a tool to 'linearize' XPS. | 12:36.52 |
tor8 | if we have control over the fetch, using the central directory shouldn't be an issue :) | 12:36.55 |
| Robin_Watts: yes. that would be a good tool to have. | 12:37.02 |
Robin_Watts | i.e. to put the files in order. | 12:37.04 |
tor8 | but given the interest level in xps... | 12:37.28 |
Robin_Watts | yeah. | 12:37.33 |
tor8 | such a tool would need to look at the resources and put them before the pages that use them | 12:37.55 |
| and join the insane interleaved parts crap | 12:38.07 |
| and you'd probably end up with a smaller file :) | 12:38.21 |
Robin_Watts | ideally you'd want to use the interleaved stuff so you could send the resource then the usage, then the next resource, then the next usage etc. | 12:40.28 |
tor8 | yeah, but I doubt any viewer can actually make use of such files | 12:40.54 |
| given the loophole in the spec where you can't actually rely on it | 12:41.05 |
| and that I've never ever even once seen a discard control part | 12:41.25 |
| and really, if you have resources at random access, parsing the nested xml data in chunks, serially, interleaved with resources... no, that's just brain dead. shame on the people who designed the interleaved parts and decided to use xml. | 12:42.52 |
Robin_Watts | shame on the people who designed .... xml | 12:43.26 |
chrisl | That's not really fair - XML is fine, it's just not the "silver bullet" solution to every problem folks seem to think it is | 12:44.15 |
Robin_Watts | "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." | 12:45.28 |
| Philip Wadler | 12:45.35 |
| (Of course, that's from the guy who co authored Orwell, so make of that what you will :) ) | 12:45.57 |
| "XML is like violence: if it doesnât solve your problem, you arenât using enough of it." (from someone at Microsoft) | 12:46.26 |
| "XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos." (Sarkos in reddit) | 12:46.53 |
| But the top quote on this page is great: | 12:47.13 |
| "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." (C.A.R. Hoare) | 12:47.28 |
chrisl | I think most of those quotes are confusing XML with the (mis-)use of XML...... | 12:50.20 |
Robin_Watts | tor8: So, to return to the fz_stream stuff. | 13:42.45 |
| I could just add fz_context arguments to fz_read, fz_seek, fz_meta. | 13:43.17 |
tor8 | yes. | 13:44.04 |
| Robin_Watts: for symmetry's sake, do the same with fz_output? | 13:44.15 |
Robin_Watts | Either those could assign into stream->ctx and then call the underlying functions unchanged (which would have the advantage of not having to change any of the underlying implementations) | 13:44.17 |
| Or I could pass the ctx on into stream->read, stream->seek etc. | 13:44.38 |
tor8 | I would rather fix everything so we limit the use of embedded contexts to devices and documents | 13:44.42 |
| (and I guess pdf_objects for now) | 13:44.47 |
| I would prefer the latter. | 13:44.58 |
Robin_Watts | Alternatively, I could have an fz_stream_bind(stream, ctx); function. | 13:45.17 |
| which sets stream->ctx | 13:45.30 |
| That would avoid any changes in the implementation, and just need a scattering of fz_stream_bind calls throughout our code. | 13:45.52 |
tor8 | I don't mind implementation changes. | 13:46.04 |
Robin_Watts | Performancewise, the latter is probably best. | 13:46.13 |
tor8 | I think only fz_read_byte etc will be impacted by any performance concerns | 13:46.33 |
| and those should be inlined anyway | 13:46.38 |
| however, it may make sense (eventually) to add fz_lock_stream for use by fz_document | 13:47.46 |
Robin_Watts | Ok, I'll go for the explicit context. | 13:47.46 |
tor8 | and then we could (with careful use) make multiple fz_documents on the same fz_stream | 13:48.01 |
| lock/seek/read/unlock | 13:48.14 |
Robin_Watts | If we were to do that, it might make more sense to change streams to a 'read from offset' API. | 13:48.52 |
tor8 | Robin_Watts: Thanks. I'm sure it will save us pain in the future. | 13:48.55 |
Robin_Watts | i.e. combine seek and read. | 13:49.01 |
| no locking required then. | 13:49.12 |
| or rather no locking required from the caller. | 13:49.22 |
| IF we're going to go for the lock/unlock stream thing, then explicit context is the wrong way to go, IMHO. | 13:50.08 |
| as the rebind comes as part of the lock/unlock. | 13:50.18 |
| but lock/unlock stream feels wrong to me at the moment. | 13:50.32 |
tor8 | Robin_Watts: yeah, but the question is where to put the offset, at each read_byte call, or just on the underlying object? or introduce a separate fz_buffered_stream type that is thread-local and holds the offset and buffer | 13:50.36 |
Robin_Watts | Multiple reading from the same stream is wrong, IMHO. | 13:50.56 |
tor8 | it will mean a lot of changes, so I'd prefer to just ignore the read-from-offset api for now | 13:51.10 |
Robin_Watts | If we want to do it we should make multiple streams from the same underlying object, I think. | 13:51.12 |
| that way each stream keeps a single buffer, etc. | 13:51.39 |
tor8 | but make it so that file descriptor based fz_streams always do seek/read or pread | 13:51.40 |
Robin_Watts | right. | 13:51.46 |
tor8 | then we could fz_clone_stream and that would have the same underlying data but be readable from other offsets in other threads | 13:52.15 |
Robin_Watts | we could engineer it so we have 2 streams both using the same FILE *, and the details of how it does that would be hidden. | 13:52.26 |
| yes. | 13:52.28 |
| Ok, so explicit context it is. | 13:52.40 |
tor8 | but the implicit context binding as an API choice is something I sort of regret | 13:52.49 |
| for the small data types like streams and objects that is | 13:53.09 |
| maybe even for the device | 13:53.16 |
Robin_Watts | yeah. | 13:53.43 |
| fz_streams and pdf_objects are the only things I can think of. | 13:54.07 |
| fz_streams we are fixing now. | 13:54.13 |
tor8 | fz_outputs as well | 13:54.43 |
Robin_Watts | and pdf_objects have an fz_document in there we can lock, so I think we've actually dodged the bullet. | 13:54.51 |
| OK, I'll fix fz_outputs too. | 13:54.57 |
tor8 | yeah, pdf_objects can lock the document when they need to load an object from file | 13:55.26 |
Robin_Watts | Callers will need to lock the document before making a pdf_object call. | 13:56.01 |
| because pdf_object calls don't take ctx args. | 13:56.15 |
tor8 | Robin_Watts: my concern is also about objects that don't have an owning document (like when creating new dicts etc) | 13:56.40 |
| or when doing pdfclean type operations where objects move from one document to another | 13:56.59 |
| but we can worry about those later | 13:57.04 |
Robin_Watts | hmm. will ponder that. | 13:57.15 |
| tor8: urgh. Moving the ctx out of the streams hits the lexer. | 14:53.02 |
tor8 | yeah... it spreads quite far (which is why we decided to pickle it the first time round) | 14:59.45 |
Robin_Watts | I'll push it through and commit it on a branch. Then I'm going to try the rebinding version as a comparison. | 15:01.02 |
| pdf_lexbuf's too :( | 15:01.59 |
tor8 | Robin_Watts: brb, need to reboot | 15:02.53 |
Robin_Watts | mvrhel_laptop: Morning | 15:45.03 |
| We got through security at OGG in about 5 minutes flat. | 15:45.31 |
| Got to the gate with almost 2 hours to spare. | 15:45.41 |
| Then as we went to get on the plane, our boarding cards didn't work. | 15:45.56 |
| "Oh", they said, "You'll have to see an agent". | 15:46.12 |
| Turns out the plane was downsized because of the snow in Dallas, so we had 47 fewer seats. | 15:46.38 |
| They spent an hour reorganising everything, cramming first class passengers into economy, getting people to step off etc, but we did get on in the end (in exit row seats, so can't complain) | 15:48.07 |
| Quite why they had to wait until we boarded before they reorganised rather than doing it while we sat around at the gate (or even at check in) is beyond me, but... | 15:49.00 |
| There was the worlds most obnoxious woman there who was insisting that she be dealt with first. "I booked in January!" she kept yelling. | 15:50.01 |
| There was a pretty obnoxious bloke there who finally snapped at her and told her to be quiet, whereupon she swore at him, and the desk clerks called security. | 15:51.01 |
| When she finally got her exit row seats, and a credit for the difference etc, she didn't say thank you, didn't even draw breath, just demanded vouchers for free food and drink on the plane. Never mind that there were still other people waiting to get seats... | 15:52.11 |
| And then when she got onto the plane, she proceeded to try to bash a huge box of chocolates or something into an overhead locker. | 15:52.46 |
| The locker was already full and the bloke underneath said "careful, there is a laptop in there", and she said "well, if you don't want it broken, you'll have to move it" (bash, bash, bash). | 15:53.27 |
| Amazing, just how many assholes there are in the world. | 15:54.20 |
kens | If oly that stupidity could be harnessed for something useful..... | 15:54.43 |
tor5 | hm, how do you start a private message session using the webchat interface? | 16:12.19 |
Robin_Watts | tor5: May not be possible. | 16:13.49 |
tor5 | right. so it only works if someone else starts it? | 16:14.10 |
| neither /msg nor /privmsg seem to do the trick... | 16:14.24 |
Robin_Watts | tor5: Click on the users name on the right hand side and you'll get a menu with 2 options. The second option is "query" | 16:15.13 |
| That starts a new tab. | 16:15.20 |
tor5 | oh, so that's what query means... | 16:15.33 |
| Robin_Watts: yeah, there seem to be an awful lot of people like that when you travel... | 16:16.53 |
Robin_Watts | tor5: In filter-jbig2.c in fz_open_jbig2d in the if (globals) case, do we leak state->ctx ? | 16:19.06 |
tor5 | what makes you think that? | 16:20.50 |
Robin_Watts | state->ctx = jbig2_ctx_new(....); outside the if. | 16:21.13 |
| Then if (globals) { state->ctx = jbig2_ctx_new(...); } | 16:21.37 |
| so we override the existing state->ctx | 16:21.44 |
tor5 | oh... yes, that doesn't look right. | 16:21.52 |
Robin_Watts | oh, but maybe the state->ctx has been pickled into the state->gctx by then ? | 16:22.13 |
| But I'd expect there to be a problem on error cleanup in that case. | 16:22.37 |
| If the second jbig2_ctx_new call fails, then state->ctx will be cleaned up both as part of the cleanup for state->gctx and for state->ctx. | 16:23.08 |
tor5 | I really have no idea how this api is supposed to work, but it looks problematic | 16:23.36 |
| I'd rather be explicit about the two jbig2_ctx_new calls if that's what is supposed to happen | 16:23.55 |
| and handle the context setup individually for the cases in if/else blocks | 16:24.59 |
Robin_Watts | tor5: I'll tweak it here so it's right. | 16:29.13 |
mvrhel_laptop | Robin_Watts: good grief. that is a little unusual for someone coming from hawaii. they should be a little more relaxed on the way home | 16:38.45 |
| but then I do have an image of this woman from your description and it is not pretty | 16:43.03 |
Robin_Watts | I honestly do not know how the staff put up with her. | 16:43.45 |
| If it had been me, I would have called security much earlier. | 16:44.01 |
mvrhel_laptop | Hi Robin_Watts: I just pushed up a bunch of changes related to error trapping, removing warnings, fixing stuff that broke with other commits in the 3rd party structure and font names. | 19:00.05 |
| if you can look this over that would be great | 19:00.12 |
Robin_Watts | sure. will look now. | 19:00.18 |
mvrhel_laptop | thank you | 19:00.22 |
| I have one more thing I want to fix, then I will finally update the store app | 19:00.34 |
| which is I need to do a bit of banding for the printing case due to the limited memory on the surface | 19:00.55 |
| works fine on my laptop but the surface barfs when I push the resolution | 19:01.09 |
Robin_Watts | mvrhel_laptop: There is code in mudraw to do banding if that helps. | 19:01.28 |
mvrhel_laptop | Robin_Watts: I will look that over. thank you | 19:01.39 |
| Robin_Watts: I have to run out for lunch. | 19:06.31 |
| bbiaw | 19:06.33 |
Robin_Watts | mvrhel_laptop: I can't follow the logic with the thumbnail adding. | 20:39.27 |
| Wierd indentation at around line 830 of MainPage.xaml.cpp | 20:41.08 |
| and 880. | 20:41.36 |
| UpDatePreRenderedPageSizes ? UpDate? surely Update ? | 20:42.44 |
| More wierd indents at 1653ish. | 20:43.58 |
| and 2125ish | 20:44.24 |
| and 2137/8ish | 20:44.48 |
| Broadly it looks OK. I can't claim to have any massive feel for the WinRT stuff, so there are limits to what a quick review will achieve, but it looks plausible. | 20:47.36 |
| I'd like to understand the thumbnail adding logic a bit better though. I feel I am missing some key piece that would make it all make sense... | 20:47.58 |
mvrhel_laptop_ | Robin_Watts: just got back | 20:56.58 |
| the thumb stuff is a bit odd and I just realized how I want to rework it | 20:57.10 |
Robin_Watts | mvrhel_laptop_: I've been away too. | 20:57.11 |
mvrhel_laptop_ | essentially the way that it was before, it was launching a thread for each page to render which was not good | 20:57.43 |
Robin_Watts | yeah, I get that it's trying to limit the number of threads that it's launching. | 20:58.02 |
mvrhel_laptop_ | the way it is now, it does not launch the next one until the previous one finishes | 20:58.04 |
| but I am going to change this | 20:58.08 |
Robin_Watts | OK. I couldn't follow the logic there, but I'll wait for the reworked version. | 20:58.25 |
mvrhel_laptop_ | the issue that I had was that the call to do the render was an async call that launched a new thread | 20:58.34 |
| I have since added a synchronous method which would be better here | 20:59.23 |
mvrhel_laptop | since the whole thumb creation stuff is on a separate thread anyway | 20:59.39 |
Robin_Watts | ok. | 20:59.45 |
mvrhel_laptop | this will end up much clearer to read | 20:59.53 |
| and fix if there are issues | 20:59.56 |
| let me do that and amend this commit | 21:00.12 |
| I was not entirely happy with what I had written there | 21:00.31 |
| but it worked | 21:00.35 |
| aha. Windows 8.1 added a new type RenderTargetBitmap that might help me | 21:48.13 |
| ugh. the stupid sample they have is only in c# | 21:48.32 |
| off to run some errands. bbiaw. Robin_Watts it will probably be this weekend before I get the new patch for you to review | 22:01.46 |
| Forward 1 day (to 2013/12/13)>>> | |